Windows integrated authentication to allow all authenticated users

Agenda

1. What is Authentication and Authorization?
2. Understanding Windows Authentication
3. Types of Windows Authentication
4. Programmatic Authentication
5. Impersonation

Authentication and Authorization

In simple words, Authentication is the process that addresses the question «Who are you?«. Authentication is done by obtaining a valid username and password on an internet or intranet system. Once a user is authenticated, the system confirms that you match the identity of whoever you claim to be. However, authentication doesn’t confirm whether you are authorized to access the resource that you might be trying to access; that is done by Authorization.

Authorization addresses the question «What Can You Do?» and this happens after successful authentication. Authorization is the process of verifying that a user is allowed to access a requested resource. This process determines whether an authenticated user is permitted access to any part of an application, access to specific points of an application, or access only to specified datasets that the application provides. After all, how can you determine whether someone is allowed to do something if you don’t recognize that person’s identity.

Windows Authentication Overview

Form Authentication is a wonderful approach, if you are implementing your own authentication process using a back-end database and a custom page. But if you are creating a web application for a limited number of users who are already part of a network domain then Windows Authentication is beneficial and the preferred choice for authentication.

Windows-based authentication is manipulated between the Windows server and the client machine.

The ASP.NET applications reside in Internet Information Server (IIS). Any user’s web request goes directly to the IIS server and it provides the authentication process in a Windows-based authentication model. This type of authentication is quite useful in an intranet environment in which users are asked to log into a network.

In this scenario, you can utilize the credentials that are already in place for the authentication and authorization process. This authentication is done by IIS. It first accepts user’s credentials from the domain login «DomainUserName and Password». If this process fails then IIS displays an error and asks to re-enter the login information.

The following are the advantages of Windows Authentication: 

• It relies on and allows the user to use existing Windows Accounts.
• Establishes the foundation for a Uniform Authentication model for multiple types of applications.
• For developers it is easy to implement.

The following are the disadvantages of Windows Authentication:

• Applicable to Microsoft platforms only.
• No custom control over this platform provided authentication process.

Types of Windows Authentication

During implementation of Windows Authentication, typically IIS proposes a range of possible authentication strategies to authenticate each request it receives as in the following:

• Basic Authentication
• Digest Authentication
• Integrated Windows Authentication
• UNC Authentication
• Anonymous Authentication

Basic Authentication

This form of authentication is supported by all browsers. When a website requests client authentication using Basic Authentication, the web browser displays a login dialog box from user name and password as in the following screenshot.

Figure 1.5 IIS Basic Authentication

After a user provides built-in Windows user account information, the data is transmitted to the web server. Once IIS receives the authentication data, it attempts to authenticate the user with the corresponding Windows account. This password is encoded using Base64 and sent to the server. It is important to note that the Base64 encoding is not encryption. So the drawback of this mechanism is that the user name and password are sent in clear text (unencrypted) during communication.

Do It Yourself

In order to see Basic Authentication in action, we will create an ASP.NET website hosted on a local IIS web server. Use the following procedure to create the sample.

1. First open the Visual Studio 2010 IDE. Then go to menu «File» -> «New» -> «Website…»  and name this website «WinAuthTest».

   

   Figure 1.6 New ASP.NET website

2. Ensure that IIS 7.0 is properly configured with registration of ASP.NET 4.0 and other components as explained earlier.
3. Open the IIS Manager using the inetmgr command from the Run window.
4. You see in the IIS Manager that the website «WinAuthTest» entry is added with its corresponding virtual directory as in the following:

   

   Figure 1.7 IIS

5. Now click on «Authentication under IIS» in the dialog box. The following options will appear:

   

   Figure 1.8 Authentications
6. It might be possible that the various authentication options above are not displayed because they are turned on by default. So you can configure them manually from Windows Features under Internet Information Services Security options as in the following screenshot;

   

   Figure 1.9 IIS Security options

7. Now as shown in the reference Figure 1.8, enable the Basic Authentication and compile the ASP.NET «WinAuthTest» project by pressing F5. Windows will show the Figure 1.5 images.
8. Enter the temporarily created Windows account «test» as in Figure 1.1 to proceed. Windows won’t let the website open until you enter the correct user name and password.

Digest Authentication

Digest Authentication, like Basic Authentication, requires the user to provide account information using a login dialog box that is displayed by the browser. Unlike Basic Authentication, the user name and password are not transmitted in clear text. Instead, a cryptographically secure hash with this information is sent. We can implement this authentication by simply enabling this option in IIS as in the following screenshot.

Figure 1.10 Digest Authentications

Digest Authentication involves hashing the user’s password using the MD5 algorithm. Windows is unable to store MD5 hashes of passwords for local accounts (SAM database) thus the limitation of Digest Authentication is that in IIS, it only functions when the virtual directory is being authenticated or controlled by a Windows Active Directory Domain Controller.

Digest Authentication protects users and applications from a variety of malicious attacks by incorporating a piece of information about the request as input to the hashing algorithm.

Enabling and disabling digest authentication can also be done programmatically. We can enable this authentication using the AppCmd command as in the following:

Integrated Windows Authentication

Integrated Windows Authentication is the most reasonable mechanism for LAN-WAN-based applications. For this authentication to work properly, both client and server must be on the same network. In fact, integrated authentication does not transmit any credential information. Instead, it coordinates with the domain server where it is logged in and gets that computer to send the authentication information to the server.

It does authentication without any client interactions. When IIS asks the client to authenticate itself, the browser sends a token that represents the Windows account of the current user. Technically, this authentication incorporates two authentication mechanisms, NTLM and Kerberos. Enabling integrated authentication via IIS Manager typically enables support for both of these two mechanisms as in the following screenshot:

Figure 1.11 Integrated Authentications

UNC Authentication

Universal Naming Convention (UNC) authentication allows you to configure IIS to use a specified user account when accessing resources on a remote share. This authentication can be implemented during creation of a virtual directory for a web application. Use the following procedure to configure UNC authentication:

1. Open IIS Manager using inetmgr from the «Run» window.
2. Locate the website at which you wish to add a new virtual directory. Right-click and choose «Add Virtual Directory».

   

   Figure 1.12 UNC Authentications

3. Enter the alias name that the directory should be accessed under and UNC physical path as in the following screenshot.

   

   Figure 1.13 UNC Authentications

4. Now click the «Connect as» button and choose the «Application User» radio button and chose a specific user account. Finally click the «Ok» button.

    

Anonymous Authentication

A remote user is not required to supply credentials to access a file when Anonymous Authentication is enabled. By default, the configured anonymous access account is the IUSR account created when IIS is installed. Anonymous Authentication can be configured from the IIS Manager as in the following screenshot.

Figure 1.15 Anonymous Authentications

It is important to note that if you enable more than one authentication option, the client will use the strongest authentication method as long as anonymous authentication is not enabled. If anonymous authentication is enabled then the client will access the website anonymously. So it is suggested to disable anonymous authentication during more than one authentication implementation.

Programmatic Authentication

You can access some additional information about the currently authenticated user using the WindowsIdentity class. The following code is required to do that:

Impersonation

Impersonation is the process under which an application can take the identity of its user to access all the resources the user is authorized for. Instead of using a fixed account for all users, web pages and applications, you can temporarily change the identity that ASP.NET uses for certain tasks.

You may want to access some resources residing on your local system, that requires you to login with valid credentials. Let’s say that you have some files in the location «C:temp». The ACL editor for the folder temp removes all the groups and leaves only the Administrator users and Administrator user groups associated to it as in the following screenshot.

Figure 1.17 ACL

Now create a simple ASP.NET Web Application with a Button and a List box control to access all files that reside in the temp folder as in the following code:

Now build the project again to test the application and it should work fine when you click the button as in the following screenshot:

Figure 1.18 Output

Alternately, you can also configure impersonation using the IIS Manager. Let’s use the preceding example as a reference. When you are done with all the programmatic and other configurations related to impersonation you will see that in IIS Manager the ASP.NET impersonation option is enabled and configured with the impersonation «VidyaVrat» account as in the following;

Figure 1.19 Impersonations

From Wikipedia, the free encyclopedia

Integrated Windows Authentication (IWA)^[1]
is a term associated with Microsoft products that refers to the SPNEGO, Kerberos, and NTLMSSP authentication protocols with respect to SSPI functionality introduced with Microsoft Windows 2000 and included with later Windows NT-based operating systems. The term is used more commonly for the automatically authenticated connections between Microsoft Internet Information Services, Internet Explorer, and other Active Directory aware applications.

IWA is also known by several names like HTTP Negotiate authentication, NT Authentication,^[2] NTLM Authentication,^[3] Domain authentication,^[4] Windows Integrated Authentication,^[5] Windows NT Challenge/Response authentication,^[6] or simply Windows Authentication.

Overview[edit]

Integrated Windows Authentication uses the security features of Windows clients and servers. Unlike Basic Authentication or Digest Authentication, initially, it does not prompt users for a user name and password. The current Windows user information on the client computer is supplied by the web browser through a cryptographic exchange involving hashing with the Web server. If the authentication exchange initially fails to identify the user, the web browser will prompt the user for a Windows user account user name and password.

Integrated Windows Authentication itself is not a standard or an authentication protocol. When IWA is selected as an option of a program (e.g. within the Directory Security tab of the IIS site properties dialog)^[7] this implies that underlying security mechanisms should be used in a preferential order. If the Kerberos provider is functional and a Kerberos ticket can be obtained for the target, and any associated settings permit Kerberos authentication to occur (e.g. Intranet sites settings in Internet Explorer), the Kerberos 5 protocol will be attempted. Otherwise NTLMSSP authentication is attempted. Similarly, if Kerberos authentication is attempted, yet it fails, then NTLMSSP is attempted. IWA uses SPNEGO to allow initiators and acceptors to negotiate either Kerberos or NTLMSSP. Third party utilities have extended the Integrated Windows Authentication paradigm to UNIX, Linux and Mac systems.

Supported web browsers[edit]

Integrated Windows Authentication works with most modern web browsers,^[8] but does not work over some HTTP proxy servers.^[7] Therefore, it is best for use in intranets where all the clients are within a single domain. It may work with other web browsers if they have been configured to pass the user’s logon credentials to the server that is requesting authentication. Where a proxy itself requires NTLM authentication, some applications like Java may not work because the protocol is not described in RFC-2069 for proxy authentication.

• Internet Explorer 2 and later versions.^[7]
• In Mozilla Firefox on Windows operating systems, the names of the domains/websites to which the authentication is to be passed can be entered (comma delimited for multiple domains) for the «network.negotiate-auth.trusted-uris» (for Kerberos) or in the «network.automatic-ntlm-auth.trusted-uris» (NTLM) Preference Name on the about:config page.^[9] On the Macintosh operating systems this works if you have a kerberos ticket (use negotiate). Some websites may also require configuring the «network.negotiate-auth.delegation-uris«.
• Opera 9.01 and later versions can use NTLM/Negotiate, but will use Basic or Digest authentication if that is offered by the server.
• Google Chrome works as of 8.0.
• Safari works, once you have a Kerberos ticket.
• Microsoft Edge 77 and later.^[10]

Supported mobile browsers[edit]

• Bitzer Secure Browser supports Kerberos and NTLM SSO from iOS and Android. Both KINIT and PKINIT are supported.

See also[edit]

• SSPI (Security Support Provider Interface)
• NTLM (NT Lan Manager)
• SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism)
  • GSSAPI (Generic Security Services Application Program Interface)

References[edit]

External links[edit]

• Discussion of IWA in Microsoft IIS 6.0 Technical Reference

Integrated Windows Authentication

If your desktop or mobile application runs on Windows, and on a machine connected to a Windows domain — AD or AAD joined — it is possible to use the Integrated Windows Authentication (IWA) to acquire a token silently. No UI is required when using the application.

Use WAM instead

Public client applications should use WAM on Windows. WAM can login the current windows user silently. See https://aka.ms/msal-net-wam
This does not require complex setup and it even works for Personal accounts.

Constraints

• Federated users only, i.e. those created in an Active Directory and backed by Azure Active Directory. Users created directly in AAD, without AD backing — managed users — cannot use this auth flow. This limitation does not affect the Username/Password flow.

• Does not work for MSA users. For MSA uses try out WAM

• IWA is for apps written for .NET Framework, .NET Core and UWP platforms

• IWA does NOT bypass MFA (multi factor authentication). If MFA is configured, IWA might fail if an MFA challenge is required, because MFA requires user interaction.

  This one is tricky. IWA is non-interactive, but 2FA requires user interactivity. You do not control when the identity provider requests 2FA to be performed, the tenant admin does. From our observations, 2FA is required when you login from a different country, when not connected via VPN to a corporate network, and sometimes even when connected via VPN. Don’t expect a deterministic set of rules, Azure Active Directory uses AI to continuously learn if 2FA is required. You should fallback to a user prompt (https://aka.ms/msal-net-interactive) if IWA fails

• The authority passed in the PublicClientApplicationBuilder needs to be:

  • tenanted (of the form https://login.microsoftonline.com/{tenant}/ where tenant is either the guid representing the tenant ID or a domain associated with the tenant.
  • for any work and school accounts (https://login.microsoftonline.com/organizations/)

  Microsoft personal accounts are not supported (you cannot use /common or /consumers tenants)

• Because Integrated Windows Authentication is a silent flow:

  • the user of your application must have previously consented to use the application
  • or the tenant admin must have previously consented to all users in the tenant to use the application.
  • This means that:
    • either you as a developer have pressed the Grant button on the Azure portal for yourself,
    • or a tenant admin has pressed the Grant/revoke admin consent for {tenant domain} button in the API permissions tab of the registration for the application (See Add permissions to access web APIs)
    • or you have provided a way for users to consent to the application (See Requesting individual user consent)
    • or you have provided a way for the tenant admin to consent for the application (See admin consent)

• This flow is enabled for .net desktop, .net core and Windows Universal Apps.

For more details on consent see v2.0 permissions and consent

How to use it?

Application registration

During the App registration , in the Authentication section for your application:

• you don’t need to provide a Reply URI

• but you need to choose Yes, to the question Treat application as a public client (in the Default client type paragraph)

  

Code

IPublicClientApplication contains a method called AcquireTokenByIntegratedWindowsAuth

AcquireTokenByIntegratedWindowsAuth(IEnumerable<string> scopes)

You should normally use only one parameter (scopes). However depending on the way your Windows administrator has setup the policies, it can be possible that applications on your windows machine are not allowed to lookup the logged-in user. In that case, use a second method .WithUsername() and pass in the username of the logged in user as a UPN format — joe@contoso.com.

The following sample presents the most current case, with explanations of the kind of exceptions you can get, and their mitigations

static async Task GetATokenForGraph()
{
 string authority = "https://login.microsoftonline.com/contoso.com";
 string[] scopes = new string[] { "user.read" };
 IPublicClientApplication app = PublicClientApplicationBuilder
      .Create(clientId)
      .WithAuthority(authority)
      .Build();

 var accounts = await app.GetAccountsAsync();

 AuthenticationResult result = null;
 if (accounts.Any())
 {
  result = await app.AcquireTokenSilent(scopes, accounts.FirstOrDefault())
      .ExecuteAsync();
 }
 else
 {
  try
  {
   result = await app.AcquireTokenByIntegratedWindowsAuth(scopes)
      .ExecuteAsync(CancellationToken.None);
  }
  catch (MsalUiRequiredException ex)
  {
   // MsalUiRequiredException: AADSTS65001: The user or administrator has not consented to use the application 
   // with ID '{appId}' named '{appName}'.Send an interactive authorization request for this user and resource.

   // you need to get user consent first. This can be done, if you are not using .NET Core (which does not have any Web UI)
   // by doing (once only) an AcquireToken interactive.

   // If you are using .NET core or don't want to do an AcquireTokenInteractive, you might want to suggest the user to navigate
   // to a URL to consent: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={clientId}&response_type=code&scope=user.read

   // AADSTS50079: The user is required to use multi-factor authentication.
   // There is no mitigation - if MFA is configured for your tenant and AAD decides to enforce it, 
   // you need to fallback to an interactive flows such as AcquireTokenInteractive or AcquireTokenByDeviceCode
   }
   catch (MsalServiceException ex)
   {
    // Kind of errors you could have (in ex.Message)

    // MsalServiceException: AADSTS90010: The grant type is not supported over the /common or /consumers endpoints. Please use the /organizations or tenant-specific endpoint.
    // you used common.
    // Mitigation: as explained in the message from Azure AD, the authoriy needs to be tenanted or otherwise organizations

    // MsalServiceException: AADSTS70002: The request body must contain the following parameter: 'client_secret or client_assertion'.
    // Explanation: this can happen if your application was not registered as a public client application in Azure AD 
    // Mitigation: in the Azure portal, edit the manifest for your application and set the `allowPublicClient` to `true` 
   }
   catch (MsalClientException ex)
   {
      // Error Code: unknown_user Message: Could not identify logged in user
      // Explanation: the library was unable to query the current Windows logged-in user or this user is not AD or AAD 
      // joined (work-place joined users are not supported). 

      // Mitigation 1: on UWP, check that the application has the following capabilities: Enterprise Authentication, 
      // Private Networks (Client and Server), User Account Information

      // Mitigation 2: Implement your own logic to fetch the username (e.g. john@contoso.com) and use the 
      // AcquireTokenByIntegratedWindowsAuth form that takes in the username

      // Error Code: integrated_windows_auth_not_supported_managed_user
      // Explanation: This method relies on an a protocol exposed by Active Directory (AD). If a user was created in Azure 
      // Active Directory without AD backing ("managed" user), this method will fail. Users created in AD and backed by 
      // AAD ("federated" users) can benefit from this non-interactive method of authentication.
      // Mitigation: Use interactive authentication
   }
 }


 Console.WriteLine(result.Account.Username);
}

Note: if you encounter the following error:
«Microsoft.Identity.Client.MsalClientException: Failed to get user name —> System.ComponentModel.Win32Exception: No mapping between account names and security IDs was done»

It means that you may be singed into the device with a local computer account as opposed to an Active Directory(AD) account. Please ensure that the device is added to the domain and that the currently signed in user backed by AD. It is not enough to have a computer joined to a domain alone as local accounts on the device wont be able to access your AD credentials.

Sample illustrating acquiring tokens through Integrated Windows Authentication with MSAL.NET

Sample	Platform	Description
active-directory-dotnet-iwa-v2	Console (.NET)	.NET Core console application letting the user signed-in in Windows, acquire, with the Azure AD v2.0 endpoint, a token for the Microsoft Graph

Additional information

In case you want to learn more about Integrated Windows Authentication:

• How this was done with the V1 endpoint: AcquireTokenSilent using Integrated authentication on Windows (Kerberos) in ADAL.NET

Troubleshooting

If you encounter the error code «parsing_wstrust_response_failed» It may be due to a number of configuration issues in the ADFS environment.

Some of those issues include:

• An account is not being available to perform IWA
• An IWA policy is preventing auto-IWA authentication
• Proxy or configuration issues prevent NTLM protocol (usually the case for 401 Negotiate/NTLM challenge presented by the endpoint for Windows authentication. You may be able to try using your own HttpClient or changing the current version of .NET to work around this issue).
• In case the Error Message is «Object reference not set to an instance of an object.» enable MSAL logging at Warning level to see more details.

For more information see AD FS Troubleshooting — Integrated Windows Authentication