Skip to main content

SecureAuth IdP Service Account Setup and Configuration Guide for LDAP Directories (Active Directory and others)

Introduction

Use this guide as a reference to configuring an LDAP directory (Active Directory and others) to successfully and securely pass information through SecureAuth IdP.

SecureAuth IdP does not have a directory and therefore does not store any user information; instead, through property - attribute mapping, SecureAuth IdP safely abstracts user data from the integrated directory and asserts it to the target resource.

Included are the Service Account requirements for an LDAP directory integration, the Profile Property information, and example Active Directory Permission configurations.

SecureAuth IdP Service Account Requirements

Prior to installing the SecureAuth IdP appliance, set up a unique SecureAuth IdP Service Account with (at minimum) Read permissions to the directory attributes used to house information required for SecureAuth IdP functionalities:

  • A Service Account is required to enable an LDAP - SecureAuth IdP integration

  • SecureAuth recommends creating a new, unique account specifically for SecureAuth IdP processes

  • SecureAuth recommends that the account be delegated only the minimum level of permissions required to function

    • The Service Account requires Read permissions on user accounts in the directory, or to specific LDAP attributes within the directory (at minimum) to read the basic account information and the data required for out-of-band registration (e-mail address, SMS / telephone numbers, KBQ / KBA, PIN, etc. for Multi-Factor Authentication)

    • The Service Account requires Modify / Write permissions on the accounts / attributes for Identity Management (IdM), data on-boarding, help desk administration, Device Recognition, certificate restrictions, password reset, and other functions

  • The properties of the account should follow the company's established security policies

  • As a best practice, set the account and password to Never Expire to avoid any unexpected authentication outages

Privileged Users and Groups

For Active Directory instances: if accounts with membership to Privileged Groups (Domain Admins, Account Operators, etc.) in Active Directory are used with SecureAuth IdP, then permission denied errors may occur when updating attribute data (such as in Self-service Account Update, Device Recognition, Password Reset, etc.)

This is due to the SecureAuth IdP Service Account being unable to write data to those account types' attributes because of the automatic application of security protection for members of several privileged groups (refer to Microsoft's Documentation for more information)

Workarounds

Option 1. Make the SecureAuth IdP Service Account a member of Domain Admins

This is not recommended for security reasons; however, this typically resolves the permissions issues and removes the need to apply specific security permissions for the Service Account the remainder of the objects in the Domain

Option 2. Ensure that the end-user accounts that require access to SecureAuth IdP services are separate from the privileged groups' accounts (i.e. use a separate, Domain Admins account for directory administration that is not used to access any external services via SecureAuth IdP)

Option 3. Apply permissions to the AdminSDHolder object by following method 2 or method 3 in Microsoft's Documentation

SecureAuth accepts no liability for the results of following the guidance presented in Microsoft's Documentation

Notice

AdminSDHolder is a container inside Active Directory that maintains a master list of permissions for objects that are members of privileged groups, including:

  • Administrators

  • Domain Admins

  • Enterprise Admins

  • Schema Admins

  • Domain Controllers

  • Server Operators

SecureAuth does not recommend making modifications to the AdminSDHolder object and accepts no liability for such actions

LDAP Directory Attribute / SecureAuth IdP Profile Property Mapping

SecureAuth IdP integrates with an LDAP directory and then maps its Profile Properties to LDAP Attributes to create a relationship without requiring data storage on the appliance. Some Properties are auto-populated out-of-the-box with commonly used Active Directory attributes, but they can be changed to any directory field as long as the requirements are met.

The AD field attribute listed in the table provides an example of a valid directory field to use in the configuration; however, you can use any field that fulfills the requirements.

DirectoryString list

The following list contains AD DirectoryString (2.5.5.12) options that can be used for the profile properties noted in the above tables. However, any DirectoryString attribute that fulfills other requirements can be used as well.

  • extensionName

  • facsimileTelephoneNumber

  • info

  • ipPhone

  • otherFacsimileTelephoneNumber

  • otherHomePhone

  • otherLoginWorkstations

  • otherMobile

  • otherPager

  • otherTelephone

  • pager

  • postOfficeBox

  • street

  • streetAddress

Example Service Account Permissions Configuration

The following are example Active Directory configurations of Service Account Permissions. SecureAuth is not responsible for Active Directory configurations and provides these for assistance, but cannot guarantee that they accurately reflect every customer's Active Directory environment. Refer to Microsoft's Documentation for more detailed information about AD Service Accounts.

Notice

SecureAuth provides two (2) methods for configuring Service Account Permissions:

  • Method 1: Configure permissions via the Delegation of Control Wizard

  • Method 2: Configure permissions manually on individual User Objects, the Organizational Unit, or Container

  1. In the Active Directory Users and Computer Management console, right-click on the OU or Container that holds user accounts, and select Delegate Control

  2. In the Delegation of Control Wizard window, click Next

    43977956.png
  3. Click Add

  4. Enter the Service Account name, and click Check Names

    43977957.png
  5. Click OK if the Service Account is found (check spelling if account is not found)

  6. Click Next

    43977958.png
  7. Select Create a custom task to delegate

  8. Click Next

  9. Select Only the following objects in the folder

    43977959.png
  10. Scroll down and select User objects

  11. Click Next

  12. Select Property-specific

    43977960.png
  13. Select the options associated to the attributes to use, playing close attention to Read vs. Write permissions

  14. Click Next, and then Finish to complete the process

View Attributes Defined under InetOrgPerson Objects

Tip

Some objects may not be listed under User objects (e.g. Exchange Email Address / mail)

Follow these steps to view attributes defined user the InetOrgPerson Objects

In some cases, permissions applied to the Exchange Email Address attribute, mail, may appear to be applied; however, mail is an AD attribute, not an Exchange attribute, and the Exchange Server automatically populates the value if used in the domain

Notice

To Change, Reset, and Unlock Accounts

The Delegation Wizard Template option can be used to enable additional features, such as Change Password, Reset Password, Unlock Account, and others

To unlock account rights, configure Allow for Read LockoutTime and Write LockoutTime, Read Password Last Set, and Write Password Last Set

If Change / Reset Password rights are delegated to the SecureAuth Service Account, then note the Network Communications required between SecureAuth IdP and the Domain Controllers for the Enterprise Site

  1. Repeat steps 1 - 8 above and then continue with the following steps

  2. Scroll down and select InetOrgPerson objects

    43977961.png
  3. Click Next

  4. Select Property-specific

    43977962.png
  5. Select the options associated to the attributes to use, playing close attention to Read vs. Write permissions

  6. Click Next, and then Finish to complete the process

  1. In the Active Directory Users and Computers console, right-click on the Individual User Object, Organizational Unit, or Container that holds the accounts to which permissions are being delegated

    Tip

    Set the permissions manually at the Container or Organizational Unit level to propagate user accounts

  2. Select Properties

  3. In the Security tab, click Advanced

    43977963.png
  4. In the Permissions tab, click Add

  5. Enter the Service Account name and click Check Names

    The Permissions Entry for Delegation dialogue displays

    43977964.png
  6. In the Object tab, select Descendant User Objects from the Apply onto dropdown

    For Windows Server 2003, select User Objects

    43977965.png
  7. In the Properties tab, select Descendant User Object

    For Windows Server 2003, select User Object

  8. Click OK

  9. Set the appropriate individual permissions

  10. Click OK on the Advanced Security Settings window

  11. Click OK on the Container Properties window