none
Kerberos - MIT and Heimdal

    Question

  • Hi Team,

    I was going through the technical documentation where I found that Kerberos is available with 2 flavours MIT and Heimdal.

    MS is working on MIT and Heimdal is used by different org like Juniper.

    I searched a lot but could not able to find main difference between MIT and Heimdal.

    Can you please help me with the same.

    Kind Regards,

    Dhruv

    Friday, April 1, 2011 8:50 AM

Answers

  • Hi Dhruv,

    Basically Kerberos iterations are all the same offering a trusted third party, ticket based authentication scheme. It's named after the 3-headed beast guarding the gates of heides, Cerberus, hence the 3 pieces of the authentication process, the client, the server, and the trusted third party. I like to describe it in class as the following:

    Tony, a business man in north Jersey, knows of a guy in Miami, Joe, that is selling a product he can resell in NY. However, he doesn't know Joe. TOny knows a guy in Chicago named Paulie, who knows Joe. Tony gives Paulie a call asking if he can hook him up. Paulie says, sure, because I know you, and we've done business together, and trust you. Here's Joe's number. I also call Joe to let him know you are calling.

    Client = Tony
    Server = Joe
    Trusted 3rd Party = Paulie

    All three itereations of Kerberos v5 do the same job, but slightly different. I believe they can be set to interoperate, but I haven't researched it that far. My best guess is Microsoft went with MIT's version of Kerberos v5 for Unix Realms interoperability, especially for SSO (single sign on), since Unix NFS also uses Kerberos v5, and more so because MIT's version has more application usage support, was created long ago, and is a known, stable product with active support and active, continuous development by a large team. That would be my guess why Unix (any flavor), went with it.

    I believe MIT is the oldest, being around since the 80's, hence it's enterprise stability and strong development and support.

    Here's something I did read that may be of interest: "Heimdal does not have a functioning replay cache, so if your app needs that you must go with MIT." Read more with this good summary:

    Heimdal or MIT kerberos?
    http://mailman.mit.edu/pipermail/kerberos/2004-October/006438.html

     

    Here are additional links:

    Kerberos (protocol) - From Wikipedia, the free encyclopedia
    http://en.wikipedia.org/wiki/Kerberos_(protocol)

    What is Heimdal? (Latest v1.4)
    Heimdal is an implementation of Kerberos 5 (and some more stuff) largely written in Sweden (which was important when we started writing it, less so now). It is freely available under a three clause BSD style license.
    http://www.h5l.org/

    What is Shishi Kerberos?
    Shishi, a free implementation of the Kerberos 5 network security system.
    http://josefsson.org/shishi/

    Ace

     

    Late edit: oops, sorry, you had already posted the http://www.h5l.org/ link. But I had re-posted it illustrating there are other versions out there. The MIT version is more enterprise ready and much more stable and proven than the others, and provide transparent application support, which are big advantages over the other versions.
    Ace

     


     

    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services

     

     

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.



    Hi Ace,

     

    Thank you for detailed explanation.

    I want to correct small point from the above that MIT cannot be used to implement SSO, thus all Unix based machines have to use Heimdal, as far Juniper SSL VPN device is using since it is a Linux device.

    However, apart replay cache I guess there is a difference between the 2 wrt to trust relationship.

    I have posted this question to my internal team regadring the same.

    Un-confirmed answer:

    A is a parent domain : B and C are 2 child domains

    A trust B and C, but B and C do not trust each other under Heimdal so we need to make a direct trust ( Kind of Short Cut Trust)

    Note : This is a unconfirmed point. Please wait.

    Regards,

    Dhruv


    Editing again::: ************************

    Ace, you are correct about Cace reply :-)

    http://k5wiki.kerberos.org/wiki/Projects/replay_cache_collision_avoidance

    Cheers !!

    Dhruv

     

    • Marked as answer by Dhruv.tech Friday, April 8, 2011 10:39 AM
    Wednesday, April 6, 2011 8:59 PM
  • Hi Ace,

    Thank you for detailed explanation.

    I want to correct small point from the above that MIT cannot be used to implement SSO, thus all Unix based machines have to use Heimdal, as far Juniper SSL VPN device is using since it is a Linux device.

    However, apart replay cache I guess there is a difference between the 2 wrt to trust relationship.

    I have posted this question to my internal team regadring the same.

    Un-confirmed answer:

    A is a parent domain : B and C are 2 child domains

    A trust B and C, but B and C do not trust each other under Heimdal so we need to make a direct trust ( Kind of Short Cut Trust)

    Note : This is a unconfirmed point. Please wait.

    Regards,

    Dhruv


    Editing again::: ************************

    Ace, you are correct about Cace reply :-)

    http://k5wiki.kerberos.org/wiki/Projects/replay_cache_collision_avoidance

    Cheers !!

    Dhruv


    Hhi Dhruv,

    In a multidomain AD forest, and I assume that's what you were referring to with the Domain A, B and C scenario, that AD creates a default two-way transitive trusts between all domains and trees in a forest. In such a scenario, even wtih AD, Domain C does not directly trust Domain B, but it does indirectly through the trust path both going through it's parent. You can shorten the trust path by creating a shortcut trust. I don't think whether being MIT or Heimdal would have anything to do with it in this scenario, since even in AD, Kerberos authentication is domain specific (each domain has a TGTS running granting a WT to each workstation), but because of the trust, there's pass-through authentication, hence why any cross domain authentication has to go through the "trust path" of course, where the workstation ticket is passed on to the next domain in the path until it reaches its final target.

    So I'm not sure about that point above, but I just wanted to point out how AD basically works. Maybe the following will help?

    Click on the image below for a larger view to see how kerb pass thru works between an AD domain and Unix Realm. Image from:
    Windows Active Directory Kerberos Interoperability
    http://www.itcs.umich.edu/windows-forest/w2k-kerberos.php

     

    Kerberos Pass-Thru

     

    The following shows trust transitivity in an AD forest. From:
    MIcrosoft: Trust Transitivity:
    http://technet.microsoft.com/en-us/library/cc739693(WS.10).aspx

    A two-way, transitive trust path connects domains

     

    And here is how a user in one domain access resources in another domain and how the Kerberos service works with the Kerberos TGT service in each domain: From:
    Microsoft - Kerberos Explained:
    http://technet.microsoft.com/en-us/library/bb742516.aspx

     

    Bb742516.kerb03(en-us,TechNet.10).gif  

    Bb742516.kerb04(en-us,TechNet.10).gif

     

    Ace


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    • Marked as answer by Dhruv.tech Friday, April 8, 2011 10:39 AM
    Thursday, April 7, 2011 10:08 PM

All replies

  • Below links might help you.

    http://mailman.mit.edu/pipermail/kerberos/2004-October/006438.html

    http://www.informit.com/guides/content.aspx?g=security&seqNum=35


    Regards


    Awinish Vishwakarma| MY Blog

    Disclaimer: This posting is provided AS-IS with no warranties or guarantees and confers no rights.
    Friday, April 1, 2011 9:06 AM
    Moderator
  • From: http://freebsd.active-venture.com/handbook/kerberos5.html

    The major difference between the <acronym class="ACRONYM">MIT</acronym> and Heimdal installs relates to the <tt class="COMMAND">kadmin</tt> program which has a different (but equivalent) set of commands and uses a different protocol. This has a large implications if your <acronym class="ACRONYM">KDC</acronym> is <acronym class="ACRONYM">MIT</acronym> as you will not be able to use the Heimdal <tt class="COMMAND">kadmin</tt> program to administer your <acronym class="ACRONYM">KDC</acronym> remotely (or vice versa, for that matter).

    The client applications may also take slightly different command line options to accomplish the same tasks. Following the instructions on the <acronym class="ACRONYM">MIT</acronym> Kerberos web site (http://web.mit.edu/Kerberos/www/) is recommended. Be careful of path issues: the <acronym class="ACRONYM">MIT</acronym> port installs into <tt class="FILENAME">/usr/local/</tt> by default, and the ``normal'' system applications may be run instead of <acronym class="ACRONYM">MIT</acronym> if your <tt class="ENVAR">PATH</tt> environment variable lists the system directories first.

    Note: With the <acronym class="ACRONYM">MIT</acronym> <tt class="FILENAME">security/krb5</tt> port that is provided by FreeBSD, be sure to read the <tt class="FILENAME">/usr/local/share/doc/krb5/README.FreeBSD</tt> file installed by the port if you want to understand why logins via <tt class="COMMAND">telnetd</tt> and <tt class="COMMAND">klogind</tt> behave somewhat oddly. Most importantly, correcting the ``incorrect permissions on cache file'' behavior requires that the <tt class="COMMAND">login.krb5</tt> binary be used for authentication so that it can properly change ownership for the forwarded credentials.

    --

    Paul Bergson

    MVP - Directory Services

    MCITP: Enterprise Administrator

    MCTS, MCT, MCSE, MCSA, Security+, BS CSci

    2008, Vista, 2003, 2000 (Early Achiever), NT4

    http://www.pbbergs.com    Twitter @pbbergs

    http://blogs.dirteam.com/blogs/paulbergson

     

    Please no e-mails, any questions should be posted in the NewsGroup. This

    posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, April 1, 2011 12:03 PM
    Moderator
  • Hi dhruv,

    Paul and Awinish gave you some good info about the differences. Is there a specific task you're trying to accomplish with the Junipers to communicate to AD? Don't the Junipers have some sort of built-in AD utility or function to communicate with AD?

    Ace


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    Friday, April 1, 2011 2:59 PM
  • Hi Team,

    Thank you all for pitching in for this issue.

    I went through the links and could not come to any conclusion about the difference between these 2.

    Kerberos is a open source protocol and 2 major companies have MIT and Heimdal.

    I went through the RFC http://www.ietf.org/rfc/rfc4120.txt which explain the difference wrt to KRB_CRED message.

        When constructing a KRB_CRED message for
       inclusion in a GSSAPI initial context token, the MIT implementation
       of Kerberos will not encrypt the KRB_CRED message if the session key
       is a DES or triple DES key.  For interoperability with MIT, the
       Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI
       token if it is using a DES session key.  Starting at version 1.2.5,
       MIT Kerberos can receive and decode either encrypted or unencrypted
       KRB_CRED tokens in the GSSAPI exchange.  The Heimdal implementation
       of Kerberos can also accept either encrypted or unencrypted KRB_CRED
       messages.  Since the KRB_CRED message in a GSSAPI token is encrypted
       in the authenticator, the MIT behavior does not present a security
       problem, although it is a violation of the Kerberos specification.


    I am dooing little research and will be upding the post soon. So if you all have any valuable suggestions please share the same.

    Regards,

    Dhruv

     

     

    Friday, April 1, 2011 9:28 PM
  • Looking forward to your update!

    Ace


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    Saturday, April 2, 2011 1:55 AM
  • Looking forward to your update!

    Ace


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services

     

     

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.


    Hi Ace,

    Today I got update from Engineering team that our VPN device use both Heimdal and MIT. They use MIT to interoperate with MS Servers and use Heimdal for configuring SSO with resources.

    I presume MIT and Heimdal  is using Kerberos version 5 but I could not able to figure out technical difference between the 2, why MS went for MIT ?

    Ihttp://web.mit.edu/kerberos/www/ 

    http://www.h5l.org/

    There is no peoper documentations either from MS nor from Juniper. I am still pushing my internal team hard for answers.

    http://technet.microsoft.com/en-us/library/bb742516.aspx

    Regards,

    Dhruv

    Tuesday, April 5, 2011 7:46 AM
  • Hi Dhruv,

    Basically Kerberos iterations are all the same offering a trusted third party, ticket based authentication scheme. It's named after the 3-headed beast guarding the gates of heides, Cerberus, hence the 3 pieces of the authentication process, the client, the server, and the trusted third party. I like to describe it in class as the following:

    Tony, a business man in north Jersey, knows of a guy in Miami, Joe, that is selling a product he can resell in NY. However, he doesn't know Joe. TOny knows a guy in Chicago named Paulie, who knows Joe. Tony gives Paulie a call asking if he can hook him up. Paulie says, sure, because I know you, and we've done business together, and trust you. Here's Joe's number. I also call Joe to let him know you are calling.

    Client = Tony
    Server = Joe
    Trusted 3rd Party = Paulie

    All three itereations of Kerberos v5 do the same job, but slightly different. I believe they can be set to interoperate, but I haven't researched it that far. My best guess is Microsoft went with MIT's version of Kerberos v5 for Unix Realms interoperability, especially for SSO (single sign on), since Unix NFS also uses Kerberos v5, and more so because MIT's version has more application usage support, was created long ago, and is a known, stable product with active support and active, continuous development by a large team. That would be my guess why Unix (any flavor), went with it.

    I believe MIT is the oldest, being around since the 80's, hence it's enterprise stability and strong development and support.

    Here's something I did read that may be of interest: "Heimdal does not have a functioning replay cache, so if your app needs that you must go with MIT." Read more with this good summary:

    Heimdal or MIT kerberos?
    http://mailman.mit.edu/pipermail/kerberos/2004-October/006438.html

     

    Here are additional links:

    Kerberos (protocol) - From Wikipedia, the free encyclopedia
    http://en.wikipedia.org/wiki/Kerberos_(protocol)

    What is Heimdal? (Latest v1.4)
    Heimdal is an implementation of Kerberos 5 (and some more stuff) largely written in Sweden (which was important when we started writing it, less so now). It is freely available under a three clause BSD style license.
    http://www.h5l.org/

    What is Shishi Kerberos?
    Shishi, a free implementation of the Kerberos 5 network security system.
    http://josefsson.org/shishi/

    Ace

     

    Late edit: oops, sorry, you had already posted the http://www.h5l.org/ link. But I had re-posted it illustrating there are other versions out there. The MIT version is more enterprise ready and much more stable and proven than the others, and provide transparent application support, which are big advantages over the other versions.
    Ace


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services

     

     

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.


    • Edited by Ace Fekay [MCT] Tuesday, April 5, 2011 9:04 PM see late edit above
    Tuesday, April 5, 2011 8:59 PM
  • Hi Dhruv,

    Basically Kerberos iterations are all the same offering a trusted third party, ticket based authentication scheme. It's named after the 3-headed beast guarding the gates of heides, Cerberus, hence the 3 pieces of the authentication process, the client, the server, and the trusted third party. I like to describe it in class as the following:

    Tony, a business man in north Jersey, knows of a guy in Miami, Joe, that is selling a product he can resell in NY. However, he doesn't know Joe. TOny knows a guy in Chicago named Paulie, who knows Joe. Tony gives Paulie a call asking if he can hook him up. Paulie says, sure, because I know you, and we've done business together, and trust you. Here's Joe's number. I also call Joe to let him know you are calling.

    Client = Tony
    Server = Joe
    Trusted 3rd Party = Paulie

    All three itereations of Kerberos v5 do the same job, but slightly different. I believe they can be set to interoperate, but I haven't researched it that far. My best guess is Microsoft went with MIT's version of Kerberos v5 for Unix Realms interoperability, especially for SSO (single sign on), since Unix NFS also uses Kerberos v5, and more so because MIT's version has more application usage support, was created long ago, and is a known, stable product with active support and active, continuous development by a large team. That would be my guess why Unix (any flavor), went with it.

    I believe MIT is the oldest, being around since the 80's, hence it's enterprise stability and strong development and support.

    Here's something I did read that may be of interest: "Heimdal does not have a functioning replay cache, so if your app needs that you must go with MIT." Read more with this good summary:

    Heimdal or MIT kerberos?
    http://mailman.mit.edu/pipermail/kerberos/2004-October/006438.html

     

    Here are additional links:

    Kerberos (protocol) - From Wikipedia, the free encyclopedia
    http://en.wikipedia.org/wiki/Kerberos_(protocol)

    What is Heimdal? (Latest v1.4)
    Heimdal is an implementation of Kerberos 5 (and some more stuff) largely written in Sweden (which was important when we started writing it, less so now). It is freely available under a three clause BSD style license.
    http://www.h5l.org/

    What is Shishi Kerberos?
    Shishi, a free implementation of the Kerberos 5 network security system.
    http://josefsson.org/shishi/

    Ace

     

    Late edit: oops, sorry, you had already posted the http://www.h5l.org/ link. But I had re-posted it illustrating there are other versions out there. The MIT version is more enterprise ready and much more stable and proven than the others, and provide transparent application support, which are big advantages over the other versions.
    Ace

     


     

    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services

     

     

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.



    Hi Ace,

     

    Thank you for detailed explanation.

    I want to correct small point from the above that MIT cannot be used to implement SSO, thus all Unix based machines have to use Heimdal, as far Juniper SSL VPN device is using since it is a Linux device.

    However, apart replay cache I guess there is a difference between the 2 wrt to trust relationship.

    I have posted this question to my internal team regadring the same.

    Un-confirmed answer:

    A is a parent domain : B and C are 2 child domains

    A trust B and C, but B and C do not trust each other under Heimdal so we need to make a direct trust ( Kind of Short Cut Trust)

    Note : This is a unconfirmed point. Please wait.

    Regards,

    Dhruv


    Editing again::: ************************

    Ace, you are correct about Cace reply :-)

    http://k5wiki.kerberos.org/wiki/Projects/replay_cache_collision_avoidance

    Cheers !!

    Dhruv

     

    • Marked as answer by Dhruv.tech Friday, April 8, 2011 10:39 AM
    Wednesday, April 6, 2011 8:59 PM
  • Hi Ace,

    Thank you for detailed explanation.

    I want to correct small point from the above that MIT cannot be used to implement SSO, thus all Unix based machines have to use Heimdal, as far Juniper SSL VPN device is using since it is a Linux device.

    However, apart replay cache I guess there is a difference between the 2 wrt to trust relationship.

    I have posted this question to my internal team regadring the same.

    Un-confirmed answer:

    A is a parent domain : B and C are 2 child domains

    A trust B and C, but B and C do not trust each other under Heimdal so we need to make a direct trust ( Kind of Short Cut Trust)

    Note : This is a unconfirmed point. Please wait.

    Regards,

    Dhruv


    Editing again::: ************************

    Ace, you are correct about Cace reply :-)

    http://k5wiki.kerberos.org/wiki/Projects/replay_cache_collision_avoidance

    Cheers !!

    Dhruv


    Hhi Dhruv,

    In a multidomain AD forest, and I assume that's what you were referring to with the Domain A, B and C scenario, that AD creates a default two-way transitive trusts between all domains and trees in a forest. In such a scenario, even wtih AD, Domain C does not directly trust Domain B, but it does indirectly through the trust path both going through it's parent. You can shorten the trust path by creating a shortcut trust. I don't think whether being MIT or Heimdal would have anything to do with it in this scenario, since even in AD, Kerberos authentication is domain specific (each domain has a TGTS running granting a WT to each workstation), but because of the trust, there's pass-through authentication, hence why any cross domain authentication has to go through the "trust path" of course, where the workstation ticket is passed on to the next domain in the path until it reaches its final target.

    So I'm not sure about that point above, but I just wanted to point out how AD basically works. Maybe the following will help?

    Click on the image below for a larger view to see how kerb pass thru works between an AD domain and Unix Realm. Image from:
    Windows Active Directory Kerberos Interoperability
    http://www.itcs.umich.edu/windows-forest/w2k-kerberos.php

     

    Kerberos Pass-Thru

     

    The following shows trust transitivity in an AD forest. From:
    MIcrosoft: Trust Transitivity:
    http://technet.microsoft.com/en-us/library/cc739693(WS.10).aspx

    A two-way, transitive trust path connects domains

     

    And here is how a user in one domain access resources in another domain and how the Kerberos service works with the Kerberos TGT service in each domain: From:
    Microsoft - Kerberos Explained:
    http://technet.microsoft.com/en-us/library/bb742516.aspx

     

    Bb742516.kerb03(en-us,TechNet.10).gif  

    Bb742516.kerb04(en-us,TechNet.10).gif

     

    Ace


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    • Marked as answer by Dhruv.tech Friday, April 8, 2011 10:39 AM
    Thursday, April 7, 2011 10:08 PM
  • Hi Ace,

    Thank you for the reply.

    I too agree with your point.

    Dhruv

     

    Friday, April 8, 2011 10:39 AM
  • Hi Dhruv,

    Thank you. At least that's what I'm leaning towards. If interested, I pasted below the actual sequence that occurs when a user authenticates using Kerberos in Active Directory. I believe that Heimdal and Shishi works a little differently, but I don't have any reference on how they work to compare. I hope at least you find this helpful with the way AD works.

    =============================
    Kerberos Authentication

    Quoted from Microsoft Official Curriculum MOC 2823, "Implementing and Administering Security in a Microsoft Windows 2003 Network," Module 1, pp 7 - 9
    http://www.microsoft.com/learning/en/us/course.aspx?ID=2823B&locale=en-us

    In a Kerberos environment, the authentication process begins at logon. The
    following steps describe the Kerberos authentication process.

    1.  When a user enters a user name and password, the computer sends the logon
    credentials to the KDC. The logon credentials include the user name,
    account domain, and preauthentication data encrypted with a secret key
    derived from the user?s password. The KDC contains a master database of
    unique long-term keys for every principal in its realm.
       
    2.  The KDC looks up the user's master key (KA), which is based on the user?s
    password. The KDC then creates two items: a session key (SA) to share
    with the user and a Ticket-Granting Ticket (TGT). The TGT includes a
    second copy of the SA, the user name, and an expiration time. The KDC
    encrypts this ticket using its own master key (KKDC), which only the KDC
    knows.

    Kerberos implements secret key cryptography, which is different
    from public key cryptography in that it does not use a public and private key
    pair.

    3.  The client computer receives the information from KDC and runs the user?s
    password through a one-way hashing function, which converts the password
    into the user?s KA. The client computer now has a session key and a TGT
    so that it can securely communicate with the KDC. The client is now
    authenticated to the domain and is ready to access other resources in the
    domain by using the Kerberos protocol.

    When a client receives the session key and TGT from the server, it
    stores that information securely in volatile memory and not on the hard disk.
    Storing the information in the volatile memory and not on the hard disk
    makes the information more secure.

    4.  When a Kerberos client needs to access resources on a server that is a
    member of the same domain, it contacts the KDC. The client will present its
    TGT and a timestamp encrypted with the session key that is already shared
    with the KDC. The KDC decrypts the TGT using its KKDC. The TGT
    contains the user name and a copy of the SA. The KDC uses the SA to
    decrypt the timestamp. The KDC can confirm that this request actually
    comes from the user because only the user can use the SA.

    5.  Next, the KDC creates a pair of tickets, one for the client and one for the
    server on which the client needs to access resources. Each ticket contains
    the name of the user requesting the service, the recipient of the request, a
    timestamp that declares when the ticket was created, and a time duration
    that says how long the tickets are valid. Both tickets also contain a new key
    (KAB) that will be shared between the client and the server so that they can
    securely communicate.

    6.  The KDC takes the server's ticket and encrypts it using the server master
    key (KB). Then the KDC nests the server?s ticket inside the client?s ticket,
    which also contains the KAB. The KDC encrypts the whole thing using the
    session key that it shares with the user from the logon process. The KDC
    then sends all the information to the user.

    7.  When the user receives the ticket, the user decrypts it using the SA. This
    exposes the KAB to the client and also exposes the ticket for server. The
    user cannot read the server's ticket. The user will encrypt the timestamp by
    using the KAB and send the timestamp and the server?s ticket to the server
    on which the client wants to access resources. When it receives these two
    items, the server first decrypts its own ticket by using its KB. This permits
    access to the KAB, which can then decrypt the timestamp from the client.

    Now both the client and the server have the KAB. The server can be sure that
    the client has truthfully identified itself because the client used the KAB to
    encrypt the timestamp. If it is necessary for the server to respond to the user, the
    server will use the KAB. The client will know that the server has truthfully
    identified itself because the server had to use its KB to get the KAB.

    Active Directory FAQ: How Kerberos authentication works?
    http://activedirectoryfaq.blogspot.com/2007/09/how-kerberos-authentication-works.html

    Computer and Network Security - Kerberos Theory
    http://web.mit.edu/6.857/OldStuff/Fall97/lectures/lecture16.pdf
    ==============================================

     

    Ace


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    Friday, April 8, 2011 7:18 PM
  • I apologize for resurrecting this thread, but...

    <blockquote><p>Here's something&nbsp;I did read&nbsp;that may be of interest: <em>"Heimdal does not have a functioning replay cache, so if your app needs that you must go with MIT."
    </em></blockquote>

    I think that is not the case anymore.

    <blockquote><p>I want to correct small point from the above that MIT cannot be used to implement SSO, thus all Unix based machines have to use Heimdal, as far Juniper SSL VPN device is using since it is a Linux device.</p></blockquote>

    That could have been some years ago, but I do have a functioning SSO setup that works rather nicely with OSX and Linux. Also, Solaris' Kerberos is MIT based.
    Wednesday, November 23, 2011 8:44 PM