I think you make a great point here. Actually I'd prefer something like this in the Eventlog:
"Event xxx: AdminSDHolder has detected that the following account does not contain to any administrative groups anymore. Administrative Action is required to set security on this object as intended. Please set the attribute admincount to 0 after justifying the security-settings on this account." You know - the same thing as we get when we didn't backup for a while, when clients log on whos IP doesn't belong to any AD-Subnets, ... one of those maintenance events ;-) Gruesse - Sincerely, Ulf B. Simon-Weidner Profile & Publications: http://mvp.support.microsoft.com/profile=35E388DE-4885-4308- B489-F2F1214C811D Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: Montag, 22. Januar 2007 01:00 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AdminSDHolder orphans Hi Ulf Thanks for the thoughts. I can see there could be issues with trying to revert settings after an object is removed from one of the protected groups. I'm now leaning towards the idea of reporting, rather than taking wholesale action. It would be good to have a canned report that shows all of the objects currently protected by the AdminSDHolder, compared with all those that have an adminCount value of 1 (or higher). An administrator could then make the decision to enable permissions inheritance on a case-by-case basis for objects listed in the second category but not the first. Sounds like a feature Joe should add to one of his many freeware tools. The behaviour would be similar to OldCMP. ;-) Tony -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Monday, 22 January 2007 11:32 a.m. To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AdminSDHolder orphans Hi Tony, late response as well - sorry. I guess why this isn't cleaned up is the same thing as in many other issues. If you have an admin which is in certain operators groups, and he's "loosing" those groups, it's likely that he has been delegated in some other ways. So not reversing the settings the account is still protected from malicious delegated admins and someone with higher privileges has to look at this account and take care of it (e.g. looking if it's still in the right OU). On the other hand - and as the others mentioned - this task of cleaning up should not run as often. And you'll either need to store the previous permissions (we don't have an attribute for this right now), or reset to some default permissions (we don't have a container to store them right now), or force the reset of the inheritance and propagate parent permissions down. Also how would we decide to reset the inheritance flag automatically - there might be accounts in the OU which have on purpose the inheritance flag turned off - so is a prior admin supposed to have inheritance turned on or off in those OUs? I don't think the task of resetting the inheritance flag would be complicated, but it's complicated to generalize that it should be reset in any case. Gruesse - Sincerely, Ulf B. Simon-Weidner Profile & Publications: http://mvp.support.microsoft.com/profile=35E388DE-4885-4308- B489-F2F1214C811D Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: Dienstag, 19. Dezember 2006 02:32 To: [EMAIL PROTECTED] Subject: [ActiveDir] AdminSDHolder orphans Just wanted to get your opinion on something. When an object becomes a member of one of the groups protected by the AdminSDHolder, the next run of the SDProp thread will: Replace the objects security descriptor with that of the AdminSDHolder; Disable permissions inheritance on the object; Set a new adminCount attribute with a value > 0 on the object. If the object is then removed from the protected group(s), the changes made by the AdminSDHolder are not reversed. In other words, the adminCount value remains the same, as does the security descriptor. Is it just me or does anyone think this behaviour a little strange? What I am finding in many environments is a large number of these AdminSDHolder orphans. These can arise quite easily, e.g. an account is made a temporary member of a privileged group to perform a specific task or someone changes role within the organisation. Of course I realise that in a perfect world these scenarios would be minimised by the use of dual accounts for splitting standard vs. admin functions, but the reality is that it is all too common. The AdminSDHolder orphans can cause problems when troubleshooting delegation issues. For example, I came across this issue recently when setting up permissions for GAL Sync using IIFP. I had to tidy up before the sync would complete without errors. Does anyone run a regular cleanup using the script provided in this article (or similar)? http://support.microsoft.com/kb/817433 Do you think the AdminSDHolder behaviour should be changed to clean-up after itself? Tony ________________________________________________________________ Sent via the WebMail system at mail.activedir.org List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx
