Showing posts with label Windows. Show all posts
Showing posts with label Windows. Show all posts

Monday, 7 May 2012

Troubleshooting Kerberos with Tools

Here are a few tools that can be used to diagnose Kerberos issues, along with a brief paragraph explaining what each tool does.

Enable Kerberos Logging for Windows XP

http://support.microsoft.com/kb/262177

Microsoft Windows 2000, Windows Server 2003, and Windows Server 2008 offer the capability of tracing detailed Kerberos events through the event log mechanism. You can use this information when you troubleshoot Kerberos. This article describes how to enable Kerberos event logging.

Insight for Active Directory v1.01

http://technet.microsoft.com/en-us/sysinternals/bb897539

ADInsight is an LDAP (Light-weight Directory Access Protocol) real-time monitoring tool aimed at troubleshooting Active Directory client applications. Use its detailed tracing of Active Directory client-server communications to solve Windows authentication, Exchange, DNS, and other problems.

ADInsight uses DLL injection techniques to intercept calls that applications make in the Wldap32.dll library, which is the standard library underlying Active Directory APIs such ldap and ADSI. Unlike network monitoring tools, ADInsight intercepts and interprets all client-side APIs, including those that do not result in transmission to a server. ADInsight monitors any process into which it can load it’s tracing DLL, which means that it does not require administrative permissions, however, if run with administrative rights, it will also monitor system processes, including windows services.

Process Monitor

http://technet.microsoft.com/en-us/sysinternals/bb896645

Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. It combines the features of two legacy Sysinternals utilities, Filemon and Regmon, and adds an extensive list of enhancements including rich and non-destructive filtering, comprehensive event properties such session IDs and user names, reliable process information, full thread stacks with integrated symbol support for each operation, simultaneous logging to a file, and much more. Its uniquely powerful features will make Process Monitor a core utility in your system troubleshooting and malware hunting toolkit.

LogMan

http://technet.microsoft.com/en-us/library/cc753820(v=ws.10).aspx

Logman creates and manages Event Trace Session and Performance logs and supports many functions of Performance Monitor from the command line.  Filters can be added to log Kerberos events.

KerbTray

http://www.microsoft.com/en-us/download/details.aspx?id=23018

This tool is used to display ticket information for a given computer running the Kerberos protocol.

KList

http://www.microsoft.com/en-us/download/details.aspx?id=11583

View and deleting the Kerberos tickets granted to the current logon session.

Setspn

http://www.microsoft.com/en-us/download/details.aspx?id=25233

http://support.microsoft.com/kb/326985

This command-line tool allows you to manage the Service Principal Names (SPN) directory property for an Active Directory™ directory service account. SPNs are used to locate a target principal name for running a service.

MIT Kerberos Client

http://web.mit.edu/kerberos/dist/

Network Identity Manager (NetIdMgr) is a graphical tool designed to simplify the management of network identities and their credentials which are used by network authentication protocols while providing secure access to network services.

When NetIDMgr is used with Kerberos v5 each network identity is a unique Kerberos principal name and the credentials are Kerberos v5 tickets. Kerberos v5 tickets can be used by NetIDMgr to obtain Andrew File System (AFS) tokens and X.509 public key certificates if the appropriate plug-ins are installed.

Process Explorer

http://technet.microsoft.com/en-us/sysinternals/bb896653

Ever wondered which program has a particular file or directory open? Now you can find out. Process Explorer shows you information about which handles and DLLs processes have opened or loaded.

The Process Explorer display consists of two sub-windows. The top window always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that Process Explorer is in: if it is in handle mode you'll see the handles that the process selected in the top window has opened; if Process Explorer is in DLL mode you'll see the DLLs and memory-mapped files that the process has loaded. Process Explorer also has a powerful search capability that will quickly show you which processes have particular handles opened or DLLs loaded.

The unique capabilities of Process Explorer make it useful for tracking down DLL-version problems or handle leaks, and provide insight into the way Windows and applications work.

DelegConfig v1

http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1434

This is an ASP.NET application used to help troubleshoot and configure IIS and Active Directory to allow Kerberos and delegating Kerberos credentials.

Kerberos SPN Viewer

http://blogs.msdn.com/b/sansom/archive/2009/10/12/kerberos-spn-viewer-and-helper-tool-sample.aspx

Simplify listing the ServicePrincipalName (SPN) and an integrated helper tool which can help us find out what SPN should we set based on the configuration that we are using.

Kinit?

http://docs.oracle.com/javase/1.4.2/docs/tooldocs/linux/kinit.html

NetMon

http://www.microsoft.com/en-us/download/details.aspx?id=4865

Tool to allow capturing and protocol analysis of network traffic.

WireShark

http://www.wireshark.org/

Network Protocol analyzer for Windows and Unix.

Tokensz

http://www.microsoft.com/en-us/download/details.aspx?id=1448

This tool will compute the maximum token size and is used to test whether a system may exhibit the issue described in KB article 327825.

Troubleshooting Kerberos Problems

http://technet.microsoft.com/en-us/library/cc786325(v=ws.10).aspx

https://developers.google.com/search-appliance/kb/secure/kerberos-troubleshooting

http://www.microsoft.com/en-us/download/details.aspx?id=21820

http://blogs.technet.com/b/askds/archive/2008/05/14/troubleshooting-kerberos-authentication-problems-name-resolution-issues.aspx

Kerberos: Authentication in Windows


Kerberos (v5) is a Network Authentication Service used by Microsoft Windows Server since 2000 that provides Single Sign On (SSO) where the user only enters their password once to access the network of servers.

The name is taken from the three headed dog in Greek mythology, due to its three pronged nature of Client, Authentication server (KDC) and Resource Server.

Kerberos assumes and protects against an open network in which packets can be sniffed and altered.

The full specification can be found here: http://tools.ietf.org/html/rfc4120

Benefits

  • Mutual authentication
  • Faster connections between client and servers, thanks to SSO (through the use of session tickets)
  • Delegation aka Impersonation

Stages

There are three stages to Kerberos in Windows, each with their own request/response message:
  • Authentication Service (AS) exchange
  • Ticket Granting Service (TGS) exchange
  • Client/Server (CS) exchange (messages are known as AP: Application Privilege)
image

Authentication Service (AS) exchange


1. The user providing a username and password.

2. The password is one way hashed and stored locally as the secret key.

3. KRB_AS_REQ message sent from client to KDC Server, consisting of:
  • Username (Client Principal Name / User Principal Name).
  • Timestamp (for pre-authentication, it's use can be disabled for a user on the AD server).  Its use prevents Replay attacks.  Client clock is sync’d with server, with the allowance of 5 min skew.
  • Kerberos target principle name (realm, a Kerberos grouping that uses the same key [the users password]).
  • Requested life time.
  • Nonce, a random message number to prevent replay attacks.
4. KRB_AS_REP message sent back from server to client, consisting of:
  • Part one: Encrypted with the users password containing:
    1. User-TGS key (generated by the KDC).
    2. Kerberos target principle name (realm).
    3. Ticket lifetime.
  • Part Two: The TGT, encrypted using a TGS key generated by the KDC so that only the server can open it (even though it is stored by the client for use during further transactions), containing:
    1. User-TGS key (which is not retained by the KDC, but its presence within the TGT means it is available when required).
    2. Client principal name.
    3. Ticket lifetime.
    4. KDC timestamp.
    5. Client IP address (taken from the initial KRB_AS_REQ).
Part one of the message can only be used if successfully decrypted by the client using their password.

Ticket Granting Service (TGS) exchange


1. The service ticket request (KRB_TGS_REQ) from client to server containing:
  • Service principal name.
  • Requested lifetime.
  • TGT, still encrypted with the TGS key.
  • Authenticator, encrypted with the user-TGS key and containing a client timestamp, guaranteeing that the request originated from the client.
2. The KRB_TGS_REP service ticket reply is again in two parts:
  • Part one is encrypted with the user-TGS key (taken from the TGT by the KDC) and contains:
    1. Service principal name.
    2. Ticket lifetime.
    3. User service key (encrypted with a user-TGS session key, generated by the KDC).
  • Part two is the Service Ticket (ST), encrypted using the service-TGS key and contains:
    1. User service key (encrypted with a user-TGS session key, generated by the KDC).
    2. Client principal name.
    3. Ticket lifetime.
    4. KDC timestamp.
    5. Client IP address.

Client/Server (CS) exchange

(messages are known as AP: Application Privilege)


1. When the client requires access to the service, the AP exchange KRB_AP_REQ contains:
  • The service ticket (ST), still encrypted using the service-TGS key
  • An authenticator (encrypted with the user-service key). 

Conclusion


So that's how Kerberos works.  The key points to remember are that:
  • AS exchange occurs at logon, providing the client with a TGT.
  • The TGT allows the client to enter a TGS exchange (which authenticates the client), returning an ST.
  • The ST identifies the authenticated client to a service following which the service will provide access (but only if the client passes the service's own authorisation criteria).
  • Messages are encrypted so only the KDC can read the TGT & only the service can read the ST.