How Kerberos works

 Kerberos in Windows -An Overview

Introduction 

Kerberos is used since a long time as an authentication protocol in the UNIX world.It entered the Windows family with Windows 2000 and is used with all the OS releases till date. Windows Active Directory uses Kerberos as a default authentication protocol.Its major advantage over other authentication schemes is its interoperability with Unix systems.When coupled with a strong password, Kerberos is considered to be the toughest to break through.Kerberos V5 is the current version used in the Windows Family.

Architecture

Kerberos Architecture typically works on the concept of mutual authentication. Unlike other authentication techniques kerberos authentication verifies the identity of the client as well as the server. NTLM misses this techinique of validation as it has no provision of validating the server.

Architectural Dependencies

Operating System – Windows brought kerberos in its family since Windows 2000 so operating systems prior to Windows 2000 would fail to use kerberos.

Network Connectivity – For Kerberos to function correctly it is essential that there exist a TCP IP connectivity between client and the domain controller

DNS – Client in a kerberos process uses FQDN(Fully Qualified Domain Name) of the Domain Controller to access resources hence DNS should exist and should be configured properly.

ADS 2000 or above – Properly configured ADS is essential for Kerberos as it has its KDC and TGS components associated with it.Windows 2000 /2003 /2008 domain environment can use kerberos.

Time Synchronization – For Kerberos to function correctly all systems and servers should be using the same source for time synchronization. An authoritative time source (usually domain contoller in AD environements) is necessary as it would make sure that the entire network has the same time synchronized.

SPNs – Every service which uses kerberos needs to have a Service Principal Names set for it so as to identify the service on the network. Clients locate this service only by identifying these SPNs.


Let’s walk through the process that functions whenever a user logs on to the client system in a typical Domain Environment.


User Enters credentials on the logon screen which is sent to Winlogon to the LSA(local Security Authority) for proccessing.

The LSA passes this info to Kerberos (kerberos.dll) through SSPI (Security Server Provider interface- Secur32.dll).

This information along with the encrytped timestamp is sent to the KDC (Key Distibution Center) A TGT (Ticket-granting Ticket) is requested along with this inforamtion.

The KDC decrypts the provided information and Issues a TGT.The issued TGT is encrypted and sent to client along with the SID of the user Account and SIDs of its associated groups.

*TGT typically contains session key, account name for the authenticated user and maximum ticket life time.

Using this TGT client requests a service ticket from the Kerberos Service on the domain Controller.

Domain Controller using the Ticket Granting Service issues an encrypted service ticket to the client.

Client uses this service ticket to access resources over the LAN which provides user indentity info and associated SID info for permissions.


Tickets received by the client are locally cached and can be used till their expiry period.In the event of expiry LSA negotiates with the KDC for ticket renewal.



Summary

Kerberos provides enhanced authentication for the distributed computing environment and standardization to interoperate with other operating systems. This MIT Developed authentication protocol is widely used in all operating system and comes as default with windows Active directory Environment. 

Comments

Post a Comment

Popular posts from this blog

Risk categorization on ad trust

 what would be defined as high risk in terms of trust A trust should be treated as **high risk** when it meaningfully increases the chance of lateral movement, privilege escalation, or cross-boundary compromise, especially if it extends access between forests or to sensitive production environments.[1][2] In practical audit terms, high risk usually means the trust weakens the security boundary, is difficult to monitor tightly, or depends on legacy settings and exceptions that expand exposure.[3][4] ## High-risk indicators A trust is typically high risk if any of the following apply:[1][5][6] - It is a **forest trust** or crosses a strong security boundary, because that expands the reachable attack surface.[1][2] - It allows broad authentication rather than **selective authentication**, meaning users from the trusted side can authenticate to many systems by default.[5][6] - **SID filtering** is disabled, weakened, or temporarily turned off for migration purposes.[4][7] - The trusted...
Read more

AD trust register

An AD trust register should be a controlled inventory of every trust relationship in your environment, with enough detail to answer **what exists, why it exists, who owns it, and when it was last validated**. At minimum, it should capture the trust’s type, direction, transitivity, source and target domains/forests, and security settings such as selective authentication or SID filtering where applicable [1][2]. ## Recommended columns A practical trust register usually includes these fields: | Field | Purpose | |---|---| | Trust ID | Unique identifier for tracking and audit references. | | Trust name / target | The other domain or forest in the trust. | | Source domain / forest | Your side of the relationship. | | Trust type | Domain, forest, external, realm, etc. [3][1] | | Direction | One-way incoming, one-way outgoing, or two-way [3][2] | | Transitivity | Transitive or non-transitive [3][1] | | Authentication model | Selective authentication or forest-wide authentication [1] | | SID f...
Read more

Ad control catalog

  # Active Directory Security Framework Detailed Control Catalog ## Purpose This document is an expanded draft of the Active Directory security framework with individual controls listed under each control domain so the framework can be used as the basis for an auditable control register, control testing workbook, or management review package.[1][2][3] The control statements are designed to be tailored to the organization’s actual implementation status and evidence sources while retaining mapping to recognized standards and vendor guidance.[1][2][4] ## How to use this catalog Each control should be assigned a unique internal control ID, owner, implementation status, review frequency, and evidence source during the next draft iteration.[3][2] The standards mapping shown here is intended as a practical starting point rather than a legal or certification opinion, and it should be validated against the organization’s chosen compliance framework.[3][5] ## Standards basis This draft uses ...
Read more