User directories and user databases store user data, including organizational information, user and group attributes, and credentials such as passwords. The Administrative UI lets you configure connections to existing user directories and databases.
You configure directory connections to resolve how the Policy Server establishes a context for user identities. The Policy Server uses these connections to verify user identities and retrieve user attributes contained in the user stores.
You configure the Policy Server to connect to any number of supported user directories, including:
The Policy Server can communicate with user directories that use the Lightweight Data Access Protocol (LDAP).
LDAP user directories are created with an inverted tree structure. Due to this hierarchical structure, LDAP-enabled directories can contain multiple user namespaces. A namespace is a grouping of entities under a node in the LDAP Directory Information Tree (DIT). Any branch of an LDAP DIT can be defined in a user directory connection as a separate namespace. Typically, user directory connections are configured for DIT branches that represent an organization (o) or an organizational unit (ou).Users and user groups are located under an o= or ou= node in the directory structure.
Any node in an LDAP tree is identified by its distinguished name (DN), which is made up of a comma separated list of its own name and the names of the nodes above it in the directory tree. This method of naming allows each point in the user directory to have a unique DN.
For example, in the diagram above, one of the users in the Marketing department is identified by the following DN:
uid=user1,ou=marketing,o=security.com
The user group Engineering is identified as the following DN:
ou=engineering,o=security.com.
User disambiguation is the process of locating a unique user in a user directory. There are two methods of locating users in a user directory. You can locate users by
The Policy Server uses information you supply in the User Lookup group box of the User Directory pane, and a user-supplied value, such as login name, to locate a user.
User Lookup by DN
You construct a user lookup by DN from the User Directory pane in the User Lookup group box of the LDAP Settings area. You concatenate the value specified in the User Lookup Start field, the username as specified by the user during login, and the value specified in the User Lookup End field.
The resulting DN has the following format:
<value in the User Lookup Start field>, <username>, <value in the User Lookup End field>
The following illustrates an LDAP Directory Information Tree (DIT) example:
In the previous diagram, the LDAP DIT design requires a DN to be of the form uid=JSmith,ou=marketing,o=myorg.org.
Only the unique part, JSmith, must be specified in the credentials when the user logs in.
User Lookup via a Search Expression
An LDAP directory server may contain numerous users in complicated DITs, and it may not be practical to create a large number of user directory connections. Your organization may have hundreds of organizational units and you may want to avoid having end users log in with detailed string representations. Instead, one user directory connection pointing to a common root can be created with the User DN Lookup Start and User DN Lookup End properties defining an LDAP search expression. The result of the search expression is a list of user DNs for the Policy Server to try during authentication.
Example: Search expressions for user DN lookups
To locate a user across many organizational units, define the User Lookup Start property as (&(objectclass=inetOrgPerson)(uid= and define the User Lookup End property as )). Only the unique part, the uid value, must be specified in the credentials. In the section of the User Directory Dialog shown above, these values replace the values contained in the LDAP User DN Lookup group box.
Note: An InetOrgPerson is a common object class used in LDAP directory deployments.
See the following figure for the type of LDAP DIT where invoking a search expression is useful:
In this case, if JSmith from ou=sales wants to access a resource, JSmith can authenticate using only his or her name for credentials (as opposed to an entire DN string). By placing the uid= attribute between the User DN Lookup Start and User DN Lookup End fields with the search expressions in the corresponding fields, the Policy Server will find all DNs that match the LDAP query (&(objectclass=inetOrgPerson)(uid=JSmith)).
The Policy Server then has a list of DNs to choose from in giving access to the protected resource. Assuming the resource can only be accessed by the JSmith of ou=sales, the username/password for the DN uid=JSmith,ou=sales,o=myorg.org will be the one that is authenticated.
As you work with LDAP directory connections in the Policy Server, you may need to specify filters for LDAP search expressions. The following table provides a brief description of some common LDAP search filters.
|
Search Filter |
Format |
Description |
|---|---|---|
|
Equality |
attribute=value For example, to find a user whose user ID is jsmith, the search filter is uid=jsmith. |
This filter finds a specific value for an attribute in an LDAP directory. |
|
String
|
attribute=*value, OR For example, uid=*smith matches all values that end in smith, such as jsmith, msmith, etc. A value of uid=*smith* matches jsmith, msmith, and bsmithe. |
LDAP search filters support wild cards, which allow you to search for an attribute value based on a partial string. To find all of the values that match a partial string, use the wildcard character (*).
|
|
Greater than or equal to |
attribute>=value For example, to find all of the users in a directory who are age 21 or over, part of the search filter would be age>=21. |
This filter finds values that are greater than or equal to the specified value. |
|
Less than or equal to
|
attribute<=value For example, to find all of the users in a directory who are age 21 or younger, part of the search filter would be age<=21. |
This filter finds values that are less than or equal to the specified value.
|
|
Greater than |
(!(attribute<=value)) For example, to find all of the users in a directory who are older than 21, part of the search filter would be (!(age<=21)). |
LDAP does not support greater than expressions. In order to filter LDAP attribute values by greater than, you must use the Negation operator (!) in conjunction with a greater than or equal to expression. |
|
Less than |
(!(attribute>=value)) For example, to find all of the users in a directory whose age is less than 21, part of the search filter would be (!(age>=21)). |
LDAP does not support less than expressions. In order to filter LDAP attribute values by less than, you must use the Negation operator (!) in conjunction with less than or equal to expression. |
|
Approximate |
attribute~=value For example, the filter uid~=smith may return the values smithe and smitt. |
This filter returns values that are similar to the value specified in the filter. |
|
Presence |
attribute=* For example, email=* returns all users who have an email address. |
This filter determines if an attribute is present. |
|
Complex And (&) Or (|) Not (!) |
Intersection of Filter1 and Filter2: Union of Filter1 and Filter2: Satisfies Filter1, but not Filter2: Note You must use parentheses to enclose the complex filter and each filter in the complex filter. For example, if you want to find all users whose User ID begins with the letter s and who are over 21 years old, you could use a filter of (&(uid=s*)(!(age<=21))).
|
Creates complex search filters. |
Objectclass Searches
Each entry in an LDAP table has at least one objectclass attribute. You can use a presence filter in conjunction with the objectclass attribute to build filters for searching your LDAP user directories. In CA SiteMinder® environments, the objectclass attribute is most useful in the following cases:
To retrieve all entries one level below a directory entry, specify a search scope of One Level, and use a search filter of (objectclass=*). Since all LDAP directory entries have at least one objectclass attribute, the search filter returns a complete list of the entries below the root.
To retrieve all entries in the branches below a directory entry, specify a search scope of Subtree, and use a search filter of (objectclass=*). The search filter returns a complete list of the entries in the entire subtree.
Filtered Characters in User IDs
CA SiteMinder® provides LDAP search filter checking functionality that parses LDAP search filters to ensure that they comply with the LDAP standard (RFC).
All user login IDs are filtered for "(", ")", "\" characters by default before being checked against an LDAP user store. To disable this check, set the following EnableSearchFilterCheck registry value to 0:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Netegrity\Siteminder\Ds\LDAPProvider\EnableSearchFilterCheck
Important! By disabling this check, you may expose your system to attack, and should not allow user IDs using these characters.
The Policy Server supports LDAP referrals for LDAP user directory connections. An LDAP referral in one directory points to a location in another LDAP directory. There are two types of LDAP referrals: write referrals and read referrals. In addition, the Policy Server supports enhanced referral processing.
Note: In order for LDAP referrals to work correctly in a multiple policy store environment, the CA SiteMinder® LDAP policy store schema must be applied to all replicas. For more information see the section describing LDAP policy store installation in the Policy Server Installation Guide.
Write Referrals
In a directory deployment that includes master and slave LDAP directories, LDAP write referrals allow updates to a master directory that can then be replicated to slave directories. In a CA SiteMinder® deployment, you can specify a connection to a slave LDAP directory. If you use any of CA SiteMinder®’s features that require data to be written to the LDAP directory, CA SiteMinder® automatically detects referrals that point to a master LDAP directory. The information that CA SiteMinder® writes to the LDAP directory will be stored in the master LDAP directory and replicated to the slave LDAP directory according to the replication scheme of your network resources.
Read Referrals
In a large LDAP directory deployment, information may be divided among several LDAP directories. For example, one directory may contain enough user information to authenticate a user, while another directory may contain other important user attributes. The authentication directory can be configured to point to the directory containing user attributes. This process is called a read referral. If a directory connection exists for an LDAP directory that contains read referrals, CA SiteMinder® is able to use the read referrals to retrieve information from the associated directories.
An LDAP directory’s topology describes the division of a directory tree among physical servers. The logical sections of a directory tree are called partitions. LDAP directory topology varies widely between LDAP deployments, but regardless of the topology, the use of referrals between partitions allows the directory to function as a single service.
Three types of LDAP referrals can be employed in a directory topology. These types can be used in conjunction to create very complex directory structures. The types are:
When a directory topology includes a replication agreement, all changes in a supplier directory are replicated (duplicated) in a second consumer directory. The consumer and supplier directories may be used to load balance requests, or may have a failover relationship. When an update request is received by the consumer directory, the consumer directory refers the request to the supplier directory where the update is completes. This is a very common type of LDAP referral.
Pointers from one directory partition to another are called knowledge references. Knowledge references that point to the node immediately upward toward the root in the DIT are considered immediate superior knowledge references. Knowledge references that point downward in the DIT to other partitions are considered subordinate references.
A pointer to a location in a portion of the directory that is not immediately above or below the original partition s called a smart referral. A smart referral contains enough information to see a node anywhere in the directory topology.
Enhancements have been made to the Policy Server’s LDAP referral handling to improve performance and redundancy. Previous versions of the Policy Server supported automatic LDAP referral handling through the LDAP SDK layer. When an LDAP referral occurred, the LDAP SDK layer handled the execution of the request on the referred server without any interaction with the Policy Server.
CA SiteMinder® includes support for non-automatic (enhanced) LDAP referral handling. With non-automatic referral handling, an LDAP referral is returned to the Policy Server rather than the LDAP SDK layer. The referral contains all of the information necessary to process the referral. The Policy Server can detect whether the LDAP directory specified in the referral is operational, and can terminate a request if the appropriate LDAP directory is not functioning. This feature addresses performance issues that arise when an LDAP referral to an offline system causes a constant increase in request latency. Such an increase can cause CA SiteMinder® to become saturated with requests.
For example, a CA SiteMinder® deployment includes two LDAP directories that are deployed in a supplier/consumer replication scheme with failover. All requests are made to the consumer directory. If the consumer directory is unavailable, the Policy Server uses the failover configuration to query the supplier directory.
If Password Services is enabled, an LDAP referral in the consumer directory takes place to ensure that password changes are written in the supplier directory. In previous versions of the Policy Server which only supported automatic LDAP referrals, if the supplier directory was unavailable, the Policy Server was unaware that the referral from the consumer directory required to write new password information into the supplier directory was not functioning, and would wait for a response from the supplier. This delay could cause the system to become saturated by pending requests.
If you configure your Policy Server with enhanced LDAP referral handling, the Policy Server is aware of the unavailable supplier LDAP directory and terminates requests that require password changes automatically, until the supplier directory is available to record password changes.
For information about configuring enhanced LDAP referral handling, see the Policy Server Management guide.
The Policy Server opens three connections when connecting to an LDAP user store:
CA SiteMinder® can use a proprietary schema in an ODBC-compatible database as a user directory for authentication and authorization purposes. This option is useful at sites where user information, such as a user name, password, and group membership is stored in an ODBC database. At such sites, this feature allows the Policy Server to view a proprietary database schema as a user directory.
The Policy Server supports connections to the following types of ODBC-compatible databases:
Note: If your user directory data is stored in an Oracle database, we recommend that you use OCI, instead of ODBC, to connect to that user directory.
For the most current information about supported database versions, check the CA Support Site.
To configure the Policy Server to use a database as a user directory you must:
Note: Don’t use the same data source with different query schemes. Create a unique data source for each query scheme.
Note: Configure the ODBC data source as a System DSN. The data source must point to a Microsoft SQL Server database or an Oracle database. For information on configuring an ODBC data source, see your Windows operating system documentation.
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 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:
Note: For information about using the LDAP namespace for an Active Directory user store, see Configure Active Directory Connections.
Note: If the Policy Server is installed on a UNIX operating system, you cannot use the AD namespace for connecting to the AD user store.
The Administrative UI allows you to create custom user directory connections by creating shared libraries using the CA SiteMinder® Directory API (available separately with the Software Development Kit; if installed, see the API Reference Guide for C for more information). Custom connections allow the Policy Server to interact with legacy directories. Once you create a directory connection using the CA SiteMinder® APIs, you can configure a custom namespace on the User Directory pane.
|
Copyright © 2013 CA.
All rights reserved.
|
|