How to map real-world identity sources and directory servers to your RSA SecurID Access Cloud Authentication Service configuration

[#1]

Article Number

000036503

Applies To

RSA Product Set: SecurID Access
RSA Product/Service Type: Cloud Authentication Service, Identity Router (IDR)

Issue

An identity source in the RSA Cloud Authentication Service configuration represents a single Microsoft Active Directory (AD) or an Lightweight Directory Access Protocol (LDAP) directory service, storing user identities and their associated attributes. 

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

 

Task

Instructions to configure a new Identity Sources and its directory servers, are in the Online Help page Add an Identity Source for the Cloud Authentication Service .

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.