LDAP Authentication

LDAP provides a single store for all user information and avoids the replication of such details, and in particular passwords, in more than one place. Common examples of LDAP servers in the enterprise are:

Microsoft Active Directory on Windows
RedHat Fedora Directory Server (formally Netscape Directory Server)
OpenLDAP on most Linux and Unix platforms
IBM Tivoli Directory Server
Novell eDirectory
Oracle Internet Directory

Using LDAP for authentication is strongly recommended on sites with multiple KCML application servers.

Most PAM based LDAP authenticators will require the use of the standard RFC2307 schema when used to authenticate against an LDAP server. However this is not the default schema for Microsoft Active Directory though it is an option when installing AD on Windows 2003R2. Microsoft's recommended paractice for integrating Unix servers into an Active domain is to use Windows 2003R2 and to install the included Windows Services for Unix (SFU) options. SFU is available as a free download for earlier versions of Active Directory. SFU adds the extra attributes to the User account replacing those of traditional Unix files like /etc/passwd. For specific details of how to authenticate against AD with SFU installed see this page.

The Connection Manager can still authenticate against an Active Directory server that is not RFC2307 compliant with certain restrictions, the most important of which is that there must be a common user account setup locally on the application servers and that all KCML processes will run under that account. However KCML will set the LOGNAME environment variable to the actual authenticated user.

Furthermore it cannot enforce AD password expiry policies and there is no practical way to change a password. This may not matter if the user is authenticating using the same credentials used to log into the Windows workstation as it will already have handled any password policy issues.

There is no change required to the LDAP database other than it is advisable that you create a group for this purpose and make only the users that can access the KCML system members of that group. KCML can then check group membership as a condition of access.

All the configuration for this form of LDAP authentication is set in the kconf.xml configuration file that is shared by all the connection managers. To implement it you need to add an <authenticators> section at the top level E.g.:

<authenticators>
<!-- named authentication schemes -->
	<scheme>
		<name>AD</name>
		<!-- Try LDAP authentication to Active directory first -->
		<methods>
			<ldap>
				<server>ldap://ldap.example.com</server>
				<isAD>Y</isAD>
				<baseDN>DC=example,DC=com</baseDN>
				<userDN>OU=People,</userDN>
				<user>CN=ADBoss,CN=Users,</user>
				<pwd>secret</pwd>
				<uid>kcmluser</uid>
				<gid>kcml</gid>
				<memberOf>CN=K8 users,OU=People,</memberOf>
			</ldap>
			<pam>kisam</pam>
			<os/>
		</methods>
	</scheme>
	...
</authenticators>

There can be multiple named schemes in this section and there can also be multiple authentication methods in each scheme. These methods will be tried in turn until one succeeds or they all fail thus allowing some fallback if the LDAP server is down. Other supported methods are <pam> where you specify a PAM configuration to use or <os> which uses the native authentication for the server, which might be PAM again or it might just be /etc/passwd lookup.

The attributes that you can define for the LDAP methods are as follows.

server	Required	This is the URL specifying the LDAP server. If you specify ldaps:// then it will use SSL. If this tag occurs more than once then the servers will be tried in turn to find one that responds. See also the isRR tag. Up to 4 servers are supported.
baseDN	Required	This is the DN (distinguished name) of top of the LDAP tree and will be appended to the end of relative DNs that end in a comma.
userDN	Optional	This is the DN to start searching for the user. It should be as close to the point in the tree that defines users. If it ends in a comma the baseDN will be appended. If missing the baseDN will be used but this will increase the time to authenticate appreciably.
user	Optional	The DN for user with browse access to the database. If not supplied then an anonymous bind is attempted. Active Directory does not support anonymous binds and so this is required for AD.
pwd	Optional	The corresponding password for the browser user
uid	Required	The name of a local user on the apps server. All KCML processes will run owned by that user. It should exist in the local /etc/passwd or NIS database.
gid	Required	The name of a group to which the user belongs in the local /etc/group
memberOf	Optional	A group on the LDAP server that a user must belong to in order to get access. If missing then any user in the directory will have access to the KCML system. It can be a relative DN with respect to either userDN or baseDN.
isAD	Optional	Set this to 'Y' to authenticate against a Microsoft Active Directory server. It tells KCML to use the sAMAccount as the username to match. For RFC2307 systems like OpenLDAP do not define this tag.
isRR	Optional	Set this to 'Y' to use a round robin algorithm in determining which server to query, assuming multiple <server> tags have been defined.
filter	Optional	This can be any filter expression acceptable to LDAP. It should contain a %s at the point the username is to be included e.g. "(uid=%s)". It allows for non-standard lookups.
timeout	Optional	Maximum time, in seconds, to perform an LDAP search. If this value is not specified a default timeout of 2 seconds is used.

In an Active Directory schema the search will compare the user id entered with the sAMAccount attribute. With standards based schemas it will check the uid attribute.

Against the section in <web_services> specifying the KCML binary to run, you should specify the named authenticator to use with the <authschem> tag. If you don't specify one then native OS authentication is used. E.g.

<kweb_services>
	...
	<kweb_service>
		<name>kcml</name>
		<authscheme>AD</authscheme>
		<program>$KCMLDIR/kcml</program>
	</kweb_service>
	...
</kweb_services>

LDAP authentication is only supported if the KCML client connects using the -M switch for HTTP based connections.

See Also: