Policy Server Guides › Policy Server Configuration Guide › User Directories › How to Configure an Active Directory Directory Connection

How to Configure an Active Directory Directory Connection

The following process lists the steps for creating the user store connection to the Policy Server:

1. Verify that an Active Directory User Directory Meets Policy Server Requirements
2. Specify an Active Directory or LDAP Namespace
3. Ping the User Store System
4. Configure a Connection from the Policy Server to an Active Directory User Store

Active Directory Considerations

Before you configure a connection to an Active Directory, consider the following points:

Enhanced Active Directory integration

Active Directory 2008 has several user and domain attributes that are specific to the Windows network operating system (NOS) and that the LDAP standard does not require. If you configure the Policy Server to use Active Directory as a user store, enable Enhanced Active Directory Integration from the Policy Server Global Tools task available from the Administrative UI. This option improves the integration between the user management feature of the Policy Server and Password Services with Active Directory by synchronizing Active Directory user attributes with CA SiteMinder® mapped user attributes.

Note: For more information, see the section Enable Enhanced Active Directory Integration in the Policy Server Administration Guide.

Multibyte Character Support

The AD namespace does not support multibyte character sets. To use a multibyte character set with Active Directory, configure your directory connection using the LDAP namespace.

Note: Regardless of the code page you are using, CA SiteMinder® treats characters as they are defined in Unicode. Although your code page can reference a special character as single-byte, CA SiteMinder® treats it as a multibyte character if Unicode defines it as such.

Active Directory namespace does not support paging

A search fails when the search results in more than 1000 users.

Authentication against a User Directory of an AD namespace

The Policy Server can authenticate a user against an Active Directory using SASL. To enable the use sasl bind, set the SASLBind registry key with a value of 1.

Note: When enabling this setting, set the administrator name on the user directory configuration to the AD login name, rather than the fully qualified distinguished name.

Create the registry key EnableSASLBind of type DWORD at the following location:

HKLM\SOFTWARE\Wow6432Node\\Netegrity\SiteMinder\CurrentVersion\Ds\LDAPProvider

EnableSASLBind

Disables or enables the SASL protocol while authenticating users. If you set EnableSASLBind to 1, the authentication occurs with SASL. If you set EnableSASLBind to 0, the authentication occurs with Simple Authentication mechanism.

Value: 0 (disabled) or 1 (enabled)

Note: The SASL authentication is specific to Windows-based Policy Servers.

Important! To configure an Active Directory User Directory using a secure (SSL) connection, set the Policy Server registry key EnableSASLBind to 0.

Administrator Credentials

When configuring a user directory in the Active Directory (AD) namespace, specify the fully qualified distinguished name of the administrator in the Username field in the Administrator Credentials section. If you do not satisfy this requirement, user authentication can fail.

LDAP Search Root Configuration

The Policy Server must identify the AD domain of an AD namespace to read account lock status. To configure the Policy Server to identify the AD domain, define the LDAP search root of the user directory as the DN of the domain. If you set the LDAP search root to any other DN, the Policy Server is not able to identify the AD domain. If the Policy Server cannot identify the AD domain, it cannot read the domain Windows lockout policy. This situation can lead users that are locked through the AD console to appear enabled when viewed in the Administrative UI User Management dialog.

For example, create five users through the AD console at the following DN and lock two of these users:

ou=People,dc=clearcase,dc=com 

The CA SiteMinder® User Management dialog shows locked users as disabled only if the LDAP search root is configured as the DN of the AD domain, as follows:

dc=clearcase,dc=com

If you configure the LDAP search root as follows, the locked users are incorrectly shown as enabled:

ou=People,dc=clearcase,dc=com

Disable Password Services Redirect for Natively Disabled Unauthorized Users

By default, CA SiteMinder® reprompts users for credentials when they are unauthorized due to being natively disabled in the directory server. This behavior does not occur for users stored in Active Directory. Rather, CA SiteMinder® redirects natively disabled users to Password Services, even if Password Services is not enabled for the authentication scheme protecting the resource. Create and enable IgnoreDefaultRedirectOnADnativeDisabled to prevent this Active Directory behavior.

IgnoreDefaultRedirectOnADnativeDisabled

Location: HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Netegrity/Siteminder/CurrentVersion/Ds/LDAPProvider

Values: 0 (disabled) or 1 (enabled).

Default: 0. If the registry key is disabled, the default behavior is in effect.

LDAP Namespace for an Active Directory User Directory Connection

When accessing an Active Directory user directory using an LDAP namespace, disable the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Netegrity\SiteMinder\CurrentVersion\Ds\
LDAPProvider\EnableADEnhancedReferrals

Values: 0 (disabled) or 1 (enabled)

Default Value: 1

This step prevents LDAP connection errors from occurring.

LDAP Namespace for an Active Directory Connection

CA SiteMinder® supports user directories on the Microsoft Active Directory platform. Although the configuration for Active Directory (AD) and LDAP namespaces in the Administrative UI is very similar, there are several functional differences.

The advantages of using the LDAP namespace for an Active Directory user store include:

• Support for enhanced LDAP referrals.
• Support for LDAP paging and sorting.

The disadvantages include:

• No support for Windows SASL

  The LDAP namespace does not support native Windows SASL, which allows native secure LDAP bind operations to support native Windows authentication methods such as Kerberos and NTLM.

• Indexing the Objectclass Attribute

  Microsoft Active Directory uses a non-standard method for identifying object classes. Because of this, the objectclass attribute in Active Directory is not indexed by default. This can cause the Administrative UI to timeout when it searches through an Active Directory LDAP implementation that includes large numbers of users or groups.

  For CA SiteMinder® to run efficiently with an Active Directory user directory, you must index the objectClass attribute in Active Directory. For more information, see your Active Directory documentation.

• Active Directory and Password Services

  Microsoft Active Directory requires an SSL connection to change stored user passwords. For Password Services to work with Active Directory user directories, you must configure an SSL connection to any Active Directory LDAP user directory to which password policies will be applied.

  Additionally you must define a specific Password Attribute: unicodePWD to enable Password Services to work with Active Directory user directories.

  Note: For complete information about configuring Microsoft Active Directory, see your Active Directory documentation.

• Using a Windows User Security Context

  A CA SiteMinder® Web Agent can run in a Windows user security context for accessing Web resources on IIS Web servers. Before CA SiteMinder® can provide the Windows user security context, you must configure a session store and enable persistent sessions on a per realm basis (see How CA SiteMinder® Is Configured to Provide a Windows User Security Context). You enable this feature in the in the User Directory dialog.

More information:

LDAP Referrals

AD Namespace for an Active Directory Connection

CA SiteMinder® supports user directories on the Microsoft Active Directory platform. Although the configuration for Active Directory (AD) and LDAP namespaces in the Administrative UI is very similar, there are several functional differences.

The advantages of using the AD namespace when configuring an Active Directory user store include:

• SSL connectivity using a native Windows certificate database.

  Note: Both the Policy Server and the systems hosting Active Directory user stores must have an established trust. For information about configuring Windows systems and Active Directory for SSL, see your Windows documentation.

• Support for native Windows SASL which allows for secure LDAP bind operations.

The disadvantages include:

• No support for enhanced LDAP referrals.
• No support for LDAP paging and sorting operations.

Ping the User Store System

Pinging the user store system verifies that a network connection exists between the Policy Server and the user directory or database.

Note: Some user store systems may require the Policy Server to present credentials.

Configure Active Directory Connections

You can configure a user directory connection that lets the Policy Server communicate with an Active Directory user store.

To configure the user directory connection

1. Click Infrastructure, Directory.

   Objects related to user directories appear on the left.

2. Click User Directories.

   The User Directories screen appears.

3. Click Create User Directory.

   The Create User Directory screen appears and displays the required settings to configure an LDAP connection.

4. Microsoft Active Directory is an LDAP-compliant user directory. You can configure the connection using the AD namespace or the LDAP namespace. Do one of the following:
   1. Leave the default LDAP settings.
   2. Select AD from the Namespace list in the Directory Setup area.
5. Complete the remaining required connection information in the General and Directory Setup areas.

   Note: Consider the following:

   • For more information about an authenticated user security context, see How a Windows User Security Context is Obtained.
   • If you are using an SSL connection from the Policy Server to an Active Directory namespace, specify the FQDN and port number in the Server field in the Directory Setup area. When the FQDN is not specified, an error is logged that states the user directory cannot be contacted. A Windows Event is also logged that reports the certificate does not match the server name.

   Note: If the Policy Server is operating in FIPS mode and the directory connection is to use a secure SSL connection when communicating with the Policy Server, the certificates used by the Policy Server and the directory store must be FIPS compliant.

6. (Optional) Click Configure in the Directory Setup area to configure load balancing and failover.

   Note: More information about load balancing and failover, see LDAP Load Balancing and Failover.

7. Do the following in the Administrator Credentials area:
   1. Select the Require Credentials option.
   2. Enter the credentials of an administrator account.

   Note: When configuring a user directory in the Active Directory (AD) namespace, specify the fully qualified domain name (FQDN) of the administrator in the Username field. Otherwise, user authentication can fail.

8. Configure the LDAP Search and LDAP User DN Lookup settings in the LDAP Settings area.
9. (Optional) Specify the user directory profile attributes that are reserved for CA SiteMinder® use in the User Attributes area.
10. (Optional) Click Create in the Attribute Mapping List area to configure user attribute mapping.
11. Click Submit.

    The user directory connection is created.

More information:

LDAP Load Balancing and Failover

Directory Attributes Overview

Define an Attribute Mapping