(2022-07-04) Presenting At The Troopers 2022 Conference

Last week I delivered a session about AD Disaster Recovery after a ransomware attack at the Troopers 2022 conference in Heidelberg Germany. The session was a blast!

I was really happy to see the room was packed with people, meaning there was much interest in listening what I had to say. The interaction with the attendees was great, people were taking notes, taking pictures and asking questions during and afterwards. Everything a presenter can wish for. Wow!

If you are interested in having a peek at the slides I used, you can find those through the following link:

Resurrecting After A Ransomware Attack – Be Secure, And Prepared!

Some time later the recording of the session is available on the Troopers Youtube channel

Have questions? Want a demo of the Semperis Disaster Recovery solution? Just let me know!

#DisasterRecovery #Semperis #Troopers

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/
————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

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

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

(2020-10-14) 6 Steps To Mitigate The ZeroLogon Vulnerability

About a month or so I blogged about the ZeroLogon vulnerability. Check it out HERE

Now why is this all important? I think I can say this is one of meanest vulnerabilities that I have seen for which you can loose control of your AD. Mitigation is quite easy through a number of steps, being:

1. Install at least the august patch on at least ALL your DCs if you have not done that already. You did not do this yet? Seriously? Living under a stone? Remember: ANYONE on your network that can communicate with your DC has the ability to own and control your AD domain/forest!
2. Monitor the System Event Log of ALL your DCs for event ID 5829, which is whenever a vulnerable Netlogon secure channel connection is used and allowed. TIP: to ease this, use Azure Log Analytics which helps you get all the information in one place! Then in Azure Log Analytics, you can use the KQL query displayed below, which will give you all the servers and the number of times it established a vulnerable Netlogon secure channel connection
3. If ANY SYSTEM still uses vulnerable netlogon connections, EITHER…
1. Patch/fix software/firmware if available (preferred!)
2. If a fix is not available immediately because the vendor is working on it, create a security group in AD, then use that security group and make all the systems, for which a fix is not yet available, a member of the security group. Then in the policy “Computer Configuration > Windows Settings > Security Settings > Security Options > Domain controller: Allow vulnerable Netlogon secure channel connections” specify that security group as the exception list
4. When ALL SYSTEMS previously using vulnerable netlogon connections, are either fixed/updated or configured as exception, enable enforcement mode as explained here
5. Monitor the System Event Log of ALL your DCs for event ID 5827, 5828, 5830, 5831 and take action as needed. Again, Azure Log Analytics which helps you get all the information in one place! You can use the KQL query displayed below
1. Event ID 5827: logged when a vulnerable Netlogon secure channel connection from a machine account is denied
2. Event ID 5828: logged when a vulnerable Netlogon secure channel connection from a trust account is denied
3. Event ID 5830: logged when a vulnerable Netlogon secure channel connection from a machine account is allowed due to the exception
4. Event ID 5831: logged when a vulnerable Netlogon secure channel connection from a trust account is allowed due to the exception
6. For all those systems in the exception group, chase the owners/vendors to fix/update the software before date XYZ (t.b.d. by yourself!) and tell them after that date you will remove the accounts as members and they will have issues

–

KQL Query for when a vulnerable Netlogon secure channel connection from a machine account is allowed (Event ID 5829)

Event
| where EventID == 5829
| project ParameterXml, TimeGenerated, EventID
| parse ParameterXml with * ‘<Param>’ Computer ‘</’ *
| summarize Count = count(EventID) by Client=Computer

–

KQL Query for when a vulnerable Netlogon secure channel connection from a machine account is denied (Event ID 5827)

Event
| where EventID == 5827
| project ParameterXml, TimeGenerated, EventID
| parse ParameterXml with * ‘<Param>’ Computer ‘</’ *
| summarize Count = count(EventID) by Client=Computer

–

KQL Query for when a vulnerable Netlogon secure channel connection from a trust account is denied (Event ID 5828)

Event
| where EventID == 5828
| project ParameterXml, TimeGenerated, EventID
| parse ParameterXml with * ‘<Param>’ Computer ‘</’ *
| summarize Count = count(EventID) by Client=Computer

–

KQL Query for when a vulnerable Netlogon secure channel connection from a machine account is allowed due to the exception (Event ID 5830)

Event
| where EventID == 5830
| project ParameterXml, TimeGenerated, EventID
| parse ParameterXml with * ‘<Param>’ Computer ‘</’ *
| summarize Count = count(EventID) by Client=Computer

–

KQL Query for logged when a vulnerable Netlogon secure channel connection from a trust account is allowed due to the exception (Event ID 5831)

Event
| where EventID == 5831
| project ParameterXml, TimeGenerated, EventID
| parse ParameterXml with * ‘<Param>’ Computer ‘</’ *
| summarize Count = count(EventID) by Client=Computer

–

Now. what’s the benefit of using this approach? There are more benefits!

1. Any update that is installed, which is released after February 9th 2021, will enable enforcement mode automatically. Any system NOT in the exception list will have issues!
2. The list of systems using vulnerable Netlogon secure channel connections, will not grow. The longer you wait the bigger the list might get. As YOU control the security group you can tell any owner requiring netlogon connections, to FIRST fix/update their software, which will allow the netlogon connection. Membership of the security group should decrease, NOT increase!

–

More details: How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472

–

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-21) Active Directory Security Scan Of Accounts (Part 5)

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.)

–

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
• PowerShell Module: LithnetPasswordProtection
• PowerShell Module: DSInternals
• LithNet Active Directory Password Protection Store With Banned Words And/Or Compromised Passwords/Hashes
• Enterprise Admin Permissions, or at least "Replicate Directory Changes" and "Replicate Directory Changes All" for EVERY NC in the AD forest!
  REMARK: Script does check for Enterprise Admin role permissions!

–

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

.\Scan-And-Check-All-Accounts-In-AD-Forest_05_Account-And-Password-Hygiene-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

–

Figure 1e: 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 2a: Sample Output Of The CSV File Displayed In PowerShell GridView

–

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

–

To get the script, see: Scan And Check All Accounts In AD Forest – Account And Password Hygiene

–

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-18) Active Directory Security Scan Of Accounts (Part 4)

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

–

The following ACEs are considered powerful:

• Full Control
• Password Reset Control Access Rights
• Control Access Right In General
• WriteOwner (Allows to write the owner and that allows to write the DACL)
• Write DACL
• Write Property In General
• Write Property For “lockoutTime” (Unlocking Account)
• Write Property For “msDS-AllowedToDelegateTo” (Adding/removing accounts for account based delegation)
• Write Property For “msDS-AllowedToActOnBehalfOfOtherIdentity” (Adding/removing accounts for resourced based delegation)
• Write Property For “servicePrincipalName” (Adding/removing SPNs)
• Write Property For “userAccountControl” (Managing security/delegation settings, enabling/disabling account)

–

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_04_Object-Level-Permissions-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 – Object Level Permissions 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-15) Active Directory Security Scan Of Accounts (Part 3)

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")

–

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_03_NC-Level-Permissions-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 – NC Level Permissions 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-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-09) Active Directory Security Scan Of Accounts (Part 1)

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>’)) <– THIS MEANS IT WILL QUERY EVERY DC (RWDC And RODC) In The AD Domain To Get The LastLogon Property From That DC! (Will be slow!)

–

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_01_Basic-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 – Basic 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-11-06) Azure AD Password Protection (A.k.a. Banned Password List) – Third Party Solution LithNet AD Password Protection (Part 9)

In addition to Azure AD Password Protection, of course there are also other third-party solutions. Azure AD Password Protection performs one heck of a job.

Nevertheless, I do believe it would be an even better solution if:

• it would allow customization of the algorithm
• would allow to remove the limit of 1000 words
• would be easy to determine what is already on the global MSFT list (also see: (2019-10-28) Azure AD Password Protection (A.k.a. Banned Password List) – Optimizing The Custom Per Tenant List (Part 6)
• would allow integration with external solutions like “Have I Been Pwned”
• would allow easy testing of passwords against it to see if accepted, rejected or even compromised

–

One solution that caught my attention is: LithNet Active Directory Password Protection.

At a high level, its features are:

• Does NOT have the limits specified above (except bullet 3)
• Can work alongside the MSFT Password Solution if needed
• Can run in LSA protected mode (co-signed by Microsoft) (https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)
• Ability to take control of what a good password means to you
• Fully or partially adopt 2018 NIST password recommendations (https://pages.nist.gov/800-63-3/sp800-63b.html)
• An eight character minimum and 64 character maximum length
• The ability to use all special characters but no special requirement to use them
• Restrict sequential and repetitive characters (e.g. 12345 or aaaaaa)
• Restrict context specific passwords (e.g. such as the name of the service, the username, and derivatives thereof, etc.)
• Restrict commonly used passwords (e.g. p@ssw0rd, etc.)
• Restrict passwords obtained from previous breach corpuses
• Ability to be used against domain accounts and local accounts on workstations and servers
• Rich set of group policy-based controls that allow to enable any combination of the following checks on attempted password changes (BE CAREFULL WHEN USING MULTIPLE POLICIES AS ONE MIGHT IMPACT THE OTHER!):
  • General settings
    • Disable password filter
  • Regular expression policies
    • Passwords must match regular expression
      AND/OR
    • Passwords must NOT match regular expression
  • Complexity policies
    • Points-based complexity policy definition. Assign points for the use of certain characters and categories and set a minimum point threshold a password must meet.
      Minimum # points required to allow/approve password
      • # Points for each character used
      • # Points for each number used
      • # Points for each lower case letter used
      • # Points for each upper case letter used
      • # Points for each symbol used
      • # Points for at least 1 number used
      • # Points for at least 1 lower case letter used
      • # Points for at least 1 upper case letter used
      • # Points for at least 1 symbol used
    • Length based complexity policy definition. For example, you can require number, symbol, upper and lower for passwords less than 13 characters, but have no special requirements for passwords 13 characters or longer. Reward length, with less complexity.
      REMARK: It is recommended to disable the built-in Active Directory password complexity requirements policy when this policy is enabled.
      REMARK: What happens when the password equals X or Y?)
      • Threshold Level 1 – less than X
        • Total number of character sets required (number, symbol, lower case letter, upper case letter)
        • Exact characters sets required at a minimum:
          • Lower case letter
          • Upper case letter
          • Symbol
          • Number
          • Number or symbol
      • Threshold Level 2 – equal to or longer than X and less than Y
        • Total number of character sets required (number, symbol, lower case letter, upper case letter)
        • Exact characters sets required at a minimum:
          • Lower case letter
          • Upper case letter
          • Symbol
          • Number
          • Number or symbol
      • Threshold Level 3 – equal to or longer than Y
        • Total number of character sets required (number, symbol, lower case letter, upper case letter)
        • Exact characters sets required at a minimum:
          • Lower case letter
          • Upper case letter
          • Symbol
          • Number
          • Number or symbol
    • Minimum password length
      REMARK: It is recommended to disable the built-in Active Directory password complexity requirements policy when this policy is enabled.
  • Password Content Policies
    • Reject passwords that contain the user’s account name (username length must be greater than 3)
    • Reject passwords that contain all or any part of the user’s display name
    • Reject passwords found in the compromised password store (Checks the exact password specified by the user against the list of compromised passwords)
      • Requires the import of the "Have I Been Pwned" (HIBP) password list!
      • Allows for differentiation between CHANGE and RESET
    • Reject normalized passwords found in the compromised password store (normalization rules) (Checks the normalized password specified by the user against the list of compromised passwords)
      • Requires the import of the "Have I Been Pwned" (HIBP) password list!
        AND/OR
      • Requires the addition of your own forbidden passwords!
      • Allows for differentiation between CHANGE and RESET
    • Reject normalized passwords found in the banned word store (Adding a banned word prevents it from being used as the base of a password. For example, adding the word ‘password’ to the banned word store, prevents not only the use of that word itself, but common variants such as ‘P@ssw0rd’, ‘pa55word!’ and ‘password123456!’. LPP is aware of common character substitutions and weak obfuscations and prevents their use through a normalization process.)
      • Requires the import of banned words!
      • Allows for differentiation between CHANGE and RESET
• Full PowerShell support which is used to;
  • Manage the compromised password and banned word stores. Add your own banned words and compromised passwords, as well as use popular databases such as the haveibeenpwned.com downloadable password list (‘NTLM ordered by hash’ list)
  • Test passwords and existing hashes against the compromised store
  • Check to see if your user’s current passwords in AD are found in the compromised password store (based upon DS Internals!)
• Passwords never leave the domain controller
• Designed for large environments where high performance is required
• Creates detailed event logs (Event Log: "Application", Source: "LithnetPasswordProtection")
• Uses a DFS-R friendly data store
• No internet access required
• No additional servers required for deployment
• Group policy support

–

Some numbers regarding the usage of Lith Active Directory Password Protection (Source: https://twitter.com/lithnet_io/status/1154892852184248320?s=12)

• Australian university, 180000 users, 6 countries
• Czech Republic and Slovakia, mobile operators, 15000 users
• 50,000 users, manufacturing. Testing in another forest with 400,000.
• 1000 user’s. Hospitality industry!
• Humanitarian company. 14000 users worldwide
• …and most likely there are more companies using it

–

More information:

• https://github.com/lithnet/ad-password-protection
• https://blog.lithnet.io/2019/01/lppad-1.html
• https://blog.lithnet.io/2019/01/lppad-2.html
• https://blog.lithnet.io/2019/01/lppad-3.html
• https://github.com/lithnet/ad-password-protection/releases

–

Make sure to give it a try, as this really rocks! Oh and buy Ryan a beer as he really deserves it, looking at the cool stuff he designs and builds and makes it available for others to use.

–

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-03) Azure AD Password Protection (A.k.a. Banned Password List) – Getting Statistics (Part 8)

After running for some time in either AUDIT ONLY mode or ENFORCE mode, it is interesting to get some statistics of what your users are doing with regards to the passwords being used. Every RWDC with the Azure AD Password Protection DC Agent installed will evaluate the provided password against the algorithm. Regarding the algorithm see (2019-10-28) Azure AD Password Protection (A.k.a. Banned Password List) – Optimizing The Custom Per Tenant List (Part 6).

On every RWDC with the Azure AD Password Protection DC Agent installed, every password is evaluated, and the outcome is  logged in an event in the event log “\Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin”. More detailed info about the events can be found here..

–

When the PowerShell CMDlet is executed against an RWDC it basically counts the number of events for a specific action and reports that. If you therefore delete events or that RWDC is decommissioned for some reason, the statistics are lost. Remember, there are two modes, each mode has 2 possible actions, and multiple outcomes are possible that contribute to the statistics

Modes:

• AUDIT ONLY Mode
• ENFORCE Mode

–

Actions:

• Password Change: actor knows old password and provides new password (always the owner of the account, or at least a person that knows the old password)
• Password (Re)Set: actor does not know or remember old password and sets a new password. This could be an admin on behalf of the user account or an intermediate system (e.g. azure ad sspr or dell sspm or whatever) on behalf of the user and still actioned by the user itself

–

Statistics

• PasswordChangesValidated: number of password changes that were validated in either mode
• PasswordChangeAuditOnlyFailures: in AUDIT ONLY mode, the number of password changes that were validated and the result was not successful
• PasswordChangeErrors: in ENFORCE mode, the number of password changes that resulted in an error for some reason
• PasswordChangesRejected: in ENFORCE mode, the number of password changes that resulted in the password being rejecte
• PasswordSetsValidated: number of password (re)sets that were validated in either mode
• PasswordSetAuditOnlyFailures: in AUDIT ONLY mode, the number of password (re)sets that were validated and the result was not successfu
• PasswordSetErrors: in ENFORCE mode, the number of password (re)sets that resulted in an error for some reason
• PasswordSetRejected: in ENFORCE mode, the number of password (re)sets that resulted in the password being rejected

–

So how many passwords were correctly validated in either mode:

• Successful “Password Changes” = PasswordChangesValidated – PasswordChangeAuditOnlyFailures – PasswordChangeErrors – PasswordChangesRejected
• Successful “Password (Re)Sets” = PasswordSetsValidated – PasswordSetAuditOnlyFailures – PasswordSetErrors – PasswordSetsRejected

–

So to gather the statistics through an AD forest I have written a script that gathers the statistics from the RWDCs that are part of the specified scope. The script supports, three modes being: forest, domain (specified) and rwdc (specified)! Independent of the scope, it also counts the total of every statistic property and presents it accordingly at the end or in the GridView through a separate entry at the end. You can therefore see the statistics per RWDC and in total. It also provides a CSV file with the info for later use in either Excel, GridView or some other way.

# To Target All RWDCs In The AD Forest

.\AAD-Password-Protection-Statistics.ps1 -scope Forest

OR

# To Target All RWDCs In The Specified AD Domain(s)

.\AAD-Password-Protection-Statistics.ps1 -scope Domain -domains <FQDN Domain 1>,<FQDN Domains 2>,<FQDN Domain N>

OR

# For All Specified RWDCs

.\AAD-Password-Protection-Statistics.ps1 -scope RWDC -servers <FQDN RWDC 1>,<FQDN RWDC 2>,<FQDN RWDC N>

–

Figure 1: Creating A Report Of RWDCs With Numbers Regarding Passwords Processed And Evaluated

–

Figure 2: GridView Output With The Same Results

–

You can download the script from here

–

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