| Author |
Message |
GMartin
Guest
|
 Posted:
Wed Jan 12, 2005 4:53 am Post subject:
AD attribute permissions |
|
|
We're developing AD as our external web directory. We've done some
schema extensions and we're working through some other issues. Right
now we're trying to understand the best way to allow a user to update
one of the custom attributes we've added. We've discovered that we can
set an ACE that references SELF and allow the user to update it. That's
cool (although I can't find it documented yet!)
The question is this. We can apply this permission in two ways. 1)
Define the ACE at the OU level and allow it to get inherited upon
creation. 2) We can apply a default permission to the attribute in the
schema and it will get set upon opject instantiation.
My questions are this: Is 2) correct? Is there a performance benefit
to doing it one way or the other?
\\Greg |
|
| Back to top |
|
 |
Tomasz Onyszko [MVP]
Guest
|
| Posted:
Wed Jan 12, 2005 5:44 am Post subject:
Re: AD attribute permissions |
|
|
GMartin wrote:
(...)
| Quote: | My questions are this: Is 2) correct?
Yes, this is one of the way You can do this |
Is there a performance benefit
| Quote: | to doing it one way or the other?
The benefit of putting the ACls on the attribute in the schema is that |
all instances of this attribute created in directory (even outside of
the OU on which You want to place the permission ) will have this
permission applied
--
Tomasz Onyszko [MVP]
T.Onyszko@w2k.pl
http://www.w2k.pl |
|
| Back to top |
|
|
Joe Richards [MVP]
Guest
|
| Posted:
Wed Jan 12, 2005 9:18 am Post subject:
Re: AD attribute permissions |
|
|
Well SELF I think is documented, it is the generic secprin representing, well,
the object itself. Anytime any object has a grant of a secprin with write
property/attribute, that secprin can write that property unless some other ACE
overrides it.
1. This is very feasible and common. Things to keep in mind is that an inherited
GRANT can be overridden by an inherited DENY or explicit DENY.
2. No you can not apply a default permission to an attribute. You apply the
default perms to a class. This means any classes that include this attribute
would have to be modified for it.
Overall I don't like perms stamped on objects from the
defaultSecurityDescriptor. This is because these are explicit perms and are
tough to clean up later if you have an issue with it and want to remove. Overall
I recommend having very few perms in the defaultSecurityDescriptor and do
everything through inheritance.
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net
GMartin wrote:
| Quote: | We're developing AD as our external web directory. We've done some
schema extensions and we're working through some other issues. Right
now we're trying to understand the best way to allow a user to update
one of the custom attributes we've added. We've discovered that we can
set an ACE that references SELF and allow the user to update it. That's
cool (although I can't find it documented yet!)
The question is this. We can apply this permission in two ways. 1)
Define the ACE at the OU level and allow it to get inherited upon
creation. 2) We can apply a default permission to the attribute in the
schema and it will get set upon opject instantiation.
My questions are this: Is 2) correct? Is there a performance benefit
to doing it one way or the other?
\\Greg |
|
|
| Back to top |
|
|
GMartin
Guest
|
| Posted:
Wed Jan 12, 2005 11:23 pm Post subject:
Re: AD attribute permissions |
|
|
Joe Richards [MVP] wrote:
| Quote: | Well SELF I think is documented, it is the generic secprin representing,
well, the object itself. Anytime any object has a grant of a secprin
with write property/attribute, that secprin can write that property
unless some other ACE overrides it.
1. This is very feasible and common. Things to keep in mind is that an
inherited GRANT can be overridden by an inherited DENY or explicit DENY.
2. No you can not apply a default permission to an attribute. You apply
the default perms to a class. This means any classes that include this
attribute would have to be modified for it.
Overall I don't like perms stamped on objects from the
defaultSecurityDescriptor. This is because these are explicit perms and
are tough to clean up later if you have an issue with it and want to
remove. Overall I recommend having very few perms in the
defaultSecurityDescriptor and do everything through inheritance.
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net
Joe, et al - thanks for the response. To your point, I came to the same |
conclusion, that while we can apply as the default, we shouldn't unless
there is a compelling reason. My feeling is that its pretty obscure and
not obvious. Trying to clean up from it could be confusing for
someone coming behind me.
Thanks again
\\Greg |
|
| Back to top |
|
|
Joe Richards [MVP]
Guest
|
| Posted:
Wed Jan 12, 2005 11:44 pm Post subject:
Re: AD attribute permissions |
|
|
Absolutely. Heck it can even be confusing to clean up for yourself later on. :)
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net
GMartin wrote:
| Quote: | Joe Richards [MVP] wrote:
Well SELF I think is documented, it is the generic secprin
representing, well, the object itself. Anytime any object has a grant
of a secprin with write property/attribute, that secprin can write
that property unless some other ACE overrides it.
1. This is very feasible and common. Things to keep in mind is that an
inherited GRANT can be overridden by an inherited DENY or explicit DENY.
2. No you can not apply a default permission to an attribute. You
apply the default perms to a class. This means any classes that
include this attribute would have to be modified for it.
Overall I don't like perms stamped on objects from the
defaultSecurityDescriptor. This is because these are explicit perms
and are tough to clean up later if you have an issue with it and want
to remove. Overall I recommend having very few perms in the
defaultSecurityDescriptor and do everything through inheritance.
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net
Joe, et al - thanks for the response. To your point, I came to the same
conclusion, that while we can apply as the default, we shouldn't unless
there is a compelling reason. My feeling is that its pretty obscure and
not obvious. Trying to clean up from it could be confusing for someone
coming behind me.
Thanks again
\\Greg |
|
|
| Back to top |
|
|
GMartin
Guest
|
| Posted:
Thu Jan 13, 2005 8:37 pm Post subject:
Re: AD attribute permissions |
|
|
Thisi s so true, esp. given the qulaity of my memory since I hit 40!
\\Greg
Joe Richards [MVP] wrote:
| Quote: | Absolutely. Heck it can even be confusing to clean up for yourself later
on. :)
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net
GMartin wrote:
Joe Richards [MVP] wrote:
Well SELF I think is documented, it is the generic secprin
representing, well, the object itself. Anytime any object has a grant
of a secprin with write property/attribute, that secprin can write
that property unless some other ACE overrides it.
1. This is very feasible and common. Things to keep in mind is that
an inherited GRANT can be overridden by an inherited DENY or explicit
DENY.
2. No you can not apply a default permission to an attribute. You
apply the default perms to a class. This means any classes that
include this attribute would have to be modified for it.
Overall I don't like perms stamped on objects from the
defaultSecurityDescriptor. This is because these are explicit perms
and are tough to clean up later if you have an issue with it and want
to remove. Overall I recommend having very few perms in the
defaultSecurityDescriptor and do everything through inheritance.
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net
Joe, et al - thanks for the response. To your point, I came to the
same conclusion, that while we can apply as the default, we shouldn't
unless there is a compelling reason. My feeling is that its pretty
obscure and not obvious. Trying to clean up from it could be
confusing for someone coming behind me.
Thanks again
\\Greg |
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in