Export (0) Print
Expand All
Expand Minimize
2 out of 4 rated this helpful - Rate this topic

Appendix E: Relevant Windows and UNIX Tools

Published: June 27, 2006
On This Page

Purpose of this Appendix Purpose of this Appendix
Windows Server 2003 Tools Windows Server 2003 Tools
UNIX Tools UNIX Tools

Purpose of this Appendix

This appendix highlights tools administrators and help desk staff will find useful for troubleshooting and other development or deployment-related tasks required by the end states described in this guide.

Windows Server 2003 Tools

Sources for Windows Server 2003 Tools

Microsoft® Windows Server™ 2003 provides a variety of tools to support configuration and diagnosis of interoperability between Windows and UNIX environments. Some of these tools (native) are included with the standard Windows Server 2003 installation, others are available in the Windows Server 2003 Support Tools or the Windows Server 2003 Resource Kit, and others are available as open source or third-party tools.

The organization of the following sections is based on the function or purpose of each tool.

In-Depth Survey of Windows Server 2003 Tools

The following tools are grouped according to their function or application.

Windows Directory Service Update and Query Tools
Active Directory

The following command-line tools can be used to manage objects in Active Directory® directory service. In the context of this guide, they are most useful for scripting directory updates. The update tools and their functions are:

  • dsadd. Adds objects to the directory.

  • dsmod. Modifies select attributes of an existing object in the directory.

  • dsmove. Moves an object from its current location to a new parent location.

  • dsrm. Removes an object, the complete subtree under an object in the directory, or both.

These tools are included with the standard Windows Server 2003 installation. For further information, see “How To Use the Directory Service Command-Line Tools to Manage Active Directory Objects in Windows Server 2003” at
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B322684.

The following command-line tools can be used to search for and display Active Directory objects:

These tools are also included with the standard Windows Server 2003 installation. For further information, see
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B322684.

  • setspn. The setspn command-line tool can be used to view and update the Service Principal Names (SPNs) of Active Directory computer and service objects. In the context of this guide, it is most useful for checking the SPN of UNIX-based computer accounts using the following syntax, where hostname is the account name of the Active Directory object:

    setspn -L hostname

    The setspn tool is available with the Windows Support Tools. For further information about the setspn tool, see http://technet2.microsoft.com/WindowsServer/f/?en/Library/eb0d5bd1-89c3-4ee7-975f-596b2e37e3aa1033.mspx.

gpupdate

The gpupdate command-line tool can be used on a server running Windows Server 2003 to refresh Group Policy settings. In the context of this guide, it is most useful for forcing an immediate Group Policy update after a policy change using the following syntax:

gpupdate /force

The gpupdate tool is included with the standard Windows Server 2003 installation. For further information, see http://technet2.microsoft.com/WindowsServer/f/?en/Library/6880fef3-76b7-4eb3-b993-fa00799615851033.mspx.

ldifde

The command-line ldifde tool can be used on a server running Windows Server 2003 to import to or export from the database directory. In the context of this guide, it is most useful to export the attributes for user, group, and/or computer objects to a file. The tool offers many switches. For each export, the –f switch (followed by a path and file name to contain the output data) is required. In addition, other switches allow you to limit the request to objects matching selected attributes and to specify the attributes that should be returned for each selected object. If the command is executed on the domain controller, the root distinguished name (also known as DN) and server name need not be specified. See the following examples. The attributes and objects are not case sensitive.

This command outputs the entire directory tree, including all objects and all attributes for those objects, to the output1.txt file:

ldifde -f c:\test\output1.txt

This command outputs the sAMAccountName, servicePrincipalName, and userPrincipalName attributes for the User objects to the output2.txt file:

ldifde -f c:\test\output2.txt -r "(objectClass=user)" -l 
"sAMAccountName, servicePrincipalName, userPrincipalName"

The ldifde tool is included with the standard Windows Server 2003 installation. For further information, see http://technet2.microsoft.com/WindowsServer/en/Library/32872283-3722-4d9b-925a-82c516a1ca141033.mspx.

ADSI Edit MMC Snap-in Tool

The ADSI Edit MMC snap-in tool can be used to view and modify attributes of directory service objects. In the context of this guide, this tool is most useful for viewing the Windows Services for UNIX attributes for user and group objects and the principal name attributes for computer objects. The ADSI Edit snap-in is easier to use than ldp for directory modifications.

The adsiedit tool is available with the Windows Support Tools. For further information about the adsiedit.msc tool, see http://technet2.microsoft.com/WindowsServer/f/?en/Library/ebca3324-5427-471a-bc19-9aa1decd3d401033.mspx.

Note   This tool is also useful in the context of testing and troubleshooting to view LDAP attributes for users and computers through a GUI interface. See the “Windows LDAP Troubleshooting Tools” section below.

ldp

The GUI ldp tool can be used to view and modify attributes of directory service objects. In the context of this guide, the tool is most useful for viewing the attributes of user, group, and computer objects. (See also the discussion of the ldp tool in the “Windows LDAP Troubleshooting Tools” section.) The tool offers many options and can be used to browse the directory for user, group, and computer information as follows:

  1. Open the tool and choose Connection and Connect. If you are using the tool on the domain controller, you may leave the Server field blank, and then click OK.

  2. Choose Connection and Bind and enter the user name and password for a user with sufficient permissions to view the objects in which you are interested. If you plan to update data, this user must have administrative permissions. If you are using the tool on the domain controller, you may leave the Domain field blank, and then click OK.

  3. Choose View and Tree and enter the base DN for the container you want to browse. If you are using the tool on the domain controller and want to view the entire directory, you may leave the BaseDN field blank, and then click OK.

Note   The ADSI Edit snap-in tool is easier to use than ldp for directory modifications.

The ldp tool is available with the Windows Support Tools. For further information about the ldp tool, see http://technet2.microsoft.com/WindowsServer/f/?en/Library/eb0d5bd1-89c3-4ee7-975f-596b2e37e3aa1033.mspx.

ktpass

The ktpass command-line tool is used to create key tables for transfer to UNIX-based computers. This tool does not create directory service accounts for the principals whose keys will be placed in these key tables. Accounts must first be created through Active Directory Users and Computers (or an alternate). The ktpass tool offers many switches. In the context of this guide, the most useful switches are:

  • -out. The path and file name for the key table to be created.

  • -pass. The password being set for the principal being added to the key table. The password is set at the time the command is run and need not match the password used when the account was originally created in Active Directory Users and Computers. The password must comply with the password policy for the domain.

  • -princ. The service principal name to be assigned to the previously created account. This name does not match the account name used to create the account through Active Directory Users and Computers. The service principal name populates the userPrincipalName and servicePrincipalName attributes. For PAM authentication on UNIX, the service principal name is always of the form host/hostname@REALM, where hostname is the fully qualified domain name (FQDN) of the UNIX-based computer for which the key table is being generated.

  • -mapuser The account name created for this principal through Active Directory Users and Computers.

  • -ptype The principal type. When creating key tables for PAM authentication on UNIX, the ptype is always KRB5_NT_SRV_HST, meaning that the principal is of the form host/hostname.

The ktpass tool is available with the Windows Support Tools. For more information about the ktpass tool, see http://technet2.microsoft.com/WindowsServer/f/?en/Library/eb0d5bd1-89c3-4ee7-975f-596b2e37e3aa1033.mspx.

ksetup

In an End State 5 solution, the ksetup command-line tool is used on both Windows domain controllers (on an Active Directory–based network, the Kerberos Key Distribution Center [KDC] is implemented as a domain service and each Active Directory domain controller runs the KDC service) and on Windows clients to configure cross-realm authentication with KDCs that are not part of Active Directory. The ksetup tool offers many switches. In the context of this guide, the most useful switch is:

  • /AddKdc. Adds the specified KDC in a foreign (UNIX) realm to the configuration on the local Windows-based computer, making it a valid KDC for authentication. This command is used on both the Active Directory domain controller and each Windows client that needs to access the foreign realm. These configuration mappings are stored in the registry:

    HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Domains

The following switches are used when configuring a Windows-based client computer as a member of a UNIX realm. They are executed on each Windows-based client computer that will be a member of the UNIX realm. Configuring the Windows client in this way allows a user to authenticate to a UNIX KDC during logon to the Windows-based computer.

  • /SetRealm. Joins the Windows client on which it is run to the foreign (UNIX) realm.

  • /SetComputerPassword. Sets the machine account password for the Windows client that is joined to the UNIX realm.

  • /MapUser. Maps a local user on the Windows-based computer on which it is run to a principal in the database of the UNIX KDC.

The ksetup tool is available with the Windows Support Tools. For further information about the ksetup tool, see http://technet2.microsoft.com/WindowsServer/f/?en/Library/eb0d5bd1-89c3-4ee7-975f-596b2e37e3aa1033.mspx.

netdom

The netdom command-line tool can be used to configure cross-realm trusts between a Windows realm and a foreign (for example, UNIX) realm. This tool is more useful for configuring a server running Microsoft Windows® 2000 than a server running Windows Server 2003. All the main cross-realm configuration steps can be accomplished with the New Trust Wizard in Windows 2003.

The netdom tool is available with the Windows Support Tools. For further information about the netdom tool, see http://technet2.microsoft.com/WindowsServer/f/?en/Library/eb0d5bd1-89c3-4ee7-975f-596b2e37e3aa1033.mspx.

Schema Management MMC Snap-in Tool

This tool is used to view the schema attributes—not the data stored in these attributes for a given object. It is not useful in the context of this guide because the schema is being extended through the use of Windows Services for UNIX.

Windows Service for UNIX Attributes MMC Snap-in Tool

This tool is used to view the UNIX attributes for a particular user. It adds a UNIX Attributes tab to user and group account properties sheets in Active Directory Users and Computers.

This tool is included as part of Windows Services for UNIX, available from http://www.microsoft.com/technet/interopmigration/unix/sfu/default.mspx.

Note   The UNIX Attributes tab for a UNIX group in Active Directory Users and Computers lets you populate the msSFU30PosixMember attribute for groups; however, you cannot use this tab to populate the msSFU30MemberUid attribute. You cannot map the msSFU30PosixMember attribute to the memberuid attribute on the UNIX-based computers because msSFU30PosixMember is a distinguished name (also known as DN) and the UNIX memberuid is an IA5String, as is msSFU30MemberUid. Therefore, you must use the ADSI Edit tool to add UNIX attributes to UNIX group accounts. For more information, see "Add UNIX Attributes to Test Groups and Users" in Chapter 4: "Developing a Custom Solution" for steps showing you how to add UNIX attributes to UNIX group accounts.

Third-Party LDAP Database Viewing Tools

There are many third-party LDAP database viewing tools for Windows. Some of these include:

  • Softerra LDAP Browser. The Softerra LDAP Browser is a third-party LDAP database viewing tool for Windows. It is available at http://www.softerra.com.

  • JXplorer Java LDAP Browser. The JXplorer Java LDAP Browser is a third-party LDAP database viewing tool for Windows. It is available at http://www.pegacat.com.

  • Open source ldapsearch. Idapsearch is an open source tool that can be compiled for Windows. It is available at http://www.openldap.org.

Windows Infrastructure Troubleshooting Tools
Event Viewer

Windows Event Viewer is used to view the log (also called event logging) of informational, warning, and error messages for the operating system and other applications generated on the Windows-based computer. It can be helpful when troubleshooting authentication and authorization issues.

By default, Event Viewer logs messages related to time synchronization problems or DNS problems. However, as installed, Windows Server 2003 logs a minimal level of events related to Kerberos or LDAP. Therefore, it might be helpful to enable extended logging of these types of messages when troubleshooting authentication and authorization failures. For information about using the event log for Kerberos troubleshooting, see “Windows Kerberos Troubleshooting Tools” later in this appendix. For information about using the event log for LDAP troubleshooting, see “Windows LDAP Troubleshooting Tools” later in this appendix.

dnslint

The dnslint tool is a command-line tool that allows you to verify Domain Name System (DNS) records. This can be useful for troubleshooting Kerberos errors because Kerberos is very sensitive to minor DNS problems. You can use dnslint to verify the responsiveness of, and records stored in, DNS servers and to look up host name and IP address data for a specified UNIX-based or Windows-based computer to confirm that the data exists and is correct.

The dnslint tool is included with the Windows Support Tools.

For more information about dnslint, see:

nslookup

The nslookup command-line tool is an alternative to dnslint that you can use to verify DNS records. The nslookup tool can be useful for troubleshooting Kerberos errors because Kerberos is very sensitive to minor DNS problems. You can use the nslookup tool to make a request to a DNS server to resolve a specific host name or IP address for a computer in your environment specified in the command-line request. The nslookup tool does not accept wildcards for DNS lookups but can be scripted to look up multiple addresses from an input list.

The nslookup tool is available in both the native Windows and UNIX operating systems.

Before the development of dnslint, the nslookup tool was used frequently to diagnose and troubleshoot these types of DNS issues. Nslookup lets you manually review a DNS infrastructure, inspecting specified DNS records. However, dnslint offers quicker verification that record-level data is correct. More information about nslookup is available at http://technet2.microsoft.com/WindowsServer/f/?en/Library/db804115-3437-4f7e-872e-ec744c6220751033.mspx.

pathping

The pathping command-line tool is an enhanced version of the ping tool. You can use pathping to verify connectivity to another host and to provide information about network latency and network loss for the path between the client and host. This tool is useful at a very basic level for both Kerberos and LDAP troubleshooting to investigate networking issues. The pathping command is included as part of the basic installation of Windows XP and Server 2003.

More information about pathping is available at http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/pathping.mspx?mfr=true.

ping

The ping command-line tool is used to verify connectivity to another host. It is useful at a very basic level for both Kerberos and LDAP troubleshooting to determine whether a given Active Directory server can be contacted from the UNIX client. The ping command is included as part of the basic installation of Windows and UNIX distributions.

netdiag

The netdiag command-line tool can be used to troubleshoot and correct network connectivity issues. In the context of this guide it is most useful for testing and correcting DNS issues when using the following switches:

  • /test:dns. Tests DNS configuration.

  • /fix. Corrects minor DNS configuration problems.

The netdiag tool is available with the Windows Support Tools. For further information about netdiag, see http://technet2.microsoft.com/WindowsServer/f/?en/Library/eb0d5bd1-89c3-4ee7-975f-596b2e37e3aa1033.mspx.

Windows Kerberos Troubleshooting Tools

This section provides explanation of some of the standard tools an administrator or help desk staff will use to diagnose and troubleshoot issues that may arise during the Developing, Deploying, and Stabilizing Phases of implementation.

Event Viewer

The Windows Event Viewer, as stated earlier, is used to view the log of informational, warning, and error messages for the operating system and other applications generated on the Windows-based computer. The following section details configuring the Windows Event Viewer to display additional Kerberos-specific information.

To enable extended Kerberos logging

  • Add a DWORD registry entry of LogLevel in the following location, and set it to 1:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

    The server must be restarted after this change before the logging will be implemented.

Repeat the above steps for each Active Directory server where extended logging is desired.

For more information about Kerberos event logging, see http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/b36b8071-3cc5-46fa-be13-280aa43f2fd2.mspx and http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx.

KerbTray

The Kerberos Tray tool, KerbTray, (kerbtray.exe) is a Windows-based GUI tool that displays Kerberos ticket information on a Windows-based computer where Kerberos tickets have been stored in the credentials cache. Kerberos tickets are acquired and stored in the credentials cache when a user logs on a Windows-based computer (client or server) as a domain user. KerbTray allows you to view and purge the ticket cache.

When executed, the tool places an icon in the system tray. This icon displays status based on the presence or absence of valid credentials. Data available through the KerbTray interface includes the time stamps on the tickets, the flags associated with the credentials (for instance, forwardable) and the encryption type(s) of the tickets.

The KerbTray tool is found in the Windows Server 2003 Resource Kit Tools and is available at http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en.

klist

The klist tool is a command-line tool that allows you to display the contents of the credentials cache and can be used on a Windows client to display or destroy existing Kerberos credentials. The klist tool requires an argument.

The "tgt" argument displays the credentials in the current cache, producing output similar to the following:

Cached TGT:
ServiceName: krbtgt
TargetName: krbtgt
FullServiceName: test01
DomainName: EXAMPLE.COM
TargetDomainName: EXAMPLE.COM
AltTargetDomainName: EXAMPLE.COM
TicketFlags: 0x40e00000
KeyExpirationTime: 0/39/4 0:00:10776
StartTime: 10/27/2004 7:54:06
EndTime: 10/27/2004 17:54:06
RenewUntil: 11/3/2004 7:54:06
TimeSkew: 11/3/2004 7:54:06

The klist tool is available on Windows as part of the Windows Server 2003 Resource Kit Tools and is available at http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en.

MIT Kerberos for Windows

The MIT Kerberos for Windows (KfW) package is a version of the standard MIT Kerberos product designed specifically for integration into Windows. It includes both GUI and command-line tools and is able to work with credentials both in the standard MIT credentials cache and the native Microsoft LSA credentials cache.

More information about MIT's Kerberos for Windows tool can be found at http://web.mit.edu/kerberos/www/kfw-2.6/kfw-2.6.5/relnotes.html.

Windows LDAP Troubleshooting Tools
Event Viewer

The Windows Event Viewer, as stated earlier, is used to view the log of informational, warning, and error messages for the operating system and other applications generated on the Windows-based computer. The following section details configuring the Windows Event Viewer to display additional LDAP-specific information.

To enable extended LDAP logging

  • Modify the DWORD registry entries in the following location:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

    Table E.1. Subkeys and Logging Levels for Extended LDAP Logging

    Subkeys

    Logging Levels

    Useful subkeys for LDAP logging include:

    • 2 Security Events

    • 3 Directory Access

    • 13 Name Resolution

    • 16 LDAP Interface Events

    The more keys you configure, the more overhead you incur.

    LDAP logging levels range from 1 to 5. For example, use:

    • 5 for maximum logging

    • 3 for medium logging

    • 1 for minimal logging

    You might want to specify 5 to start. If 5 logs too much data, scale back to a lower number. (The default value is 0, which specifies no logging.)

    Repeat these steps for each Active Directory server on which you want to configure extended logging.

ldp

In the context of testing and troubleshooting, this tool is most useful to browse LDAP attributes for users and computers through a GUI interface and to search for objects. You must be a knowledgeable LDAP user in order to make use of this tool. Its only advantages for the average user over the adsiedit tool are the following:

  • The capability to search for objects in a manner similar to ldapsearch, specifying, for instance, that you want to see the attributes for all objects whose sAMAccountName starts with "test."

  • The capability to see all attributes for a given object immediately instead of having to browse through attributes one-by-one as is necessary, to some degree, with adsiedit.

We do not recommend using ldp to make attribute updates because doing so is especially complex.

For more information about ldp, see the discussion of ldp in the section “Windows Directory Service Update and Query Tools” earlier in this appendix.

ADSI Edit MMC Snap-in Tool

In the context of testing and troubleshooting, this tool is most useful to view LDAP attributes for users and computers through a GUI interface and, as necessary, make updates to the attributes for these objects. It is much more user-friendly than ldp for this purpose. Among the behind-the-scenes LDAP tools (as opposed to Active Directory Users and Computers), this is the most useful tool. (See also the discussion of adsiedit in the “Windows Directory Service Update and Query Tools” section.)

Note   Also refer to the “Windows Directory Service Update and Query Tools” section for discussions on ldapsearch and other LDAP database viewing tools.

Windows Network Monitoring and Protocol Analysis Tools

Protocol analysis tools can help troubleshoot Kerberos and LDAP problems. They allow you to capture ("sniff") all packets sent between your UNIX-based client computer (configured for authentication and/or for authorization against Active Directory) and the Active Directory server. You can then review the packets to help determine why authentication (using pam_krb5 or pam_ldap) or authorization (using nss_ldap) is failing. These tools can be helpful for troubleshooting each end state described in this guide.

Two primary monitoring and analysis tools are available for the Windows platform:

  • Network Monitor. Network Monitor is included in the Microsoft Windows Server 2003 product. It is not installed as part of the base operating system and must be installed using Add/Remove Programs > Add/Remove Windows Components. It installs as part of the Management and Monitoring Tools option.

    Information about using Network Monitor is available at http://technet2.microsoft.com/WindowsServer/en/Library/ad2b59d1-0fb8-45e3-9055-a5aeba8817a91033.mspx.

    Information about using Network Monitor for Kerberos troubleshooting is available at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx.

  • Ethereal. Ethereal is an open source protocol analysis tool available in both Windows and UNIX versions from http://www.ethereal.com. (Also see the “UNIX Network Monitoring and Protocol Analysis Tools” section.) Unlike Network Monitor, Ethereal can be used to read trace files generated by many other applications, including the Solaris snoop tool. For Solaris solutions, it may be helpful to use the Solaris snoop command on the UNIX client and then read the snoop file with Ethereal.

For End States 1 and 2, each logon attempt with pam_krb5 generates as many as three requests with associated replies:

  1. An initial request for a TGT. This request is not accompanied by preauthentication data and may generate a response from the server that preauthentication data is required. For most configurations and logins, preauthentication data is required. If this is the case, the first request will receive an error response of KRB5KDC_ERR_PREAUTH_REQUIRED. If the user has been configured with the "Do not require Kerberos preauthentication" flag (required for Solaris native End State 2 logon via dtlogin due to a bug in the operating system), the ticket will be granted at this stage and request 2 will be skipped.

  2. A second request for a TGT accompanied by preauthentication data. If the user name and password provided were correct, the TGT will be granted.

  3. A service ticket request for the target host—principal host/hostname@REALM, where hostname is the fully qualified domain name (FQDN) of the UNIX client computer.

Some implementations do not request or require a service ticket. If the implementation requires a service ticket and the logon failure point is the service ticket request, Ethereal should show a request but an error in the response.

In some configurations, two sets of these messages may appear in the trace—one message for krbtgt/REALM for basic authentication and another message for kadmin/changepw password change support.

If no Kerberos packets are seen in the trace, the UNIX client is not attempting to send a Kerberos request or the Active Directory server has not received the request (assuming that the packet tracing tool is being run on the Active Directory server). For Solaris solutions, it may be helpful to use the Solaris snoop command on the UNIX client to determine whether packets are being requested. (See “UNIX Protocol Analysis Tools” section.)

For more information about interpreting Kerberos and LDAP packets, see the “Ethereal” section, below.

Note For End State 2, the instructions in Volume 2: Chapter 4, "Developing a Custom Solution," advise you first to configure the solution without TLS/SSL or Kerberos authentication for the LDAP connection and then implement TLS or Kerberos authentication for the LDAP connection after the solution is working correctly. The same recommendation is also true for End States 3 and 4. Part of the reason for this is that after the LDAP connection is secured, it becomes impossible to interpret the LDAP traffic with a tool such as Ethereal. (See the “Ethereal” section later in this appendix.) Because the tools do not decrypt the encrypted packets, the nature of the requests and returned data cannot be determined. If you encounter problems with the solution for these end states that requires troubleshooting with one of these tools, disable the security temporarily while troubleshooting.

UNIX Tools

This section highlights various tools and procedures helpful with general troubleshooting and diagnosis of issues that may arise during a deployment. This section provides explanation of some of the standard tools an administrator or help desk staff member will use to diagnose and troubleshoot issues that may arise during the Developing, Deploying, and Stabilizing Phases of implementation.

Sources for UNIX Tools

UNIX and Linux provide a variety of tools that you can use to support configuration and diagnosis of interoperability between Windows and UNIX environments. Some of these tools (native) are included with the UNIX or Linux operating system; others are available from third-party vendors or as free downloads.

You can find information about native UNIX tools and many open source UNIX tools by typing man command to view the UNIX manual page.

The organization of the following sections is based on the function or purpose of each tool.

In-Depth Survey of UNIX Tools

The following tools are grouped according to their function or application.

UNIX Directory Service Update and Query Tools
id

The id command-line tool is a native UNIX command-line tool that is used to output the user and group IDs of either the current user or a specified user. In the context of this guide it is most useful for validating that an Active Directory user's uid and gid are being resolved to the correct user name and group name.

groups

The groups command-line tool is a native UNIX command-line tool that is used to output the group IDs of either the current user or a specified user. In the context of this guide, it is most useful for validating that all of an Active Directory user's groups are returned and being resolved correctly to the group names after logon.

CSS ADKadmin

The CSS ADKadmin tool (css_adkadmin) is designed to allow a system administrator to manage user and computer accounts in an Active Directory database from a UNIX host. In the context of this guide, it is used to create service principals and write them to service key tables.

The tool is also useful for viewing attributes of user and computer accounts. The tool can be used from either the UNIX command line or through the tool's command shell. See the following examples.

The following command, executed from the UNIX command line, creates a service principal, host/unix01.example.com, with a DES key in the ou=computers,ou=unix,dc=example,dc=com container in Active Directory and writes it to the default service key table (/etc/krb5.keytab or /etc/krb5/krb5.keytab, depending on the platform) on the UNIX host. The Active Directory database is accessed as user adminuser.

css_adkadmin -p adminuser -q "ank +use_des \

-group ou=computers,ou=unix,dc=example,dc=com -k host/unix01.example.com"

The CSS ADKadmin tool is available for free download from Certified Security Solutions at http://www.css-security.com/downloads.html.

ldapsearch

The ldapsearch tool is a native UNIX command-line tool that is used to search for and display attributes of Active Directory objects. (See also “Windows Directory Service Update and Query Tools” section.) The tool uses many switches, including those to specify the Active Directory server to contact, the proxy user used to attempt a bind, and the type of data to retrieve (a specific user or group of users, for instance). In the context of this guide, the most useful of the ldapsearch switches are:

  • -x. Uses simple authentication. This switch is only used on Linux and in open source versions of ldapsearch.

  • -h. The host from which to retrieve data (the Active Directory server).

  • -D. The domain name of the user whose credentials are used to bind to the Active Directory server.

  • -w. The password of the bind user. If not specified in the command, the program will provide a prompt.

  • -n. The base distinquished name (DN) in which to search for objects.

  • -s. The search scope. The options are sub, one, and base.

Note   Command-line switches for UNIX tools are case sensitive.

The switches are followed by a search filter and, optionally, a list of attributes to retrieve for those users matching the search filter. Some useful filters include:

  • Return all objects whose cn (account name) begins with "test":

    '(cn=test*)'

  • Return all objects from objectClass User whose sAMAccountName begins with "test":

    '(&(objectclass=User)(sAMAccountName=test*))'

  • Return all objects whose servicePrincipalName begins with "host" and display the servicePrincipalName, sAMAccountName and userPrincipalName:

    '(servicePrincipalName=host*)' servicePrincipalName sAMAccountName userPrincipalName

  • Return the sAMAccountName, msSFU30Password, msSFU30UidNumber, msSFU30GidNumber, msSFU30HomeDirectory, and msSFU30LoginShell attributes for the users whose uid number begins with "123" and whose account name begins with "test”:

    '(&(msSFU30UidNumber =123*)(sAMAccountName=test*))' sAMAccountName msSFU30Password msSFU30UidNumber msSFU30GidNumber cn msSFU30HomeDirectory msSFU30LoginShell

The syntax of the ldapsearch command varies by platform. The ldapsearch command is useful for determining whether a connection can be made for LDAP to a specific Active Directory server, whether a bind can be successfully completed for a given proxy user, and whether a given set of data can be retrieved. The ldapsearch command is NOT useful for validating LDAP configuration on the UNIX client because all contact information (for example, the server to contact and the proxy user) is specified as part of the command.

The following sample ldapsearch command makes a request to the directory on the Active Directory server with IP address 10.9.8.1 in base dn ou=unix,dc=example,dc=com to return all attributes for users whose cn (account name) starts with "test".

ldapsearch -h 10.9.8.1 -Dcn=aduser,cn=users,dc=example,dc=com -w Password1
 –b ou=unix,dc=example,dc=com -s sub '(cn=test*)'

Note   In this example, the Active Directory database is accessed as user aduser with password Password1.

Note   The ldapsearch command does not read the ldap configuration files.

ldaplist

The ldaplist tool is a native Solaris command-line tool that is used to search for and display LDAP directory objects. Unlike ldapsearch, the ldaplist tool reads the native Solaris LDAP configuration files to determine which Active Directory server should be contacted and which Active Directory user to connect as. The tool is most useful for validating the native Solaris LDAP configuration for End States 2, 3, and 4.

Below are some sample ldaplist commands:

  • The following simple command returns the domain name for the user test02:

    ldaplist passwd test02

  • The following command returns the DN for all groups:

    ldaplist group \*

  • The following command returns all attibutes for the tstgrp02 group:

    ldaplist -l group tstgrp02

getent

The getent command-line tool is a native UNIX command-line tool that is used to list entries from the administrative database. It takes several database types as input. In the context of this guide, the passwd and group databases are most useful. The command can be used to validate the LDAP configuration with a lookup of an Active Directory user or group.

Below are some sample getent commands:

  • The following command returns all the user data from both the local /etc/passwd file and the container in Active Directory for which LDAP on the UNIX client computer is configured:

    getent passwd

  • The getent tool can also be used to list a single object. The following command lists the user test02:

    getent passwd test02

UNIX Infrastructure Troubleshooting Tools
System Log File (syslog)

The UNIX system logging function (syslog) is configured in the /etc/syslog.conf file to direct log output to a variety of optional destinations, including to a text file or files, or to the system console. The system log is frequently configured to log high-priority alerts to multiple destinations and standard messages to a text file. You can view this text file with a text editor (such as vi) or display it on the screen with tools such as cat, more, less, or tail. It is often useful to view the log in real time using tail with the -f switch.

For example, the following command displays the last several lines of a standard Solaris syslog file in real time:

tail –f /var/adm/messages

The default file name and location for the syslog varies by operating system.

The syslog configuration file includes arguments for the type of data to be logged in addition to the logging destination. The definition of the type of data is separated into the facility and the level. The facility is the source of the message and the level is the severity level defined in the application. For troubleshooting, it can be helpful to enable all logging temporarily by configuring an entry with this format in the /etc/syslog.conf file:

*.debug    /var/adm/messages

If you change the configuration in the /etc/syslog.conf file, you must restart the syslog daemon.

For more information about syslog configuration on Solaris, see http://docs.sun.com/app/docs/doc/817-3945/6mjgluk9a?a=view.

Warning   On an active UNIX-based computer hosting many users or applications, the syslog file can grow very large very quickly when configured to capture full debug level data.

nslookup

The nslookup command-line tool is a native UNIX tool that you can use to verify Domain Name System (DNS) records. The nslookup tool can be useful for troubleshooting Kerberos errors because Kerberos is very sensitive to minor DNS problems. You can use the nslookup tool to make a request to a DNS server to resolve a specific host name or IP address for a computer in your environment specified in the command-line request. The nslookup tool does not accept wildcards for DNS lookups but can be scripted to look up multiple addresses from an input list.

The nslookup tool is available in both the native UNIX and Windows operating systems. However, on some UNIX systems, nslookup has been deprecated—for example, Red Hat has indicated that nslookup might be removed from future releases and recommends the use of the dig tool as an alternative.

Note   The nslookup tool on most UNIX platforms directs inquiries only to the DNS server or servers specified in the /etc/resolv.conf file. It does not perform lookups based on the entries in the /etc/nsswitch.conf file. Any entries in the local /etc/hosts file of the computer on which the command is run will be ignored. This can cause confusion and lead to false conclusions about the health of the host name resolution environment. Be sure to verify how host name resolution is accomplished on the computers involved in testing DNS.

dig

The dig command-line tool is a native UNIX tool that has functionality similar to the nslookup tool with many additional options. For example, you can use the dig tool to make a request to a DNS server to resolve a specific IP address or host name, and you can also use it to return a list of all records in a DNS server’s forward or reverse lookup tables. The dig tool is part of the standard Red Hat installation but might not be available by default on Solaris client installations.

ping

The ping command-line tool is a native UNIX tool that is used to verify connectivity to another host. It is useful at a very basic level for both Kerberos and LDAP troubleshooting to determine whether a given Active Directory server can be contacted from the UNIX client.

Ping may be used as a general purpose troubleshooting tool to determine if basic network connectivity exists between the various systems used in the deployment. It may be also used to determine if other network problems may exists, such as network latency and packet loss.

UNIX Kerberos Troubleshooting Tools
CSS GetTicket

The Certified Security Solutions GetTicket (css_gettkt) command-line tool is useful for troubleshooting logon problems related to Kerberos authentication. It has two main functions:

  • Acquire a service ticket. When gettkt is used with the getsrvtkt option, it requests a service ticket for a specified service. This is useful when troubleshooting to determine whether a service ticket for the UNIX-based computer account (host/hostname@REALM) can be acquired on the UNIX-based computer on which Kerberized PAM logon is failing. In many Kerberized logon failure scenarios, logon might fail even if a TGT can be obtained. This is because service ticket requests are more sensitive to Kerberos configuration problems as well as to configuration problems with services such as DNS and NTP.

  • Acquire an intial ticket-granting ticket using the key stored in a key table. When gettkt is used with the gettgt option, it requests a TGT using the key stored in the specified key table instead of prompting the user for a password. This is useful for validating the key stored in the key table.

The CSS GetTicket tool is available for free download from Certified Security Solutions at http://www.css-security.com/downloads.html.

kinit

The kinit command-line tool is a native UNIX tool that is used to acquire Kerberos credentials from the Active Directory server. This tool can be used when troubleshooting Kerberos problems to validate the Kerberos configuration on the UNIX client.

Note   The kinit tool is installed by default on UNIX clients when configured by using the instructions in Volume 2: Chapter 4, "Developing a Custom Solution."

With kinit, you can determine whether the problem is related specifically to the pam_krb5 module or is a broader problem with the functionality of Kerberos on the UNIX client. If a ticket can be acquired with kinit but a logon with pam_krb5 fails, the problem is not specifically related to basic Kerberos configuration. However, the logon may still be failing at the Kerberos step. This can be determined by using the GetTicket tool to attempt to acquire a service ticket and by examining a network trace of the logon attempt to see if Kerberos requests are being made and whether tickets are being granted.

The kinit tool offers several switches. In the context of this guide, kinit is most useful for validating Kerberos and network configuration on the UNIX-based computer and connectivity to the Active Directory server by acquiring credentials for a test user. The following command requests a credential for user test02:

$ kinit test02

The kinit tool can also be used to validate a key table entry by acquiring a ticket using the password stored in the key table instead of with a user-provided password. The following command requests a credential for account host/test01.example.com using the password stored in the default key table:

# kinit -k host/test01.example.com

You must have permissions to read the key table in order to use kinit in this way. Generally that means that you must be root.

klist

The klist command-line tool is a native UNIX tool that is used to display credentials found in the local credentials cache file. It can also be used to display the contents of the service key table on the UNIX host.

Note   The klist tool is installed by default on UNIX clients when configured by using the instructions in Chapter 4, "Developing a Custom Solution" and is also available on Windows as part of the Windows Server 2003 Resource Kit. (See also the “Windows Kerberos Troubleshooting Tools” section in this appendix.)

The klist command can be executed with or without arguments. When used without arguments, the default credentials cache (the cache for the current user) is read and the output from the klist command is similar to the following:

Ticket cache: /tmp/krb5cc_500

Default principal: test01@EXAMPLE.COM

Valid starting          Expires               Service principal

Thu 10 Aug 2006 10:36:15 AM PDT  Thu 10 Aug 2006 08:36:15 PM PDT  krbtgt/EXAMPLE.COM@EXAMPLE.COM

        renew until Thu 17 Aug 2006 10:36:15 AM PDT

The klist tool includes several switches that can be used to provide additional information. In the context of the solutions included in this guide, the most useful switches are:

  • -e.    Display the encryption type of the credential or key table entry.

  • -k.    List the contents of the key table instead of the user's credentials cache.

  • -t.    Specify the path and location to the key table for a nonstandard key table name or location.

The following command displays the contents of the service key table /etc/krb5/krb5.test inluding the encryption type of the stored key:

# klist -ekt /etc/krb5/krb5.test

You must have permissions to read the key table in order to use klist in this way. Generally that means that you must be root.

kdestroy

The kdestroy command-line tool is a native UNIX tool that is used to delete a credentials cache. The -c switch in kdestroy can be used to specify the cache to be deleted.

Note   The kdestroy tool is installed by default on UNIX clients when configured by using the instructions in Chapter 4, "Developing a Custom Solution." The KerbTray tool (described earlier in the "Windows Kerberos Troubleshooting Tools" section) includes a kdestroy functionality.

ktutil

The ktutil command-line tool is a native UNIX tool that is used to manage service key tables. It can also be used to delete entries from an existing key table and to list service key table entries. However, ktutil does not offer as many list options as klist.

Note   The ktutil tool is installed by default on UNIX clients when configured by using the instructions in Chapter 4, "Developing a Custom Solution."

kpasswd

The kpasswd command-line tool is a native UNIX tool that is used to change the Kerberos password for a user. It can be used to verify that the password change configuration in the Kerberos krb.conf file is correct.

Note   The kpasswd tool is installed by default on UNIX clients when configured by using the instructions in Chapter 4, "Developing a Custom Solution."

MIT GSS-API Sample

The MIT Kerberos package includes sample GSS-API client and server applications. In the context of this guide, these are most useful for validating cross-realm configuration in the End State 5 solution.

The MIT Kerberos packages is an open source tool and is available from http://web.mit.edu/kerberos/www/.

System Log File (syslog)

The system log file on a UNIX host that is not used as a KDC often does not contain many log messages specific to Kerberos; however, sometimes helpful messages related to the pam_krb5 library are generated. This is especially true if debugging for pam_krb5 is enabled.

For open source End State 2 solutions, messages related to Kerberos authentication for the LDAP proxy user might appear in the syslog.

For more information about the system log file, see the “UNIX Infrastructructure Troubleshooting Tools” section.

UNIX LDAP Troubleshooting Tools
chown

The chown command-line tool is a native UNIX tool that is used to set ownership on a file or directory. In the context of this guide, it is most useful for validating the LDAP configuration by attempting to change the ownership of a file to a user in Active Directory.

chgrp

The chgrp command-line tool is used to set group ownership on a file or directory. In the context of this guide, it is most useful for validating the LDAP configuration by attempting to change the group ownership of a file to a user in Active Directory.

Note   Also see the discussions of ldapsearch, ldaplist, and getent in the “UNIX Directory Service Update and Query Tools” section.

id

The id tool can be used to verify that correct LDAP data about the user can be retrieved from Active Directory after LDAP-enabled logon.

For more information about this command, see the “UNIX Directory Service Update and Query Tools” section.

groups

The groups tool can be used to verify that all the groups for the user can be retrieved from Active Directory after LDAP-enabled logon.

For more information about this command, see the “UNIX Directory Service Update and Query Tools” section.

getent

The getent tool can be used for LDAP-specific troubleshooting to verify that entries from Active Directory can be retrieved to the UNIX-based computer and that the LDAP configuration for the UNIX-based computer is correct. This basic functionality is necessary in order for logon using LDAP to be successful.

For more information about this command, see the “UNIX Directory Service Update and Query Tools” section.

ldap_cachemgr

The ldap_cachemgr tool on Solaris can be used to check the status of the native Solaris LDAP cache manager daemon.

ldaplist

The ldaplist tool on Solaris can be used for LDAP-specific troubleshooting to verify that entries from Active Directory can be retrieved to the UNIX-based computer and that the LDAP configuration for the UNIX-based computer is correct. This basic functionality is necessary in order for logon using LDAP to be successful.

For more information about this command, see the “UNIX Directory Service Update and Query Tools” section.

ldapsearch

The ldapsearch tool can be used to retrieve LDAP data from Active Directory. The data to be retrieved can be specified, making the tool quite versatile. However, this tool does not verify the LDAP configuration of the UNIX-based computer. For basic LDAP troubleshooting, the ldaplist or getent tool might be preferable.

For more information about this command, see the “UNIX Directory Service Update and Query Tools” section.

System Log File (syslog)

The system log file on a UNIX-based computer might contain log messages specific to LDAP, depending on the LDAP solution selected and depending on the LDAP configuration. Typically, however, these messages are not useful for troubleshooting LDAP-specific problems. Instead, try a network trace or try enabling debugging in the LDAP configuration file (/etc/ldap.conf for open source and native Red Hat solutions). When debugging is enabled in the LDAP configuration file, debug output is not sent to the standard system log file but is instead sent to the user interface.

For more information about the system log file, see the “UNIX Infractructure Troubleshooting Tools” section.

UNIX Network Monitoring and Protocol Analysis Tools

Protocol analysis tools can help troubleshoot Kerberos and LDAP problems. They allow you to capture ("sniff") all packets sent between your UNIX-based client computer (configured for authentication and/or for authorization against Active Directory) and the Active Directory server. You can then review the packets to help determine why authentication (using pam_krb5 or pam_ldap) or authorization (using nss_ldap) is failing. These tools can be helpful for troubleshooting each end state described in this guide.

Monitoring and analysis tools are available for the UNIX platform include:

  • snoop. The snoop command-line tool is a native Solaris tool used to capture network packets.The snoop tool is installed as part of the base Solaris operating system and includes several command-line switches.

    Note   The snoop tool is part of the Solaris operating system and is not available on other platforms.

    When troubleshooting a solution on Solaris it might occasionally be helpful to generate a network trace with snoop and then analyze it with Ethereal (described next). The snoop tool, for instance, can be helpful in troubleshooting issues where an Ethereal trace on the Active Directory server shows no packets of a given type (Kerberos or LDAP). With snoop, you can determine whether any Kerberos or LDAP requests are being made (the result of running snoop shows no packets of these types) or whether the requests are made but not received by the Active Directory server (snoop shows packets of this type, but a trace done on Active Directory with Network Monitor or Ethereal does not).

    The following is a sample snoop command that traces traffic between the Solaris client on which the command is run (sol01 in this example) and the Active Directory server to which the traffic is directed (kdc01 in this example). The -o switch identifies the path and file name of the output file.

    # snoop –o /tmp/snoopout1 sol01 kdc01

    If you have more than one KDC (Active Directory server) configured for Kerberos (in the krb5.conf file) and/or more than one Active Directory server configured for LDAP (in the /etc/ldap.conf or /var/ldap/ldap_client_file for native Solaris), be sure to specify the first server configured for each of these. It might be helpful to do a trace for traffic to each of the Active Directory servers configured for Kerberos and/or LDAP on the Solaris client.

  • Ethereal. Ethereal is an open source protocol analysis tool available in both Windows and UNIX versions from http://www.ethereal.com. (Also see the “Windows Network Monitoring and Protocol Analysis Tools” section.) Ethereal can be used to read trace files generated by many other applications, including the Solaris snoop tool.

  • ssldump. The ssldump tool is a network protocol analyzer that decodes SSLv3/TLS traffic. If the appropriate private key material associated with the SSL certificate is provided to ssldump, slldump will decrypt the SSL connection, thereby providing access to the LDAP traffic.

    In instances where turning off SSL protection for a connection is impractical, it might be useful to investigate the use of ssldump.

    The ssldump tool is an open source tool available at http://www.rtfm.com/ssldump/.

  • tcpdump. The tcpdump tool is an open source tool available at http://www.tcpdump.org. The tcpdump tool prints out the headers of packets on a network interface and lets you store the captured output to a file for analysis of network problems.

Note   For End State 2, the instructions in Volume 2: Chapter 4, "Developing a Custom Solution," advise you first to configure the solution without TLS/SSL or Kerberos authentication for the LDAP connection and then implement TLS or Kerberos authentication for the LDAP connection after the solution is working correctly. The same recommendation is also true for End States 3 and 4. Part of the reason for this is that after the LDAP connection is secured, it becomes impossible to interpret the LDAP traffic with a tool such as Ethereal. (See the “Ethereal” section earlier in this section.) Because the tools do not decrypt the encrypted packets, the nature of the requests and returned data cannot be determined. If you encounter problems with the solution for these end states that requires troubleshooting with one of these tools, disable the security temporarily while troubleshooting, or try the ssldump tool.

For End States 1 and 2, each logon attempt with pam_krb5 generates as many as three requests with associated replies. You may use snoop or Ethereal to monitor this process:

  1. An initial request for a TGT. This request is not accompanied by preauthentication data and may generate a response from the server that preauthentication data is required. For most configurations and logins, preauthentication data is required. If this is the case, the first request will receive an error response of KRB5KDC_ERR_PREAUTH_REQUIRED. If the user has been configured with the "Do not require Kerberos preauthentication" flag (required for Solaris native ES 2 login via dtlogin due to a bug in the operating system), the ticket will be granted at this stage and request 2 will be skipped.

  2. A second request for a TGT accompanied by preauthentication data. If the user name and password provided were correct, the TGT will be granted.

  3. A service ticket request for the target host— principal host/hostname@REALM, where hostname is the fully qualified domain name (FQDN) of the UNIX client computer .

Some implementations do not request or require a service ticket. If the implementation requires a service ticket and the login failure point is the service ticket request, Ethereal should show a request but an error in the response.

In some configurations, two sets of these messages may appear in the trace—one message for krbtgt/REALM for basic authentication and another message for kadmin/changepw password change support.

If no Kerberos packets are seen in the trace, the UNIX client is not attempting to send a Kerberos request or the Active Directory server has not received the request (assuming that the packet tracing tool is being run on the Active Directory server). For Solaris solutions, it may be helpful to use the Solaris snoop command on the UNIX client to determine whether packets are being requested.

To temporarily disable TLS/SSL security for native LDAP on Solaris

  • Modify the /var/ldap/ldap_client_file to change the NS_LDAP_AUTH configuration to simple instead of tls with the following command:

    # ldapclient mod -a authenticationMethod=simple

    This should modify the following line in the ldap_client_file file:

    NS_LDAP_AUTH= tls:simple

  • Alternately, you can manually edit the /var/ldap/ldap_client_file and change the LDAP authentication entry to:

    NS_LDAP_AUTH= simple

  • After making this change, stop and restart the LDAP daemons using the following commands:

    # /etc/init.d/ldap.client stop

    # /etc/init.d/ldap.client start

    # /etc/init.d/nscd stop

    # /etc/init.d/nscd start

To perform this task for the open source End State 2 solutions for on Red Hat and Solaris

Comment out the following entries in the /etc/ldap.conf file:

# Enable Kerberos authentication for server bind.

# use_sasl on

# rootuse_sasl on

# krb5_ccname /var/tmp/proxycreds

Modify the following entries in the /etc/ldap.conf file.

  1. Comment out the binddn: entry for the user service_proxy and uncomment or add the entry for the user proxyuser:

    # The distinguished name to bind to the server with.

    # Optional: default is to bind anonymously.

    # binddn cn=service_proxy,cn=users,dc=example,dc=com

       binddn cn=proxyuser,cn=users,dc=example,dc=com

  2. Uncomment the bindpw entry (where secret is the password of the Active Directory account for proxyuser):

    # The credentials to bind with.

    # Optional: default is no credential.

    bindpw secret

Restart the nscd daemon:

RedHat:

# /etc/rc.d/init.d/nscd restart

Solaris:

# /etc/init.d/nscd stop; /etc/init.d/nscd start

To temporarirly disable TLS/SSL security for End State 3 and End State 4 open source LDAP on Red Hat and Solaris

Modify the following entries in the /etc/ldap.conf file.

  • Comment out the uri entry for the Active Directory server(s) using LDAPS and uncomment or add the entry for the Active Directory server(s) using LDAP:

    # Another way to specify your LDAP server is to provide an
    # uri with the server name. This allows to use
    # Unix Domain Sockets to connect to a local LDAP Server.
    uri ldap://server1.example.com/ ldap://server2.example.com/
    # uri ldaps://server1.example.com/ ldaps://server2.example.com/
  • Uncomment the ssl no entry:

    # Client certificate and key
    # Use these, if your server requires client authentication.
    # tls_cert
    # tls_key
    ssl no
    # pam_password md5
  • Comment out the SSL configuration entries:

    # OpenLDAP SSL mechanism
    # start_tls mechanism uses the normal LDAP port, LDAPS typically 636
    #ssl start_tls
    # ssl on
     
    # OpenLDAP SSL options
    # Require and verify server certificate (yes/no)
    # Default is "no"
    # tls_checkpeer yes
     
    # CA certificates for server certificate verification
    # At least one of these are required if tls_checkpeer is "yes"
    # tls_cacertfile /etc/ssl/certnew.cer
  • Restart the nscd daemon:

    RedHat:

    # /etc/rc.d/init.d/nscd restart

    Solaris:

    # /etc/init.d/nscd stop; /etc/init.d/nscd start
UNIX Cron Command

The cron tool is available natively in most UNIX operating systems, including Red Hat and Solaris. The cron tool is used to schedule commands so that they run at specified dates and times according to instructions in a "cron table" file called the crontab file. The cron service runs continuously in the background, checking frequently to determine whether it is time yet to run any of its scheduled jobs. Although users can have their own crontab files, administrators use a system-wide crontab file, which is stored, typically, in the /etc directory or in a subdirectory of /etc.

You can find information about the cron tool from the following sources:

Download

Get the Windows Security and Directory Services for UNIX Guide

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.