An identity source is a repository in the Cloud Authentication Service that represents one primary LDAP directory server and its replicas. This topic describes:
The Cloud Authentication Service supports Microsoft Active Directory and LDAPv3 directories. The LDAPv3 servers must support Simple Paged Search. Your LDAP server must support control type 1.2.840.1135220.127.116.119. See your LDAP server documentation to verify this support before adding an LDAPv3 identity source.
The Cloud Authentication Service has read-only access to the LDAP directory server. To manage LDAP users within RSA SecurID Access, register user Authenticate devices and FIDO Tokens, and ensure that attributes are available for access policies and SMS Tokencode and Voice Tokencode authentication, user records must be synchronized between the Cloud Authentication Service and the directory server.
Identity source synchronization produces the following results:
New user records are added to the cloud.
Existing user records are overwritten in the cloud. All attribute values that were modified in the LDAP directory server since the previous synchronization are updated in the cloud. Attribute values that did not originate in LDAP and exist only in the cloud are not overwritten. For example, these include user devices and authentication methods.
The Cloud Authentication Service automatically disables or re-enables users depending on whether they are expired, disabled, or missing in the directory server. For details, see Synchronization and User Status in the Cloud Authentication Service.
During synchronization, RSA SecurID Access searches for an available identity source server. At least one server must be reachable. If a server cannot be reached, the synchronization process terminates.
Users who are moved to a different organizational unit (OU) in the LDAP directory server cannot use their LDAP directory passwords for device registration until after synchronization. You can enable just-in-time synchronization to avoid this issue.
Note: The identity router uses simple bind authentication for connections to LDAP directory servers.
Synchronization may update the user status in the Cloud Authentication Service based on the status in the directory server. The relevant attributes are automatically mapped for Active Directory identity sources. Manual mapping is required for LDAPv3 identity sources. If you map only one attribute for an LDAPv3 identity source, that attribute provides the user status from the directory server. If you do not map any attributes for LDAPv3, the Cloud Authentication Service views the user as enabled in the directory server and the status in the Cloud Authentication Service is never overridden during synchronization. If you map both attributes for an LDAPv3 identity source, expect the following synchronization results for both LDAPv3 and Active Directory identity sources:
|User Status in Directory Server||User Status in Cloud Authentication Service||User Status Result After Next Synchronization|
|Disabled or expired||No existing records|| |
These users are not added to the Cloud Authentication Service.
|Disabled or expired||Enabled (from previous synchronization)||These users become disabled in the Cloud Authentication Service. You cannot manually re-enable them in the Cloud Authentication Service.|
|Enabled, disabled, or expired||Manually disabled||These users remain disabled after synchronization even if they are enabled in the directory server.|
|Re-enabled or no longer expired||Disabled through synchronization||These users automatically become re-enabled in the Cloud Authentication Service.|
|Re-enabled or no longer expired||Disabled through synchronization, then Pending Deletion||These users automatically become re-enabled in the Cloud Authentication Service (no longer pending deletion).|
|Missing (users who were deleted or are not in scope defined for the identity source)||Enabled, disabled, pending deletion||Users who were previously enabled are disabled in the Cloud Authentication Service. Users who were previously disabled or pending deletion (and disabled) remain in that state.|
The User Search Filter field determines which users get synchronized. If you synchronize immediately after adding the identity source, as recommended, then all users within the User Search Filter scope are added to the Cloud Authentication Service.
Note: You can modify the User Search Filter to narrow the scope after the initial synchronization. Users who are no longer within scope are not automatically removed from the Cloud Authentication Service the next time you synchronize. These users can still authenticate. You must manually delete these records from the Cloud Authentication Service to disable authentication.
RSA SecurID Access synchronizes a limited subset of user attributes from your directory server to identity sources and uses these attributes for different purposes, depending on which product components are included in your deployment.
|Deployment Components||Synchronized Attributes and Usage|
|SSO Agent||Identity source attributes are required to validate users for authentication and device registration. For a list of synchronized attributes, see Directory Server Attributes Synchronized for Authentication. User passwords are not synchronized.|
Relying parties, RADIUS clients, and MyPage
RSA SecurID Access synchronizes the same attributes as it does in an SSO Agent deployment to obtain attributes for authentication and device registration.
In addition, you must configure a separate list of attributes to identify the target user population in access policies (not required if you use the policy All Authenticated Users). You select these attributes when you add an identity source, in the Policies column on the User Attributes page. Synchronization makes the selected user attributes available to access policies during authentication. If synchronization is disabled and access policies require LDAP attributes to select the target population, users cannot successfully authenticate. Without synchronization, only policies that allow all authenticated users allow successful authentication.
For more information on making identity source attributes available to access policies, see Access Policies.
Three methods are available for synchronizing your LDAP directory servers with the Cloud Authentication Service:
The following sections describe each method.
Just-in-time synchronization ensures that the identity source in the Cloud Authentication Service is updated every time a user attempts to perform one of the following actions:
Register a device using the RSA SecurID Authenticate app.
Access a protected resource using additional authentication after the LDAP password is validated.
When just-in-time synchronization is enabled, you never need to add user records through manual or scheduled synchronization. Enablement affects all identity sources in the Cloud Authentication Service deployment.
Note: For a variety of reasons, the Cloud Authentication Service might not always be able to obtain the most current information about a user from the LDAP directory server. For example, the identity source connection may be down, or the user may have been deleted from the LDAP diretory server, or the search filter may no longer include that user within its scope. In these cases, the Cloud Authentication Service uses the information that was synchronized most recently. Consequently, a user whose record has been deleted from LDAP directory can still authenticate. You must manually delete the user from the Cloud Authentication Service to prevent authentication.
You can manually request immediate synchronization at any time for an identity source. This method is recommended after you add an identity source, to initially load users to the Cloud Authentication Service. For instructions, see Manually Synchronize an Identity Source for the Cloud Authentication Service.
You can add a schedule to automatically synchronize an identity source on selected days, weeks, or months. This feature ensures that an identity source is updated automatically, on a regular basis, without human intervention. You can edit, enable, or disable the schedule as needed. You can configure a schedule separately for each identity source. For instructions, see Schedule Identity Source Synchronization for the Cloud Authentication Service.
A Super Admin or Help Desk Admin can synchronize a single user by clicking Synchronize on the User Management page for the user.
Users can use SMS Tokencode or Voice Tokencode if each method meets the following criteria:
- RSA has enabled the method for your company.
- Users' required identity source information is synchronized with the Cloud Authentication Service (similar to other authentication methods).
- Phone numbers for these methods are stored for the user in the Cloud Authentication Service. Phone numbers can be synchronized from the LDAP directory server or entered manually by the administrator.
You configure SMS Tokencode and Voice Tokencode separately. You are not required to make both methods available to users.
Phone Number Attributes
If you want phone numbers to be synchronized from the identity source, you must enter an LDAP attribute for the SMS and Voice phone numbers in the identity source configuration. If the phone number format for that attribute changes in the LDAP directory server, the format is also changed in the Cloud Authentication Service, but the actual phone number remains the same.
If you do not configure an attribute and SMS Tokencode or Voice Tokencode is required for authentication, you must manually enter phone numbers for users on the Users > Management page.
If the Cloud Authentication Service has multiple phone numbers for a user for either SMS Tokencode or Voice Tokencode, the first number in the list for each method is used as the default number for that method. You can use the Cloud Administration Console to select a different phone number to use for authentication.
Overwriting Phone Numbers During Synchronization
During synchronization, all user information is updated in the cloud identity source. The following information applies only to the users' assigned SMS Tokencode and Voice Tokencode phone numbers that are maintained on the Users > Management page.
If you configure a phone number attribute for SMS or Voice, users' assigned phone numbers are overwritten in the cloud identity source during synchronization when both of the following are true:
The phone number was not manually modified for the user on the Users > Management page in the Cloud Administration Console.
The phone number value has been changed on the LDAP directory server.
Users' assigned SMS and Voice phone numbers are not overwritten in the cloud identity source during synchronization if you manually entered or changed those phone numbers on the Users > Management page. For example:
You manually modify a synchronized phone number, including by changing the country code.
You manually enter the phone number when no LDAP phone number attribute is configured in RSA SecurID Access. The phone number is not overwritten even if you add the LDAP attribute at a later date.
You manually delete an existing phone number (that was either manually-entered or synchronized) and did not manually enter a new number, leaving the field value blank.
Note: The LDAP directory server determines the phone number format. If you modify the phone number format on the Users > Management page after synchronization, the next synchronization overwrites your changes. For example, if the LDAP directory server synchronizes the phone number +1 555-5555 and you change the format on the Users > Management page to +1 555.5555, the next synchronization will replace your change with +1 555-5555.
RSA SecurID Access evaluates the user's account expiration date and enabled/disabled status in the Cloud Authentication Service only during synchronization. As a result, a user with an expired or disabled account in the LDAP directory server can successfully authenticate to the Cloud Authentication Service if the Cloud Authentication Service is not handling primary authentication and the identity source was not synchronized after the account expired or became disabled.
For example, suppose a user's account expires on February 10, 2018, the account is scheduled to be synchronized on February 13, 2018, and primary authentication is not required to access the resource. The expired user can access the resource on February 11 and 12 before the synchronization takes place. The Cloud Authentication Service only knows the user is expired after the user is synchronized.
Just-in-time synchronization prevents unauthorized access under these circumstances because when the expired or disabled user tries to authenticate, the account is synchronized and the user automatically becomes disabled in the Cloud Authentication Service.
Note: If the identity router does not respond to the authentication request within five seconds, the user's account in the Cloud Authentication Service is not updated in time and the expired or disabled user is granted access. However, for subsequent authentications, the user's account will be correctly updated in the Cloud Authentication Service and the user will be denied access.
User records that are synchronized to the Cloud Authentication Service and then subsequently deleted from the directory server are not automatically deleted from the Cloud Authentication Service. These users cannot register a device or use the directory server password to authenticate. Until these users are disabled in the Cloud Authentication Service, they can still use authentication methods that do not require an LDAP password, for example, SMS tokencode. After you manually delete these users' records from the Cloud Authentication Service or delete the identity source containing these users, the users will no longer be able to access resources through the Cloud Authentication Service using any method.
When you add an identity source to a deployment that uses the SSO Agent, you can enable users to change their LDAP passwords using the application portal. To use this feature, you must provide directory server administrative credentials that have read and write permissions, and the identity source must be configured to use SSL connections.
We want your feedback! Tell us what you think of this page.