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

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

Advertisements

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 | Leave a Comment »

(2019-05-27) (Un)Constrained Kerberos Delegation

Posted by Jorge on 2019-05-26


Within Windows Server Kerberos Delegation can be used to, for example, access data in a SQL database by a front-end service on behalf of the user accessing the front-end service.

The flow then looks like: USER (U)  —— access—-> FRONT-END SERVICE (FE) —— access on behalf of “U”—-> DATA (D).

While U accesses FE, FE then needs to access D on behalf of U. The “on behalf of” part is achieved through Kerberos Delegation.

When looking at Kerberos Delegation there are three flavors that can be used

  1. Unconstrained Kerberos Delegation
  2. Constrained Kerberos Delegation
  3. Resource-Based Kerberos Delegation

[ad.1] Unconstrained Kerberos Delegation

This is available in since Windows Server 2000 up to the latest and greatest version of Windows available today. It is VERY INSECURE, therefore avoid this if possible! Why is it insecure? Well, with UNconstrained Kerberos Delegation, the FE, when configured for Unconstrained Kerberos Delegation, is allowed to access ANY service without restrictions, and not just D. You could also call this “Account-Based Unconstrained Kerberos Delegation”

Imagine a bank vault (the “D”) and many other bank vaults and a bank clerk (the “FE”). The bank clerk is configured to access any access any bank vault on behalf of clients, but the bank clerk should really only access one specific bank vault (“D”) on behalf of clients. Yeah right! Better yet, the owner of the bank vaults do not have anything to say about this. Just shut up and allow access!

Read more about it:

[ad.2] Constrained Kerberos Delegation

This is available in since Windows Server 2003 (with FFL W2K3) up to the latest and greatest version of Windows available today. It is a better option than the previous option, so if you cannot implement the next option, then at least try this option! With Constrained Kerberos Delegation, the FE, when configured for Constrained Kerberos Delegation, is ONLY allowed to access specific services (e.g. only “D”) for which it has been configured to do so and not any service. You could also call this “Account-Based Constrained Kerberos Delegation”

Imagine a bank vault (the “D”) and many other bank vaults and a bank clerk (the “FE”). The bank clerk is configured to access only the specific bank vault (“D”) on behalf of clients. Other bank vaults cannot be accessed on behalf of clients. Sounds better, but the owner of that specific bank vaults still does not have anything to say about this. Just shut up and allow access!

Read more about it:

[ad.3] Resource-Based Kerberos Delegation

This is available in since Windows Server 2012 up to the latest and greatest version of Windows available today. This is the best option when compared to the previous 2 options. This does require the complete service chain (FE, D, AD domain for FE, AD domain for D and any domain in between) to run at least Windows Server 2012. With regards to AD domains, at least one Windows Server 2012 DC is needed and there are no dependencies on DFLs/FFLs. Guess what?! This is by default constrained, therefore no need to mention the word “Constrained”, otherwise it is the same as saying “wet water”! With “Resource-Based Kerberos Delegation”, the D, when configured for Resource-Based Kerberos Delegation, is ONLY allowing access by specific services (e.g. only “FE”).

Imagine a bank vault (the “D”) and many other bank vaults and a bank clerk (the “FE”). A specific bank vault (“D”) is configured by its owner to only allow access by the bank clerk (the “FE”) on behalf of clients. Sounds even better!

Read more about it:

With both “Unconstrained Kerberos Delegation” and “Constrained Kerberos Delegation”, delegation is configured at delegated account level (hence: “Account-Based (Un)Constrained Kerberos Delegation”), and not at resource level, which is weird! Looking at ACLs in all kinds of services (file, sql, AD, etc.), permissions are configured at resource level, as it should be! This changes in “Resource-Based Constrained Delegation”, which is my preferred way of delegation!

Additional Reading:

Enjoy and have fun!,

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), Delegation, Kerberos AuthN | Leave a Comment »

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

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

 
%d bloggers like this: