Jorge's Quest For Knowledge!

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

Archive for the ‘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 »

(2011-09-14) Kerberos Authentication Over An External Trust – Is It Possible? (Part 6)

Posted by Jorge on 2011-09-14


In PART 1 I explained the setup I will use.

In PART 2 I showed the usage of Kerberos authN accessing the websites on the local web server.

In PART 3 I showed the usage of Kerberos authN accessing the websites from another computer in the same AD forest/domain.

In PART 4 I showed the usage of Kerberos authN when logged on to a computer in another AD forest/domain, while a FOREST TRUST is in place

In PART 5 I showed the usage of Kerberos authN when logged on to a computer in another AD forest/domain, while a EXTERNAL TRUST is in place

In this, really, last post about this I will, besides showing the usage of Kerberos authN while a EXTERNAL TRUST is in place, also explain how to achieve this functionality.

All of you that read the first 5 blog posts about this topic AND tried to achieve this, may have failed to achieve the result that I was able to achieve. The main reason for is that I never mentioned the missing link in this. If you dug deep into it you end with the question “How does the TRUSTED domain find the TRUSTING domain that owns the service principal name?”

To make sure it is explained correctly so that you understand it correctly, let’s go through all of it again. With this information you will be able to try it your self!

Let’s start again with a FOREST TRUST and its configuration…

image

Figure 1: One-Way Forest Trust –> TRUSTED FOREST = ADCORP.LAB (Incoming) | TRUSTING FOREST = ADDMZ.LAN (Outgoing)

image

Figure 2: Name Suffix Routing Configuration On The Forest Trust For The TRUSTING FOREST

image

Figure 3: The Forest Trust Configuration On The TRUSTED Side From An Attribute Perspective

image

Figure 4: The Human Readable Information Stored In The “msDS-TrustForestTrustInfo” Attribute Of The Trusted Domain Object (TDO)

So, if you take the configuration that I posted in PART 1 into account, the following will happen when a user from the “ADCORP.LAB” AD forest logged on to a computer also from the “ADCORP.LAB” AD forest is accessing the websites “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82” (high-level steps):

  1. User account in “ADCORP.LAB” AD domain logs on to computer in “ADCORP.LAB” AD domain.
  2. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a TGT for the “ADCORP.LAB” AD domain.
  3. To access either website “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82”, the user account requests a TGS for either service.
  4. The DC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD domain but cannot find a user account or a computer in the local AD domain that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
  5. The GC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD forest but cannot find a user account or a computer in the local AD forest that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
  6. The DC/GC in the “ADCORP.LAB” AD domain/forest servicing the user account checks for any local or GC located Trusted Domain Object (TDO) (in the “msDS-TrustForestTrustInfo” Attribute) and checks if it can find any SPN suffix that matches the SPN suffix of the required service/SPN to be able to refer the user to (figure 4). (Success!)
  7. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a referral ticket to the user account for the AD domain “ADDMZ.LAN” (single AD domain in the AD forest, otherwise additional similar steps included!)
  8. The DC in the “ADDMZ.LAN” AD domain servicing the user account issues a TGT for the “ADDMZ.LAN” AD domain.
  9. The DC in the “ADDMZ.LAN” AD domain servicing the user account issues a TGS for either website that has either SPN HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN” configured in its service or application pool account
  10. The user account presents the TGS to the website
  11. Based upon the contents of the TGS the website allows access

REMARK: Detailed information about Kerberos authN can be found HERE.

REMARK: The information in the “msDS-TrustForestTrustInfo” attribute is build from the information within the trusting AD forest, such the “UPN-Suffixes” attribute and the “ms-DS-SPN-Suffixes” attribute on the Partitions container. Also see “Building Well-Formed msDS-TrustForestTrustInfo Messages” and “Routing name suffixes across forests

So far so good!

Let’s continue again with an EXTERNAL TRUST and its configuration…

image

Figure 5: One-Way External Trust –> TRUSTED DOMAIN = ADCORP.LAB (Incoming) | TRUSTING DOMAIN = ADDMZ.LAN (Outgoing)

image

Figure 6: Name Suffix Routing Configuration On The External Trust For The TRUSTING FOREST. WAIT! There is None!!!

image

Figure 7: The External Trust Configuration On The TRUSTED Side From An Attribute Perspective

image

Figure 8: The Human Readable Information Stored In The “msDS-TrustForestTrustInfo” Attribute Of The Trusted Domain Object (TDO). WAIT! There is None!!!

So, if you take the configuration that I posted in PART 1 into account, the following will happen when a user from the “ADCORP.LAB” AD forest logged on to a computer also from the “ADCORP.LAB” AD forest is accessing the websites “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82” (high-level steps):

  1. User account in “ADCORP.LAB” AD domain logs on to computer in “ADCORP.LAB” AD domain.
  2. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a TGT for the “ADCORP.LAB” AD domain.
  3. To access either website “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82”, the user account requests a TGS for either service.
  4. The DC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD domain but cannot find a user account or a computer in the local AD domain that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
  5. The GC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD forest but cannot find a user account or a computer in the local AD forest that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
  6. The DC/GC in the “ADCORP.LAB” AD domain/forest servicing the user account checks for any local or GC located Trusted Domain Object (TDO) (in the “msDS-TrustForestTrustInfo” Attribute) and checks if it can find any SPN suffix that matches the SPN suffix of the required service/SPN to be able to refer the user to (figure 4).(Failure!)
  7. THEREFORE, the DC in the “ADCORP.LAB” AD domain servicing the user account CANNOT issue a referral ticket to the user account for the AD domain “ADDMZ.LAN”
  8. THEREFORE, The DC in the “ADDMZ.LAN” AD domain servicing the user account CANNOT issue a TGT for the “ADDMZ.LAN” AD domain.
  9. THEREFORE, The DC in the “ADDMZ.LAN” AD domain servicing the user account CANNOT issue a TGS for either website that has either SPN HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN” configured in its service or application pool account
  10. THEREFORE, the user account CANNOT present the TGS to the website
  11. THEREFORE, the user account cannot leverage Kerberos AuthN!
  12. Because either website is configure with NEGOTIATE, the system will switch to NTLM authN.

REMARK: Detailed information about NTLM can be found HERE.

After you have enabled Verbose Kerberos Logging as explained in MS-KBQ262177 you will see the following in the System Event Log (DO NOT FORGET TO DISABLE IT AGAIN!)

image

Figure 9: Kerberos Error Message About Not Being Able To Find The SPN In The Local AD domain/forest

A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 22:7:3.0000 9/13/2011 Z
Error Code: 0x7  KDC_ERR_S_PRINCIPAL_UNKNOWN
Extended Error:
Client Realm:
Client Name:
Server Realm: ADCORP.LAB
Server Name: HTTP/delegconfig.addmz.lan
Target Name: HTTP/delegconfig.addmz.lan@ADCORP.LAB

Error Text:
File: 9
Line: f09
Error Data is in record data.

So, the main reason for External Trusts NOT supporting Kerberos AuthN is because there is no routing information available to create the referral! The DCs do not have enough information for the next hop. That’s really it! If there would be a mechanism that is able to provide such required information, you would Kerberos over the external trust. What can you do about this, is the question that needs to be answered!

When you open the GPMC you will see the following settings (amongst others!)

image

Figure 10: GPO Settings To Configure The KDC Service On A DC

Pay close attention to the GPO Setting called “Use forest search order”. The description is:

This policy setting defines the list of trusting forests that the Key Distribution Center (KDC) searches when attempting to resolve two-part service principal names (SPNs).

If you enable this policy setting, the KDC will search the forests in this list if it is unable to resolve a two-part SPN in the local forest. The forest search is performed by using a global catalog or name suffix hints. If a match is found, the KDC will return a referral ticket to the client for the appropriate domain.

If you disable or do not configure this policy setting, the KDC will not search the listed forests to resolve the SPN. If the KDC is unable to resolve the SPN because the name is not found, NTLM authentication might be used.

To ensure consistent behavior, this policy setting must be supported and set identically on all domain controllers in the domain.

image

Figure 11: GPO Settings To Configure The Kerberos AuthN Protocol On Windows Computers In Common

Pay close attention to the GPO Setting called “Use forest search order”. The description is:

This policy setting defines the list of trusting forests that the Kerberos client searches when attempting to resolve two-part service principal names (SPNs).

If you enable this policy setting, the Kerberos client will search the forests in this list if it is unable to resolve a two-part SPN. If a match is found, the Kerberos client will request a referral ticket to the appropriate domain.

If you disable or do not configure this policy setting, the Kerberos client will not search the listed forests to resolve the SPN. If the Kerberos client is unable to resolve the SPN because the name is not found, NTLM authentication might be used.

The GPO Setting “Use forest search order” is therefore the mechanism that is able to provide the missing information for this to work! If you look carefully in figure 12, this will only work for W2K8R2 AD forest!

I will therefore use the option shown in figure 10 and configure it as shown below:

image

Figure 12: Configuring The GPO Setting “Use Forest Search Order” That Will Be Applied On ALL DCs (GPO Setting In Figure 10) And Applied On All Windows Computers (GPO Setting In Figure 11) In The AD Domain/Forest

REMARK: It should be enough to configure either the KDC on all W2K8R2 DCs or all Win7/W2K8R2 computers in the AD domain

Make sure to wait until end-to-end AD/SYSVOL Replication is complete and every DC has (re-)applied the GPO with the new GPO Setting. In this case I executed GPUPDATE /FORCE on the one and only RWDC I have in my TRUSTED AD FOREST.

So, if you NOW take the configuration that I posted in PART 1 into account AND the configuration shown in figure 10 and 12, the following will happen when a user from the “ADCORP.LAB” AD forest logged on to a computer also from the “ADCORP.LAB” AD forest is accessing the websites “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82” (high-level steps):

  1. User account in “ADCORP.LAB” AD domain logs on to computer in “ADCORP.LAB” AD domain.
  2. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a TGT for the “ADCORP.LAB” AD domain.
  3. To access either website “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82”, the user account requests a TGS for either service.
  4. The DC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD domain but cannot find a user account or a computer in the local AD domain that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
  5. The GC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD forest but cannot find a user account or a computer in the local AD forest that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
  6. The DC/GC in the “ADCORP.LAB” AD domain/forest servicing the user account checks for any local or GC located Trusted Domain Object (TDO) (in the “msDS-TrustForestTrustInfo” Attribute) and checks if it can find any SPN suffix that matches the SPN suffix of the required service/SPN to be able to refer the user to (figure 4). (Failure!)
  7. The DC/GC in the “ADCORP.LAB” AD domain/forest servicing the user account checks for any additional routing hints as configured by the GPO Setting “Use forest search order” and checks if it can find any SPN suffix that matches the SPN suffix of the required service/SPN to be able to refer the user to (figure 4). (Success!)
  8. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a referral ticket to the user account for the AD domain “ADDMZ.LAN” (single AD domain in the AD forest, otherwise additional similar steps included!)
  9. The DC in the “ADDMZ.LAN” AD domain servicing the user account issues a TGT for the “ADDMZ.LAN” AD domain.
  10. The DC in the “ADDMZ.LAN” AD domain servicing the user account issues a TGS for either website that has either SPN HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN” configured in its service or application pool account
  11. The user account presents the TGS to the website
  12. Based upon the contents of the TGS the website allows access

BINGO!!!!! We have a winner! Kerberos AuthN over an external trust is working!

To prove I’m not bullshitting you, check out the following screen dumps. Pay attention to the time shown in the screen dump.

image

Figure 13: Kerberos Tickets Cached By The Client BEFORE Accessing The Websites Over An External Trust

image

Figure 14: Kerberos AuthN Is Used When Accessing The Website “HTTP://DELEGCONFIG.ADDMZ.LAN:81” While An External Trust Is In Place

image

Figure 15: Kerberos AuthN Is Used When Accessing The Website “HTTP://R2FSMBSVA.ADDMZ.LAN:82” While An External Trust Is In Place

image

Figure 16: Kerberos Tickets Cached By The Client AFTER Accessing The Websites Over An External Trust

image

Figure 17: An Kerberos Error Is Still Logged In The System Event Log Because The Search For The SPN (HTTP/DELEGCONFIG.ADDMZ.LAN) In The LOCAL AD Forest Fails

A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 8:11:14.0000 9/14/2011 Z
Error Code: 0x7  KDC_ERR_S_PRINCIPAL_UNKNOWN
Extended Error:
Client Realm:
Client Name:
Server Realm: ADCORP.LAB
Server Name: HTTP/delegconfig.addmz.lan
Target Name: HTTP/delegconfig.addmz.lan@ADCORP.LAB
Error Text:
File: 9
Line: f09
Error Data is in record data.

image

Figure 18: An Kerberos Error Is Still Logged In The System Event Log Because The Search For The SPN (HTTP/R2FSMBSVA.ADDMZ.LAN) In The LOCAL AD Forest Fails

A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 8:12:5.0000 9/14/2011 Z
Error Code: 0x7  KDC_ERR_S_PRINCIPAL_UNKNOWN
Extended Error:
Client Realm:
Client Name:
Server Realm: ADCORP.LAB
Server Name: HTTP/r2fsmbsva.addmz.lan
Target Name: HTTP/r2fsmbsva.addmz.lan@ADCORP.LAB
Error Text:
File: 9
Line: f09
Error Data is in record data.

The following question remains: “How about custom suffixes (e.g. EXTERNAL.LAN) not hosted by the AD forest “ADDMZ.LAN” by default???”. Remember that the mechanism is different. With a forest trust the information in the Trusted Domain Object (attribute “msDS-TrustForestTrustInfo”) is used that is available in the local AD forest through the GC. With an external trust that information does not exist. The KDC in the trusted AD forest or the kerberos client in the trusted AD forest searches the trusting AD forests listed in the order specified in the GPO Setting after not being able to find it in the local AD forest.

Although Microsoft has the following requirement:

  • The server name in the trusting resource domain has to be the FQDN, and the domain suffix of the server name has to match the AD DS domain’s DNS FQDN

I have already shown it work if you do not use the FQDN of the server (R2FSMBSVA) but rather an alias (DELEGCONFIG.ADDMZ.LAN) which also has the same suffix as the AD forest/domain. How about an alias that has a different suffix? That also appears to work also! I created an additional website “HTTPS://DELEGCONFIG.EXTERNAL.LAN:83” on the same server. Let’s see what happens with that!

image

Figure 19: Kerberos Tickets Cached By The Client BEFORE Accessing The Website Over An External Trust

image

Figure 20 Kerberos AuthN Is Used When Accessing The Website “HTTP://DELEGCONFIG.EXTERNAL.LAN:83” While An External Trust Is In Place

image

Figure 21: Kerberos Tickets Cached By The Client AFTER Accessing The Website Over An External Trust

Now before you go all crazy….

  • This only works when the TRUSTED/TRUSTING forest contains at least W2K8R2 DCs OR Win7/W2K8R2 computers (either one needs to be able to perform the search)
  • You may have an external trust while you require Kerberos AuthN and creating a forest trust is not an option. Example: Interactive user logon over external trust fails or encounters delays
  • I did not test every possible scenario! Therefore use this information for your own fun and make sure to test your own scenario! It may not apply to every possible scenario.
  • If you want/need to leverage Kerberos AuthN over an external trust, check first with Microsoft if that’s supported or not. Remember that currently Kerberos AuthN is only supported over a forest trust

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), Blog Post Series, Kerberos AuthN, Trusts | 12 Comments »

 
%d bloggers like this: