Chapter Contents
Elektron may be configured to authenticate users against your network’s LDAP directory. To use LDAP for user authentication, select and configure it using the Authentication panel in the Elektron Settings application.
LDAP user authentication is performed using an LDAP “bind” operation. That is, a user requesting network access provides Elektron with a username and password, which in turn is used by Elektron to bind to the LDAP directory. This requirement — that Elektron has access to the unhashed, unencoded user password — limits the authentication methods support by LDAP. The available methods are PAP, TTLS/PAP, and PEAP/EAP-GTC.
LDAP Configuration
The following configuration options are available:
Server Address
Enter the DNS name or IP address of your LDAP server.
Server Port
For non-SSL connections, the default port is 389; for SSL connections, the default port is 636.
Use SSL
This option determines whether or not Elektron will communicate with the LDAP server using an SSL connection. If this option is enabled, the LDAP server’s SSL certificate will be authenticated during the connection. Elektron uses operating system services to communicate with LDAP servers, so your server’s operating system must be configured to accept your LDAP server’s SSL certificate.
Bind DN
Elektron must bind to the LDAP directory in order to search for the user being authenticated. This field contains the distinguished name of that will be used to perform this initial bind. For example, binding to an Open Directory LDAP server might look like:
uid=ldapuser,cn=users,dc=periodiklabs,dc=com
Bind Password
This is the password used for the initial LDAP bind. It must match the login for the distinguished name configured in the Bind DN field.
Search Base DN
The LDAP distinguished name that will be used as a starting point for the search.
Search Filter
An LDAP search filter as defined in RFC 1960. The following filter will be passed to the LDAP server using a combination of your specified search filter and the username of the user being authenticated:
(&(<filter>)(<uid>=<username>))
where
For example, if you choose to constrain user lookups to the ACME Widget Company, your search filter might be:
“o=ACME Widget, c=US”
UID Attribute
The name of the attribute that holds the username in your LDAP directory. If left blank, “uid” will be used. If you are authenticating against an Open Directory LDAP server, “uid” will work for this attribute; when authenticating against an Active Directory LDAP server, use “sAMAccountName”. Group Membership You may optionally define the attributes used to pull group membership information out of the LDAP directory. If you are not using authorization policies, or are not using authorization policies based on account group membership, you may leave these options blank. If these options are not configured, Elektron will not be able to obtain group membership information.
When using LDAP groups to apply policies, Elektron uses the common name attribute of the group as the group name. You should be careful when naming your groups in order to disambiguate the groups names. For instance, an LDAP directory containing the following two group entries:
CN=Users,OU=Sales,DC=periodiklabs,DC=com
CN=Users,OU=Marketing,DC=periodiklabs,DC=com
would lead to Elektron seeing only one group name, “Users”. This restriction is due to the many different ways which different LDAP servers store group information. It presents a “lowest common denominator” approach. For the same reason, nested group membership is not support. For instance, if a user is a member of the “Users” group, and that group is itself a member of the “Domain Users” group, Elektron will only see the “Users” group.
Active Directory Groups
With this option selected, Elektron will use the Active directory LDAP schema for determining group membership. This means that the record for the user being authenticated will be searched for “memberOf” attributes containing Active Directory groups.
Note that the Active Directory LDAP component will not return the name of the user’s primary group in this attribute. This is a shortcoming of Active Directory. If you have policies configured that use account groups as policy criteria, be sure not to use the user’s primary group as a criterion, since it will not show up. This is not usually a problem, since the default primary group for users in an Active Directory is usually “Domain Users”. This make the primary group the same for all users, meaning it is not particularly useful for defining a policy that will apply to specific users.
A more efficient way to use Active Directory for authentication is to install Elektron on an Active Directory controller and use Windows accounts for authentication. This has the advantage of being faster, offering more authentication protocol options, and including full group membership information.
Group Object Class
The object class within the LDAP directory that is used to store account group information. This is “group” many LDAP schemas, and “apple-group” for Open Directory. If left blank, “group” will be used.
Group Member Attribute
Within the group object, the attributes that contains UIDs of the members of the group. Many LDAP schemas use “member”; Open Directory uses “memberUid”. If left blank, “member” will be used.