Extending the capability of secldap to authenticate from multiple data sources

The secldapclntd daemon establishes connection between an LDAP server and the AIX® security LDAP module. Usual steps to configure a secldapclntd daemon with LDAP server allows us to provide multiple replicated LDAP server details during configuration. However, there can be a situation when the information for all the users is not available in only one LDAP server. In such a scenario, configuring just one active LDAP server details might not be sufficient. To resolve this limitation, this article demonstrates the usage of pass-through authentication feature in IBM Tivoli Directory Server. The steps listed in this article can be followed to configure a setup such that AIX security module will be able to seek authentication information from multiple data sources and yet hide the backend server details from the client, hence ensuring abstraction and security.

Share:

Nikhil Firke (nikhilfirke@in.ibm.com), System Software Engineer, IBM India Software Labs

Nikhil FirkeNikhil is a System Software Engineer, currently working with IBM India Software Labs in Pune, India. He has extensive experience with Tivoli Security products including Tivoli Directory Server, Tivoli Identity Manager, and Tivoli Directory Integrator. He holds a degree in Computers Engineering from Pune Institute of Computer Technology.



Nilesh T. Patel (nilesh.patel@in.ibm.com), System Software Engineer, IBM India Software Labs

Nilesh PatelNilesh is a System Software Engineer, currently working with Tivoli Security team as a technical leader of IBM Tivoli Directory Server team in IBM India Software Labs for past 4 years. His areas of expertise include IBM Tivoli Directory Server, Tivoli Access Manager, Tivoli Identity Manager, Tivoli Directory integrator and Virtual Member Manager. Nilesh holds a degree in Information technology from Pune Institute of Computer Technology in Pune, India.



01 June 2010

Also available in Chinese

Introduction - Limitation to secldap (mksecldap) utility

Develop skills on this topic

This content is part of a progressive knowledge path for advancing your skills. See AIX security: Learn the basics

The LDAP server is an important part of any security setup. For AIX, the secldapclntd daemon manages the connection between an LDAP server and the internal AIX security LDAP module. The LDAP implementation of the security subsystem in AIX is available as the LDAP authentication load module. This module is a complete package that supports user authentication. Developers have provided a utility, mksecldap to simplify the secldapclntd daemon configuration. The mksecldap command can be used to set up a LDAP security information server.

Most commonly used, and also the recommended LDAP server for AIX security infrastructure, is the IBM Tivoli Directory Server. It is highly recommended that AIX user/group management be configured using IBM Tivoli Directory Servers servers. However, when configuring a secldapclntd daemon, the utility, mksecldap, allows us to provide only typical LDAP server details during the configuration process. There is no option to provide a secondary authentication data source, which can be alternatively probed if data is not found on the primary LDAP server. However, multiple LDAP servers which contain the replicated data can be configured with secldapclntd daemon. Replicated servers get activated when request to default servers encounters a rc = 81 (Can't contact LDAP server) from the server. With such a limitation, it becomes a requirement for the single LDAP server to store all the user authentication information.

There can be scenarios where it is necessary for Tivoli Directory Server to support users present in another directory server. Migrating users from another directory to Tivoli Directory Server is one of the possible solutions. But this is not only a time consuming effort, but we also need to consider the scalability factor for the single Tivoli Directory Server which will have to suddenly handle an increased load. Maintaining users in two different directories takes up a lot of space, and keeping users in sync in both the directories will be another administrative overhead. Apart from these scalability and memory usage issues, the existing application's compatibility also needs to be handled. Migration of all the existing applications to a new LDAP server cannot be done on a short notice and usually takes time to configure the upgraded applications with a new LDAP server.

To resolve this secldap limitation, this article demonstrates the usage of the pass-through authentication feature in Tivoli Directory Server. This feature has been introduced in Tivoli Directory Server V6.1; we will be using Tivoli Directory Server V6.2 for demonstrating our sample setup.


Conceptual background for pass-through authentication

Tivoli Directory Server provides user authentication for the users stored in its directory. Any client which uses Tivoli Directory Server and is looking for authentication information needs to bind to the correct Tivoli Directory Server for retrieving the authentication information. The user has to perform a successful bind to the directory using his password to be authorized for subsequent LDAP operations. Tivoli Directory Server by default supports authentication only to local users (i.e., the users present in the local directory).

Pass-through authentication is a mechanism which allows a client to bind to a directory server even if the user credential is not available locally. Using this mechanism the server attempts to verify the credentials from another external directory server or a pass-through server on behalf of the client. The credential here refers to the userpassword attribute in Tivoli Directory Server.

Points to remember for a successful pass-through authentication:

  • After pass-through authentication is configured, make sure that the pass-through authentication server is up and running when the Tivoli Directory Server is started.
  • The pass-through authentication server should be a LDAP server.
  • The pass-through authentication server must always be reachable for pass-through authentication to work.
Figure 1. Pass-through authentication working.
Illustration showing how pass-through authentication works
  1. A client binds to the Tivoli Directory Server normally without the knowledge of any pass-through authentication configuration.
  2. Tivoli Directory Server determines that the entry for the particular client does exist but the user password attribute, which would have helped in authenticating the client, does not exist. If no pass-through authentication was configured in the Tivoli Directory Server, it would not have cared to look for the credentials on some other server. However, if the server is configured to perform a pass-through authentication to another server, the Tivoli Directory Server would continue with the following steps.
  3. The same credentials which the client used to bind to the Tivoli Directory Server, are used to bind to the other data source.
  4. The other data source, which has the credentials, responds to the Tivoli Directory Server's bind with a success or an invalid credentials error.
  5. As per the result obtained from the pass-through server, the client is authenticated or a failure is reported.

The following attributes are used in pass-through authentication configuration:

  • ibm-slapdPtaSearchBase: This required attribute defines the distinguished name of the sub-tree base in the pass-through server against which the entry will be searched.
  • ibm-slapdPtaAttrMapping: This required attribute stores the attribute mapping for pass-through authentication. For example, if 'attr1' in Tivoli Directory Server maps to 'attr2' in the pass-through server, then this attributes value will be 'attr1$attr2'. During server startup, Tivoli Directory Server will check that 'attr1' is a valid attribute in its schema. If the pass-through server is running, it will also attempt to check that 'attr2' is a valid attribute in the pass-through server's schema. A warning will be issued if the attempt to verify 'attr2' in the pass-through server fails. It is expected that 'attr1' in Tivoli Directory Server is single-valued. As part of pass-through authentication, the entry in the pass-through server identified by the filter ('attr2' = value of 'attr1' in Tivoli Directory Server) within the sub-tree identified by ibm-slapdPtaSearchBase is looked up. It is expected that this lookup yields a single entry in the pass-through server. If multiple entries are returned, it is termed as a bind failure. If a single corresponding entry is found in the pass-through server, a bind is performed against it.
  • ibm-slapdPtaBindDN: This required attribute indicates the distinguished name to be used for binding against the pass-through server when performing lookup in the event of an attribute mapping being defined.
  • ibm-slapdPtaBindPW: This required attribute indicates the bind password to be used for binding against the pass-through server when performing lookup in the event of an attribute mapping being defined.
  • ibm-slapdPtaSubtree: This must-contain, multi-valued attribute points to the sub-tree in the local directory for which Tivoli Directory Server will perform pass-through authentication. Special sub-trees like cn=configuration, cn=schema, cn=pwdpolicy,cn=ibmpolicies and cn=changelog are not allowed as values for this attribute. Nested sub-trees are not allowed to be values for this attribute (i.e., c=US and o=ibm,c=US both cannot be specified as values for this attribute). If specified, the server will fail to start in the normal mode.
  • ibm-slapdPtaResultTimeout: This is an optional attribute, which if specified defines the time in milliseconds that Tivoli Directory Server will wait for getting the result of a bind operation against the pass-through server. If result is not received in the defined time period, Tivoli Directory Server returns LDAP_INVALID_CREDENTIALS to the client. Its default value is 1000 ms. A value of 0 indicates that the bind operation will not wait and will return immediately after checking the result. Only values in the range of 0 to 60000 ms (1 minute) are supported.
  • ibm-slapdPtaMigratePwd: This optional attribute indicates that a successful bind request to the pass-through directory should be followed by a migration of the bind credentials to the local directory (Tivoli Directory Server). In the absence of this attribute in the configuration, the default behavior is to not perform credential migration. Once the credential migration is performed, subsequent bind operations for that entry would be executed against the local directory and not against the pass-through directory.
  • ibm-slapdPtaConnectionPoolSize: This optional attribute indicates the number of connections to be opened against the pass-through server to handle frequent bind requests. This attribute is intended to achieve performance improvements in pass-through authentication; however, when the pass-through directory server destroys inactive connections, creating a connection pool through this option may not be efficient. This attribute supports values ranging from 2 to 15. Any other value specified for this attribute results in the server to start in configuration mode. In the absence of this attribute, a connection pool of size 4 is created.
  • ibm-ptaReferral: This auxiliary objectclass is associated with a Tivoli Directory Server entry to define entry-specific mapping in the pass-through server. It includes the ibm-ptaLinkAttribute and the ibm-ptaLinkValue attribute.
  • ibm-ptaLinkAttribute: If the value of this attribute is _DN_, then the value of corresponding ibm-ptaLinkValue will be distinguished name of the entry in the pass-through server, thereby eliminating the need for a lookup. If the value of this attribute is _DISABLE_, then pass-through authentication is disabled for this entry. In all other cases, this attribute will store the name of the attribute to be used for lookup in the pass-through server. This is needed because the attribute mapping as defined in the ibm-slapdPtaAttrMapping attribute applies to all entries. If an entry needs some special attribute mapping, that can be achieved through this attribute.
  • ibm-ptaLinkValue: This required attribute holds the value corresponding to ibm-slapdPtaLinkAttribute.

Configuration steps on Tivoli Directory Server and secldap

In this section we are listing the steps which need to be followed for configuring pass-through authentication on the Tivoli Directory Server and the modification that is to be made in the secldapclntd daemon configuration. Here we will be splitting the configuration in two parts. The first part covers the steps for configuring a completely new setup from scratch. However, in the second section we are assuming that a secldap/Tivoli Directory Server setup was already existing, and it needs to be extended such that pass-through authentication can be used with the existing setup to authenticate users from any other data source.

Configuration steps for a new setup

The example setup we are demonstrating in this article is Attribute Mapping, where Attribute Mapping is configured and the entry is present locally. In this scenario, the entry is present locally in Tivoli Directory Server, and it is possible to determine an attribute in Tivoli Directory Server that has a one-to-one mapping to an attribute in the pass-through server. The attribute in Tivoli Directory Server and the pass-through server that are to be mapped need not have the same name. When a bind is requested against Tivoli Directory Server and attribute mapping is defined, then a lookup is performed on the pass-through server for an entry which has the same value for the mapped attribute in the pass-through server as the value of the mapped attribute in Tivoli Directory Server. If such an entry is found, then a bind is performed against it with the credentials passed in by the Tivoli Directory Server client application.

In this case, the administrator is responsible for identifying an attribute that uniquely identifies the entry in Tivoli Directory Server and in the pass-through server. If it is not possible to find a common attribute across entries that uniquely identifies each entry, then the attribute mapping can be defined explicitly per entry using the link attributes in the ibm-slapdPtaReferral objectclass.

Figure 2. Target configuration.
Illustration showing a target configuration and pass-through server
Listing 1. Add user aixauth
# idsadduser -g idsldap -l /home/aixauth -u aixauth -w aixauth
Listing 2. Create Tivoli Directory Server instance
# idsicrt -I aixauth -e abcd1234567890 -l /home/aixauth -n
Listing 3. Configuring database with the Tivoli Directory Server instance
# idscfgdb -I aixauth -l /home/aixauth -a aixauth -w aixauth -t aixauth -n
Listing 4. Configuring admin DN and passwords
# idsdnpw -I aixauth -u cn=root -p root -n
Listing 5. Configuring cn=aixdata suffix
# idscfgsuf -I aixauth -s cn=aixdata -n
Listing 6.Start Tivoli Directory Server instance to change the default password encryption
# ibmslapd -I aixauth -n
Listing 7. Enable pass-through authentication on Tivoli Directory Server
Create an ldif file:

====enablepta.ldif Begins====
dn : cn=configuration
changetype : modify
replace : ibm-slapdPtaEnabled
ibm-slapdPtaEnabled : TRUE
===enablepta.ldif Ends====

Command to enable pass-through authentication:

# idsldapmodify -D cn=root -w root -i <path for enablepta.ldif>
Listing 8. Add pass-through configuration
Create an ldif file:

====ptaconfig.ldif Begins====
dn: cn=PassthroughServer1, cn=Passthrough Authentication, cn=Configuration
cn: PassthroughServer1
ibm-slapdPtaURL: ldap://9.182.194.84:389
ibm-slapdPtaSubtree: cn=aixdata
ibm-slapdPtaAttrMapping: uid $ sAMAccountName
ibm-slapdPtaSearchBase: CN=Users,DC=tamesso,DC=com
ibm-slapdPtaBindDN: CN=Administrator,CN=Users,DC=tamesso,DC=com
ibm-slapdPtabindPW: tivoli@123
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdPta
objectclass: ibm-slapdPtaExt

===ptaconfig.ldif Ends====

Command to enable pass-through authentication:

# idsldapmodify -D cn=root -w root -i <path for ptaconfig.ldif>

***Note : 
1. With the configuration entry given in this listing, we are setting up Pass-through
   Authentication for the subtree cn=aixdata. Any bind request arriving at the Tivoli
   Directory Server server for the user under this subtree will be a candidate for PTA. 
	   
2. Pass-through Authentication will be performed at the server located at the 
   location ldap://9.182.194.84:389. 
	   
3. On the destination server, a search will be performed under the subtree
   CN=Users,DC=tamesso,DC=com.

4. While binding to the PTA server, Tivoli Directory Server will use the 
   DN as N=Administrator,CN=Users,DC=tamesso,DC=com and the password as tivoli@123.
	   
5. With the attribute mapping defined as uid $ sAMAccountName, any value associated 
   with uid in the Tivoli Directory Server will be looked for in the sAMAccountName
   attribute in the destination PTA server.
Listing 9.Stop Tivoli Directory Server instance
# ibmslapd -I aixauth -k

At this point, we need to modify the user ldif file such that the userpassword attribute is deleted for the user who will be authenticated through the pass-through server. As we are using the Attribute Mapping pass-through authentication, make sure that the value of uid attribute for any entry in the Tivoli Directory Server should uniquely match a particular attributes value on the pass-through server (As per the pass-through authentication configuration defined by ibm-slapdPtaAttrMapping).

Listing 10. Example user entry
dn: uid=user1,ou=People,cn=aixdata
uid: user1
objectClass: aixauxaccount
objectClass: shadowaccount
objectClass: posixaccount
objectClass: account
objectClass: ibm-securityidentities
objectClass: top
cn: user1
passwordchar: !
uidnumber: 205
gidnumber: 14
homedirectory: /home/ldapdb2
loginshell: /usr/bin/ksh
isadministrator: false
shadowlastchange: 14203
passwordflags: NOCHECK
ixtimelastlogin: 1227177141
hostlastlogin: braziltivl2
unsuccessfullogincount: 0

**Note: 
1. attributes might be different, and their values can be different too.
2. Userpassword attribute has been removed.
3. As per the configuration in listing8 ( ibm-slapdPtaAttrMapping: uid $ sAMAccountName)
   uid has been set to user1. This will uniquely map this entry to the entry on the
   Pass-through Server.
Listing 11. Import ldif file to the Tivoli Directory Server
# idsldif2db -I aixauth -i <path of user.ldif file>
Listing 12. Configure secldap client
# mksecldap -c -h secldaptds.ibm.com -a cn=root -p root
Listing 13. Stop secldapclntd daemon
# stop-secldapclntd
Listing 14. Take a back of existing ldap.cfg file
# cp /etc/security/ldap/ldap.cfg <a safe location>
Listing 15. Edit ldap.cfg file
Edit the value for ldap_auth parameter and set it to ldap_auth.
By default it is set unix_auth

auth_type:ldap_auth
Listing 16. Start secldapclntd daemon
# start-secldapclntd

Configuration steps for an existing setup

The earlier section demonstrated the steps to configure a completely new setup from scratch. In this section we are providing the steps which need to be followed to modify an existing setup. Readers of this article will certainly look for steps which can help them modify their existing setup so as to reap the benefits of the pass=through authentication feature in Tivoli Directory Server. Steps to modify an existing setup will always be looked for when a organization is acquired by an another organization and it is not possible to migrate all the users in the newly acquired organization's LDAP into the existing LDAP server. As an example to start with an exiting setup, we have shown a very simple setup which exists in most implementations.

Figure 3. Existing configuration.
Illustration showing an existing configuration using Tivoli Directory Server

The following steps convert the previous setup into the one as shown in Figure 2.

Listing 16b. Stop secldapclntd daemon
# stop-secldapclntd
Listing 17. Take a back of existing ldap.cfg file
# cp /etc/security/ldap/ldap.cfg <safer location>
Listing 18. Edit ldap.cfg file
Edit the value for ldap_auth parameter and set it to ldap_auth.
By default it is set unix_auth

auth_type:ldap_auth
Listing 19. Start secldapclntd daemon
# start-secldapclntd
Listing 20. Enable pass-through authentication on Tivoli Directory Server
Create an ldif file:

====enablepta.ldif Begins====
dn : cn=configuration
changetype : modify
replace : ibm-slapdPtaEnabled
ibm-slapdPtaEnabled : TRUE
===enablepta.ldif Ends====

Command to enable pass-through authentication:

# idsldapmodify -D cn=root -w root -i <path for enablepta.ldif>
Listing 21. Add pass-through configuration
Create an ldif file:

====ptaconfig.ldif Begins====
dn: cn=PassthroughServer1, cn=Passthrough Authentication, cn=Configuration
cn: PassthroughServer1
ibm-slapdPtaURL: ldap://9.182.194.84:389
ibm-slapdPtaSubtree: cn=aixdata
ibm-slapdPtaAttrMapping: uid $ sAMAccountName
ibm-slapdPtaSearchBase: CN=Users,DC=tamesso,DC=com
ibm-slapdPtaBindDN: CN=Administrator,CN=Users,DC=tamesso,DC=com
ibm-slapdPtabindPW: tivoli@123
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdPta
objectclass: ibm-slapdPtaExt

===ptaconfig.ldif Ends====

Command to enable pass-through authentication:

# idsldapmodify -D cn=root -w root -i <path for ptaconfig.ldif>

We just need a sample user entry in the Primary Tivoli Directory Server for the users for which the pass-through authentication has to be performed. If pass-through authentication has to be performed for an entry, remove the userpassword attribute and leave the other attribute as they are. Typically, when a new organization is acquired, it is not possible to import all the user data from the existing LDAP server of the acquired organization. In such a case, you would need to create a simple entry on the acquiring organizations LDAP server with minimum required attributes and let pass-through authentication handle the authentication for such user. Given such a scenario, Whenever an authentication request from acquired organization's employee hits the acquiring organization's LDAP server, corresponding entry will be located and since the userpassword attribute will not be found available, pass-through authentication module will take over and authenticate the user using the pass-through server.

Listing 23. Restart Tivoli Directory Server instance
# ibmslapd -I aixauth -k
# ibmslapd -I aixauth -n

Example with a complex scenario

Secldapclntd daemon is many a time configured to use a highly available Tivoli Directory Server setup. Tivoli Directory Server can be made highly available using the Master-Master replication configuration. In such a setup, one of the replicating Tivoli Directory Server is used as a primary server while the other is used as a secondary server. All the read/write requests are primarily sent to the primary server. Any update made on this primary server is immediately replicated to the secondary server so as to maintain a copy of the active data. In the situation, when the primary server cannot be contacted or if it goes down due to some problem, secldapclntd daemon automatically switches to the secondary server. Hence achieving a high availability and avoiding any downtimes.

Figure 4. Existing configuration
Illustration of complex existing configuration using Tivoli Directory Server and a pass-through Domino Directory

As per the figure, AIX clients contact either of the two Tivoli Directory Server configured at the backend based on priority or availability basis. We can include the pass-through authentication settings on both these backend servers so that the pass-through Domino Directory (as per this example) is referenced when the userpassword is not found in the Tivoli Directory Server. All other configuration on secldap side remain the same.


Restrictions when using Tivoli Directory Server pass-through authentication

  • Pass-through authentication covers many other scenarios. However, we have used only one scenario in which the entry is present locally and the userpassword is not available in the Tivoli Directory Server. We used this scenario as this is the one which applies best in this scene. Other scenario of pass-through authentication define the situation where the entry is not present locally. However, this scenario cannot be used as for secldap to use the Authentication from Tivoli Directory Server, entry must be present on the Tivoli Directory Server, though the userpassword may be missing.
  • For the users who will be authenticated using the pass-through server, it would not be possible to use the passwd command to change the user's password. This is not allowed because the pass-through authentication feature does not update any value on the pass-through server. Running the passwd command will result in addition of userpassword on the primary Tivoli Directory Server and might eventually cause the LDAP servers to go out of sync. Tivoli Identity Manager can optionally be used to synchronize passwords and work around this limitation.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX, Java technology
ArticleID=492361
ArticleTitle=Extending the capability of secldap to authenticate from multiple data sources
publish-date=06012010