Creating new schema object

G

Guest

Guest
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.
 
G

Guest

Guest
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.
>
 
G

Guest

Guest
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.
>
 
G

Guest

Guest
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.
>>
 
G

Guest

Guest
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.
>>>
>
>
>
 
G

Guest

Guest
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.
>>>>
>>
>>
 
G

Guest

Guest
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.
>>>>>
>>>
>>>
>