Co-managed Delegation: About OU Admin accounts

Introduction:

The following attempts to describe the implementation details and consequences of the manner in which admin rights are assigned within the IFAS portion of UFAD. Note: this description uses Steve Lasley (Gatorlink ID="sel") and OU (Entnem) as example. You may need to view our structure in ADUC for these descriptions to make good sense. Documentation is available on Setting up an Admin Workstation to help you get over that hurdle should you just be starting out.

Note that one can run ADUC with various credentials and will see various results accordingly. Admin accounts have greater privileges in general. For example, you need to have "Read Group Membership" rights in UFAD in order to read the true contents of the MemberOf Tab for a particular user account. Admin accounts should be a member of this group since they are a member of ALL-UNIT-ADMINS. This particular right secures the membership of the Student Course Groups. In other words, pay attention to the credentials you use to connect--different credentials may see different things.

Two accounts:

Each administrator has two management accounts which reside within the "-Central-IT/Management Accounts" OU. In the case of Steve Lasley, for example, these are: IF-ADMN-SEL and IF-ADML-SEL.

Local Admin Accounts:

The IF-ADML-SEL account is a member of the IF-ADML-ENTNEM group which resides within the "Central-IT/Groups/Admin Groups/ENTNEM" OU. Note: ". IFAS-ADML-CO-MANAGED" is a member of this group also; this is part of what implements the co-mangaged aspect of our delegation structure.

The "IF-ENTNEM Computer" GPO uses a restricted groups setting to add the IF-ADML-ENTNEM group as a member of the Local Admininstrators group on each machine within the ENTNEM OU. Note: more specifically, access for the ". IFAS-ADM-ENTNEM" group is added here; this group has both ". IFAS-ADML-ENTNEM" and ". IFAS-ADMN-ENTNEM" groups as members and is the group upon which unit Admin access permissions should be based. A further security setting in the "IF-Co-Managed Computer" GPO denies this group (actually via the ". IFAS-ADML-ALL" group) network access to any of these computers--thus making it useful only for local admin logon to all machines in the ENTNEM OU.

The password on this account could be changed frequently to improve overall security of the unit's machines and perhaps enforced via password change policy.

Network Admin Accounts:

The IF-ADMN-SEL account is a member of the IF-ADMN-ENTNEM group which resides within the "Central-IT/Groups/Admin Groups/ENTNEM" OU.

The IF-ADMN-ENTNEM group is delegated full administrator rights to the ENTNEM OU within AD. The IF-ENTNEM Computer" GPO uses a restricted groups setting to add the IF-ADMN-ENTNEM group as a member of the Local Admininstrators group on each machine within the ENTNEM OU (again, this is actually done via the ". IFAS-ADM-ENTNEM" group. At first we thought that a further security setting in this GPO could simply deny this group local logon to these same computers--the idea being that this would force Steve to (possibly read, but certainly) follow Chris H.'s instructions regarding proper logon procedures to AD management workstations.

It turns outs that denying local logon meant that one had to use the "/netonly" switch when using runas with "IF-ADMN-" credentials; when this switch is used, the alternative credentials are only used over the network. (See here for further discussion on using Runas.) This caused problems for running remote assistance (RA) and various other command line utilities (like netdom and some other Resource Kit Tools) because they are really just executing other programs or scripts. These would execute under the normal user account, because they are launched locally instead of over the network. This was also the case with RA. The solution was simple, once realized: simply create a logon script for the "IF-ADMN-" accounts that logs them off again immediately.

Security Consequences:

The ". IFAS-ADMN-CO-MANAGED" Group gives numerous persons outside Entnem the ability to do everything that Entnem admins can do within the ENTNEM OU of AD.

These persons have to use the same security precautions as would Entnem Admins; which provides confidence that they will follow proper administrative procedures.

The ". IFAS-ADML-CO-MANAGED" Group gives numerous persons outside Entnem the ability to logon locally with administrator privileges to any of the machines within the Entnem OU (or any other OU within the co-managed branch for that matter).

Both the Local and Network admin accounts are members of the IF-ADM-ENTNEM group. This group should be used for permissioning file and printer shares, thus promulgating admin access of those resources to both management accounts at the same time.

Changing Passwords:

OU Admin accounts are originally created with random passwords. You may change these for yourself by going to https://itsa.ifas.ufl.edu/changeadmpw. You must login there with your Gatorlink credentials (not your IF-ADMN or IF-ADML credentials) in order to view the last password change date and change a password without knowing what it is.

Logging on locally with Network Admin:

Due to the implementation we are using (see above), you will be immediately logged off via a logon script. There are numerous occasions, however, where you will need the IF-ADMN credentials:

• If you are using the management tools, such as Active Directory Users and Computers or any other remote MMC, you use the IF-ADMN account via runas.
• If you are doing things against a machine remotely, such as via a command prompt or via Explorer, you would use the IF-ADMN account via runas.
• When joining a computer to the domain, you would use the IF-ADMN account after pre-staging the computer.
• If you have an admin workstation set up according to directions, you would use the IF-ADMN account in the short-cut commands.

Logging on with Local Admin:

If you are logging into a machine via Remote Desktop or locally at the machine, you will need to use the IF-ADML Account.

On login, you will receive a dialog box (actually a stripped-down web page) asking for your IF-ADMN account password. If you have a reasonable doubt as to the security of this machine, you should not enter the password; a keylogger could steal your OU admin credentials--a BAD THING.

If you type in the password, a script will run that will do the following:

• It will make the required registry modification so Explorer will work as a RunAs (the user interface access to this registry setting is via Explorer's "Tools > Folder Options... > View" dialog where you would check the "Launch folders windows in a separate process" option. See here for further discussion).
• It will open two Explorer windows and a command prompt with the IF-ADMN credentials. One Explore windows is focused on the IFAS DFS root \\ad.ufl.edu\ifas and the other is focused on the local desktop. The idea here is that this would allow you to easily move files between remote and local resources. There is an oddity with the local window however; it doesn't update the view automatically for some reason. Pressing F5 will force a refresh.
• Note: You can always use the command prompt to open another explorer window focused wherever you wish. For example:

  C:\WINDOWS\system32>explorer /e,\\if-srv-epo\install$

If you wish to modify the script further, you have access to doing that by copying it into your login script User OU (e.g. "\\ad.ufl.edu\netlogon\ifas\ENTNEM\User\IF-ADML-sel.vbs"), and then making the modifications you desire. Some in IT/SA have the script also open ADUC. You could look at Dwight’s script as an example. You will also need to run ADUC as the IF-ADML user and change the Login Script setting to point to your new script rather than the default template provided (at \\ad.ufl.edu\netlogon\ifas\IF-ADML-template.vbs). Alternatively, you could clear the login script setting and name the script appropriately (e.g., \\ad.ufl.edu\netlogon\ifas\ENTNEM\User\IF-ADML-sel.vbs) to have it run automatically. This is the only time you should run ADUC as the IF-ADML user, as the other permissions in AD are assigned to the IF-ADMN accounts only. Note that the permissions are set so that you will see nothing at all in the Logon Script field of your IF-ADML account properties--unless you run ADUC as that IF-ADML user.

Tip: you might want to put a shortcut to this script on your desktop. You can also run it whenever needed via the Run box.

Note on Windows 2003: When you first login to a Windows 2003 machine, you may need to authorize the website as a trusted site for it to work properly.

Implementation Goal:

Please begin using these accounts and email the ICC with any problems you notice. The goal is to remove the IF-ADM accounts by early July of 2005.