Creating new schema object

Archived from groups: microsoft.public.win2000.active_directory (More info?)

I have registered a new X.500 Schema Prefix and Root OID for use in active
directory. I have created a new attribute using these values, linked this
attribute to the user class as an optional attribute, and everything is
replicated as it should be.

I have now begun testing of an application that writes some simple string
values to this attribute (the code works correct, it's been taken from a
production application) when non administrative users try to write to this
new attribute in AD, I get the following error -2147024891, General Access
Denied. This is "fixable" by giving the user domain administrative rights,
which is completely NOT acceptable.

what do I have to do in order to grant regular domain users the ability to
write data to this attribute (in their own user account, not for other
users)??

Thanks.
6 answers Last reply
More about creating schema object
  1. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    Change the permission for the particular attribute within the schema
    manager, ADSI Edit or with the dsacls tool.

    --
    Regards
    Christoffer Andersson
    Microsoft MVP - Directory Services

    No email replies please - reply in the newsgroup
    ------------------------------------------------
    http://www.chrisse.se - Active Directory Tips

    "Brian Higgins" <brian@-NO-accentconsulting-SPAM-.com> skrev i meddelandet
    news:%23q0Q5tQIFHA.2640@TK2MSFTNGP09.phx.gbl...
    >I have registered a new X.500 Schema Prefix and Root OID for use in active
    >directory. I have created a new attribute using these values, linked this
    >attribute to the user class as an optional attribute, and everything is
    >replicated as it should be.
    >
    > I have now begun testing of an application that writes some simple string
    > values to this attribute (the code works correct, it's been taken from a
    > production application) when non administrative users try to write to this
    > new attribute in AD, I get the following error -2147024891, General Access
    > Denied. This is "fixable" by giving the user domain administrative
    > rights, which is completely NOT acceptable.
    >
    > what do I have to do in order to grant regular domain users the ability to
    > write data to this attribute (in their own user account, not for other
    > users)??
    >
    > Thanks.
    >
  2. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    Actually attributes don't have a default SD, the default SD is on classes.

    The two solutions would be to modify the default SD on the user object or better
    yet, add an inherited ACE to the OU where the objects are that allows the
    specified group of people to modify the attribute. If the attribute should be
    modified by the user's themselves, I.E. I should be able to update this new
    attribute only on my own object, I could either set a SELF WP ACE for that
    attribute on the OU structure or I could add the attribute to the personal
    information property set.

    --
    Joe Richards Microsoft MVP Windows Server Directory Services
    www.joeware.net


    Chriss3 [MVP] wrote:
    > Change the permission for the particular attribute within the schema
    > manager, ADSI Edit or with the dsacls tool.
    >
  3. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    If I understood both of you correctly, I have 2 options, 1, make a new
    class, and set the permissions on the class (where it should be relatively
    easy to do?), and then make that class a sub class of the user class, or 2,
    modify the ACL on the attribute and grant permissions accordingly (sounds
    like the better option, but sounds more difficult?)

    do you have any references to point me at for this? this is the first time
    I've worked with modifying the schema in any way, and could use a few
    pointers. Thanks.


    "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
    news:uOh8HwZIFHA.2656@TK2MSFTNGP09.phx.gbl...
    > Actually attributes don't have a default SD, the default SD is on classes.
    >
    > The two solutions would be to modify the default SD on the user object or
    > better yet, add an inherited ACE to the OU where the objects are that
    > allows the specified group of people to modify the attribute. If the
    > attribute should be modified by the user's themselves, I.E. I should be
    > able to update this new attribute only on my own object, I could either
    > set a SELF WP ACE for that attribute on the OU structure or I could add
    > the attribute to the personal information property set.
    >
    > --
    > Joe Richards Microsoft MVP Windows Server Directory Services
    > www.joeware.net
    >
    >
    > Chriss3 [MVP] wrote:
    >> Change the permission for the particular attribute within the schema
    >> manager, ADSI Edit or with the dsacls tool.
    >>
  4. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    Honestly I would avoid touching the schema. My personal favorite is a schema
    with no Default SDs so any object instantiated just has permissions granted to
    it through inheritence, it is MUCH easier to track down issues that way.

    This adding of inherited ACEs is basic AD delegation. You want people to modify
    their own samaccountname in some OU, you go to that OU and grant WP (Write
    property) to sAMAccountName for user objects to Self.

    A good book for all of this stuff overall is Inside Active Directory, 2E by
    Sakari and Mike. Great book, especially in terms of security and schema stuff. I
    was recommending that book shortly after the first edition came out. I was a
    technical reviewer/editor for the second edition so I am also behind that one.


    joe

    --
    Joe Richards Microsoft MVP Windows Server Directory Services
    www.joeware.net


    Brian Higgins wrote:
    > If I understood both of you correctly, I have 2 options, 1, make a new
    > class, and set the permissions on the class (where it should be relatively
    > easy to do?), and then make that class a sub class of the user class, or 2,
    > modify the ACL on the attribute and grant permissions accordingly (sounds
    > like the better option, but sounds more difficult?)
    >
    > do you have any references to point me at for this? this is the first time
    > I've worked with modifying the schema in any way, and could use a few
    > pointers. Thanks.
    >
    >
    >
    > "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
    > news:uOh8HwZIFHA.2656@TK2MSFTNGP09.phx.gbl...
    >
    >>Actually attributes don't have a default SD, the default SD is on classes.
    >>
    >>The two solutions would be to modify the default SD on the user object or
    >>better yet, add an inherited ACE to the OU where the objects are that
    >>allows the specified group of people to modify the attribute. If the
    >>attribute should be modified by the user's themselves, I.E. I should be
    >>able to update this new attribute only on my own object, I could either
    >>set a SELF WP ACE for that attribute on the OU structure or I could add
    >>the attribute to the personal information property set.
    >>
    >>--
    >>Joe Richards Microsoft MVP Windows Server Directory Services
    >>www.joeware.net
    >>
    >>
    >>Chriss3 [MVP] wrote:
    >>
    >>>Change the permission for the particular attribute within the schema
    >>>manager, ADSI Edit or with the dsacls tool.
    >>>
    >
    >
    >
  5. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    I can not find any place to edit the security on a specific attribute, be it
    through delegation or whatnot. I have the attribute already created and
    showing up for each user as an available property(verified with ADSI edit,
    and I can read the values from that property through ADSI scripting),
    everything works exactly as I need, except for that I need to give regular
    users the ability to write to this property of their account, without going
    and granting specific permissions for each user, as this is going to be used
    for hundreds of users across multiple domains, so I need a way to set this
    up at the domain level so that all users in the domain will inherit the
    permissions.

    "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
    news:OVvPZtnIFHA.2656@TK2MSFTNGP09.phx.gbl...
    > Honestly I would avoid touching the schema. My personal favorite is a
    > schema with no Default SDs so any object instantiated just has permissions
    > granted to it through inheritence, it is MUCH easier to track down issues
    > that way.
    >
    > This adding of inherited ACEs is basic AD delegation. You want people to
    > modify their own samaccountname in some OU, you go to that OU and grant WP
    > (Write property) to sAMAccountName for user objects to Self.
    >
    > A good book for all of this stuff overall is Inside Active Directory, 2E
    > by Sakari and Mike. Great book, especially in terms of security and schema
    > stuff. I was recommending that book shortly after the first edition came
    > out. I was a technical reviewer/editor for the second edition so I am also
    > behind that one.
    >
    >
    > joe
    >
    > --
    > Joe Richards Microsoft MVP Windows Server Directory Services
    > www.joeware.net
    >
    >
    > Brian Higgins wrote:
    >> If I understood both of you correctly, I have 2 options, 1, make a new
    >> class, and set the permissions on the class (where it should be
    >> relatively easy to do?), and then make that class a sub class of the user
    >> class, or 2, modify the ACL on the attribute and grant permissions
    >> accordingly (sounds like the better option, but sounds more difficult?)
    >>
    >> do you have any references to point me at for this? this is the first
    >> time I've worked with modifying the schema in any way, and could use a
    >> few pointers. Thanks.
    >>
    >>
    >>
    >> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
    >> news:uOh8HwZIFHA.2656@TK2MSFTNGP09.phx.gbl...
    >>
    >>>Actually attributes don't have a default SD, the default SD is on
    >>>classes.
    >>>
    >>>The two solutions would be to modify the default SD on the user object or
    >>>better yet, add an inherited ACE to the OU where the objects are that
    >>>allows the specified group of people to modify the attribute. If the
    >>>attribute should be modified by the user's themselves, I.E. I should be
    >>>able to update this new attribute only on my own object, I could either
    >>>set a SELF WP ACE for that attribute on the OU structure or I could add
    >>>the attribute to the personal information property set.
    >>>
    >>>--
    >>>Joe Richards Microsoft MVP Windows Server Directory Services
    >>>www.joeware.net
    >>>
    >>>
    >>>Chriss3 [MVP] wrote:
    >>>
    >>>>Change the permission for the particular attribute within the schema
    >>>>manager, ADSI Edit or with the dsacls tool.
    >>>>
    >>
    >>
  6. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    Because you aren't editing the security on a specific attribute. You are editing
    the security on objects and saying that people can modify that specific
    attribute on the objects.

    At the domain NC Level or at the OU level where you keep your users for each
    domain, simply add a SELF WP ACE for the attribute on user objects. You should
    be able to do that with adsiedit or dsacls.

    A dsacls command would look something like

    dsacls OU_DN /I:S /G SELF:RPWP;attributename;user

    This grants Read and Write to the attribute in case something else doesn't grant
    Read. If you know something else grants read, you can simply do WP.

    For instance to grant SELF write access to the description attribute on users in
    my default user location of my test domain I would run the following command

    dsacls cn=users,dc=joe,dc=com /I:S /G SELF:RPWP;description;user

    This would result in the following ACE:

    Inherited to user
    Allow NT AUTHORITY\SELF SPECIAL ACCESS for description
    WRITE PROPERTY
    READ PROPERTY


    --
    Joe Richards Microsoft MVP Windows Server Directory Services
    www.joeware.net


    Brian Higgins wrote:
    > I can not find any place to edit the security on a specific attribute, be it
    > through delegation or whatnot. I have the attribute already created and
    > showing up for each user as an available property(verified with ADSI edit,
    > and I can read the values from that property through ADSI scripting),
    > everything works exactly as I need, except for that I need to give regular
    > users the ability to write to this property of their account, without going
    > and granting specific permissions for each user, as this is going to be used
    > for hundreds of users across multiple domains, so I need a way to set this
    > up at the domain level so that all users in the domain will inherit the
    > permissions.
    >
    > "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
    > news:OVvPZtnIFHA.2656@TK2MSFTNGP09.phx.gbl...
    >
    >>Honestly I would avoid touching the schema. My personal favorite is a
    >>schema with no Default SDs so any object instantiated just has permissions
    >>granted to it through inheritence, it is MUCH easier to track down issues
    >>that way.
    >>
    >>This adding of inherited ACEs is basic AD delegation. You want people to
    >>modify their own samaccountname in some OU, you go to that OU and grant WP
    >>(Write property) to sAMAccountName for user objects to Self.
    >>
    >>A good book for all of this stuff overall is Inside Active Directory, 2E
    >>by Sakari and Mike. Great book, especially in terms of security and schema
    >>stuff. I was recommending that book shortly after the first edition came
    >>out. I was a technical reviewer/editor for the second edition so I am also
    >>behind that one.
    >>
    >>
    >> joe
    >>
    >>--
    >>Joe Richards Microsoft MVP Windows Server Directory Services
    >>www.joeware.net
    >>
    >>
    >>Brian Higgins wrote:
    >>
    >>>If I understood both of you correctly, I have 2 options, 1, make a new
    >>>class, and set the permissions on the class (where it should be
    >>>relatively easy to do?), and then make that class a sub class of the user
    >>>class, or 2, modify the ACL on the attribute and grant permissions
    >>>accordingly (sounds like the better option, but sounds more difficult?)
    >>>
    >>>do you have any references to point me at for this? this is the first
    >>>time I've worked with modifying the schema in any way, and could use a
    >>>few pointers. Thanks.
    >>>
    >>>
    >>>
    >>>"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
    >>>news:uOh8HwZIFHA.2656@TK2MSFTNGP09.phx.gbl...
    >>>
    >>>
    >>>>Actually attributes don't have a default SD, the default SD is on
    >>>>classes.
    >>>>
    >>>>The two solutions would be to modify the default SD on the user object or
    >>>>better yet, add an inherited ACE to the OU where the objects are that
    >>>>allows the specified group of people to modify the attribute. If the
    >>>>attribute should be modified by the user's themselves, I.E. I should be
    >>>>able to update this new attribute only on my own object, I could either
    >>>>set a SELF WP ACE for that attribute on the OU structure or I could add
    >>>>the attribute to the personal information property set.
    >>>>
    >>>>--
    >>>>Joe Richards Microsoft MVP Windows Server Directory Services
    >>>>www.joeware.net
    >>>>
    >>>>
    >>>>Chriss3 [MVP] wrote:
    >>>>
    >>>>
    >>>>>Change the permission for the particular attribute within the schema
    >>>>>manager, ADSI Edit or with the dsacls tool.
    >>>>>
    >>>
    >>>
    >
Ask a new question

Read More

Microsoft Active Directory Windows