Grant read/write to a specific custom AD attribute?

In OpenLDAP, we've got a number of ACLs set up, of the form "If you're
in this group, you can read/write" this attribute on every object". I'm
assuming a Win2003-mode AD server can emulate this, but I'm not sure how
to go about it, especially with the case of custom attributes.

I've done a lot of searching, but most of the examples seem to be for the
general case of allowing an existing group (ie: Authenticated Users) the
ability to control entire objects, or existing stock attributes.

How would I go about it, for example, if I had a custom attribute like
"dalPayGrade" on every user object, and I wanted to have a group like
"Payroll Admins" allowed to read/write that attribute, but nobody else
should be able to see it... including the users themselves?

I think I just need a basic example to get me started.

--
Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/

If you read the MSDN documentation on controlling access in AD, they pretty
much tell you what you need to know. Here are a few basic things:

Any attribute can be ACLed, not just the built in ones
You can use any security principal (SID) to apply the permission to

The details in the ACE in the DACL that define this are the specific flags
determining what type of permission is being granted and the specific GUID
for the attribute that you want to apply the permission to. The GUID in
question is the value of the schemaIDGUID attribute on the attributeSchema
object in the schema partition. It is not the objectGUID of that attribute
(which is different in every directory).

The key with making these types of edits repeatable is to assign a fixed
schemaIDGUID in your LDIF when you add the attribute. If you don't, AD will
happily assign you a random value but then the GUID used for permissions
will be different in every forest where the schema is instantiated. If you
ever look at AD schema extension LDIF files from MS, you'll notice that they
very carefully set the schemaIDGUID at create time so the GUID which match
the published value in MSDN and any tool that wants to hard code these
values can. However, lots of people skip this and end up with a mess.

There are also things called "control access rights" which can take the form
of a "property set" which basically allows you to set permissions on
multiple attributes with a single ACE. This is kind of advanced/extra
credit, but if you'd like grouping features (one ACE controlling access to
multiple permissions) and would like to avoid ACL bloat, these are good
things to use. This is how AD implements those attribute group features you
see in the AD UI's.

The bottom line is that you just need the SID of the security principal and
the schemaIDGUID of the attribute you and can set these types of
permissions.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
<> wrote in message
news:hfm1a8$d4t$...
> In OpenLDAP, we've got a number of ACLs set up, of the form "If you're
> in this group, you can read/write" this attribute on every object". I'm
> assuming a Win2003-mode AD server can emulate this, but I'm not sure how
> to go about it, especially with the case of custom attributes.
>
> I've done a lot of searching, but most of the examples seem to be for the
> general case of allowing an existing group (ie: Authenticated Users) the
> ability to control entire objects, or existing stock attributes.
>
> How would I go about it, for example, if I had a custom attribute like
> "dalPayGrade" on every user object, and I wanted to have a group like
> "Payroll Admins" allowed to read/write that attribute, but nobody else
> should be able to see it... including the users themselves?
>
> I think I just need a basic example to get me started.
>
> --
> Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/