Easily upload multiple users’ photos to Office 365. Manage them with an intuitive GUI and use handy built-in cropping and resizing options. Link photos with users based on Azure AD attributes. Free tool!
So why is this happening only on a few users?
When a user is placed in an Admin groups such as Domain Admins, AD tries to protect the security of that user object. It does this by explicitly setting the security of that object as opposed to inheriting the security as it usually does for regular users. This prevents someone from delegating access on a container that contains a Domain/Enterprise Admin user and thus providing access to a admin user object. For instance, if you wanted to allow a helpdesk to change passwords or delete users in a OU, you can delegate that. If your admin user was in that OU, the helpdesk could conceivably change your password or delete your account. Not good.
So where does the implicit security come from?
It comes from the AdminSDHolder object in the System container. The security permissions of the AdminSDHolder object are set on all Admin accounts explicitly. The object name kind of makes sense (Admin Security Descriptor Holder). AD applies these permissions every few hours to Admin objects. so someone can turn on inheritance and set explicit permissions on a Admin object, but AD will re-apply the AdminSDholder object permissions overtop of it again, thus restoring security.
So how do I set specific permissions for an Admin user?
One way would be to modify the permissions of the AdminSDholder object(https://technet.microsoft.com/en-ca/library/cc772662(v=ws.10).aspx). This is normally a bad idea, and I wouldn't recommend it. A better way would be to remove the person from the Admin group and give them a second account for admin purposes. It is best practice not to mail enable an Admin account anyhow. Users shouldn't use their day to day account for admin purposes.
I removed the user from the Admin group, but the permission is still being removed. Why?
This is because AD keeps a user attribute called adminCount that is used for the AdminSDHolder process in the incorrect state. To correct this:
For more information this Microsoft articles discusses the delegated permissions and the AdminSDHolder object : https://support.microsoft.com/en-us/help/817433/delegated-permissions-are-not-available-and-inheritance-is-automatical
This article discusses Protected accounts and the adminCount attribute:
Hope this helps.
|The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR||1,306|
|How to manage local account passwords from Active Directory without LAPS||657|
|Protecting Active Directory Credentials Amidst New Threats [VIDEO]||681|
|Active Directory Cleanup Tool (ADCleanup)||935|