Windows Integrated AuthenticationIf you’ve written an application the intranet, you’ve likely used Windows Integrated Authentication at some point. When it works, it’s pretty slick. Not only is it flexible in the authentication protocols you can use, but users (if set up right) don’t even need to enter in their username/password.
Windows Integrated Authentication can use any of NTLM, Kerberos, Negotiate, or Digest. So if you’re picky about your security protocols (performance, client availability, hack-ability) there’s probably something in that list that will float your boat.
For those that haven’t had the pleasure yet, WIA is a way for users to authenticate (establish an identity) with an application in a Windows environment. The identity they’re usually establishing is one from from Active Directory or a local Windows credential.
Why’s It UsefulAs it turns out, people don’t like logging in. Most users don’t even like typing in general, and the rest can’t be bothered to remember their password. When WIA works well, the user doesn’t do anything. They simply access a resource, and in the background a challenge/response ballet establishes their identity. All they see is a page that knows who they are treats them accordingly.
The equivalent of this happening to you in real life would be people just (seemingly) knowing who you are and treating you accordingly. If you were to arrive at a fancy restaurant (and you had reservations) you could just show up and be led to you table (no need to check in).
On the other side of things, if you showed up somewhere you weren’t supposed to be (no permissions) they’d immediately throw you into the street. The moral of the story here; regardless of how you get treated, you don’t need to type.
A Day In The LifeHere’s a look into what some WIA challenge/responses looks like in against a SharePoint 2007 site using NTLM and Internet Explorer 8 as a client. The important note here is that the user didn’t do anything beyond visit the site. All this happens in the background when WIA behaves appropriately.
This is the first of a series of requests and responses to a web server that requires the user to authenticate via WIA (in this case, NTLM).
The user types in the address of an end point they’re trying to visit (say http://server:81) and the browser sends the first request with the following request headers (request and response headers courtesy of Fiddler).
The server looks at the request, notices that there’s no cookie or any kind of identity sent with it, and kindly tells the browser (401) that not just anyone can visit this URL. In the response headers, the web server asks the browser to establish the users identity using the NTLM protocol.
Request Response 2This is the second and final request/response in the WIA handshake. Its of note that the user still hasn’t done or seen anything, s/he’s still waiting on the screen to load…
The browser sends a 2nd request with the identity of the user according to the NTLM protocol. The server inspects the request, processes the NTLM response and decides that this user is indeed who s/he claims to be.
The server issues a response with a token that the client can use to identify themselves.
Request Response 3 (Not Shown)Finally, the client makes the last request using the token just obtained, to identify themselves. The server authenticates them and hands back a cookie associating the user with a logged in session. The client is finally authenticated.
Its worth mentioning that this handshake takes place extremely quickly and the user is often none the wiser. All the user truly notices (if anything at all) is that the page they just requested recognizes who they are.
As mentioned earlier, when it works it offers a great user experience, but there’s a couple things that can get in the way.
Internet ExplorerInternet Explorer is the only browser that works with WIA “out of the box”. Any browser that supports the required authentication protocol (NTLM, Kerberos, Negotiate, Digest) can authenticate against the server, but there are some special conditions that need to exist.
For IE to send an encrypted identity over the wire, WIA has to be enabled (it is by default). You can check to see whether WIA is enabled under Tools-> Internet Options->Advanced Tab.
In addition to WIA being enabled, one of the following needs exist:
- The site needs to be in the “Intranet Zone”. IE has a pretty simple test to verify this. Effectively it looks to see if there’s any periods/dots in the host name. For instance, http://someserver is in the intranet zone, but http://someserver.fullyqualified.com however is not (even thought they may both resolve to the same IP. As a result any IP address (e.g. 192.168.132.155) also won’t be in the intranet zone either.
- If the site isn’t in the intranet zone, it needs to be a trusted site for IE to send the user’s identity over the wire w/out prompting. You can see/manage trusted sites by going to: Tools->Internet Options->Security->Trusted Sites
FireFoxFirefox has no ideas of intranet zones like IE. If you want FireFox to trust a site and send over the user’s identity, you need to enlist the site as a trusted NTLM site (and ensure that NTLM is a usable protocol for WIA in IIS).
You do this by:
- Opening FireFox
- Type “about:config” into the address bar
- Edit the Network.automatic-ntlm-auth.trusted-uris property and add the URL of the site you’d like to trust. You can enter multiple URLs delimited by commas.
This browser should now be able to authenticate via NTLM.
ChromeAt the time of writing, Chrome doesn’t have have a way to seamlessly integrate with WIA (the current browser does support NTLM though). Unfortunately for the time being, Chrome users will always need to enter in their credentials.
SummaryWindows Integrated Authentication can be pretty slick in certain environments. While some if its protocols aren’t rock solid security wise, and many are proprietary, it provides one of the cheapest solutions for authentication that balances both maintenance and ease of use for the user.