LDAP Authentication
This chapter is relevant only if you wish to use an LDAP server to authenticate Routing Active Testing users.
Routing Active Testing supports the use of LDAP to manage and authenticate its users in a centralized way. The authentication is then done using a remote server instead of the local Control Center user database.
When a user attempts to log in to Control Center, the latter sends an authorization request to the LDAP server. Based on the response, Control Center grants or denies the user access to Routing Active Testing accounts as detailed in the response.
- If some account is defined twice in the mapping from LDAP to Control Center, the user will receive the higher permission of the two granted. Thus, if the permission is set to "read" in one list element and to "admin" in another, the user will receive admin permission for that account.
- If one permission mapping grants permission to one account and another mapping denies it, then the user will receive access to the account.
- Account permissions are synchronized with the LDAP server on each user login. If the user is granted additional permissions by the Routing Active Testing local admin, these are valid only until the next time the user logs in. Conversely, if the user's privileges are changed on the LDAP server, these will not come into effect until next login.
- If the user name entered at login matches the email address of an existing Control Center user, the login will proceed using that user rather than a new one being created. However, during server authentication, all user profile details except the password will be overwritten with what is stored on the server, insofar as these details have been defined. The user can still log in using the existing Control Center password. This means that select users can have the password set in Control Center, so that it is still possible to log in if the LDAP server goes down.
- If the user name entered at login does not exist in Control Center, the following
happens:
- The user's email address is read from the user
emailfield. The name of this field can be changed using the settingAUTH_LDAP_USER_ATTR_MAP. - If the email address is valid, it will be entered as email address in the Control Center database as well. However, the user will still have to log in with his LDAP username.
- If the email address is not valid, an email address will be created with the structure
username@LDAP_EMAIL_DOMAINand entered into the database. Edit the settings file to change this domain.
- The user's email address is read from the user
We will illustrate the above by reproducing a typical (OpenLDAP) server-side file with data preloaded into the LDAP database, and subsequently showing what corresponding configuration is necessary in Control Center.
Contents of ldap.ldif:
dn: dc=example,dc=com
objectClass: organization
objectClass: dcObject
objectClass: top
dc: example
o: example.com
dn: ou=users,dc=example,dc=com
objectClass: top
objectClass: groupOfNames
cn: Users
member: uid=jsmith,dc=example,dc=com
member: uid=jane.smith@example.com,dc=example,dc=com
ou: users
dn: uid=jsmith,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: extensibleObject
cn: John Smith
givenName: John
sn: Smith
c: GB
telephoneNumber: +44 20 7946 0296
mail: john.smith@example.com
uid: jsmith
userPassword: Password1
dn: uid=jane.smith@example.com,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: extensibleObject
cn: Jane Smith
givenName: Jane
sn: Smith
c: GB
telephoneNumber: +44 20 7946 0580
mail: jane.smith@example.com
uid: jane.smith@example.com
userPassword: Password1
dn: ou=admins,dc=example,dc=com
objectClass: top
objectClass: groupOfNames
cn: Administrators
member: uid=jdoe,dc=example,dc=com
member: uid=jane.doe@example.com,dc=example,dc=com
ou: admins
dn: uid=jdoe,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: extensibleObject
cn: John Doe
givenName: John
sn: Doe
c: GB
telephoneNumber: +44 20 7946 0344
mail: john.doe@example.com
uid: jdoe
userPassword: Password1
dn: uid=jane.doe@example.com,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: extensibleObject
cn: Jane Doe
givenName: Jane
sn: Doe
c: GB
telephoneNumber: +44 20 7946 0113
mail: jane.doe@example.com
uid: jane.doe@example.com
userPassword: Password1This creates a total of four users, two with write privileges
(jsmith and jane.smith@example.com) and two
with admin privileges (jdoe and
jane.doe@example.com). Note how two of the users have their
user name as uid, while the other two have a uid
consisting of an email address.
In order to enable LDAP authentication in Control Center, the following attributes
have to be provided in the settings file
/etc/netrounds/netrounds.conf:
# LDAP settings
import ldap
# NOTE: ActiveDirectoryGroupType is only needed if you are using Microsoft Active Directory.
from django_auth_ldap.config import LDAPSearch, GroupOfNamesType, ActiveDirectoryGroupType
AUTH_LDAP_ENABLED = True
AUTH_LDAP_START_TLS = True
AUTH_LDAP_SERVER_URI = 'ldap://ldap.example.com'
AUTH_LDAP_USER_DN_TEMPLATE = 'uid=%(user)s,dc=example,dc=com'
# LDAP user attribute value to use during lookup on database side
AUTH_LDAP_USER_QUERY_FIELD = 'email'
# This is the domain that will be appended to the username when the one from
# LDAP is not a valid email
AUTH_LDAP_EMAIL_DOMAIN='example.com'
# Set up the basic group parameters
# For vanilla LDAP such as OpenLDAP, use this.
GROUP_OBJECTCLASS_NAME ='groupOfNames'
# Uncomment this if using Microsoft Active Directory
# GROUP_OBJECTCLASS_NAME = 'group'
AUTH_LDAP_GROUP_SEARCH = LDAPSearch('dc=example,dc=com',
ldap.SCOPE_ONELEVEL,
'(objectClass=%s)' % GROUP_OBJECTCLASS_NAME
)
# LDAP group type used to indicate group membership for a user
AUTH_LDAP_GROUP_TYPE = GroupOfNamesType()
# Note: If you are using Microsoft Active Directory, use this instead:
# AUTH_LDAP_GROUP_TYPE = ActiveDirectoryGroupType()
# Mapping between LDAP groups and Control Center account/permission
AUTH_LDAP_ACCOUNT_GROUP_MAPPING = [
{
'dn': 'ou=users,dc=example,dc=com',
'accounts': [
{
'name': 'dev',
'permission': 'write'
}
]
},
{
'dn': 'ou=admins,dc=example,dc=com',
'accounts': [
{
'name': 'dev',
'permission': 'admin'
}
]
}
]
# Populate the Django user from the LDAP directory
AUTH_LDAP_USER_ATTR_MAP = {
'first_name': 'givenName',
'last_name': 'sn',
'email': 'mail',
'phone': 'telephoneNumber',
'country': 'c'
}
# LDAP connection options
AUTH_LDAP_CONNECTION_OPTIONS = {
# Limit on waiting for a network response in seconds. This is a timeout
# returned by poll/select following a connect in case of no activity.
# OpenLDAP specific.
ldap.OPT_NETWORK_TIMEOUT: 30,
# Timeout value for the synchronous API calls in seconds. OpenLDAP specific.
ldap.OPT_TIMEOUT: 30
}
# The following user must exist unless anonymous login is allowed
# Non-anonymous bind DN
# Note: It is mandatory for AUTH_LDAP_BIND_DN to start with a 'cn=' relative
# distinguished name. Using 'uid=' will not work in case OpenLDAP is used as server.
AUTH_LDAP_BIND_DN = 'cn=admin,dc=example,dc=com'
# Non-anonymous bind password
AUTH_LDAP_BIND_PASSWORD = 'Password1'
# Finally, in order to get LDAP working, the first list item must be
# added below
AUTHENTICATION_BACKENDS = (
'netrounds.domain.backends.LDAPAuthBackend',
'netrounds.domain.backends.AuthBackend',
)Most of the above follows what is documented at https://django-auth-ldap.readthedocs.io/en/latest/reference.html#settings.