Claims-based authentication: internal access
If you have a multiple domain environment where trust does not exist between the domains, or where some users exist in a different attribute store such as a partner organization, you can use claims-based authentication to handle internal user authentication.
Claims authentication flows as follows:
.png "Claims authentication internal access flow")
The client sends a request to access the Microsoft Dynamics CRM website.
IIS refuses the connection with an HTTP 302 error message and redirects the user to the trusted claims provider (also known as the STS) for Microsoft Dynamics CRM (AD FS 2.0).
The client sends a request for a security token to AD FS 2.0.
AD FS 2.0 returns an HTTP 401.1 error, indicating that the client must supply a Kerberos ticket.
The client sends a Kerberos authentication request to Active Directory.
Active Directory validates the client and sends a Kerberos ticket.
The client sends a request for a security token to AD FS 2.0 and includes the Kerberos ticket.
Note
If the client already has a valid Kerberos ticket on the network, this ticket is sent to AD FS 2.0 in step 3 and steps 4 through 7 are skipped.
AD FS 2.0 provides a security token containing claims for access to Microsoft Dynamics CRM data.
The client sends the security token containing claims obtained from AD FS 2.0 to the Microsoft Dynamics CRM server.
The Microsoft Dynamics CRM server decrypts and validates the security token and presents the user with the requested information.
Important
Microsoft Dynamics CRM security roles and profiles are respected. The security token containing claims only replaces the Kerberos ticket used with Windows Authentication.