|
Inherited perms from top of subtree are
better for everyone….easier to manage and such. And of course if you’re
going to do serious ACLing, 2k03 is a great upgrade path because of single
instance store (SIS) of SDs. I don’t like making changes to
default SD personally. Only when absolutely required with no other choices….. ~Eric From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of joe The two attributes mentioned aren't in any
property sets which means whatever permissions set for the user object itself
are what counts. I have never seen either of those specifically outlined with
permissions on a user object which would seem to indicate that the normal users
would not have the ability to modify the values by default. The positive proof would be to log on as a
normal user, fire up adsiedit and try to modify the attributes or write a
script to do so. If you get access denied, you know you are cool. I agree with Eric though for the choice of
tool and how to do the determination. On the updating perms, if you can do it
with inherited perms that rocks. If not it is kind of a pain. Actually I would like to see some serious
docs from MS concerning locking down an AD deployment very seriously. I.E.
Cleaning up all the default SDs in the schema so that by default, you get the
permissions the container/OU the object is created in has. When I say serious,
I mean what permissions would need to be given back and why so you don't break
MS software or knowingly break it. They don't have to outline what you have to
do to make anyone else's software work, just theirs. joe From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Eric Fleischman You can look at the acls on the user
object itself to see what the effective perms are….I like dsacls, others
might have other tools of choice. To modify it wholesale for a lot of users,
my method of choice is ensuring there are no explicit acls on the users
granting them write to the attributes in question (you can look at the default
SD for the user object, or just create one, uncheck inherit for test, and see
what’s there, or just look at what is explicit….tons of choices ;))
then put the desired ACL on the top of a subtree that gives what you
want….in this case it would be DENY WRITE on the attribute(s) in question
for at least SELF, probably a larger group of users defined somehow. Or perhaps just don’t allow write to
SELF, and that will implicitly mean they can’t write to it. ~Eric From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas M. Long Is there an easy way to find out what
attributes a user to edit? The two I am most concerned about are employeeID,
and employeeNumber. If they do appear to be editable by the user, how do i
change that (a link would be great)? Thanks |
Title: RE: [ActiveDir] Exchange 2003 Question
- RE: [ActiveDir] User modifiable attributes joe
- RE: [ActiveDir] User modifiable attributes Eric Fleischman
- RE: [ActiveDir] User modifiable attributes Grillenmeier, Guido
- RE: [ActiveDir] User modifiable attributes joe
- [ActiveDir] PAGE file Douglas M. Long
