AD FS 2.0 How to force rollover on certificates with office 365 and federated services

http://social.technet.microsoft.com/wiki/contents/articles/1424.ad-fs-2-0-how-to-enable-and-immediately-use-autocertificaterollover.aspx

AD FS 2.0: How to Enable and Immediately Use AutoCertificateRollover

Summary

When the GUI Initial Configuration Wizard (ICW) of AD FS 2.0 has been executed, AutoCertificateRollover is automatically enabled by default and the token-signing and token-decrypting certificates are self-signed and maintained by the AD FS 2.0 service.

When the command line ICW of AD FS 2.0 has been executed, AutoCertificateRollover is either on or off depending on the syntax you provided at the command line.

You can optionally turn off AutoCertificateRollover post-ICW by running the following from PowerShell:

Add-PSSnapin Microsoft.Adfs.Powershell
Set-ADFSProperties -AutoCertificateRollover $false

If you have turned off AutoCertificateRollover in the past and you want to turn it back on, there are a few things you need to consider:

•  
  • Simply turning AutoCertificateRollover back on via PowerShell will not immediately cause the self-signed certificates to be generated
  • The self-signed certificates will only be generated once the critical threshold (close to expiration) of your existing certificates has been met
  • There is a way to immediately cause the self-signed certificates to be generated, but this will cause service outage with your partners until they have refreshed from your federation metadata. We recommend causing the certificate generation after hours to avoid an outage. Alternatively, you could work closely with your partners to ensure that they are ready to immediately update via federation metadata (causing a short outage).

If you decide to let the existing certificates hit the critical threshold instead of invoking the certificate generation process, then you only need to re-enable AutoCertificateRollover.

If you decide that you want to immediately generate new self-signed certificates, then you need to first re-enable AutoCertificateRollover and then issue a PowerShell command to invoke immediate certificate generation.

PowerShell command to re-enable AutoCertificateRollover:

Add-PSSnapin Microsoft.Adfs.PowershellSet-ADFSProperties -AutoCertificateRollover $true

PowerShell command to immediately generate new self-signed certificates:

Add-PSSnapin Microsoft.Adfs.Powershell

Update-AdfsCertificate -Urgent

http://social.technet.microsoft.com/wiki/contents/articles/2554.ad-fs-2-0-how-to-replace-the-ssl-service-communications-token-signing-and-token-decrypting-certificates.aspx

AD FS 2.0: How to Replace the SSL, Service Communications, Token-Signing, and Token-Decrypting Certificates

Table of Contents

• Replacing the SSL and Service Communications certificate
• Replacing the Token-Signing certificate
• Replacing the Token-Decrypting certificate
• More Information
• Were you looking for AD FS 1.x information regarding certificate replacement?
• Have you recently enabled AutoCertificateRollover and you need to immeditately self-sign new Token-Signing and Token-Decrypting certificates?

Replacing the SSL and Service Communications certificate

*Note - Replacing the SSL and Service Communications certificates go hand-in-hand. Any time you are replacing one of these certificates, you must also replace the other. SSL certificates exist on all Federation Servers and Federation Server Proxy servers. Service Communications certificates only exist on Federation Servers.

1. Obtain a new certificate with the following requirements    a. Enhanced Key Usage is at least Server Authentication. If you are obtaining this from an internal MS Exterprise CA, the Web Server template will work fine.
    b. Subject or Subject Alternative Name (SAN) must contain the DNS name of your Federation Service or an appropriate wildcard name
           Example: sso.contoso.com or *.contoso.com
    c. You may wish to generate the certificate request and mark the private key exportable so that you can move the certificate from one server to others in the case when you have a Federation Server farm or at least one Federation Server Proxy.
    d. Take note of which server was used to generate the certificate request. The private key is generated and stored here. When you receive the certificate from the issuing CA, you will need to bring that file back to the server where the request was initiated so that you can create a private/public key pair.
    e. The issuing CA that you choose is important because your Federation Server(s), Federation Server Proxy(ies), and all clients accessing your Federation Service must be able to chain to a trusted root certification authority when validating the SSL certificate. Customers will typically use a 3rd party, public CA for the SSL and Service Communications certificate.

2. ACL the SSL and Service Communications certificate to allow Read access for the AD FS 2.0 service account*Note - This step must be completed on all Federation Servers only.

    a. Click Start, Run, type MMC.exe, and press Enter
    b. Click File, Add/Remove Snap-in
    c. Double-click Certificates
    d. Select Computer account and click Next    e. Select Local computer and click Finish    f. Expand Certificates (Local Computer), expand Personal, and select Certificates
    g. Right-click your new SSL and Service Communications certificate, select All Tasks, and select Manage Private Keys
    h. Add Read access for your AD FS 2.0 service account and click OK    i. Close the Certificates MMC

3. Bind the new SSL and Service Communications certificate to the web site in IIS which hosts the Federation Service*Note - This step must be completed on all Federation Servers and Federation Server Proxy servers.
    a. In IIS7 on Windows Server 2008 and Windows Server 2008 R2, you will select the web site, right-click, Edit Bindings, and select the SSL port, Edit, and use the drop-dwon to select the new SSL certificate:

        

*Note - Be careful when making your certificate selection. Your old SSL certificate and new SSL certificate will likely have the same subject name and/or friendly name, and this may make it difficult to differentiate between the two certificates. When in doubt, use thumbprint matching (see the Thumbprint Matching section at the end of this article).

4. Set a new Service Communications certificate in the AD FS 2.0 Management console*Note - This step needs to be completed just one time on a single Federation Server in the farm. Proxies are not involved here, and other Federation Servers in a farm will pick up this change automatically.

    a. Launch AD FS 2.0 Management from the Administrative Tools menu
    b. Expand Service and select Certificates    c. In the Actions pane, click Set Service Communications Certificate...


    d. You will be presented with a list of certificates that are valid for Service Communications. If you find that your new certificate is not being presented in the list, you need to go back and make sure that a. the certificate is in the local computer Personal store with private key associated, and b. the certificate has the Server Authentication EKU.
    e. Select your new Service Communications certificate and click OK* Note: Be careful when making your certificate selection. Your old Service Communications certificate and new Service Communications certificate might have the same subject name and/or friendly name, and this may make it difficult to differentiate between the two certificates. When in doubt, use thumbprint matching (see the Thumbprint Matchingsection at the end of this article).



5. Test SSL functionality for internal and external users to ensure that SSL is working as expected on the Federation Servers and the Federation Server Proxy servers.

Replacing the Token-Signing certificate

*Note - If you are utilizing the AutoCertificateRollover feature of AD FS 2.0, you do not need to manually replace the Token-Signing certificate. AutoCertificateRollover will create a self-signed Token-Signing certificate for you and set it as the Primary Token-Signing certificate when a time threshold has been met. The new Token-Signing certificate is published in your Federation Metadata, and Relying Party (RP) partners who can consume Federation Metadata will automatically pick up the change whenever they pull your Federation Metadata document. You should work with your RP partners to see how often they pull for Federation Metadata so that, in the event of a certificate replacement, they will experience little to no downtime before trusting your new certificate. If your RP partners cannot consume Federation Metadata, you should be aware of when AutoCertificateRollover will set a new Primary Token-Signing certificate and you will need to plan accordingly to send the public key portion of this certificate to your RP partners.

1. Check to see if you are utilizing AutoCertificateRollover    a. Launch PowerShell on a Federation Server
    b. Run the following commands:
        Add-Pssnapin Microsoft.Adfs.Powershell
        Get-ADFSProperties    c. Look for the value of AutoCertificateRollover in the output. It will show True or False    d. If the result of step c. is True, then you are finished, and you should take special note of everything in the *Noteabove. If the result of step c. is False, then you will need to maintain the Token-Signing certificate manually, and you should move on to the next step.

2. Obtain a new certificate with the following requirements    a. It is common to think that a specific Enhanced Key Usage (EKU) is needed for the Token-Signing certificate, but this is, in fact, not correct. The only requirement for usage is that Key Usage (KU) must contain at least Digital Signature. We have seen a lot of customers go through the trouble of obtaining a Code Signing EKU certificate. Again, EKU is not required for Token-Signing.
    b. Subject and/or Subject Alternative Name (SAN) does not matter. We recommend using something like "AD FS Token-Signing" or "Contoso SSO Token-Signing" so that you know exactly what the certificate is used for when you see it.
    c. Take note of which server was used to generate the certificate request. The private key is generated and stored here. When you receive the certificate from the issuing CA, you will need to bring that file back to the server where the request was initiated so that you can create a private/public key pair.
    d. When choosing an issuing CA, remember that only your Federation Servers, your RP Federation Servers and RP applications need to be able to chain to a trusted root certification authority when validating your Token-Signing certificate. You could save on the cost of a 3rd party certificate by using an internal PKI-issued certificate or a self-signed certificate. If you choose to use an internal PKI, your Federation Servers, RP Federation Servers and RP applications must trust your PKI root. If you choose to use a self-signed certificate, your Federation Servers and Resource Partner Federation Servers must import the self-signed certificate to the Trusted Root Certification Authorities store in order to trust the self-signed certificate.

3. Decide how your RP partners will trust the new Token-Signing certificate

RP partners who can consume Federation Metadata

You should replace the Token-Signing certificate and instruct the RP partners to pull for your new Federation Metadata to pick up the new certificate.

RP partners who can NOT consume Federation MetadataYou must manually send them the public key of your new Token-Signing Certificate. Send your new Token-Signing certificate public key (.cer file or .p7b if you wish to include the entire chain) to all of your RPs. Have the partner implement changes on their side to trust the new certificate. If the RP partner is using AD FS 2.0, the following will apply.

On the RP partner AD FS 2.0 server:    a. Launch AD FS 2.0 Management from the Administrative Tools menu
    b. Expand Trust Relationships, select Claims Provider Trusts, and select the trust that was created for you
    c. Right-click the trust name and select Properties    d. Select the Certificates tab and Add the new Token-Signing certificate
    e. Click OK



4. Add the new Token-Signing certificate    a. Launch AD FS 2.0 Management from the Administrative Tools menu
    b. Expand Service and select Certificates    c. In the Actions pane, click Add Token-Signing Certificate...    d. You will be presented with a list of certificates that are valid for Token-Signing. If you find that your new certificate is not being presented in the list, you need to go back and make sure that a. the certificate is in the local computer Personal store with private key associated, and b. the certificate has the Digital Signature KU.
    e. Select your new Token-Signing certificate and click OK* Note: Be careful when making your certificate selection. Your old Token-Signing certificate and new Token-Signing certificate might have the same subject name and/or friendly name, and this may make it difficult to differentiate between the two certificates. When in doubt, use thumbprint matching (see the Thumbprint Matching section at the end of this article).



5. ACL the private key to allow Read access to the AD FS 2.0 service account    a. When you add a new Token-Signing certificate, you receive a warning reading: "Ensure that the private key for the chosen certificate is accessible to the service account for this Federation Service on each server in the farm":



    b. Click Start, Run, type MMC.exe, and press Enter
    c. Click File, Add/Remove Snap-in
    d. Double-click Certificates
    e. Select Computer account and click Next    f. Select Local computer and click Finish    g. Expand Certificates (Local Computer), expand Personal, and select Certificates
    h. Right-click your new Token-Signing certificate, select All Tasks, and select Manage Private Keys
    i. Add Read access for your AD FS 2.0 service account and click OK    j. Close the Certificates MMC

6. Set the new Token-Signing certificate as Primary    a. With the Certificates node in AD FS 2.0 Management selected, you should now see two certificates listed under Token-Signing:
        i.  Your old Token-Signing certificate
        ii. Your new Token-Signing certificate
    b. Select your new Token-Signing certificate, right-click, and select Set as primary    c. Leave the old certificate as secondary for rollover purposes. You should plan to remove the old certificate once you are confident it is no longer needed for rollover, or when the certificate has expired.
            i. Current users' SSO sessions are signed and possibly also encrypted using the OLD certificate
            ii. Current AD FS 2.0 Proxy Trust relationships utilize tokens that are signed and encrypted using the OLD certificate




7. Test the new Token-Signing certificate by sending a SAML assertion to your RP partners and RP applications

Replacing the Token-Decrypting certificate

*Note - If you are utilizing the AutoCertificateRollover feature of AD FS 2.0, you do not need to manually replace the Token-Decrypting certificate. AutoCertificateRollover will create a self-signed Token-Decrypting certificate for you and set it as the Primary Token-Decrypting certificate when a time threshold has been met. The new Token-Decrypting certificate is published in your Federation Metadata, and Claims Provider (CP) partners who can consume Federation Metadata will automatically pick up the change whenever they pull your Federation Metadata document. You should work with your CP partners to see how often they pull for Federation Metadata so that, in the event of a certificate replacement, they will experience little to no downtime before utilizing your new certificate for token encryption. If your CP partners cannot consume Federation Metadata, you should be aware of when AutoCertificateRollover will set a new Primary Token-Decrypting certificate and you will need to plan accordingly to send the public key portion of this certificate to your CP partners.

1. Check to see if you are utilizing AutoCertificateRollover    a. Launch PowerShell on a Federation Server
    b. Run the following commands:
        Add-Pssnapin Microsoft.Adfs.Powershell
        Get-ADFSProperties    c. Look for the value of AutoCertificateRollover in the output. It will show True or False    d. If the result of step c. is True, then you are finished, and you should take special note of everything in the *Noteabove. If the result of step c. is False, then you will need to maintain the Token-Decrypting certificate manually, and you should move on to the next step.

2. Obtain a new certificate with the following requirements    a. It is common to think that a specific Enhanced Key Usage (EKU) is needed for the Token-Decrypting certificate, but this is, in fact, not correct. The only requirement for usage is that Key Usage (KU) must contain at least Key Encipherment. We have seen a lot of customers go through the trouble of obtaining a Code Signing EKU certificate. Again, EKU is not required for Token-Decrypting.
    b. Subject and/or Subject Alternative Name (SAN) does not matter. We recommend using something like "AD FS Token-Decrypting" or "Contoso SSO Token-Decrypting" so that you know exactly what the certificate is used for when you see it.
    c. Take note of which server was used to generate the certificate request. The private key is generated and stored here. When you receive the certificate from the issuing CA, you will need to bring that file back to the server where the request was initiated so that you can create a private/public key pair.
    d. When choosing an issuing CA, remember that only your Federation Servers and CP partners need to be able to chain to a trusted root certification authority when validating your Token-Decrypting certificate. You could save on the cost of a 3rd party certificate by using an internal PKI-issued certificate or a self-signed certificate. If you choose to use an internal PKI, your Federation Servers and CP partners must trust your PKI root. If you choose to use a self-signed certificate, your Federation Servers and CP partners must import the self-signed certificate to the Trusted Root Certification Authorities store in order to trust the self-signed certificate.

3. Decide how your CP partners will trust the new Token-Decrypting certificate
CP partners who can consume Federation Metadata

You should replace the Token-Decrypting certificate and instruct the CP partners to pull for your new Federation Metadata to pick up the new certificate.

 CP partners who can NOT consume Federation MetadataYou must manually send them the public key of your new Token-Decrypting certificate. Send your new Token-Decrypting certificate public key (.cer file or .p7b if you wish to include the entire chain) to all of your CPs. Have the partner implement changes on their side to trust the new certificate. If the CP partner is using AD FS 2.0, the following will apply.

On the CP partner AD FS 2.0 server:    a. Launch AD FS 2.0 Management from the Administrative Tools menu
    b. Expand Trust Relationships, select Relying Party Trusts, and select the trust that was created for you
    c. Right-click the trust name and select Properties    d. Select the Encryption tab and click Browse... to select the new Token-Decrypting certificate
    e. Click OK


4. Add the new Token-Decrypting certificate    a. Launch AD FS 2.0 Management from the Administrative Tools menu
    b. Expand Service and select Certificates    c. In the Actions pane, click Add Token-Decrypting certificate...
    d. You will be presented with a list of certificates that are valid for Token-Decrypting. If you find that your new certificate is not being presented in the list, you need to go back and make sure that a. the certificate is in the local computer Personal store with private key associated, and b. the certificate has the Key Encipherment KU.
    e. Select your new Token-Decrypting certificate and click OK

* Note: Be careful when making your certificate selection. Your old Token-Decrypting certificate and new Token-Decrypting certificate might have the same subject name and/or friendly name, and this may make it difficult to differentiate between the two certificates. When in doubt, use thumbprint matching (see theThumbprint Matching section at the end of this article).



5. ACL the private key to allow Read access to the AD FS 2.0 service account    a. When you add a new Token-Decrypting certificate, you receive a warning reading: "Ensure that the private key for the chosen certificate is accessible to the service account for this Federation Service on each server in the farm":


   b. Click Start, Run, type MMC.exe, and press Enter    c. Click File, Add/Remove Snap-in    d. Double-click Certificates    e. Select Computer account and click Next    f. Select Local computer and click Finish    g. Expand Certificates (Local Computer), expand Personal, and selectCertificates
    h. Right-click your new Token-Decrypting certificate, select All Tasks, and select Manage Private Keys
    i. Add Read access for your AD FS 2.0 service account and click OK
    j. Close the Certificates MMC

6. Set the new Token-Decrypting certificate as Primary    a. With the Certificates node in AD FS 2.0 Management selected, you should now see two certificates listed under Token-Decrypting:
        i.  Your old Token-Decrypting certificate
        ii. Your new Token-Decrypting certificate
    b. Select your new Token-Decrypting certificate, right-click, and select Set as primary    c. Leave the old certificate as secondary for rollover purposes. You should plan to remove the old certificate once you are confident it is no longer needed for rollover, or when the certificate has expired.
            i. Current users' SSO sessions are signed and possibly also encrypted using the OLD certificate
            ii. Current AD FS 2.0 Proxy Trust relationships utilize tokens that are signed and encrypted using the OLD certificate



7. Test the new Token-Decrypting certificate by having your CP partners send you an encrypted SAML assertion

More Information

Thumbprint Matching
1. View the properties of the certificate (double-click the certificate in the Certificates MMC or in Windows Explorer. Within an application interface, you may be presented with a control to View Certificate or similar).
2. Select the Details tab
3. Scroll down to the Thumbprint property and select it:



4. Take note of the first 4 characters and the last 4 characters (this usually gives us a good idea of thumbprint uniqueness)
    Example from the screenshot above: 92 e3 and d8 6c

5. Repeat steps 1-4 on another certificate and compare the noted values

Were you looking for AD FS 1.x information regarding certificate replacement?

AD FS 1.0 and 1.1: How to Replace the SSL, Token-Signing, and Federation Server Proxy Certificates -http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-1-0-and-1-1-how-to-replace-the-ssl-token-signing-and-federation-server-proxy-certificates.aspx

Have you recently enabled AutoCertificateRollover and you need to immeditately self-sign new Token-Signing and Token-Decrypting certificates?

AD FS 2.0: How to Enable and Immediately Use AutoCertificateRollover -http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-how-to-enable-and-immediately-use-autocertificaterollover.aspx

AD FS, AD FS 2.0, AD FS v2, adfs, ADFS 2.0, ADFS v2, certificate, certificates, EKU, enhanced key usage, en-US,federation server, federation server proxy, FSP, FS-P, has comment, has image, Has TOC, key usage, replace, self-signed,server authentication, Service Communications, SSL, token decrypting, token decryption, token encryption, token signing, token-decrypting, token-signing

Granting non admins rights to a service

There are times when you want a non admin to have service stop/start rights. here is one way to do it

http://thommck.wordpress.com/2011/12/02/how-to-allow-non-admins-to-start-and-stop-system-services/

Any Microsoft Windows operating system has services. These are little programs that run in the background of the OS to keep things ticking over. They’re really fundamental to servers as it means that programs can run in the background without any user being logged. In fact Windows servers are fine-tuned to give better performance to background services rather than any app running on the screen.

It’s always the best principle to log on with the least amount of privileges on any PC, i.e. you shouldn’t log on to a desktop or server with full admin rights. You should log on as a normal user and only elevate the  programmes authority to admin level if absolutely necessary.

Some System Administrators may want an easy life and just let everything “run as admin” as it cuts back on a lot of problems, especially when using old software. Obviously this greatly widens the security attack vector, as any user who can gain access to the machine can do anything they want on it.

However, one of the issues of running as a standard user is that you are not allowed to stop or start Windows services. That is by design, you wouldn’t really want a non-admin to stop a critical service. The problem is when you have a Service Account running (as good practice dictates) as a lowly user. To get around this you can give the Service Account permission to do whatever you want to a particular service you want. Unfortunately, this is a bit more convoluted than setting file permissions. This article will explain how to achieve this. It applies to all versions of Windows from Windows 2000 or newer. My screenshots are from the Windows 8 Developer Preview.

Scenario

A server on our network runs some aging but critical telephony software. The services run under a Service Account with a username of Svc-Phones. The Svc-Phones account also logs on to the server interactively to view any messages from the application or stop & start the services if there is an issue (avoiding a whole server reboot). The IT manager wants the Svc-Phones account to be removed from the local Administrators group to help secure the server. This means we will need to change the security permissions for the telephony program’s service.

Step 1 – Create the Console

We need to open a hidden console snap-in

1. Click Start > Run (or press WIN + R) and type “mmc.exe”
2. This opens an empty Microsoft Management Console. Click File > Add/Remove Snap-in… (Ctrl+ M)
3. Scroll down the list of available Snap-ins and selectSecurity Configuration and Analysis
4. Click Add
5. Next select Security Templates
6. Click Add
7. Click OK

Step 2 – Create a blank Security Template

In Windows Server 2003 and below you can store these files anywhere but later versions have tougher restrictions so we will be creating everything in D:\Securtiy\

1. Right-click Security Templates from the console tree and select New Template Search Path …
2. Browse to D:\Security, or other local path, and click OK
3. Right-click D:\Security from the console tree and select New Template …
4. Give the new template a name, e.g. Custom Services. It doesn’t matter what you use.
5. The Description is optional but may be useful if you want to re-use it
6. Click OK and you will see the new template appear in the console

The point of these templates are to lock-down servers using the Windows Security Configuration Wizard but we are only using them for a simple permission change

Step 3 – Create a Security Database

1. Right-click Security Configuration and Analysis from the console tree and select Open Database…
2. Browse to D:\Security, or other local path, and type a name in the File name: box e.gSecurity
3. Click OK. This creates an Security.sdb file that is used to apply the changes
4. An Import Template window appears. Browse to D:\Security/Custom Services.inf and selectOpen. This applies the template with all the local services to the database
5. If you get the error “The database you are attempting to open does not exist.” then you need to choose a different path i.e. on a local disk
6. Right-click Security Configuration and Analysis from the console tree and select Analyze Computer …
7. Click OK to accept the default log file path
8. You will then be presented with something that looks very similar to the Group Policy Editor or Local Security Policy Console

Step 4 Change Service Permissions

1. Double-Click System Services
2. Scroll down to find the service you need to change, e.g. Fax
3. Double-Click the service
4. Tick the box Define this policy in the database:
5. Click the Edit Security … button
6. Click Add
7. Type in the user name of the Service account e.g. Svc-Phones, and click OK
8. With the Svc-Phones account selected, check the Allowpermissions for Start, stop and pause
9. Click OK
10. Click OK on the Service Properties to bring you back to the console
11. You’ll notice the Service now has an ‘x’ on it and Investigate message on the Permission column. This is because the new permissions we’ve chosen conflict with what is on the local computer

Step 5 – Apply new Security Permissions

1. Right-click Security Configuration and Analysis from the console tree and select Configure Computer …
2. Click OK to accept the default log file path
3. This will apply the new custom permissions to the local computer
4. You can now test it out on the server with the Svc-Phones account and test it works

You can see that this is rather long-winded just to configure permissions on a service. thankfully, you can save everything and it will be quick to re-use in the future or as part of a batch process across servers. If you want to change the permissions on a default Microsoft Service you can use the Security section of Group Policy to achieve the same results

Related Reading:

• Microsoft Support article: How to grant users rights to manage services in Windows Server 2003

Application pool IDs in 2008 and assigning permissions

There will be times you need to take an application pool and use the id it uses to get special rights a web site may need.

http://www.iis.net/learn/manage/configuring-security/application-pool-identities

Application Pool Identities

By Thomas Deml

March 28, 2014

Introduction

Whether you are running your site on your own server or in the cloud, security must be at the top of your priority list. If so, you will be happy to hear that IIS has a security feature called the application pool identity. This feature was introduced in Service Pack 2 (SP2) of Windows Server 2008 and Windows Vista. An application pool identity allows you to run an application pool under a unique account without having to create and manage domain or local accounts. The name of the application pool account corresponds to the name of the application pool. The image below shows an IIS worker process (W3wp.exe) running as the DefaultAppPool identity.

Application Pool Identity Accounts

Worker processes in IIS 6.0 and in IIS 7 run as Network Service by default. Network Service is a built-in Windows identity. It doesn't require a password and has only user privileges; that is, it is relatively low-privileged. Running as a low-privileged account is a good security practice because then a software bug can't be used by a malicious user to take over the whole system.

However, a problem arose over time as more and more Windows system services started to run as Network Service. This is because services running as Network Service can tamper with other services that run under the same identity. Because IIS worker processes run third-party code by default (Classic ASP, ASP.NET, PHP code), it was time to isolate IIS worker processes from other Windows system services and run IIS worker processes under unique identities. The Windows operating system provides a feature called "virtual accounts" that allows IIS to create a unique identity for each of its application pools. Click here for more information about Virtual Accounts.

Configuring IIS Application Pool Identities

If you are running IIS 7.5 on Windows Server 2008 R2, or a later version of IIS, you don't have to do anything to use the new identity. For every application pool you create, the Identity property of the new application pool is set to ApplicationPoolIdentityby default. The IIS Admin Process (WAS) will create a virtual account with the name of the new application pool and run the application pool's worker processes under this account by default.

To use this virtual account when running IIS 7.0 on Windows Server 2008, you have to change the Identity property of an application pool that you create to ApplicationPoolIdentity. Here is how:

1. Open the IIS Management Console (INETMGR.MSC).
2. Open the Application Pools node underneath the machine node. Select the application pool you want to change to run under an automatically generated application pool identity.
3. Right click the application pool and select Advanced Settings...
   
4. Select the Identity list item and click the ellipsis (the button with the three dots).
5. The following dialog appears:
   
6. Select the Built-in account button, and then select the identity type ApplicationPoolIdentity from the combo box.

To do the same step by using the command-line, you can call the appcmd command-line tool the following way:

%windir%\system32\inetsrv\appcmd.exe set AppPool <your AppPool> -processModel.identityType:ApplicationPoolIdentity

Securing Resources

Whenever a new application pool is created, the IIS management process creates a security identifier (SID) that represents the name of the application pool itself. For example, if you create an application pool with the name "MyNewAppPool," a security identifier with the name "MyNewAppPool" is created in the Windows Security system. From this point on, resources can be secured by using this identity. However, the identity is not a real user account; it will not show up as a user in the Windows User Management Console.

You can try this by selecting a file in Windows Explorer and adding the "DefaultAppPool" identity to the file's Access Control List (ACL).

1. Open Windows Explorer
2. Select a file or directory.
3. Right click the file and select Properties
4. Select the Security tab
5. Click the Edit button and then Add button
6. Click the Locations button and make sure that you select your computer.
   
7. Enter IIS AppPool\DefaultAppPool in the Enter the object names to select: text box.
8. Click the Check Names button and click OK.

By doing this, the file or directory you selected will now also allow the DefaultAppPool identity access.

You can do this via the command-line by using the ICACLS tool. The following example gives full access to the DefaultAppPool identity.

ICACLS test.txt /grant "IIS AppPool\DefaultAppPool":F

For more information, see ICACLS.

On Windows 7 and Windows Server 2008 R2, and later versions of Windows, the default is to run application pools as the application pool identity. To make this happen, a new identity type with the name "AppPoolIdentity" was introduced. If the "AppPoolIdentity" identity type is selected (the default on Windows 7 and Windows Server 2008 R2, and later), IIS will run worker processes as the application pool identity. With every other identity type, the security identifier will only be injected into the access token of the process. If the identifier is injected, content can still be ACLed for the ApplicationPoolIdentity, but the owner of the token is probably not unique. Here is an article that explains this concept.

Accessing the Network

Using the Network Service account in a domain environment has a great benefit. Worker process running as Network Service access the network as the machine account. Machine accounts are generated when a machine is joined to a domain. They look like this:

<domainname>\<machinename>$,

For example:

mydomain\machine1$

The nice thing about this is that network resources like file shares or SQL Server databases can be ACLed to allow this machine account access.

WHAT ABOUT APPLICATION POOL IDENTITIES?

The good news is that application pool identities also use the machine account to access network resources. No changes are required.

Compatibility Issues with Application Pool Identities

GUIDANCE DOCUMENTATION

The biggest compatibilty issue with application pool identities is probably earlier guidance documents which explicitly recommend that you ACL resources for Network Service, that is, the default identity of the DefaultAppPool in IIS 6.0 and IIS 7.0. Customers will have to change their scripts to ACL for "IIS AppPool\DefaultAppPool" (or another application pool name) when running on IIS 7.5 or later (see the example above for how to do this).

USER PROFILE

IIS doesn't load the Windows user profile, but certain applications might take advantage of it anyway to store temporary data. SQL Express is an example of an application that does this. However, a user profile has to be created to store temporary data in either the profile directory or in the registry hive. The user profile for the Network Service account was created by the system and was always available. However, with the switch to unique Application Pool identities, no user profile is created by the system. Only the standard application pools (DefaultAppPool and Classic .NET AppPool) have user profiles on disk. No user profile is created if the Administrator creates a new application pool.

However, if you want, you can configure IIS application pools to load the user profile by setting the LoadUserProfile attribute to "true".

Summary

Application pool identities are a powerful new isolation feature introduced for Windows Server 2008, Windows Vista, and later versions of Windows. It will make running IIS applications even more secure and reliable.