(2019-11-12) Active Directory Security Scan Of Accounts (Part 2)

With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “Kerberos Delegation” related account information.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

• Domain FQDN (e.g. ‘IAMTEC.NET’)
• Domain NBT (e.g. ‘IAMTEC’)
• Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
• Sam Account Name (e.g. ‘jorge’)
• Account Name (e.g. ‘IAMTEC\jorge’)
• Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
• Service Principal Name(s) (e.g. <comma separated list of SPNs> or "No SPNs")
• Acc Based Deleg Type (e.g. "No-Acc-Deleg" or "Acc-Unc-Deleg" or "Acc-Con-Deleg-AnyAuthN" or "Acc-Con-Deleg-KerbAuthN"
• Acc Based Deleg To (e.g. <comma separated list of SPNs> or "No Delegated SPNs")
• Res Based Deleg For (e.g. <comma separated list of user account names with type and domain listed> or "No-Res-Deleg"

–

When the script finishes, it produces a CSV report that contains every account in the AD forest that can authenticate (user, computer, gMSA, inetOrgPerson) and potentially be a threat, and it displays that CSV in a GridView automatically. The CSV can of course also be used in Excel if needed. With this information you may be able to remove or fix configurations and/or get an idea how things look like to mitigate risks as much as possible!

While the script is running it logs every to a log file. which is in the same folder as the script itself.

–

This script requires:

• PowerShell Module: ActiveDirectory
• Basic User Permissions, Nothing Special!

–

Scan/Check All Accounts In The AD Forest And Create The Report

.\Scan-And-Check-All-Accounts-In-AD-Forest_02_Delegation-Info.ps1

–

The script has been tested in three different AD forests:

• AD forest with a Single AD domain with less than 500 accounts and quite some account config
• AD forest with a Single AD domain with approx. 150000 accounts and less account config
• AD forest with Multiple AD domains (Forest Root Domain, Child Domain and Tree Root Domain) with approx. respectively 4000, 25000 and 12000 accounts and less account config

–

Figure 1a: Sample Output Of The Log File

–

Figure 1b: Sample Output Of The Log File

–

Figure 1c: Sample Output Of The Log File

–

Figure 1d: Sample Output Of The Log File

–

To open the CSV on another computer and display it in GridView, execute the following command:

Import-CSV <Full Path To The CSV File> | Out-Gridview

Figure 2: Sample Output Of The CSV File Displayed In PowerShell GridView

–

To get the script, see: Scan And Check All Accounts In AD Forest – Delegation Info

–

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

(2019-11-08) Active Directory Security Scan Of Accounts

This month will have a serious security focus in scanning your AD to determine all kinds of account configurations, see relations between those configurations and mitigate any security risks due to combined configurations. A simple example can be an account with unconstrained delegation configured while it has a weak/compromised password, etc, etc.

To scan the accounts within an Active Directory forest, I will be releasing 5 PowerShell scripts.

–

[Script 1] .\Scan-And-Check-All-Accounts-In-AD-Forest_01_Basic-Info.ps1

Features:

With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “basic” account information that is related to security.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

• Domain FQDN (e.g. ‘IAMTEC.NET’)
• Domain NBT (e.g. ‘IAMTEC’)
• Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
• Sam Account Name (e.g. ‘jorge’)
• Account Name (e.g. ‘IAMTEC\jorge’)
• Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
• User Principal Name  (e.g. ‘jorge@iamtec.nl’)
• Display Name (e.g. Jorge de Almeida Pinto)
• Enabled (e.g. TRUE or FALSE)
• Locked (e.g. TRUE – At:<date/time> or FALSE – Never Locked or FALSE – Has Been Locked Before)
• Account Expires On (e.g. <date/time> or NEVER)
• Pwd Last Set On (e.g. <date/time> or "Must Chng At Next Logon")
• Pwd Never Expires (e.g. TRUE or FALSE)
• Last Logon Timestamp (e.g. <date/time> or NEVER)
• Last Logon (RWDC) (e.g. <date/time> or NEVER Or NOT AVAILABLE (On ‘<FQDN RWDC>’))

–

[Script 2] .\Scan-And-Check-All-Accounts-In-AD-Forest_02_Delegation-Info.ps1

Features:

With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “Kerberos Delegation” related account information.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

• Domain FQDN (e.g. ‘IAMTEC.NET’)
• Domain NBT (e.g. ‘IAMTEC’)
• Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
• Sam Account Name (e.g. ‘jorge’)
• Account Name (e.g. ‘IAMTEC\jorge’)
• Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
• Service Principal Name(s) (e.g. <comma separated list of SPNs> or "No SPNs")
• Acc Based Deleg Type (e.g. "No-Acc-Deleg" or "Acc-Unc-Deleg" or "Acc-Con-Deleg-AnyAuthN" or "Acc-Con-Deleg-KerbAuthN"
• Acc Based Deleg To (e.g. <comma separated list of SPNs> or "No Delegated SPNs")
• Res Based Deleg For (e.g. <comma separated list of user account names with type and domain listed> or "No-Res-Deleg"

–

[Script 3] .\Scan-And-Check-All-Accounts-In-AD-Forest_03_NC-Level-Permissions-Info.ps1

Features:

With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “Permissions At NC Level” related account information.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

• Domain FQDN (e.g. ‘IAMTEC.NET’)
• Domain NBT (e.g. ‘IAMTEC’)
• Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
• Sam Account Name (e.g. ‘jorge’)
• Account Name (e.g. ‘IAMTEC\jorge’)
• Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
• DS Repl Chng Perms (e.g. "<comma separated list of domain DNs> (<Assigned Security Principal>)" or "No Perms")
• DS Repl Chng All Perms (e.g. "<comma separated list of domain DNs> (<Assigned Security Principal>)" or "No Perms")
• Migr SID History Perms (e.g. "<comma separated list of domain DNs> (<Assigned Security Principal>)" or "No Perms")

–

[Script 4] .\Scan-And-Check-All-Accounts-In-AD-Forest_04_Object-Level-Permissions-Info.ps1

Features:

With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “Permissions At Object Level” related account information.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

• Domain FQDN (e.g. ‘IAMTEC.NET’)
• Domain NBT (e.g. ‘IAMTEC’)
• Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
• Sam Account Name (e.g. ‘jorge’)
• Account Name (e.g. ‘IAMTEC\jorge’)
• Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
• Protected Group Membership (e.g. <comma separated list of group account names> or "No Memberships")
  REMARK: With protected groups, the focus is ONLY on default AD Protected Groups (e.g. BUILTIN\Administrators", "<DOMAIN>\Domain Admins", etc.)
  REMARK: if protected groups are listed then any ACEs for those protected groups are NOT listed to prevent an overload of ACEs
• ACE On AdminSDHolder (e.g. <comma separated list of objects with configured permissions> or "No ACEs")
  REMARK: If protected groups are listed then any ACEs for those protected groups are NOT listed to prevent an overload of ACEs
  REMARK: It will only look at explicit defined ACEs. Inherited ACEs are NOT listed to prevent an overload of ACEs
• Powerful ACEs On Objects (e.g. <comma separated list of objects with configured permissions> or "No ACEs")
  REMARK: If protected groups are listed then any ACEs for those protected groups are NOT listed to prevent an overload of ACEs
  REMARK: It will only look at explicit defined ACEs. Inherited ACEs are NOT listed to prevent an overload of ACEs

–

[Script 5] \Scan-And-Check-All-Accounts-In-AD-Forest_05_Account-And-Password-Hygiene-Info.ps1

Features:

With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “Account And Password Hygiene” related information.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

• Domain FQDN (e.g. ‘IAMTEC.NET’)
• Domain NBT (e.g. ‘IAMTEC’)
• Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
• Sam Account Name (e.g. ‘jorge’)
• Account Name (e.g. ‘IAMTEC\jorge’)
• Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
• Enabled (e.g. TRUE or FALSE)
• Pwd Last Set On (e.g. <date/time> or "Must Chng At Next Logon")
• Has Adm Count Stamp (e.g. TRUE or FALSE)
• Delegatable Adm (e.g. TRUE or FALSE)
• Does Not Req Pre-AuthN (e.g. TRUE or FALSE)
• Has Sid History (e.g. TRUE or FALSE)
• Has LM Hash (e.g. TRUE or FALSE)
• Has Default Pwd (e.g. TRUE or FALSE)
• Has Blank Pwd (e.g. TRUE or FALSE)
• Uses DES Keys Only (e.g. TRUE or FALSE)
• Has Missing AES Keys (e.g. TRUE or FALSE)
• Pwd Rev Encrypt (e.g. TRUE or FALSE)
• Pwd Not Req (e.g. TRUE or FALSE)
• Pwd Never Expires (e.g. TRUE or FALSE)
• Has Shared Pwd (e.g. TRUE – Domain Shrd Pwd Grp x Of y or FALSE)
• Compromised Pwd (e.g. TRUE or FALSE)
• Most Used Hash (e.g. <hash> (<count>) or N.A.)

–

Interested in this? Stay tuned!

Thanks!

–

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

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

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:

• Get rid of accounts that use Kerberos Unconstrained Delegation
• Active Directory Security Risk #101: Kerberos Unconstrained Delegation (or How Compromise of a Single Server Can Compromise the Domain)
• “Relaying” Kerberos – Having fun with unconstrained delegation
• Hunting in Active Directory: Unconstrained Delegation & Forests Trusts
• Another Word on Delegation

–

[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:

• Kerberos Constrained Delegation Overview

–

[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:

• What’s New in Kerberos Authentication
• How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 1
• How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 2
• Resource Based Kerberos Constrained Delegation

–

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:

• (2013-10-21) Delegating The Configuration Of "Trusted For Delegation" In AD
• (2014-03-25) An Account With "Trusted For Delegation" – What Are The Risks?
• (2014-03-26) Determining Computers Configured With "Trusted For Delegation"
• (2014-03-27) Determining Users Configured With "Trusted For Delegation"
• (2015-11-08) Kerberos Constrained Delegation (KCD) Visualized The Easy Way  <= displays the supported scenarios for all three flavors

–

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

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

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

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

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

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!

–

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