Group Policy | Stephen Hackers Blog

26/02/2021

Azure Conditional Access Integration with Google Chrome

By Steve inAzure Security, Cloud Security, Conditional Access, Externsions, Google, Group Policy, Microsoft, Microsoft Azure, Office Apps & Services Tag Azure AD Joined, Azure SignIn, Block, Chrome, Chrome Extension, Google, Join Type, Managed Device, Non Compliant Device, Windows 10 Accounts

Scenario: Anyone using MCAS, Conditional Access, Window 10 Endpoints and Google Chrome.

Challenge: How do you get Google Chrome to be recognised by Azure Conditional Access policies.

Issue : Azure Sign In’s, by default will not see Google Chrome as Azure AD Joined.

Browser = Chrome & Joined Type = [Blank]

However, by default Microsoft Edge does report as Azure AD Joined

Browser = Edge & Joined Type = Azure AD Joined

Solution : chrome://extensions/

Conditions in Conditional Access policy – Azure Active Directory | Microsoft Docs

“For Chrome support in Windows 10 Creators Update (version 1703) or later, install the Windows 10 Accounts extension. This extension is required when a Conditional Access policy requires device-specific details.

To automatically deploy this extension to Chrome browsers, create the following registry key:”

Path HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome\ExtensionInstallForcelist

Name 1

Type REG_SZ (String)

Data ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx

Or Add manually

Extension now appears for Windows 10 Accounts show below

Then the next Azure/265 Sign in with show Azure AD Joined using Google Chrome

29/01/2016

Differences between Roaming Profiles and ProfileimagePath

By Steve inGroup Policy, Microsoft, Microsoft Windows Server 2008, Remote Desktop Services (RDS)

We have and RDS cluster everythings is working fine.

We use roaming profiles, redirection to a share is working as well.

When a user logs on to any RDS node we can see a user folder appear in E:\Users\ of the RDS Server.

When I checked the registry, and i can see 2 keys about profiles :
– you can see that the redirection is OK : Centralprofile (in my exemple \\Sharename\…)
– you can see a ProfileImagePath to E:\Users

So what is :
– A ProfileImagePath ?
– A CentralProfile ?

E:\Users\<username> is the local cache of the roaming profile. I’ve never seen a setting to avoid caching of the profile on the local system entirely.

There is a group policy setting to automatically delete the cached copy upon user logout. It’s under Computer Configuation->Policies->Administrative Templates->System->UserProfiles->Delete cached copies of roaming profiles.

Plus side : This avoids disk space from caching the users profiles

Down side
It will probably increase the logon time as the full profile will have to copy every time.
When testing, this also cleared out the cache from a custom application which didnt right back to the roaming profile.

29/01/2016

Group Policy –Add the Administrator security group to roaming users profiles

By Steve inGroup Policy, Microsoft, Microsoft Windows Server 2008, Remote Desktop Services (RDS)

Tested on Windows 2008 R2

Create a GPO – “Add the Administrator security group to roaming users profiles”

Computer Configuration > Policies > Administrative Templates > System > User Profiles” and applied to Windows XP / 2003 or later.

This setting adds the administrator ACL to the users roaming profile path on the server when it is first created.

Administrator are able to view users profiles without the need to take ownership

Enable this option as soon as possible as this setting does NOT apply retrospectively to existing users profiles as it only applied the administrators group to the profile when the roaming profile when it is created on the server for the first time.

Original detail posted by Alan Burchill

Category Group Policy