8.1 Adding an LDAP Repository

IMPORTANT:The LDAP Repository is not available in Advanced Authentication as a Service (SaaS) version.

To add a repository, perform the following steps:

  1. Click Repositories > New LDAP repo.

  2. Select an applicable repository type from the LDAP type list. The options are:

    For AD, a repository name is automatically set to the NetBIOS name of the domain. For other LDAP repository types, you need to specify the name in Name.

  3. Specify a container for the users in Base DN. When you select the Subtree option, Advanced Authentication performs a search for the users in all the child nodes. You can change the search scope by selecting the Search one level only option.

  4. Specify a user account in User and specify the password of the user in Password. Ensure that the user's password has no expiry.

  5. You can specify a container for the groups in Group DN (optional). When you select the Subtree option, Advanced Authentication performs a search for the groups in all the child nodes. You can change the search scope by selecting the Search one level only option.

  6. If you have selected AD as the LDAP type, you can perform the DNS discovery either automatically or manually.

    Automatically Performing the DNS Discovery

    1. Select DNS discovery in the LDAP servers option.

    2. Specify the DNS zone.

    3. Specify the Site name (optional).

    4. The Use SSL option is set to OFF by default. This indicates that the DNS discovery is done on a non-SSL mode for the port 389. An _ldap SRV record is retrieved from the DNS server when this option is disabled. For example, _ldap._tcp.test2.local2.

      To use SSL for DNS discovery on port 636, turn Use SSL to ON. An _ldaps SRV record is retrieved from the DNS server. For example, _ldaps._tcp.test2.local2. However, administrators must create the SRV record on the DNS server before using the SSL option.

    5. Click Perform DNS Discovery.

      When the DNS discovery is done, the DNS servers list is updated every three hours.

    Manually Performing the DNS Discovery

    1. Select the Manual setting option in the LDAP servers option to add LDAP servers manually.

    2. Click Add server. You can add the different servers in your network. The list is used as a pool of servers. Each time the connection is open, a random server is selected in the pool and unavailable servers are discarded.

    3. Specify an LDAP server's Address and Port.

    4. Turn SSL to ON to use SSL (if applicable).

      NOTE:If you specify an RODC (Read Only Domain Controller) in the LDAP server, the server uses this DC for read requests (get groups, get user info) and for logon requests (LDAP Password method and bind requests for Advanced Authentication LDAP user). These requests are redirected to a writable DC because RODC is installed in untrusted locations and does not have copies of the user’s passwords. Therefore, if a writable DC is not available, Advanced Authentication will not be able to bind to the LDAP repository.

      To solve this issue, you must enable the password replication of a user account specified in Step 4. To do this, you must add the account to the Allowed RODC Password Replication Group.

      However, even when you enable such replication, users cannot use the LDAP Password method because user’s passwords are not replicated. It is recommended not to replicate passwords of all the users. For more information, see the article Understanding “Read Only Domain Controller” authentication.

      NOTE:If you have a domain per-site architecture, the Global Master Server must have a connection at least to one LDAP server from each site. This is required because the Global Master Server must have access to all domains. In the secondary sites, ensure that the LDAP servers list contains only local LDAP servers to prevent an Advanced Authentication server to communicate to a remote LDAP server. This is because communication to servers that are located far may result in delays.

      For example, suppose you have the company.com domain at the primary site. Also, there are few child domains, located at other sites such as my1.company.com and my2.company.com. If you will put only LDAP servers from company.com to repository configuration, this will mean there is no sync possible with LDAP servers that belong to the child domains.

      It is necessary to put the local and at least one LDAP server from each child domain on the Global Master Server to allow synchronization with those child domains.

    5. Click the save icon next to server's credentials.

      Add additional servers (if applicable).

  7. (Conditional) To configure custom attributes, expand Advanced Settings. The Advanced Settings are required for OpenDJ, OpenLDAP, and in some cases for NetIQ eDirectory.

  8. Click Save.

    NOTE:If you use NetIQ eDirectory with the option Require TLS for Simple Bind with Password enabled, you may get the error: Can't bind to LDAP: confidentialityRequired. To fix the error, you must either disable the option or do the following:

    1. Click LDAP > LDAP Options > Connections in the NetIQ eDirectory Administration portal.

    2. Set Client Certificate to Not Requested.

    3. Set a correct port number and select SSL in the Repository settings.

    4. Click Sync now with the added repository.

  9. You can change the search scope and the Group DN (optional) functionality. In Advanced Authentication 5.2, you had to specify a common Base DN for users and groups.

  10. To verify the synchronization of a repository, click Edit and you can view the information in Last sync.

  11. Click Full synchronization to perform a complete synchronization of the repository.

    NOTE:Full synchronization must be initiated only on the Global Master server.

    Advanced Authentication performs automatic synchronization of only the modified user attributes (fast synchronization) on an hourly basis. The fast sync is supported for AD repositories only.

    The complete synchronization (Full synchronization) is performed weekly for all types of repositories. The full sync capture all the users and groups from a random LDAP server and verifies against the actual data. The full sync is performed to remove the users who are no longer a member of the groups that are assigned to the authentication chains of Advanced Authentication. If the user is no longer a member of the groups assigned in the authentication chains, it will be marked for removal after N days depending on the Retain the deleted users or groups (days) in the policy. After the period, the user including his authenticators will be deleted from the Advanced Authentication database. This allows to release a user license.

NOTE:If an LDAP server is unavailable for 2.5 seconds, Advanced Authentication excludes it from the LDAP requests for a period of 3 minutes.

8.1.1 Advanced Settings

Advanced Settings allow you to customize attributes that Advanced Authentication reads from a repository. Click + to expand the Advanced Settings. The following list describes the different attributes in Advanced Settings:

User Lookup Attributes

Advanced Authentication validates the specified attributes for an entered user name.

For Active Directory (AD), the default attributes are sAMAccountName and userPrincipalName. For other repositories, cn is the default attribute.

User Name Attributes

Advanced Authentication shows a name from the first, non-empty specified field for an entered user name.

For AD, the default attributes are sAMAccountName and userPrincipalName. For other repositories, cn is the default attribute.

User Mail Attributes

Advanced Authentication validates the specified attributes to retrieve a user's email address.

Default attributes are mail and otherMailbox.

User Cell Phone Attributes

Advanced Authentication validates the specified attributes to retrieve a user's phone number. These attributes are used for methods such as SMS OTP, Voice, and Voice OTP. Previously, the first attribute of User cell phone attributes was used as a default attribute for authenticating with SMS OTP, Voice, and Voice OTP methods. Now, users can use different phone numbers for these methods. For example, Bob wants to authenticate with SMS OTP, Voice, and Voice OTP methods. He has a cell phone number, a home phone number, and an IP phone number and wants to use these numbers for each of these methods. He can define these phone numbers in the respective settings of these methods.

Default attributes: mobile, otherMobile.

NOTE:If you have multiple repositories, you must use the same configuration of User cell phone attributes for all the repositories.

User ID/Passport Number Attributes

Advanced Authentication validates the specified attributes to retrieve the national ID or passport number of users. These attributes are used for the HANIS method.

User Social Security Number Attribute

Advanced Authentication validates the specified attributes to retrieve the Social Security number of users. These attributes are used for the Danish National ID method. As the AD repository does not have a Social Security number attribute, you can specify the Social Security number in any other attribute and specify the same attribute name in this field.

For example, If you register your Social Security number in the Pager number attribute in AD, you can specify Pager in this field. Then, the Advanced Authentication checks the Pager attributes to retrieve the Social Security number.

Group Lookup Attributes

Advanced Authentication validates the specified attributes for an entered group name.

For Active Directory, the default attribute is sAMAccountName. For other repositories, cn is the default attribute.

Group Name Attributes

Advanced Authentication shows a name from the first, non-empty specified field for an entered group name.

For Active Directory, the default attribute is sAMAccountName. For other repositories, cn is the default attribute.

Advanced Authentication supports the RFC 2037 and RFC 2037 bis. RFC 2037 determines a standard LDAP schema and contains a memberUid attribute (POSIX style). RFC 2037 bis determines an updated LDAP schema and contains a member attribute. Active Directory, LDS, and eDir support RFC 2037 bis. OpenLDAP contains posixAccount and posixGroup that follows RFC 2037.

Advanced Authentication supports the following attributes for the Group Name attributes:

Attribute

Default Value

Value for the Repository

User Object Class

user

OpenDJ and OpenLDAP: person

Group Object Class

group

OpenDJ: groupOfNames

OpenLDAP: posixGroup

Group Member Attribute

member

OpenDJ: member

OpenLDAP: memberUid.

If a required group contains groupOfNames class, disable POSIX style groups. If the group contains posixGroup, enable POSIX style groups.

  • User UID attribute

    This attribute is available only when POSIX style groups is ON.Default value: uid.

Object ID Attribute

entryUUID

This attribute is available only for other LDAP type only.

NOTE:For information about the Logon filter settings (Legacy logon tag and MFA logon tag), see Configuring Logon Filter.

Verify SSL Certificate

Enable Verify SSL Certificate to ensure that the LDAP connection to appliance is secured with a valid self-signed SSL certificate. This helps to prevent any attacks on the LDAP connection and ensures safe authentication. Click Browse to browse the self-signed certificate.

Enable Paged Search

The Enable paged search option allows LDAP repositories to support paged search in which the repositories can retrieve a result of a query set in small portions. By default, this option is set to ON. For openLDAP (with file-based backend), the option must be set to OFF.

NOTE:You must not disable the option for Active Directory repositories. It can also affect the performance on other supported repositories such as NetIQ eDirectory.

Enable Nested Groups Support

This option allows you to enable or disable nested groups support. By default, the Enable nested groups support option is set to ON.

If Enable nested groups support option is set to ON, then Advanced Authentication will authenticate all the users of the group and its nested groups assigned to a chain. If Enable nested groups support option is set to OFF, then Advanced Authentication will authenticate only the members of the group assigned to the chain. The members of the nested groups cannot access the chain.

Consider there is a group by name All Users assigned to SMS Authentication chain and the All Usersgroup has subgroups Contractorsand Suppliers.When Enable nested groups support option is set to ON, then Advanced Authentication will authenticate All Users group and the nested groups Contractors and Suppliers for SMS Authentication chain. When the option is set to OFF, then Advanced Authentication will authenticate only the members of All Users group and the nested group members will not have access to SMS Authentication chain. This improves the login performance of the appliance.

Framed IPv4 Address Attribute

This attribute is applicable for the RADIUS Server event.

For Active Directory, when the Framed IPv4 Address is blank, the Advanced Authentication RADIUS server returns value of the msRADIUSFramedIPAddress attribute as Framed-IP-Address after you log in with the RADIUS event. When you specify any other attribute in Framed IPv4 Address attribute, then the value of the specified attribute is returned as the Framed-IP-Address instead of the msRADIUSFramedIPAddress attribute value. You can configure the Framed-IP-Address in Active Directory Users and Computers > Dial-in > Assign Static IP Addresses and click Static IP Addresses. It supports only IPv4.

For the other repositories, when the Framed IPv4 Address is blank, the Advanced Authentication RADIUS server returns value of the radiusFramedIPAddress attribute as Framed-IP-Address after you log in with the RADIUS event. When you specify any other attribute in Framed IPv4 Address attribute, then the value of the specified attribute is returned as the Framed-IP-Address instead of the radiusFramedIPAddress attribute value.

Custom Attributes to Fetch

Custom Attributes to Fetch contains the list of attributes that should be requested from the repository during authentication. In the case of RADIUS Server events, it's possible to configure rules based on the RADIUS Options.It's possible to use it also for SAML 2.0 integrations. In this case, every attribute must be also added to Custom Attributes to Return list. If an attribute contains multiple values, the top value will be used.

Custom Attributes to return

Custom Attributes to Return contains the list of attributes that should be returned to the REST API clients after successful authentication. For SAML 2.0 integrations, only the LDAP attributes are supported. In this case, every attribute must be also added to Custom Attributes to Fetch list. If an attribute contains multiple values, the top value will be used.

Used Attributes

The following table describes the attributes that the appliance uses in the supported directories.

Attribute Name

LDAP Name

Description

Type

Supported in Active Directory

Supported in LDS

Supported in eDirectory

CN (Common Name)

CN

An identifier of an object

String

Mobile

Mobile

A phone number of an object's cellular or mobile phone

Phone number

Email Address

mail

An email address of a user

Email address

User-Principal-Name (UPN)

userPrincipalName

An Internet based format login name for a user

String

SAM-Account-Name

sAMAccountName

The login name used to support clients and servers running earlier versions of operating systems such as Windows NT 4.0

String

×

×

GUID

GUID

An assured unique value for any object

Octet String

×

×

Object Class

Object Class

An unordered list of object classes

String

Member

Member

A list that indicates the objects associated with a group or list

String

User-Account-Control

userAccountControl

Flags that control the behavior of a user account

Enumeration

×

×

ms-DS-User-Account-Control-Computed

msDS-User-Account-Control-Computed

Flags that are similar to userAccountControl, but the attribute's value can contain additional bits that are not persisted

Enumeration

×

Primary-Group-ID

primaryGroupID

A relative identifier (RID) for the primary group of a user

Enumeration

×

×

Object-Guid

objectGUID

A unique identifier for an object

Octet String

×

object-Sid

objectSid

A Binary value that specifies the security identifier (SID) of the user

Octet String

×

Logon-Hours

logonHours

Hours that the user is allowed to logon to the domain

Octet String

×

×

USN-Changed

uSNChanged

An update sequence number (USN) assigned by the local directory for the latest change including creation

Interval

×

NOTE:The sAMAccountName and userPrincipalName attributes are supported only for AD DS repository. The Active Directory LDS and eDirectory repositories do not support the attributes.

LDAP Queries for Repository Sync

Active Directory DS and AD LDS Queries

1. Search users

(&(usnChanged>=217368)(&(objectClass=user)(|(cn=*)(sAMAccountName=*)(userPrincipalName=*))))

Requested attributes:

['objectSID', 'sAMAccountName', 'objectClass', 'logonHours', 'primaryGroupId', 'otherMobile', 'mobile', 'userAccountControl', 'cn', 'usnChanged', 'userPrincipalName', 'msDS-User-Account-Control-Computed', 'objectGUID', 'mail', 'otherMailbox', 'GUID']

2. Search groups

(&(usnChanged>=217368)(&(objectClass=group)(|(cn=*)(sAMAccountName=*))))

Requested attributes:

['objectSID', 'sAMAccountName', 'objectClass', 'logonHours', 'primaryGroupId', 'userAccountControl', 'cn', 'usnChanged', 'msDS-User-Account-Control-Computed', 'objectGUID', 'GUID']

eDirectory Queries

The queries are the same as for Active Directory DS and Active Directory LDS, except for 'usnChanged' (this filter is not used).

1. Search users

(&(objectClass=user)(|(cn=*)(sAMAccountName=*)(userPrincipalName=*)))

Requested attributes:

['objectSID', 'sAMAccountName', 'objectClass', 'logonHours', 'primaryGroupId', 'otherMobile', 'mobile', 'userAccountControl', 'cn', 'userPrincipalName', 'msDS-User-Account-Control-Computed', 'objectGUID', 'mail', 'otherMailbox', 'GUID']

2. Search groups

(&(objectClass=group)(|(cn=*)(sAMAccountName=*)))

Requested attributes:

['objectSID', 'sAMAccountName', 'objectClass', 'logonHours', 'primaryGroupId', 'userAccountControl', 'cn', 'msDS-User-Account-Control-Computed', 'objectGUID', 'GUID']

LDAP Queries During Logon

For Active Directory LDS queries, the attributes are same as Active Directory DS except for the objectSid (the filter is not used in queries on membership in groups).

In the examples below, the username is pjones, base_dn is DC=company,DC=com

Active Directory DS and Active Directory LDS queries

1. Basic user information

(&(objectClass=user)(|(cn=pjones)(sAMAccountName=pjones)(userPrincipalName=pjones)))

Requested attributes:

(&(objectClass=user)(objectGUID=\0f\d1\14\49\bc\cc\04\44\b7\bf\19\06\15\c6\82\55))

Requested attributes:

['otherMobile', 'GUID', 'userAccountControl', 'msDS-User-Account-Control-Computed', 'mobile', 'primaryGroupId', 'cn', 'objectGUID', 'userPrincipalName', 'objectSID', 'mail', 'sAMAccountName', 'objectClass', 'logonHours', 'otherMailbox']

2. Group membership information for user

Active Directory specific query using objectSid filter:

(|(member=CN=pjones,CN=Users,DC=company,DC=com)(objectSid=S-1-5-21-3303523795-413055529-2892985274-513))

Requested attributes:

['GUID', 'userAccountControl', 'msDS-User-Account-Control-Computed', 'primaryGroupId', 'objectGUID', 'cn', 'objectSID', 'objectClass', 'sAMAccountName', 'logonHours']

3. Iteratively query about each group received from above query

(member=CN=Performance Monitor Users,CN=Builtin,DC=company,DC=com)

Requested attributes:

['GUID', 'userAccountControl', 'msDS-User-Account-Control-Computed', 'primaryGroupId', 'objectGUID', 'cn', 'objectSID', 'objectClass', 'sAMAccountName', 'logonHours']

eDirectory Queries

Basic user information

(&(objectClass=user)(|(cn=pjones)(sAMAccountName=pjones)(userPrincipalName=pjones)))

Requested attributes:

['otherMobile', 'GUID', 'userAccountControl', 'msDS-User-Account-Control-Computed', 'mobile', 'primaryGroupId', 'cn', 'objectGUID', 'userPrincipalName', 'objectSID', 'mail', 'sAMAccountName', 'objectClass', 'logonHours', 'otherMailbox']
(&(objectClass=user)(GUID=\57\b6\c2\c1\b9\7f\4b\40\b9\70\5f\9a\1d\76\6c\d2))

Requested attributes:

['otherMobile', 'GUID', 'userAccountControl', 'msDS-User-Account-Control-Computed', 'mobile', 'primaryGroupId', 'cn', 'objectGUID', 'userPrincipalName', 'objectSID', 'mail', 'sAMAccountName', 'objectClass', 'logonHours', 'otherMailbox']

Group membership information for user

              (member=cn=pjones,o=AAF)
            

Requested attributes:

['GUID', 'userAccountControl', 'msDS-User-Account-Control-Computed', 'primaryGroupId', 'objectGUID', 'cn', 'objectSID', 'objectClass', 'sAMAccountName', 'logonHours']

Search groups

(&(objectClass=group)(GUID=<group_GUID>))

Requested attributes:

['cn', 'objectClass', 'GUID', 'loginDisabled', 'loginExpirationTime', 'lockedByIntruder', 'radiusFramedIPAddress']

8.1.2 Adding an AD LDS Repository with the Configured AD LDS Proxy

  1. Click Repositories > New LDAP repo.

  2. Select Other from the LDAP type list.

  3. Specify a container for the users in Base DN. When you select the Subtree option, Advanced Authentication performs a search for the users in all the child nodes. You can change the search scope by selecting the Search one level only option.

  4. Specify a user account in User and specify the password of the user in Password. Ensure that the user's password has no expiry.

  5. You can specify a container for the groups in Group DN (optional). When you select the Subtree option, Advanced Authentication performs a search for the groups in all the child nodes. You can change the search scope by selecting the Search one level only option.

  6. Under Advanced Settings, specify objectGUID as object ID attribute and userProxy as user class.

  7. Click Save.

NOTE:The drawback of this solution is that Advanced Authentication server does not validate the user attributes (account disabled, account locked out, and so on). This solution is beneficial when the users log on using the chain that does not include the LDAP password method (for example, CARD + PIN). However, LDS validates the user attributes in both the above scenarios when the LDAP password method is in use.