One of the most far-reaching, new administrative features that Windows 2000 offers is Group Policy. As part of InteliMirror, Group Policy lets administrators control desktop settings, use scripts, perform Internet Explorer (IE) maintenance, roll out software, redirect folders, and more. All of these features can be an administrator's dream in supporting LAN users.
Group Policy places restrictions on what a user or computer can do by removing liberties; as such, Group Policy is a tool that simplifies the administrator's job and is not for the benefit of the user (restrictions do not equal benefits). So, for example, on standalone Win2K Professional workstations, Group Policy lets you prevent users from deleting programs, sending huge files to a slow printer, and deleting the system registry.
By limiting what users can do, you also limit the features and equipment that you must support, thereby reducing the overall administrative cost of supporting the network, computers, and users. So, if you take away the user's ability to add new software, you don’t have to worry about supporting untested applications. Likewise, if you remove the ability to delete installed printers, you don’t have to waste time reinstalling printers.
But what if your workforce is mobile? How do you enforce restrictions on users who don't have a direct connection to your LAN? With a few local policies, some security templates, and the occasional use of Group Policy, you can place restrictions on your mobile workforce.
Roaming Users Versus Mobile Users
Before we go any further, it is important to differentiate between roaming users and mobile users. As the name implies, roaming users roam the network and use different computers within the same LAN. Mobile users use the same workstation but don't have a direct connection to the LAN. Because you can't force mobile users to connect to a server on your LAN each time they boot, you are less able to enforce administrative restrictions such as Group Policies. However, you can apply administrative restrictions on mobile users using other means, depending on the type of client you're dealing with.
Legacy clients. If a mobile computer runs Windows NT or Windows 9x, you can use System Policies to apply registry restrictions to that system and hide the policies locally. System Policies, which are the predecessors of Group Policies, restrict only registry settings, while Group Policies exceed that functionality.functionality by going far beyond registry settings alone. For information on setting System Policies for mobile users, see my article, "Creating System Policies for a Mobile Workforce".
Windows 2000 clients. Even if you can't use Group Policies on Win2K clients without a direct connection, you can still place many settings directly on the mobile computer and make these settings local policies. Local policies can apply to several areas, including
- administrative templates. Administrative templates consist mostly of registry restrictions that existed in System Policies. These templates let you manage the registry settings that control the desktop, including applications and OS components.
- scripts. Scripts let you automate user logon and logoff.
- security settings. The Security Settings extension lets you define security options (local, domain, and network) for users within the scope of a Group Policy Object (GPO), including Account Policy, encryption, and so forth.
Creating the Local Policy
Before you can implement a local policy for a mobile client, you need to create the policy using Group Policy Editor (GPE). To start the GPE, either click Run from the Start menu and enter
gpedit.msc
or click Run from the Start menu and enter
MMC
to open the Microsoft Management Console (MMC). If you choose the MMC option, go to the Console menu, select Open, and select gpedit.msc from the System32 directory.
When opened, a local policy has two primary divisions: Computer Configuration and User Configuration. The settings that you configure for Computer Configuration apply to the computer, regardless of who is using it. Conversely, the settings that you configure for User Configuration apply only if the specified user is logged on. Both primary divisions can be useful with a mobile workforce. Note that the OS applies the Computer Configuration settings whenever the computer is on, whereas it applies the User Configuration settings only when the user logs on.
Password Policies
Because the likelihood of laptops being stolen is always a possibility, you will want to make use of good password policies for your mobile users. You can access password settings in gpedit.msc at the following path: Computer Configuration - Windows Settings - Security Settings - Account Policies - Password Policy. An example password policy is as follows:
Enforce password history: 8 passwords remembered
Maximum password age: 42 days
Minimum password age: 3 days
Minimum password length: 6 to 8 characters
Leave the other three settings disabled (minimum password length, passwords must meet complexity requirements, and store passwords using reverse encryption for all users in the domain) disabled.
When you work with a mobile workforce, you must weigh the choice of having users call you in the middle of the night when they forget their password against the security of those users' systems if their laptops fall into the wrong hands. A good rule of thumb is to lock out the user after five attempts for a period of between 30 and 60 minutes.
Local Policies
Gpedit.msc contains a Local Policies section at Computer Configuration – Windows Settings – Security Settings that consists of three subsections: Audit Policy, User Rights Assignment, and Security Options. The Audit Policy subsection contains nine settings, the default value for each being "No auditing." Valid options are Success and/or Failure, as Figure 1 shows, for Audit account logon events. However, you will want to consider turning on this auditing for mobile users to see how often they log on and log off their machines. For all these settings, when you turn on auditing for an event, Win2K logs the entries in the Security log file.
Applying Security Templates
Rather than editing the local policy on each machine, you can use the Security Templates snap-in to create a sample file that you can readily apply on any machine. The Security Templates snap-in includes several default templates that you can use to create the baseline.
To reach the Security Templates snap-in, start the MMC, go to the Console menu, and select Add/Remove Snap-in. Next, click Add, select Security Templates, and click OK twice to return to the snap-in within the MMC. Figure 2 shows the Security Templates snap-in and the default templates.
Of particular interest for a mobile workforce is the secure workstation template (securews). Table 1 shows the default settings that this template applies.
Occasional Use of Group Policy
You can configure Group Polices that will apply to Win2K Pro clients when your mobile users do connect directly to the network (such as a mobile laptop user sitting in the office with the machine in the docking station), yet not force updates on clients connecting over slow links. If you try to force the policy in the field, it can take considerable time and even prevent users from performing simple tasks (e.g., dialing in to upload an order).
The Group Policy slow link detection setting, as Figure 3 shows, is located beneath Computer Configuration. To access this setting, go to Administrative Templates, choose System, and choose Group Policy. The slow link detection setting applies to security settings, administrative templates, software installation and maintenance, scripts, folder redirection, and IE maintenance. The default definition of a slow link is 500Kbps; however, you can change it to any value you desire.
In situations where you are applying both local policies and Group Policies (such as when the computer is in the office connecting to the docking station), Win2K applies the local policies first. Because the OS applies any Group Policies second, the Group Policy settings can easily override, compliment, or simply not affect those within the local policies.
For example, a local policy can't contain folder redirection, but a Group Policy can. In the field, folder redirection won't be in place, but it will be present in the office. Not only do Group Policies run after the local policies, but multiple Group Policies can run—each changing or adding to the restrictions and settings. After local policies, the order of execution is as follows:
- A site Group Policy, if applicable
- A domain Group Policy, if applicable
- Organizational unit (OU) policies, if applicable
(Microsoft refers to this order of execution as sites, domains, and organization units—SDOU.)
Be aware that in the absence of a direct connection to the LAN (and, therefore, to Active Directory—AD), there are several Group Policy restrictions that you can't enforce. These restrictions include assigning and publishing software, folder redirection, remote installation, and roaming profiles.
Other Considerations for Mobile Users
In addition to using Win2K's Group Policy feature, you will want to consider several other factors for the mobile workforce. The first and foremost of these is security. Every mobile computer should be running NTFS to take advantage of its file- and folder-level security features. Additionally, you should protect the data with Encrypting File System (EFS) to keep it from prying eyes (e.g., if a laptop is stolen). You should also create usernames that are not easy to guess and encourage users to make use of good password practices.
