Jorge's Quest For Knowledge!

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

Archive for the ‘PowerShell’ Category

(2019-11-21) Active Directory Security Scan Of Accounts (Part 5)

Posted by Jorge on 2019-11-21


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

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

Figure 1d: Sample Output Of The Log File

image

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

image

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

image

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

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, IT Pro Tools, Passwords, PowerShell, Replication, Security, Security, Tooling/Scripting | Leave a Comment »

(2019-11-18) Active Directory Security Scan Of Accounts (Part 4)

Posted by Jorge on 2019-11-18


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

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

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

image

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

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, Delegation Of Control, IT Pro Tools, PowerShell, Security, Security, Tooling/Scripting | Leave a Comment »

(2019-11-15) Active Directory Security Scan Of Accounts (Part 3)

Posted by Jorge on 2019-11-15


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

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

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

image

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

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, Delegation Of Control, IT Pro Tools, PowerShell, Security, Security, Tooling/Scripting | Leave a Comment »

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

Posted by Jorge on 2019-11-12


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

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

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

image

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

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, Delegation, IT Pro Tools, Kerberos AuthN, Kerberos Constrained Delegation, PowerShell, Security, Security, Tooling/Scripting | Leave a Comment »

(2019-11-09) Active Directory Security Scan Of Accounts (Part 1)

Posted by Jorge on 2019-11-09


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

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

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

image

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

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, IT Pro Tools, Last Logon Information, PowerShell, Security, Security, Tooling/Scripting | Leave a Comment »

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

Posted by Jorge on 2019-11-08


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

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, Delegation, Delegation Of Control, IT Pro Tools, Kerberos Constrained Delegation, Last Logon Information, Passwords, PowerShell, Replication, Security, Tooling/Scripting | Leave a Comment »

(2019-10-14) Testing TCP Ports Through Your Firewall

Posted by Jorge on 2019-10-14


You need to test one or multiple ports through your firewall?

Then have a look at the following script, which has “built-in” templates for scenarios using specific TCP ports. You can use pre-defined template names, single port, multiple ports, range of ports. If you want you can add your own templates! Be careful with large ranges! Unfortunately, only TCP Ports are supported and UDP ports are not supported in this script.

image

Figure 1: Sample Output For Single Port

image

Figure 2: Sample Output For Multiple Ports

image

Figure 3: Sample Output For Multiple Ports And Port Range

image

image

Figure 4: Sample Output For Pre-Defined Template

Ohhh, and I almost forgot! 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/ ###################
————————————————————————————————————————————————————-

Posted in Firewall, PowerShell, Tooling/Scripting, Windows Client, Windows Server | Leave a Comment »

(2019-10-06) Examining Pending Export Deletions In Azure AD Connect

Posted by Jorge on 2019-10-06


If you know FIM/MIM, you also know that Azure AD Connect is based upon that under the hood. As described in Azure AD Connect sync: Prevent accidental deletes, Azure AD Connect allows you to configure a specific threshold that represents a normal/accepted amount of deletions towards Azure AD. Now, if you have a low amount of objects that you need to investigate you can easily click through the Sync Service Manager. But what happens if you need to investigate hundreds or thousands of pending deletions? Try to do that in the Sync Service Manager and you’ll through a loooooot of pain! Are there easier ways to do that? Fortunately, YES! Therefore keep reading.

Now please aware that if the number of deletions is equal to or higher than the deletion threshold it will stop the complete export operation to Azure AD, meaning no adds, updates and deletes to Azure AD! This prevents unintended deletion due to mistakes, bad configurations, etc.

To analyze those deletions, use the next steps.

  1. Logon to the ACTIVE (NON-Staging!) AAD Connect server (To determine the ACTIVE AAD Connect Server, see below!)
  2. Open a PowerShell Command Prompt Window and export the pending exports from the connector space that needs further analysis (see below)
  3. Parse the CS Export file to make it readable (see below) (PowerShell GridView Is Opened AND A CSV File Generated!)
  4. Either use the PowerShell GridView or the CSV to analyze the data being exported!
  5. For objects being deleted check if those still exist in AD and what the state is (see below)

[ad.1] Determine The Active AAD Connect Server

Open a PowerShell Command Prompt Window, and execute:

Import-Module ADSYNC

Get-ADSyncGlobalSettingsParameter | ?{$_.Name -eq "Microsoft.Synchronize.StagingMode"} | Select Name,Value

REMARK: If the VALUE mentions TRUE, then it is the Passive (staging) Server, if the VALUE mentions FALSE or is empty, then it is the Active (Non-Staging) Server

[ad.2] Export The Pending Exports From The Connector Space That Needs Analysis

On The Active AAD Connect Server, open a PowerShell Command Prompt Window, and execute:

CD "C:\Program Files\Microsoft Azure AD Sync\Bin"
$connectorHT = New-Object system.collections.hashtable
Write-Host ""
Write-Host "+++ Available Connectors +++" -ForegroundColor Cyan
$connectorNr = 0
Get-ADSyncConnector | %{
    $connectorNr++
    $connectorName = $null
    $connectorName = $_.Name
    $connectorHT[$connectorNr.ToString()] = $connectorName
    Write-Host "[$connectorNr] – $connectorName" -ForegroundColor Magenta
    Write-Host ""
}
$chosenConnectorNr = $null
$chosenConnectorNr = Read-host "Please Choose The Connector By Typing Its Number"

$chosenConnectorName = $null
$chosenConnectorName = $connectorHT[$chosenConnectorNr]
$datetime = Get-Date -Format "yyyy-MM-dd_HH.mm.ss"
$csExportXMLFilepath = Join-Path "C:\TEMP" $($datetime + "_CS-" + $chosenConnectorName + "_PendingExports.xml")
$csExportCMD = ".\CSEXPORT.EXE `"$chosenConnectorname`" `"$csExportXMLFilepath`" /f:x"
Invoke-Expression $csExportCMD
Write-Host ""
Write-Host "Export File…….: $csExportXMLFilepath" -ForegroundColor Cyan
Write-Host ""

[ad.3] Parse The CS Export XML File

On The Active AAD Connect Server, open a PowerShell Command Prompt Window, and execute:

CD "<Folder With Script>"

$csExportCSVFilepath = $csExportXMLFilepath.TrimEnd(".xml")

.\Parse-CS-Export-XML-To-CSV.ps1 -outToAll -sourceXMLfilePaths $csExportXMLFilepath -targetFilePath $csExportCSVFilepath

REMARK: the GridView will be opened automatically!

image

Figure 1: Results After Parsing The XML File(s) To A CSV

In the GridView or Excel, any value added or deleted, will be specified as such. Unchanged values are not listed

image

Figure 2: GridView Sample Output

image

Figure 3: GridView Sample Output

image

Figure 4: GridView Sample Output

 image

Figure 5: GridView Sample Output

REMARK: To reopen the GridView using the CSV file use the following command:

Import-CSV $($csExportCSVFilepath + ".csv") | Out-Gridview

or

Import-CSV "<CSV File Path>" | Out-Gridview

[ad.5a] Check Deleted USERS Against AD

$csExportCSV = Import-CSV $($csExportCSVFilepath + ".csv")
$objectListUsers = @()
$csExportCSV | ?{$_."Object-Type" -eq "user" -And $_."Ops-Type" -eq "delete"} | %{
    $immutableID = $null
    $immutableID = $_."Source-ID"
     $userPrincipalName = $null
    $userPrincipalName = $_."AD-ID"

    $ldapFilter = $null
    $ldapFilter = "(|(raboADImmutableID=$immutableID)(userPrincipalName=$userPrincipalName))"

    $adObject = $null
    $adObject = Get-ADObject -LDAPFilter $ldapFilter -Server :3268 -Properties *

    $displayName = $null
    $status = $null
    $canonicalName = $null

    If ($adObject) {
        $displayName = $adObject.DisplayName
        $status = If (($adObject.userAccountControl -band 2) -eq "2") {"Disabled"} Else {"Enabled"}
        $canonicalName = $adObject.CanonicalName
    } Else {
        $displayName = "Unavailable"
        $status = "Unavailable"
        $canonicalName = "Unavailable"
    }

    $object = New-Object -TypeName System.Object
    $object | Add-Member -MemberType NoteProperty -Name "immutableID" -Value $immutableID
    $object | Add-Member -MemberType NoteProperty -Name "userPrincipalName" -Value $userPrincipalName
    $object | Add-Member -MemberType NoteProperty -Name "displayName" -Value $displayName
    $object | Add-Member -MemberType NoteProperty -Name "status" -Value $status
    $object | Add-Member -MemberType NoteProperty -Name "canonicalName" -Value $canonicalName
    $objectListUsers += $object
}
$objectListUsers | Out-GridView

REMARK: A Gridview will be opened automatically telling you the status of the object and if it exists in AD

[ad.5b] Check Deleted GROUPS Against AD

$objectListGroups = @()
$csExportCSV | ?{$_."Object-Type" -eq "group" -And $_."Ops-Type" -eq "delete"} | %{
    $immutableID = $null
    $immutableID = $_."Source-ID"
    $domain = $null
     $domain = $($_."AD-ID").SubString(0, $($_."AD-ID").IndexOf("\"))
    $sAMAccountName = $null
    $sAMAccountName = $($_."AD-ID").SubString($($_."AD-ID").IndexOf("\") + 1)
    $ldapFilter = $null
    $ldapFilter = "(|(raboADImmutableID=$immutableID)(sAMAccountName=$sAMAccountName))"
    $adObject = $null
    $adObject = Get-ADObject -LDAPFilter $ldapFilter -Server $domain`:389 -Properties *
    $displayName = $null
    $canonicalName = $null
    If ($adObject) {
        $displayName = $adObject.DisplayName
        $canonicalName = $adObject.CanonicalName
    } Else {
        $displayName = "Unavailable"
        $canonicalName = "Unavailable"
    }
    $object = New-Object -TypeName System.Object
    $object | Add-Member -MemberType NoteProperty -Name "immutableID" -Value $immutableID
    $object | Add-Member -MemberType NoteProperty -Name "sAMAccountName" -Value $sAMAccountName
    $object | Add-Member -MemberType NoteProperty -Name "displayName" -Value $displayName
    $object | Add-Member -MemberType NoteProperty -Name "canonicalName" -Value $canonicalName
    $objectListGroups += $object
}
$objectListGroups | Out-GridView

REMARK: A Gridview will be opened automatically telling you the status of the object and if it exists in AD

[ad.5c] Check Deleted CONTACTS Against AD

Function GuidToEscapedByte($guid) {
    $guidParts = $guid.Split("-")
     $reverse = $guidParts[0].ToCharArray()[($guidParts[0].Length – 1)..0] + $guidParts[1].ToCharArray()[($guidParts[1].Length – 1)..0] + $guidParts[2].ToCharArray()[($guidParts[2].Length – 1)..0]
    $rest = $guidParts[3].ToCharArray() + $guidParts[4].ToCharArray()
    for ($inc =0; $inc -lt $reverse.Length; $inc+=2) {
        $escapedGUID = $escapedGUID + "\" + $reverse[$inc+1] + $reverse[$inc]
    }
    for ($inc =0; $inc -lt $rest.Length; $inc+=2) {
        $escapedGUID = $escapedGUID + "\" + $rest[$inc] + $rest[$inc+1]
    }
    return $escapedGUID
}
$csExportCSV = Import-CSV $($csExportCSVFilepath + ".csv")
$objectListContacts = @()
$csExportCSV | ?{$_."Object-Type" -eq "contact" -And $_."Ops-Type" -eq "delete"} | %{
    $immutableID = $null
    $immutableID = $_."Source-ID"
    $objectGUID = $null
    $objectGUID = (New-Object -TypeName System.Guid -ArgumentList(,(([System.Convert]::FromBase64String($immutableID))))).Guid
    $objectGUIDEscaped = $null
    $objectGUIDEscaped = GuidToEscapedByte $objectGUID
    $mail = $null
    $mail = $_."AD-ID"
     $ldapFilter = $null
    $ldapFilter = "(|(objectGUID=$objectGUIDEscaped)(mail=$mail))"
    $adObject = $null
    $adObject = Get-ADObject -LDAPFilter $ldapFilter -Server :3268 -Properties *
    $displayName = $null
    $canonicalName = $null
    If ($adObject) {
        $displayName = $adObject.DisplayName
         $canonicalName = $adObject.CanonicalName
    } Else {
         $displayName = "Unavailable"
        $canonicalName = "Unavailable"
    }
    $object = New-Object -TypeName System.Object
     $object | Add-Member -MemberType NoteProperty -Name "immutableID" -Value $immutableID
    $object | Add-Member -MemberType NoteProperty -Name "mail" -Value $mail
    $object | Add-Member -MemberType NoteProperty -Name "displayName" -Value $displayName
    $object | Add-Member -MemberType NoteProperty -Name "canonicalName" -Value $canonicalName
    $objectListContacts += $object
}
$objectListContacts | Out-GridView

REMARK: A Gridview will be opened automatically telling you the status of the object and if it exists in AD

Now assuming you have confirmed all deletions are expected, you can lift the threshold or increase its value (temporarily) to allow the sync cycle to succeed! You need an Azure AD Admin Account with the Global Administrator role

  • If needed elevate your account through https://portal.azure.com/ → Privileged Identity Management \ Azure AD Roles \ Global Administrator – Activate
  • On the active AAD Connect server, open a PowerShell Command prompt Window and execute:

$aadAdminCreds=Get-Credential

Get-ADSyncExportDeletionThreshold -AADCredential $aadAdminCreds

Disable-ADSyncExportDeletionThreshold -AADCredential $aadAdminCreds

REMARK: The sync engine maybe synching as you do that and you may receive an error. Just wait until the sync engine finishes.

  • As soon as the sync engine is not executing a sync cycle, execute:

Start-ADSyncCycle -PolicyType Delta

  • As soon as that sync cycle has finished enable the threshold again using the previous value

Enable-ADSyncExportDeletionThreshold -DeletionThreshold <value> -AADCredential $aadAdminCreds

PS: this script also works for Pending Export Deletes in FIM/MIM and the script supports multiple source XML files (each for a different CS) as input files!

Ohhh, and I almost forgot! You can download the script from here! Smile

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

Posted in Azure AD Connect, Connector/MA, CSExport, Forefront Identity Manager (FIM) Sync, Microsoft Identity Manager (MIM), PowerShell, Tooling/Scripting, Tools, Windows Azure Active Directory | 1 Comment »

(2019-07-11) Creating A List Of Role Members Within Azure AD Administrative Units

Posted by Jorge on 2019-07-11


Do you need to create a list of role members that have been delegated one or more roles to administrative units? Then look no further. See the example below

image

Figure 3: The Administrative Units And Its Scoped Role Members

The script can be downloaded from the script gallery 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/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Administrative Units, PowerShell, Tooling/Scripting, Windows Azure Active Directory | Leave a Comment »

(2019-07-09) Creating A List Of Users Within Azure AD Administrative Units

Posted by Jorge on 2019-07-09


Do you need to create a list of users that are a members of administrative units? Then look no further. See the example below

image

Figure 1: The Administrative Units And Its AU Members

The script can be downloaded from the script gallery 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/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Administrative Units, PowerShell, Tooling/Scripting, Windows Azure Active Directory | Leave a Comment »

 
%d bloggers like this: