Jorge's Quest For Knowledge!

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

Archive for the ‘NTLM AuthN’ Category

(2014-03-27) Determining Users Configured With "Trusted For Delegation"

Posted by Jorge on 2014-03-27


You may need to be able to query AD and find all users accounts that have been configure with any of the three following delegation options:

  1. Trust This User For Delegation To Any Service (Kerberos Only) – A.K.A. "Open Delegation"
  2. Trust This User For Delegation To Specified Services Only – Use Any Authenticaton Protocol – A.K.A. "Constrained Delegation"
  3. Trust This User For Delegation To Specified Services Only – Use Kerberos Only – A.K.A. "Constrained Delegation"

[AD.1] Querying ALL Users with "Trusted For Delegation To Any Service (Kerberos Only)"

"Trusted For Delegation To Any Service (Kerberos Only)" translates to the "TRUSTED_FOR_DELEGATION" bit on the userAccountControl attribute, which in its turn translates to decimal value "524288".

Import-Module ActiveDirectory Get-ADUser -Server "<FQDN of DC>" -SearchBase "<DN of Domain NC>" -LdapFilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)" | %{$_.DistinguishedName}

[AD.2a] Querying ALL Users with "Trusted For Delegation To Specific Services – Any AuthN (At Least One Service Specified)"

"Trusted For Delegation To Specific Services – Any AuthN" translates to the "TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION" bit on the userAccountControl attribute, which in its turn translates to decimal value "16777216".

Import-Module ActiveDirectory Get-ADUser -Server "<FQDN of DC>" -SearchBase "<DN of Domain NC>" -LdapFilter "(&(userAccountControl:1.2.840.113556.1.4.803:=16777216)(msDS-AllowedToDelegateTo=*))" | %{$_.DistinguishedName}

[AD.2b] Querying ALL Users with "Trusted For Delegation To Specific Services – Any AuthN (No Service Specified, Empty List)"

"Trusted For Delegation To Specific Services – Any AuthN" translates to the "TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION" bit on the userAccountControl attribute, which in its turn translates to decimal value "16777216".

Import-Module ActiveDirectory Get-ADUser -Server "<FQDN of DC>" -SearchBase "<DN of Domain NC>" -LdapFilter "(&(userAccountControl:1.2.840.113556.1.4.803:=16777216)(!(msDS-AllowedToDelegateTo=*)))" | %{$_.DistinguishedName}

REMARK: Some systems/applications/appliances may use this scenario to for any protocol and still use open delegation. One example is a Riverbed Steelhead Appliance which is able to optimize network traffic for different protocols. For the WHY I refer to the documentation of the systems/applications/appliances.

[AD.3a] Querying ALL Users with "Trusted For Delegation To Specific Services – Kerberos AuthN (At Least One Service Specified)"

"Trusted For Delegation To Specific Services – Kerberos AuthN" DOES NOT translates to any bit on the userAccountControl attribute.

Import-Module ActiveDirectory Get-ADUser -Server "<FQDN of DC>" -SearchBase "<DN of Domain NC>" -LdapFilter "(&(!(|(userAccountControl:1.2.840.113556.1.4.803:=524288)(userAccountControl:1.2.840.113556.1.4.803:=16777216)))(msDS-AllowedToDelegateTo=*))" | %{$_.DistinguishedName}

[AD.3b] Querying ALL Users with "Trusted For Delegation To Specific Services – Kerberos AuthN (No Service Specified, Empty List)"

It is not possible to query this as "Trusted For Delegation To Specific Services" expects a list of at least one service for which delegation is allowed and in this case it does not translate to any bit on the userAccountControl attribute. Because of that it would return any computer account which basically is a false result!

REMARK: I used PowerShell here, but of course you can use the same LDAP filter with any other LDAP Querying tool such as ADFIND. Remember that you may need to amend the LDAP filter to target the correct object type!

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

———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Delegation, Kerberos AuthN, NTLM AuthN | Leave a Comment »

(2014-03-26) Determining Computers Configured With "Trusted For Delegation"

Posted by Jorge on 2014-03-26


You may need to be able to query AD and find all computer accounts that have been configure with any of the three following delegation options:

  1. Trust This User For Delegation To Any Service (Kerberos Only) – A.K.A. "Open Delegation"
  2. Trust This User For Delegation To Specified Services Only – Use Any Authenticaton Protocol – A.K.A. "Constrained Delegation"
  3. Trust This User For Delegation To Specified Services Only – Use Kerberos Only – A.K.A. "Constrained Delegation"

[AD.1] Querying ALL Computers with "Trusted For Delegation To Any Service (Kerberos Only)"

"Trusted For Delegation To Any Service (Kerberos Only)" translates to the "TRUSTED_FOR_DELEGATION" bit on the userAccountControl attribute, which in its turn translates to decimal value "524288".

Import-Module ActiveDirectory Get-ADComputer -Server "<FQDN of DC>" -SearchBase "<DN of Domain NC>" -LdapFilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)" | %{$_.DistinguishedName}

[AD.2a] Querying ALL Computers with "Trusted For Delegation To Specific Services – Any AuthN (At Least One Service Specified)"

"Trusted For Delegation To Specific Services – Any AuthN" translates to the "TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION" bit on the userAccountControl attribute, which in its turn translates to decimal value "16777216".

Import-Module ActiveDirectory Get-ADComputer -Server "<FQDN of DC>" -SearchBase "<DN of Domain NC>" -LdapFilter "(&(userAccountControl:1.2.840.113556.1.4.803:=16777216)(msDS-AllowedToDelegateTo=*))" | %{$_.DistinguishedName}

[AD.2b] Querying ALL Computers with "Trusted For Delegation To Specific Services – Any AuthN (No Service Specified, Empty List)"

"Trusted For Delegation To Specific Services – Any AuthN" translates to the "TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION" bit on the userAccountControl attribute, which in its turn translates to decimal value "16777216".

Import-Module ActiveDirectory Get-ADComputer -Server "<FQDN of DC>" -SearchBase "<DN of Domain NC>" -LdapFilter "(&(userAccountControl:1.2.840.113556.1.4.803:=16777216)(!(msDS-AllowedToDelegateTo=*)))" | %{$_.DistinguishedName}

REMARK: Some systems/applications/appliances may use this scenario to for any protocol and still use open delegation. One example is a Riverbed Steelhead Appliance which is able to optimize network traffic for different protocols. For the WHY I refer to the documentation of the systems/applications/appliances.

[AD.3a] Querying ALL Computers with "Trusted For Delegation To Specific Services – Kerberos AuthN (At Least One Service Specified)"

"Trusted For Delegation To Specific Services – Kerberos AuthN" DOES NOT translates to any bit on the userAccountControl attribute.

Import-Module ActiveDirectory Get-ADComputer -Server "<FQDN of DC>" -SearchBase "<DN of Domain NC>" -LdapFilter "(&(!(|(userAccountControl:1.2.840.113556.1.4.803:=524288)(userAccountControl:1.2.840.113556.1.4.803:=16777216)))(msDS-AllowedToDelegateTo=*))" | %{$_.DistinguishedName}

[AD.3b] Querying ALL Computers with "Trusted For Delegation To Specific Services – Kerberos AuthN (No Service Specified, Empty List)"

It is not possible to query this as "Trusted For Delegation To Specific Services" expects a list of at least one service for which delegation is allowed and in this case it does not translate to any bit on the userAccountControl attribute. Because of that it would return any computer account which basically is a false result!

REMARK: I used PowerShell here, but of course you can use the same LDAP filter with any other LDAP Querying tool such as ADFIND. Remember that you may need to amend the LDAP filter to target the correct object type!

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

———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Kerberos AuthN, NTLM AuthN | Leave a Comment »

(2014-03-25) An Account With "Trusted For Delegation" – What Are The Risks?

Posted by Jorge on 2014-03-25


Sometimes when implementing some system/application/appliance that needs a service account, that service account may need to be configured with "Trusted For Delegation". The latter has three flavors as shown in figure 1 below.

Figure 1: The Delegation TAB After Configuring A Service Principal Name

As you can see in figure 1, you have 4 options you can configure, being:

  1. Trust This User For Delegation To Any Service (Kerberos Only) – A.K.A. "Open Delegation"
  2. Trust This User For Delegation To Specified Services Only – Use Kerberos Only – A.K.A. "Constrained Delegation"
  3. Trust This User For Delegation To Specified Services Only – Use Any Authenticaton Protocol – A.K.A. "Constrained Delegation"
  4. Do Not Trusted This User For Delegation – (this is obvious, isn’t it?!)

Now, you may wonder: "what are the risks?". Keep reading! Smile

An AD user account or computer account with such powers is worthless on its own. You need to have a system/application/appliance using such an account that is being targeted by end users and that is providing some kind of service.

With regards to the system/application/appliance that has that account configured you are fully trusting the code of the system/application/appliance to act on a user’s behalf for any OR specific services it is performing delegation for. With that in mind you should also think about how likely is it for the system/application/appliance to be "misused" during an attack? As risk mitigations you can think of measures such as physical access controls (secure rooms) and network access controls (firewalls) access controls, but also having the latest patches/hotfixes applied that are recommended by the vendor.
It also comes down to the question if you trust the administrators and/or vendor of the system/application/appliance to not misuse those high privileges. Having trusted administrators with the correct delegation of control supported (pro-active measure) with the correct auditing measures (re-active measure) helps to "secure" the system/application/appliance in a proactive and re-active way.

In addition, if even possible AND after testing, you may be able to configure the following user rights for the service account on different Windows systems to mitigate risks:
(
User Rights)

  • Deny Access To This Computer From The Network
  • Deny Log On As A Batch Job
  • Deny Log On As A Service
  • Deny Log On Locally
  • Deny Log On Through Terminal Services

Again in addition, you can configure the account with a very secure password and if needed/possible use the (at least) four-eyes principle to make sure nobody ever knows the complete password but just part of it.

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

Posted in Active Directory Domain Services (ADDS), Delegation, Kerberos AuthN, NTLM AuthN | 2 Comments »

(2014-01-18) Tracking NTLM Authentication Delays And Failures In Both Windows Server 2008 SP2 And Windows Server 2008 R2

Posted by Jorge on 2014-01-18


After installing a hotfix (see KBs below) you will be able to track NTLM authentication delays and failures in both Windows Server 2008 SP2 and Windows Server 2008 R2.

SYMPTOMS

Consider the following scenario:

  • You have one or more forests that have multiple domains
  • There are combinations of users and resources (such as applications or proxy servers) in different domains
  • There are lots of NTLM logon requests from remote domain users to a resource server that is running either Windows Server 2008 Service Pack 2 (SP2) or Windows Server 2008 R2.

In this scenario, the NTLM requests time out. For example, Exchange clients do not authenticate to the Exchange server when this issue occurs. Therefore, users cannot access their mailboxes, and Microsoft Outlook seems to stop responding.

CAUSE

This issue occurs because the NTLM API throttling limit is reached

MORE DETAILED INFORMATION

For more detailed information see the corresponding KB articles:

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

Posted in Active Directory Domain Services (ADDS), NTLM AuthN | Leave a Comment »

(2013-11-04) What Happens When The AD User Account Expires While Being Logged On?

Posted by Jorge on 2013-11-04


A colleague of mine asked me the following question: "What Happens When The AD User Account Expires While Being Logged On?"

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

  1. you logon interactively while your AD user account and password are valid, AND
  2. your AD user account expires.

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

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 AD user account (not your password!) suddenly expires while you are 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 most likely will also not be prompted for credentials.

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 AD user account (not your password!) suddenly expires while you are logged on, you will be NOT able to access resources through the NTLM authentication protocol. As soon as your AD user account has expired and you then try to access a resource through the NTLM authentication protocol, you will be prompted to provide credentials.

So, the moral of the story is: "if you know a person still needs to use his/her AD user account make sure the AD user account DOES NOT expire"!

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

Also see: (2013-11-03) What Happens When The Password Of A User Is Reset While Being Logged On?

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

Posted in Active Directory Domain Services (ADDS), Kerberos AuthN, NTLM AuthN | Leave a Comment »

(2013-11-03) What Happens When The Password Of A User Is Reset While Being Logged On?

Posted by Jorge on 2013-11-03


A colleague of mine asked me the following question: "What Happens When The Password Of A User Is Reset By An Admin Or The Service Desk While The User Is Logged On?"

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

  1. you logon interactively while your password is valid, AND
  2. an administrator resets your password in AD like that without warning you.

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

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 in AD is reset while you are 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.

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 in AD is reset while you are logged on, you will be NOT able to access resources through the NTLM authentication protocol. As soon as the password is reset and you then try to access a resource through the NTLM authentication protocol, you will be prompted to provide credentials.

So, the moral of the story is: "do not reset the password of a user in AD like that without warning the user or without the request of the user and you have verified it is the actual person using the user account"!

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

Also see: (2013-11-04) What Happens When The AD User Account Expires While Being Logged On?

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

Posted in Active Directory Domain Services (ADDS), Kerberos AuthN, NTLM AuthN | 2 Comments »

(2013-09-06) Duplicate SPN Breaks Trust Between Client/Server And Active Directory

Posted by Jorge on 2013-09-06


A colleague and I were setting up an ADFS test environment with ADFS v2 and ADFS v3. We used ADFS v3 as both the Identity Provider and Service Provider and we used ADFS v2 as the Identity Provider. ADFS v3 was installed on just one member server and it was configured with a custom service account and a custom ADFS service FQDN. The ADFS service FQDN was different than the server FQDN. The service FQDN was therefore registered on the custom service account as (without the quotes) “HOST/<ADFS Service FQDN>”. ADFS v2 was also installed on just one member server and it was configured with a custom service account and, with laziness as the main reason, we configured the ADFS  service FQDN to be exactly the same as the server FQDN (hint: this is where it went wrong!).

So, by default every Windows Client and Windows Server registers, amongst others, the following SPNs on its own computer account: HOST/<NetBIOS Name Of Computer> (e.g. HOST/MYCOMPUTER) and HOST/<FQDN of Computer> (e.g. HOST/MYCOMPUTER.DOMAIN.COM). As a regular/best practice to get Kerberos working on an ADFS STS, you should register the SPN HOST/<ADFS Service FQDN> (e.g. HOST/ADFS.DOMAIN.COM) on the service account the ADFS service is running on..

In the ADFS v3 case we did it correctly. And in the ADFS v2 case, because of our laziness, we made a mistake without even being aware of it. As the ADFS Service FQDN matches the server FQDN you end up with “HOST/<ADFS Service FQDN>”, which matches “HOST/<Server FQDN>” on two different security principals. In the case of ADFS v2 you would find the SPN on both the computer account and on the ADFS service account. In other words, the cause of all this was duplicate SPNs, which in our case is a stupid mistake!

This is just to explain of what happened and what the cause was upfront. ADFS in all this is just an example and is not directly related to the error or cause. All of this was done on W2K12, but it also applies to all other Windows OS’s!

We installed the Windows Server for ADFS and joined it to the AD domain. So far so good and everything is fine. We installed ADFS and performed the necessary configurations. We rebooted the server and suddenly we were surprised with the error “The trust relationship between this workstation and the primary domain failed” as shown in figure 1. What the heck!

image

Figure 1: “The Trust Relationship Between This Workstation And The Primary Domain Failed”

We saw this and our first reaction, honestly, was WTF!. We disjoined the server from the AD domain, reset its computer account password and rejoined it to the AD domain. So far so good, no errors at all. When trying to logon, we got the same error again as shown in figure 1. We disjoined the server from the AD domain again, reset its computer account password and rejoined it to the AD domain. Again, so far so good, no errors at all. When trying to logon, again we got the same error as shown in figure 1. OK, something is wrong! No shit, Sherlock!? Smile

On another server I executed the following PowerShell command line which leverages this script.

.\Search-EventLog-For-String.ps1 -listOfServers R1FSMBSV2.ADCORP.LAB -eventLogName Security -stringToSearchFor "An Error occured during Logon"

image

Figure 2a: “An Error Occurred During Logon” Event When I tried To Logon

image

Figure 2b: “An Error Occurred During Logon” Event When I tried To Logon

The next event proves Kerberos is not being used at all and instead NTLM is being used. This is because I’m running the script on a server other than the failing server and the script is contacting the failed server to read its event log by using NTLM authN. Remember, Kerberos authN is broken!

.\Search-EventLog-For-String.ps1 -listOfServers R1FSMBSV2.ADCORP.LAB -eventLogName System -stringToSearchFor "NTLM authentication"

image

Figure 3: Detection Of NTLM AuthN Being Used Instead Of Kerberos AuthN

Just to be sure and based upon the errors found above, we decided to scan the DCs in the same site as the failing server for “KDC_ERR_S_PRINCIPAL_UNKNOWN” errors.

.\Search-EventLog-For-String.ps1 -discoverDC LOCALSITE -eventLogName System -stringToSearchFor "KDC_ERR_S_PRINCIPAL_UNKNOWN" -table $true

.\Search-EventLog-For-String.ps1 -discoverDC LOCALSITE -eventLogName System -stringToSearchFor "KDC_ERR_S_PRINCIPAL_UNKNOWN"

image

Figure 4: Detection SPN Issues

Based on the previous output, we scanned the DCs in the same site as the failing server for “DS_SERVICE_PRINCIPAL_NAME” errors.

.\Search-EventLog-For-String.ps1 -discoverDC LOCALSITE -eventLogName System -stringToSearchFor "DS_SERVICE_PRINCIPAL_NAME" -table $true

.\Search-EventLog-For-String.ps1 -discoverDC LOCALSITE -eventLogName System -stringToSearchFor "DS_SERVICE_PRINCIPAL_NAME"

image

Figure 5: Duplicate SPNs Detected On Multiple AD accounts

As an additional check, we used SETSPN to determine if duplicate SPNs exist at all.

image

Figure 6: Accounts Detected In The AD Domain With The Same SPN Registered (By Using SETSPN)

Querying AD for the SPN (without the quotes) “HOST/R1FSMBSV2.ADCORP.LAB”, resulted in showing the information in figure 7 to see which accounts have been affected by having the same SPN registered!

image

Figure 7: Accounts Determined That Have The Same SPN Registered

The solution in this case was to change the SPN on the ADFS service account. First, we changed the ADFS Service FQDN and reregistered that SPN on the existing service account. We also removed the old SPN from the the service account. In ADFS terms we also had to change the ADFS Service Communication Certificate (just mentioned as a side note)

The moral of the story? Duplicate SPNs break stuff! Smile

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

Posted in Active Directory Domain Services (ADDS), Kerberos AuthN, NTLM AuthN | 3 Comments »

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

Posted by Jorge on 2012-11-10


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.

image

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.

image

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

image

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

image

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

image

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

image

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

image

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

image

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.

image

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.

image

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

image

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

Posted in Kerberos AuthN, NTLM AuthN, Tooling/Scripting | Leave a Comment »

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

Posted by Jorge on 2012-01-26


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:

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:

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:

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

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

Posted in Active Directory Domain Services (ADDS), Kerberos AuthN, NTLM AuthN | 1 Comment »

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

Posted by Jorge on 2011-02-13


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.

image

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

Posted in Active Directory Domain Services (ADDS), Kerberos AuthN, NTLM AuthN, Windows Client, Windows Server | 5 Comments »

 
%d bloggers like this: