I have noticed what appears to be an anomoly in the way that adminSDHolder is applying object permissions and was wondering if anybody else has seen something similar or has a workaround.
We want our internal helpdesk staff to be able to unlock any users account, even privliged accounts that are protected by adminSDHolder 'inheritance'. The HELPDESK group has been give Read/Write permissions on the lockoutTime attribute for User Objects protected by adminSDHolder. However, when members of HELPDESK go to unlock a locked account of this type, the choice is grayed out. (The same permissions given to the same group for accounts not protected by adminSDHolder allow the HELPDESK to unlock those accounts without any problem.) When I look at the permissions applied to the specific user object it shows that the HELPDESK group has Read/Write on the lockoutTime attribute as expected. The only way that members of the HELPDESK group can gain access to the account lockout box is to set the security on a specific account for the lockoutTime READ/WRITE permission to apply to 'This Object' rather than the "User Objects' choice. Unfortunately, when setting the security on the adminSDHolder container, I cannot use the "This object and all child objects" choice because when that is selected, the lockoutTime attribute is not an available option. Rick Bowersox Rockwell Collins "If you cannot convince them, confuse them." ------------------------------------------ Harry S Truman List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
