Creating new schema object

  • Thread starter Thread starter Brian Higgins
  • Start date Start date
B

Brian Higgins

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.
 
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
 
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.
 
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.
 
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
 
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.
 
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
 
Back
Top