How to use Group Policy to configure the Taskbar in Windows 10

In release 1607 of Windows 10, Microsoft has now introduced a way to configured the Windows 10 taskbar using Group Policy. This feature allows Group Policy administrator to now add or replace the application that appear on the taskbar. This actually is the first time since Windows Vista that a Group Policy administrator has been able to configure the taskbar for a user. Before this you could only configure it by modifying the default users profile, but user would then be able to remove and reconfigured the taskbar however they wanted.

To implement this feature you need to first create an XML file that has the required configuration information. This is actually just an addition to the same XML file you might already have deployed to configure your start menu. In fact the policy setting to apply the taskbar settings is the exact same “Start Layout” policy setting under “Users\Administrator Templates\Start Menu and Taskbar” that was introduced in Windows 8.1.

image

Once you have configured the XML then save it to a network share that has “Authenticated Users” read permission and then point the policy setting to use the XML file you saved at this location.

Below is an example XML that will apply Paint, Microsoft Mail and Command Prompt to the taskbar.

<?xml version=”1.0″ encoding=”utf-8″?>
<LayoutModificationTemplate
xmlns=”http://schemas.microsoft.com/Start/2014/LayoutModification”
xmlns:defaultlayout=”http://schemas.microsoft.com/Start/2014/FullDefaultLayout”
xmlns:start=”http://schemas.microsoft.com/Start/2014/StartLayout”
xmlns:taskbar=”http://schemas.microsoft.com/Start/2014/TaskbarLayout”
Version=”1″>
<CustomTaskbarLayoutCollection>
<defaultlayout:TaskbarLayout>
<taskbar:TaskbarPinList>
<taskbar:DesktopApp DesktopApplicationLinkPath=”%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Accessories\Paint.lnk” />
<taskbar:UWA AppUserModelID=”microsoft.windowscommunicationsapps_8wekyb3d8bbwe!microsoft.windowslive.mail” />
<taskbar:DesktopApp DesktopApplicationLinkPath=”%appdata%\Microsoft\Windows\Start Menu\Programs\System Tools\Command Prompt.lnk” />
</taskbar:TaskbarPinList>
</defaultlayout:TaskbarLayout>
</CustomTaskbarLayoutCollection>
</LayoutModificationTemplate>

As you can see the Microsoft Windows Live Mail is a Universal Windows Application, if you want to pin another UWA like this you can pin it to your start menu and then use the “Export-StartLayout” PowerShell command to get the exact AppUserModelID value for the app you want to pin.

So now you have the XML you want to use and you want to apply it simply configured and apply the “Start Layout” policy (as per above) to the user and they will now get the apps pin’d to the taskbar next time they logon.

image

Note that even though you have added the pinned items to the taskbar you should be aware that they can still un-pin these items. Unlike other policy settings however, they will not come back after the next Group Policy refresh. Instead they will only come back once the XML modification date is changed. The easiest way to do this is to simple open then XML configuration file on the central server and then just save the un-modified file. Note: This feature does not allow you to remove the “Cortana” and “Task View” items using this feature.

For more information about this feature including a complete breakdown of the XML schema check out https://technet.microsoft.com/en-us/itpro/windows/manage/configure-windows-10-taskbar

Remote Server Admin Tool out now for Windows 10

Every time Microsoft releases a new Windows client OS they also release the Remote Server Admin Tools for the client OS and as expect they have done this again for Windows 10 1607. In case you don’t know what Remote Server Admin Tools (a.k.a. RSAT) is, its the full sweet of admin tools that you would normally have available on a Windows Server but packaged to be installed on the client OS. This is a essential for anyone who manages servers as it is important to be able to manage you serves remotely. This is of course particularly important as Windows Server 2016 by default, does not install the GUI thus making this tool not only important but essential.

Of course, one of the tools that is part of this update file is the Group Policy Management Console and as always recommended, its best to use the latest version of the GPMC when editing Group Policy Objects.

So if you do any GPO editing in your environment and you are running Windows 10 then go download it now at  https://www.microsoft.com/en-us/download/details.aspx?id=45520

 

Microsoft Releases ADMX Version History Spreadsheet

With each new release/upgrade/update of Windows there are changes to the group policy settings. ADMX files are of course the way Microsoft publishes most of these new settings and then we as GPO admins normally just update the Central store and we now (presumably) have a superset of the policy setting we had on all our GPOs. However, this is not always the case and Microsoft does occasionally modify and remove group policy settings. An example of this is the recent changes to the Windows 10 version upgrade policy settings which were removed and completely replace between Windows 10 1511 and 1607 (see http://www.grouppolicy.biz/2016/08/windows-update-business-group-policy-changes-windows-10-1607/) .

Historically Microsoft has release a new spreadsheet with each new version of an OS (see http://www.microsoft.com/en-us/download/details.aspx?id=48257 ) which is a good reference to have. But it was still very hard to figure out what settings had been created, updated or deleted from the past versions as there are many thousand of setting that needed to be compared.

Thankfully, Kai Ohnesorge a Premier Field Engineer (PFE) based in Germany has created a “ADMX Version History” spreadsheet that actually tracks all the new, changed and removed settings between versions ADMX files release by Microsoft dating back to Windows Vista. This will certainly be a handy reference guide for any GPO Administrator. For me, I think this will be most valuable when some Group Policy settings have just “disappeared” so I can actually check that this might have actually been the case.

To see the more information about this spreadsheet and for the links to download the file check out https://blogs.technet.microsoft.com/grouppolicy/2016/10/12/admx-version-history/

Securing Credentials for Privileged Access

 

Hello, Paul Bergson back again. I have been on the road a bit more than normal doing security training/POC deliveries (POP-SLAM *1) for our customers related to Pass-the-Hash and credential protection. I have noticed an alarming trend in how credential protection is thought to resolve a customer’s credentials from being compromised. Enterprises that are investing in vaulting software, and not ensuring the users of this vault have workstations that are isolated from internet and e-mail, are being lulled into a false sense of security!

Credential randomization and vaulting software has begun to expand; this is a great step as enterprises move to protect their assets from exposure but accessing the vault, from an insecure workstation, bypasses the protective steps taken to secure these credentials. “Securing privileged access is a critical first step to establishing security assurances for business assets in a modern organization.” *2

By randomizing passwords, the task for an administrator to use these credentials requires them to open the vault and check them out.  As soon as an insecure workstation connects to the vault any of the credentials retrieved can no longer have their integrity assured.  Making matters worse, I have seen administrators want to reduce their trips to the vault by foreseeing possible future activity and copying ALL their privileged accounts to their desktop at the start of their day and pasting them in the clear to an open application such as Notepad.  Capturing pasted credentials to the clipboard or an application is trivial on a compromised workstation.

If an enterprise allows administrators to use their workstation for both unprivileged activities that have public e-mail & internet browsing available as well as remote administration they have NOT increased their credential protection.  All the labor and expense that has been committed to vault and protect credentials has been wasted.

Looking at the example at the end of this document you can see that an engineer without a protected/isolated workstation, that is saving their password locally, can easily have their secrets harvested.  Even if a user is safe and brings up a browser and only reads their password (never placing on the clipboard or into a text based app) the result is the same, the password can be harvested.

An engineer’s workstation should be isolated and protected from any potential malware threats.  Microsoft has a published a document that guides our customers on how to configure their engineer’s workstation.  The guidance is called Privileged Access Workstation (PAW *3).  Customers can use this guidance without any further assistance from Microsoft, to secure their workstations.

A Microsoft PAW implementation won’t require any additional hardware, as long as the current hardware can run a virtualization stack such as Windows 10. So, there should be no new net expense just a requirement to rebuild the user’s/Administrator’s workstation.  If the current workstation is using Win10, it should be fully licensed for the Win10 guests of a PAW implementation, at no additional cost.

“Any user of a Licensed Device, or any device used by a Licensed User; may remotely access up to four Instances of the Software Running in Virtual OSEs or one Instance of the Software Running in one Physical OSE on (a) device(s) dedicated to Customer’s use.”  *4

Why a dedicated workstation?

“The current threat environment for organizations is rife with sophisticated phishing and other internet attacks that create continuous risk of security compromise for internet exposed accounts and workstations.

This threat environment requires an organization to adopt an “assume breach” security posture when designing protections for high value assets like administrative accounts and sensitive business assets. These high value assets need to be protected against both direct internet threats as well as attacks mounted from other workstations, servers, and devices in the environment.”  *5

As a part of protecting credentials within a vault, “Credential Tiering” should also be deployed.  Credential Tiering is a configuration where credentials are only allowed to be used within a predefined Tier.  Tiering will compliment network isolation when the isolation isn’t effective by restricting what administrators can control and where they can log on.

“The Tier model is composed of three levels and only includes administrative accounts, not standard user accounts”.  *6

· Tier 0 – Manage the identity store and a small number of systems that are in effective control of it

o DC’s, PKI, Radius, etc…

· Tier 1 – Manage enterprise servers, services, and applications

· Tier 2 – Manage enterprise desktops, laptops, printers, and other user devices

PAW workstations should only be allowed to extract credentials and manage assets of a single Tier.  This protects against Tier escalation via what an account can manage and control.

Attack scenario example below:

It is trivial to retrieve the password from memory using a debugger, once a host has been compromised.

clip_image001

1. What the heck is a POP-SLAM?

a. http://ift.tt/1MUxuFY

2. http://ift.tt/2dtlG4A

3. Plat blog on PAW

a. http://ift.tt/1TIOre9

4. http://ift.tt/1fkGjhz

5. http://ift.tt/2bqGcmY

6. http://ift.tt/2dtk8HR

Hopefully this has sparked some thought and gotten you to understand that simply purchasing a vault product (Or using our free LAPS tool) isn’t enough to protect your secured credentials. I would suggest folks that aren’t following this guidance to form a plan to protect any workstations that have access to credentials.

from Ask Premier Field Engineering (PFE) Platforms http://ift.tt/2cQuJyR
via IFTTT

Windows Update for Business Group Policy Changes for Windows 10 1607

If you have deployed Windows 10 to your organisation then you might be familiar with the new Group Policy setting that allowed you to defer the upgrade of Windows 10. These policy setting also know as “Windows Update for Business” allows you to delay by up to 8 months the OS upgrade that Microsoft delivers to you via Windows Update (see below).

DeferUpgradesandUpdateGPEdit

DeferUpgradesandUpdate

However, with the release of Windows 10 1607 the Group Policy setting “Defer Upgrade and Updates” has been completely removed and replaced by new policy settings under “Windows Update>Defer Windows Updates” (see below).

DeferUpgradesandUpdateGPEdit1

The two new policy settings called “Select when Feature Update are received” and “Select when Quality Update are received” (see below).

SelectWhenFeatureUpdateAreReceived SelectWhenQualityUpdatesAreReceived

NOTE: Some times when Microsoft release a new OS they might rename the GPO setting but still keep the underlying Registry Key the same. This means that the name of the policy setting has changed but the actually setting is preserved when upgrading. But this is *NOT* the case. Therefore, you might want to go back to your ADMX Group Policy Central store de-configure the “Defer Upgrades and Update” GPO setting before upgrade the policy files.

Alternatively, you could just leave the policy setting configured and do the ADMX upgrade and just live with the “Extra Registry Settings” message in GPMC (See below).

Note: This policy will still apply with the “Extra Registry Settings” will still apply to the Windows 10 1511 build.

Windows Update Extra Registry Keys

Then at a later stage once all your Windows 10 1511 computer have upgrade to 1607 you can either quickly swap the “WindowsUpdate.admx” and “WindowsUpdate.adml” in the central store and then just de-configure the policy setting to clear the above “Extra Registry Settings” message from the policy.