Hunter, Joe, thanks for replying. So i will follow joe advice about building their OUs myself so they can not modify their OUs ACLs. Also why isn't MIIS being used to handle all user properties? => you are absolutly right. Just to describe our strategy in MIIS. We use the HR database as the Master DB whose pushes all users informations to other slaves DB such as AD, Openldap , Sysbase databases. AD has been for now 4 years "THE" only databases where OUs admins get used to populate users information so that it can be accessible for everyone. But we noticed that certain informations in the HR DB are not updated, or are missing during users life in our university, AD is. So u may say : "Hey yann, so update this HR database and eveything is ok ?" Unfortunately, for political reasons, we can not update the HR db, the admin won't let us acces to his DB :): it is difficult to change HR users habits of working and mentalities and convince them that miis will do everything for them.We must be patient in order to change their attitudes.... So we decided to populate only most common attributes such as sn, givenname, description, employeeid,etc... and let the admins OU the choice to modify users informations. Thanks, Yann
________________________________ De: [EMAIL PROTECTED] de la part de joe Date: ven. 07/10/2005 02:21 À: [email protected] Objet : RE: [ActiveDir] Question about Delegation & Object Owner. Yep, completely agree. Remove the right to create OUs. I have mentioned this on the list multiple times as the creator/owner issue. What you should do is define a fixed structure that is used by all delegated groups and when a new delegated group spins up, you build the entire OU structure and then they have at it. Also why isn't MIIS being used to handle all user properties? ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Coleman, Hunter Sent: Thursday, October 06, 2005 3:16 PM To: [email protected] Subject: RE: [ActiveDir] Question about Delegation & Object Owner. If you create an object, you are the owner of the object and have full control over it. Seems like your options include removing their create/delete OU rights and making them go through you, or setting up a proxied system (e.g. web page) that will do the creation for them. You could run a script that takes ownership of all OUs and resets permissions on them, but that will be reactive and you may still end up with user accounts or other things that the admins created manually inbetween runs of the script. Hunter ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of TIROA YANN Sent: Thursday, October 06, 2005 12:09 PM To: [email protected] Subject: [ActiveDir] Question about Delegation & Object Owner. Hello, In my university, I had succesfully delegated to each admins responsible of their OU the following tasks: -> Creste.delete groups. -> Create/delete computers -> Create/delete OUs.. -> Only Modify Users properties: Admins have no right to create/delete users because this task is done by our MIIS 2003. BUT, i noiticed that in some OUs, users are still created manually, and after searching, it was due to the fact that admins have the rights to create child OUs, they become automatically the owner of their OU so they can easily modify the ACLs to have full control .. :( So my question : is there a way to grant them create/delete OU without having them to be the owner of their OU ? I did not find a set of properties in dssec.dat concerning my needs. Thanks for input. Cheers, Yann
<<winmail.dat>>
