If your organization does not do penetration testing as a method of validating enterprise security practices, you are not aware of how vulnerable the administrator's workstation can be. Actually without a full scope penetration test against your network, you really have no idea of what your exposures are and how vulnerable you are. Guaranteed you will be shocked!

The administrator's workstation is a high priority target for the penetration team, which will try to use it as a lever to gain access to production resources. Policies and methods that minimize potential damage by the domain administrator will be presented, with the focus being the administrator's workstation.

There are no hard and fast rules or universal Best Practices. Each organization has to balance productivity and operational issues against risks. How much and where security measures are applied depends on the enterprise's risk analysis. One organization's gross security violation is another's operational mandate.

Do not treat the domain administrator's workstation as just any other workstation.

Just as the CEO's workstation should receive special attention, so should the administrator's workstation. The CEO and other executive staff have documents which must be protected against loss or exposure. The administrator's workstation is a prime target for hackers. The hacker who gains admin access to the domain administrator's workstation can use numerous approaches to leverage this local access to acquire domain level access. Examples of poor workstation practices and techniques used by hackers follow.

Problem: Administrators tend to minimize the number of passwords they have to remember. They tend to use the same passwords where they can. Hackers take advantage of the dangerous admin practice of using the same password for their workstation admin account and their domain admin account. A hacker can run a dictionary attack against the workstation's administrator account password, and use that password as a starting point for attacks against the domain admin account. The default configuration for the built-in administrator account allows unlimited password guessing, permitting a dictionary attack against the account. The NT Resource Kit utility, Passprop, changes the local workstation's security policy so that the built-in admin account will conform to the account lockout policy of the workstation. To be effective, the workstation needs to have an account lockout policy such as disable the account after 3 bad password attempts and leave it disabled for 15 minutes. Passprop does not disable console access to the built-in administrator account under any circumstances.

Best Practices:

1. Do not use the same password on multiple platforms.
2. Apply Passprop to lockout remote attacks against workstation admin accounts for all NT workstations.

Problem: It is an all-too-common practice to use the same password for the built-in administrator account on all NT workstations in a department or even an entire organization. A hacker with physical access to a poorly protected user's workstation can rapidly gain access to that workstation's administrator account and thus gain remote admin access to all workstations sharing the common password, including the NT domain administrator's PC. (See methods used by hackers to gain access.) A similar practice involves using an access control number, vendor serial number, or other tag found on the PC for the administrator password. A hacker can break into poorly protected user PCs and compare the acquired passwords to labels on the box to identify the pattern.

Best Practice: Do not allow common passwords, patterned passwords, or passwords based on labels.
Minimal Practice: Make sure critical workstations (officers and admins) have unique and strong passwords for the built-in administrator accounts.

Opportunity: Administrator workstations are targets for hackers. You can use this to your advantage by installing personal firewall software. Pick a product with a management console where suspicious or hostile activity reports will be centralized to generate network alerts. BlackICE Defender is an example of a personal firewall with a centralized management console, ICEcap Manager.

An alternative to personal firewall protection, is to disable the server service. This method provides protection but no reporting mechanism. Disabling Server service also prevents file sharing which is inherently dangerous on administrator workstations. Improperly secured shares permit informational exposure when shares are world- readable, or the planting of a Trojan when they are world-writable.

To disable the server service on workstations:

• Click on Services In Control Panel
• Click on Server service
• Stop the service
• Click on Startup button
• Click the Disable radio button

The Computer Browser service depends on the Server service. It also needs to be disabled to prevent NT from generating an error message at boot time stating that a service has failed to start. Disabling the Computer Browser service will not impact workstation functionality. The combination of disabling the server service and applying Passprop protects the workstation against most remote hacker tools and techniques.

Alternative Best Practice: Disable Server service on NT workstations.

Minimal Alternative Best Practice: Disable Server service on domain admin workstations.

Should neither of these alternatives be practical in your environment, some protection is gained by hiding the NT administrator's workstation from Network Neighborhood. To hide the workstation from browsers, use the following net command:

net config server /hidden:yes

Do not make the administrator's workstation a server.

It is another all-to-common practice for administrators (and developers) to install NT Server on their admin workstation. They believe it makes administration easier and is a convenient platform for experimentation. But administrators rarely adhere to server security policies when the server is in their office. This practice is not only dangerous, it is not necessary. Microsoft has client-based administrator utilities which can be installed on NT Workstation or Windows 95. The tools are found in the \clients\srvtools\winnt folder on the Windows NT Server CD or the apps\clients folder on the Windows NT Workstation Resource Kit CD. The server admin tools install into the %systemroot%\system32 folder. Or just copy the executables to your workstation from an existing server.

Do not perform non-administrative tasks from the administrator's workstation while logged on with a domain administrator account.

When NT domain administrators performs user functions such as email, web surfing, and word processing using admin rights, they guarantee serious consequences should they trigger a nasty like the Melissa virus or run a game program and unknowingly install a BackOrifice-like Trojan. The following are possible alternatives to working full-time logged on as domain administrator.

Method 1. Logon to workstation as administrator, do admin task(s), logoff. Logon to workstation as user, do user tasks, logoff.

The honor system. Lets get real. I have tried this approach. I have observed this approach. It is not workable. Over time, the administrator spends longer and longer periods logged on as domain administrator and soon begins working as domain admin exclusively. Logging off and on between user and domain admin accounts is considered to be too much of a hassle. It takes too long to switch back and forth. It is a real productivity killer. Finally, how can one monitor compliance of the policy?

Method 2. Do admin work only at server consoles, and user tasks only at personal workstations. Or Thou shalt logon as administrator only at server consoles.

I have seen this proposed as a security policy. It might work in a standalone office, on a ship at sea, or in a departmental environment. It is simply not operationally feasible in an enterprise-wide environment. Actually, whether this policy would work for your organization depends on your operational needs and risk assessment. The proposed policy derives from very serious concerns about the ease of capturing NT password hashes on the network, specifically domain admin passwords flowing from the admin workstation to domain servers. L0phtCrack is a powerful and inexpensive tool to take advantage of NT password hash weaknesses.

This policy is not necessary if the administrator workstation and client workstations are segregated from each other on different network segments.

Method 3. Two workstations: an administrator workstation with admin tools and a user workstation with only standard user applications.

This method works for the administrator but does not usually work as well for management because of the cost issue. Having a workstation configured and used only for NT administration and another workstation configured and used only for user activities is very useful for the following reasons.

It enhances productivity by allowing user and administrative tasks to occur simultaneously. One does not have to log on and off between user and admin accounts.

Administrators experiment using their workstations. NT can get corrupted, requiring a reinstall. With dual equipment, such experimentation is not as destructive – at least email, word processor and other user tools and files are still intact on the user workstation.

With dual workstations, the admin workstation can be tightly secured while the user workstation can have normal user security.

If you can get around the cost and space issues (need room for two PCs), this is a near ideal solution. One possible solution to the cost dilemma: when it comes time for the administrator to get a new workstation, let him/her keep the old workstation for the second workstation.

Method 4. Use IPC$ server authentication to escalate from user to admin access rights. Perform admin task. Remove IPC$ access to de-escalate back to user access level.

Log onto the admin workstation with ones domain user account. Use this account for email, surfing the web, printing and performing all normal user tasks. In this situation, anyone attempting to illicitly access network services with administrator level access rights will be sadly disappointed. The domain administrator is logged on as a normal user.

When one needs to perform a server administrative task, gain admin access with the following command:

net use \\PDCforDomain\IPC$ /user:domain\adminaccount *

Let's say the domain of interest is hrdom, the PDC for hrdom is hrsrv1 and the account with admin access is hrcwmadm, then the command is:

net use \\hrsrv1\ipc$ /user:hrdom\hrcwmadm *

This works because IPC$ is used for server authentication. The asterisk instructs the "net use" command to prompt for the password for account hrcwmadm in domain hrdom. After the above command succeeds, a secured connection is established between the admin workstation and hrsrv1 such that ensuing commands are executed using the hrcwmadm account although the administrator is logged onto the workstation as a user.

User Manager for Domains, usrmgr.exe, can now be used to manage accounts and groups in hrdom because it runs under the authority of hrcwmadm in hrdom. An attempt to manage accounts in any other domain, SALESDOM for example, will fail with "Access Denied" because the admin-level connection is only to hrdom. To gain admin access to another domain, for example the salesdom PDC which is salessrv1, issue the command:

net use \\salessrv1\ipc$ /user:salesdom\salescwmadm *

This completes a secure connection between the workstation and the pdc salessrv1. You now have two secure admin connections active and can do administrative work in both domains. Perform whatever account management is needed, get out of User Manager for Domains, and remove admin access to these domains. To remove admin access rights, issue the commands:

net use \\salessrv1\ipc$ /d

net use \\hrsrv1\ipc$ /d

The /d parameter deletes the connection to the IPC$ authentication resource. The general rule is to get the access you need; do the required work; and remove the admin access. Working with this pattern drastically reduces risk of inappropriate access. If you have a large number of domains, you can automate the drudgery out of these commands by using scripts. To control connections to the PDCs for User Manager access, the following script may prove useful.

IPC.BAT

IPC$ access is also used with the client-based tool Server Manager, srvmgr.exe. This tool is used to create, delete and manage access to network shares on a server-by-server basis. To gain access to the file server, fssrv1, use the ipc$ command:

net use \\fssrv1\ipc$ /user:fsdom\fscwmadm *

One can create shares, remove shares and manage access to shares using the secure connection created. Let's say you have created a new share, \\fssrv1\dev1share, which maps to the folder e:\developers\dev1. One can control access to the new share using share-level permissions via Server Manager as show above, or at the NTFS permissions level. To manage access to NTFS permissions, gain admin access to the required drive using the command:

net use \\fssrv1\e$ /user:fsdom\fscwmadm *

One can then manage the NTFS permissions using the My Computer GUI:

• Navigate to the folder
• Right click the folder symbol
• Select Properties
• Select Security tab
• Select Permissions
• Set whatever NTFS access controls are desired

Creating and breaking secured connections focuses the administrators attention to the admin tasks at hand. It also reduces the scope of admin access to the specific secured connections, and reduces the duration of admin access to the life of the secured connection. This should restrict damages should one's virus scanner or intrusion detection fail.

Method 5. Access client-based admin tools using terminal server.

This method, the final one presented here, also enforces a clean separation of admin and user functions. A terminal server client is installed on the admin workstation. The client is used to connect to the terminal server, where admin tools are installed and execute. Separation of function is maintained. The admin-level secured connections flow from the terminal server to the other servers being administered, not from the workstation to the other servers. This method is very attractive from both security and cost perspectives assuming that there are enough admin personnel to make a terminal server cost effective.

Summary

This article discusses why and how one should pay special attention to the NT domain administrator's workstation. The administrator workstation is a significant risk to your network should a virus or pernicious Trojan be triggered from that workstation while accessing the network with administrative privileges. This article does not focus on these general threats but focuses on poor practices that make the administrator workstation more vulnerable than it need be. Do a risk analysis and consider one of the methods presented to limit the scope of admin exposure when working from the admin workstation. Test the feasible methods in your environment. Realize that most administrators will react strongly to any perceived restriction to their admin privileges (personal experience as an NT and unix admin). If your organization avoids the more egregious poor security practices noted, your network will be significantly safer. The administrator and management attitude "we have worked that way for years and never had a problem" changes diametrically when faced with the findings of a competent penetration exercise.