Configure LDAP in DX UIM to integrate with AD authentication
Article ID: 11420
Updated On:
Products
Issue/Introduction
How can I configure LDAP in DX UIM to integrate with AD authentication?
Environment
DX UIM 23.4.* / 20.4.*
Cause
Guidance
Resolution
LDAP Authentication
Selecting this option, the hub probe can be configured to forward login requests to an LDAP server. This makes it possible to log on to the Nimsoft consoles as an LDAP user. Using ACLs (Access Control Lists), defined in the Infrastructure Manager, users belonging to different groups in LDAP can be assigned different permissions in Nimsoft.
Hub LDAP parameters
The HUB can be configured to point to a specific LDAP server, using IP address or hostname. A Lookup button lets you test the communication.
· Select the LDAP server type. Currently, two LDAP server types are supported; Active Directory and eDirectory.
· Use SSL
Tick this option if you want to use SSL during LDAP communication. Most LDAP servers are configured to use SSL.
· You must also specify a username and a password to be used by the HUB when accessing the LDAP server to retrieve information.
In Active Directory, the user can be specified as an ordinary username.
In eDirectory, the user must be specified as a path to the user in LDAP on the format CN=yyy,O=xxx, where CN is the username and O is the organization.
· Specify a group container in LDAP to define where in the LDAP structure to search for groups. Clicking the Test button lets you check if the container is valid.
Finally, specify a user container in LDAP to define more specifically where in the LDAP structure to search for users.
STEPS TO FOLLOW:
Open the hub probe-> Select the General Tab->Click on the Settings button
1. Select LDAP Authentication
2. Enter a Server Name
3. Select the Server Type. In this case AD
4. Change the Group Container to:
CN=User,DC=xxxx,DC=xxxxx
Where XXXX is your domain
5. Add the user in the form of domain\user
6. Add the password
LDAP Authentication prerequisites
In Active Directory create a single flat group in the AD for your Nimsoft users (create an OU that is dedicated for NMS groups), e.g., Nimsoft-Admins, You also need to add this group to each user you want to have Nimsoft access.
Then using the Infrastructure Manager, create an ACL and specify the LDAP Group you just created as your Nimsoft group.
LDAP/Active Directory authentication configuration tips:
Note that UIM (Nimsoft) supports Active Directory and eDirectory LDAP interfaces.
Add an Active Directory Group (Task for the Active Directory Admin)
Make sure that the group you add to the AD is truly a FLAT AD group. Nested groups are currently NOT supported. 'Groups within groups' or AD referrals are not supported in any manner. A nested group in this context means:
- LDAP Group A Exists
- Individual User is a direct member of LDAP Group A
- LDAP Group B Also Exists
- LDAP Group A is added to LDAP Group B's membership so that users who are members of A are now also 'indirectly' members of B.
IMPORTANT: Currently you cannot use nested groups/users within an AD group otherwise it will not work correctly. You MUST use just one 'FLAT' group with your Nimsoft 'admin' users in it - don't 'nest' sub-groups with users in it as it will not work.
When nested groups are used, associating the ACL with a given login user will not work since the hub doesn't see/treat the user as a direct member of the group. The user must be a direct member of a single flat group meaning that the group would be listed in the Active Directory "MemberOf" attribute.
Other hub settings:
Open the hub in Raw Configure mode and select the ldap->templates section.
By default, the hub probe is configured with the default setting:
member_lookup_reverse = yes
Open the hub probe in Raw Configure and set:
member_lookup_reverse = no
Do this above IF the DN contains a comma. Then the hub will use the 'old' lookup method, which still works even if the DN contains a , character.
Username format
Also using hub Raw Configure, you can try changing the default setting of:
format = $username@$domain
to
format = $username
Please also set:
lookup = no
Then click ok to restart the hub.
When you try to login, use a simple username from AD such as jsmith.
LDAP Groups
After you have configured a flat group in LDAP for Nimsoft administrators such as "Nimsoft-Admins", and the user(s) are a direct member of that group in the AD, when you are logged in to the Infrastructure Manager, in the IM Menu:
Select Security->Manage Access Control List...
Select or define a new ACL.
Then Click the "Set LDAP Group" button to set the LDAP group for that ACL. As a result of clicking on the button "Set LDAP Group" you should see a list of LDAP groups populated in the window INCLUDING the one you created in the AD, e.g., <XXXXX-Admins>
Once you associate the ACL you created with the flat AD group in the Infrastructure Manager, e.g., Nimsoft-Admins LDAP group associated with your defined ACL, e.g., 'NMS_ADMINS,' then authenticating as the user(s) belonging to that LDAP group that is associated with the ACL should work as expected.
Once the AD (LDAP) user is logged in you will see their active login id displayed on the bottom left-hand side of the IM client window.
Additional Information
Troubleshooting:
Creating a FLAT Group
Create a group in AD for your Nimsoft users (create an OU that is dedicated for NMS groups). You also need to add this group to each user you want to have Nimsoft access.
Using the Infrastructure Manager make sure you have defined an ACL and associated the LDAP Group you created in AD for Nimsoft users, to the ACL.
The Group DN is the distinguishedName in LDAP of a specific group of users who need Nimsoft access.
Once AD is properly configured, in the Infrastructure Manager, click Security->Manage ACLs, Set LDAP Group to and you should see the available AD Groups. Do you see the available groups?
Moreover, when testing login using an AD user that belongs directly to the flat group you created, you should check the hub log and make sure the group you created is listed in the log output. If it is NOT listed, then there is something wrong with/different about that group, e.g., it is not configured properly or it is not a flat group. If the flat group which was created in AD is not listed in the log output then LDAP user authentication will not work.
Collecting logs
Open the hub using Raw Configure and under the 'hub' section set the loglevel to 5 and then set the logsize to 15000. Click Ok and let the hub restart.
Login as that user to IM to make sure they can authenticate successfully and if not check the hub log.
Try associating that user to an ACL/reproduce the issue originally reported in the case.
If the group is truly flat and created properly in AD, the hub log should list the group as in the hub log below, you can see the AD group 'Nimsoft-Admins'
Feb 24 10:41:09:592 [1684] hub: 17 PDS_PCH 30 XXXX_XXXXX_XXX_users_d ~
Feb 24 10:41:09:592 [1684] hub: 18 PDS_PCH 32 DEV_XXX_XXXXXXX_XXX_users_~
Feb 24 10:41:09:592 [1684] hub: 19 PDS_PCH 14 XXX-XXXX
If the AD group is NOT listed in the hub log it is not found/known by the hub and you will get an error like the one below:
hub: access [LDAP] - no ACL found for user=CN=<username>,OU=Users,OU=XXXX,OU=XXXXX,DC=am,DC=corp,DC=XXXXX,DC=com
Also as a test, and for diagnostic purposes only - you could temporarily associate the defined ACL with one of the groups which DOES appear in the hub.log just to validate whether that allows the user to log in.
If authentication still fails please attach the hub.log and _hub.log to your Support Case showing the failure and indicate the login username.
Additional notes:
1) Direct LDAP is only available on Linux and Windows hubs, due to the availability of the LDAP library the hub uses. So native LDAP is NOT supported on Solaris.
2) Regarding hub support for Linux-based LDAP servers.
The code will actually work against anything that implements the Microsoft ActiveDirectory LDAP protocol or the Novell eDirectory LDAP protocol. We have a customer that uses IBM Tivoli LDAP server on Linux, which the hub treats/sees as an 'eDirectory' instance.
3) OpenLDAP on Linux does NOT work.
4) We only currently TEST against Windows Active Directory.
Feedback
