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

(2019-08-01) Moving Towards The Password-Less Concept – One Heck Of Journey And Badly Needed

Posted by Jorge on 2019-08-01


Current passwords are potentially weak and any use of those in general further weakens an infrastructure. Preferably any org needs to move away from using passwords as much as possible. This means for example preventing the usage of passwords, and instead use SSO and/or other more secure authentication mechanisms. In other words, the adoption of the "Password-Less" concept. However, for those scenarios that cannot adopt “Password-Less" (yet), passwords must be strengthened or better secured at rest and in transport. In today’s world “identity” is the key control plane. Therefore protecting the “identity” and everything related is of utmost importance. Usage of weak passwords presents unacceptable security risks to any org. We all know that, don’t we?! Now you need to act to secure yourself as best as possible.

Going password-less is a journey on its own and implementing that concept could mean for example (NOT an exhaustive list and also in random order!):

  • Ban “weak/common” words from being used in weak passwords using Azure AD Password Protection and/or LithNet Password Protection For Active Directory (LPP) (last one is free and the feature set is huge!)
  • Check AD for weak passwords and weak accounts configurations and follow up with risk mitigating actions. Can be done through LPP and DS Internals and generic LDAP queries
  • Help and educate users in terms of using, storing, generating, uniqueness, sharing/distributing, etc. for less frequent (complex and long) and regular used (pass phrases) passwords. Preferably use machine generated passwords as those have no human logic in them, or use (long) passphrases or bang your head against the keyboard multiple times while on and off holding the SHIFT key (last one, kidding!) (people tend to implement logic or sequences somehow in passwords to not forget those long passwords and to make them unique)
  • Move service accounts in AD from regular service accounts to:
    • Group Managed Service Accounts if possible
    • …and if that’s not possible have a password vault store, manage and change passwords on a regular basis
    • …and if that’s not possible keep using regular service accounts with long and unique passwords
  • If possible, increase the password length to a minimum of 15 characters for users
  • Move away from periodic password changes to risk based password changes (e.g. through Azure AD Identity Protection)
  • Using strong and unique passwords for every individual system/site not supporting SSO (the strength of a password is mostly determined by its length, the longer the better!);
  • Securely store passwords in an MFA enabled password manager/vault that is available on both your desktop and mobile device(s)
  • Make Self-Service Password Reset available to users for those occasions where the password is needed but the user has forgotten the password or has locked itself out
  • When using ADFS, implement extranet lockout policy
  • Only use HTTPS connections (at least TLS1.2) in your environment and do not use HTTP
  • Update systems, tools, scripts to NOT set weak/generic/well-known password or account configurations (e.g. LM Hashes, Password Not Required, Password Never Expires, etc)
  • Decrease the use of passwords as much as possible by:
    • Implementing SSO
    • Implement password-less authN for Windows computers (e.g. Windows Hello for Business) and remove password based authN if possible
    • Implement password-less authN for mobile devices (e.g. Azure AD MFA + AuthNtor App Notifications And OTPs) as primary authN, preferably with at least 2 factors during that primary authN, or implement password authN as secondary authN (when using ADFS)

Additional Resources:

Hope this helps you!

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Azure AD Password Protection, Kerberos AuthN, Microsoft Authenticator App, Multi-Factor AuthN, NTLM AuthN, Password-Less, Security, Self-Service Password Reset, SSO, WH4B, Windows Azure Active Directory, Windows Client, Windows Integrated AuthN | 1 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 | 1 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 | 1 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 | 3 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 | 1 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 »

 
%d bloggers like this: