Best Practices for Secure Planning and Deployment of ADFS 2.0

This topic provides best-practice information to help you plan and evaluate security when you design your Active Directory Federation Services (AD FS) 2.0 deployment. This topic is a starting point for reviewing and assessing considerations that affect the overall security of your use of AD FS 2.0. The information in this topic is meant to compliment and extend your existing security planning and other design best practices.

Core security best practices for AD FS 2.0

The following core best practices are common to all AD FS 2.0 installations where you want to improve or extend the security of your design or deployment:

• Use the Security Configuration Wizard to apply AD FS-specific security best practices to federation servers and federation server proxy computers
  
  The Security Configuration Wizard (SCW) is a tool that comes preinstalled on all Windows Server 2008 and Windows Server 2008 R2 computers. You can use it to apply security best practices that can help reduce the attack surface for a server, based on the server roles that you are installing.
  
  When you install AD FS 2.0, the setup program creates role extension files that you can use with the SCW to create a security policy that will apply to the specific AD FS 2.0 server role (either federation server or federation server proxy) that you choose during setup.
  
  Each role extension file that is installed represents the type of role and subrole for which each computer is configured. The following role extension files are installed in the %systemroot%\Active Directory Federation Services 2.0\Scw directory:
  
  
  • Farm.xml
    
  • SQLFarm.xml
    
  • StandAlone.xml
    
  • Proxy.xml (This file is present only if you configured the computer in the federation server proxy role.)
    
  To apply the AD FS 2.0 role extensions in the SCW, complete the following steps in order:
  
  
  1. Install AD FS 2.0 and choose the appropriate server role for that computer. For more information, see Install the AD FS 2.0 Software in the AD FS 2.0 Deployment Guide.
     
  2. Register the appropriate role extension file using the Scwcmd command-line tool. See the following table for details about using this tool in the role for which your computer is configured.
     
  3. Verify that the command has completed successfully by examining the SCWRegister_log.xml file, which is located in the %systemroot%\security\Msscw\Logs directory.
     
  You must perform all these steps on each federation server or federation server proxy computer to which you want to apply AD FS 2.0–based SCW security policies.
  
  The following table explains how to register the appropriate SCW role extension, based on the AD FS 2.0 server role that you chose on the computer where you installed AD FS 2.0.
  
  

   

  AD FS 2.0 server role	AD FS configuration database used	Type the following command at a command prompt:
  Stand-alone federation server	Windows Internal Database	scwcmd register /kbname:ADFS2Standalone /kbfile:"%programfiles%\Active Directory Federation Services 2.0\scw\StandAlone.xml"
  Farm-joined federation server	Windows Internal Database	scwcmd register /kbname:ADFS2Standalone /kbfile:"%programfiles%\Active Directory Federation Services 2.0\scw\Farm.xml"
  Farm-joined federation server	SQL Server	scwcmd register /kbname:ADFS2Standalone /kbfile:"%programfiles%\Active Directory Federation Services 2.0\scw\SQLFarm.xml"
  Federation server proxy	N/A	scwcmd register /kbname:ADFS2Standalone /kbfile:"%programfiles%\Active Directory Federation Services 2.0\scw\Proxy.xml"

  For more information about the databases that you can use with AD FS 2.0, see The Role of the AD FS Configuration Database.
  
• Use token replay detection in situations in which security is a very important concern, for example, when kiosks are used.
  Token replay detection is a feature of AD FS 2.0 that ensures that any attempt to replay a token request that is made to the Federation Service is detected and the request is discarded. Token replay detection is enabled by default. It works for both the WS-Federation passive profile and the Security Assertion Markup Language (SAML) WebSSO profile by ensuring that the same token is never used more than once.
  
  When the Federation Service starts, it begins to build a cache of any token requests that it fulfills. Over time, as subsequent token requests are added to the cache, the ability to detect any attempts to replay a token request multiple times increases for the Federation Service. If you disable token replay detection and later choose to enable it again, remember that the Federation Service will still accept tokens for a period of time that may have been used previously, until the replay cache has been allowed enough time to rebuild its contents. For more information, see The Role of the AD FS Configuration Database.
  
• Use token encryption, especially if you are using supporting SAML artifact resolution.
  
  Encryption of tokens is strongly advised to increase security and protection against potential man-in-the-middle (MITM) attacks that might be tried against your AD FS 2.0 deployment. Using use encryption might have a slight impact on throughout but in general, it should not be usually noticed and in many deployments the benefits for greater security exceed any cost in terms of server performance.
  
  To enable token encryption, first set add an encryption certificate for your relying party trusts. You can configure an encryption certificate either when creating a relying party trust or later. To add an encryption certificate later to an existing relying party trust, you can set a certificate for use on the Encryption tab within trust properties while using the AD FS 2.0 snap-in. To specify a certificate for an existing trust using the AD FS 2.0 cmdlets for Windows PowerShell, use the EncryptionCertificate parameter of either the Set-ClaimsProviderTrust or Set-RelyingPartyTrust cmdlets. To set a certificate for the Federation Service to use when decrypting tokens, use the Set-ADFSCertificate cmdlet and specify "Token-Encryption" for the CertificateType parameter. Enabling and disabling encryption for specific relying party trust can be done by using the EncryptClaims parameter of the Set-RelyingPartyTrust cmdlet.
  
• Utilize extended protection for authentication
  
  To help secure your deployments, you can set and use the extended protection for authentication feature with AD FS 2.0. This setting specifies the level of extended protection for authentication supported by a federation server.
  
  Extended protection for authentication helps protect against man-in-the-middle (MITM) attacks, in which an attacker intercepts client credentials and forwards them to a server. Protection against such attacks is made possible through a Channel Binding Token (CBT) which can be either required, allowed, or not required by the server when it establishes communications with clients.
  
  To enable the extended protection feature, use the ExtendedProtectionTokenCheck parameter on the Set-ADFSProperties cmdlet. Possible values for this setting and the level of security that the values provide are described in the following table.
  
  

   

  Parameter Value	Security level	Protection setting
  Require	Server is fully hardened.	Extended protection is enforced and always required.
  Allow	Server is partially hardened.	Extended protection is enforced where systems involved have been patched to support it.
  None	Server is vulnerable.	Extended protection is not enforced.

• If you are using logging and tracing, ensure the privacy of any sensitive information.
  
  AD FS 2.0 does not, by default, expose or track personally identifiable information (PII) directly as part of the Federation Service or normal operations. When event logging and debug trace logging are enabled in AD FS 2.0, however, depending on the claims policy that you configure some claims types and their associated values might contain PII that might be logged in the AD FS 2.0 event or tracing logs.
  
  Therefore, enforcing access control on the AD FS 2.0 configuration and its log files is strongly advised. If you do not want this kind of information to be visible, you should disable loggin, or filter out any PII or sensitive data in your logs before you share them with others.
  
  The following tips can help you prevent the content of a log file from being exposed unintentionally:
  
  
  • Ensure that the AD FS 2.0 event log and trace log files are protected by access control lists (ACL) that limit access to only those trusted administrators who require access to them.
    
  • Do not copy or archive log files using file extensions or paths that can be easily served using a Web request. For example, the .xml file name extension is not a safe choice. You can check the Internet Information Services (IIS) administration guide to see a list of extensions that can be served.
    
  • If you revise the path to the log file, be sure to specify an absolute path for the log file location, which should be outside of the Web host virtual root (vroot) public directory to prevent it from being accessed by an external party using a Web browser.
    

SQL Server–specific security best practices for AD FS 2.0

The following security best practices are specific to the use of Microsoft SQL Server® or Windows Internal Database (WID) when these database technologies are used to manage data in AD FS 2.0 design and deployment.

Note
These recommendations are meant to extend, but not replace, SQL Server product security guidance. For more information about planning a secure SQL Server installation, see Security Considerations for a Secure SQL Installation (http://go.microsoft.com/fwlink/?LinkID=139831).

• Always deploy SQL Server behind a firewall in a physically secure network environment.
  
  A SQL Server installation should never be exposed directly to the Internet. Only computers that are inside your datacenter should be able to reach your SQL server installation that supports AD FS 2.0. For more information, see Security Best Practices Checklist (http://go.microsoft.com/fwlink/?LinkID=189229).
  
• Run SQL Server under a service account instead of using the built-in default system service accounts.
  
  By default, SQL Server is often installed and configured to use one of the supported built-in system accounts, such as the LocalSystem or NetworkService accounts. To enhance the security of your SQL Server installation for AD FS 2.0, wherever possible use a separate service account for accessing your SQL Server service and enable Kerberos authentication by registering the security principal name (SPN) of this account in your Active Directory deployment. This enables mutual authentication between client and server. Without SPN registration of a separate service account, SQL Server will use NTLM for Windows-based authentication, where only the client is authenticated.
  
• Minimize the surface area of SQL Server.

More Here

Courtesy:http://technet.microsoft.com/en-us/library/adfs2-design-best-practices-for-secure-planning-and-deployment%28WS.10%29.aspx