The following process lists the steps for creating the user store connection to the Policy Server:
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 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, SiteMinder treats characters as they are defined in Unicode. Although your code page can reference a special character as single-byte, 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\Netegrity\SiteMinder\CurrentVersion\Ds\LDAPProvider
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 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, 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, 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/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\Netegrity\SiteMinder\CurrentVersion\Ds\ LDAPProvider\EnableADEnhancedReferrals
Values: 0 (disabled) or 1 (enabled)
Default Value: 1
This step prevents LDAP connection errors from occurring.
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:
The disadvantages include:
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.
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 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.
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.
A SiteMinder Web Agent can run in a Windows user security context for accessing Web resources on IIS Web servers. Before 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 SiteMinder Is Configured to Provide a Windows User Security Context). You must also enable this feature in the Credentials and Connection tab in the User Directory dialog.
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:
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.
The disadvantages include:
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.
|
Copyright © 2012 CA.
All rights reserved.
|
|