- Azure PowerShell vs. Azure CLI - Wed, Mar 15 2023
- Use Azure Storage for backup - Thu, Feb 23 2023
- Azure Data Studio vs. SQL Server Management (SSMS) - Wed, Feb 8 2023
With the release of Windows 8 and Windows Server 2012, Microsoft gave us the Windows Store, an online marketplace for "Windows 8 apps." And in case you were wondering: yes, the Windows Store is directly analogous to the Apple Store in OS X.
The availability of Windows 8 apps in the Windows Store is tied to the Microsoft Account, which was formerly known as the Windows Live ID.
The Windows Store
To be sure, the Windows Store and the Microsoft Account present great convenience for the Windows 8 consumer user. However, I dare say that the majority of Windows systems administrators feel differently. For instance, how many of you want to add the following issues to your "worry list"?
- A user downloads a Windows app that compromises the security of your network
- A user purchases a Windows app and files a help desk ticket regarding the app
- A user leverages Microsoft Account data synchronization and inadvertently (or intentionally) copies corporate confidential data to their SkyDrive account in the cloud
No, I certainly don't want to deal with those hassles. Traditionally, we have a service-level agreement (SLA) with our user base such that we deploy and support only authorized applications. Moreover, many of us are under governmental and/or industry regulations that require us to track data access very closely.
Let's learn how to restrict domain user access to the Windows Store and to connected Microsoft Accounts. First, though, let's look at the default behavior.
Default Windows Store settings for domain users
As you probably know, Windows 8 supports three types of user accounts:
- Local user
- Domain user
- Microsoft Account user
Of course, when a Windows 8 computer is joined to an Active Directory domain, our users log onto their systems by using their domain user account. Nevertheless, can a domain user still access the Windows Store and download apps by default?
The answer is yes. As you can see in Figure 2, the domain user is prompted to attach his or her Microsoft Account to their domain credential at the time of app purchase or download.
By default, domain users can access the Windows Store and associate their Microsoft Account credentials.
Restricting user access to the Windows Store
Somewhat surprisingly, you must install the Desktop Experience server feature on your Windows Server 2012 domain controllers in order to see the Windows Store Group Policy setting. I'm not kidding--the setting simply won't appear in your GPO unless and until you install it.
You have to add the Desktop Experience feature on your DC to enable Windows Store Group Policy.
Now we can add the Windows Store policy to our properly scoped Group Policy Object (GPO). The relevant path to the Turn off the Store application policy is:
User Configuration\Policies\Administrative Templates\Windows Components\Store
Enable this policy and propagate Group Policy throughout your domain. When a domain user attempts to launch the Windows Store from the Windows 8 Start Screen, they see he message displayed in the next screenshot.
A domain user is blocked from accessing the Windows Store.
Here are some additional notes with regard to ramifications of disabling user access to the Windows Store:
- The Group Policy does not uninstall any Windows 8 apps that may have already been installed. However, the restriction will prevent those apps from being updated in the future
- You can use Windows InTune or System Center 2012 (among other methods) to deploy your own line of business Windows 8 apps to your users if need be; this process of software installation is referred to as "sideloading"
- Group Policy offers a setting that prevents AD users from removing Windows 8 apps; browse to the GPO location User Configuration\Policies\Administrative Templates\Start Menu and Task Bar and check out the Prevent users from uninstalling applications from Start policy
- It appears that PowerShell scripting is the primary method for removing deployed Windows 8 apps from users' systems for those admins without access to Windows InTune or System Center
Restricting user access to Microsoft Accounts
Now let's turn our attention to preventing users from connecting their Microsoft Account to their Active Directory domain user account. The primary security concern with allowing connected accounts is that Microsoft Accounts are optimized to synchronize user and computer data and configuration settings across multiple devices, potentially including non-domain devices.
To activate the restriction, edit your desired GPO and navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options and open the Accounts: Block Microsoft Accounts policy. I show you this dialog box in Figure 5.
Locking down Microsoft Account usage
As you can see by inspecting the screenshot above, we can either prevent users from linking their Microsoft Account to their domain or local user account, or we can block Microsoft accounts from usage and system logon as well.
When the domain user attempts to link their Microsoft accounts through the Windows 8 PC Settings dialog, they see that the Connect your Microsoft account button is disabled as shown below.
A domain user is unable to connect his Microsoft Account
Want to write for 4sysops? We are looking for new authors.
Hi a There
You do t mention whether this is pro or enterprise edition
Hey Brett. The Group Policy user interface says that the setting is supported on “at least Windows Server 2012, Windows 8 or Windows RT.” I would presume that this means the policy works with Windows 8 “Core,” Professional, and Enterprise. Thanks, Tim
i have updated to the latest ADMX files (from 9-2014) and do not see the block microsoft account option in local policy GPO section. Anyone else on this version and seeing the same? Did MS kill this option with the latest ADMX release?
another comment for updates
Worth noting that you don’t *necessarily* have to install the Desktop Experience on your DC to see these policies. If you’re using RSAT on a Win 8/10 machine, you’ll have the relevant ADMX files there. It’s not necessary to have these on your DC as well. After all the ADMX simple provides a GUI and specifies what reg keys to modify.