Sometimes it might be required to enable NTLM in IIS. One good reason for this could be some service suite (for example bunch of WCF service). As long you enable your services internally in your enterprise you should enable KERBEROS authentication only. This kind of authentication is internally in IIS called Windows Authentication or Windows Integrated Authentication. However in this context there are two different kind of Windows Integrated Authentication:
- Negotiate (or kerberos)
- Ntlm (or chalenge response)
Which kind of authentication will be used it is defined by target site. One site (application) can require NTLM, Negotiate or both. When some site requires NTLM and Kerberos (Negotiate)authentication following response would be returned by the site, when some client sends requests:
HTTP: Response, HTTP/1.1, Status Code = 401
ProtocolVersion: HTTP/1.1
StatusCode: 401, Unauthorized
Reason: Unauthorized
ContentLength: 1656
ContentType: text/html
Server: Microsoft-IIS/6.0
WWWAuthenticate: Negotiate
WWWAuthenticate: NTLM
If one authentication would be allowed (required), then one of last two self explaining entries in the response would appear in response. Fore more information about proticols teke a look here. To enable Windows Integrated Authentication authentication type in IIS7 start Internet Information Server Manager (simply start inetmgr.exe), select the wanted site or application and open authentication features.
If Windows Integrated Authentication is installed you will see following.
Here you can enable and disable it. If the wanted authentication type does not appear in the list you can install it by turning of windows features on.
After all you can set the required authentication mechanism on NTLM or Negotiate as shown at the next picture:
After that you can set the priority of providers. Next picture shows that KERBEROS is the preferred one. That means, if for example the browser can talk both protocols the kerberos will be used.
This was the simple and nice part of the story, because real troubles start just now. If you are very lucky, you are done now. According to morphs low, you are now on the beginning.
First problem you will get with KERBEROS when clients should access the site (service) by using of some specific alias like: http://myservice.testdomain.com. However your IIS host machine would be internally accessible as http://yourhost.testdomain.com. (yourhost is the hostname of the machine which host the IIS, which will host the service.)
If the client cannot authenticate, because of KERBEROS do following:
c:\>setspn -L yourhost
This command will list registered SPN-s:
Registered ServicePrincipalNames for CN=YOURHOST,CN=Computers,DC=TESTDOMAIN,DC=COM:
MSSQLSvc/YOURHOST.TESTDOMAIN.COM:MSSQLSERVER2008
RestrictedKrbHost/DADO-NB0
HOST/YOURHOST
RestrictedKrbHost/YOURHOST.TESTDOMAIN.COM
HOST/YOURHOST.TESTDOMAIN.COM
This is default configuration which will not work. To enable KERBEROS to authenticate aganist external qualified name like myservice.testdomain.com do following:
c:\>setspn -A HTTP/myservice.testdomain.com YOURHOST
Optionally, you can define more qualified names:
c:\>setspn -A HTTP/myservice YOURHOST
To be sure that all is done, enlist registered SPNS-s again:
c:\>setspn -L yourhost
This should be the result now:
Registered ServicePrincipalNames for CN=YOURHOST,CN=Computers,DC=TESTDOMAIN,DC=COM:
HTTP/myservice.testdomain.com
HTTP:/myservice
MSSQLSvc/YOURHOST.TESTDOMAIN.COM:MSSQLSERVER2008
RestrictedKrbHost/DADO-NB0
HOST/YOURHOST
RestrictedKrbHost/YOURHOST.TESTDOMAIN.COM
HOST/YOURHOST.TESTDOMAIN.COM
After that restart your machine and pray. I mean this seriously, because changes will not take effect immediately even after restart. Sometimes I was even giving up, and then after few hours it just worked.
SPN-s in Win 7 and Win Server 2008 R2
In Windows 7 and Windows Server 2008 R2 some things might be slightly different.Two new types of service accounts are available in Windows Server® 2008 R2 and Windows 7. The managed service account and the virtual account. The managed service account is designed to provide crucial applications such as SQL Server and IIS with the isolation of their own domain accounts, while eliminating the need for an administrator to manually administer the service principal name (SPN) and credentials for these accounts. Virtual accounts in Windows Server 2008 R2 and Windows 7 are "managed local accounts" that can use a computer's credentials to access network resources. Unlike with normal local computer and user accounts, the administrator does not have to complete complex SPN management tasks to use managed service accounts.
If you have survived SPN-step you could be done. But, if you develop internet applications like Silverlight or ASP.NET, which should invoke operations on your service, KERBEROS (Negotiate) cannot be used. The reason is that KERBEROS is not really internet capable protocol, because KERBEROS required ports are by default blocked by firewalls out of your enterprise.
In this case your authentication adventure is not completed yet. As next, you should enable NTLM protocol. This one is not that safe as Kerberos, but it can be used in internet as long browsers supports it (for example IE and Firefox).
Usually, NTLM doesn’t make so much troubles like Kerberos. Unfortunately, if it does, it could be much, much more complicated than Kerberos. I have experienced two possible issues with NTLM: DNS configuration and using of Windows 7 (or Win Server 2008 R2)
NTLM Dns Configuration issue
I figured out that if myservice entry in DNS server is of host type and the machine which host IIS does not have the same name (in our example it has the name: yourhost) the authentication will fail with code: 401.1. Usually you will not find any more detailed information about the reason, why this has happened. I was digging in event logs, IIS logs etc, and didn’t find anything.
The solutions is more than simple. Just reconfigure DNS entry myservice to be an alias which points to yourhost. After that all will work immediately, if you are not lucky user of Windows 7 or Windows Server 2008 R2.
One more thing in this context is important. When you use the fully qualified domain name (FQDN) or a custom host header to browse a local Web site in IIS 6 or IIS7 and the Web site uses Integrated Authentication and has a name that is mapped to the local loopback address you may encounter HTTP 401.1 - Unauthorized: Logon Failed again. If all other staffs are configured correctly this will only happen while accessing the site directly from machine which hosts the site. If you can access the site from some other machine there is workaround described here.
Trusted Delegation
Another very common case is enabling of trusted delegation. Trusted delegation can/should be enabled for the machine and user. Both tasks can be performed by using of MMC of Active Directory. Usually, you will have to enable the machine yourhost for delegation. If this is not the case you will notice 401.1 error code.
Depending on your scenario, sometimes it is also required to enable the user for trusted delegation. This sis the case when your service performs impersonation and it has to access resources which are physically located on another machine (not on yourhost).
Posted
Aug 16 2009, 08:06 PM
by
Damir Dobric