LDAP Connection Behavior as of Release 2017 R1
As of Release 2017 R1, LDAP connections have been enhanced in the following ways:
• A new Group Membership Process automatically adds users to groups based on permissions associated with the group. This process runs at the end of every LDAP Synchronization job, and automatically whenever you Publish if any of your changes have touched the Users, Groups, or Permissions tabs.
• Attribute mapping has been extended to handle constants, manual entry, and mapping both LDAP organizational units and LDAP group names.
• A single LDAP connection is designed to gather all of the information needed to create the user and to synchronize the user’s attribute data from LDAP. In addition, relevant organizational unit information and security group membership can be mapped to the user’s attributes stored in aPriori. In this way the automated Group Membership Process can associate the user to the correct Access Control groups.
• The user’s provenance can either be “Manual”, an LDAP connection, or blank.
• Manual means that LDAP connections should not modify this user (changes are managed by admins through the UI).
• LDAP connection name means that the named connection will manage this user; other connections will ignore it.
• Blank should be a temporary value that is used for users that are intended to be managed by an LDAP connection. When the user is provisioned properly in LDAP, a sync will pick this user up. We do not want to put the connection name in since if the user is not yet provisioned in LDAP, a sync will not find the user and LDAP map/sync will remove the user from the aPriori database.
Note: When importing users from a spreadsheet, if a user’s provenance is changed from LDAP to either blank or Manual, their password is reset to the default value provided during spreadsheet import. On their next login, they will be prompted with a Reset Password dialog (the same as a new user added via spreadsheet).
LDAP connections can be manually invoked one at a time through the UI (“LDAP Map”), or multiple connections can be run in an automated sync job (“LDAP Sync”, which requires the separately licensed LDAP Synchronization module). When using LDAP Map, the administrator can invoke all or some of the connections and can process the additions, modifications, and deletions after each connection is synced. For an LDAP Sync job, the connections that are contained in the scheduled job will run and the changes will be published (no opportunity for manual massaging of the results).
When running LDAP Map, the user must “publish” the changes to the database by clicking on the Publish Changes icon in the toolbar..
The following rules describe connection logic during a sync (both manual and automated).
• User is returned by the sync and the user already exists
o User’s provenance matches the LDAP connection or the user’s provenance is blank then the user is updated and all attributes (including the user’s provenance if it is blank) get updated; user is added to the modify list.
• User is returned by the sync and the user does not already exist
o The user is created, and all attributes are updated including setting the provenance; user is added to the addition list.
• User is returned by the sync and the user’s provenance does not match the LDAP connection
o The user is not updated.
• User is returned by the sync and the user’s provenance is “Manual”
o The user is ignored (not put on the modified list either).
• User is not returned but the user’s provenance matches the LDAP connection
o The user is marked for deletion (i.e. put on the deletion list).
• User is not returned, and the user’s provenance does not match the LDAP connection, or it is blank
o The user is ignored.
The following table summarizes this behavior in terms of the System and VPE Admin checkboxes on the aPriori tab of the LDAP Connection dialog box:
Conditions of users | ||
same Provenance | different Provenance | |
Users returned by LDAP qry | group membership impact - see table below | ignored |
Users NOT returned by LDAP qry | removed from aP | ignored |
changes for users returned by LDAP query AND have matching or blank Provenance | |||
Admin groups (sysAdmin & vpeAdmin) | |||
checked | unchecked | ||
Sync Admin Group Membership | checked | added to group (or remain in group) | removed from group if a member |
unchecked | no changes | no changes | |
The addition, modification and deletion lists are processed when the Publish button is clicked.
To change the connection that a user is provisioned by, an admin first changes the user’s provenance field, clicks Publish, and then runs that newly-specified connection.
Multiple LDAP connections
The behavior of how LDAP Map or LDAP Sync handle multiple connections has not changed, except that they do not manage group membership anymore. In general, an individual user should be provisioned by a single connection. If a user is returned by more than once connection, LDAP sync will use the connection that matches the value of the user’s Provenance field. If the provenance is blank, the provenance is set to the connection that has returned the user.
LDAP Authentication
LDAP authentication is used when a user’s provenance is set to an LDAP connection. You must first define the connection using the aPriori System Administrator Window. Connections can be defined as either Simple Authentication or Kerberos. If Kerberos authentication is used, you can elect to have Kerberos tickets cached, allowing automatic log ins to aPriori after an initial authentication.
Note: If SSO is turned on then the authentication via the user’s Domain-cached Kerberos ticket will take precedence over the LDAP Kerberos cached ticket. In simpler terms, when SSO is enabled, the user’s Windows authentication will take precedence over the LDAP connection authentication.
(See Managing Single Sign On options for information about Single Sign On authentication which also allows for automatic log ins.)
Simple Authentication
• Login: when aPriori is started it presents a login dialog and the user is asked to enter their username and password.
• Authentication: aPriori authenticates the user’s credentials using the LDAP connection (i.e. the LDAP directory is used).
Kerberos (including “automatic log in”)
When you choose Kerberos authentication, you can choose whether or not specify Allow Credential Caching:
Credential caching disabled: the login and authentication process works similar to Simple Authentication above.
Credential caching enabled (“automatic log in”):
• Login: when aPriori is started for the first time it presents a login dialog and the user is asked to enter their username and password. The user’s Kerberos credentials are cached. When aPriori is started the next time, aPriori will skip the login screen and use the cached credentials (assuming the credentials have not expired and are still valid).
• Authentication: aPriori authenticates the user’s credentials using the LDAP connection (i.e. the LDAP directory is used).
