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

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

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:

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]

Figure 2: KCD Old Style – Single Domain Forest

–

[Scenario 2]

Figure 3: KCD Old Style – Multiple Single Domain Forests

–

[Scenario 3]

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]

Figure 5: KCD New Style – Single Domain Forest

–

[Scenario 2]

Figure 6: KCD New Style – Multiple Domain Forest

–

[Scenario 3]

Figure 7: KCD New Style – Multiple Single Domain Forests

–

[Scenario 4]

Figure 8: KCD New Style – Multiple Single Domain Forests

–

[Scenario 5]

Figure 9: KCD New Style – Multiple Single Domain Forests

–

[Scenario 6]

Figure 10: KCD New Style – Multiple Single Domain Forests

–

[Scenario 7]

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

–

[Scenario 8]

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:

• Resource Based Kerberos Constrained Delegation
• 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
• Setting up Kerberos Authentication for a Website in IIS
• Understanding Kerberos Double Hop
• About Kerberos constrained delegation
• Fun with the Kerberos Delegation Web Site
• DelegConfig – A Tool To help resolve Kerberos authentication and delegation issues
• [MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol
• Kerberos Protocol Transition and Constrained Delegation
• Kerberos
• Kerberos Survival Guide

–

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