How to Configure OpenLDAP Server User Directory Connections

Policy Server Guides › Policy Server Configuration Guide › User Directories › How to Configure OpenLDAP Server User Directory Connections

How to Configure OpenLDAP Server User Directory Connections

You can use OpenLDAP Server as a user store. Complete the following steps to create the user directory connection:

Create a user store.
Configure the OpenLDAP Server user directory connection.

Create a User Store

You can use an OpenLDAP directory server as a user store

To create a user store

Use an LDIF file to create ou=People under the root DN.
Create users under the organizational unit.

Configure OpenLDAP Directory Server User Directory Connections

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

Follow these steps:

Click Infrastructure, Directory.
Select User Directories.
Click Create User Directory..
Complete the required connection information in the General and Directory Setup areas.
Configure the LDAP search and LDAP user DN lookup settings in the LDAP Settings area.
Do the following steps in the Administrator Credentials area:
1. Select the Require Credentials option.
2. Enter the credentials of an administrator account.
(Optional) Specify the user directory profile attributes that are reserved for SiteMinder use in the User Attributes area.
(Optional) Click Create in the Attribute Mapping List area to configure user attribute mapping.
Click Submit.
The user directory connection is created.

More information:

LDAP Load Balancing and Failover

Define an Attribute Mapping

Configure Red Hat Directory Server User Directory Connnections

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

Follow these steps:

Click Infrastructure, Directory.
Select User Directories.
Click Create User Directory..
Complete the required connection information in the General and Directory Setup areas.
Configure the LDAP search and LDAP user DN lookup settings in the LDAP Settings area.
Do the following in the Administrator Credentials area:
1. Select the Require Credentials option.
2. Enter the credentials of an administrator account.
(Optional) Specify the user directory profile attributes that are reserved for SiteMinder use in the User Attributes area.
(Optional) Click Create in the Attribute Mapping List area to configure user attribute mapping.
Click Submit.
The user directory connection is created.

SQL Server User Store Case Insensitivity and Extra Trailing Spaces Password Issues

A SQL Server user store can be case insensitive and also ignore extra trailing spaces in users’ passwords. This causes a problem because users entering passwords that are case insensitive or with extra trailing spaces can gain access to protected resources. For example, if a password policy is configured so that a user's password must be the case sensitive "ABCD", but the user enters "ABcd", SQL Server allows entry. In another example, if the password policy is configured so that a user's password must be " A B C", but the user enters " A B C ", SQL Server ignores the extra trailing spaces in the password and allows entry.

The following are solutions to these two issues.

First Issue: SQL Server User Store is Case Insensitive: The SQL Server database is not performing proper collation and does not recognize case sensitivity in passwords.
Solution 1

To impose case sensitivity to a SQL Server user store, select the proper collation during table creation when installing the database.

For more information about the collation, see the following:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/instsql/in_collation_3oa6.asp

Solution 2

If you already installed SQL Server with the default collation and the database does not recognize case sensitivity in passwords, create the proper collation when creating tables for the user store.

To specify the collation, modify and then import one of the following scripts.

siteminder_install\db\SQL\smsampleusers_sqlserver.sql

siteminder_install\db\SQL\smsampleusers_sqlserver_upgrade.sql

Note: These two script files use the default US English localization.

smsampleusers_sqlserver.sql Script File

Change the following lines highlighted in bold in the smsampleusers_sqlserver.sql script file:

CREATE TABLE SmGroup (
       GroupID          int NOT NULL,
       Name nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL ,
       PRIMARY KEY (GroupID)
)
DROP TABLE SmUser
go
CREATE TABLE SmUser (
   UserID         int NOT NULL,
   Name  nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL,
   Password nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL,
   LastName nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL,
   FirstName nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL,
   EmailAddress nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL,
   TelephoneNumber nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL ,
     Disabled nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL ,
     PIN      nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL ,
     Mileage int NOT NULL,
     PasswordData varchar(2000) NOT NULL,
     PRIMARY KEY (UserID)
 )
go

After modifying the script, you need to import it into the SQL Server database.

Important! Back up any existing data as running this script removes existing data and creates new tables.

smsampleusers_sqlserver_upgrade.sql Script File

The following lines highlighted in bold are changes you need to make in the smsampleusers_sqlserver_upgrade.sql script file:

/* Upgrade table SmGroup*/
ALTER TABLE  SmGroup ALTER COLUMN Name nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL
go
/* Upgrade table SmUser*/
ALTER TABLE  SmUser ALTER COLUMN Name nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL
go
ALTER TABLE  SmUser ALTER COLUMN Password nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL
go
ALTER TABLE  SmUser ALTER COLUMN LastName nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL
go
ALTER TABLE  SmUser ALTER COLUMN FirstName nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL
go
ALTER TABLE  SmUser ALTER COLUMN EmailAddress nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL
go
ALTER TABLE  SmUser ALTER COLUMN TelephoneNumber nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL
go
ALTER TABLE  SmUser ALTER COLUMN Disabled nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL 
go
ALTER TABLE  SmUser ALTER COLUMN PIN nvarchar(255) COLLATE Latin1_General_CS_AS NOT NULL
go

After modifying the script, you need to import it into the SQL Server database.

Important! Back up any existing data as running this script removes existing data and creates new tables.

Second Issue: SQL Server Ignores Trailing Spaces in the Password

SQL Server pads the strings that are being compared and makes their lengths equal.

Solution

To have SQL Server recognize trailing white spaces in passwords stored in the database, modify the Authenticate User query in the ODBC Query Scheme object using the Administrative UI. To have SQL Server compare strings without padding or trimming, incorporate the LIKE predicate instead of the = operator. When the right side of a LIKE predicate expression features a value with a trailing space, SQL Server does not pad the two values to the same length before the comparison occurs. An example authentication query is:

select Name from SmUser where Name = '%s' and Password LIKE '%s'

Important! Using the LIKE predicate expression in the password matching query can open a security hole. If a user enters a ‘%’ in the password, SQL Server treats it as wild card character for the LIKE predicate and this user can authenticate using more than one password.

Note the following:

If you are creating the ODBC query scheme object using the SDK, you can specify the authentication query using the pszQueryAuthenticateUser attribute of the Sm_PolicyApi_ODBCQueryScheme_t object.
If you are creating the ODBC query scheme object using Perl Scripting Interface, you can specify the authentication query while calling the CreateODBCQueryScheme() API.

Configure ODBC Directory Connections

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

If you use a Microsoft SQL Server database for audit logs and caching is turned on, under heavy load, performance may suffer as the Policy Server queues messages for logging. Turn on asynchronous auditing for the realms associated with the resources being accessed by a high volume of users to alleviate the problem.

Follow these steps:

Click Infrastructure, Directory.
Objects related to user directories appear on the left.
Click User Directories.
The User Directories screen appears.
Click Create User Directory.
The Create User Directory screen appears and displays the required settings to configure an LDAP connection.
Select ODBC from the Namespace list.
ODBC settings appear.
Complete the remaining required connection information in the General and Directory Setup areas.
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.
Select a SQL query scheme.
(Optional) Do the following in the Administrator Credentials area:
1. Select Require Credentials.
2. Enter the credentials of an administrator account.
Note: The user name must match the user who owns the tables containing user directory data. For example, if you are using the SmSampleUsers schema, this user must be the owner of the SmUser, SmUserGroup, and SmGroup tables. The administrator account must have read or read/write privileges for the user directory.
(Optional) Specify the user directory profile attributes that are reserved for SiteMinder use in the User Attributes area.
(Optional) Click Create in the Attribute Mapping List area to configure user attribute mapping.
Click Submit.
The user directory connection is created.

More information:

SQL Query Schemes

Configure ODBC Data Source Failover

Define an Attribute Mapping

Configure Custom Directory Connections

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

Follow these steps:

Click Infrastructure, Directory.
Click User Directories.
Click Create User Directory.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
Select Custom from the Namespace list.
Complete the required connection information in the General and Directory Setup areas.
(Optional) Complete the following steps in the Administrator Credentials area:
1. Select the Require Credentials option.
2. Enter the credentials of an administrator account.
(Optional) Click Create in the Attribute Mapping List area to configure user attribute mapping.
Note: The Policy Server uses the shared library to determine the user attributes that are available to the custom directory. Before you enter user attributes, create the user directory connection.
Click Submit.
The user directory connection is created.

More information:

Directory Attributes Overview

Define an Attribute Mapping