(2012-11-10) Testing/Understanding The Authentication Protocol Your Web Site Is Using

Last Wednesday I was at a customer for a workshop/presentation/demo and talking about ADFS, federation, federated identities, authentication, SSO, claims,  Kerberos and NTLM. The day ended how to execute the next steps in troubleshooting both Kerberos and NTLM authentication because of the authentication issues this customer was experiencing.

-

In the past I already blogged about troubleshooting Kerberos/NTLM Authentication. Also see: (2012-01-26) Troubleshooting Authentication Problems – Kerberos Or NTLM

-

After arriving home and having some dinner I searched on the internet for “testing Kerberos authentication” and that’s when I found Michel Barneveld’s blog that contained a blog post about the Kerberos Authentication Tester.

-

This allows you to test the authentication protocol being used by a specific website. The main features are:

• It shows what authentication method is used in a web request: None, Basic, NTLM or Kerberos
• It shows the SPN used in case of Kerberos
• It shows the HTTP status
• It shows the HTTP Headers of the request
• It shows the version of NTLM used (v1 or v2)
• It has a detailed view with a complete breakdown of the Authorization header. (Yep, went through all the RFCs to dissect the Kerberos and NTLM packages)
• It shows your current Kerberos tickets and allows you to remove them (like klist.exe)

-

I tried this tool against my test/demo environment and below you will find some screen dumps.

-

On The Settings TAB you can specific the credentials that should be used when targeting the specified website.

Figure 1: Settings TAB – Credentials And Proxy

-

On the Test TAB, after specifying a URL and clicking on [Test], it will output the HTTP Headers. In this case I was targeting a Kerberos Based Web Site.

Figure 2a: Test TAB – Output HTTP Headers For Kerberos Authentication

-

Figure 2b: Test TAB – Output HTTP Headers For Kerberos Authentication (Continued)

-

Figure 2c: Test TAB – Output HTTP Headers For Kerberos Authentication (Continued)

-

Figure 2d: Test TAB – Output HTTP Headers For Kerberos Authentication (Continued)

-

Figure 2e: Test TAB – Output HTTP Headers For Kerberos Authentication (Continued)

-

Figure 2f: Test TAB – Output HTTP Headers For Kerberos Authentication (Continued)

-

Figure 2g: Test TAB – Output HTTP Headers For Kerberos Authentication (Continued)

-

In case of Kerberos Authentication, you can see the total list of Kerberos Tickets, including the one for the Kerberos Based Web Site.

Figure 3: Tickets TAB – List Of Kerberos Tickets

-

On the Test TAB, after specifying a URL and clicking on [Test], it will output the HTTP Headers. In this case I was targeting an NTLM Based Web Site.

Figure 4a: Test TAB – Output HTTP Headers For NTLM Authentication (Continued)

-

Figure 4b: Test TAB – Output HTTP Headers For NTLM Authentication (Continued)

-

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

(2012-01-26) Troubleshooting Authentication Problems – Kerberos Or NTLM

Over the years I have written a few blog posts about or related to Kerberos or NTLM authentication. These blog posts are summarized here for your convenience:

• (2006-12-28) NTLM And Kerberos Authentication Explained The Easy Way
• (2010-10-12) User Principal Names In AD (Part 1)
• (2010-10-12) User Principal Names In AD (Part 2)
• (2010-10-12) User Principal Names In AD (Part 3)
• (2011-02-13) Accessing A Resource With The Kerberos Authentication Protocol
• (2011-02-13 ) Accessing A Resource With The NTLM Authentication Protocol
• (2011-02-13) When Will The Password Expire For An AD User Account And What Happens Then?

-

However, in addition to what I have written, the guys at AskDS have written a bunch of excellent Kerberos related blog posts. These blog posts are summarized here for your convenience:

• Kerberos for the Busy Admin
• Troubleshooting Kerberos Authentication problems – Name resolution issues
• Kerberos Authentication problems – Service Principal Name (SPN) issues – Part 1
• Kerberos Authentication problems – Service Principal Name (SPN) issues – Part 2
• Kerberos Authentication problems – Service Principal Name (SPN) issues – Part 3
• Understanding Kerberos Double Hop
• Fun with the Kerberos Delegation Web Site

-

A guy from WebTopics also has written a very good blog post about Kerberos in IIS. This blog post is also here for your convenience:

• Service Principal Name (SPN) checklist for Kerberos authentication with IIS 7.0/7.5

-

And the guys from IIS support in France have also written a great article about troubleshooting Kerberos

• Things to check when Kerberos authentication fails using IIS/IE

-

Read all these blog posts, and you are up to speed in no time when the need arises to troubleshoot authentication problems. 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/ ########
———————————————————————————————

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

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

-

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!

-

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.

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

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

(2011-02-13) When Will The Password Expire For An AD User Account And What Happens Then?

A few weeks ago I was discussing an issue with a colleague he experienced at his customer. The issue was about password expiration and I thought it was also worth to post the technical parts of the discussion. As you may know, Windows itself, will warn you during logon (Windows XP) or right after logon in the notification area (Windows Vista and Windows 7).

If you log on interactively while your password is already expired, the system will force you to change the password before allowing you to continue to logon.

However, what would happen and what is the impact if:

1. you logon interactively while your password is still valid (i.e. not expired), AND
   
2. you are warned by Windows your password will expire within one day (optional if configured!), AND
   
3. you ignore that and do not change the password (depends on [2]), AND
   
4. your password expires a few hours after logging on (e.g. 3 hours) and before logging off again.
   

The universal IT answer to that is: "it depends!". Seriously, it really depends on the authentication protocol being used when accessing a resource, while your password has expired previously.

One of the users at my colleague’s customer experienced the following, after the previous 4 steps:

• Drive mappings still worked;
  
• Outlook still worked;
  
• Access to the internet did not work, and the user was prompted to provide credentials again.
  

After some research, the first two (Microsoft systems) used Kerberos as the authentication protocol and the last one (non-Microsoft system) used NTLM as the authentication protocol. Detailed information about the Kerberos authentication protocol can be found here and here and here. Detailed information about the NTLM authentication protocol can be found here and here.

A very very very high-level overview of both authentication mechanisms can also be read here in this post I wrote once.

To make it more easy to understand, I will provide some high-level information (but with more depth than the previous post) when using either authentication protocol to access a resource. Windows will always try to use Kerberos first and if that is not possible it will fallback to NTLM.

The version of accessing a resource with the Kerberos authentication protocol, can be found here.

In short, when resources are accessed through the Kerberos authentication protocol…. If your password expires after you have logged on, you will be able to access resources through the Kerberos authentication protocol for as long as the TGT renewal period has not ended. As soon as the TGT renewal period has ended, you will be prompted to provide credentials, and depending on the resource (e.g. Exchange) you may get the possibility to change your password on the fly.

The version of accessing a resource with the NTLM authentication protocol, can be found here.

In short, when resources are accessed through the NTLM authentication protocol…. If your password expires after you have logged on, you will be NOT able to access resources through the NTLM authentication protocol. As soon as the password expires, you will be prompted to provide credentials, and depending on the resource (e.g. Exchange) you may get the possibility to change your password on the fly.

So, the moral of the story is: "change the password as soon as you are warned it is going to expire"!

Another solution would be to scan for expiring passwords and notify the user through e-mail to change his/her password and if needed in addition force the user to change the password at next logon earlier than the password expires. This can be accomplished quite easily with the correct tools, and if you are using FIM 2010, it is also quite easy to accomplish. Watch out for an upcoming blog post from me on how to do that using FIM 2010!

If you want to do this by using a custom made script (e.g. VBScript, PowerShell), then the complexity of logic in the script depends on whether or not you are using Password Settings Objects (PSO). For more information about PSOs, click here and here.

Below, I will explain the logic of what the script should do according to my opinion. A free unsupported tool that can do just the mailing part can be found here.

Before continuing, lets define the password lifecycle timeline as shown in the picture below.

['A'] When NOT using PSOs, just the password settings in the default domain GPO
(Also see a similar article about this on MSDN: How Long Until My Password Expires?)

• Retrieve a list of user accounts that match the following criteria:
  
  • User accounts, AND –> (objectCategory=person)(objectClass=user)
    
  • Enabled, AND –> (!(userAccountControl:1.2.840.113556.1.4.803:=2))
    
  • Password will expire, AND –> (!(userAccountControl:1.2.840.113556.1.4.803:=65536))
    
  • Mailbox/mail-enabled –> (mail=*)
    
• Read the maximum password age "maxPwdAge" from the domain NC. If set to 0 (zero) then stop processing as then passwords will not expire for any AD user account;
  
• Define a warn period in days which is the number of days before the password expiration date;
  
• For each AD user account in the list:
  
  • Retrieve the "pwdLastSet" attribute;
    
  • Calculate the password expiration date by adding the maximum password age to the password last set date;
    
  • Calculate the warn period starting date by extracting the warn period from the password expiration date;
    
  • Based upon the calculated information, perform the following action(s):
    
    • [1]
      
      • Send an e-mail if TODAY (or NOW) falls after the warn period starting date AND before the password expiration date
        
    • OR
      
    • [2]
      
      • Send an e-mail if TODAY (or NOW) falls after the warn period starting date AND before one day before the password expiration date
        AND
        
      • Configure the AD user account with ‘change password at next logon’ if TODAY (or NOW) falls within one day before the password expiration date
        
    • OR
      
    • [3]
      
      • Configure the AD user account with ‘change password at next logon’ if TODAY (or NOW) falls within one day before the password expiration date
        

['B'] When using PSOs incl. the password settings in the default domain GPO

• Retrieve a list of user accounts that match the following criteria:
  
  • User accounts, AND –> (objectCategory=person)(objectClass=user)
    
  • Enabled, AND –> (!(userAccountControl:1.2.840.113556.1.4.803:=2))
    
  • Password will expire, AND –> (!(userAccountControl:1.2.840.113556.1.4.803:=65536))
    
  • Mailbox/mail-enabled –> (mail=*)
    
• Define a warn period in days which is the number of days before the password expiration date;
  
• For each AD user account in the list:
  
  • Retrieve the value of the "pwdLastSet" attribute;
    
  • Retrieve the value of the "msDS-ResultantPSO" attribute (constructed attribute);
    
  • Logic around retrieved from "msDS-ResultantPSO" attribute:
    
    • If no value (<NOT SET>) exists in the attribute, read the maximum password age "maxPwdAge" from the domain NC. If set to 0 (zero) then stop processing as then passwords will not expire for this AD user account;
      
    • If a value (distinguished Name of PSO) exists in the attribute, read the maximum password age "msDS-MaximumPasswordAge" from the PSO object. If set to 0 (zero) then stop processing as then passwords will not expire for this AD user account;
      
  • Calculate the password expiration date by adding the maximum password age to the password last set date;
    
  • Calculate the warn period starting date by extracting the warn period from the password expiration date;
    
  • Based upon the calculated information, perform the following action(s):
    
    • [1]
      
      • Send an e-mail if TODAY (or NOW) falls after the warn period starting date AND before the password expiration date
        
    • OR
      
    • [2]
      
      • Send an e-mail if TODAY (or NOW) falls after the warn period starting date AND before one day before the password expiration date
        AND
        
      • Configure the AD user account with ‘change password at next logon’ if TODAY (or NOW) falls within one day before the password expiration date
        
    • OR
      
    • [3]
      
      • Configure the AD user account with ‘change password at next logon’ if TODAY (or NOW) falls within one day before the password expiration date
        

As you can see, script ['B'] is a lot more complex because of the usage of PSOs. It becomes more complex because you cannot query for a list of AD user accounts and retrieve the resultant PSO, but rather you need to query for a list of users and then for each user individually query for the resultant PSO. Either way, as soon as you know which resultant PSO is being used by that AD user account, you need to query the resultant PSO for the maximum password age. Because multiple accounts may use the same resultant PSO, that same PSO will be queried multiple times for the same information. You could enhance this by querying all PSOs and retrieve the maximum password age and "cache" it somewhere and the use the cache to retrieve the maximum password age to calculate the password expiration date.

Whatever script you use (['A'] or ['B']), you can schedule as task that executes the script at midnight. The configuration of the AD user account with ‘change password at next logon’ should only occur for those AD user accounts for which the password will expire in the next 23 hours. This way, as soon as the user logs on, he/she will be forced immediately to change it in the morning. This could lower the impact when a user is able to access resources through the Kerberos authN protocol, but not through the NTLM authN protocol, when the password expires after the user logs on and ignores the warning message which states the user should change the password because it will expire soon.

-

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

(2011-02-13) Accessing A Resource With The Kerberos Authentication Protocol

Like the mythical guard (the three headed dog), the Kerberos protocol has three heads, or in other words three parties are involved and each with its own purpose and interest: a (requesting) client, a (targeted) server, and a trusted third party to mediate between the first two. The trusted intermediary in this protocol is the Key Distribution Center (KDC), which runs on every Windows DC (RWDC and RODC) by default. The KDC is a service running on a physically secure server (HINT: amongst other reasons, this is also why a DC MUST be physically secured!). It maintains a database with account information for all security principals (users and computers) in its realm. A realm is also the Kerberos equivalent of an AD domain in Windows. Along with other information about each security principal, the KDC stores a cryptographic key known only to the principal and the KDC.

During the interactive logon the domain name, the user name and the password are collected as the credentials to generate authentication data (Kerberos tickets) which is then used for subsequent network logons. The Kerberos client on the user’s computer will convert the password into an encryption key by passing it through a one-way hash function. This encryption key will be the user’s master key (i.e. the password in a different format). Using the master key for the long term would be a bad idea as it is derived from the password. That’s why the client instead uses a temporary key received from a Key Distribution Center (KDC) which will only be valid for the current logon session. So when a user logs on to a client, the client requests a special ticket for the KDC itself, which is called the "Ticket Granting Ticket (TGT)".

An example of a TGT ticket is shown below in the picture.

The TGT is encrypted with the KDC’s master key (this master key is derived from the domain-wide KRBTGT user account in case of a RWDC or the RODC specific KRBTGT user account in case of an RODC). This TGT is what will be used by the client during its current logon session for subsequent resource access requests through the use of service tickets. From this point the password of the logged on user will not be used anymore (!). The lifetime of this TGT can be configured through the GPO setting "Maximum lifetime for user ticket", and by default this lifetime equals to 10 hours. At the same time this same TGT can be renewed a number of times within a period which is configured in the GPO setting "Maximum lifetime for user ticket renewal". By the default this period equals 7 days.

The "Maximum lifetime for user ticket" GPO setting determines the amount of time the TGT is valid until it will expire at some point in time. The best practice value for this setting should reflect the average amount of time a user uses his/her computer during a normal working day. So, by default this is configured with 10 hours. At the end of the ticket lifetime, the user’s computer requests to renew the existing TGT. A shorter value for this setting provides greater security, but it increases network traffic. A longer value for this setting provides less security, but it also decreases network traffic.

The "Maximum lifetime for user ticket renewal" GPO setting determines the period in which a user’s TGT can be renewed. So, by default this is configured with 7 days. A shorter period eases the requirement for users to reauthenticate. An attacker with a renewable TGT ticket can renew it for as long as this setting allows it. Shorter renewal periods, makes the work of an attacker more difficult and it also increases the authentication load on DCs.

When a client wants to create a secure connection with a server, the client begins by sending a request to the KDC, not to the server that it wants to reach. The KDC creates and sends to the client a unique session key for the client and the server to authenticate each other. The KDC has access to both the client’s master key and the server’s master key. The KDC encrypts the server’s copy of the session key using the server’s master key, and the client’s copy using the client’s master key.

Unlike the NTLM authentication protocol, when a client wants to access a resource, it does not access the resource right way. First it requests from the KDC a special ticket called a service ticket that can be used to access a specific resource on a server. The client authenticates itself to the KDC using the previously received TGT. Based upon that TGT the KDC generates a service ticket and hands it out to the client. The client then hands out the service ticket to the resource to authenticate itself. Because the resource also trusts the KDC, it will also trust the information in the service ticket. This service ticket is what will be used by the client during its current logon session to access the resource. The lifetime of this service ticket can be configured through the GPO setting " Maximum lifetime for service ticket", and by default this lifetime equals to 600 minutes (=10 hours).

The "Maximum lifetime for service ticket" GPO setting determines the amount of time the service is valid until it will expire at some point in time. This setting usually is configured with the same value as the "Maximum lifetime for user ticket" GPO setting. It might be shorter if there is a need for secure authentication to services in addition to what is required for user authentication. It might be longer if users require uninterrupted access to services for long periods of time. For example, you might need to extend the service ticket lifetime if services are used for a longer period than the duration of the user ticket lifetime. If no special requirements exist for the service ticket lifetime, do not extend the lifetime of the ticket and use the default value. The maximum service ticket lifetime must be greater than 10 minutes and less than or equal to the maximum lifetime for user ticket setting. By default, this value is set to 600 minutes (10 hours) in the Default Domain Group Policy object (GPO). Ongoing operations are not interrupted if the session ticket, used to authenticate the connection, expires before the operation is complete.

If a client presents an expired service ticket when it connects to a resource, the server returns an error message. The client must request a new service ticket from the KDC to access that resource. Authentication of the client again occurs with the TGT. Once a connection to a resource is authenticated, it no longer matters whether the service ticket remains valid. Service tickets are used only to authenticate new connections with servers. Ongoing operations are not interrupted if the service ticket that is used to authenticate the connection expires during the connection. So, with Kerberos the path is: "Client" –> "DC" –> "Client" –> "Resource/Server" –> "Client"

An example of a service ticket is shown below in the picture.

The following steps present an outline of Kerberos authentication, which is detailed in 4 phases.

Phase 1: User Logon To A Client

1. A user enters the domain name, the user name and its password on the client computer;
   
2. The Kerberos client on the user’s computer will convert the password into an encryption key by passing it through a one-way hash function. This encryption key will be the user’s master key.
   

Phase 2: Client Authentication

1. The client sends a clear text message containing the user name to the KDC (a.k.a. Authentication Server, AS) (Note: Neither the master key nor the password is ever sent to the KDC).
   
2. The KDC checks to see if the user is in its AD database and if it is, the KDC generates the secret key by hashing the password of the user found in the AD database;
   
3. The KDC checks to see if the client computer is in its AD database. If it is, the KDC sends back the following two messages to the client:
   
   1. Message A: Client/Ticket Granting Service (TGS) Session Key encrypted using the secret key of the client/user;
      
   2. Message B: Ticket Granting Ticket (TGT) (which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the KDC/TGS.
      
4. Once the client receives messages A and B, it attempts to decrypt message A with the secret key generated from the password entered by the user at logon. If the password entered by the user does not match the password in the AD database, the client’s secret key will be different and thus unable to decrypt message A. With a valid password and secret key the client decrypts message A to obtain the Client/TGS Session Key. This session key is used for further communications with the KDC/TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS’s secret key.) At this point, the client has enough information to authenticate itself to the KDC/TGS and request service tickets as needed. The password will no longer be used.
   

Phase 3: Client Service Authorization

1. When requesting services, the client sends the following two messages to the KDC/TGS;
   
   1. Message C: Composed of the TGT from message B and the ID of the requested service;
      
   2. Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key;
      
2. Upon receiving messages C and D, the KDC/TGS retrieves message B out of message C. It decrypts message B using the KDC/TGS secret key. This gives it the "client/TGS session key". Using this key, the KDC/TGS decrypts message D (Authenticator) and sends the following two messages to the client:
   
   1. Message E: Client-to-server ticket (which includes the client ID, client network address, validity period and Client/Server Session Key) encrypted using the service’s secret key;
      
   2. Message F: Client/server session key encrypted with the Client/TGS Session Key.
      

Phase 4: Client Service Request

1. Upon receiving messages E and F from the KDC/TGS, the client has enough information to authenticate itself to the resource on the server. The client connects to the resource on the server and sends the following two messages:
   
   1. Message E from the previous step (the client-to-server ticket, encrypted using service’s secret key);
      
   2. Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using client/server session key.
      
2. The resource on the server decrypts the ticket using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, the resource on the server decrypts the Authenticator and sends the following message to the client to confirm its true identity and willingness to serve the client:
   
   1. Message H: the timestamp found in client’s Authenticator plus 1, encrypted using the Client/Server Session Key.
      
3. The client decrypts the confirmation using the Client/Server Session Key and checks whether the timestamp is correctly updated. If so, then the client can trust the server and can start issuing service requests to the server.
   
4. The server provides the requested services to the client.
   

Now look at step 1.2, step 2.2 and step 2.4. If the password has expired after the user logged on interactively, but before the user accessed the resource, the DC will hand out a service ticket for the specific resource because the client is authenticating itself using the TGT. Access to resources is allowed using the Kerberos protocol (in other words: requesting service tickets) as long as the TGT is valid and as long as it can be renewed. The TGT remains valid after being renewed within the configured period until a completely new TGT must generated using the master key of the user, which depends on the password of the user. So, if during a logon session, the user’s password expires before the user logs off, the TGT remains valid and can be renewed over and over again as long as the TGT renewal period has not ended. With that TGT, or a renewed TGT, service tickets can be requested to access resources that support the kerberos authentication protocol. Be aware though, because your password has expired you might be reminded by the OS over and over again to provide your password again as shown in the picture below.

However, if during the same logon session the password expires and at a later stage the renewal period ends, the user will start to experience issues when accessing resources. This occurs because service tickets cannot be requested anymore as the TGT is not valid anymore and it cannot be renewed anymore. The renewal period has ended and a brand new TGT needs to be issued, but that will not occur because the password has expired.

An example of issues with Outlook/Exchange in the latter case is shown below in the two pictures. Without logging off, you get the possibility to change the password.

An example of issues with drive mappings and/or UNC paths in the latter case is shown below in the two pictures.

The version of accessing a resource with the NTLM authentication protocol, can be found here.

So, the moral of the story is: "change the password as soon as you are warned it is going to expire"!

-

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