RE: [ActiveDir] User modifiable attributes

[joe]

Title: RE: [ActiveDir] Exchange 2003 Question

Douglas you appear to be in luck...   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 Sent: Monday, May 17, 2004 10:10 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] User modifiable attributes 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 Sent: Monday, May 17, 2004 8:07 AM To: [EMAIL PROTECTED] Subject: [ActiveDir] User modifiable attributes   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