How to map real-world identity sources and directory servers to your RSA SecurID Access Cloud Authentication Service configuration
Originally Published: 2018-07-03
Last Modified: 2022-06-20
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
How to configure RSA Validation Manager to obtain real-time certificate status from RSA Certificate Manager Number of Views Real Time Rules not seen in Admin UI and-or Mitigator is not running in RSA Web Threat Detection Number of Views How to determine real-time row counts of each table in the RSA Via Lifecycle & Governance AVUSER schema Number of Views Authentication using acetest fails TRANSACTION_ROLLBACK on real time authentication activity monitor for RSA Authenticatio… Number of Views Set Restricted Access Times for Trusted User Groups Number of Views
Trending Articles
How to Change the Token Lifetime Extension Window in Authentication Manager Using rsautil RSA Authentication Manager 8.9 Patches and Hotfixes Readme RSA Authentication Manager Upgrade Process RSA MFA Agent 2.5 for Microsoft Windows Installation and Administration Guide Troubleshooting RSA MFA Agent for Microsoft Windows
Don't see what you're looking for?
