It's quite possible to do this. On your Student OU (assuming you have one) set a permission to modify it. To set it up right, in ADU&C, go to the OU object, right click and go to Properties
- On the Security tab, click Advanced
- Add the user
- Select the Properties tab
- Change it to "All Descendant User Objects"
- Check "Read" and "Write" to "UserAccountControl"
That object will now be able to set the account state for all user objects in that OU.
How we've handled this problem is by creating a web application with its own authentication (we use our SSO solution to manage access to it) that handles these requests from your exception-desiring technicians. The web-app then performs the actions with the account created above. The app acts as an auditable proxy for who is unlocking what.
Apple Open Directory does not use the memberOf user attribute (OSX Server 10.7.5).
Instead it solely relies on the memberUid group attribute to enumerate the users which are members of a given group. Therefore one cannot determine a users group memberships by querying the user object, but must instead enumerate all groups for memberUid attributes corresponding to that user, if one wishes a complete list of user specific group memberships.
One can of course modify the schema to add the memberOf attribute, but must then also do the necessary legwork of keeping the group memberUid attribute values and the user memberOf attribute values in sync.
This is in contrast to ldap implementations which support the memberOf user attribute and which contain mechanisms for keeping the values of the attribute pair in sync (Microsoft Active Directory, OpenLDAP with the memberOf overlay).
The [Google Apps Directory Sync Administration Guide][1], page 28, states that:
There are three ways to mark your Google Apps users in LDAP:
• OU: Set up an organizational unit (OU) and move Google Apps users into that unit.
• Group: Create a new group in LDAP, and add Google Apps users as a member of that group.
• Custom Attribute: Create a custom attribute for your users, and set that attribute for new users.
My guess is you could solve the task through either one, but querying users for memberOf only works if you yourself add the memberOf attribute to your user objects. It is to be regarded as a Custom Attribute with Open Directory.
That some attributes are empty in an ldap object is not a great cause for concern, it just means they are included in the ldap schema but their values have not been set for the ldap object. You would see a similar state of things in any out-of-the-box ldap implementation.
[1] http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en/us/support/enterprise/static/gapps/docs/admin/en/gads/admin/gads_admin.pdf
Best Answer
Sometimes a set of yes/no values is stored in a single value by setting various bits. You can use a bitmask to check if they are set.
For example, 546 in decimal is the binary value 10 0010 0010 - in decimal, the sum of 512, 32, and 2. (All those numbers are powers of 2, which means they only have one '1' in their binary representation): That means those three yes/no values are set.
According to the userAccountControl docs that means the following values are set:
However, for example, if you had a user who did not have
PASSWD_NOTREQDset (so their userAccountControl value was 512), or one who also hadDONT_EXPIRE_PASSWORD(65536) set (meaning their value was 66082), you would not find those users in your query.What you need to do is use a bitwise AND in order to query the value of only that bit:
If the value for that bit is 1, then that bit is set. It doesn't matter what the other bits are set to, so you are effectively asking if
userAccountControl & 2 == 2.The LDAP syntax for checking a bit using AND is 1.2.840.113556.1.4.803, therefore you can see if the
ACCOUNTDISABLEbit is set with (userAccountControl:1.2.840.113556.1.4.803:=2). Adding (!(foo)) around it gives you all the users who are not disabled.