(2019-12-12) Delivered Session About “Moving Towards Passwordless Concept”

Delivered session @DetronICT, invited by @ThierryVos about "Moving Towards Passwordless Concept" (preso and demos). About 30 tech enthusiasts listened until bitter end. Thanks for the invitation, and until a next time! Reward afterwards? Enjoying some beers together!

Figure 1: Initial Slide – Title/SubTitle

–

Figure 2: Introducing Me

–

Figure 3: The Agenda

–

Figure 4: The Agenda With Demos

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

Advertisement

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

(2008-02-10) Showing Last Logon Info At Logon In Windows Server 2008

From the WNT4 days it was possible to use the "lastLogon" attribute to determine the last logon time of a user account. This attribute has been available in all OS’s until now. The caveat of this attribute is that it does not replicate between DCs and because it is possible for a user account to be authenticated by any DC in the domain, you would need to retrieve the information from every DC in the domain. Starting with Windows Server 2003 (W2K3) a new attribute called "lastLogonTimeStamp" has been introduced which records the last logon time of a user account somewhat more accurately. This attribute is only used by the system when the Domain Functional Level has been raised to Windows Server 2003. That means that only W2K3 DCs exist in the AD domain and no WNT4 or W2K DCs. Compared to the "lastLogon" attribute, the "lastLogonTimeStamp" attribute DOES replicate. To prevent excessive replication that attribute is only updated for NTLM and Kerberos Interactive Logons under certain conditions. The attribute is updated if it is older than [(the current time) – (value of "msDS-LogonTimeSyncInterval" attribute)]. For an accurate explanation of when the attribute is updated I suggest you read joe’s post about the "Replication of lastLogonTimeStamp".

As you might have noticed, Windows Server 2008 (Microsoft’s flagship OS) has RTMed. That OS introduces a new set of attributes which allow you to determine:

• The last successful Interactive Logon (information stored in the "msDS-LastSuccessfulInteractiveLogonTime" attribute)
  
• The last failed Interactive Logon (information stored in the "msDS-LastFailedInteractiveLogonTime" attribute)
  
• The total number of failed Interactive Logons recorded since the time has been enabled (information stored in the "msDS-FailedInteractiveLogonCount" attribute)
  
• The total number of failed Interactive Logons recorded since the last successful Interactive Logon (information stored in the "msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon" attribute)
  

This feature is only available after the Domain Functional Level has been increased to Windows Server 2008. That means that only W2K8 DCs exist in the AD domain and no WNT4, no W2K or W2K3 DCs. Even after increasing the DFL the feature is not available right away. For this feature you need to distinguish two things: "reporting the information at logon" and "writing the information into the directory at logon". The feature can only be leveraged by Windows Vista and Windows Server 2008. Other OS’s will ignore it. Compared to the other attributes mentioned, these attributes are updated without conditions.

To "write the information into the directory at logon" a GPO with DCs in its Scope of Management must have the setting the following setting enabled:

• Computer Configuration\Administrtive Templates\Windows Components\Windows Logon Options\Display information about previous logons during user logon = ENABLED
  

At the same time it will also report the information for all accounts logging on at ANY DC in the AD domain.

To "report the information at logon" a GPO with servers and/or clients in its Scope of Management must have the setting the following setting enabled:

• Computer Configuration\Administrative Templates\Windows Components\Windows Logon Options\Display information about previous logons during user logon = ENABLED
  

If the feature is enabled for servers and/or clients, but not for W2K8 DCs (independent of Domain Functional Level) the following error will occur at logon.

As you can see the user is NOT able to logon. So someone managing a GPO that targets servers and/or clients can configure the system in a way that nobody is able to logon. So be very careful with this!

So if the feature is enabled for BOTH W2K8 DCs and Windows Vista/Windows Server 2008 clients/servers the following will appear the first time an account logs on:

As you can see the user MUST click OK to continue. There is no other option.

I the feature is enabled for BOTH W2K8 DCs and Windows Vista/Windows Server 2008 clients/servers the following will appear at the next successful logon after a certain amount of failed logons:

An example of the account metadata looks like:

Now you might wonder why this feature is important. One of the examples that come to my mind is online banking. As an awareness measure when using online banking some of the online banking systems report the last time your account logged on and used the online banking system. A similar feature like this can be very important for very high secure environments. That way you are able to see if someone is trying to use your account and guessing the password. Unfortunately it does not report from which computers the logons were carried out. For that you would still need to check the security logs of the DCs. One of the tricks you could do to see on which DC the attribute was written is to retrieve the object metadata of the user account (with REPADMIN /SHOWOBJMETA <DC> <ObjectDN>) and check the originating DC of one of the four attributes. When only using W2K8 RWDCs this method is accurate is enough. However, this method might not be that accurate when also using Read-Only Domain Controllers. The reason is that when an account is authenticated by an RODC the information is written into the attributes on the RODC and on a nearby RWDC. And NO, the information does not replicate from the RODC to the RWDC!!! Although the RODC already has the information it will replicate back again from the RWDC to the RODC. This occurs because the update sequence number (USN) and the high-water mark are not updated on the RODC, but they are updated on the RWDC. So it might look like the account was authenticated by an RWDC, but it could also have been authenticated by an RODC.

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————