Windows Server Knowledge Base

Active Directory (AD):

Active Directory (AD) is a technology created by Microsoft to provide network services including LDAP directory services; Kerberos based authentication, DNS naming, secure access to resources, and more.


Lightweight Directory Access Protocol – an application protocol for querying and modifying directory services developed at the University of Michigan in the early 1990s. An LDAP directory tree is a hierarchical structure of organizations, domains, trees, groups, and individual units.


The domain is typically of the Internet naming variety (e.g., but you are not forced to stick with this structure – you could technically name your domain whatever you wish.

Domain Controllers

In Windows NT, domains used a Primary Domain Controller (PDC) and Backup Domain Controller (BDC) model. This had one server, the PDC, which was “in charge” while the other DCs where subservient. If the PDC failed, you had to promote a BDC to become the PDC and be the server in charge

In Active Directory, you have multiple Domain Controllers which are equal peers. Each DC in the Active Directory domain contains a copy of the AD database and synchronizes changes with all other DCs by multi-master replication. Replication occurs frequently and on a pull basis instead of a push one. A server requests updates from a fellow domain controller. If information on one DC changes (e.g. a user changes their password), it sends signal to the other domain controllers to begin a pull replication of the data to ensure they are all up to date.

Servers not serving as DCs, but in the Active Directory domain, are called ‘member servers.’

Active Directory requires at least one Domain Controller, but you can install as many as you want (and it’s recommended you install at least two domain controllers in case one fails).


Groups serve two functions in Active Directory: security and distribution.

A security group contains accounts which can be used for security access. For example, a security group could be assigned rights to a particular directory on a file server.

A distribution group is used for sending information to users. It cannot be used for security access.

There are three group scopes:

Global: Global scope security groups contains users only from the domain in which is created. Global security groups can be members of both Universal and Domain Local groups.

Universal: Universal scope security groups can contain users, global groups, and universal groups from any domain. These groups are typically used in a multi-domain environment if access is required across domains.

Domain Local: Domain Local scope groups are often created in domains to assign security access to a particular local domain resource. Domain Local scope groups can contain user accounts, universal groups, and global groups from any domain. Domain Local scope groups can contain domain local groups in the same domain.


An Active Directory site object represents a collection of IP subnets, usually constituting a physical Local Area Network (LAN). Multiple sites are connected for replication by site links. Typically, sites are used for:

Physical Location Determination: Enables clients to find local resources such as printers, shares, or domain controllers.


Active Directory is integrated with Domain Naming System (DNS) and requires it to be present to function. DNS is the naming system used for the Internet and on many Intranets. You can use DNS which is built into Windows 2000 and newer, or use a third party DNS infrastructure such as BIND if you have it in the environment. It is recommended you use Window’s DNS service as it is integrated into Windows and provides the easiest functionality.

AD uses DNS to name domains, computers, servers, and locate services.

A DNS server maps an object’s name to its IP address. For example, on the Internet, it is used to map a domain name (such as to an IP address (such as In an Active Directory network, it is used n
ot only to find domain names, but also objects and their IP address. It also uses service location records (SRV) to locate services.


SharePoint Authentication Method

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.


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:

  1. The user is prompted to enter a Windows account user name and password.
  2. 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).
  3. 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:

  1. The client makes a request.
  2. 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.
  3. 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.


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, 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):, 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.


  • 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.


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.

  1. (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.
  2. The client sends the user name to the server (in plaintext).
  3. The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.
  4. 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.
  5. The server sends the following three items to the domain controller:
    • User name
    • Challenge sent to the client
    • Response received from the client
  6. 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.
  7. 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.

Application Server and Web Server

Application Server and Web Server

A Web server serves pages for viewing in a Web browser, while an application server provides methods that client applications can call.

A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols.

The Web server

A Web server handles the HTTP protocol. When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page. To process a request, a Web server may respond with a static HTML page or image, send a redirect, or delegate the dynamic response generation to some other program such as CGI scripts, JSPs (JavaServer Pages), servlets, ASPs (Active Server Pages), server-side JavaScripts, or some other server-side technology. Whatever their purpose, such server-side programs generate a response, most often in HTML, for viewing in a Web browser.

Understand that a Web server’s delegation model is fairly simple. When a request comes into the Web server, the Web server simply passes the request to the program best able to handle it. The Web server doesn’t provide any functionality beyond simply providing an environment in which the server-side program can execute and pass back the generated responses. The server-side program usually provides for itself such functions as transaction processing, database connectivity, and messaging.

While a Web server may not itself support transactions or database connection pooling, it may employ various strategies for fault tolerance and scalability such as load balancing, caching, and clustering—features oftentimes erroneously assigned as features reserved only for application servers.

The Application server

As for the application server, according to our definition, an application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object (or a function in the procedural world).

Such application server clients can include GUIs (graphical user interface) running on a PC, a Web server, or even other application servers. The information traveling back and forth between an application server and its client is not restricted to simple display markup. Instead, the information is program logic. Since the logic takes the form of data and method calls and not static HTML, the client can employ the exposed business logic however it wants.

In most cases, the server exposes this business logic through a component API, such as the EJB (Enterprise JavaBean) component model found on J2EE (Java 2 Platform, Enterprise Edition) application servers. Moreover, the application server manages its own resources. Such gate-keeping duties include security, transaction processing, resource pooling, and messaging. Like a Web server, an application server may also employ various scalability and fault-tolerance techniques.

Friends I tale reference of following site for the above article

Ref Site: