Appendix C Authenticate Against Active Directory

Sun Java™ System Identity Server provides the ability to authenticate against a variety of backend sources. Primarily, Directory Server and LDAP are used, but the LDAP Authentication module can be configured to use Microsoft® Active Directory® as its authentication source. This appendix contains the following sections:

Overview

Since Active Directory is an LDAPv3-compliant directory server, it is just a matter of configuring the Identity Server to recognize Active Directory as an authentication source. There are two options to consider when defining this configuration. The administrator can either point all LDAP authentication to the Active Directory or a new authentication module can be created and registered for this purpose.

Point to Existing LDAP Authentication Module

Using this method, all users attempting to authenticate with the LDAP Authentication module would be verified against the Active Directory. This is a change from the default LDAP authentication which is verified against Sun Java System Directory Server. This appendix focuses on this scenario.

Create New Active Directory Authentication Module


Note	The LDAP Authentication module can be used in the manner described in this chapter against any LDAP v3 compliant server.

The other option is to create and register an authentication module which specifically performs LDAP authentication against the Active Directory. Identity Server does not allow multiple instances of the same authentication module to be used with different server configurations so a new class would be needed for this approach. This option is used if the Active Directory suffix and Directory Server suffix are not the same. It is not covered in this appendix, but information on how to create a custom authentication module can be found in the Identity Server 2004Q2 Developer’s Guide.

Multiple LDAP Sub-Configurations

An administrator can define multiple LDAP authentication module configurations under one organization. Although these additional configurations are not visible from the console, they work in conjunction with the primary configuration if an initial search for the requesting user’s authorization is not found. For example, one organization can define a search through LDAP servers for authentication in two different domains or it can configure multiple user naming attributes in one domain. For the latter, which has only one text field in the console, if a user is not found using the primary search criteria, the LDAP module will then search using the second scope. More information on this option can be found in the Identity Server 2004Q2 Developer’s Guide.

Setting Up Active Directory Authentication

The following steps detail the procedure for the LDAP Authentication Module to verify credentials against Active Directory.

Install and configure Identity Server.

The following steps will be modifying the default configuration of the LDAP Authentication module. This is potentially hazardous, and can cause a lockout. See Troubleshooting if access to Identity Server is denied.

Select Dynamically Created in the User Profile attribute of the Core Authentication Service for the organization.

Identity Server requires that an account exist within Directory Server for authorization despite authentication being delegated to an external source. The options for this are:

Use a meta directory to synchronize accounts.

Enable dynamic profile creation which allows Identity Server to look for an account for the user in question. If none exists, the account is automatically created with the same account name used in Active Directory.



Note	More information on this attribute and how to enable it can be found in Sun Java System Identity Server Administration Guide.

Change the Primary LDAP Server and Port attribute in the LDAP Authentication module to the host name and port number of the Active Directory in the form: hostname.domain.com:389.

Change the DN to Start User Search attribute to the proper base for the Active Directory.

Simply specifying the base suffix will not work in this attribute. Generally, it would be the cn=Users plus suffixes in: cn=Users,dc=domain,dc=com.

Change the DN for Root User bind attribute to a user with the right to read the Active Directory and update the password.

Anonymous access to the Active Directory is not allowed, so a bind account is needed. It is simply an account for Active Directory that has read ability on the attribute to which the user will authenticate. An example might be cn=administrator,cn=Users,dc=domain,dc=com. The password should be updated for this entry.

Change the User Naming Attribute.

This attribute is the one that the LDAP Authentication module will search for in Active Directory, and pass back to match the UID in Directory Server. For example, if a meta-directory synchronizes the two systems and entries in Directory Server were stored with mail as the RDN, userPrinicipalName might be specified here as it stores a mail address in Active Directory. In this case, it might be best to specify sAMAccountName, as it is the attribute in Active Directory most like UID.

Change the User Entry Search Attributes.

This attribute is used to locate the account in Active Directory. It should correspond to the attribute with which people use to log in. For example, if users login using their Common Name, the value of this attribute would be cn. In this case, it might be best to specify sAMAccountName, as it is the attribute in Active Directory most like UID.



Note	This attribute may contain multiple values, each of which will be tried.

Deselect the Return User DN to Auth attribute.

This attribute forces the LDAP Authentication module to return the DN it authenticated as to Identity Server, saving the need to search for it again for authorization. The DN though will not be the same in Active Directory as in the Directory Server so it needs to be turned off. This enables Identity Server to take the value returned from Active Directory as the attribute specified in the User Naming Attribute in Step 6, and search Directory Server using the attribute specified in Core Authentication (uid by default). So, in this example, LDAP Authentication will search Active Directory for sAMAccountName=UID_entered_by_user, and after authentication, search the Directory Server for uid=sAMAccountName from Active Directory.

Add the amAdmin account to Active Directory.

An account needs to be created with the sAMAccountName of amAdmin, so that amAdmin may continue to login to Identity Server. This user is created in Active Directory by:

Selecting Active Directory Users and Computers from Start -> Programs -> Administrative Tools.

Right click on the Users node in the left pane and select New -> User.

Fill in appropriate information and specify amAdmin as the account name.

Verify that amAdmin is able to log in to Identity Server.

Verify that a user defined in Active Directory is able to log in to Identity Server.

Troubleshooting

Modifying the LDAP Authentication information makes it possible for a lock out to occur. The following procedures detail how to overcome this.

Quick Access To Identity Server

The DN found in the com.iplanet.authentication.super.user property of AMConfig.properties allows amAdmin to login to Identity Server via the LDAP Authentication module. amAdmin is the Identity Server manager for Directory Server. The value of this property is the full DN of the amAdmin account, uid=amAdmin,ou=People,root-suffix. The full DN is entered in the User Name field. In this case, the instance of Directory Server configured in AMConfig.properties is used and the LDAP Authentication module parameters are not.

Reconfigure Using Directory Server

Authentication configuration information is stored in Directory Server and, thus, the entry is easily modified. ou=default,ou=OrganizationConfig,ou=1.0,ou=iPlanetAMAuthLDAPService,ou=service,root-suffix is the object that defines the Authentication Configuration Service. Modify the iplanetKeyValue attribute to correct any errors made. The relevant values are:

Previous Contents Index Next
Sun Java System Identity Server 2004Q2 Deployment Planning Guide


Note	The value of this property is encrypted using the ampassword utility.