Exinda | Synchronizing LDAP Users for Exinda Authentication and assigning Exinda roles to individual users

Summary

Synchronize LDAP Users for Exinda Authentication and how to assign exinda roles to individual users

Overview

Customer needs to set up the Exinda Authentication options to synchronize with the LDAP users. We can assign a specific Group or Organization Unit as the Base for all the users allowed to log into Exinda. In this document we will explain how to do this and how to map individual users within that group or OU with a specific permission (admin or monitor).

Resolution

How to set-up an Exinda Appliance with LDAP

This document shows the basics of configuring an Exinda appliance with a LDAP server, to be used for authentication only.

On the Exinda, it is a two-step process to configure LDAP (AAA and LDAP sections).

1. Configure the Global LDAP Settings in System Authentication LDAP.
   1. User Base DN: This is where the user info is stored in the LDAP tree. It must be an OU for now. We will later on mention how to assign the User Base to a specific Group within that OU. It is important to clarify that this field must be filled out with the entire distinguished name of the OU. In Active Directory, the command "dsquery" helps you list the correct DN's.
   2. User Search Scope: We use Subtree by default, but any of the options are valid.
   3. Login Attribute: By default we recommend sAMAccountName, as it most cleanly matches up with the back-end LDAP schema attributes, but any other attribute is valid. sAMAccount is the portion of the email address before the @. E.G: user.exinda@company.com has a sAMAccount of "user.exinda".
   4. Bind DN: The bind DN is the external user permitted to search the LDAP directory within the defined search base. Most of the time, the bind DN will be permitted to search the entire directory. The role of the bind DN is to query the directory using the LDAP query filter and search for the base DN for authenticating Exinda user. When the DN is returned, the DN and password are used to authenticate the Exinda user. This user can be part of any OU or Group, it does not need to be part of the BASE DN above, the only condition is that it needs to have enough rights to query the LDAP directory (it is recommended to be a member of the "Domain Admins" group).
   5. Bind Password: The password of the Bind DN account already described above.
   6. Timeout: Use default 5 seconds.
   7. LDAP Version: Use 3.
   8. Server Port: Use default 389 or the appropriate one your LDAP server is using.

Click Apply Changes

1. Insert LDAP server IP in box near bottom of screen.

Click Add New LDAP Server

1. Turn on LDAP authentication.
   1. Change Authentication Method List in System Authentication AAA.
   2. Change First Method to Local.
   3. Change Second Method to LDAP.
   4. Change Authorization/Map Order: remote-first.
   5. Change Authorization/Map Default User: monitor.

Screen Shots of Configuration Parameters

Once the steps above are working, you can limit the ability to log into the Exinda to a specific LDAP Group with the CLI command "ldap group-dn" followed by the distinguished name of the group.

Issues Found:

• The Bind Password might reset itself after making a change in any of these options. If you make any changes to the Global LDAP Settings, make sure you re-type the BIND password.

Map Individual LDAP Users to have different login permissions

Even after successfully configured a limited number of LDAP Users to log into the Exinda with Active Directory credentials, user might need to map individual users to access with admin privileges and others with monitor privileges. In order to do so, we need to add a Custom Attribute called local-user-name. The steps to implement this solution are shown below but only for Active Directory:

NOTE: For users not configured with this attribute (or attribute not set), they will log in with whatever permissions are set under Configuration-->Authentication-->AAA?Authorization?Map Default User

1.- In order to create a new Attribute, you will need a Unique OID generated by the Active Directory Server. To create one, you will need to copy the script found in the below link and save it as a .vbs file extension in the DC Hard Drive:
https://gallery.technet.microsoft.com/scriptcenter/56b78004-40d0-41cf-b95e-6e795b2e8a06
Then you can run the script (double click the file) and you will be prompted with a screen like the one below:


That will be the OID you will use, copy it and save it, you will need it later.

2. With Administrative Access to the Active Directory controller, open a windows command prompt (cmd).
3. Mount the Active Directory Schema with the following command:

regsvr32 schmmgmt.dll



4. Open the MMC console by typing MMC at the Start Menu. Once there, Click on File Add/Remove Snap-in and add the Active Directory Schema:



5. Once in the Active Directory Schema, right-click on Attributes and then select Create Attribute (A warning screen will show up, simply click on Continue).



6. The attribute created will need to have the next configuration (The Unique X500 Object ID is for the number saved in a step 1):


7. Click on OK, then refresh the Active Directory Schema console and look for the newly created Attribute:



8. Once the attribute has been created, we need to add it to the user class. Go to the Classes sub directory within the Active Directory Schema console, look for the user class, right click on it and select Properties:



9. Select the Attributes tab, click on Add, look for the attribute and then on OK.



10. Restart the Active Directory Service using the services.mmc console
11. Verify that the changes were applied properly: Open the Active Directory Users and Computers snap-in, click on View Advanced Features. Then look on any user, right-click on it and select Properties, then go to the Attribute Editor and make sure that the new Attribute is there (it will be pointing to value: <not set> if you are seeing it for the first time):



12. Simply, go to the specific user, double click on this attribute (image above) and change the value to monitor or admin.
 

Issues Found:

• You can add the attribute to a group and change it from a group level as well, however you need to verify that the Active Directory Users are properly inheriting these values from the Group. The steps to do this are not covered in this documentation, please contact Microsoft Support.