Title: Message
Huh.  Tried it before I posted the information.  Worked here - I best go check the DC.  It might have gone up in a mushroom cloud as I've violated Microsoft force of will.  :-p
 
Well, then, folks - don't do this.  Pester MS to let you control your own data.  Hopefully in the next 3 - 4 years, we can get some traction on that one......  Yeah, right.  :-/
 

Rick Kingslan  MCSE, MCSA, MCT
Microsoft MVP - Active Directory
Associate Expert
Expert Zone - www.microsoft.com/windowsxp/expertzone
 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe
Sent: Wednesday, July 16, 2003 11:40 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Locking Down User Information Fields in AD

Sorry Rick this won't really work this easily.
 
The problem is that MS in their infinite wisdom (sorry this is one of those sore spots with me) made lots of permissions part of the default sd for a given object. With user objects self gets rights on several property sets - Personal Information, Phone and Mail Options, Web Information.
 
Because these default sd's get applied directly to the object combined with the fact that inherited aces do not overpower explicit aces (unless you have a 3 kings and a deuce) you can't trump the explicit grant of access to say address (which is in personal information property set) with an inherited deny.
 
The only way to correct this is to (and not necessarily in this order)
 
a. apply a deny ace for every property you want denied on every user object you want it denied on
b. remove the self grant personal information ace and then add a new ace for any attributes in pers-inf you want the user to modify. Note that you really need to understand what is in the property set before you remove it so you know what you are breaking... like user certs for instance...
 
I don't really recommend A and if you do B you will want to do the corresponding Schema update to modify the default SD for the object so you don't have to keep doing it for all the new users.
 
<exchange vent>
This is one of the many reasons why Exchange 2K Granular delegation is such a royal pain in the arse. Take a look at the public information property set and what you need to do basic Exchange mailbox support work such as deleting (disconnecting), reconnecting, and moving. If you have a setup where you want E2K admins to not dork with non-exchange attributes you have to add a bazillion aces (*slight* inflation of truth) to the containers where user objects reside. Then in the meanwhile any bright exchange admin realizes they can give themselves more access by simply using an Exchange server to add themselves to an Exchange Server group and bypass your delegation because if you modify the delegation to the "main" Exchange Server/Services groups, you are no longer supported by MS.
</exchange vent>
 
<dream weaver sequence>
I would love to have seen less default perms given in the default sd's. Also I would like to see a separate workstation and server computer object so you can have different default sd's and inherited perms for them. Heck while I'm at it... I want operatingSystemHotfix to be updated on computer objects automatically (and make it multivalued) or at least someone to publish the format it will be using when it is published so I can write something to do it in the meanwhile... <As joe patches for MS03-26>.
</dream weaver sequence>
 
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan
Sent: Wednesday, July 16, 2003 7:58 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Locking Down User Information Fields in AD

Sure.  I just posted a message here already about delegating computer object stuff, but the user object stuff is pretty much the same.  Let's say you don't want your users to change their phone number, for example.  One point on this example - by default, all users have the right (or more appropriately - the permission) to modify their OWN information, so we'll need to take it away.
 
1.  Go to the Domain or OU level of choice, right click / properties / Security / Advanced UI
2.  If not already there, add the SELF principal.  Makes life easier - see caveat [1]
3.  Select the Properties tab, 'Apply on to:' and choose User Object
4.  Check in the DENY column fields that you do not want the user to be able to Write to - the will still be able to View it.
5.  Apply / OK / OK should get it done.
 
[1] Caveat - make sure that you plan this carefully.  SELF is great for this, unless you REALLY want to assign this explicitly to each and every user.  Denys, as always are very nasty and a misplaced one can be very hard to track down.  Apply this on to an OU for your users, leaving the Administrative accounts unscathed.
 
Rick Kingslan  MCSE, MCSA, MCT
Microsoft MVP - Active Directory
Associate Expert
Expert Zone - www.microsoft.com/windowsxp/expertzone
 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wright, T. MR NSSB
Sent: Wednesday, July 16, 2003 2:41 PM
To: '[EMAIL PROTECTED]'
Subject: [ActiveDir] Locking Down User Information Fields in AD

Just curious how I would go about stopping a user from being able to update their address, website, etc under their own account. AD...
Basically I want them only to be able to update their own phone # and nothing else and I would also like to force it to be strictly a numeric only field (which it isn't by default.)
Any ideas??
 
 
Thanks,
 
-Tim
 

Reply via email to