Welcome to Port3101.org : Your BES Connection Mark forums read | View Forum Leaders
Port3101.org : Your BES Connection



Reply
LinkBack (20) Thread Tools Display Modes
AdminSDHolder - or where did my permissions go?
 
  20 links from elsewhere to this Post. Click to view. #1 (permalink)  
Old 01-31-2009, 01:01 AM
hdawg's Avatar
Proprietor
 
Join Date: Nov 2008
Posts: 2,257
Blog Entries: 147
Default AdminSDHolder - or where did my permissions go?

Taken from - AdminSDHolder - or where did my permissions go? - Directory Services/Active Directory (thanks hdawg)

RIM will point you to BlackBerry - Send As Issue ... but here is an explanation as to WHY.

Any security best practice will always recommend you grant permissions observing the Principle of least privilege.

----------
AdminSDHolder - or where did my permissions go?

I recently had a customer who had an issue which is by design, but not well known to every AD Administrator. So I decided to summarize some info about it.

Symptom
Usually you delegate permission in Active Directory via OUs. Those permissions apply (if configured so) to objects like users underneath that OU. However you may experience that they don't apply to all user-accounts (e.g. a delegated admin is able to change the phonenumber for most users, but not on a few others), or that the permissions are being reset/lost on some accounts. If you look at the permissions of that user-account you'll find that the accounts security-descriptor is set not to inherit permissions from parent objects. If you set the security-descriptor to inherit permissions again, you'll see that this will be reset after a while. If you configure permissions directly on the object they will be reset after a while as well.

Reason
Active Directory protects certain accounts not to inherit delegated permission. This behavior applies to direct and nested members of the following security-groups:

Windows 2000 SP3:
Enterprise Admins
Schema Admins
Domain Admins
Administrators

Windows 2000 SP4 oder Windows Server 2003 additional:
Account Operators
Server Operators
Print Operators
Backup Operators
Cert Publishers

Additional the accounts Administrator and krbtgt are protected.

Why are those accounts protected?
Delegation via AD permissions is usually used to delegate administrative rights to regular user-accounts, to implement administrative roles like Site-Administrator. Those might be assigned to reset passwords, deactivate accounts or other tasks. The AdminSdHolder-Thread assures that such an administrative roles gains not more permissions or is able to compromise the privileged accounts.

How are those accounts protected?
The AdminSdHolder/Ds Propagator tread modifies all accounts which are direct or nested members of one of those groups and increases the attribut adminCount to a value higher than 0. This thread runs once an hour on the Domaincontroller holding the PDC-Emulator role. The thread further resets the security-descriptor of those accounts with the default permissions for administrative accounts which is defined by the security-descriptor of the object cn=AdminSdHolder,cn=System,dc=yourdomain,dc=com. This also resets the flag to disable inheritance of parent objects.

But what can I do if I need different permissions?
If you need different permissions on those accounts there are a few approaches you can take:
  • Usually you should avoid using administrative accounts for the daily routine. Use a regular user-account, and just start administrative applications (such as Active Directory-Users and -Computers) with administrative credentials (via RunAs or Context-Menu, Open withů).
    Active Directory enabled applications or Site-Admins would be able to change the regular user-account of the Administrators, which is usually sufficient, but their administrative accounts are protected. This protects the Administrator from administrative errors of delegated administrators, and he's further protected against virusses/worms when surfing the web/reading e-mail.
  • You could use a domain-admin account for AD-enabled applications: This would be a solution, but should be avoided whenever possible. It's quite easy to delegate AD-integrated applications only write-permissions to the attributes they need, so use that feature to protect your AD. Many times those applications only need permissions to add/modify/delete objects which are defined by their schema extension, and write-permissions on attributes on existing objects their schema extension also added.
  • If absolutely necessary you are able to change the default permissions on administrative accounts to reflect the need of those applications. You can easily do this by modifying the permissions on cn=AdminSdHolder,cn=System,dc=yourdomain,dc=com. This can be accomblished using ADSIEdit.msc or DsAcls.exe. DsAcls is a commandline-tool for modifying AD-permissions, which every administrator who delegates rights in AD should know. Be sure to test in advance which attributes of which objects are being modifies by the application.

What else is important to know?
  • AdminSdHolder also applies the permissions to accounts which are nested members through distribution groups. E.g. if User1 is a member of the distribution group Maillist-KnowHow, which is a member of account operators, then User1 is considered as one of the protected accounts (since the distribution group could be converted to a security group).
    Be aware that the command whoami /all does show nested group memberships, but not nested groups through distribution groups.
    Usually you should avoid nesting distribution groups in one of the protected groups.
  • Users, which are removed out of one of the protected groups (or their nested groups) do not inherit permissions from parent objects. You need to check the box to inherit permissions when removing those users out of the group manually, or use a script to check your users.
  • If you have many accounts which are protected by the AdminSdHolder/DS Propagation-Thread, you might notice that the lsass-process on the Domaincontrller holding the PDC-Emultor raises to 100% once an hour. Therefore you should avoid putting loads of users in the protected groups, and rather use delegated administration whenever possible.
  • Depending on your need you might want to remove Backup Operators, Printer Operators, Server Operators or Account Operators out of the AdminSdHolder protection. You can get a Hotfix at Microsoft PSS which allows to configure that. See the following KB for more informations on that:
    http://support.microsoft.com?id=817433


More Information: http://search.microsoft.com/search/results.aspx?qa=adminsdholder+admincount
__________________
http://blog.port3101.org/hdawg/
Reply With Quote
Sponsored Links
  #2 (permalink)  
Old 10-21-2009, 03:08 AM
BES Activated
 
Join Date: Oct 2009
Location: india
Posts: 1
Default hi

I am having the same issue, excpet the users that are not inheriting permissions are not members of any admin group. They actually are just random members of different OU's, with no common denominator. The way that I discovered this issue was that one of our helpdesk employees, who is not a member of an admin group, can make changes on most of the user accounts, but some she cannot. When I checked on it, the group she is a member of is not located on the security tab of these users and the permissions are not inheriting, while 95% of the other users in these same OU's are inheriting. Make sense?
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is On
Trackbacks are On
Pingbacks are On
Refbacks are On


LinkBacks (?)
LinkBack to this Thread: http://www.port3101.org/blackberry-server-faq/428-adminsdholder-where-did-my-permissions-go.html
Posted By For Type Date
Best practice bes user/domain admin rights This thread Refback 04-04-2011 01:30 PM
One way Calendar Tips/Fixes This thread Refback 02-18-2011 06:37 PM
Calendar sync problem with one user - BlackBerryForums.com : Your Number One BlackBerry Community This thread Refback 09-17-2009 04:49 PM
Calendar sync problem with one user - BlackBerryForums.com : Your Number One BlackBerry Community This thread Refback 09-15-2009 02:57 PM
Calendar sync problem with one user - BlackBerryForums.com : Your Number One BlackBerry Community This thread Pingback 09-14-2009 08:48 PM
Untitled document This thread Refback 08-20-2009 03:43 PM
Domain Admin, Send As, and Red X issue - BlackBerryForums.com : Your Number One BlackBerry Community This thread Refback 08-17-2009 01:24 PM
Tried to install Blackberry Professional Server, but failed. - BlackBerryForums.com : Your Number One BlackBerry Community This thread Pingback 08-12-2009 09:44 PM
Untitled document This thread Refback 08-04-2009 12:23 PM
Untitled document This thread Refback 07-15-2009 02:27 PM
Untitled document This thread Refback 07-03-2009 09:20 AM
Untitled document This thread Refback 07-01-2009 01:07 PM
Untitled document This thread Refback 07-01-2009 08:19 AM
Untitled document This thread Refback 06-26-2009 10:53 AM
Untitled document This thread Refback 06-25-2009 11:57 AM
Untitled document This thread Refback 06-22-2009 09:27 PM
Unable to reply or send emails - BlackBerryForums.com : Your Number One BlackBerry Community This thread Refback 06-05-2009 02:24 PM
BPS Sync issues - BlackBerryForums.com : Your Number One BlackBerry Community This thread Pingback 06-02-2009 10:29 AM
one way calendar sync - BlackBerryForums.com : Your Number One BlackBerry Community This thread Refback 06-02-2009 09:38 AM
Email Redirection and Attachment Opening stops - BlackBerryForums.com : Your Number One BlackBerry Community This thread Pingback 06-02-2009 09:06 AM

Similar Threads
Thread Thread Starter Forum Replies Last Post
BES 5.0 And Telenav Application Permissions bbg Port 3101: The BES Admin Bar & Grill 5 03-06-2011 01:52 PM
BESadmin permissions wont propogate down sp33d Port 3101: The BES Admin Bar & Grill 2 01-12-2010 12:29 PM
Disabling Application Permissions adambullied Port 3101: The BES Admin Bar & Grill 3 12-21-2009 03:35 PM
Send As permissions... what went wrong? bdunnuck Port 3101: The BES Admin Bar & Grill 8 02-02-2009 11:33 AM


All times are GMT -4. The time now is 11:41 PM.
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.


 

SEO by vBSEO 3.3.2 PL2