kerb_presentation

Document Sample
kerb_presentation Powered By Docstoc
					Kerberos and Windows Domain
            Logon
• Overview of the Windows Domain logon
  process
• Paying attention to what happens from when
  you press CTRL-ALT-Del to when the machine
  decided you have authenticated yourself
  properly
• Windows to Kerberos handoff
                Assumptions
• Windows 2003 Server domain
• Windows XP and Windows Vista clients
• Default (that is, Microsoft) domain logon
  GINA/setup (no smartcards, etc.)
• No additional Kerberos functionality
  – (no Kerberos 4 compatibility)
   Window XP vs. Windows Vista
• Vista and XP have different architectures for
  the logon process.
• They’re similar, but use differing processes
• I’ll display them in parallel and briefly explain
  the differences
• Once I’m done with the Windows portion I’ll
  come back and explain the Kerberos part.
Windows Logon Processes
        Client Machine Boot
• Power on the machine
• POST
• Windows bootstraps itself up
• Login screen comes up (CTRL-ALT-DEL) –
  winlogon.exe
• Machine locates domain controller
• Netlogon->DsGetDcName->DNSQuery->LDAP
     Windows XP logon overview
• Winlogon starts shell
• Winlogon calls MSGINA
• After user enters password, MSGINA passes
  username/pw back to winlogon
• Winlogon passes this info to the LSA
• LSA determines if the username/pw is local or
  domain by sending it to SSPI (note that other
  SSPs can be used here)
• SSPI gives it to Kerberos SSP, which talks to the
  domain (or throws “No Logon Server Available”)
    Windows Vista logon Overview
• Winlogon detects SAS and calls LogonUI
• LogonUI starts Credential Provider(s)
• LogonUI displays UI
• LogonUI gets password
• LogonUI passes password to Credential Provider
• If password OK, LogonUI passes the OK back to
  Winlogon
• Winlogon notifies the LSA
Windows XP                         Windows Vista
•   Winlogon detects SAS           • Winlogon detects SAS, calls
•   Winlogon starts shell            LogonUI
•   Winlogon calls MSGINA          • LogonUI starts Credential
                                     Provider(s)
•   After user enters password,
    MSGINA passes                  • LogonUI displays UI
    username/pw back to            • LogonUI gets password
    winlogon                       • LogonUI passes password to
•   Winlogon passes this info to     Credential Provider
    the LSA                        • If password OK, LogonUI
•   LSA gives info to SSPI           passes the OK back to
•   SSPI gives info to SSP           Winlogon
•   If correct, the OK is passed   • Winlogon notifies the LSA
    back to the LSA
       Kerberos Authentication
• After the Windows components above, the
  Kerberos negotiation starts.
• Computers: Client, KDC, Application Server
• KDC is domain controller
• Assumes a hostile network.
• This presentation assumes one realm.
                 Encryption
• 2k - 56b DES, default 128bit rc4
• XP- default is RC4, allows others, notably DES
• 2k and XP domains may not be able to use
  DES for NT compatibility reasons
• Vista: 256bit AES, TDES, SHA2
• Set in Domain Policy
Kerberos logon process
                       AS_REP

• Client computer sends an   • Preauthentication is usually
  AS_REQ message to the        required by Windows
  KDC.                       • This involves sending an
                               “authenticator” consisting
                               of an encrypted timestamp.
                   AS_REP
• Authentication Server on KDC replies to client
  with an AS_REP
                TGS_REQ
• Client computer sends a TGS_REQ to the TGS
  on the KDC
                    TGS_REP
• TGS responds to client   • Application server key
  with a TGS_REP             can be service or
                             system, depending on
                             what access is being
                             requested. There are
                             “service” keys and
                             “system” keys.
                  AP_REQ
• Client sends AP_REQ to Application Server
                     AP_REP
• If requested to,          • This allows mutual
  Application Server          authentication.
  sends AP_REP to client.   • Assuming all is OK,
                              application server sets
                              up access token for the
                              SID passed in the
                              AP_REQ
                  Cacheing
• Credentials are cached in
  HKEY_LOCAL_MACHINE\Security\Cache as a
  hash of the password hash
• Tickets are stored in a non-paged section of
  memory and are destroyed when user is
  logged off, or when machine shuts down.
  MS Technet articles of interest:

• http://technet2.microsoft.com/windowsserve
  r/en/library/4a1daa3e-b45c-44ea-a0b6-
  fe8910f92f281033.mspx?mfr=true
• http://www.microsoft.com/windowsserver20
  03/evaluation/overview/technologies/kerbero
  s.mspx