Access Control

Access control problems can manifest themselves when you cannot access Active Directory objects. They can also happen when you get "Access Denied" errors when trying to map to another network resource, or when trying to run net view at the command prompt to, see a particular server.

This section discusses diagnostic tools and gives examples of possible access control problems, along with suggested solutions. The first step toward identifying and diagnosing Active Directory access control problems is to find out the security descriptor of the object being accessed, and then to look in Event Viewer.

Event Viewer

To view access control errors, you need to activate auditing. Then you can see events logged in the Security log.

Gaining Access to Other Computers

The Net view command-line tool enables you to determine whether you can gain access to other network computers. To view the computer, to determine whether you can access other computers, carry out the following:

net view \\<computer name >

Determining Whether You Can View Other Computers

If you can view other computers, can you use the computer to connect to your domain by using net use \\server1\ipc$ /u:reskit\<user > <password > ? If you do have connectivity, can you establish a connection through a local domain account? If the first option fails, this indicates a problem with the trust links. To correct problems with the trust links, run Nltest.exe as shown in the following example:

nltest.exe /server:<server> /sc_query:<domain of server that is failing>

e.g. nltest /server:server1 /sc_query:reskit

• If the result from the Nltest.exe comes back with a specific server (server1) error, ensure that that domain controller has connectivity to the domain controller of the secure channel query. Test each server by using ping and net view commands to ensure server functionality.

  • If ping works, but net view doesn't, verify the type of name resolution (for example, WINS or DNS).

  • If ping does not work, verify transport connectivity or functionality status of the server in question. (Note that the server might not be running TCP/IP.)

  • If the domain controller and connectivity are good but, net use still fails, attempt to reset secure channel by using nltest /server:<server > /sc_reset:<domain of server that is failing > .

Note

You must be connected as an Administrator to the target < server >.

If you ** cannot connect to your domain and cannot establish a connection through a local domain account, the LSA and SAM might be the problems. If you receive an error message while running the net view \\<server>** or net use command, do the following:

• When a computer is not able to be authenticated by any domain user, the first step is to try to ping the computer.

  • If there is no response to the ping, perform a local review. Do this by verifying whether your computer has bug checked or access violated. If not, verify the local IP address returned by DNS by using the ping command. (For example, is the IP address returned from the ping the same as the local IPConfig/all address?)

  • If you can obtain the IP address of the computer by using ping , is the computer viewable by using the net view command. In other words, does it return "access denied" or the share list? If not, WINS or the SMB Services might be suspect. Perform a Network Monitor sniffer trace to determine which name server is responding and, with what address. Verify the address returned to the server in question. If they do not match, this indicates a name server inconsistency. If they do match, a sniffer trace might help identify the error.

Gaining Access to Active Directory Objects

If you have a problem gaining access to Active Directory objects, this is almost always because the ACL embedded in the security descriptor for the object does not explicitly grant access to the person performing the operation.

Using Dsacls to View an Object's Security Descriptor

To view the security descriptor of an Active Directory object, you can use the Dsacls command-line tool. By using Dsacls.exe, you can view the security descriptor for an object, which includes the ACL. The ACL contains the discretionary access control list (DACL) and the system access control list (SACL)

The DACL identifies the permissions or rights that particular security groups have with regard to the Active Directory object. If it is not obvious why the DACL doesn't grant the user the access privileges he or she desires, you have to reset the permissions and add permissions so that you can gain access to the appropriate resource.

Note

There are other ways to view the ACL. For example, from the Security tab in the various consoles.

Resetting the permissions might fix the particular problem, but it might affect another area. It is more reliable to add the required permissions. Alternately, if the permissions on the object are set such that no meaningful access is possible, resetting them to default might be the only option.

Using SDCheck to Verify ACL Inheritance

To verify that ACL entries are being propagated correctly through parent-child relationships, use the sdcheck (Security Descriptor Check) command-line tool. You can determine whether ACLs are being inherited correctly and if ACL changes are being replicated from one domain controller to another. For more information about inheritance, see "Access Control" in this book.

To list all of the ACEs that are inherited from the parent to the child, for the child object that is having its password ACLs changed, you can use the sdcheck/dumpall command.

Viewing ACEs with the Ldp Tool

To view ACEs for particular Active Directory objects, use the Ldp.exe tool included in the Microsoft Windows 2000 Resource Kit companion CD. To use this tool select the security principal (object) of reference, such as cn=<user1>, cn=Users, cn=Domain, dc=<domain name>, dc=<root domain>, and so on. From the Browse menu, click the security descriptor for the object of reference to provide the default access control list and the system access control list in a low-level format.

Taking Ownership of an Object and Resetting the ACL

Another benefit here is that, if you have an administrator who inadvertently set an access control so that nobody can view an object in the directory, you can use ADSIEdit to take ownership of that object and reset the ACL to one where users can do that. For more information about ACLs, see "Access Control" in this book.

Using the Netdom Tool to Maintain Your Enterprise

You can use Netdom to manage computer accounts for member workstations and member servers. The options of Add, Remove, and Query, allow you to specify the OU for the computer account, move an existing computer account for a member workstation from one domain to another, and list the member workstations or servers in a domain.

Only certain objects are supported for each command. These objects are listed in Table 10.9.

Table   10.9 Netdom Tool Commands

Auditing Policy

To be able to track user activity, you need to establish an auditing policy. An auditing policy defines the kinds of events that you want to monitor for a particular group of users. It is defined on the SACL.

The following includes the implementation sequence for establishing an auditing policy:

• Enable auditing policy for the domain controller

• Set an auditing SACL on the object of interest

• Force object access

• Check the audit log

Enable Auditing Policy for the Domain Controller

The first procedure to implement is an auditing policy to enable the domain controller to audit the actions of specified security principals. You must be logged on as a member of the Administrators group to perform this procedure.

To enable the auditing policy for the domain controller

1. From the Start menu, select Programs , Administrative Tools , and Active Directory Users and Computers .

2. Locate the container holding the domain controller, and then right-click it to display the Properties page.

3. Click the Group Policy tab, and then click Edit to edit the Default Domain Policy ( <domain controller name> ) from the Group Policy window.

4. In the left pane, click Computer Configuration .

5. In the right pane, double-click each of the following in succession: Windows Settings , Security Settings , and Local Policies .

6. Double-click Audit Policy . The right pane includes an entry named Audit Directory Service Access .

7. Double-click Audit Directory Service Access , and then enable or disable successful or failed access attempts. Because domain controllers poll for policy changes every five minutes, it is best that these modifications take effect within five minutes. Then other domain controllers are updated at the next replication interval. Click OK .

Note

For more information about specific auditing options, see "Group Policy" in this book.

Set an Auditing SACL on the Object of Interest

The next procedure in implementing an auditing policy is to set an Auditing SACL on the objects of interest. You must be logged on as a member of the Administrators group to perform his procedure.

To set an Auditing SACL on the object of interest

1. From the Start menu, select Programs , Administrative Tools, Active Directory Users and Computers .

2. On the View menu, select Advanced Features .

3. Locate the container holding the objects, and right-click it to display the Properties page.

4. Open the container holding the object of interest by double-clicking it.

5. Right-click the object to display the Properties page, and select the Security tab.

6. Click Advanced , and then select the Auditing tab.

7. Click the Add button to display the Select User, Computer, orGroup dialog box where you can specify whose actions to audit. Select a security principal name and click OK .

8. The Auditing Entry for Administrator dialog box displays with two tabs: Object and Properties .

   • The Object tab lets you identify generic and control rights to audit.

   • The Properties tab lets you identify property accesses to audit.

   Decide what the object access and rights apply to by choosing from the selections in the pull-down list. (The default is "this object and all child objects.") Click each tab you want to modify and check the boxes for the accesses or properties that you need to audit. When you are finished, click Apply , and then click OK .

9. At the Access Control Settings window, determine whether auditing entries must be inherited from the parent container to propagate this object. If so, check the Allow inheritable auditing entriesfom parent to propagate to this object box. When you are finished, click Apply and then click OK .

10. At the Properties window, determine whether auditing permissions must be inherited from the parent container to propagate this object. If so, check the box. When you are finished, click Apply and then click OK .

Access and Use Objects

After the domain controller and object auditing entries are made, perform a test to ensure the auditing policy is implemented according to your requirements. To do this, you must have a reference indicating the objects, security principals, types of access and entries that comprise the auditing policy. Create a test plan that lists a sampling of the accesses and actions for each security principal for which you have an auditing policy. Perform consecutive logons, logging in under a different security principal each time and performing the actions from auditing policy test plan.

Check the Audit Log

The last part of the implementation of an auditing policy is to verify that the auditing policy works as expected by reviewing the results of your test plan. To do this, use the Event Viewer MMC snap-in. Browse the ** Security log. To refresh the window to see the most recent access, press F5. The events are displayed according to the event category to which they pertain. Each entry provides an audit trail of who gained access to what at what time and whether they were denied access.

For more information about auditing, see Windows 2000 Server Help.