I have configured the LDAP integration via the GUI as described in the Platform Administration Guide. I configure under Authentication Management -> LDAP General Configuration and select Microsift Active Directory. The LDAP server URL is configured with the DN that specifies the root that should be connected to. I have ticked the Distinguished Name Resolution box and added the DNS of the Search-Entitled user and added the password. When I add the username and password to the Test DN Resolution box (UUID and Password), I am able to succesfully obtain a "Bound in succesfully as" message back when I hit the "Test" button.
Moving on to the LDAP Group Mapping Configuration box, I add the values for the base and the filters and when I hit the Test button, I am able to see the three groups in the AD that I want to map to three groups in BSM.
I then finish this box and it succesfully presents me with a summary of the settings that i have used. I therefore move to the User Management Tab and am able to map the AD groups to BSM Groups. No problems so far.
I have also added a new user and given that user Superuser capabilites as per the documentation, so that if I log off and the integration does not work, I will have a user that still has Superuser capabilites. The user is added to the root of the user/groups tree.
All of the DN's and the specification of the Search-Entitled user have been found by using the Softerra LDAP Browser (from the same server that BSM is installed on) and I have succesfully connected with the same user specified as the Search-Entitled user in the BSM configuration using the LDAP browser and seen the groups etc. that I want to see. This is also confirmed in BSM as previously described by my use of the test buttons in the configuration screens.User synchronization IS enabled.
Now comes the problem.
After all of this testing and setup, I log out of BSM (having been logged in as the administrator) and attempt to log back in using a user that I know exists in a group in the AD that I have mapped to a group in BSM. However, I am unable to log back into BSM with that user and I just get the "incorrect user/password, contact the system administrator message". I am also not able to log on using the Superuser user that I configured beforehand (same error message).
Looking at the logon.log I see this error message:
2012-03-27 15:22:30,551 [ajp-0.0.0.0-8009-4] (LDAPUtils.java:429) ERROR - Failed to create LDAP User Management com.hp.sw.bto.ast.security.uum.UserManagementException: Exception caught while connecting to LDAP with the following configuration parameters: com.hp.sw.bto.ast.security.uum.UserManagementLDAPConfiguration@2b9292a
Caused by: com.hp.sw.bto.ast.security.uum.UserManagementConnectionException: Exception, while connecting to LDAP with the following configuration parameters: com.hp.sw.bto.ast.security.uum.UserManagementLDAPConfiguration@2b9292a at com.hp.sw.bto.ast.security.uum.LDAPTools.createConnectionAndConnect(LDAPTools.java:170) at com.hp.sw.bto.ast.security.uum.UserManagementLDAP.findUser(UserManagementLDAP.java:113) ... 98 more Caused by: com.hp.sw.bto.ast.security.uum.UserManagementConnectionException: Cannot connect to host = ad.nss.nnit.com, port = 389, username = cn=ec_bsm_services,ou=service accounts,ou=xx,dc=xx,dc=xx,dc=xx,dc=xx at com.hp.sw.bto.ast.security.uum.LDAPTools.ldapConnect(LDAPTools.java:194) at com.hp.sw.bto.ast.security.uum.LDAPTools.createConnectionAndConnect(LDAPTools.java:168) ... 99 more Caused by: netscape.ldap.LDAPException: error result (49); 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 52e, v1771 at netscape.ldap.LDAPConnection.checkMsg(LDAPConnection.java:4852)
I do not understadn why I am getting the Cannot connect to host message, as I am able to succesfully connect using the LDAP browser with the same credentials from the same host (note the real values of the DN have been replaced tih x's).
Anybody know what the last:
"LDAPException error result (49); 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 52e, v1771"
Anybody have any clues as to what the problem might be ??
Once you enable LDAP all local user accounts are disabled. You can use the JMX console to disable the LDAP Authentication so the local accounts will get you back in to trouble shoot. Let me know if you need help with the JMX console settings
Hi Kevin, thanks for the update. I was wondering why it states in the manual that in order to avoid being locked out, one should create a user with Superuser capabilites before enabling user synchronisation. I am fine with using the lmx-console to get back in again. I was asked to HP SUpport to make this change:
Modify Admin>platform>infrastructure settings > Foundations (SSO) Unknown User Handling Mode to Allow instead of Integration User.
In addition I changed the Gourps search filter to "objectClass=group" as well as the Root Groups Filter.
This has changed the stack trace in the usersync log file, so that it seems that "BSM" is now able to access the AD, but is still unable to find the user that I try to log in with. Looks like it is now a question of getting the LDAP filters and base parameters correctly set up.
I promised to get back to this when I found the solution.
I have found the solution.
Bottom line at the top - the issue was that the ldap integration was not pointing at the right Root Groups base DN.
It's a pity that the error messages emanting from BSM in relation to this problem are very poor.
Anyhow, the way to solve the issue was to use an LDAP Browser (the one from Softerra mentioned elsewhere in this forum is great) to gain a knowledge of the way that the groups are structured in the AD and also to identify the various elements that you need to point to. For example, locate the service account that you are using to interrogate the LDAP, use the proporties button and copy and paste the precise DN (or whatever) specification into your BSM LDAP integration setup.
Make sure that your Root Groups base DN really does point to a place in the AD tree that gives you access to the groups that you want to map. Use the test button both on the first ad last pages of the wizard to test that your user can actually interrogate the LDAP and find a user that you know to be in one of the groups that you will be mapping (this is where I failed).