How to map real-world identity sources and directory servers to your RSA SecurID Access Cloud Authentication Service configuration
Originally Published: 2018-07-03
Article Number
Applies To
RSA Product/Service Type: Cloud Authentication Service, Identity Router (IDR)
Issue
Each directory service will physically consist of one or more directory servers (a primary directory server, and its replicas).
This KB article explains how a directory service and its real-world directory servers should be mapped into an RSA Cloud Authentication Service identity source configuration.
For more information about identity sources, see:
- Identity Sources for the Cloud Authentication Service
- RSA SecurID Access Cloud Authentication Service Planning Guide
Tasks
Resolution
LDAP and AD Identity Sources with Multiple Directory Servers
Each Identity Source configured in the RSA Cloud Administration Console must represent one primary LDAP or AD directory server and its replicas. Consequently, the set of user identity objects on all directory servers configured for an Identity Source, must be the same.If you have a completely different set of end users on some directory servers, then that set of directory servers should be configured as a different/additional Identity Source in the RSA Cloud Administration Console. Policies also must be configured to indicate which Identity Source(s) each policy applies to.
When end users authenticate with the Cloud Authentication Service, an authentication request will be sent to only one RSA Identity Router (IDR). If you have more than one active IDR, the actual IDR that receives the request will depend on how the IDRs are load balanced. Whichever IDR receives an end user's authentication request must be able to access a directory server that has that end user's identity object, so that the IDR can confirm the user's credentials. This implies that every IDR must be able to access at least one directory server for every Identity Source configured in your RSA Cloud Authentication Service.
If an IDR cannot access a directory server that has the user's object, the authentication attempt will fail. This is because authentication requests are not forwarded onto other IDRs in the hope that one of them can get to a directory server with that user's object. So, if the directory server with the end user's identity object is not accessible on the same subnet as the IDR, then you need to make sure that network connections, firewalls, DNS, etc. will allow the IDR to access the directory server across the wider network.
Additional Microsoft Active Directory Considerations
If you have a multidomain forest, it is technically possible to use a Global Catalog (GC) as a directory server with all user objects in all domains in the forest. However, there are two main caveats:- A GC has readonly access to the domains, so users can't do password changes via the RSA Cloud Authentication Service.
- A GC has only a partial representation of each user object. Not all attributes are present. You need to adjust the GC configuration to make sure it has all the attributes that the Cloud Authentication Service needs to synchronize from the Identity Source. For information about attributes that are synchronized, see section "User Attributes Synchronized" on page Identity Sources for the Cloud Authentication Service and also Directory Server Attributes Synchronized for Authentication. If you synchronize additional attributes, these must be made available in the GC also, if they are not there by default. See the Microsoft Active Directory documentation for the default set of attributes that are available in a GC, for your Windows Server version.
Identity Source Errors during Authentication
When "internal error" is logged for an authentication attempt, the Cloud is likely reporting a failure finding the user. If it was a genuine user, then this type of error is usually an Identity Source configuration error. If the Identity Source configuration does not meet some aspect of the requirements, users will not be synchronized correctly.When synchronizing, the Identity Source will be accessed from the Cloud via any one of the active IDRs. If all user objects in an Identity Source are not available in every directory server defined for that Identity Source, or are defined differently in some directory servers, then inconsistencies related to synchronization will occur. Or if every Identity Source is not available via every IDR, then there will be synchronization inconsistencies. Such inconsistencies can lead to authentication issues which can be intermittent, depending on the nature of the problem, which IDR is used for authentication and which directory server is available to that IDR.
Related Articles
Account summary table export includes the HTML tags that construct the account mapping button in RSA Identity Governance &… Number of Views Link an Identity Source to the System Number of Views Windows collection has stopped working but did work in the past. Number of Views Provisioning Node Mapping display changed in RSA Identity Governance & Lifecycle Number of Views Active Directory Global Catalog Identity Sources Number of Views
Trending Articles
RSA MFA Agent 2.3.6 for Microsoft Windows Installation and Administration Guide RSA Release Notes for RSA Authentication Manager 8.8 Deploying RSA Authenticator 6.2.2 for Windows Using DISM RSA Authentication Manager 8.9 Release Notes (January 2026) Supported On-Demand Authentication (ODA) SMS providers for use with RSA Authentication Manager 8.x
Don't see what you're looking for?
