Sometimes it necessary to set special permissions on user objects.  For instance when using a Blackberry server, the SendAs permission needs to be set. I see many admins struggle with the setting that permission only to see it disappear within a few hours.  The issue usually on occurs on a few users.  So why is this?  Usually it is always traced back to that user is in a Domain Admin or Enterprise Admins group, or at one time they used to be. 

So why does that make a difference?  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 on 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.  That would be 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 the user attribute that is used for the AdminSDHolder process in the incorrect state.  You need to load ADSIedit.msc and connect to the Domain naming context.  Then navigate the tree to the user in question.  Right click the user and select properties.  The attribute called AdminCount should be set to <Not Set> for all non-admin users.  Select this attribute, click Edit and select Clear.  This should fix this issue.  You may need to set the user object to re-inherit security permissions for the Advanced button under the security tab in AD Users and Computers.

For more information see this Microsoft article: http://support.microsoft.com/kb/817433

Hope this helps.