(2023-05-18) Test Environments, Snapshots And The SYSVOL Do Not Always Like Each Other (2)

In the following article, I explained a scenario with test environments, where the SYSVOL replication breaks due to the use of snapshots. I also explained how to fix it.

(2023-05-06) Test Environments, Snapshots And The SYSVOL Do Not Always Like Each Other (1)

Now, if you are using snapshots frequently to revert the test environment back to a certain state, fixing the SYSVOL will be part of that whole process. In addition, if you forget to fix the SYSVOL, you are working with a broken SYSVOL while not even realizing it, and that might have an impact one way or another.

Another approach to this problem is to disable the Generation ID process that detects any difference in the Generation ID between the VM and the registration on the computer account. That process is managed by the “Microsoft Hyper-V Generation Counter” (GenCounter) service. That service is not visible in the services.msc, but it is visible through Get-Service CMDlet. The idea is to disable that service on ALL DCs in the AD forest. The best way to achieve that is to configure a GPO in every AD domain, existing or new, that is linked to the “Domain Controllers” OU. That configuration in the GPO, tells every DC (RWDC and RODC) to DISABLE the “Microsoft Hyper-V Generation Counter” (GenCounter) service, but it will not stop it. A reboot of every DC, make sure that service is not started as it has been configured to be disabled. It is therefore a 2 step approach.

However, to configure a service in the System Services section of a GPO, the service itself must exist on the DC. Because the service does exist but is not visible, you can still not configure it through the GPMC. Another way to configure this is to use a registry preference. The downside of configuring this through a registry preference is that it tattoos the registry, meaning it will not be undone when you remove the configuration. When using a service in the System Services, it does not tattoo the system, and because of that it is preferred. Although not visible when you want to configure it, it is visible in the GUI if you want to remove it.

The easiest way to configure this as a service in the System Services section of a GPO, is to use PowerShell. And to help you out I have written some PowerShell code. That code can be found through the following link: Configuring New Or Existing GPO With The GenCounter System Service To NOT Start (i.e., Disable Generation ID)

PS: please make sure to test this first in a test environment. DO NOT use it in any production environment!

That code would need to be used per AD domain and should be executed locally on 1 RWDC per AD domain. Remember, it should be used within all AD domains in the AD forest! Before using the code, configure first the name of either an existing GPO or a new GPO. In case of a new GPO, the code will create that GPO. With either an existing or new GPO, for it configuration to be affective, it must be linked to the Domain Controllers OU.

Just to be sure, a disclaimer: DO NOT USE SNAPSHOTS OR ANYTHING SIMILAR, OR ANY OF THE STEPS ABOVE IN A PRODUCTION ENVIRONMENT, OR ANY PRODUCTION LIKE TEST ENVIRONMENT!
Again: DO NOT DISABLE THE GENERATION ID PROCESS IN A PRODUCTION ENVIRONMENT, OR ANY PRODUCTION LIKE TEST ENVIRONMENT!

Please be aware, that when the Generation ID process is reenabled, after it has been disabled, it will detect a change which will trigger the behavior explained in the first part of the blog post. The fix of that is explained also in that first part.

Now, with a PERSONAL test environment that you use for regular testing of patches/updates, testing of AD features, security testing, scripting, testing AD-related products, used for learning/demoing, etc, etc, it is a common thing to use VM snapshots. The following are common steps in PERSONAL test environments:

• Create and configure DCs and AD as needed
• Shutdown ALL DCs in the AD Forest
• For ALL DCs in the AD Forest, create the snapshot and give it a meaningful name with a date and time
• Boot up ALL or SOME of the DCs in the AD forest
• Do whatever you need to do
• When done, shut down all the DCs that were booted after the snapshot was created, and also revert all those DCs to the same snapshot. ==> Because the generation ID process is disabled, nothing will happen with the SYSVOL as explained.

Do you need to perform updates on the DCs or AD, then follow the next steps:

• Revert ALL DCs in the AD forest to the exact same snapshot as that is the snapshot containing the state of all DCs that all DCs know about each other ==> because the generation ID process is disabled, nothing will happen with the SYSVOL as explained.
• Boot up ALL DCs in the AD forest
• Perform all required updates on either/both the DCs and/or AD
• Shutdown ALL DCs in the AD Forest
• For ALL DCs in the AD Forest, create the snapshot and give it a meaningful name with a date and time
• Delete the previous/older VM snapshot

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

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

Advertisement

(2023-05-06) Test Environments, Snapshots And The SYSVOL Do Not Always Like Each Other (1)

With many test environments, it is a common thing to create and configure a test environment with at least 1 AD domain and probably multiple domain controllers (DCs).

Before explaining what can happen and what all this is about, let’s just go back in time a bit to understand, why things work like they work.

Background

Apparently, one of the common things that occurred in production environments is that some admins created one or more snapshot of one or more virtual DCs before implementing changes, installing hotfixes/updates, and some even used it as a way to recover AD when needed. Another similar action on DCs running on physical hardware is restoring an image that contains the earlier state of the DC. The common cocktail of trouble, that resulted from any of these scenarios after reverting to a previous snapshot, is called USN rollbacks. With USN rollback, all other DCs have a higher USN for the DC that was reverted back through a snapshot. Put differently, the higher USN on the other DCs for the DC that was reverted back through a snapshot means those DCs all think that DC is already up-to-date, but in reality it is not. Updates from other DCs will therefore not replicate to that DC. This means inconsistencies, which in turn means different behavior. Examples of possible different behavior:

1. different results in LDAP queries
2. difference in authentication and authorizations
3. ..and more.

The one and only solution of resolving the issues on a DC with USN rollback? Force demote the DC and clean up its metadata. After that repromote to a new DC.

More information about USN rollback can be found through the following links:

• A Windows Server domain controller logs Directory Services event 2095 when it encounters a USN rollback
• (2006-03-08) Backup And Restore Of Active Directory

The Solution

The quick and easy solution? Stop using snapshots with DCs!

The Microsoft solution? With Windows Server 2012, Microsoft introduced “Virtualization Safeguards For DCs” in both Windows and its hypervisor “Hyper-V”. Other virtualization platforms, like e.g. and amongst others VMWare, also implemented the same mechanism in their hypervisor to offer the same “Virtualization Safeguards For DCs”. The core solution is the support for VM-GenerationID by checking for it and comparing it. The process is explained in figure 1, and examples of events, when a DC is reverted to a certain snapshot state, are displayed in other figures.

Figure 1: The VM-GenerationID Check And Comparison Process

Source: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/virtualized-domain-controller-architecture#safe-restore-detailed-processing

Figure 2: The Detection Of Generation ID And Its Current Value For The VM

Figure 3: The Detection Of Generation ID And Its Current Value For The Computer Account In AD

Figure 4: The Detection Of The Difference Between The Generation ID For The VM And The Generation ID For The Computer Account In AD

A Generation ID change has been detected.

Generation ID cached in DS (old value):
4655303322081246329
Generation ID currently in VM (new value):
9133133598227488399

The Generation ID change occurs after the application of a virtual machine snapshot, after a virtual machine import operation or after a live migration operation. Active Directory Domain Services will create a new invocation ID to recover the domain controller. Virtualized domain controllers should not be restored using virtual machine snapshots. The supported method to restore or rollback the content of an Active Directory Domain Services database is to restore a system state backup made with an Active Directory Domain Services aware backup application.

Figure 5: The Change Of The Invocation ID

The invocationID attribute for this directory server has been changed. The highest update sequence number at the time the backup was created is as follows:

InvocationID attribute (old value):
fd229607-190b-497d-b4a6-db886c407da3
InvocationID attribute (new value):
5b026ded-8c93-4645-a382-548f125d85ae
Update sequence number:
958540

The invocationID is changed when a directory server is restored from backup media, is configured to host a writeable application directory partition, has been resumed after a virtual machine snapshot has been applied, after a virtual machine import operation, or after a live migration operation. Virtualized domain controllers should not be restored using virtual machine snapshots. The supported method to restore or rollback the content of an Active Directory Domain Services database is to restore a system state backup made with an Active Directory Domain Services-aware backup application.

Figure 6: Configuring The Generation ID Value Of The Computer In AD With The Generation ID Value Of The VM Itself

Figure 7: The SYSVOL Being Initialized As Non-Authoritative

When there is a difference detected in VM-GenerationID between what the hypervisor knows and what the DC itself knows, it will trigger the “Virtualization Safeguards For DCs” to protect the AD environment from USN rollback. The following actions occur:

1. The identity of the database instance, a.k.a. the invocationID, is changed (Figure 5)
2. The RID pools the DC knows about are invalidated
3. A new RID pool is requested from the DC with the RID Master
4. The SYSVOL is put in non-authoritative mode by deleting either the NTFRS or DFS-R databases, while at the same time keeping the existing content of the SYSVOL that is used to pre-seed it. (Figure 7)
5. Any more recent changes or new objects in AD on other DCs that do not yet exist, are inbound replicated
6. Any more recent changes or new files in the SYSVOL on other DCs that do not exist yet, are inbound replicated. This, however, does require those other DCs to be either in normal mode, or authoritative mode.

Now after reading this, you might think: “Oh, that’s cool! I can now use snapshots to restore DCs without messing up the DCs or AD”. Well, actually, no! DO NOT DO IT!

The Impact Of The Solution

The “Virtualization Safeguards For DCs” are intended for production DCs. However, DCs are also used in test environments. For the larger TEST environments, the same rules apply as in production environments, as most likely those TEST environments are used by multiple teams, multiple applications and are continuously up and running.

However, if you have a PERSONAL test environment that you use for regular testing of patches/updates, testing of AD features, security testing, scripting, testing AD-related products, used for learning/demoing, etc, etc, it is a common thing to use VM snapshots. The following are common steps in PERSONAL test environments:

• Create and configure DCs and AD as needed
• Shutdown ALL DCs in the AD Forest
• For ALL DCs in the AD Forest, create the snapshot and give it a meaningful name with a date and time
• Boot up ALL or SOME of the DCs in the AD forest
• Do whatever you need to do
• When done, shut down all the DCs that were booted after the snapshot was created, and also revert all those DCs to the same snapshot.

Do you need to perform updates on the DCs or AD, then follow the next steps:

• Revert ALL DCs in the AD forest to the exact same snapshot as that is the snapshot containing the state of all DCs that all DCs know about each other
• Boot up ALL DCs in the AD forest
• Perform all required updates on either/both the DCs and/or AD
• Shutdown ALL DCs in the AD Forest
• For ALL DCs in the AD Forest, create the snapshot and give it a meaningful name with a date and time
• Delete the previous/older VM snapshot

Just to be sure, a disclaimer: DO NOT USE SNAPSHOTS OR ANYTHING SIMILAR, OR ANY OF THE STEPS ABOVE IN A PRODUCTION ENVIRONMENT, OR ANY PRODUCTION LIKE TEST ENVIRONMENT!

Now this looks easy, right? Are there any caveats to using these steps? Yes, there are! Have a look at the Virtualization SafeGuard for DCs in step 4 (the one about the SYSVOL).

Think about it, when reverting all DCs in an AD domain, all those DCs in the AD domain, are in a non-authoritative state and waiting to perform (initial) replication from a DC with either a normal or authoritative SYSVOL. Because all DCs in the AD domain are in a non-authoritative state, there is NO DC with either a normal or authoritative SYSVOL. Oops! The consequences are that all DCs are waiting for each in terms of SYSVOL replication. You might not even notice it immediately, but later on, you might experience weird behavior, like no SYSVOL replication, inconsistent SYSVOL content, inconsistent GPO behavior, etc

The Fix

Either immediately after reverting the snapshot, or later on if still possible, you need to repair the SYSVOL within an AD domain by marking 1 RWDC authoritative for the SYSVOL, and all others, incl RODCs, non-authoritative for the SYSVOL. The RWDC authoritative for the SYSVOL will initialize and mark itself as the primary member of the special and default DFS-R Replication Group called “Domain System Volume” with a DFS-R Replicated Folder called “SYSVOL Share”, while all other RWDCs/RODCs in that same AD domain, will also reinitialize and wait to perform initial replication from an RWDC with either a normal or authoritative SYSVOL.

The steps for this are described in the following blog post: (2011-06-22) Restoring The SYSVOL (Non-)Authoritatively When Either Using NTFRS Or DFS-R (Part 4)

When having multiple DCs in an AD domain, and even multiple AD domains with multiple DCs within the AD forest, that can be quite exhaustive to execute manually. Because of that, I have written some PowerShell code to do this automatically per AD Domain. The code can be executed on any DC, and by default, it will mark the RWDC with the PDC FSMO role as the RWDC with the authoritative SYSVOL, while marking all others as non-authoritative. If you need to have another RWDC to be authoritative, then specify its FQDN in the variable.

The code can be found through the following link: Fixing Broken DFS-R Replication Group (SYSVOL) Replication Between All Replication Group Members While Assigning A Primary Member As Source

PS: please make sure to test this first in a test environment. DO NOT use in any production environment!

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

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

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

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

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

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

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

–

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

At a high level, its features are:

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

–

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

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

–

More information:

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

–

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

–

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

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

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

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

–

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

Modes:

• AUDIT ONLY Mode
• ENFORCE Mode

–

Actions:

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

–

Statistics

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

–

So how many passwords were correctly validated in either mode:

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

–

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

# To Target All RWDCs In The AD Forest

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

OR

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

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

OR

# For All Specified RWDCs

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

–

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

–

Figure 2: GridView Output With The Same Results

–

You can download the script from here

–

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

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

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

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

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:

1. Normalize password
1. all letters in password to lower case (e.g. A->a, B->b, etc.) and compare with banned password list. If true, deny!
2. Replace special characters to normal letters (e.g. @->a, 1->I, etc.) and compare with banned password list. If true, deny!
2. Fuzzy matching –> Check the password against the banned password list taking 1 edit distance into account (e.g. "abcdef" vs. "abcdeg"). If true, deny!
3. Check if password contains:
1. First Name. If true, deny!
2. Last Name. If true, deny!
3. Tenant Name. If true, deny!
4. If still not denied, calculate the score of the password
1. Minimum allowed score for passing is 5 points
2. Check which words on BPL (e.g. motor, cycle, helmet) are in password, assign 1 point for each
1. Found substrings (“m0torcyc1ehelmetU63”) = 1 point each –> 3 points in this example
3. For every remaining individual characters, assign 1 point for each character
1. Found individual characters (“m0torcyc1ehelmetU63”) = 1 point each –> 3 points in this example
4. 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/ ###################
————————————————————————————————————————————————————-

(2019-10-26) Azure AD Password Protection (A.k.a. Banned Password List) – Checking The DC Agent Status (Part 5)

As you deploy RWDCs, you need to make sure all have the Azure AD Password Protection DC Agent installed, and preferably the latest version. Although the Azure AD Password protection Proxy Service component supports autoupgrade, the Azure AD Password Protection DC Agent DOES NOT. It will log an event in the Azure AD Password Protection DC Agent Operational Event Log. With that information you need to download the latest version from here and you can check the version history here. To create a report of RWDCs that have the Azure AD Password Protection DC Agent with some other info, and RWDCs that DO NOT have it installed, what the OS is and if the minimum required .NET Framework version is installed, you can use the following PowerShell script. The script supports, three modes being: forest, domain (specified) and rwdc (specified)! Now be aware that this check script only reports the correct information about an RWDC if the RWDC has been rebooted after the installation of the Azure AD Password Protection DC Agent .

# To Target All RWDCs In The AD Forest

.\AAD-Password-Protection-Install-DC-Agent-Check.ps1 -scope Forest

OR

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

.\AAD-Password-Protection-Install-DC-Agent-Check.ps1 -scope Domain -domains <FQDN Domain 1>,<FQDN Domains 2>,<FQDN Domain N>

OR

# For All Specified RWDCs

.\AAD-Password-Protection-Install-DC-Agent-Check.ps1 -scope RWDC -servers <FQDN RWDC 1>,<FQDN RWDC 2>,<FQDN RWDC N>

–

  

Figure 1: Creating A Report Of RWDCs With And Without The Azure AD Password Protection DC Agent Before The Reboot (Scope: Forest)

–

Figure 2: GridView Output Before The Reboot

–

Based upon the output displayed above I can say the following:

• This is a disconnected AD forest with no connection to Azure AD. That’s why some RWDCs that are all green still have “Not Registered/Unknown” for the Azure AD Tenant.
• For all those cases where you can see the version installed and the version registered do not match (“Not Registered/Unknown”), that’s because those RWDCs have not been rebooted yet after installing the Azure AD Password Protection Agent for the first time!
• For all those cases where you can see the version installed and the version registered do not match (numeric version mismatch), that’s because those RWDCs have not been rebooted yet after upgrading the Azure AD Password Protection Agent

–

After rebooting all RWDCs, it looks like:

Figure 3: Creating A Report Of RWDCs With And Without The Azure AD Password Protection DC Agent After The Reboot (Scope: Forest)

–

Figure 4: GridView Output After The Reboot

–

 

Figure 5: Creating A Report Of RWDCs With And Without The Azure AD Password Protection DC Agent (Scope: Domain)

–

Figure 6: Creating A Report Of RWDCs With And Without The Azure AD Password Protection DC Agent (Scope: RWDC)

–

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

(2019-10-24) Azure AD Password Protection (A.k.a. Banned Password List) – Deploy The DC Agent (Part 4)

In addition to configure Azure AD, the Azure AD Password Protection DC Agent needs to be installed on every writable domain controller in the AD domain. As read-only domain controllers do not process passwords by themselves, there is no need to install Azure AD Password Protection DC Agent on them. The Azure AD Password Protection DC Agent is nothing more than a password filter that will evaluate the password provided by the user.

To install the Azure AD Password Protection DC Agent, you can use the following PowerShell code which will configure a log file and some nice output. For additional requirements, please see Azure AD Password Protection – Deployment Requirements. Please be aware that the following PowerShell script target RWDCs based upon the scope (forest, domain, rwdc) you define in the parameters. With the forest scope it will enumerate all AD domains in the AD forest and then for every AD domain enumerate all writable domain controllers and try to install the software on each writable domain controller. With the domain scope it will enumerate all RWDCs of the specified AD domains and try to install the software on each writable domain controller. With the rwdc scope it will target the specified RWDCs. In all cases it will if Enterprise Admin credentials are available. If will always check if an AD domain or RWDC actually exists and in the latter case it will also check if it can connect to the RWDC. Installing the DC Agent requires a restart of the targeted RWDC(s). The code DOES NOT do that. You still need to do that by yourself! As an added bonus it checks if the minimum required .NET Framework is installed or not.

To download the latest version: Azure AD Password Protection for Windows Server Active Directory

To read about the version history and release notes: Azure AD Password Protection agent version history

# For All RWDCs In The AD Forest

.\AAD-Password-Protection-Install-DC-Agent.ps1 -scope Forest -installSourceFullPath "<Full Path To AzureADPasswordProtectionDCAgentSetup.msi>"

OR

# For All RWDCs In The Specified AD Domain(s)

.\AAD-Password-Protection-Install-DC-Agent.ps1 -scope Domain -domains <FQDN Domain 1>,<FQDN Domains 2>,<FQDN Domain N> -installSourceFullPath "<Full Path To AzureADPasswordProtectionDCAgentSetup.msi>"

OR

# For All Specified RWDCs

.\AAD-Password-Protection-Install-DC-Agent.ps1 -scope RWDC -servers <FQDN RWDC 1>,<FQDN RWDC 2>,<FQDN RWDC N> -installSourceFullPath "<Full Path To AzureADPasswordProtectionDCAgentSetup.msi>"

–

Figure 1: Installing The Azure AD Password Protection DC Agent (Scope: Forest)

–

Figure 2: GridView Output

–

Figure 3: Installation Log File Sample

–

Figure 4: Installing The Azure AD Password Protection DC Agent (Scope: Domain)

–

Figure 5: Installing The Azure AD Password Protection DC Agent (Scope: RWDC)

–

You can download the script from here

–

Unlike what the version history says, Azure AD Password Protection DC Agent software still uses an MSI. Nevertheless, the PowerShell code supports both an EXE and an MSI. The Azure AD Password Protection DC Agent does not support automatic upgrade like the Azure AD Password Protection Proxy Service does. However, the Azure AD Password Protection DC Agent will log an event ID 30034 in the Azure AD Password Protection DC Agent Operational Event Log mentioning there is a newer version available. You can then use this script if you want to redeploy/upgrade the Azure AD Password Protection DC Agent.

–

And if you require to UNinstall the Azure AD Password Protection DC Agent, then you can use the following on a single RWDC (I only provide the code and no script. However, if you want to you can leverage the code and logic above to execute the part below instead!)

WMIC PRODUCT WHERE NAME="Azure AD Password Protection DC Agent" CALL UNINSTALL

OR

$product = Get-WmiObject -Class win32_product -Filter "Name like ‘Azure AD Password Protection DC Agent’"

$product

$product.Uninstall() # WARNING: Reboot is immediate, no mercy and no questions asked!!!

–

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

(2019-10-22) Azure AD Password Protection (A.k.a. Banned Password List) – Deploy The Proxy Service (Part 3)

As it is not desirable to have DCs communicate directly with anything on the internet, the Azure AD Password Protection solution provides a Azure AD Password Protection Proxy Service that acts as an intermediate between the Azure AD Password Protection DC Agents on the DCs and Azure AD. Per AD forest you can implement 2 servers with the Azure AD Password Protection Proxy Service installed.

To install the Azure AD Password Protection Proxy Service, you can use the PowerShell script which will configure use a log file and some nice output. For additional requirements, please see Azure AD Password Protection – Deployment Requirements.

To download the latest version: Azure AD Password Protection for Windows Server Active Directory

To read about the version history and release notes: Azure AD Password Protection agent version history

.\AAD-Password-Protection-Install-Proxy-Service.ps1 –servers <FQDN Server 1>,<FQDN Server 2> -installSourceFullPath "<Full Path To AzureADPasswordProtectionProxySetup.exe>"

–

Figure 1: Installing The Azure AD Password protection Proxy Service

–

Figure 2: GridView Output

–

Figure 3: Installation Log File Sample

–

You can download the script from here

–

Just before version 1.2.116.0 Azure AD Password Protection Proxy Service software was an MSI and starting with that version it is an EXE. That’s why the code above supports both.

With version 1.2.116.0 and higher the Azure AD Password Protection Proxy Service software supports automatic upgrade, which is enabled by default.

Figure 2: Checking The Azure AD Password Protection Proxy Service Configuration

–

To disable automatic upgrade, you can use the following command:

Set-AzureADPasswordProtectionProxyConfiguration -AutoUpgradeEnabled $false

… and to enable it again:

Set-AzureADPasswordProtectionProxyConfiguration -AutoUpgradeEnabled $true

–

If auto upgrade is disabled, the Azure AD Password Protection Proxy Service will log an event ID 20002 in the Azure AD Password Protection Proxy Service Operational Event Log mentioning there is a newer version available. With auto upgrade enabled, nothing is logged about a newer version.

–

After installing the Azure AD Password Protection Proxy Service for the first time or after installing version 1.2.116.0 or higher, you need to (re-)register both the Azure AD Password Protection Proxy Service and the on-premises AD forest in Azure AD.

To register the Azure AD Password Protection Proxy Service in Azure AD:

$adAdminAccount = Get-Credential

$aadAdminAccount = Get-Credential

Register-AzureADPasswordProtectionProxy -ForestCredential $adAdminAccount -AzureCredential $aadAdminAccount

If you are already logged on with an Enterprise Admin account for AD, then register the Azure AD Password Protection Proxy Service in Azure AD as follows:

$aadAdminAccount = Get-Credential

Register-AzureADPasswordProtectionProxy -AzureCredential $aadAdminAccount

To register the on-premises AD forest in Azure AD:

$adAdminAccount = Get-Credential

$aadAdminAccount = Get-Credential

Register-AzureADPasswordProtectionForest -ForestCredential $adAdminAccount -AzureCredential $aadAdminAccount

If you are already logged on with an Enterprise Admin account for AD, then register the on-premises AD forest in Azure AD as follows:

$aadAdminAccount = Get-Credential

Register-AzureADPasswordProtectionForest -AzureCredential $aadAdminAccount

–

And if you require to UNinstall the Azure AD Password Protection Proxy Service, then you can use the following

WMIC PRODUCT WHERE NAME="Azure AD Password Protection Proxy" CALL UNINSTALL

OR

$product = Get-WmiObject -Class win32_product -Filter "Name like ‘Azure AD Password Protection Proxy’"

$product

$product.Uninstall() # WARNING: Reboot is immediate, no mercy and no questions asked!!!

–

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