This command-line tool has practically the same possibilities and features as the Kerberos Tray tool described earlier. This tool has the following commands:
klist tgt displays the initial TGT.
klist tickets lists all cached tickets.
klist purge allows you to delete a specific ticket in a dialog.
Here is an example of such a dialog:
C:\>klist purge Cached Tickets: (10) Server: krbtgt/SUBDOM.NET.DOM@NET.DOM KerbTicket Encryption Type: RSADSI RC4-HMAC (NT) End Time: 6/12/2002 1:33:40 Renew Time: 6/18/2002 15:33:40 Purge? (y/n) : y Deleting ticket: ServerName = krbtgt/SUBDOM.NET.DOM (cb=42) RealmName = NET.DOM (cb=14) Submit Buffer size = 84 Ticket purged!
You must answer "yes" or "no" for each ticket.
If the client has no cached tickets, the tool returns the "Cached Tickets: (0)" message.
The SDCheck command-line tool is primarily intended to help administrators verify and monitor the following issues related to directory objects' security descriptors:
Propagation of inherited ACLs for a specified directory object
Replication of ACLs between different domain controllers
Let us consider how to fulfill these tasks using the following sample output. In this scenario, we will test the ACLs of a user object (Alice@net.dom) that belongs to a nested OU. (A domain controller must also be specified in the command.) Some lines, as well as the comments placed in the text below these lines, are shown in bold.
C:\>sdcheck netdc1.net.dom Alice@net.dom Security Descriptor Check Utility - build(3621) Input: Alice@net.dom Object: CN=Alice, OU=Marketing, OU=Staff, DC=net, DC=dom Domain: net.dom Domain: DC=net, DC=dom Server: netdc1.net.dom *** Warning: No values returned for dSCorePropagationData on DC=net, DC=dom Object: CN=Alice, OU=Marketing, U=Staff, DC=net, DC=dom Classes: top person organizational Person user SD: 2060 bytes Metadata: 06/13/2002 20:26:22 @ netdc4.net.dom ver: 3 History: 06/13/2002 20:28:43 flags(0x1) SD propagation 06/13/2002 20:36:08 flags(0x1) SD propagation 06/13/2002 20:49:29 flags (0x1) SD propagation 06/13/2002 20:51:06 flags (0x1) SD propagation [By viewing metadata on different DCs, an administrator can monitor the replication of the changed security descriptor. For example, you can note that the version number on another DC differs from the version shown, and that another DC has originated the changes. To view the replication metadata, you can also use the repadmin /showmeta command.] Object: OU=Marketing, OU=Staff, DC=net, DC=dom Classes: top organizationalUnit SD: 1332 bytes Metadata: 06/13/2002 20:20:41 @ netdc1.net.dom ver: 3 History: 06/13/2002 20:28:43 flags (0x1) SD propagation 06/13/2002 20:36:08 flags (0x1) SD propagation 06/13/2002 20:49:29 flags (0x1) SD propagation 06/13/2002 20:51:06 flags (0x1) SD propagation Object: OU=Staff, DC=net, DC=dom Classes: top organizationalUnit SD: 1332 bytes Metadata: 06/13/2002 20:51:06 @ netdc1.net.dom ver: 6 History: 06/13/2002 20:22:10 flags (0x1) SD propagation 06/13/2002 20:49:29 flags (0x1) SD propagation [Take note of the lines within the object's history. This information helps an administrator to trace changes and determine their originating container. For example, the changes made at the Staff OU level at 30:51:06 have been successfully propagated to all child objects including Alice's user object. At 20:49:29, the domain security descriptor has been changed, and the changes have been extended through the entire domain. If the time values are different at some levels, the inheritance might be blocked and this fact should be tested.] Object: DC=net, DC=dom Classes: top domain domainDNS SD: 1400 bytes Metadata: 06/13/2002 20:49:29 @ netdc1.net.dom ver: 4 Checking ACL inheritance ... [This test will display the ACL inheritance errors at any level if such an error has been found.] Parent: 3 - DC=net, DC=dom Child: 2 - OU=Staff, DC=net, DC=dom *** OK Checking ACL inheritance ... Parent: 2 - OU=Staff, DC=net, DC=dom Child: 1 - OU=Marketing, OU=Staff, DC=net, DC=dom *** OK Checking ACL inheritance ... Parent: 1 - OU=Marketing, OU=Staff, DC=net, DC=dom Child: 0 - CN=Alice, OU=Marketing, OU=Staff, DC=net, DC=dom *** OK
The output shown is an example of a successful test.
To verify the "continuity" of the inherited ACLs, use the -debug parameter. Suppose, in our example, that propagation of ACLs is blocked at the Marketing OU level. This means that the Inherit from parent the permission entries that apply to child objects checkbox on the Permissions tab in the Advanced Security Settings window has been cleared. To see this window, open the Marketing's Properties window and click Advanced on the Security tab. (In Windows 2000, the Allow inheritable permissions from parent to propagate to this object checkbox on the Security tab is used for that purpose.)
In our case, you can quickly diagnose whether an inheritance is blocked or not by using the command:
C:\>sdcheck netdc1.net.dom Alice@net.dom -debug
At a specific moment, the tool outputs a warning:
... Checking ACL inheritance ... Parent: 2 - OU=Staff, DC=net, DC=dom Child: 1 - OU=Marketing, OU=Staff, DC=net, DC=dom *** Warning: Child has SE_DACL_PROTECTED set, therefore doesn't inherit - skipping test *** OK ...
If the ACL inheritance is not blocked, the test will run without any warnings.