glassfish
  1. glassfish
  2. GLASSFISH-19525

Enabling secure admin fails if admin realm is configured to use LDAP instead of the provided FileRealm

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.2.2, 4.0
    • Fix Version/s: 4.0_b84_RC1
    • Component/s: admin
    • Labels:
      None

      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)
      

        Issue Links

          Activity

          Tim Quinn created issue -
          Hide
          Tim Quinn added a comment -

          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.

          Show
          Tim Quinn added a comment - 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.
          Hide
          Tim Quinn added a comment -

          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

          Show
          Tim Quinn added a comment - 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
          Tim Quinn made changes -
          Field Original Value New Value
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 4.0_b72_EE7MS4 [ 16101 ]
          Resolution Fixed [ 1 ]
          Hide
          Tim Quinn added a comment -

          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
          Show
          Tim Quinn added a comment - 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
          Tim Quinn made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Tags 4_0-review
          Hide
          Tom Mueller added a comment -

          Approved for 4.0.

          Show
          Tom Mueller added a comment - Approved for 4.0.
          Tom Mueller made changes -
          Tags 4_0-review 4_0-approved
          Hide
          javashawn added a comment -

          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?

          Show
          javashawn added a comment - 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?
          Hide
          Tim Quinn added a comment -

          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

          Show
          Tim Quinn added a comment - 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
          Tim Quinn made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Fix Version/s 4.0_b84_RC1 [ 16113 ]
          Fix Version/s 4.0_b72_EE7MS4 [ 16101 ]
          Resolution Fixed [ 1 ]
          Hide
          Tim Quinn added a comment -

          javashawn,

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

          Show
          Tim Quinn added a comment - javashawn, I've created GLASSFISH-20182 to capture your improvement request. Thanks, and thanks for sharing the workaround.
          Tim Quinn made changes -
          Link This issue is related to GLASSFISH-20182 [ GLASSFISH-20182 ]

            People

            • Assignee:
              Tim Quinn
              Reporter:
              Tim Quinn
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: