AD FS 2.0, out of the box, supports four local authentication types:

  1. Integrated Windows authentication (IWA) – can utilize Kerberos or NTLM authentication. You should always prefer Kerberos authentication over NTLM and configure the appropriate service principal name (SPN) for the AD FS 2.0 service account so that Kerberos can be used. Credential collection can happen in two ways depending on how your browser is configured:
    1. automatic logon with current user name and  password – used when AD FS 2.0 URL is in IE Intranet Zone or another IE Zone which is configured to automatically logon with current user name and password
    2. Browser-based HTTP 401 authentication prompt – used when credentials cannot be automatically supplied to the 401 challenge for credentials
  2. Forms-based authentication (FBA) – A forms-based .aspx page is presented to the user containing username and password fields. This page is fully customizable so that you can add new sign-in logic or page customizations (logos, style sheet, etc.)
  3. Transport layer security client authentication – a.k.a. Client certificate authentication or Smart Card authentication. The credential is supplied by selecting an appropriate client authentication certificate.
  4. Basic authentication – The web browser displays a credential prompt and the credentials supplied are sent across the network. The advantage of Basic authentication is that it is part of the Hypertext Transfer Protocol (HTTP) specification, and is supported by most browsers. The disadvantage is that Web browsers that use Basic authentication transmit passwords in an unencrypted form. If a non-user monitors communications on your network, they can easily intercept and decipher these passwords by using publicly available tools. Therefore, Basic authentication is not recommended unless you are confident that the connection between the user and your Web server is secure; direct cable connections or a dedicated lines are secure connections.

By default AD FS 2.0 Federation Servers use IWA and AD FS 2.0 Federation Server Proxy servers use FBA. The reason for this is because we assume that you would prefer no credential prompt for your internal users who can directly contact your internal Federation Servers, and we also assume that users who are coming from the internet via the Federation Server Proxy servers would not be able to experience integrated Windows authentication, thus a customizable forms-based page is the best fit.

If you prefer to select a non-default local authentication type, perform the following steps:

  1. In Windows Explorer, browse to C:inetpubadfsls (assuming that inetpub lives in C:)
  2. Select web.config and Edit in Notepad
  3. Find (Ctrl+F) <localAuthenticationTypes>
  4. There are four lines below <localAuthenticationTypes>. Each line represents one of the local authentication types listed above.
  5. Cut your preferred local authentication type (the entire line), and Paste it to the top of the list (under <localAuthenticationTypes>)
  6. Save and Close the web.config file

Note: There is no need to restart IIS or make any further changes. Your change will be immediately picked up by IIS since you edited the web.config.

Example:

If I want to change the local authentication type for my internal Federation Servers from IWA to FBA, the resultant web.config section would look like this:

<microsoft.identityServer.web>
<localAuthenticationTypes>
<add name=”Forms” page=”FormsSignIn.aspx” />
      <add name=”Integrated” page=”auth/integrated/” />
<add name=”TlsClient” page=”auth/sslclient/” />
<add name=”Basic” page=”auth/basic/” />
</localAuthenticationTypes>


Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts

Microsoft

PowerShell TTUC #15 – File Name with Time Stamp

PoweShell TTUC (Tips, Tricks and Useful Commands) #16 – File Name with Time Stamp File can be created with date / time suffix using the following syntax / commands: New-item -type file -Name (“MyFile_$(Get-Date -f Read more…

Microsoft

Azure AD and Manual UPN Update

In Azure AD, the UserPrincipalName (UPN) can be manually updated using Set-MsolUserPrincipalName Power Shell cmdlet.  The details and syntax are explained here – https://msdn.microsoft.com/en-us/library/azure/dn194135.aspx One of the common issues you experience during this process is Read more…

Microsoft

Azure Password Reset – The Password you’ve selected does not meet your Active Directory password policy

This is a common error message when you try to reset a password from Azure management port or Self service portal.  The error message is very clear here – “The Password you’ve selected does not Read more…