Jorge's Quest For Knowledge!

All about Windows Server, ADDS, ADFS & FIM (It Is Just Like An Addiction, The More You Have, The More You Want To Have!)

(2011-09-14) Kerberos Authentication Over An External Trust – Is It Possible? (Part 6)

Posted by Jorge on 2011-09-14


In PART 1 I explained the setup I will use.

In PART 2 I showed the usage of Kerberos authN accessing the websites on the local web server.

In PART 3 I showed the usage of Kerberos authN accessing the websites from another computer in the same AD forest/domain.

In PART 4 I showed the usage of Kerberos authN when logged on to a computer in another AD forest/domain, while a FOREST TRUST is in place

In PART 5 I showed the usage of Kerberos authN when logged on to a computer in another AD forest/domain, while a EXTERNAL TRUST is in place

In this, really, last post about this I will, besides showing the usage of Kerberos authN while a EXTERNAL TRUST is in place, also explain how to achieve this functionality.

-

All of you that read the first 5 blog posts about this topic AND tried to achieve this, may have failed to achieve the result that I was able to achieve. The main reason for is that I never mentioned the missing link in this. If you dug deep into it you end with the question “How does the TRUSTED domain find the TRUSTING domain that owns the service principal name?”

-

To make sure it is explained correctly so that you understand it correctly, let’s go through all of it again. With this information you will be able to try it your self!

-

Let’s start again with a FOREST TRUST and its configuration…

-

image

Figure 1: One-Way Forest Trust –> TRUSTED FOREST = ADCORP.LAB (Incoming) | TRUSTING FOREST = ADDMZ.LAN (Outgoing)

-

image

Figure 2: Name Suffix Routing Configuration On The Forest Trust For The TRUSTING FOREST

-

image

Figure 3: The Forest Trust Configuration On The TRUSTED Side From An Attribute Perspective

-

image

Figure 4: The Human Readable Information Stored In The “msDS-TrustForestTrustInfo” Attribute Of The Trusted Domain Object (TDO)

-

So, if you take the configuration that I posted in PART 1 into account, the following will happen when a user from the “ADCORP.LAB” AD forest logged on to a computer also from the “ADCORP.LAB” AD forest is accessing the websites “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82” (high-level steps):

  1. User account in “ADCORP.LAB” AD domain logs on to computer in “ADCORP.LAB” AD domain.
  2. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a TGT for the “ADCORP.LAB” AD domain.
  3. To access either website “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82”, the user account requests a TGS for either service.
  4. The DC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD domain but cannot find a user account or a computer in the local AD domain that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
  5. The GC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD forest but cannot find a user account or a computer in the local AD forest that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
  6. The DC/GC in the “ADCORP.LAB” AD domain/forest servicing the user account checks for any local or GC located Trusted Domain Object (TDO) (in the “msDS-TrustForestTrustInfo” Attribute) and checks if it can find any SPN suffix that matches the SPN suffix of the required service/SPN to be able to refer the user to (figure 4). (Success!)
  7. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a referral ticket to the user account for the AD domain “ADDMZ.LAN” (single AD domain in the AD forest, otherwise additional similar steps included!)
  8. The DC in the “ADDMZ.LAN” AD domain servicing the user account issues a TGT for the “ADDMZ.LAN” AD domain.
  9. The DC in the “ADDMZ.LAN” AD domain servicing the user account issues a TGS for either website that has either SPN HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN” configured in its service or application pool account
  10. The user account presents the TGS to the website
  11. Based upon the contents of the TGS the website allows access

REMARK: Detailed information about Kerberos authN can be found HERE.

REMARK: The information in the “msDS-TrustForestTrustInfo” attribute is build from the information within the trusting AD forest, such the “UPN-Suffixes” attribute and the “ms-DS-SPN-Suffixes” attribute on the Partitions container. Also see “Building Well-Formed msDS-TrustForestTrustInfo Messages” and “Routing name suffixes across forests

-

So far so good!

-

Let’s continue again with an EXTERNAL TRUST and its configuration…

-

image

Figure 5: One-Way External Trust –> TRUSTED DOMAIN = ADCORP.LAB (Incoming) | TRUSTING DOMAIN = ADDMZ.LAN (Outgoing)

-

image

Figure 6: Name Suffix Routing Configuration On The External Trust For The TRUSTING FOREST. WAIT! There is None!!!

-

image

Figure 7: The External Trust Configuration On The TRUSTED Side From An Attribute Perspective

-

image

Figure 8: The Human Readable Information Stored In The “msDS-TrustForestTrustInfo” Attribute Of The Trusted Domain Object (TDO). WAIT! There is None!!!

-

So, if you take the configuration that I posted in PART 1 into account, the following will happen when a user from the “ADCORP.LAB” AD forest logged on to a computer also from the “ADCORP.LAB” AD forest is accessing the websites “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82” (high-level steps):

  1. User account in “ADCORP.LAB” AD domain logs on to computer in “ADCORP.LAB” AD domain.
  2. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a TGT for the “ADCORP.LAB” AD domain.
  3. To access either website “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82”, the user account requests a TGS for either service.
  4. The DC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD domain but cannot find a user account or a computer in the local AD domain that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
  5. The GC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD forest but cannot find a user account or a computer in the local AD forest that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
  6. The DC/GC in the “ADCORP.LAB” AD domain/forest servicing the user account checks for any local or GC located Trusted Domain Object (TDO) (in the “msDS-TrustForestTrustInfo” Attribute) and checks if it can find any SPN suffix that matches the SPN suffix of the required service/SPN to be able to refer the user to (figure 4).(Failure!)
  7. THEREFORE, the DC in the “ADCORP.LAB” AD domain servicing the user account CANNOT issue a referral ticket to the user account for the AD domain “ADDMZ.LAN”
  8. THEREFORE, The DC in the “ADDMZ.LAN” AD domain servicing the user account CANNOT issue a TGT for the “ADDMZ.LAN” AD domain.
  9. THEREFORE, The DC in the “ADDMZ.LAN” AD domain servicing the user account CANNOT issue a TGS for either website that has either SPN HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN” configured in its service or application pool account
  10. THEREFORE, the user account CANNOT present the TGS to the website
  11. THEREFORE, the user account cannot leverage Kerberos AuthN!
  12. Because either website is configure with NEGOTIATE, the system will switch to NTLM authN.

REMARK: Detailed information about NTLM can be found HERE.

-

After you have enabled Verbose Kerberos Logging as explained in MS-KBQ262177 you will see the following in the System Event Log (DO NOT FORGET TO DISABLE IT AGAIN!)

image

Figure 9: Kerberos Error Message About Not Being Able To Find The SPN In The Local AD domain/forest

-

A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 22:7:3.0000 9/13/2011 Z
Error Code: 0×7  KDC_ERR_S_PRINCIPAL_UNKNOWN
Extended Error:
Client Realm:
Client Name:
Server Realm: ADCORP.LAB
Server Name: HTTP/delegconfig.addmz.lan
Target Name: HTTP/delegconfig.addmz.lan@ADCORP.LAB

Error Text:
File: 9
Line: f09
Error Data is in record data.

-

So, the main reason for External Trusts NOT supporting Kerberos AuthN is because there is no routing information available to create the referral! The DCs do not have enough information for the next hop. That’s really it! If there would be a mechanism that is able to provide such required information, you would Kerberos over the external trust. What can you do about this, is the question that needs to be answered!

When you open the GPMC you will see the following settings (amongst others!)

image

Figure 10: GPO Settings To Configure The KDC Service On A DC

-

Pay close attention to the GPO Setting called “Use forest search order”. The description is:

This policy setting defines the list of trusting forests that the Key Distribution Center (KDC) searches when attempting to resolve two-part service principal names (SPNs).

If you enable this policy setting, the KDC will search the forests in this list if it is unable to resolve a two-part SPN in the local forest. The forest search is performed by using a global catalog or name suffix hints. If a match is found, the KDC will return a referral ticket to the client for the appropriate domain.

If you disable or do not configure this policy setting, the KDC will not search the listed forests to resolve the SPN. If the KDC is unable to resolve the SPN because the name is not found, NTLM authentication might be used.

To ensure consistent behavior, this policy setting must be supported and set identically on all domain controllers in the domain.

-

image

Figure 11: GPO Settings To Configure The Kerberos AuthN Protocol On Windows Computers In Common

-

Pay close attention to the GPO Setting called “Use forest search order”. The description is:

This policy setting defines the list of trusting forests that the Kerberos client searches when attempting to resolve two-part service principal names (SPNs).

If you enable this policy setting, the Kerberos client will search the forests in this list if it is unable to resolve a two-part SPN. If a match is found, the Kerberos client will request a referral ticket to the appropriate domain.

If you disable or do not configure this policy setting, the Kerberos client will not search the listed forests to resolve the SPN. If the Kerberos client is unable to resolve the SPN because the name is not found, NTLM authentication might be used.

-

The GPO Setting “Use forest search order” is therefore the mechanism that is able to provide the missing information for this to work! If you look carefully in figure 12, this will only work for W2K8R2 AD forest!

-

I will therefore use the option shown in figure 10 and configure it as shown below:

image

Figure 12: Configuring The GPO Setting “Use Forest Search Order” That Will Be Applied On ALL DCs (GPO Setting In Figure 10) And Applied On All Windows Computers (GPO Setting In Figure 11) In The AD Domain/Forest

REMARK: It should be enough to configure either the KDC on all W2K8R2 DCs or all Win7/W2K8R2 computers in the AD domain

-

Make sure to wait until end-to-end AD/SYSVOL Replication is complete and every DC has (re-)applied the GPO with the new GPO Setting. In this case I executed GPUPDATE /FORCE on the one and only RWDC I have in my TRUSTED AD FOREST.

-

So, if you NOW take the configuration that I posted in PART 1 into account AND the configuration shown in figure 10 and 12, the following will happen when a user from the “ADCORP.LAB” AD forest logged on to a computer also from the “ADCORP.LAB” AD forest is accessing the websites “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82” (high-level steps):

  1. User account in “ADCORP.LAB” AD domain logs on to computer in “ADCORP.LAB” AD domain.
  2. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a TGT for the “ADCORP.LAB” AD domain.
  3. To access either website “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82”, the user account requests a TGS for either service.
  4. The DC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD domain but cannot find a user account or a computer in the local AD domain that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
  5. The GC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD forest but cannot find a user account or a computer in the local AD forest that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
  6. The DC/GC in the “ADCORP.LAB” AD domain/forest servicing the user account checks for any local or GC located Trusted Domain Object (TDO) (in the “msDS-TrustForestTrustInfo” Attribute) and checks if it can find any SPN suffix that matches the SPN suffix of the required service/SPN to be able to refer the user to (figure 4). (Failure!)
  7. The DC/GC in the “ADCORP.LAB” AD domain/forest servicing the user account checks for any additional routing hints as configured by the GPO Setting “Use forest search order” and checks if it can find any SPN suffix that matches the SPN suffix of the required service/SPN to be able to refer the user to (figure 4). (Success!)
  8. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a referral ticket to the user account for the AD domain “ADDMZ.LAN” (single AD domain in the AD forest, otherwise additional similar steps included!)
  9. The DC in the “ADDMZ.LAN” AD domain servicing the user account issues a TGT for the “ADDMZ.LAN” AD domain.
  10. The DC in the “ADDMZ.LAN” AD domain servicing the user account issues a TGS for either website that has either SPN HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN” configured in its service or application pool account
  11. The user account presents the TGS to the website
  12. Based upon the contents of the TGS the website allows access

-

BINGO!!!!! We have a winner! Kerberos AuthN over an external trust is working!

-

To prove I’m not bullshitting you, check out the following screen dumps. Pay attention to the time shown in the screen dump.

-

image

Figure 13: Kerberos Tickets Cached By The Client BEFORE Accessing The Websites Over An External Trust

-

image

Figure 14: Kerberos AuthN Is Used When Accessing The Website “HTTP://DELEGCONFIG.ADDMZ.LAN:81” While An External Trust Is In Place

-

image

Figure 15: Kerberos AuthN Is Used When Accessing The Website “HTTP://R2FSMBSVA.ADDMZ.LAN:82” While An External Trust Is In Place

-

image

Figure 16: Kerberos Tickets Cached By The Client AFTER Accessing The Websites Over An External Trust

image

Figure 17: An Kerberos Error Is Still Logged In The System Event Log Because The Search For The SPN (HTTP/DELEGCONFIG.ADDMZ.LAN) In The LOCAL AD Forest Fails

A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 8:11:14.0000 9/14/2011 Z
Error Code: 0×7  KDC_ERR_S_PRINCIPAL_UNKNOWN
Extended Error:
Client Realm:
Client Name:
Server Realm: ADCORP.LAB
Server Name: HTTP/delegconfig.addmz.lan
Target Name: HTTP/delegconfig.addmz.lan@ADCORP.LAB
Error Text:
File: 9
Line: f09
Error Data is in record data.

-

image

Figure 18: An Kerberos Error Is Still Logged In The System Event Log Because The Search For The SPN (HTTP/R2FSMBSVA.ADDMZ.LAN) In The LOCAL AD Forest Fails

A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 8:12:5.0000 9/14/2011 Z
Error Code: 0×7  KDC_ERR_S_PRINCIPAL_UNKNOWN
Extended Error:
Client Realm:
Client Name:
Server Realm: ADCORP.LAB
Server Name: HTTP/r2fsmbsva.addmz.lan
Target Name: HTTP/r2fsmbsva.addmz.lan@ADCORP.LAB
Error Text:
File: 9
Line: f09
Error Data is in record data.

-

The following question remains: “How about custom suffixes (e.g. EXTERNAL.LAN) not hosted by the AD forest “ADDMZ.LAN” by default???”. Remember that the mechanism is different. With a forest trust the information in the Trusted Domain Object (attribute “msDS-TrustForestTrustInfo”) is used that is available in the local AD forest through the GC. With an external trust that information does not exist. The KDC in the trusted AD forest or the kerberos client in the trusted AD forest searches the trusting AD forests listed in the order specified in the GPO Setting after not being able to find it in the local AD forest.

Although Microsoft has the following requirement:

  • The server name in the trusting resource domain has to be the FQDN, and the domain suffix of the server name has to match the AD DS domain’s DNS FQDN

I have already shown it work if you do not use the FQDN of the server (R2FSMBSVA) but rather an alias (DELEGCONFIG.ADDMZ.LAN) which also has the same suffix as the AD forest/domain. How about an alias that has a different suffix? That also appears to work also! I created an additional website “HTTPS://DELEGCONFIG.EXTERNAL.LAN:83” on the same server. Let’s see what happens with that!

-

image

Figure 19: Kerberos Tickets Cached By The Client BEFORE Accessing The Website Over An External Trust

-

image

Figure 20 Kerberos AuthN Is Used When Accessing The Website “HTTP://DELEGCONFIG.EXTERNAL.LAN:83” While An External Trust Is In Place

-

image

Figure 21: Kerberos Tickets Cached By The Client AFTER Accessing The Website Over An External Trust

-

Now before you go all crazy….

  • This only works when the TRUSTED/TRUSTING forest contains at least W2K8R2 DCs OR Win7/W2K8R2 computers (either one needs to be able to perform the search)
  • You may have an external trust while you require Kerberos AuthN and creating a forest trust is not an option. Example: Interactive user logon over external trust fails or encounters delays
  • I did not test every possible scenario! Therefore use this information for your own fun and make sure to test your own scenario! It may not apply to every possible scenario.
  • If you want/need to leverage Kerberos AuthN over an external trust, check first with Microsoft if that’s supported or not. Remember that currently Kerberos AuthN is only supported over a forest trust

-

HAVE FUN!

-

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

8 Responses to “(2011-09-14) Kerberos Authentication Over An External Trust – Is It Possible? (Part 6)”

  1. [...] To understand HOW it works check out PART 6 [...]

  2. [...] MS post “Conditions for Kerberos to be used over an External Trust” and the post “Kerberos Authentication Over An External Trust – Is It Possible? (Part 6)“. For testing the authentication method used when accessing a web page, the tool [...]

  3. It gets a bit trickier (not much) if external trusts are to domains in a forest that is a root domain with multiple child domains. In that case you put FQDNs of child domains in the search order _before_ the root domain.

  4. Scrap my last comment. If external trusts are to domains within same forest (i.e. a forest at Windows 2000 FFL) and you use domain search policy, Kerberos will only work to the first domain in the search list. Requests to other domain will receive a hard error – there will be no fallback to NTLM either.

    Kerberos over such external trusts is still possible, using Kerberos realm policies.

  5. ericstephani said

    Awesome series of posts. I learned something because we have this exact situation and I could never really understand why things work and don’t work some times.

  6. Danny said

    Wow this article is spot on. Thank you!

  7. Ivan R said

    I just re-read this article. One of our implementers asked me if he should do just an external trust and I remembered reading this over a year ago and told him to do both. This was a great read. Good job. Still extremely helpful although it has been more then a couple of years since it was posted.

  8. blablas74 said

    Great article! I was struggling whit external trust auth with no clue on how to get rid of it! Thank you!
    I’ve a mixed environment with XP/7 PCs in both domains (bidirectional non transitive trust) and W2K8R2 (domA) and W2K12 DCs (domB).The KDC policy does not seem to have any effect, whilst the Kerberos policy is doing its job, but only for Win7 clients (as expected!).
    Should the KDC policy make kerberos authN work even for XP clients?
    Could anyone shed some ligth on this?

    Thanks

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: