Update Application Pool Password using PowerShell Script

By using below script we can update Passwod of Specific User for all his assigned Application Pool

PowerShell Script:

Import-Module WebAdministration
$applicationPools = Get-ChildItem IIS:\AppPools | where { $_.processModel.userName -eq "SPServer\administrator" }
 
foreach($pool in $applicationPools)
{
    $pool.processModel.userName = "SPServer\administrator"
    $pool.processModel.password = "sp#123@admin"
    $pool.processModel.identityType = 3
    $pool | Set-Item
}
 
Write-Host "Password Sucessfully Updated." -ForegroundColor Magenta 
Write-Host "" 

Active Directory Setup For SharePoint Development Environment

To configure Active Directory Domain Service on Windows Server follow below steps:

Navigate to Server Manager

Click On Add roles and features.

It will start Add Roles and Features Wizard.

Click on Next

Select Installation Type as shown in Image

Click on Next

Select Option as shown in Image

Click on Next

Select Active Directory Domain Service

When you click on it, it will prompt you to add features for Active Directory Domain Service

Click on Add Features

Now Active Directory Domain Service is checked or selected.

Click on Next

On Features Tab Click on Next

On AD DS tab click on Next

On Confirm Installation selection section click on Install.

Next step will show us Installation Progress

Once the installation succeeds click on Close

After Successful installation, you can see in Dashboard Notification Message to promote this server for a domain controller.

Click on it.

It will Start “Active Directory Domain Service Configuration Wizard”

Click on Add New Forest. Enter Root Domain name

Clock on Next

Enter Password and Confirm Password

Click on Next

It will show DNS Options

Click on Next

Additional Options will check Domain Name

Click on Next

Select Path

Click on Next

Review Option.Review Entered information

Click on Next

Check Prerequisites.Click On Install.It will start installation process.

Once installation is complete restart server.

 

 

How to create SharePoint Provider Hosted APP/Add-ins

In this post we are going to create SharePoint Provider Hosted Add-in.

Provider Hosted Apps are simply a SharePoint app where the code in your app runs in a space you provide. I am going to use ASP.Net Web Forms application as APP.

Steps to create Provider Hosted APP:

1. Create Developer Site Collection
2. Create and Export Certificate
3. Set up trusted security token
   1. Create Issuer ID
   2. Create Client ID
4. Create SharePoint Provider Hosted APP
5. CRUD Operation Using SharePoint Provide Hosted APP

Create Developer Site Collection

Navigate to SharePoint Central Administration and Create a Site collection with template Developer Site.

Once site is created, it will appear as per below image:

Create and Export Certificate

Now Next step is to establish trust. A trust is necessary due to the fact that the provider-hosted app is hosted outside SharePoint in a separate web application.

Primary requirement to establish Trust is having a Certificate. I have already created separate post regarding create and export process of Certificate you may check here.

Set up trusted security token

To establish Trust, first thing, we need to do is to get ISSUER ID.

Create GUID using Visual Studio which needs to be added in PowerShell Script.

GUID: e9fe114f-3406-400d-bd22-50f077a8f17f

Note that GUID must be in Lowercase.

Create Folder on location: “C:\output” which is going to store output file of PowerShell Scrip

Create Issuer ID

Open SharePoint Management Shell and Run Issuer ID Script

PowerShell Script for Issuer ID:

Add-PSSnapin "Microsoft.SharePoint.PowerShell"

$issuerID = "e9fe114f-3406-400d-bd22-50f077a8f17f"

$targetSiteUrl = "http://sqlserver:3333"

$targetSite = Get-SPSite $targetSiteUrl

$realm = Get-SPAuthenticationRealm -ServiceContext $targetSite

$registeredIssuerName = $issuerID + '@' + $realm

$publicCertificatePath = "C:\Certificate\NileshSPDemoCertificate.cer"

$publicCertificate = Get-PfxCertificate $publicCertificatePath

Write-Host "Create Security token issuer"

$secureTokenIssuer = New-SPTrustedSecurityTokenIssuer -Name $issuerID -RegisteredIssuerName $registeredIssuerName -Certificate $publicCertificate -IsTrustBroker

$secureTokenIssuer | select *

$secureTokenIssuer | select * | Out-File -FilePath "c:\output\SecureTokenIssuer.txt"

#Turn off the HTTPS requirement for OAuth during development

$serviceConfig = Get-SPSecurityTokenServiceConfig

$serviceConfig.AllowOAuthOverHttp = $true

$serviceConfig.Update()

Write-Host "All done..."

Create Client ID

Now Next Step is to Create Client ID by mapping into APP Principal

PowerShell Script for Client ID: fee415ed-6977-4c3c-b5d0-a06682719fb7

Add-PSSnapin "Microsoft.SharePoint.PowerShell"

# set intialization values for new app principal

$appDisplayName = "EMployeeManagement"

$clientID = "fee415ed-6977-4c3c-b5d0-a06682719fb7"

$targetSiteUrl = "http://sqlserver:3333"

$targetSite = Get-SPSite $targetSiteUrl

$realm = Get-SPAuthenticationRealm -ServiceContext $targetSite

$fullAppPrincipalIdentifier = $clientID + '@' + $realm

Write-Host "Registering new app principal"

$registeredAppPrincipal = Register-SPAppPrincipal -NameIdentifier $fullAppPrincipalIdentifier -Site $targetSite.RootWeb -DisplayName $AppDisplayName

$registeredAppPrincipal | select * | Format-List

$registeredAppPrincipal | select * | Format-List | Out-File -FilePath "c:\output\ClientID.txt"

Write-Host "Registration Completed"

#Get-SpAppPrincipal -?

Remember or note down Client ID as we need to enter in Application Configuration.

Once Issuer ID and Cline ID Created and configured to use Certificate next step is to create Provider Hosted APP.

Create SharePoint Provider Hosted APP

Open Visual Sudio and create a project of type SharePoint Add-in

Click OK

Select Developer Site and Select Provider-Hosted Add-in Type

Click Next

Select Target Version I am using SharePoint 2016. You may choose as per your environment.

Click Next

Select Project Type : Asp.Net Web Forms Application. Click Next.

Here you need to select Certificate which was exported and having PFX key.

Make sure that you enter correct password for certificate and Issuer Id (GUID which was generated and associated with certificate.). Click Finish.

It will create SharePoint Hosted APP as shown above image.

I have added single line in Default Page

AppManifest.xml file of APP is as below.

With AppManifest.xml We can change App Icon and Start Page.

I have changed APP Icon. Make Sure that Icon size is  96 x 96 pixels.

Click on AppManifest.xml and Navigate to View Code

You may find below code in AppManifest.xml

AppManifest.xml contains user rights permission on app to be run or executed. Also it contains client id.

To add user permission  navigate to AppManifest.xml ==>Permissions Tab. Give appropriate rights as per requirement .

Add Client ID in RemoteWebApplication tag.

Complete AppManifest.xml will look below image.

Code For AppManifest.xml:

<?xml version="1.0" encoding="utf-8" ?>
<!--Created:cb85b80c-f585-40ff-8bfc-12ff4d0e34a9-->
<App xmlns="http://schemas.microsoft.com/sharepoint/2012/app/manifest"
 Name="EmployeeManagementAPP"
 ProductID="{47f6010d-e511-42d7-8210-49ca99f1bfd7}"
 Version="1.0.0.0"
 SharePointMinVersion="16.0.0.0"
>
 <Properties>
 <Title>EmployeeManagementAPP</Title>
 <StartPage>~remoteAppUrl/Pages/Default.aspx?{StandardTokens}</StartPage>
 </Properties>

 <AppPrincipal>
 <RemoteWebApplication ClientId="fee415ed-6977-4c3c-b5d0-a06682719fb7" />
 </AppPrincipal>
 <AppPermissionRequests>
 <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web" Right="FullControl" />
 <AppPermissionRequest Scope="http://sharepoint/taxonomy" Right="Write" />
 <AppPermissionRequest Scope="http://sharepoint/content/sitecollection" Right="FullControl" />
 </AppPermissionRequests>
</App>

Now Navigate to EmployeeManagementAPPWeb’s Web.config file section

Add below code in appSettings section

<appSettings>
<add key="webpages:Version" value="3.0.0.0" />
<add key="webpages:Enabled" value="false" />
<add key="ClientValidationEnabled" value="true" />
<add key="UnobtrusiveJavaScriptEnabled" value="true" />
<add key="ClientId" value="fee415ed-6977-4c3c-b5d0-a06682719fb7" />
<add key="ClientSigningCertificatePath" value="C:\Certificate\Export\NileshSPDemoCertificateExported.pfx" />
<add key="ClientSigningCertificatePassword" value="admin@123" />
<add key="IssuerId" value="e9fe114f-3406-400d-bd22-50f077a8f17f" />
</appSettings>

Also add location section

<location path="FederationMetadata">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>

Web.config File Location Section

Web.Config File

<?xml version="1.0" encoding="utf-8"?>
<!--
For more information on how to configure your ASP.NET application, please visit
http://go.microsoft.com/fwlink/?LinkId=169433
-->
<configuration>
<location path="FederationMetadata">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<system.web>
<compilation debug="true" targetFramework="4.5"/>
<httpRuntime targetFramework="4.5"/>
<authorization>
<deny users="?" />
</authorization>
</system.web>
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs"
type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701"/>
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"
type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
warningLevel="4" compilerOptions="/langversion:14 /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+"/>
</compilers>
</system.codedom>
<appSettings>
<add key="webpages:Version" value="3.0.0.0" />
<add key="webpages:Enabled" value="false" />
<add key="ClientValidationEnabled" value="true" />
<add key="UnobtrusiveJavaScriptEnabled" value="true" />
<add key="ClientId" value="fee415ed-6977-4c3c-b5d0-a06682719fb7" />
<add key="ClientSigningCertificatePath" value="C:\Certificate\Export\NileshSPDemoCertificateExported.pfx" />
<add key="ClientSigningCertificatePassword" value="admin@123" />
<add key="IssuerId" value="e9fe114f-3406-400d-bd22-50f077a8f17f" />
</appSettings>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<!--Used by SharePoint Add-in-->
<binding name="secureBinding">
<security mode="Transport" />
</binding>
</basicHttpBinding>
</bindings>
<protocolMapping>
<add binding="basicHttpBinding" scheme="https" bindingConfiguration="secureBinding" />
</protocolMapping>
</system.serviceModel>
</configuration>

Now Navigate to EmployeeManagementAPPWeb’s Project’s Property -> Web Section

Click On Create Virtual Directory button

It will create Virtual Directory.

Navigate to EmployeeManagementAPPWeb’s Property

Set properties as shown in above image.

Now everything looks great and we are able to deploy application.

Click on Start it will deploy application.

After app deployment you will see below App Permission Page

Click on Trust It and it will open an APP as show below

CRUD Operation Using SharePoint Provide Hosted APP

How to Create and Export Self-Signed Certificate

To create Self-Signed Certificate using IIS follow below steps.

Navigate to IIS

Select Server Certificate

Click on “Create Self-Signed Certificate” link

Enter the details as shown below.

Click on OK.

Do IISRESET

Now Certificate will be available in Server Certificates.

You can check by editing any existing binding

Save Certificate :

Double click on the Certificate in IIS.

Click on Details tab and click on Copy to File.

Now Certificate Export Wizard will available.

Click Next

Click Next Give Certificate Name.

Click Next

Click Finish

It will display message “The export was successful.”

Export Certificate in Personal Exchange Format (.pfx)

Navigate to IIS

Select the Certificate which you want to export.

Click on Export

Give Certificate Export Location and Certificate Name

Enter Password and Confirm Password.

Click on OK.

It will Export Certificate in PFX format.

 

SharePoint – PowerShell Script to Create multiple Sub Sites

From below PowerShell Script we can create multiple sub sites in specific application

param([string] $url,[Array] $sites)
foreach($s in $sites)
{
New-SPWeb -URL ($url + $s) -Template BLANKINTERNET#1 -Name $s
}

Result:

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.

LDAP :

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.

Domains:

The domain is typically of the Internet naming variety (e.g. Learnthat.com), 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:

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.

Sites

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.

DNS

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 www.learnthat.com) to an IP address (such as 64.34.165.234). 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.

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:

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.

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.

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:

http://www.javaworld.com/javaqa/2002-08/01-qa-0823-appvswebserver.html

http://technet.microsoft.com/en-us/library/cc262350%28office.12%29.aspx