locked
NTLM authentication, Claim authentication and window authentication RRS feed

  • Question

  • Hi All,

    i am confused with NTLM authentication, Claim authentication and window authentication. Which authentication do SharePoint use in default configuration? Is window authentication and NTLM authentication same? How to implement the claim authentication in SharePoint? Could anyone please help me on this?

    Regards Amit 


    Monday, May 14, 2012 5:41 AM

Answers

  • Hi Amit,

    Not exactly, actually Microsoft SharePoint Services 3.0, MOSS, and SharePoint Foundation supports security for user access at the Web site, list, library folder, and item levels2. This security is managed based on role based mechanisms where each user is able to perform specific operation and all levels based on his/her role, and this is achieved through Authorization process once the user is successfully authenticated by the underlying authentication mechanism.

    Please go through the steps how sharepoint authentication works in background with all scenarios. Little bit detailed but good to known.

    How Windows Authentication works in Background, In SharePoint Site.

    1. A client sends a request using browser that initiates a connection to a SharePoint front-end server, which is handled by IIS with .NET through an HTTP GET request.
    2. If the zone is configured for anonymous access (such as for Internet scenarios), IIS continues to process the request. Otherwise, IIS returns error 401.2 and requests authentication from the client browser.
    3. The client browser receives the request and, depending on the zone and associated options, authenticates the client. A common method is by prompting for a username/password, and then passing an auth token back to SharePoint via IIS.
    4. IIS is waiting for a response in the HTTP conversation and accepts the auth token, and then either authorizes or denies access. At this point, IIS passes the request to SharePoint through
    5. At this point, IIS passes the request to SharePoint through .NET.
    6. If the requested page has a Web Part that needs to access the back-end SQL databases, SharePoint authenticates with the SQL Server and accesses the databases.
    7. The nature of the SQL authentication varies with the configuration options. For example, you can configure SQL Server authentication or Integrated Windows authentication using NTLM or Kerberos.

    How Authentication works in NTLM mode of Authentication

    1. A client sends a request using browser that initiates a connection to a SharePoint front-end server, which is handled by IIS with .NET through an HTTP GET request.
    2. If the zone is configured for anonymous access (such as for Internet scenarios), IIS continues to process the request. Otherwise, IIS returns error 401.2 and requests authentication from the client browser.
    3. The client browser receives the request and, depending on the zone and associated options, authenticates the client. A common method is by prompting for a username/password, and then passing an auth token back to SharePoint via IIS.
    4. IIS rejects the anonymous request with a 401 error and send back a request to authenticate with NTLM
    5. The client browser receives the request, creates the Authentication token that includes domain and computer name, and then sends the authentication token to IIS.
    6. IIS accepts the details and sends an NTLM challenge to the client.  The client responds with the response to the challenge (auth token again), encrypted with the password of the user.
    7. At this point, IIS needs to talk to the domain controller. It sends the client’s user name, challenge, and challenge response.
    8. The domain controller retrieves the password hash for the user and compares t to the challenge response, which was encrypted using the user’s credentials. If there’s a match, the domain controller returns a successful authentication to IIS, and IIS can talk to the client browser.

    How Authentication works in Kerberos mode of Authentication

    1. In case, where Kerberos mode (Kerberos uses a ticket system that authenticates once and then authorizes through delegation) of authentication is configured then Step 3 and 4 would be as follows
    2. A client sends a request using browser that initiates a connection to a SharePoint front-end server, which is handled by IIS with .NET through an HTTP GET request.
    3. If the zone is configured for anonymous access (such as for Internet scenarios), IIS continues to process the request. Otherwise, IIS returns error 401.2 and requests authentication from the client browser.
    4. The client browser receives the request and, depending on the zone and associated options, authenticates the client. A common method is by prompting for a username/password, and then passing an auth token back to SharePoint via IIS.
    5. The client contacts the KDC (Key distribution center) on the domain controller and requests a ticket for the SPN (service principal name) based on what the browser client sent as the hostname.
    6. If the KDC locates a matching SPN, it encrypts the ticket and returns it.
    7. The browser client creates the authenticator and sends it with the service ticket to the IIS server, which in turn decrypts the ticket, determines identity, and checks the permissions (access control list) on the requested resource to see if access is permitted.
    8. If access is permitted, IIS, through the Web Application service, contacts the SQL Server and the service requests a ticket for the SQL Server from the KDC.
    9. Generally, Windows based Authentication mode is selected whenever your application is running on windows, where Active directory is already configured, this is the easiest way of authenticating in SharePoint.

    How Authentication works in Anonymous Access

    Anonymous Access is a way of providing unregistered users to interact with SharePoint sites. For internal deployments and Intranet sites Anonymous Access is always discouraged. The possible scenario in which anonymous authentication should be considered is on public-facing websites – so that people can browse sites without having to create accounts. Anonymous access does not provide item-level control, prevents document authoring, and does not provide access to remote interfaces.

    How Authentication works in Form Based Authentication in SharePoint

    The Forms-based authentication option is generally selected when an environment does not use Active Directory, or needs to support external access. Form based Authentication basically builds on top of ASP.Net 2.0 Membership concepts, where there is Member Ship Provider which defines interfaces for identifying and authenticating individual users, and a Role Manager, which defines interfaces for grouping individual users into logical groups or roles4. The authentication is authorization is done by redirecting to custom pages developed in asp.net using login controls and/or custom controls and after getting user credentials a user identity object is created which is used to authenticate users based on their roles against custom data base (SQL) or Active directory users.

    Wednesday, May 16, 2012 9:52 AM
  • Hi Amit,

    Both the Kerberos protocol and NTLM are Integrated Windows authentication methods, which let users seamlessly authenticate without being prompted for credentials. Users who access SharePoint sites from Internet Explorer will authenticate by using the credentials the Internet Explorer process is running under. By default, these credentials are the credentials that the user used to log on to the computer. Services or applications that access SharePoint Server resources by using Integrated Windows authentication methods will attempt to authenticate by using the credentials of the running thread, which by default is the identity of the process.

    NTLM is the simplest form of Windows authentication to implement. Simply select this option when you are creating a Web application.

    Kerberos is a secure protocol that supports ticketing authentication. Use of the Kerberos protocol requires additional configuration of the environment. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). Configuring the Kerberos protocol involves setting up service principal names (SPNs) in AD DS before you install SharePoint Server 2010.

    The following steps summarize the process of configuring Kerberos authentication:

    1. Configure Kerberos authentication for SQL Server communications by creating SPNs in AD DS for the SQL Server service account.
    2. Create SPNs for Web applications that will use Kerberos authentication.
    3. Install the SharePoint Server 2010 farm.
    4. Configure specific services within the farm to use specific accounts.
    5. Create the Web applications that will use Kerberos authentication.

    Forms-based authentication is an identity management system that is based on ASP.NET membership and role provider authentication. In SharePoint Server 2010, forms-based authentication is available only when you use claims-based authentication.

    Forms-based authentication can be used against credentials stored in AD DS, in a database such as a SQL Server database, or in an LDAP data store such as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE. Forms-based authentication enables user authentication based on validation of credential input from a logon form. Unauthenticated requests are redirected to a logon page, where the user must provide valid credentials and submit the form. If the request can be authenticated, the system issues a cookie that contains a key for reestablishing the identity for subsequent requests.

     SharePoint by default the standard IIS Windows authentication methods are supported.

    SharePoint 2010 has introduced claims-based authentication, which is built on Windows Identity Foundation (WIF), a set of .NET framework classes that implement authentication based on open standards including WS-Trust, WS-Federation, and uses SAML tokens for user identity.

    The important distinction of using claims for the authentication architecture is that SharePoint is no longer tied to a specific authentication strategy. When authentication is required, SharePoint delegates the authentication call to a Secure Token Service (STS) to authenticate the user and build a claims token.

    follow the below given link[ thread ] for step by steps creating the Claim based authentication in SP 2010.

    http://technet.microsoft.com/en-us/library/ee806886.aspx


    Krishana Kumar http://www.mosstechnet-kk.com


    Monday, May 14, 2012 6:32 AM

All replies

  • Hi Amit,

    Both the Kerberos protocol and NTLM are Integrated Windows authentication methods, which let users seamlessly authenticate without being prompted for credentials. Users who access SharePoint sites from Internet Explorer will authenticate by using the credentials the Internet Explorer process is running under. By default, these credentials are the credentials that the user used to log on to the computer. Services or applications that access SharePoint Server resources by using Integrated Windows authentication methods will attempt to authenticate by using the credentials of the running thread, which by default is the identity of the process.

    NTLM is the simplest form of Windows authentication to implement. Simply select this option when you are creating a Web application.

    Kerberos is a secure protocol that supports ticketing authentication. Use of the Kerberos protocol requires additional configuration of the environment. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). Configuring the Kerberos protocol involves setting up service principal names (SPNs) in AD DS before you install SharePoint Server 2010.

    The following steps summarize the process of configuring Kerberos authentication:

    1. Configure Kerberos authentication for SQL Server communications by creating SPNs in AD DS for the SQL Server service account.
    2. Create SPNs for Web applications that will use Kerberos authentication.
    3. Install the SharePoint Server 2010 farm.
    4. Configure specific services within the farm to use specific accounts.
    5. Create the Web applications that will use Kerberos authentication.

    Forms-based authentication is an identity management system that is based on ASP.NET membership and role provider authentication. In SharePoint Server 2010, forms-based authentication is available only when you use claims-based authentication.

    Forms-based authentication can be used against credentials stored in AD DS, in a database such as a SQL Server database, or in an LDAP data store such as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE. Forms-based authentication enables user authentication based on validation of credential input from a logon form. Unauthenticated requests are redirected to a logon page, where the user must provide valid credentials and submit the form. If the request can be authenticated, the system issues a cookie that contains a key for reestablishing the identity for subsequent requests.

     SharePoint by default the standard IIS Windows authentication methods are supported.

    SharePoint 2010 has introduced claims-based authentication, which is built on Windows Identity Foundation (WIF), a set of .NET framework classes that implement authentication based on open standards including WS-Trust, WS-Federation, and uses SAML tokens for user identity.

    The important distinction of using claims for the authentication architecture is that SharePoint is no longer tied to a specific authentication strategy. When authentication is required, SharePoint delegates the authentication call to a Secure Token Service (STS) to authenticate the user and build a claims token.

    follow the below given link[ thread ] for step by steps creating the Claim based authentication in SP 2010.

    http://technet.microsoft.com/en-us/library/ee806886.aspx


    Krishana Kumar http://www.mosstechnet-kk.com


    Monday, May 14, 2012 6:32 AM
  • Hi Krishana,

    It means that it doesn’t matter what the authentication is being used, SharePoint always do use the Claim authentication in background? It is to make the SharePoint independent of the authentication. Am I correct?

    Regards Amit


    Monday, May 14, 2012 7:13 AM
  • Hi Amit,

    Not exactly, actually Microsoft SharePoint Services 3.0, MOSS, and SharePoint Foundation supports security for user access at the Web site, list, library folder, and item levels2. This security is managed based on role based mechanisms where each user is able to perform specific operation and all levels based on his/her role, and this is achieved through Authorization process once the user is successfully authenticated by the underlying authentication mechanism.

    Please go through the steps how sharepoint authentication works in background with all scenarios. Little bit detailed but good to known.

    How Windows Authentication works in Background, In SharePoint Site.

    1. A client sends a request using browser that initiates a connection to a SharePoint front-end server, which is handled by IIS with .NET through an HTTP GET request.
    2. If the zone is configured for anonymous access (such as for Internet scenarios), IIS continues to process the request. Otherwise, IIS returns error 401.2 and requests authentication from the client browser.
    3. The client browser receives the request and, depending on the zone and associated options, authenticates the client. A common method is by prompting for a username/password, and then passing an auth token back to SharePoint via IIS.
    4. IIS is waiting for a response in the HTTP conversation and accepts the auth token, and then either authorizes or denies access. At this point, IIS passes the request to SharePoint through
    5. At this point, IIS passes the request to SharePoint through .NET.
    6. If the requested page has a Web Part that needs to access the back-end SQL databases, SharePoint authenticates with the SQL Server and accesses the databases.
    7. The nature of the SQL authentication varies with the configuration options. For example, you can configure SQL Server authentication or Integrated Windows authentication using NTLM or Kerberos.

    How Authentication works in NTLM mode of Authentication

    1. A client sends a request using browser that initiates a connection to a SharePoint front-end server, which is handled by IIS with .NET through an HTTP GET request.
    2. If the zone is configured for anonymous access (such as for Internet scenarios), IIS continues to process the request. Otherwise, IIS returns error 401.2 and requests authentication from the client browser.
    3. The client browser receives the request and, depending on the zone and associated options, authenticates the client. A common method is by prompting for a username/password, and then passing an auth token back to SharePoint via IIS.
    4. IIS rejects the anonymous request with a 401 error and send back a request to authenticate with NTLM
    5. The client browser receives the request, creates the Authentication token that includes domain and computer name, and then sends the authentication token to IIS.
    6. IIS accepts the details and sends an NTLM challenge to the client.  The client responds with the response to the challenge (auth token again), encrypted with the password of the user.
    7. At this point, IIS needs to talk to the domain controller. It sends the client’s user name, challenge, and challenge response.
    8. The domain controller retrieves the password hash for the user and compares t to the challenge response, which was encrypted using the user’s credentials. If there’s a match, the domain controller returns a successful authentication to IIS, and IIS can talk to the client browser.

    How Authentication works in Kerberos mode of Authentication

    1. In case, where Kerberos mode (Kerberos uses a ticket system that authenticates once and then authorizes through delegation) of authentication is configured then Step 3 and 4 would be as follows
    2. A client sends a request using browser that initiates a connection to a SharePoint front-end server, which is handled by IIS with .NET through an HTTP GET request.
    3. If the zone is configured for anonymous access (such as for Internet scenarios), IIS continues to process the request. Otherwise, IIS returns error 401.2 and requests authentication from the client browser.
    4. The client browser receives the request and, depending on the zone and associated options, authenticates the client. A common method is by prompting for a username/password, and then passing an auth token back to SharePoint via IIS.
    5. The client contacts the KDC (Key distribution center) on the domain controller and requests a ticket for the SPN (service principal name) based on what the browser client sent as the hostname.
    6. If the KDC locates a matching SPN, it encrypts the ticket and returns it.
    7. The browser client creates the authenticator and sends it with the service ticket to the IIS server, which in turn decrypts the ticket, determines identity, and checks the permissions (access control list) on the requested resource to see if access is permitted.
    8. If access is permitted, IIS, through the Web Application service, contacts the SQL Server and the service requests a ticket for the SQL Server from the KDC.
    9. Generally, Windows based Authentication mode is selected whenever your application is running on windows, where Active directory is already configured, this is the easiest way of authenticating in SharePoint.

    How Authentication works in Anonymous Access

    Anonymous Access is a way of providing unregistered users to interact with SharePoint sites. For internal deployments and Intranet sites Anonymous Access is always discouraged. The possible scenario in which anonymous authentication should be considered is on public-facing websites – so that people can browse sites without having to create accounts. Anonymous access does not provide item-level control, prevents document authoring, and does not provide access to remote interfaces.

    How Authentication works in Form Based Authentication in SharePoint

    The Forms-based authentication option is generally selected when an environment does not use Active Directory, or needs to support external access. Form based Authentication basically builds on top of ASP.Net 2.0 Membership concepts, where there is Member Ship Provider which defines interfaces for identifying and authenticating individual users, and a Role Manager, which defines interfaces for grouping individual users into logical groups or roles4. The authentication is authorization is done by redirecting to custom pages developed in asp.net using login controls and/or custom controls and after getting user credentials a user identity object is created which is used to authenticate users based on their roles against custom data base (SQL) or Active directory users.

    Wednesday, May 16, 2012 9:52 AM