Archive for the ‘Passwords’ Category

(2023-06-14) Securing Or Attacking Your Active Directory With Azure AD Passwordless Authentication? That IS The Question!

Posted by Jorge on 2023-06-14

Tonight I was reading Dirk-Jan’s post on how Cloud Kerberos Trust, in use by Azure AD Passwordless AuthN, could be used to attack the Active Directory. Very interesting read! For all the details, please see: Obtaining Domain Admin from Azure AD by abusing Cloud Kerberos Trust

This is interesting as normally Active Directory is being used to attack Azure AD. Now it is the other way around, using Azure AD to attack Active Directory. Dirk-Jan explains all the details in his blog post, so please make sure to read that too!

So, after configuring Cloud Kerberos Trust in your AD as explained in Cloud Kerberos trust deployment, you will end up with 2 special objects in AD to support that:

The RODC computer account “AzureADKerberos$”, by default in the Domain Controllers OU;
An additional RODC-like KrbTgt account named krbtgt_AzureAD. This account contains the Kerberos keys used for tickets that Azure AD creates.

The RODC computer account has an additional configuration, being the Password Replication Policy (PRP). For a real RODC, the PRP looks like the following.
REMARK: The 2 groups starting with “GRP” are custom and were added by me to this PRP.

Analyzing it

1 default ALLOW group that by default is empty
5 default DENY groups with other high-privileged groups or accounts as members

**Figure 1**: The Password Replication Policy Of A Read-Only Domain Controller

After configuring Cloud Kerberos Trust in the AD, you will see an RODC-like computer account called AzureADKerberos (=CN), and its password replication policy looks like the following.

Analyzing it:

1 default ALLOW group that by default contains ALL users in the AD domain
9 default DENY groups with other high-privileged groups or accounts as members

**Figure** 2: The Password Replication Policy Of The RODC Like Computer Account For The Cloud Kerberos Trust

So looking at this, the end result will be that all users in the AD domain, except for high-privileged accounts in the specified high-privileged groups, will be able to use Passwordless Authentication. Those same accounts are subject to an attack, but there is no need to worry as it does not contain high-privileged accounts, right? Wrong!

There may be many accounts in AD, that may not be a member in any of the 9 default DENY group, but still have very high privileges for some (valid) reason. A few that come to mind are the accounts in use by Azure AD Connect Sync (MSOL_* or custom) and Azure AD Cloud Sync (pGMSA_*) to connect to AD and retrieve data from or write data to AD. Those accounts most likely have “Replicating Directory Changes” and “Replicating Directory Changes All” control access right (CAR). Any account with those powers is able to perform DC Sync and get the password hashes of other accounts like the default domain administrator, and the KrbTgt account. But is that enough? Heck no! On the domain NC, you may have accounts with all kinds of exotic permissions that after a few steps allow you to still perform DC Sync. Think about accounts, or even groups configured on the domain NC with other permissions like “Full Control” (allows to perform DC Sync), or “Write DACL” (allows to change the permissions and assign “Replicating Directory Changes” and “Replicating Directory Changes All” control access right, and then perform CD sync), or “Write Owner” (allows to change the permissions and assign “Replicating Directory Changes” and “Replicating Directory Changes All” control access right, and then perform CD sync). As you can see lots of ways to get the required permissions for follow-up attacks. So how would you solve this?

There are 2 ways to solve this problem, and it depends on what you prefer to manage.

If you prefer to manage the Password Replication Policy of the AzureADKerberos RODC-like computer account, then:

Configure all accounts and groups, configured on the domain NC, with explicit permissions for “Replicating Directory Changes” and “Replicating Directory Changes All” control access right (CAR), or “Full Control”, or “Write DACL” or “Write Owner”, in the DENY part of the Password Replication Policy

If you prefer to manage group membership, while at the same time also protecting/preventing explicitly accounts/groups from having the password of the accounts being replicated to other RODCs if in place, then:

Configure the default “Denied RODC Password Replication Group” (objectSID = domainSID-572) in the DENY part of the Password Replication Policy
Configure all accounts and groups, configured on the domain NC, with explicit permissions for “Replicating Directory Changes” and “Replicating Directory Changes All” control access right (CAR), or “Full Control”, or “Write DACL” or “Write Owner”, as members of that default “Denied RODC Password Replication Group”

The second and last option would be my personal preferred way of configuring this.

Some additional comments I would like to make:

In Cloud Kerberos trust deployment, the following NOTE is displayed halfway through the page:

**Figure** 3: A Note About The Configuration Of The Group “Denied RODC Password Replication Group”

The note is a weird statement, as when you look at Figure 2, it is not even listed by default, while it should be. My guess is that a mistake was made when the default ALLOW group was replaced by the Domain Users group, they also removed the default DENY group, which should not have happened.

In Cloud Kerberos trust deployment, the following NOTE is displayed at the end of the page:

**Figure** 4: A Note About Relaxing The Password Replication Policy Of The AzureADKerberos Computer Account

Looking at what Dirk-Jan has described, I would NOT recommend in relaxing the Password Replication Policy of the AzureADKerberos Computer Account. Better yet, I would harden it as described Dirk-Jan in his post and by me in this post.

For both NOTES I will try to contact Microsoft to have those statements updated if possible.

You may also want to check out the contributions from Elad Shamir:

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 ##########################
#################### https://jorgequestforknowledge.wordpress.com/ ###################

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

IAMTEC

Identity | Security | Recovery

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

Posted in Active Directory Domain Services (ADDS), AuthN, Azure AD Connect, Kerberos AuthN, KrbTgt Account, Passwordless, Passwordless, Passwords, Passwords, Read-Only Domain Controller, Windows Azure Active Directory | Tagged: Active Directory, Azure Active Directory, Azure AD Connect, Cloud Kerberos trust, Passwordless | 1 Comment »

(2020-03-30) Resetting The Password Of The Special Purpose KrbTgt Account For Azure AD

Posted by Jorge on 2020-03-30

To reset the password of krbtgt accounts in the AD domain I have written a script that helps you with that.

More information can be found through the following links:

–

The script itself can be downloaded through the following link: Reset The KrbTgt Account Password/Keys For RWDCs/RODCs

–

With the passwordless investments made by Microsoft, a preview currently is available to also use passwordless authentication using security keys against the on-premises AD. You can read more about it through the following link:

Enable passwordless security key sign-in to on-premises resources with Azure Active Directory (preview)

–

To achieve the goal of passwordless authentication using security keys against AD, a special krbtgt account (‘Krbtgt_AzureAD’) is created in every single AD domain where that is required. That krbtgt account is very similar to a krbtgt account for an RODC and represents Azure AD for a specific AD domain. Like any other krbtgt account, that krbtgt account also requires to have its password reset and keys rotated. Very important to note here, is the password reset should not be done like any other regular password reset, but instead a special procedure should be followed. The PowerShell script that I mention above DOES NOT impact that special krbtgt account. Including with other updates, I will update the PowerShell script to warn you if it finds that special krbtgt account in the AD domain, and also include the method and steps to officially reset the password and rotate the keys.

–

To officially officially reset the password and rotate the keys, use the following steps:

Go to an Azure AD Connect server (v1.4.32.0 or later)
Open a PowerShell Command Prompt window
In that window execute the following commands:

# Import The PowerShell Module For Azure AD Kerberos Server
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADKerberos\AzureAdKerberos.psd1"

# AD Domain FQDN To Target
$adDdomainFQDN = Read-Host "AD Domain FQDN To Target"

# AD Domain/Enterprise Admin Credentials
$adDomainAdminAccount = Read-Host "AD Admin Account"
$adDomainAdminPassword = Read-Host "AD Admin Account Password" -AsSecureString
$secureAdDomainAdminPassword = ConvertTo-SecureString $adDomainAdminPassword -AsPlainText -Force
$adDomainAdminCreds = New-Object System.Management.Automation.PSCredential $adDomainAdminAccount, $secureAdDomainAdminPassword

# Azure AD Global Admin Credentials
$aadDomainAdminAccount = Read-Host "Azure AD Admin Account"
$aadDomainAdminPassword = Read-Host "Azure AD Admin Account Password" -AsSecureString
[string]$aadDomainAdminPassword = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($aadDomainAdminPassword))
$secureAadDomainAdminPassword = ConvertTo-SecureString $aadDomainAdminPassword -AsPlainText -Force
$aadDomainAdminCreds = New-Object System.Management.Automation.PSCredential $aadDomainAdminAccount, $secureAadDomainAdminPassword

# Check the CURRENT status of the Azure AD Kerberos Server object in Active Directory
Get-AzureADKerberosServer -Domain $adDdomainFQDN -DomainCredential $adDomainAdminCreds -CloudCredential $aadDomainAdminCreds

# Reset the password and rotate the keys
Set-AzureADKerberosServer -Domain $adDdomainFQDN -DomainCredential $adDomainAdminCreds -CloudCredential $aadDomainAdminCreds -RotateServerKey

# Check the NEW status of the Azure AD Kerberos Server object in Active Directory
Get-AzureADKerberosServer -Domain $adDdomainFQDN -DomainCredential $adDomainAdminCreds -CloudCredential $aadDomainAdminCreds

REMARKS:

For AD, domain or enterprise admin credentials are required
For AAD, global admin credentials are required (accounts with MFA are supported!)
Make sure the ‘KeyVersion’ value matches the ‘CloudKeyVersion’ value and the ‘KeyUpdatedOn’ value matches the ‘CloudKeyUpdatedOn’ value!

–

Figure 1A: The Popup You Will Get When The AAD Global Admin Account Is MFA Enabled Or Is Targeted Through Conditional Access For MFA

–

Figure 1B: The Popup You Will Get When The AAD Global Admin Account Is MFA Enabled Or Is Targeted Through Conditional Access For MFA

–

Figure 2: When Having The Correct Version Of Azure AD Connect And The KrbTgt Account Does Not Yet Exist

–

Figure 3: The Initial Creation Of The KrbTgt Account For Azure AD

–

Figure 4: How The KrbTgt Account Looks Like Under The Hood

–

Figure 5A: The Placeholder RODC Computer Account For The KrbTgt Account

–

Figure 5B: The Placeholder RODC Computer Account For The KrbTgt Account

–

Figure 6: Result After Resetting The Password Of The KrbTgt Account Like Any Other KrbTgt Account (DO NOT Do This!)

–

Fixing regular reset: Set-AzureADKerberosServer -Domain <AD Domain FQDN> -DomainCredential <AD Domain Admin Creds> -CloudCredential <AAD Global Admin Creds> –RotateServerKey

Official reset: Set-AzureADKerberosServer -Domain <AD Domain FQDN> -DomainCredential <AD Domain Admin Creds> -CloudCredential <AAD Global Admin Creds> -RotateServerKey

Figure 7: Fixing A Regular Reset And Officially Resetting The Passwords

–

Figure 8: Too Frequent (Within 24 Hours) Password Resets Generates A Warning

–

Set-AzureADKerberosServer : You must wait 24 hours in between rolling the Azure AD Kerberos Server keys. Rolling keys too frequently may result in service disruption. You may use the Force option to ignore this warning.
At line:1 char:1
+ Set-AzureADKerberosServer -Domain $adDomainFQDN -DomainCredential $ad …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Set-AzureADKerberosServer], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.AzureAD.Kdc.Management.SetAzureADKerberosServer

–

Have fun!

–

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), Azure AD Connect, Kerberos AuthN, KrbTgt Account, Passwordless, Passwordless, Passwords, Passwords, Windows Azure Active Directory | 2 Comments »

(2020-02-14) Creating An HTML Report Of All Password And Account Lockout Policies In The AD Forest

Posted by Jorge on 2020-02-14

It was one of those days. Auditors came in to audit stuff. One of the questions was to produce evidence about the password and account lockout policy in the default domain policy. Those guys are probably still living in the Windows Server 2003 ages as with Windows Server 2008 and later so called Password Settings Objects (PSO) are supported where you can have as many password and account lockout policies as you see fit for your environment. For example, a PSO for regular users, one for regular service accounts and one or more your admin accounts.

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

Posted by Jorge on 2019-12-12

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

Posted in Active Directory Domain Services (ADDS), Active Directory Federation Services (ADFS), Azure AD / Office 365, Azure AD Connect, Azure AD Identity Protection, Azure AD MFA Adapter, Azure AD Password Protection, Conferences, Field Experiences, Group Policy Objects, Last Logon Information, Microsoft Authenticator App, Multi-Factor AuthN, MVP, Password Expiration Notification, Password-Less, Passwords, Passwords, Self-Service Password Reset, SSO, SYSVOL, Tooling/Scripting, Windows Azure Active Directory | 1 Comment »

(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

–

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

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

(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

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 | 2 Comments »

(2019-11-06) Azure AD Password Protection (A.k.a. Banned Password List) – Third Party Solution LithNet AD Password Protection (Part 9)

Posted by Jorge on 2019-11-06

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:

–

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

Posted in Active Directory Domain Services (ADDS), IT Pro Tools, Passwords, Replication, Security, SYSVOL | Leave a Comment »

(2019-11-03) Azure AD Password Protection (A.k.a. Banned Password List) – Getting Statistics (Part 8)

Posted by Jorge on 2019-11-03

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

Posted in Active Directory Domain Services (ADDS), Azure AD Password Protection, Blog Post Series, Passwords, Passwords, Replication, Security, SYSVOL, Windows Azure Active Directory | 4 Comments »

(2019-10-29) Azure AD Password Protection (A.k.a. Banned Password List) – From Audit Mode To Enforce Mode (Part 7)

Posted by Jorge on 2019-10-29

If you are implementing this correctly, you should configure Azure AD with the banned words and set it initially to AUDIT MODE, install the Azure AD Password Protection Proxy Service on 1 or 2 member servers within the targeted/registered AD forest, install AD Password Protection DC Agent on all the writable DCs in the targeted/registered AD forest. At some point in time you need to move from AUDIT MODE to ENFORCE MODE, but when do you do that?

–

At its core Azure AD Password Protection will prevent the usage of specific passwords that use words from the global Microsoft list and the custom per tenant list and that have a score that’s lower than the threshold. Therefore putting it in ENFORCE MODE right will hurt your users! Why? If your users have the habit of using weak words and/or words related to your business (that are or end up on the banned lists), you need to educate and communicate to those users NOT to use weak (pass)words. The strength of a password is not related to the number of characters substituted by special or numeric characters. The strength of a password is related to the length of the password. Therefore “mYc00lco3p@ny!” is really not as strong as something like “I really like to w0rk at my cool company!”.

–

So, while running in AUDIT MODE and at the same time educating/communicating to your users, you already can get some statistics about what users are doing with their passwords when changed or reset (admin or self-service). All new passwords will go throw the password filter and be evaluated. If the password should be blocked, in AUDIT MODE it will not block the password but it will specify in the DC Agent Admin Log (“\Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin”) it would have been blocked in ENFORCE MODE. The user itself is not notified of such potential blocking. After having everything setup and up and running after a week or 2 or so, check the statistics. Compare the amount of “bad passwords” with the amount of “good passwords”. Your eyes will pop out when you see the results! So educate and communicate first! Do not for get to also inform your service desk(s) before moving to ENFORCE MODE

–

As soon as you move to ENFORCE MODE, it will impact any account in the AD forest that tries to change or reset the password when running in ENFORCE MODE. It will NOT have an impact on existing passwords! With impact I mean: if the provided password is not accepted by Azure AD Password Protection, it will block the user from using it and the user will be notified as such. Unfortunately, the user gets the default “Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain” when updating the password through the GINA. The message may differ however, when using other intermediate systems/

–

One of the things that I have seen or heart when implementing Azure AD Password Protection, is that people want to understand why a password is not accepted. That is valid because with that in mind they can make a better choice for a new password. Following up that, you might hear something like: “can we publish somewhere which words we do not allow to be used in passwords?”. With this question in mind, please remember that it is not forbidden to use words on the global Microsoft list and/or the custom per tenant list. You just need to make sure the password with one or multiple words is accepted by the scoring algorithm (score of 5 or higher). For more information on that please check (2019-10-28) Azure AD Password Protection (A.k.a. Banned Password List) – Optimizing The Custom Per Tenant List (Part 6).

So to answer the question: “can we publish somewhere which words we do not allow to be used in passwords?”, the answer is: “yes, but it will not help you!”. Why? Because there are 2 lists! The custom per tenant list is managed by you and therefore known to you, but the global Microsoft list is managed by Microsoft and its contents is unknown to the outside world. Nevertheless, the blog post (2019-10-28) Azure AD Password Protection (A.k.a. Banned Password List) – Optimizing The Custom Per Tenant List (Part 6) does provide information on how to check if a password is blocked by the custom per tenant list or the global Microsoft list or both. In other words, there is no value in publishing your list, as it only tells you half of the truth. Nevertheless, you may of course decide different as you see fit.

–

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), Azure AD Password Protection, Blog Post Series, Passwords, Passwords, Replication, Security, SYSVOL, Windows Azure Active Directory | Leave a Comment »

(2019-10-28) Azure AD Password Protection (A.k.a. Banned Password List) – Optimizing The Custom Per Tenant List (Part 6)

Posted by Jorge on 2019-10-28

The main goal of Azure AD Password Protection is to prevent users from using passwords that are (too) common and predictable. Because those passwords are too common or predictable those are always used in attacks like or similar to password spraying. Looking at the past “January2018” is considered complex as it has characters from three out of four character sets. Most likely the next password is “February2018“, etc. The same is true for “Pa$$w0rd”. Those combinations are too easy and nobody is fooled by character substitutions.

–

Azure AD Password Protection has a specific algorithm and it works like:

Normalize password

all letters in password to lower case (e.g. A->a, B->b, etc.) and compare with banned password list. If true, deny!
Replace special characters to normal letters (e.g. @->a, 1->I, etc.) and compare with banned password list. If true, deny!

Fuzzy matching –> Check the password against the banned password list taking 1 edit distance into account (e.g. "abcdef" vs. "abcdeg"). If true, deny!
Check if password contains:

First Name. If true, deny!
Last Name. If true, deny!
Tenant Name. If true, deny!

If still not denied, calculate the score of the password

Minimum allowed score for passing is 5 points
Check which words on BPL (e.g. motor, cycle, helmet) are in password, assign 1 point for each

Found substrings (“m0torcyc1ehelmetU63”) = 1 point each –> 3 points in this example

For every remaining individual characters, assign 1 point for each character

Found individual characters (“m0torcyc1ehelmetU63”) = 1 point each –> 3 points in this example

Total = 6 points –> PASS

–

REMARK: if the BPL has the words ”motor”, “cycle” and “motorcycle” and you are trying to use the password “m0torcycleY6k”, it will fail (4 points and not 5 points). In this case it check against the word “motorcycle” instead of “motor” and “cycle”. If the BPL contains 2 or more words that combined also exists as an individual word, it will always prefer to check against the longer word as with it will end up with lower amount of points.

–

The BPL consists of 2 lists, being the global MSFT list and the custom per tenant list. The custom per tenant list has a maximum of 1000 words, each word must be at least 4 characters long and not be longer than 16 characters. It is also not possible to tweak the algorithm. This is it and that’s what you can use.

–

With regards to the global MSFT list, which is maintained by MSFT, nobody, except MSFT, knows the content of that list. So when you need to populate the custom per-tenant list how do you know it is not already included in the global MSFT list and you are not wasting valuable space in the custom per-tenant list? Easy answer! You don’t! But, I found a way to test words to determine if those are already included in the global MSFT list or not! THAT will help YOU determine if any of your words are already included in the global MSFT list or not. I even wrote a PowerShell script for that you can use.

–

Yes I know it is against bad practice! But I did not want to complicate the script to get things done. In general this script requires “Domain Admins” equivalent permissions if you have a single AD domain in your AD forest! If you have multiple AD domains in your AD forest, then it really depends on your scenario which depends between needing “Domain Admins” or needing “Enterprise Admins”. You would just need “Domain Admins” if the executing account of the script is in the same AD domain as the account you are using to test the words against. You would just need “Enterprise Admins” if the executing account of the script is in some other AD domain then the account you are using to test the words against.

To really be concrete about what you need, you need the following:

Reset Password” Control Access Right, a.k.a. Extended Right, on the targeted AD user account
Permissions to read/query the Microsoft-AzureADPasswordProtection-DCAgent/Admin Event Log

As you can see, either “Domain Admins” or “Enterprise Admins” will get the job done, but I really can imagine if you want to cut down those permissions to delegated rights. Is that possible? Hell yes, it is possible. Feel free to use the contact form to get more info about delegating this. At this point I was just too lazy to write it all down in addition to this.

–

Other things to note when using Azure AD Password Protection:

You cannot change anything in this algorithm. This is it and you need to use as-is
Only populate lower version of words. Do not specify upper characters or special character to replace normal characters
Changes in Azure AD, may take some hours before those get down to the RWDCs. The easy way to propagate faster is to restart the Azure AD Password Protection DC Agent service on at least 1 RWDC per AD domain. That action makes sure that RWDC triggers the instant download of the newest policies for that AD domain. Remember, although this is a per AD forest registration, the consumption of all this is per AD domain!
Something else to note is localization. Unfortunately it is not fully localized (English Only). For example, it prohibits "welkom" and allows "wachtwoord", while it denies both "password" and "welcome". Weird, but true.
Another unfortunate thing is that it does not integrate directly with external solutions such as “Have I Been Pwned”. MSFT however may have some integration in the background where the newest compromised password are included. Unfortunately, nobody knows, except MSFT. You can check the latest version of the global MSFT list after restarting the Azure AD Password Protection DC Agent service as at that point in time it will specify in the Microsoft-AzureADPasswordProtection-DCAgent/Admin event log which policy date version is being used for the global MSFT list and the custom per tenant list.
Not easy to test passwords against it (please do continue reading!)

–

As mentioned earlier I found a way to check candidate words for the custom per-tenant list and check if those are already on that list and/or on the global MSFT list.

This is what you need:

Create an input text file with all the (new) candidate words for the custom per tenant list
Create an user account in some AD domain in the AD forest that is registered in Azure AD, and make sure that user account is disabled (security measure!)
If you want to use delegated permissions instead of the Domain/Enterprise Admins “will always work” permissions, you need at least the following delegated permissions

Reset Password” Control Access Right, a.k.a. Extended Right, on the targeted AD user account

Permissions to read/query the Microsoft-AzureADPasswordProtection-DCAgent/Admin Event Log

Create a PSO that allows a minimum password length of 7 characters (minimum word length of 4 + 3 additional characters)
Assign the user account directly to that PSO
ActiveDirectory PowerShell CMDlets

–

Figure 1: Example Details Of The AD User Account To Test Words Against

–

Figure 2: Example Details Of The AD User Account To Test Words Against

–

.\AAD-Password-Protection-Check-Custom-AAD-Banned-Word-List.ps1 –accountName <Domain FQDN>\<sAMAccountName> -inputFileWordsFullPath <Input File With Candicate Words To Test>

Figure 3: PowerShell Script That Checks Every Word In The Input File And Reports On It

–

You can download the script from here

–

Have fun!

–

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), Azure AD Password Protection, Blog Post Series, Passwords, Passwords, Replication, Security, SYSVOL, Windows Azure Active Directory | 3 Comments »

« Previous Entries

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!

For Ad Free Blog

Social Media

Profiles

Statistics

Other Cool Blogs

Interesting Places To Visit

The Knowledge Archives

RSS Links

Email Subscription

Categories

Archive for the ‘Passwords’ Category

(2020-03-30) Resetting The Password Of The Special Purpose KrbTgt Account For Azure AD

(2020-02-14) Creating An HTML Report Of All Password And Account Lockout Policies In The AD Forest

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

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

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

(2019-11-06) Azure AD Password Protection (A.k.a. Banned Password List) – Third Party Solution LithNet AD Password Protection (Part 9)

(2019-11-03) Azure AD Password Protection (A.k.a. Banned Password List) – Getting Statistics (Part 8)

(2019-10-29) Azure AD Password Protection (A.k.a. Banned Password List) – From Audit Mode To Enforce Mode (Part 7)

(2019-10-28) Azure AD Password Protection (A.k.a. Banned Password List) – Optimizing The Custom Per Tenant List (Part 6)

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!

For Ad Free Blog

Social Media

Profiles

Statistics

Other Cool Blogs

Interesting Places To Visit

The Knowledge Archives

RSS Links

Email Subscription

Categories

Archive for the ‘Passwords’ Category

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: