Understanding Integrated Authentication in IIS

1. Understanding Integrated Authentication in IIS Chris Adams IIS Supportability Lead Microsoft Corp.

2. Agenda • Introduction to Integrated Authentication • Dynamics of NTLM Authentication • Dynamics of Negotiate Authentication • Demonstration One • Best Practices for Integrated Authentication • References

3. Introduction to Integrated Authentication • Introduced in Windows 2000 • Commonly referred to as “Windows Integrated Authentication” • Secure: It is considered secure because it does not transmit password “on the wire” • Internet Explorer preferred – • IF Basic and Integrated are both enabled, IE will use Integrated for security reasons

4. Introduction: Let’s review… • How authentication works in IIS • Request enters server core • Server core forwards to • anonymous provider. IIS builds • path (w3svc/1/root) and verifies • if anonymous is enabled. • Yes: Provide path and Anon. • users token to authorization • manager • No: IIS passes the path to each • provider to determine if • path has that provider enabled. • Each provider that is enabled returns to • Server core the appropriate header. Anonymous Server Core Basic Kerberos NTLM Digest Passport

5. Introduction… Negotiate NTLM Kerberos

6. Introduction to Integrated Authentication Platform information for Windows Integrated Windows NT 4: • Supports only NTLM (Not known as Windows Integrated) Windows 2000: • Supports Negotiate and NTLM Windows 2003: • Supports Negotiate and NTLM

7. Introduction to Integrated Authentication Metabase Property: AuthNTLM

8. Introduction to Integrated Authentication • How the appropriate integrated authentication is determined? NTAuthenticationProviders AuthNTLM Yes NO 401.3 Access Denied Negotiate NTLM

9. Dynamics of NTLM • Connection Oriented • Same Connection always used per request • HTTP Keep-Alives Required • Understanding Auth Dialog Boxes • NTLM, by default, doesn’t prompt • NTLM may prompt if original request fails with 401.1 • NTLM’s use of Domain\Username\Password • Domain and Username are always shared over the wire between client and server • Password is never – Always uses Hash of password • Authentication Header includes: • Domain\Username\HashedPassword

10. Dynamics of NTLM: Security • Why is NTLM authentication secure? • Hash Algorithm of password is unknown when hackers monitor the HTTP requests on the wire • If connections are broke, manipulated (by proxies), then NTLM fails

11. NTLM @ Work… Client Requests: One Connection Get /Default.HTM 1 3 Get /Default.HTM w/ AuthNTLM Get /Default.HTM w/ AuthNTLM Hashed 5 Server Responses: Same Connection 401 – Access Denied 2 401 – WWW Auth: NTLM 4 200 - OK 6

12. Dynamics of NTLM • NTLM at work… (previous slide) • IE Client requests a IIS resource (Anon) • IIS returns 401 with WWWAuthenticate Header saying NTLM • IE submits new request for a IIS resource with NTLM Authentication header (username) • IIS uses NT Authentication Header to build secret key and sends 401 with key back to client • IE submits new request for a IIS resource with NTLM Authentication header (username\password\hash of password) • IIS checks username\password\hash and matches, return 200 OK –or- 401.1 Login failed (IE prompts)

13. Dynamics of Negotiate • Why create another authentication protocol? • NTLM limitations • NTLM Tokens cannot be delegated • NTLM is proprietary and only supported by Windows platform • Is Negotiate a new protocol? • No, it is just a wrapper that allows either Kerberos or NTLM authentication based on client request

14. Dynamics of Negotiate Key Terms of Negotiate • Client: Internet Explorer • Server: IIS Server that is member of Active Directory Domain • Active Directory: • Key Distribution Center (KDC) for all clients • Ticket Granting Service: Issues all tickets (aka tokens)

15. Dynamics of Negotiate IIS Server Active Directory (KDC) The IIS server is started and when the server authenticates to domain (aka KDC) it receives it ticket. Ticket Granting Services

16. Dynamics of Negotiate Active Directory (KDC) Registered ServicePrincipalNames for CN=CA-WEBCAST-IIS,OU=Domain Controllers,DC= ca-webcast,DC=local: GC/ca-webcast-iis.ca-webcast.local/ca-webcast.local HOST/ca-webcast-iis.ca-webcast.local/CA-WEBCAST HOST/CA-WEBCAST-IIS HOST/ca-webcast-iis.ca-webcast.local HOST/ca-webcast-iis.ca-webcast.local/ca-webcast.local E3514235-4B06-11D1-AB04-00C04FC2DCD2/84bbfa08-5854-4729-80aa-56117bc4ecb6/ca -webcast.local ldap/84bbfa08-5854-4729-80aa-56117bc4ecb6._msdcs.ca-webcast.local ldap/ca-webcast-iis.ca-webcast.local/CA-WEBCAST ldap/CA-WEBCAST-IIS ldap/ca-webcast-iis.ca-webcast.local ldap/ca-webcast-iis.ca-webcast.local/ca-webcast.local NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/ca-webcast-iis.ca-webcast.local Setspn %computername%

17. Negotiate @ Work… Client Requests: One Connection Initial Client request for IIS resource anonymously KDC (Active Directory) 1 The Server esponse is 401 – WWWAuth Header for Negotiate 3 2 4 I need a ticket for The following service (aka HTTP\HOST) 3 6 If Service located in KDC, Secret Key shared with Client Shared 4 5 IIS Server 2 Using key provided, Client creates hash (key) and sends IIS 5 1 IIS uses secret key and verifies that password matches 6

18. Demonstration OneConfiguring a Process to use a Domain Accountand KerberosThe purpose of this demonstration is to show how a worker process identity set on a application pool affects authentication when the authenticated user uses the Negotiate protocol and Kerberos

19. References • IIS 6 Help Documentation • http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/standard/sec_auth_intwinauth.aspIIS 6 Deployment Guide • Load Balancing and Kerberos • http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/maintain/security/nlbsecbp.asp

20. Q & A