A:
Usually, this outcome is the result of a permissions issue; you might have sufficientpermissions to view a Group Policy Object (GPO) link but not to actually edit the GPO. Figure 8.12 shows an example of a message you might see when trying to edit a GPO.
Figure 8.12: Viewing an inaccessible GPO.
The error—inaccessible GPO-Access Denied—is typically caused by the fact that the user who is trying to edit that GPO does not have Read permissions on the GPO. In this case, the access control list (ACL) on the GPO didn’t contain the Authenticated Users group, which normally has Read permissions as a minimum setting on all GPOs. Figure 8.13 shows this GPO’s ACL, which doesn’t contain the Authenticated Users group, resulting in the error.
Figure 8.13: Viewing the ACL on a GPO that results in an inaccessible error.
Special care needs to be taken when removing the Authenticated Users group permission from a GPO. By removing this permission, you effectively prevent all users from being able to read, and thus process a GPO. A user receiving an inaccessible error message can sometimes be a good thing. For example, if the GPO controls security on your domain, you probably don’t want a user account that doesn’t process machine-specific security GPO in the first place to even be able to see it, let alone edit it. You’ll also note that in Figure 8.12, the Edit button is grayed out,
indicating that the user doesn’t have write permissions on the GPO either.
Permission problems can be tricky, but typically the problem comes down to overlooking a simple granting (or removal) of permissions to straighten things out.
Q 8.7: When I try to edit a Group Policy Object, I get an error message
that says the domain controller is not found. DNS isn’t the problem,
what else could it be?
A:
This problem is a known issue when trying to edit Active Directory (AD)-based Group Policy when Microsoft File and Print Sharing has been disabled on the PDC role holder in your domain. Because the ability to edit a Group Policy Object (GPO) relies on File and Print Sharing (and specifically file services) to be available, this service needs to be running in order for you to be able to successfully edit a GPO. Remember that, by default, the Group Policy Microsoft Management Console (MMC) snap-in tries to connect to the PDC emulator within your AD domain first when opening a GPO. If File and Print Sharing services are not running on the PDC role holder, you might get a message similar to the one that Figure 8.14 shows.Figure 8.14: Viewing the error message you receive when you try to edit a GPO while File and Print Sharing services are disabled.
If you choose one of the other options that Figure 8.14 shows, you might get another error message, as Figure 8.15 shows.
After you receive the error message that Figure 8.15 shows, a curious thing will happen. If you try to view the GPOs in your domain from that Active Directory Users and Computers MMC snap-in, the list of GPOs linked to a particular container will appear empty; very disconcerting! The quick and easy solution to this problem is to verify that File and Print Sharing services are enabled on the PDC role holder in your domain (at the least). To do so, bring up the network connections applet—I like to simply type ncpa.cpl from a command line in Windows 2000 (Win2K) or Windows XP to start the applet. Right-click the Local Primary Area Connection applet, choose Properties from the context menu, and make sure that the File and Printer Sharing for Microsoft Networks check box is selected (see Figure 8.16).
Figure 8.16: Viewing the dialog box to enable File and Print Sharing in Win2K.
After you re-enable File and Print Sharing, you should be able to successfully connect to and edit GPOs. The interesting part of this problem is that, with this service disabled, you can’t even connect to GPOs if you are sitting at the console of the PDC role holder domain controller. So you don’t have to be remote to feel the effects of this configuration problem.
Q 8.8: I’m having problems with security policy processing. Is it
possible to get more in-depth troubleshooting information than that
provided by the event logs?
A:
Yes, you can enable verbose security policy logging that provides much more detailed information than you can get from even the verbose Group Policy Object (GPO) logging that is written to the Application event log or %systemroot%\debug\usermode\userenv.log. To enable verbose security policy logging, you will need to add a value to the registry. Fire up regedit.exe or regedt32.exe and navigate toHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\G PExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}. Within this GUID-named key, add a new value of type REG_DWORD called ExtensionDebugLevel, and give it a value of 2. The change will take effect right away. The log file that is created by this registry entry is called %systemroot%\security\logs\winlogon.log.
If you don’t see winlogon.log appear on a Windows 2000 (Win2K) workstation after enabling logging, try applying Service Pack 3.
Winlogon.log is a text file that contains quite a bit of information about the processing of security policy. You can see the effects of this logging immediately by triggering a background refresh of policy using secedit.exe:
Secedit /refreshpolicy machine_policy
Figure 8.17 shows a sample of a log file generated by this registry key change.