Body
LDAP
In order to setup the LDAP module module, you should already be familiar with the configuration and maintenance of the LDAP-compatible server you are using. With the LDAP authentication module you can use any LDAP compatible directory server for your source of users, passwords and groups. But as noted above, Kerberos provides more secure authentication of name and password so you may want to use the information in this section for LDAP details, but configure the actual LDAP connection using the Kerberos module.
LDAP version 2 and 3 using the original LDAP server from University of Michigan, OpenLDAP, Netscape Directory Server, NetWare Directory Services (with LDAP support enabled), and Active Directory are all supported. Communication between KeyServer and the LDAP server can be configured to use secure (SSL) when available by checking the option named "Try to establish secure connection to LDAP server". But if the secure connection is unsuccessful, an insecure connection will be used so make sure that your server and the KeyServer host computer are correctly configured so that secure communication is possible. Test with a standard LDAP client tool (such as ldapsearch). When a secure connection cannot be made, all passwords will be visible as clear text when conveyed between KeyServer and the LDAP server.
Configuration for the LDAP authentication module consists of specifying the network location of the LDAP server, providing the DN and password of a directory object with sufficient permission to search for users and check group membership, indicating the base DN within which all searches will be performed, giving the object classes for user, computer, and group objects, and giving the attribute type for group members. Each of these is described in more detail below.
The Host field contains the network address where the LDAP server is located. The Host field can be either the DNS name of the LDAP server or the dotted IP address. Depending on how permissions are set on your LDAP server, you might need to provide a specific “Bind DN” and password. The Bind DN should have permission to search for users and groups and check for membership in a group. If all these can be done by an anonymous user, then you can leave the Bind DN and Bind Password fields empty.
The LDAP module searches for users, computers, and groups within the subtree given in the Base DN field. This value should contain (either directly or in the subtree) objects for all users that will be logging into the KeyServer, all groups that you will be using to control access to policies, and any computers that belong to these groups.
The User Object Class, Computers Object Class, and Group Object Class fields specify the object classes that users, computers, and groups must have. The Group Member Attribute field specifies the attribute type that contains group members. The object classes and attribute type will be used in searches when authenticating users or determining group memberships. If you do not want to use LDAP to determine group memberships, leave the Group Member Attribute field blank. If you do not want to check for group memberships of computers, leave the Computers Object Class field blank.
When verifying a user's password, the LDAP authentication module first searches for the user in the Base DN subtree, and then attempts an LDAP “bind” operation with the resulting DN and the password. When searching for the user, the “cn”, “uid” and “sAMAccountName” attributes are checked to see if they contain the user name (The “sAMAccountName” attribute is included for support of short login names in Active Directory, and is only included in the query if the "Use sAMAccountName Attribute" option is checked). For example, if “John Doe” is attempting to log onto KeyServer, then the following search filter is used, starting from the Base DN and using a subtree search (assuming that User Object Class is “person”):
(&(objectclass=person)(|(cn=John Doe)(uid=John Doe)(sAMAccountName=John Doe)))
Once the user's full DN has been found in the directory, the LDAP module checks the password using an LDAP bind operation.
To check if a user is a member of a group, the LDAP module searches for the group in the Base DN subtree and then verifies that the user is a member of that group. The first search uses the same filter as given above. To check membership, a search filter like the one below is used (assuming the group is named “Some Group”, the Group Object Class is “groupOfNames”, and the Group Attribute is “member”). A subtree search is done in the Base DN subtree:
(&(objectclass=groupOfNames)(cn=Some Group)(|(member=<user DN>)(member=<user name>)(memberuid=<user name>)))
where <user DN> is replaced by the user's DN determined in the first search, and <user Name> is replaced by the user's name as known to KeyServer (“John Doe” in the example above).
If the group membership test for the user fails, and if you have specified the Computers Object Class, then the LDAP module checks if the client computer is a member of the group. First the client computer name (e.g., “JOHNS_PC”) is looked up:
(&(objectclass=computer)(cn=JOHNS_PC))
then a search filter like the one below is used (assuming the same settings as above). A subtree search is done in the Base DN subtree:
(&(objectclass=groupOfNames)(cn=Some Group)(|(member=<computer DN>)(member=<computer name>)))
The table below suggests some values for the object class and attribute names for some common LDAP servers. Note that LDAP servers are customizable, so you should check with your LDAP server administrator that these values are applicable in your environment.
| |
OpenLDAP |
NetWare(NDS) |
Active Directory |
macOS Server |
| User Object Class |
person
or organizationalPerson
or inetOrgPerson |
person
or organizationalPerson
or inetOrgPerson |
person
or organizationalPerson
or inetOrgPerson |
apple-user
or posixAccount
or inetOrgPerson |
| Computer Object Class |
computer |
computer |
computer |
machine |
| Group Object Class |
groupOfNames |
groupOfNames |
group |
apple-group
or posixGroup |
| Group Member Attribute |
member |
member |
member |
member |
| Division Mapping Attribute |
ou |
ou |
ou |
ou |
If you want the list of LDAP groups to appear in KeyConfigure's Groups window, check the option named "Gather Group List". When this option is checked, the LDAP module will perform a search query that might generate a large result set, placing a (temporary) burden on your LDAP server. Because this search can be expensive, the LDAP module will cache the group list. Changes to the group list on the LDAP server will not appear in KeyConfigure for up to an hour. The following search filter is used, starting from the Base DN and using a subtree search (assuming that Group Object Class is “member”):
(objectclass=member)
Note that the "Gather Group List" option is not necessary in order to use groups within KeyServer's Policies. Gathering the group list is only a convenience so you do not have to type the group names into Policy Detail windows. If you choose not to have the LDAP module gather the group list, you can still use the groups in policies by typing the group names as they appear on the LDAP server. Case is not important, and you should not include the attributes (e.g., "cn=").
Divisions can be assigned automatically if you specify a "Division Mapping Attribute"
Further customization of the LDAP module is possible if the standard queries will not work with your LDAP server. Contact Support if you cannot get LDAP to work using the standard configuration options described above.