Grant read/write to a specific custom AD attribute?

Discussion in 'Active Directory' started by Guest, Dec 8, 2009.

  1. Guest

    Guest Guest

    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.
    Guest, Dec 8, 2009
    1. Advertisements

  2. Guest

    Joe Kaplan Guest

    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
    Joe Kaplan, Dec 9, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.