Authentication :
Authentication is the process of validating a user’s identity. After a user’s identity is validated, the authorization process determines which sites, content, and other features the user can access
In Office SharePoint Server 2007, the authentication process is managed by Internet Information Services (IIS). After IIS performs authentication of users, the security features in Office SharePoint Server 2007 perform the authorization process.
Following Authentication method are available:
| Authentication method |
Description |
Examples |
| Windows |
The standard IIS Windows authentication methods are supported. |
- Anonymous
- Basic
- Digest
- Certificates
- Kerberos (Integrated Windows)
- NTLM (Integrated Windows)
|
| ASP.NET forms |
Office SharePoint Server 2007 adds support for identity management systems that are not based on Windows by integrating with the ASP.NET forms authentication system. ASP.NET authentication enables Office SharePoint Server 2007 to work with identity management systems that implement the Membership Provider interface. You do not need to rewrite the security administration pages or manage shadow Active Directory directory service accounts. |
- Lightweight Directory Access Protocol (LDAP)
- SQL database or other database
- Other ASP.NET-based forms authentication solutions
|
| Web Single Sign-On (SSO) |
Office SharePoint Server 2007 supports federated authentication through Web SSO vendors. Web SSO enables SSO in environments that include services running on disparate platforms. You do not need to manage separate Active Directory accounts. |
- Active Directory Federation Services (AD FS)
- Other identity management systems
|
Anonymous Authentication :
Anonymous authentication gives users access to the public areas of your Web or FTP site without prompting them for a user name or password. By default, the IUSR_computername account is used to allow anonymous access.
In IIS 6.0, anonymous authentication no longer requires the Allow log on locally user right, because NETWORK_CLEARTEXT is now the default logon type for anonymous and basic authentication.
During setup, the IUSR_computername account is added to the Guests group on the computer running IIS. Guests have the same access as members of the Users group by default, except for the Guest account, which is further restricted.
IIS and Built-in Accounts (IIS 6.0)
IIS uses a number of built-in Windows accounts, as well as accounts that are specific to IIS. For security reasons, you should be aware of the different accounts and their default user privileges. It can be a security risk to change the identity of a worker process so that it runs as an account with a high level of access, such as the LocalSystem user account.
IUSR_ComputerName
The IIS IUSR_ComputerName user account is for anonymous access to IIS. By default, when a user accesses a Web site that uses Anonymous authentication, that user is mapped to the IUSR_ComputerName account. The following table shows the default user privileges for the IUSR_ComputerName account, along with how each privilege is derived.
Basic Authentication
Basic authentication is a widely-used method of collecting user name and password information. Basic authentication sends and receives user information as text characters that can be read. Although passwords and user names are encoded, no encryption is used with Basic authentication. The following steps outline how a client is authenticated by using Basic authentication:
- The user is prompted to enter a Windows account user name and password.
- Forefront TMG receives the HTTP request with the credentials and validates the credentials against the specified authentication server (RADIUS or Active Directory, LDAP server for incoming requests only).
- For outbound Web proxy requests, Forefront TMG validates credentials and then evaluates access rules. For incoming requests, Forefront TMG uses the credentials to authenticate to the published Web server, according to the configured delegation method. The Web server must be configured to use the authentication scheme that matches the delegation method used by Forefront TMG. The plaintext password is Base64-encoded before it is sent over the network, but this is not encryption, and if the password is intercepted over the network by a network sniffer, unauthorized users can decode and reuse the password.
The advantage of Basic authentication is that it us supported by almost all HTTP clients. The disadvantage is that Web browsers using Basic authentication transmit passwords in an unencrypted form. By monitoring communications on your network, an attacker or malicious user can intercept and decode these passwords by using publicly available tools. Therefore, Basic authentication is not recommended unless you are confident that the connection is secure, such as with a dedicated line or an SSL connection.
Digest and WDigest authentication
Digest authentication offers the same features as Basic authentication but has a more secure way of transmitting the authentication credentials.
Digest authentication relies on the HTTP 1.1 protocol as defined in RFC 2617. This is not supported by all browsers. If a non-HTTP 1.1 compliant browser requests a file when Digest authentication is enabled, the request is rejected. Digest authentication can be used only in Windows domains.
Digest authentication is successful only if the domain controller has a reversibly encrypted (plaintext) copy of the requesting user’s password stored in Active Directory. To allow passwords to be stored in plaintext, you need to activate the Store password using the reversible encryption setting on the Account tab of the user in Active Directory. Alternatively, you can set group policy to enable this capability. After making this setting, you need to set a new password in order to activate this feature because the old password cannot be determined.
WDigest, a new form of Digest authentication, is used when Forefront TMG is installed in a Windows Server 2008 domain. WDigest does not have the requirement that a reversibly encrypted copy of the user password is stored in Active Directory.
Digest and WDigest authentication work as follows:
- The client makes a request.
- Forefront TMG denies the request and prompts the client to enter a Windows account user name and password. Note that when you use WDigest, the user name and domain name are case-sensitive and must be written exactly as they appear in Active Directory. In addition, WDigest requires a value in the resource part of the URL path. For example, the user request http://host.domain.tld fails because the URL resource is missing.
- Authentication credentials pass through a one-way process known as hashing. The result is an encrypted hash or message digest. Values are added to identify the user, the user’s computer and domain. A time stamp is added to prevent a user from using a password after it has been revoked. This is a clear advantage over Basic authentication because it makes it more difficult for an unauthorized person to intercept or use the password.
Client Certificate Authentication
Client certificate authentication is not supported for authenticating outbound Web requests. You can use a client certificate in order to authenticate Forefront TMG to an upstream proxy server. For more information, see About Web proxy chaining.
For incoming requests for published resources, requiring a client certificate can help increase the security of your published server. Users can obtain client certificates from a commercial certification authority (CA) or from an internal CA in your organization. A certificate may also be one that is embedded in a smart card, or a certificate that is used by a mobile device so that it can connect to Microsoft ActiveSync.
The certificate must be matched to a user account. When users make a request for published resources, the client certificate sent to Forefront TMG is passed to a domain controller, which determines the mapping between certificates and accounts. Forefront TMG must be a domain member. The information is passed back to Forefront TMG for application of relevant firewall policy rules. Note that Forefront TMG cannot pass client certificates to an internal Web server.
Kerberos
The Kerberos version 5 authentication protocol provides a mechanism for authentication — and mutual authentication — between a client and a server, or between one server and another server.
The Kerberos Key Distribution Center (KDC) uses the domain’s Active Directory directory service database as its security account database. Active Directory is required for default NTLM and Kerberos implementations.
The Kerberos V5 protocol specifies mechanisms to:
- Authenticate user identity. When a user wants to gain access to a server, the server needs to verify the user’s identity. Consider a situation in which the user claims to be, for example, Alice@tailspintoys.com. Because access to resources are based on identity and associated permissions, the server must be sure the user really has the identity it claims.
- Securely package the user’s name. The user’s name — that is, the User Principal Name (UPN): Alice@tailspintoys.com, for example — and the user’s credentials are packaged in a data structure called a ticket.
- Securely deliver user credentials. After the ticket is encrypted, messages are used to transport user credentials along the network.
Note
- Although the Kerberos protocol authenticates the user’s identity, it does not authorize access. This is an important distinction. Tickets in other contexts, such as drivers’ licenses, often both prove identity and authorize actions or access. A Kerberos ticket only proves that the user is who the user claims to be. After the user’s identity is verified, the Local Security Authority will authorize or deny resource access.
NTLM
Abbreviation for “Windows NT LAN Manager”
Interactive NTLM authentication over a network typically involves two systems: a client system, where the user is requesting authentication, and a domain controller, where information related to the user’s password is kept. No interactive authentication, which may be required to permit an already logged-on user to access a resource such as a server application, typically involves three systems: a client, a server, and a domain controller that does the authentication calculations on behalf of the server.
The following steps present an outline of NTLM noninteractive authentication. The first step provides the user’s NTLM credentials and occurs only as part of the interactive authentication (logon) process.
- (Interactive authentication only) A user accesses a client computer and provides a domain name, user name, and password. The client computes a cryptographic hash of the password and discards the actual password.
- The client sends the user name to the server (in plaintext).
- The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.
- The client encrypts this challenge with the hash of the user’s password and returns the result to the server. This is called the response.
- The server sends the following three items to the domain controller:
- User name
- Challenge sent to the client
- Response received from the client
- The domain controller uses the user name to retrieve the hash of the user’s password from the Security Account Manager database. It uses this password hash to encrypt the challenge.
- The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.
Your application should not access the NTLM security package directly; instead, it should use the Negotiate security package. Negotiate allows your application to take advantage of more advanced security protocols if they are supported by the systems involved in the authentication. Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication.
Nilesh Rathod 