[GLASSFISH-19525] Enabling secure admin fails if admin realm is configured to use LDAP instead of the provided FileRealm Created: 11/Jan/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.2.2, 4.0
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: Tim Quinn Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-20182 configure-ldap-for-admin command shou... Open
Tags: 4_0-approved

 Description   

Shawn reported this in the GlassFish forum.

If the admin realm is configured, for instance, to use LDAP instead of the build-in FileRealm, then enabling secure admin fails with an exception similar to this:

javax.enterprise.system.tools.admin.com.sun.enterprise.security.admin.cli|_ThreadID=17; _ThreadName=Thread-2;ClassName=org.glassfish.api.ActionReport;MethodName=failure;|Error enabling secure admin
org.jvnet.hk2.config.TransactionFailure: java.lang.NullPointerException
  at com.sun.enterprise.security.admin.cli.EnableSecureAdminCommand.run(EnableSecureAdminCommand.java:151)
  at com.sun.enterprise.security.admin.cli.SecureAdminCommand.execute(SecureAdminCommand.java:891)
  at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
  at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
  at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
  at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
  at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
  at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
  at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
  at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
  at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
  at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:117)
...several other higher classes that may not be meaningful...
  at java.lang.Thread.run(Unknown Source)


 Comments   
Comment by Tim Quinn [ 14/Jan/13 ]

Because enabling secure admin allows remote administration the system is trying to make sure that no admin user has an empty password.

The code for this check is not correctly handling the case in which an admin realm other than the default file realm has been configured.

So far there does not seem to be a good workaround, but we are still looking.

Comment by Tim Quinn [ 14/Jan/13 ]

Fix checked in for 4.0 (trunk).

Project: glassfish
Repository: svn
Revision: 58369
Author: tjquinn
Date: 2013-01-14 16:50:21 UTC
Link:

Log Message:
------------
Fix for 19525

Before allowing a user to enable secure admin the system checks to make sure that there are no admin users in the default file realm with empty passwords, which would be a security risk. That checking code failed if the user configures a non-default admin realm, such as LDAP, throwing a NPE.

This change skips the check if the admin realm is not the file realm.

Tests: QL

Revisions:
----------
58369

Modified Paths:
---------------
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminHelperImpl.java

Comment by Tim Quinn [ 04/Apr/13 ]

The earlier fix for this was not correct, and when using an LDAP realm for admin authentication the enable-secure-admin command still fails incorrectly.

  • What is the impact on the customer of the bug?
    Any customer using an LDAP admin security realm who tries to enable secure admin will encounter this problem.
  • What is the cost/risk of fixing the bug?
    The fix is a one-line (actually a one-word) fix. I have it in my local workspace and it resolves the problem.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
  • Which is the targeted build of 4.0 for this fix?
    b84
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    N/A
Comment by Tom Mueller [ 04/Apr/13 ]

Approved for 4.0.

Comment by javashawn [ 04/Apr/13 ]

I just wanted to point out that we have found a workaround for this issue that applies to v3.1.2.2. We discovered this issue documented here when we tried to setup admin for LDAP by creating a GlassFish domain based on a domain template (customized to change the admin-realm to use the LDAP realm).

We were able to workaround the issue by doing the following:
1. Instead of using the customized domain template we now use the default template (domain.xml) to create our GlassFish domain.
2. We enable-secure-admin (server must be running).
3. We then add a LDAP realm:
create-auth-realm -classname com.sun.enterprise.security.auth.realm.ldap.LDAPRealm --property jaas-context=ldapRealm:group-mapping=[ldap group to control admin access]>asadmin:group-search-filter=[LDAP group search filter]:search-bind-password=[LDAP bind account password - we use a PW alias here]:search-bind-dn=[LDAP search bind dn]:base-dn=[LDAP base dn]:directory=[LDAP server url] ldap-admin-realm
4. Delete the file-based admin-realm:
asadmin delete-auth-realm admin-realm
5. Stop the domain.
6. Rename the ldap-admin-realm that you just created to "admin-realm" in the domain's domain.xml. We're using the Ant "replace" task to do this.
7. Start the domain.

On a side note, when we originally began working with setting up GF admin realm to use LDAP we were trying to understand why the configure-ldap-for-admin subcommand only let you set the basedn and ldap-group attributes? This is what started us down the path of using a domain template that populated the other attributes (such as group-search-filter). It seems like the configure-ldap-for-admin command should allow for setting the same properties available for the LDAPRealm?

Comment by Tim Quinn [ 04/Apr/13 ]

Fix checked in:

Project: glassfish
Repository: svn
Revision: 61180
Author: tjquinn
Date: 2013-04-04 22:02:22 UTC
Link:

Log Message:
------------
GLASSFISH-19525 - Enabling secure admin fails if admin realm is configured to use LDAP instead of the provided FileRealm

An earlier fix for this issue correctly sidestepped the check of the file admin realm for admins with empty passwords when LDAP was configured for admin authentication but a method incorrectly returned "true" in that case when it should have returned "false."

Reviewed by Jeff T
Approved by Tom M
Passed QL tests, manual test with LDAP admin configured and enabling (and disabling) secure admin

Revisions:
----------
61180

Modified Paths:
---------------
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminHelperImpl.java

Comment by Tim Quinn [ 04/Apr/13 ]

javashawn,

I've created GLASSFISH-20182 to capture your improvement request. Thanks, and thanks for sharing the workaround.

Generated at Fri May 29 10:18:56 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.