****
*
*
*
*







*
*
                                      
*
*
Windows Server



    

How Kerberos works    

*
*

*
*

How Kerberos works



Apr
21

How Kerberos works

 

1) Kerberos 5: Only Supported for IE 5.5+

Kerberos 5 is supported for Internet Explorer browsers continuing IE 5.5 and then later browsers.

2) Kerberos doesnot works on Internet

            This is important to note that the Kerberos protocol is not supported on Internet.

 

Kerberos is an open authentication Protocol developed by MIT. For local machines that aren't actively participating in a domain, Windows NT LAN Manager protocol is still utilized to verify a user's name and password before granting system access. However, in domain environments, Microsoft has coupled Active Directory closely with Kerberos. Once access is granted, tickets that permit specific access to other system resources within the domain are exchanged

 

The Kerberos protocol name is based on the three- headed dog figure from Greek mythology known as Kerberos

 

The three heads of Kerberos comprise the

 

1. Key Distribution Center (KDC)

2. Client User

3. Server with the desired service to access

clip_image001

 

 

The KDC is installed as part of the domain controller and performs two service functions: the Authentication Service (AS) and the Ticket-Granting Service (TGS)

 

Three exchanges are involved when the client initially accesses a server resource:

 

1. AS Exchange

2. TGS Exchange

3. Client/Server (CS) Exchange

clip_image002

           

 

AS Exchange

 

When initially logging on to a network, users must negotiate access by providing a log-in name and password in order to be verified by the AS portion of a KDC within their domain. The KDC has access to Active Directory user account information. Once successfully authenticated, the user is granted a Ticket to Get Tickets (TGT) that is valid for the local domain. The TGT has a default lifetime of 10 hours and may be renewed throughout the user's log-on session without requiring the user to re-enter his password. The TGT is cached on the local machine in volatile memory space and used to request sessions with services throughout the network.

 

When the user logs on to the domain a time stamp will be encrypted using the user's password hash as an encryption key. If the KDC reads a valid time when using the user's password hash (stored in the Active Directory) to decrypt the time stamp, the KDC knows that request isn't a replay of a previous request

 

If the KDC approves the client's request for a TGT, the reply (referred to as the AS reply) will include two sections:

 

A TGT encrypted with a key that only the KDC (TGS) can decrypt

A session key encrypted with the user's password hash to handle future communications with the KDC

 

Because the client system cannot read the TGT contents, it must blindly present the ticket to the TGS for service tickets.

 

 

TGS Exchange

 

The user presents the TGT to the TGS portion of the KDC when desiring access to a server service. The TGS on the KDC authenticates the user's TGT and creates a ticket and session key for both the client and the remote server. This information, known as the service ticket, is then cached locally on the client machine.

 

The TGS receives the client's TGT and reads it using its own key. If the TGS approves of the client's request, a service ticket is generated for both the client and the target server. The client reads its portion using the TGS session key retrieved earlier from the AS reply. The client presents the server portion of the TGS reply to the target server in the client/server exchange coming next.

 

 

Client/Server Exchange

 

Once the client user has the client/server service ticket, he can establish the session with the server service. The server can decrypt the information coming indirectly from the TGS using its own long-term key with the KDC. The service ticket is then used to authenticate the client user and establish a service session between the server and client. After the ticket's lifetime is exceeded, the service ticket must be renewed to use the service.

 

 

Client/Server Exchange Detail

 

The client blindly passes the server portion of the service ticket to the server in the client/server request to establish a client/server session. The target server returns a time stamp encrypted using the service ticket session key. If the time stamp decrypts correctly, not only has the client authenticated himself to the server, but the server also has authenticated itself to the client. The target server never has to directly communicate with the KDC. This reduces downtime and pressure on the KDC.

 

 

The Log-in Process

 

A TGT and a service ticket are needed to access services on remote computers, but they are also required to successfully log on to a local system. When the log-on window appears, password encryption using a one-way hash algorithm occurs immediately and negotiations commence with the KDC for a valid TGT and service ticket. The process is the same as accessing a remote service. An access token is created for the user containing all security groups to which they belong. This access token is attached to the user's log-on session and is subsequently inherited by any process or application the user starts.

 



No TrackBacks

TrackBack URL: http://www.skar.us/site/mt-tb.cgi/3206

Leave a comment








*
*

ebhakt
Author Bio          ★★★★★

Author Name:         ebhakt
Author Location:    India
Author Rank:          Writer
Author Status:        
The Green leave stands!!


*
*
*
*
****



*****



    Desktop
  • eBooks
  • Games
  • Softwares
  • Tools
  • Tweaks
  • Wallpapers
  • Warez
    PDA
  • Games
  • Tools
  • Wallpapers
    System Administration
  • dll Center
  • Scripts
  • Tools
  • .extensions database
  • Write-up
    more...
  • Download Database
  • Jobs
  • Lists
  • Polls
  • Glossary

01000011 01110010 01100001 01100011 01101011 01111010 01101000 01100001 01100011 01101011