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
In the Active Directory Users and Computer Management console, right-click on the OU or Container that holds user accounts, and select Delegate Control
In the Delegation of Control Wizard window, click Next
Click Add
Enter the Service Account name, and click Check Names
Click OK if the Service Account is found (check spelling if account is not found)
Click Next
Select Create a custom task to delegate
Click Next
Select Only the following objects in the folder
Scroll down and select User objects
Click Next
Select Property-specific
Select the options associated to the attributes to use, playing close attention to Read vs. Write permissions
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
Repeat steps 1 - 8 above and then continue with the following steps
Scroll down and select InetOrgPerson objects
Click Next
Select Property-specific
Select the options associated to the attributes to use, playing close attention to Read vs. Write permissions
Click Next, and then Finish to complete the process
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
Select Properties
In the Security tab, click Advanced
In the Permissions tab, click Add
Enter the Service Account name and click Check Names
The Permissions Entry for Delegation dialogue displays
In the Object tab, select Descendant User Objects from the Apply onto dropdown
For Windows Server 2003, select User Objects
In the Properties tab, select Descendant User Object
For Windows Server 2003, select User Object
Click OK
Set the appropriate individual permissions
Click OK on the Advanced Security Settings window
Click OK on the Container Properties window