Microsoft Dynamics CRM Authentication (On-premises)

Microsoft Dynamics CRM Authentication (On-premises)

If you have any doubt in the post please post comments. I will try to solve your problem.

Have you ever wondered how you are authenticating to your CRM application? It is useful to think about this because it:

1. Helps you troubleshoot when there are security-related issues.
   
2. Reinforces your understanding of your network infrastructure.
   

We will be taking a look at Windows authentication, claims-based authentication for internal access, and claims-based authentication for external access.
Windows authentication
Windows authentication is available to clients who want to authenticate using Kerberos or NT LAN Manager (NTLM). It is used in an intranet setting where all users are members of your Active Directory (AD) domain. When a client tries to log into the CRM website anonymously, they receive a 401 error. They get redirected to AD where their Windows (logon) credentials are compared to an existing account. AD then grants them a Kerberos ticket which they use to authenticate into the site. CRM accepts the ticket and pushes content to the client.

Source: Microsoft
Claims-based authentication: internal access
This authentication method is used in a multiple domain environment where there is no trust between domains, or where users exist in a different attribute store; users are authenticated internally. When an anonymous request is sent to the CRM server, it is rejected with a 302 error and the client is redirected to the Active Directory Federation Services (AD FS) login page. By logging in, they send a request for a security token. If they do not already have a valid Kerberos ticket on the network, they receive a 401 error. Otherwise, the Kerberos ticket is used in this step and the client automatically receives the security token to use on the CRM server. In the event that they do not have a Kerberos ticket, the client sends their logon credentials to Active Directory and supplies that Kerberos ticket to AD FS. The security token is then issued to the client which is then used against the CRM server. The CRM server authenticates the client and receives content.

Source: Microsoft
Claims-based authentication: external access
Accessing the CRM website through the internet using Internet-facing deployment (IFD) is now done with claims-based authentication. Both of the claims-based authentication methods are largely the same. The main difference between internal vs. external access is that Kerberos tickets are not used in external authentication. When a user navigates to the CRM website, they are redirected to AD FS and prompted to login. If there exists more than one trusted claims provider in AD FS (Active Directory is the only claims provider by default), the user will select a claims provider. Users then login and the credentials are validated by AD FS.

Source: Microsoft
A multiple server environment is recommended for a CRM server deployment. Although small businesses with a limited number of users can house AD FS and CRM on the same server, it is recommended to have AD FS and CRM on separate servers.