Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Announcement: Try the Ask AI chatbot for answers to your technical questions about Juniper products and solutions.

close
header-navigation
keyboard_arrow_up
list Table of Contents
file_download PDF
{ "lLangCode": "en", "lName": "English", "lCountryCode": "us", "transcode": "en_US" }
English
keyboard_arrow_right

LDAP Authentication

date_range 06-Nov-23

This chapter is relevant only if you wish to use an LDAP server to authenticate Paragon Active Assurance users.

Paragon Active Assurance 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 Paragon Active Assurance 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 Paragon Active Assurance 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 email field. The name of this field can be changed using the setting AUTH_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_DOMAIN and entered into the database. Edit the settings file to change this domain.

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:

content_copy zoom_out_map
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: Password1

This 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:

content_copy zoom_out_map
# 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.

footer-navigation