In this post an overview of the integration of the IMC TAM module with an Active Directory LDAP Server.

The goal of this configuration is to ensure members of a specific Active Directory group (for example g_networkadmins) are granted a specific IMC TAM Policy level.

The post has the following sections:

• Overview of Active Directory structure used in lab
• Installation/Version overview of TAM
• TAM Policy creation
• TAM LDAP Server definition
• TAM LDAP Sync policy
• Results

 

Overview of Active Directory structure used in lab

Hierarchy

An LDAP Server such as Active Directory is using a hierarchical structure to present its objects. This is similar to a filesystem which is using a directory structure.

In case of a filesystem, a specific file can be found based on the full path (e.g. c:\data\file.txt), in case of an LDAP directory, an object (such as a user) can be found based on its Distinguished Name (DN – e.g. cn=user,ou=test,dc=my,dc=com).

For a Microsoft Active Directory, which is used for Windows domains, the DNS Domain name section is represented by DC (domain component), then you will typically see OU (Organizational Units), and finally the end object identified with a CN (Common Name).

 

 

 

This full path altogether is referred to as the Distinguished Name.

LDAP Bind

An Active Directory will typically not allow anonymous connections to get much information out of the LDAP Server. This means that in order to retrieve a user list out of the LDAP Directory, you will need to logon with some credentials.

While most applications would just prompt for a username/password, an LDAP Server will expect the full Distinguished Name of the user which is used to login.

Since IMC TAM/UAM needs to query which users exist in the Active Directory, you will need to create a user for this purpose. So the only  purpose is to query the Active Directory, in order to discover new or updated user objects.

Inside IMC, this is referred to as the ADMIN DN, which I do not really prefer as description, since a normal Active Directory user can be used for this. Since we do not want IMC LDAP sync to break when a normal user account changes his password, you should create a dedicated ldap sync user for IMC.

The location in the Directory for this LDAP sync user is not important at all. In general, most organizations will have some OU for service/system accounts, so it makes sense to create this ldap-sync user in this OU.

Make sure to note the actual location in the AD, since you need to use the DN of this object to enter into IMC LDAP server properties.

In this lab example, a standard Domain User imc-uam-ldap is created in the OU System under the OU Corporate.

The DN of the object would be

cn=imc-uam-ldap,ou=system,ou=corporate,dc=hpnet,dc=local

Make sure to set the password to never expire:

 

 

 

 

 

 

 

 

 

 

 

Users and Groups

Network Administrator Groups

Active Directory users can exist under multiple OUs, but a user cannot be in 2 OUs at the same time.

To organize access rights, the AD will use groups, since a user can be member of multiple groups. When a user is made member of a group, the Group DN will be saved to the user in the memberOf attribute of the user. In the GUI, you will not see the DN, just the display name of the group.

For the TAM module, the example will use 2 groups:

• g_netadmin_level1
• g_netadmin_level2

Since these groups will be used as a condition to import TAM users (network admins), you will need to known the DN of these groups.

In this example the DNs are:

• cn=g_netadmin_level1,ou=groups,ou=corporate,dc=hpnet,dc=local
• cn=g_netadmin_level2,ou=groups,ou=corporate,dc=hpnet,dc=local

When you make a user member of 1 of these groups, this group DN will be listed under the memberOf attribute of the user.

Network Admin users

Some sample users (admin-level1 and admin-level2) have been created, these users have been placed into the 2 network admin groups. Existing users could have been used as well, just make them member of 1 of these groups.

 

Installation/Version overview of TAM

The sample setup is based on IMC PLAT 7.1 E0302 and IMC TAM 7.1 E0302:

 

Once Installed, the TAM module can be found under the User page of IMC.

• Device User: the actual users
• Device User Policy: the configuration of the TAM module

 

TAM Policy creation

In the TAM module, the IMC Admin can define different roles for different users. These roles are referred to as Policies.

Each policy can control permitted and denied commands or access levels to the systems.

In this example, we focus on the LDAP integration, so 2 sample policies are created without going into the details of the policies:

 

TAM LDAP Server definition

The IMC Admin now needs to define the LDAP Server object. This will include the LDAP Bind account. The Server definition does not import any users, it simply defines the target LDAP object with the credentials to query LDAP information.

Under Device Access Policy > LDAP > LDAP Servers, a new LDAP Server can be defined:

 

Next, a server name and IP Address can be configured. The server Type should be set toe Microsoft AD.

For the Server Information, you need to configure:

• Base DN: The DN of the domain, this is the root query level
  dc=hpnet,dc=local
• Admin DN: This is the LDAP Bind user, which is the imc-uam-ldap account created earlier. This does not need to be an administrator in the domain (normal domain user). This must be the DN of the LDAP Bind user.
  cn=imc-uam-ldap,ou=system,ou=corporate,dc=hpnet,dc=local

 

Once the Server information has been entered, the Test button can be used.

At this point, the TAM module will perform an LDAP Bind to the AD to verify the Admin DN credentials.

By default, LDAP is clear text, as can be seen in the network trace:

201411-imctam-ldap-test-clear

Make sure to enable LDAP SSL for this connection. The procedure is the same as of UAM LDAP and can be found here:

https://abouthpnetworking.com/2013/12/27/imc-uam-secure-ldap/

TAM LDAP Sync policy

Once the LDAP Server has been created, LDAP Sync policies can be defined.

An LDAP Sync policy will control which users will be bound to which TAM Policy. If you want to assign multiple groups each to their own policy, multiple LDAP sync policies must be created.

To add a Sync Policy, navigate to User>Device User Policy>LDAP Service>Sync Policies

 

Sync Policy Query

An LDAP Sync policy is based on an LDAP query, by default the query will be based on an OU. This means that all user objects under an OU will be selected by the policy.

Once a user is selected by the Sync Policy, it will be bound to a TAM Policy, so the user can login to the devices.

Since not all network admins may be grouped into 1 OU, and since you may want to assign different TAM Policies to different users, it would be better to ensure the Sync Policy only only matches users of a given group (not OU). This can be achieved using the filter option of the LDAP Sync Policy.

LDAP Sync Policy1: Level1 users

The Sync Policy will be configured with a Sub-base DN, this is the top OU level where the search will be started. Since the network admins can be placed in any OU under the Corporate OU, the Sub-base DN will be set at this high level:

Sub-Base DN : ou=corporate,dc=hpnet,dc=local

Next the filter will be used to get only the users who have a memberOf attribute which contains the DN of the desired group.

The first sync policy will be configured to select users of the group g_networkadmin_level1, the DN of this group is:

cn=g_netadmin_level1,ou=groups,ou=corporate,dc=hpnet,dc=local

The default filter shows (&(objectclass=user)(sAMAccountName=*)) , which means that all users found under the the Corporate OU would be added, which is not the desired result. A new filter will be used, to ensure only users of the given group are matched.

We simply add an additional AND filter (&) to look for objects matching the memberOf attribute:

(&(objectclass=user)(sAMAccountName=*)(memberOf=cn=g_netadmin_level1,ou=groups,ou=corporate,dc=hpnet,dc=local))

Click on the Next button to continue.

Login Password

In this screen, some attribute mapping can be configured. You will notice that the Login password must be configured. Since the AD does not support to extract the user passwords in clear text, the field cannot be synced to the IMC TAM user database.

When a user attempts a login, the IMC TAM server will use the entered credentials and perform an LDAP Bind to the AD with these credentials.

So if this works with an LDAP Bind, why do we need to configure a login password ?

The reason is very simple: as a result of the LDAP Sync policy, Device user objects will be created in IMC TAM. These are “LDAP-Bound” user accounts. When the IMC Admin would “disconnect” the user from the LDAP server, the user object becomes a local IMC TAM device user. This user will get this configured password by default. (so normally this password would never be used!)

User Authorization Policy

This field allows you to assign one of the predefined authorization policies to users matching this Sync policy

Once you finish the policy creation, a configuration should be shown:

Now the synchronization can be manually run to verify the results:

 

Under the Device User page, the new user should be listed:

And when you click on this user, it has been bound to the Level1 Policy:

LDAP Sync Policy1: Level1 users

Now this is repeated for the g_netadmin_level2 group:

Add new Policy

Use filter for the second group:

(&(objectclass=user)(sAMAccountName=*)(memberOf=cn=g_netadmin_level2,ou=groups,ou=corporate,dc=hpnet,dc=local))

 

Configure the password and now assign level2

Run the manual sync to test

 

Navigate to the Device User list, open the details of the admin-level2 user.

This shows the other policy has imported the user and assigned the correct policy.

 

Any users who are added to these 2 groups will be authorized due to the Sync schedule.

 

System Parameters

The LDAP Sync schedule and parameters can be configured under the Device User Policy>Service Parameters :

Under the System Settings, the LDAP options can be set:

Additional Notes

Based on the lab setup, I noticed these behaviors:

• So far, it seems there is no option to set LDAP Sync priorities, so if a user is member of both Groups, it is not configurable which policy will be applied
• Once a user has been processed by a Sync policy, the applied TAM Policy seems to be fixed to the user. So when a user would be removed from 1 group and added to another group, it still uses the original TAM Policy. The user will need to be manually updated in TAM with the new policy.

Let’s hope these things get fixed, since it simplifies the daily administration of users.