Al, Version 1 of your proposal is exactly what I have done in the past, and works quite well (within some defined boundaries). Account managers were delegated very minimum rights over AD (such as unlock account reset password etc), and everything else was done via a "tool" (was client-server at the time). Account Managers would use the tool to create / manage a user account, and the back-end applied rules to where things occurred. The advantage of this was that there was a business logic layer in the background that forced certain things to occur (such as creating the home drive / Exchange mailbox on the logically closest server, without the creator needing to know what was going on). The primary disadvantage was the maintenance overhead of such a "tool".
Some Other advantages: - Business Rules automatically defined which groups, resources users had access to (based on a defined "profile", or location, or job function) - Approval Paths (workflow) could be placed over the top to send an approval request upwards if a certain level of network access was requested (eg Administrator access). Link this in with outlook forms and the Exchange Workflow engine and you have some pretty neat abilities. - Granular security. The tool (through security settings or business logic) defined exactly what requestors could do, based on their relative ability (or security clearance). Functionality within the tool can be enhanced (or completely removed) based on this security "profile". - Requests can be scheduled !! This was a biggie at a former employer, since comms links were heavily utilised during the day. Requests for user movement / mailbox movement / creation could be scheduled to occur after hours. The system simply delayed the task until a certain time, then automatically processed the request. When complete, either a notification through the app was sent to the helpdesk person, or an email sent directly to the requestor. - Because there is business logic / rules applied, things always end up the same way (capitalisation, phone number formats, email addresses etc) - The business logic / processes could be changed easily without having to go through a notification / retraining process. The helpdesk etc just filled out the form the same way, but the back-end process did other things. - Logging. Since the "tool" was client server, extensive logging can be performed, and NT Authentication used to log exactly who made the request etc. Made it a lot easier looking for inappropriate changes to the network (although the number was heavily reduced as no-one had access to do anything). - Multiple Interfaces. We ended up with a web-based, standalone app, Outlook Forms, and Email request methods. Allows a lot of flexibility. - Incremental Functionality. Since there is an app (web or otherwise), functionality can be incrementally added as you put functionality into the system. Start off small (like user creation), and increase the tools functionality as you go. Makes it easier to implement rather than biting off a huge chunk in one go. - Removes dependence on 2nd / 3rd level support. Since 2nd / 3rd level support typically are required for some of the higher level functions, you can allow the app to do this without increasing the access for your helpdesk staff. For example, our user creations required the home drive creation to be sent to 2nd level (due to NTFS permissions settings). Once the tool was doing the user creation, 2nd level no longer needed to be involved. It released them for other / higher-value tasks. Disadvantages - Tool Availability. If the tool isn't available (server crash / app crash etc), people cant do things. - Account Access. Since the back-end process is doing everything, this account may need very high levels of access (IT Security may have an issue with that). Haven't played with MIIS much, but I presume it could do a lot of this stuff through the provisioning engine. The EA / Quest tools as you mentioned have a lot of this sort of functionality as well. Oops, that was a bit of a ramble, apologies everyone. Glenn -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Wednesday, 29 September 2004 3:06 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] How to take away the password never expirers chec k box right? Some alternatives to your thinking might be worth discussing: One alternative would be to only grant them the bare minimum rights they need to do their jobs. An optimal way to do this would be to have a centralized account lifecycle management tool that you can use to prevent admins from going outside the processes defined. Creation/Deletion and possibly modifications would be handled by this central tool (think web page). From there, the local admins would have "helpdesk" rights via the ADUC. The centralized tool is still self-service for the admins to manage their OU's, it's just that they don't have the direct rights. I figure they'd need to be able to add/remove computer objects, create OU's, and reset passwords. Everything else could be done via a central tool. The tool concept I'm thinking of would be a MIIS like tool permissioned for their use. Another alternative would be to enforce after the fact. You said it's a policy, so by nature if you're an admin you should be following policy. If you're not, then a) we need to know about (reporting) and b) you need to be corrected according to company guidelines and policies. This setup infers more layer-7 influence at the mgmt level but you have to collect the information and trigger the alerting. Many monitoring systems can monitor event logs or you could home-brew something I'm sure. A script that checks all user objects would work as well, right? It's just that it's after the fact vs. prevention. That gives you three options to meet your overall goals. To meet your original goal of removing that right, you'd have to either go with the Quest type tool else remove their rights from the useraccountcontrol attribute. That's difficult since they can create objects and could theoretically just add those rights back meaning you'd have to work harder to prevent that and then monitor that process etc., right? Al List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
