Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Windows 2003 Group Policy
So what's new with Group Policy for Windows 2003? In Group Policy for Windows 2000, you didn't have software restriction or wireless network policies that you could set up for a GPO. In Windows 2003, both of these policies are now available. First, take a look at setting up a software restriction policy first.
Setting up a Software Restriction Policy
If you want to restrict or allow applications to be run on certain computers on your network, you can create a software restriction policy (SRP) that will accomplish this. To take a closer look at what settings can be applied here, open the Default Domain Security Settings snap-in from the Administrative Tools menu. In the left pane, click the Software Restrictions Policies node, as shown in Figure 1.
)
Figure
1 Viewing the Software Restriction Policies node.
To create a software restriction policy, you need to right-click the SRP node and select All Tasks > New Software Restriction Policies. After you do this, the right pane now shows some additional folders and settings that can be applied. For purposes of this example, go ahead and set up a security policy that will disallow Yahoo Pager from running on the system. After you finish, you could also add other applications to this same policy that adhere to the same settings that are applied here. To get started, open the Security Levels folder; you should see a screen similar to the shown in Figure 2.
)
Figure
2 Viewing Security Level settings.
In the right pane, you can see two different settings that can be applied at the security level to all software will be part of our policy. One setting (Disallowed) is already set by default. The other setting (Restricted), if set to default, would mean that a user's access permissions to the application would determine whether he could run it or not. In this example, leave it restricted so that no user will get access to any application you add here, regardless of permissions to the application's executable file.
Next, take a look at some additional rules that you can apply. Click to open the Additional Rules folder in the left pane, which is where you tell the policy which applications to restrict (or disallow). Notice that by right-clicking a blank portion in the right pane, you can also set up rules that prohibit access to certificates or even web sites by overriding the rules that are defined by the Internet Security Zone settings.
In the right pane, you see some default registry paths. To use one of these rules, just double-click one to change the path a bit. I don't recommend using registry paths to application executables unless you're fairly familiar with the registry. In this example, you will restrict the use of Yahoo Messenger, if installed on any machine on your network. As an administrator, you may want to do this from time to time. To do this, right-click somewhere on a blank area in the right-hand pane and select New Path Rule from the context menu. Next, browse to Yahoo Messenger's executable (ypage.exe) to define the path, as shown in Figure 3.
)
Figure
3 Restricting the Yahoo Messenger application.
The path shown should be the same on every user's machine that is part of our Group Policy. For any other applications, simply create a new path rule for the application. Going back to the main node (the Software Restriction Policies folder), you find three other property sheets: Enforcement, Designated File Types, and Trusted Publishers. Double-click the Enforcement sheet, and you should see a screen similar to the one shown in Figure 4.
)
Figure
4 Viewing the Enforcement property sheet.
Now that you have set up your security level and the path rules for the applications that you will be restricting, it's time to declare which files of the application will be restricted. The default option is set to restrict all files, excluding the dll library files that the application uses. It is good to leave this option as the default because many applications share the same dll library files. If you also restricted the library files, you might cause another application (one you don't want restricted) to not function.
Moving on to the next property sheet, Designated File Types, you can specify which file types will serve as an application's launch (executable) file. The most common ones are already listed, such as .exe and .com. If you have an application that you want to set a path rule for that launches by a file type that is different from what's shown, you add that file type here. The last property sheet, Trusted Publishers, applies only to certificate rules. Use this sheet if you want to define which user type (that is, administrators) will be given authorization for choosing trusted publishers (that is, Verisign) of certificates that will be accepted to operate or be installed on the machine.
Setting Up a Wireless Network Policy
Setting up a wireless access policy is done in much the same manner as any other policy. To begin, find the Wireless Network node in the left pane of the Default Domain Security Settings snap-in. Right-click the node to launch the Wireless Network Policy Wizard as shown in figure 5 below.
)
Figure
5 Wireless Network Policy Wizard start screen.
In this example, I call the new policy Global Wireless Restrictions. Call yours what you like, click Next and leave the Edit Properties boxed checked, and click Finish. Now the Global Wireless Restrictions (or whatever you called it) dialog box appears with the General tab selected, as shown in Figure 6.
)
Figure
6 Editing Wireless Network Policy properties.
The Description field is obvious: Enter a description for this policy here. Looking down, you see the interval in minutes (the default is 180), which specifies how often wireless network clients on your domain check for any new policy changes. Next, you see a drop-down box showing the types of networks your clients can have access to. The default here is any available network.
An Infrastructure type of wireless network means that all your connections are through a wireless access point (simply put, a wireless hub). An Ad hoc type of network means making wireless connections between devices only, without any fixed access points. Leave the Use Windows To Configure Wireless Network Settings For Clients Box checked to have Windows configure the wireless settings for network clients you defined here. Choose the non-preferred networks check box only if you want your wireless clients to connect to networks not in the Preferred Networks list. To view or add to this list, click the Preferred Networks tab; you should see a screen similar to the one shown in Figure 7.
)
Figure
7 Viewing the Preferred Networks tab.
There are no preferred networks listed. To add a wireless network to this list, click the Add button; you should see the screen shown in Figure 8.
)
Figure 8 Adding network properties for a preferred network type.
){kind=link}
In the first box, enter the network name, also known as the Service Set Identifier (SSID). Make sure that it is the same name as the one being broadcast by one of the wireless network routers (or access points) on your network. In the Wireless network key section, there are three check boxes for security purposes. The first one is for data encryption (it is checked by default). By having this box checked, your wireless network will be as secure as a wired one without any encryption.
The next option for shared mode authentication tells Windows to require key authentication defined by the IEEE 802.11 wireless protocol standard. If left disabled, open system authentication is used. Open system authentication is actually no authentication at all; it uses the wireless client's network adapter MAC address for identification when making a connection. The last option, when enabled, tells Windows to provide the WEP (Wired Equivalent Privacy) encryption key automatically when encrypting and decrypting data routed between your wireless network clients.
IEEE 802.1x is the open standard protocol for wireless networks. Click the IEEE 802.1x tab to see the properties that can be set when this protocol is used (the default). You should see a screen similar to the one shown in Figure 9.
)
Figure
9 Setting the IEEE 802.1x properties.
The first option you can set is for the EAPOL (Extensible Authentication Protocol) start message. Its job is to accept and authenticate requests between wireless clients. You can choose to have the client transmit (default) after a request is acknowledged, not transmit, or transmit per IEEE 802.1x. The last setting (transmit per IEEE 802.1x) tells the wireless client to authenticate each packet before transmitting data back. In effect, this would be more secure, but also cause some latency. The parameters for the start message can also be set in seconds. You can define how long you want the request to be examined and authenticated before transmitting. The default settings here are adequate because they allow for enough time for verification.
Because the EAP protocol uses certificates known as EAP-TLC certificates for authentication (much like SSL), the next setting that can be applied is the EAP type. It can be in the form of a Smart Card or other certificate, or protected. Click the Settings button; you should see a screen similar the one shown in Figure 10.
)
Figure
10 Setting the EAP type.
When connecting, the first option is set by default to search for a valid certificate on the client machine to perform authentication. Windows XP clients for wireless authentication cannot use Smart Cards. The next option tells the client to validate the certificate that was selected (also the default). The list at the bottom of this property sheet is root certificate authorities, which issue the certificates, much as Versign does for an SSL certificate. You can check off which ones your clients will trust when making a validation.
The last option is for times when a user is logged into the client computer. The user must have permission to use the certificate. If you create one type of user that has this permission, you can check this box and indicate which user it is. This way, only one user has to have the permission and be assigned, instead of going through all wireless client users and giving them explicit permissions to use EAP-type certificates. Click OK or Cancel; now you should be back at the IEEE 802.1x property sheet.
The last set of options is for the way authentication is handled. The first option, if checked, tells the client to authenticate the request as guest if no other user credentials are found or available. The next option, Authenticate As Computer When Computer Information Is Available, tells the client to accept requests based on the computer's identification instead of a user that would log on. You can also use computer and user authentication together. The Computer Authentication drop-down menu has three choices. If you choose With User Authentication from this list, the client will authenticate by computer credentials if no user is logged on. If a user logs on, credentials are maintained by using both user and computer credentials. If the user logs off, the connection is lost because both credentials are no longer there (computer and user). With the second option, With User Re-authentication, computer credentials are used if no user is logged on. If a user logs on, the user credentials are used; if the user logs off, computer credentials are used again. This is the default selection because it ensures a connection from the client computer, whether a user is logged on or not. The last option is Computer Only, which tells the client to user computer credentials only and to disregard user credentials altogether.