(2013-12-19) Selective Authentication Broken In W2K12R2 – To Be Fixed

UPDATE (2014-01-25): The following "General Availability Update Rollup" has a fix for the issue below

– 

While browsing through the DS forum I bumped into the following thread: Server 2012 R2 no longer able to query objects in a trusted domain over a Forest Trust using Selective Authentication

–

In that same thread a link has been posted, which are the Release Notes For Windows Server 2012 R2.

–

The release notes specifically mention the following:

Trusts

The Selective Authentication feature of selective trusts is not functional. Access to resources enabled by “Allowed to Authenticate” will fail. There is no workaround at this time.

–

Ouch….I was quite surprised to read this.

–

I have not tested this, the following scenario applies:

• Forest "ADCORP.LAB" — W2K8R2 or W2K12
• Forest "ADDMZ.LAN" — W2K8R2 or W2K12
• One-way forest/external trust with selective authentication enabled, where Forest "ADDMZ.LAN" trusts Forest "ADCORP.LAB"

Everything is working.

However, while keeping Forest "ADDMZ.LAN" on W2K8R2 or W2K12 and introducing W2K12R2 DCs into the Forest "ADCORP.LAB" everything over the trust would still work.

However, while keeping Forest "ADCORP.LAB" on W2K8R2 or W2K12 and introducing W2K12R2 DCs into the Forest "ADDMZ.LAN" everything over the trust while the "Allowed To Authenticate" on resources in the Forest "ADDMZ.LAN" would break when the access check is performed by a W2K12R2 DC.

–

If you have a forest, which is a candidate for a (near) future upgrade to W2K12R2 AND that same forest has an outgoing trust with selective authentication enabled, my suggestion is to NOT upgrade that forest to W2K12R2. Wait until Microsoft has released a fix to solve that issue before you perform the upgrade.

If you are not using Selective Authentication at all, then there is no issue.

–

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/ ########
———————————————————————————————

Advertisement

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

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…

–

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

–

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

–

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

–

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…

–

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

–

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

–

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

–

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!)

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: 0x7  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!)

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.

–

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:

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.

–

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

–

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

–

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

–

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

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: 0x7  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.

–

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: 0x7  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!

–

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

–

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

–

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: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

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

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 this last post I will show the usage of Kerberos authN when logged on to a computer in another AD forest/domain, while a EXTERNAL TRUST is in place

–

Now, let’s try with an EXTERNAL TRUST. Detailed Configuration of the External Trust is shown below

–

According to the articles mentioned at the beginning of this post, the requirements to be able to leverage Kerberos over an External Trust are:

• The trust has to be created using the fully qualified domain name (FQDN). Kerberos referral fails if the FQDN is missing from the TDO –> I confirm the trust was setup using the DNS name of the AD domains (created individually on both sides using DNS names!)
• User name syntax is UPN and the UPN suffix is resolvable to a DC in DNS (implicit UPN) –> Not sure how to understand this
• UDP 389, UDP/TCP 88, and UDP/TCP 464 (password change requests) ports are open for the domain controllers in the user domain. –> In my environment I do have a firewall, but I confirm I created a top level rule to allow all traffic in all directions
• 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 confirm the website has the same FQDN as the server “R2FSMBSVA.ADDMZ.LAN”

–

So, let’s do this and see what happens. Not nuts, no glory!

–

In the following picture, I’m logged on to an RWDC (“R1FSRWDC1.ADCORP.LAB”) in the AD CORP domain with the default AD CORP admin account (renamed from “ADCORP\administrator” to “ADCORP\ADM.ROOT”) that’s a domain admin within the AD CORP forest/domain and accessing the website “DELEGCONFIG.ADDMZ.LAN”. As you can see Kerberos authN is being used. In addition the picture contains the proof that a External Trust is in place, which appears to support Kerberos as stated in the Microsoft blog and technical article!

–

In the following picture, I’m logged on to an RWDC (“R1FSRWDC1.ADCORP.LAB”) in the AD CORP domain with the default AD CORP admin account (renamed from “ADCORP\administrator” to “ADCORP\ADM.ROOT”) that’s a domain admin within the AD CORP forest/domain and accessing the website “R2FSMBSVA.ADDMZ.LAN”. As you can see Kerberos authN is being used. In addition the picture contains the proof that a External Trust is in place, which appears to support Kerberos as stated in the Microsoft blog and technical article!

–

You can slap me crazy, but as you can see I have got Kerberos authN working over an external trust!!! YES! Therefore: IT WORKS!!!!!!!!!!!

–

Try it yourself and enjoy!

To understand HOW it works check out PART 6

–

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/ ########
———————————————————————————————

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

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 this post I will show the usage of Kerberos authN when logged on to a computer in another AD forest/domain, while a FOREST TRUST is in place

–

In the previous posts the proof is delivered Kerberos AuthN is working against those two website. Let’s now perform the exact same test using a Forest Trust and an External Trust. Let’s first start with a FOREST TRUST.

Detailed Configuration of the Forest Trust is shown below

–

In the following picture, I’m logged on to an RWDC (“R1FSRWDC1.ADCORP.LAB”) in the AD CORP domain with the default AD CORP admin account (renamed from “ADCORP\administrator” to “ADCORP\ADM.ROOT”) that’s a domain admin within the AD CORP forest/domain and accessing the website “DELEGCONFIG.ADDMZ.LAN”. As you can see Kerberos authN is being used. In addition the picture contains the proof that a Forest Trust is in place, which supports Kerberos as we all know!

–

In the following picture, I’m logged on to an RWDC (“R1FSRWDC1.ADCORP.LAB”) in the AD CORP domain with the default AD CORP admin account (renamed from “ADCORP\administrator” to “ADCORP\ADM.ROOT”) that’s a domain admin within the AD CORP forest/domain and accessing the website “R2FSMBSVA.ADDMZ.LAN”. As you can see Kerberos authN is being used. In addition the picture contains the proof that a Forest Trust is in place, which supports Kerberos as we all know!

–

This continues in PART 5, which is the NEXT and LAST post.

–

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/ ########
———————————————————————————————

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

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 this post I will show the usage of Kerberos authN when logged on to another computer in the same AD forest/domain

–

In the following picture, I’m logged on locally to an RWDC (“R2FSRWDC1.ADDMZ.LAN”) in the AD DMZ domain with the default AD DMZ admin account (renamed from “ADDMZ\administrator” to “ADDMZ\ADM.ROOT”) that’s a domain admin within the AD DMZ forest/domain and accessing the website “DELEGCONFIG.ADDMZ.LAN”. As you can see Kerberos authN is being used.

–

In the following picture, I’m logged on locally to an RWDC (“R2FSRWDC1.ADDMZ.LAN”) in the AD DMZ domain with the default AD DMZ admin account (renamed from “ADDMZ\administrator” to “ADDMZ\ADM.ROOT”) that’s a domain admin within the AD DMZ forest/domain and accessing the website “R2FSMBSVA.ADDMZ.LAN”. As you can see Kerberos authN is being used.

–

This continues in PART 4, which is the NEXT post.

–

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/ ########
———————————————————————————————

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

In PART 1 I explained the setup I will use.

In this post I will show the usage of Kerberos authN when logged on to the local application server.

–

In the following picture, I’m logged on locally to the application server (“R2FSMBSVA.ADDMZ.LAN”) in the AD DMZ domain with a custom AD DMZ user account (“ADDMZ\ADM.ADM_ADLCL_R2FSRODC5”) that’s local admin on the application server and accessing the website “DELEGCONFIG.ADDMZ.LAN”. As you can see Kerberos authN is being used.

–

In the following picture, I’m logged on locally to the application server (“R2FSMBSVA.ADDMZ.LAN”) in the AD DMZ domain with a custom AD DMZ user account (“ADDMZ\ADM.ADM_ADLCL_R2FSRODC5”) that’s local admin on the application server and accessing the website “R2FSMBSVA.ADDMZ.LAN”. As you can see Kerberos authN is being used.

–

This continues in PART 3, which is the NEXT post.

–

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/ ########
———————————————————————————————

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

About a year or so ago I read this blog post which leads this Microsoft technical article. My first reaction was “WTF!”, because everybody has always thought, and you can read it anywhere that:

• External Trust –> NTLM AuthN only
• Forest Trust –> Kerberos AuthN and NTLM AuthN

–

I could not believe this and I had to try it out myself of course. Today was that day! So here goes!

–

Before continuing, let’s briefly discuss the infrastructure I used to test this.

• AD forest “ADCORP.LAB”
  • AD domain “ADCORP.LAB”
    • RWDC “R1FSRWDC1.ADCORP.LAB”
      
• AD forest “ADDMZ.LAN”
  • AD domain “ADDMZ.LAN”
    • RWDC “R2FSRWDC1.ADDMZ.LAN”
    • RWDC “R2FSRWDC2.ADDMZ.LAN”
    • RODC “R2FSRODC5.ADDMZ.LAN”
    • SERVER “R2FSMBSVA.ADDMZ.LAN”
      
• TEST1 –> One-way Forest Trust (as shown below)
  • Trusting AD forest = “ADDMZ.LAN”
  • Trusted AD forest = “ADCORP.LAB”
  • Forest Wide Authentication enabled

–

–

• TEST2 –> One-way External Trust (as shown below)
  • Trusting AD domain = “ADDMZ.LAN”
  • Trusted AD domain = “ADCORP.LAB”
  • Domain Wide Authentication enabled

–

–

–

In all cases/tests, the application server “R2FSMBSVA” hosted 5 website as shown below

The web sites are configured as follows:

• DELEGCONFIG.ADDMZ.LAN:81 (DelegConfig v2 Beta)
  • Application Pool = Kerberos AppPool
  • Application Pool Account = ADDMZ\SVC_R2_KERBAPP
  • servicePrincipalName on application pool account = HTTP/DELEGCONFIG.ADDMZ.LAN
  • Report option will show which authN protocol is used
• R2FSMBSVA.ADDMZ.LAN:82 (DelegConfig v2 Beta)
  • Application Pool = Kerberos AppPool
  • Application Pool Account = ADDMZ\SVC_R2_KERBAPP
  • servicePrincipalName on application pool account = HTTP/R2FSMBSVA.ADDMZ.LAN
  • Report option will show which authN protocol is used
• SHAREPOINT.ADDMZ.LAN (Windows Sharepoint Services configured with NTLM AuthN)
  • Application Pool = SharePoint – 80
  • Application Pool Account = ADDMZ\SVC_R2_KERBAPP
  • servicePrincipalName on application pool account = HTTP/SHAREPOINT.ADDMZ.LAN
• KERBAPP.ADDMZ.LAN:8080 (Windows Sharepoint Services configured for Kerberos AuthN)
  • Application Pool = SharePoint – KERBAPP.ADDMZ.LAN8080
  • Application Pool Account = ADDMZ\SVC_R2_KERBAPP
  • servicePrincipalName on application pool account = HTTP/KERBAPP.ADDMZ.LAN
• NTLMAPP.ADDMZ.LAN:8081 (Windows Sharepoint Services configured for NTLM AuthN)
  • Application Pool = SharePoint – NTLMAPP.ADDMZ.LAN8081
  • Application Pool Account = ADDMZ\SVC_R2_KERBAPP
  • servicePrincipalName on application pool account = HTTP/NTLMAPP.ADDMZ.LAN

–

For the tests I’m going to only use the websites:

• DELEGCONFIG.ADDMZ.LAN:81 (DelegConfig v2 Beta) –> To prove Kerberos AuthN with a Forest Trust in place
• R2FSMBSVA.ADDMZ.LAN:82 (DelegConfig v2 Beta)–> To prove Kerberos AuthN with an External Trust in place

–

To prove what type of authN is being used, I’m using DelegConfig, which you can download from here. DelegConfig is an ASP.NET application that can be used to help troubleshoot and configure IIS and Active Directory to allow Kerberos and delegating Kerberos credentials. Very handy!!!

–

To prove Kerberos AuthN IS WORKING against BOTH websites on server “R2FSMBSVA” I will target those first with a user account from the AD domain ADDMZ.LAN from a computer also within the AD domain ADDMZ.LAN

• The user account will be “ADDMZ\ADM.ADM_ADLCL_R2FSRODC5” and the computer will be “R2FSMBSVA.ADDMZ.LAN”.
• The user account will be “ADDMZ\ADM.ROOT” and the computer will be “R2FSRWDC1.ADDMZ.LAN”.

–

This continues in PART 2, which is the NEXT post.

–

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/ ########
———————————————————————————————