I've worked on places where the admins have disabled desktop personalization on Windows for settings like:
- changing desktop background and lock screen images
- local themes - no high contrast for example
What are the risks of these settings?
Changing them to other Windows defaults would pose no security risk.
Allowing people to install fonts or screensavers from third parties poses a HUGE security risk.
However, it's most likely these things are locked down not for security reasons but for conformity reasons. If you are rolling out thousands of computers, less options means less things to troubleshoot down the road. If you cant change the screen contrast, you will never get a phone call to tech support saying that the screen contrast is "broken".
Sometimes blocking desktop personalisation can be a HR issue rather than a security one. For example, if you allow people to set their own backgrounds, sooner or later someone is going to set something that's a bit risque, or that someone else in the organisation finds offensive - meaning you think need to introduce polices about what is and isn't acceptable, and have arguments about all the edge cases. Better to just block it and avoid the whole issue.
Some environments will also use the desktop background to provide information to the user. This might be with something like BgInfo to show system details, or giving administrative accounts a red background to make them stand out, or showing the classifiction level of the system. If you're doing that sort of thing, the obviously you don't want users changing it.
There is a technical reason and a psychological reason to prevent personalisation of an admin account:
Malware used to play with personalization settings to hide their activities - by blocking these changes, the user (the admin) can be more aware of things trying to change the environment. However, it's been years since I've seen malware do this, so I do not know how relevant it is today.
By forcing a "plain" environment, it forces the person into a certain mindset. The admin is reminded that they are on a special-purpose account and that can remind the person about how the account is supposed to be used. If someone changes their admin account to match their user account, it can become easy to forget which account one is on.
It also triggers different behavior. Studies show that when someone dresses like a certain skilled professional (doctor, dentist, mechanic, etc.) the person actually performs better in the technical tasks of that profession, even if the person is not specifically trained in those skills. And it goes both ways. If the skilled professional is not dressed in their typical way, then they score a little worse in the skills that they are trained in. Uniforms really do matter.
So, an "admin" UI helps the person remember to act, and actually act better, as an admin.
Personalisation can be used as a security mitigation.
Namely, it can be a mitigation against picture-in-picture attacks, in which an adversary attempts to trick the user into interacting with an image that pretends to be a trusted operating system window. When the style of the fake window doesn’t match the active system theme (or more generally: when it behaves in a way inconsistent with active personalisations), it will alert the user to the fact that it is not actually a real window. Locking the system theme to the default makes it harder to take advantage of this technique: picture-in-picture attacks are usually performed with the (often by necessity) blind assumption that the user did not change the default theme.
However, this mitigation is useless when the attacker can learn all the relevant personalisations, especially in targetted attacks. For the mitigation to work, it requires the user to be aware of the attack vector and to be able to recognise it. (It also requires applications to honour the user’s personalisations instead of shoving their branding in the user’s face like they so often like to do.) Anecdotal reports seem to indicate the mitigation is not particularly effective even in otherwise ideal circumstances:
“Well, we passed this screenshot around our entire information security department, and nobody could tell it’s a picture-in-picture attack. Can you?” they slid an 8.5×11 color print across the table.
“Of course!” I said, immediately relieved. I quickly grew gravely depressed as I realized the implications of the fact that they couldn’t tell the difference.
“How?” they demanded.
“It’s a picture of an IE7 browser running on Windows Vista in the transparent Aero Glass theme with a page containing a JPEG of an IE7 browser running on Windows XP in the Luna aka Fisher Price theme?” I pointed out.
“Oh. Huh.” they noted.
My thoughts of using browser personalization as an effective mitigation died that day.
Nevertheless, as feeble as this technique is, taking personalisation away denies the user the opportunity to apply it.