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

(2017-05-23) Bug In GPP Registry Wizard Prevents Registry Settings From Applying

In the blog post (2017-03-01) Hardening – Disabling Weak Ciphers, Hashes And Protocols On ADFS, WAP, AAD Connect, Azure AD MFA Server And Azure AD Application Proxy I explain how to harden several hybrid identity related servers. I provide the individual settings and I also provide at the end of the blog post how you can use a GPO to configure all the settings from AD. For the registry settings I configured one server using the REG ADD commands and then I used the Registry Wizard in the GPP to consume all the settings I configured. The GPO I used also contained other regular policy settings.

–

After having all the settings in the GPO as described above, I found out the registry settings specifically never were applied to the servers, although the GPO was being processed. I confirmed processing of the GPO by using GPRESULT remotely and locally. I also looked at the registry settings multiple times to see if I could find any anomalies, but unfortunately I did not see anything strange. Well it took me some time, but if you look very carefully there is something strange to it

Figure 1: Setting Registry Values Through A GPO

–

I’m going to spare you the time that it took me to find what was wrong and guide you through the steps so that you understand where it goes wrong and how you can fix it.

If you look at figure 2 below what are you noticing? Hint: Look at the values in every column!

Correct! The “Hive” column does not have any value specified. THAT is the reason the registry setting is not applied at all to targeted servers

Figure 2: A Sample Registry Setting That Was Read Through The Registry Wizard – Empty Hive Value

–

However, if you open a registry setting for which the “Hive” value is not listed as shown in figure 2, you can see in figure 3, the “Hive” value IS listed. Confusing right?!

Figure 3: A Sample Registry Setting That Was Read Through The Registry Wizard – Populated Hive Value

–

The solution here is to reconfigure the “Hive value and committing the change into the GPO. Bu if you look at the [Apply] button figure 3 you see it is grayed out.

As shown in figure 4 just reselect the already listed “Hive” value.

Figure 4: A Sample Registry Setting That Was Read Through The Registry Wizard – Reselecting The Hive Value

–

After doing that the [Apply] button becomes available to be clicked/pressed.

Figure 5: A Sample Registry Setting That Was Read Through The Registry Wizard – Recommitting The Hive Value

–

After you have clicked/pressed the [Apply] button, you can see the “Hive” value is indeed populated as shown in the figure 6.

Figure 6: Sample Registry Setting That Was Read Through The Registry Wizard – Populated Hive Value For One Setting

–

Now do this for every registry setting read by the wizard

Figure 7: Sample Registry Setting That Was Read Through The Registry Wizard – Populated Hive Value For Another Setting

–

Because the “Hive” value was not specified for the registry settings in the GPO, those same registry settings were not applied, although the GPO that contained them was processed! Respecifying the “Hive” value solved the problem. And yes you will have to do this for every registry setting.

This issue only occurs when you use the Registry Wizard within the GPP and specify a remote server as the target server. If you specify the local server as the target then “Hive” value is populated correctly.

This occurred on both W2K12R2 and W2K16 servers

–

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

(2016-10-13) Namespace Already Defined As The Target Namespace For Another File In The Policy Store

My AD is running W2K12R2 DCs with the corresponding ADMX/ADML files. While preparing it for an updated Windows 10 client (Version 1607, OS build 14393.22) (this was installed ages ago and updated to the latest and greatest using Windows Update), I also decided to update the policy definitions on the central policy store. So I copied the files in the folder “C:\Windows\PolicyDefinitions” on the updated Windows 10 computer to the folder representing the central policy store on a DC (<Drive>:\<folder>\domain\Policies\PolicyDefinitions). SYSVOL replication should take care of the rest.

–

Now after starting the GPMC and targeting any of the GPOs you have for either viewing or editing

…and clicking on the Settings tab followed by clicking the “Show All”, you may see something similar to the following

Figure 1: Error Message About An Already Defined Namespace In Some Other ADMX File

–

…or opening a GPO, you may see something similar to the following

Figure 2: Error Message About An Already Defined Namespace In Some Other ADMX File

–

Figure 3: Error Message About An Already Defined Namespace In Some Other ADMX File

–

Looking at my Windows 10 client, its PolicyDefinitions folder contained the following files:

• LocationProviderAdm.admx (en-US folder contained LocationProviderAdm.adml)
• Microsoft-Windows-Geolocation-WLPAdm.admx (en-US folder contained Microsoft-Windows-Geolocation-WLPAdm.adml)
• WindowsStore.admx (en-US folder contained WindowsStore.adml)

–

After this I also checked my Windows Server 2016 TP5 machine and its PolicyDefinitions folder contained the following files

Looking at my Windows 10 client, its PolicyDefinitions folder contained the following files:

• LocationProviderAdm.admx (en-US folder contained LocationProviderAdm.adml)
• WindowsStore.admx (en-US folder contained WindowsStore.adml)

–

My W2K12R2 DC had initially the following files in the central policy store:

• LocationProviderAdm.admx (en-US folder contained LocationProviderAdm.adml)
• WinStoreUI.admx (en-US folder contained WinStoreUI.adml)

–

After copying the files from the Windows 10 client to the central policy store on the W2K12R2 DC it ended up with the following files:

• LocationProviderAdm.admx (en-US folder contained LocationProviderAdm.adml)
• Microsoft-Windows-Geolocation-WLPAdm.admx (en-US folder contained Microsoft-Windows-Geolocation-WLPAdm.adml)
• WindowsStore.admx (en-US folder contained WindowsStore.adml)
• WinStoreUI.admx (en-US folder contained WinStoreUI.adml)

–

Looking at the end result of the files, it explained the error messages in Figure 1, 2 and 3.

–

The solution to this one in my case:

• Using Notepad++, I compared “LocationProviderAdm.admx” and “Microsoft-Windows-Geolocation-WLPAdm.admx” and found no differences
• I deleted:
• Microsoft-Windows-Geolocation-WLPAdm.admx
• en-US\Microsoft-Windows-Geolocation-WLPAdm.adml
• Using Notepad++, I compared “WindowsStore.admx” and “WinStoreUI.admx” and found differences
• I deleted:
• WinStoreUI.admx (this file was older and contained less data than the other file)
• en-US\WinStoreUI.adml

–

You can also read more about this in the following KB article MS-KBQ3077013 – "’Microsoft.Policies.Sensors.WindowsLocationProvider’ is already defined" error when you edit a policy in Windows

–

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

(2016-06-16) A Change In Group Policy Processing After The Security Update MS16-072

The Security Update MS16-072 changes the way how user GPOs are being processed. If you do not meet pre-requisites, make sure you do before applying the security update!

This applies to every Windows version starting from Windows Server 2008 and Windows Vista and higher!

–

More about this:

• MS16-072: Security update for Group Policy: June 14, 2016
• Microsoft Security Bulletin MS16-072 – Important

–

Symptoms

All user Group Policy, including those that have been security filtered on user accounts or security groups, or both, may fail to apply on domain joined computers.

–

Cause

This issue may occur if the Group Policy Object is missing the Read permissions for the Authenticated Users group or if you are using security filtering and are missing Read permissions for the domain computers group.

–

Resolution

To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:

Add the Authenticated Users group with Read Permissions on the Group Policy Object (GPO).
If you are using security filtering, add the Domain Computers group with read permission.

–

Script

If you want to script this have a look at:

• New Group Policy Patch MS16-072– “Breaks” GP Processing Behavior
• MS16-072 – Known Issue – Use PowerShell to Check GPOs

–

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

(2011-10-23) Best Practices For The Default Domain Policy And The Default Domain Controllers Policy GPOs

Every AD domain since Windows 2000 Server implements two default GPOs being the “Default Domain Policy” GPO and the “Default Domain Controllers Policy” GPO.

–

With regards to the domain related GPOs the following are best practices:

• Create a separate “Custom Domain Policy” GPO and link that also to the AD domain to be applied after the Default Domain Policy.
• Use the “Custom Domain Policy” GPO for all non-default settings you require to use, except for the password policy and account lockout policy settings
• For the password policy and account lockout policy settings still use the “Default Domain Policy” GPO. The reason for that is described in “(2010-09-27) Password Policies And Account Lockout Policies Within An AD Domain (Part 1)” and in “(2010-09-27) Password Policies And Account Lockout Policies Within An AD Domain (Part 2)”

–

With regards to the domain controllers related GPOs the following are best practices:

• Create a separate “Custom Domain Controllers Policy” GPO and link that also to the domain controllers OU to be applied after the Default Domain Policy.
• Use the “Custom Domain Controllers Policy” GPO for all non-default settings you require to use, except for the user rights settings.
• For the user rights settings still use the “Default Domain Controllers Policy” GPO OR you need to duplicate all user rights from the “Default Domain Controllers Policy” GPO into the “Custom Domain Controllers Policy” GPO. However, when installing applications with Domain Admin or Enterprise Admin equivalent permissions, some of those applications may automatically edit the “Default Domain Controllers Policy” GPO  with regards to the user rights without any interaction. It is therefore better to still configure all user rights for domain controllers in the “Default Domain Controllers Policy” GPO. Because of this reason it is pointless to manage user rights settings in a “Custom Domain Controllers Policy” GPO.
• You may need to create an additional GPO that only targets Branch Office DCs through group filtering or WMI filtering so that Branch Office DCs do not register domain-wide SRV records
• You need to create an additional GPO that only targets the DC currently hosting the PDC FSMO role and any candidate DC to host the PDC FSMO role through WMI filtering. You can read more about that in “(2010-09-26) Configuring And Managing The Windows Time Service (Part 1)”, “(2010-09-26) Configuring And Managing The Windows Time Service (Part 2)”, “(2010-09-26) Configuring And Managing The Windows Time Service (Part 3)” and “(2010-09-26) Configuring And Managing The Windows Time Service (Part 4)”.

–

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