Jorge's Quest For Knowledge!

All 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 ‘Kerberos AuthN’ Category

(2015-11-08) Kerberos Constrained Delegation (KCD) Visualized The Easy Way

Posted by Jorge on 2015-11-08


Kerberos Constrained Delegation (KCD) in general can be very difficult to understand, especially if you take all the possible scenarios into account. This post is not about explaining KCD old-style (pre-Windows Server 2012) and/or KCD new-style (Windows Server 2012 and higher). It is rather about visualizing the possible scenarios I could think of. Hopefully your scenario is included, so that you can easily see what is possible or not.

As an example of services I use a web based front-end and a SQL based back-end.

In all the scenarios specified below the following applies:

image

Figure 1: Types Of User Accounts Used In KCD Setups

KCD Old-Style, supported by both pre-Windows Server 2012 Servers/DCs and Windows Server 2012 Servers/DCs and Higher 

To support KCD Old-Style, the following must be true:

  • Front-End Server is running Windows Server 2008 R2 or lower
    OR
  • Back-End Server is running Windows Server 2008 R2 or lower
    OR
  • At least 1 RWDC running Windows Server 2012 is not available in the same AD domain as the front-end server
    OR
  • At least 1 RWDC running Windows Server 2012 is not available in the same AD domain as the back-end server
    OR
  • KCD is be configured through delegated kerberos constrained delegation (targeted resource is not configured to have the impersonating service account listed in the attribute “msDS-AllowedToActOnBehalfOfOtherIdentity” and delegated account is rather configured to have the target resource listed in the attribute “msDS-AllowedToDelegatedTo”)
    OR
  • Any of the above combined in some way

[Scenario 1]

image

Figure 2: KCD Old Style – Single Domain Forest

[Scenario 2]

image

Figure 3: KCD Old Style – Multiple Single Domain Forests

[Scenario 3]

image

Figure 4: KCD Old Style – Multiple Domain Forest

KCD New-Style, supported by only Windows Server 2012 Servers/DCs and Higher

To support KCD New-Style, the following must be true:

  • Front-End Server must run Windows Server 2012 or higher
    AND
  • Back-End Server must run Windows Server 2012 or higher
  • AND
  • At least 1 RWDC running Windows Server 2012 must be available in the same AD domain as the front-end server. Other RWDCs/RODCs running either Windows Server 2008 or Windows Server 2008 R2 must have the hotfix MS-KBQ2665790 installed
    AND
  • At least 1 RWDC running Windows Server 2012 must be available in the same AD domain as the back-end server. Other RWDCs/RODCs running either Windows Server 2008 or Windows Server 2008 R2 must have the hotfix MS-KBQ2665790 installed
    AND
  • KCD must be configured through resource-based kerberos constrained delegation (targeted resource must have the impersonating service account listed in the attribute “msDS-AllowedToActOnBehalfOfOtherIdentity”)

[Scenario 1]

image

Figure 5: KCD New Style – Single Domain Forest

[Scenario 2]

image

Figure 6: KCD New Style – Multiple Domain Forest

[Scenario 3]

image

Figure 7: KCD New Style – Multiple Single Domain Forests

[Scenario 4]

image

Figure 8: KCD New Style – Multiple Single Domain Forests

[Scenario 5]

image

Figure 9: KCD New Style – Multiple Single Domain Forests

[Scenario 6]

image

Figure 10: KCD New Style – Multiple Single Domain Forests

[Scenario 7]

image

Figure 11: KCD New Style – Multiple Single Domain Forests (Similar To KCD Old Style In Figure 3)

[Scenario 8]

image

Figure 12: KCD New Style – Multiple Single Domain Forests (Similar To KCD Old Style In Figure 4)

To read more and learn about all the dirty details, have a look at the following blog posts/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), Kerberos AuthN, Kerberos Constrained Delegation | Leave a Comment »

(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 »

(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 »

 
%d bloggers like this: