Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2006-12-28) NTLM And Kerberos Authentication Explained The Easy Way

Posted by Jorge on 2006-12-28


Kerberos authentication is always used when:

  • Both endpoints are at least W2K or higher
    AND
  • In case of a trust, Kerberos is supported

Kerberos is supported within an AD forest and between AD forests when a forest trust is used.

In all other cases NTLM authentication is used.

Let’s say you have the following layout:

  • Domain A
    • Multiple DCs
    • Clients and servers
  • Domain B
    • Multiple DCs
    • Clients and servers
  • Domain A trusts Domain B and vice versa

If NTLM is used the order of authentication is:

  1. CLIENT-DOMAIN_A wants to access MEMBERSRV-DOMAIN_B
  2. CLIENT-DOMAIN_A connects to MEMBERSRV-DOMAIN_B
  3. MEMBERSRV-DOMAIN_B connects to a DC in DOMAIN_B and asks do you know: CLIENT-DOMAIN_A
  4. The DC in DOMAIN_B says NO, but I do trust DOMAIN_A. Let me check.
  5. A DC in DOMAIN_B connects to a DC in DOMAIN_A and asks do you know: CLIENT-DOMAIN_A
  6. The DC in DOMAIN_A says: yes, it’s OK
  7. The DC in DOMAIN_B sets up an access token for domain B for CLIENT-DOMAIN_A.
  8. CLIENT-DOMAIN_A accesses MEMBERSRV-DOMAIN_B

If KERBEROS is used the order of authentication is:

  1. CLIENT-DOMAIN_A wants to access MEMBERSRV-DOMAIN_B
  2. CLIENT-DOMAIN_A connects to a DC in DOMAIN_A and asks for a ticket to access MEMBERSRV-DOMAIN_B
  3. The DC in DOMAIN_A says: let me check, just a sec.
  4. The DC in DOMAIN_A says: that server does not exist within the domain or the forest. However I do have a trust with DOMAIN_B. Go to a DC in DOMAIN_B
  5. CLIENT-DOMAIN_A connects to a DC in DOMAIN_B and asks for a ticket to access MEMBERSRV-DOMAIN_B
  6. The DC in DOMAIN_B says: let me check, just a sec.
  7. The DC in DOMAIN_B says: here’s your ticket and access token. have fun
  8. CLIENT-DOMAIN_A accesses MEMBERSRV-DOMAIN_B

More information can be found in the following MS articles:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

12 Responses to “(2006-12-28) NTLM And Kerberos Authentication Explained The Easy Way”

  1. What about when mapping drive?
    Say XP (non-domain client) to DC secured folder
    – What Authentication used?

    1) Using NET USE or WSHNetwork.MapNetworkDrive (vbscript / wscript)
    2) XP Pro (SP2) in a workgroup, not in a domain.
    3) Mapping drive to a secured folder within Netlogon share on a DC, in a domain

    When we pass name/pw creds, does it use Kerberos or NTLM (V1 or V2)?

    If not Kerberos, is there a way to force it to use Kerberos?

    thx!

  2. Note that the above mentioned sequence means that ALL the domain controllers must be able to reach each other! and with a forest domain trust, not only do the two root domain controllers need to be fully routable.. also all child domain controllers..

  3. […] very very very high-level overview of both authentication mechanisms can also be read here in this post I wrote […]

  4. […] https://jorgequestforknowledge.wordpress.com/2006/12/28/ntlm-and-kerberos-authentication-explained-th… […]

  5. […] (2006-12-28) NTLM And Kerberos Authentication Explained The Easy Way […]

  6. […] (2006-12-28) NTLM And Kerberos Authentication Explained The Easy Way […]

  7. […] very very very high-level overview of both authentication mechanisms can also be read here in this post I wrote […]

  8. […] very very very high-level overview of both authentication mechanisms can also be read here in this post I wrote […]

  9. Hans Reidt said

    What happens if there is a one-way trust ?

    Significant changes (more specific with the security protocol and firewall requirements) ?

    • Jorge said

      The trust direction, basically specifies the access direction.
      If Domain A trusts domain B, then users from domain B can access stuff across the trust in Domain A. If it was a two-way trust, then users from domain A can access stuff across the trust in Domain B

      Amongst others, the type of trust determines if NTLM or Kerberos is being used. Kerberos over a trust can be used if routing information is available. Also see: https://jorgequestforknowledge.wordpress.com/blog-post-series/#Kerberos-Authentication-Over-An-External-Trust-Is-It-Possible

      regards,
      jorge

      • Hans Reidt said

        Well, first…I REALLY like your posts and knowledge !

        2nd, I do not want Kerberos authentication for the following reason.
        Domain B trusts domain A (making domain B a resource domain).
        But there is a firewall between domain A and domain B.
        In domain B there are 2 DC’s but in domain A there are 54 DC’s.
        Multiply that with approx. 10 ports….firewall team is not happy

        With NTLM authentication, a DC B would contact a DC A (and I think which DC from A can be configured in the 1-way trust ?).
        If Kerberos would be used, all clients from Domain A would require access to a DC B.
        Correct ?

        – if NTLM is used, what would be the list of ports to be opened ?
        – any reason to prefer Kerberos over NTLM (Domain A and B are within the same company) ?

        Kind regards,

        Hans

        • Jorge said

          check out the following documents:
          https://www.microsoft.com/en-us/download/details.aspx?id=18102
          https://technet.microsoft.com/en-us/library/dd560678%28v=ws.10%29.aspx

          to use a specific protocol, the resource being accessed by support that protocol and be configured for it!

          In my honest opnion, it will be NTLM that will give you issues, not kerberos.

          What you need to do is to make sure the same AD sites exist in both AD forests OR at least have the subnets from one forest defined in the other forest and linked to some site. The site you choose contains the DCs “near” the firewall. That way client/servers from one forest can be matched to the defined subnets in the other forests which in turn are linked to the DCs “near” the firewall. Those same DCs can then ben specified in the firewall

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: