Professional Documents
Culture Documents
Agenda
Demonstration One
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
Kerberos
NTLM Digest Passport
Server Core
Each provider that is enabled returns to Server core the appropriate header.
Introduction
Negotiate
Kerberos
NTLM
Windows 2000:
Windows 2003:
NTAuthenticationProviders
401.3
Access Denied
Negotiate
NTLM
Dynamics of NTLM
Connection Oriented
Same Connection always used per request HTTP Keep-Alives Required NTLM, by default, doesnt prompt NTLM may prompt if original request fails with 401.1 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
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
NTLM @ Work
Get /Default.HTM
200 - OK
Dynamics of NTLM
6.
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)
Dynamics of Negotiate
NTLM limitations
NTLM Tokens cannot be delegated NTLM is proprietary and only supported by Windows platform
No, it is just a wrapper that allows either Kerberos or NTLM authentication based on client request
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)
Dynamics of Negotiate
IIS Server
Active Directory
The IIS server is started and when the server authenticates to domain (aka KDC) it receives it ticket. Ticket Granting Services
(KDC)
Dynamics of Negotiate
Active Directory (KDC)
Registered ServicePrincipalNames for CN=CAWEBCAST-IIS,OU=Domain Controllers,DC= ca-webcast,DC=local: GC/ca-webcast-iis.ca-webcast.local/cawebcast.local HOST/ca-webcast-iis.ca-webcast.local/CAWEBCAST HOST/CA-WEBCAST-IIS HOST/ca-webcast-iis.ca-webcast.local HOST/ca-webcast-iis.ca-webcast.local/cawebcast.local E3514235-4B06-11D1-AB0400C04FC2DCD2/84bbfa08-5854-4729-80aa56117bc4ecb6/ca -webcast.local ldap/84bbfa08-5854-4729-80aa56117bc4ecb6._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/cawebcast.local NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/cawebcast-iis.ca-webcast.local
Setspn %computername%
Negotiate @ Work
Initial Client request for IIS resource anonymously
The Server esponse is 401 WWWAuth Header for Negotiate I need a ticket for The following service (aka HTTP\HOST) If Service located in KDC, Secret Key shared with Client Using key provided, Client creates hash (key) and sends IIS IIS uses secret key and verifies that password matches
IIS Server
Demonstration One
Configuring a Process to use a Domain Account and Kerberos
The 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
References
Q&A