Troubleshooting and Logging NIS Operations

This section describes how to use diagnostic tools and log files to retrieve information about adnisd operation and correct problems.

Analyzing Zones for Potential Issues

One way to avoid problems with agentless authentication or incomplete information is to periodically analyze the zone in the Active Directory forest using the Analyze wizard.

When you run the Analyze wizard, it checks only open zones in the Active Directory forest. Make sure the zone you are using as a NIS domain is open before analyzing the forest.

To check for potential problems in the Active Directory forest:

  1. Open Access Manager.

  2. If so prompted, specify the forest domain or domain controller to which to connect.

  3. In the console tree, select the Access Manager root node, right-click, and click Analyze.

  4. At the Welcome page, click Next.

  5. Select the checks to perform (at least the two in the table below) and click Next.

    Select this option To do this
    Inconsistency in granting NIS server permissions Check that a zone_nis_servers group exists in each zone that supports agentless authentication, and that the group contains all NIS servers defined for the zone (to ensure data integrity). This group is required for assigning permissions to Delinea-managed computers that act as NIS servers. Do not delete or modify it manually.
    Orphan UNIX data objects Check for profile objects whose parent objects have been deleted – for example, manually deleted zone objects whose user, group or computer UNIX profile data may be left in Active Directory. This option removes UNIX-specific data from Active Directory.

  6. Review the summary report and click Finish.

  7. If the summary report indicates any issues, select Analysis Results in the console tree and view the details listed in the right pane. For example:

    To drill down further, or to resolve the issue, select the warning or error, right-click, and select Properties. For example:

Verifying NIS Configuration for Servers and Clients

If you are troubleshooting issues with the Delinea Network Information Service or NIS client look-ups, start by verifying whether the current environment is configured properly by doing the following:

  • Check the connectivity between the NIS client and the NIS server with a ping command. If the ping command fails, check the network connection and the DNS configuration for name resolution problems.

  • Verify that the nisd.securenets parameter allows responses to NIS clients on other computers. By default, the adnisd process responds only to local NIS requests.

  • Verify that the adnisd process is running, for example with the ps command. If adnisd is not running, restart it.

  • Verify that ypserv is not currently running. If ypserv is running, stop it, modify the system initialization files so ypserv does not start when the computer is rebooted, and restart adnisd.

  • Verify that adnisd has registered with RPC by running rpcinfo -p localhost on the adnisd server. You should see two entries in the RPC table for the ypserv program (100004):

    program vers proto port
    100004 2 udp 844 ypserv
    100004 2 tcp 846 ypserv

    If no table is displayed, restart RPC services. If the ypserv process is not listed, restart adnisd.

  • Verify RPC connectivity from the NIS client:

    rpcinfo -p server

    You should see the same table and entries as when you listed RPC entries for the adnisd server. For example:

    program vers proto port
    100004 2 udp 844 ypserv
    100004 2 tcp 846 ypserv

    If no table is displayed, check the access permissions to the RPC server. For example, on Linux, check /etc/hosts.allow and /etc/hosts.deny files.

  • Make sure the correct NIS domain name is configured on the NIS client. The NIS domain name is usually the same name as the name of the zone that the server is joined to. To set the domain name, log on as root run the following command:

    domainname zone_name

  • Verify that the ypbind process is running on the NIS client using the ps command. If ypbind is not listed as a running process, configure and start it.

  • Verify that ypbind on the NIS client has found the Delinea NIS server by running ypwhich on the NIS client machine.

    If the client is not bound to the correct server name, check the ypbind configuration files and start-up options.

    If you are transitioning from an existing NIS infrastructure to the Delinea Network Information Service, the most common reasons for errors are an incorrect domainname setting or an improper ypbind configuration. For example, if your existing NIS domain names do not match the zone name, some clients may fail because they use the old NIS domain name instead of the domain name you have set up for the Delinea Network Information Service domain.

Updating the Startup Sequence

On some platforms, the adnisd package might prevent the ypbind service from starting properly because of the order in which services are started. For example, if ypbind is configured to start before the adnisd service, the bind will fail. In most cases, this issue does not occur if you are installing new packages because the installation process checks and corrects the startup sequence to ensure that the bind will be successful. However, to prevent unintended changes to the existing startup sequence during an upgrade, upgrading the adnisd package will not modify your existing startup configuration. You can manually correct the startup sequence after an upgrade by running the chkconfig script. For example, run the following command after the adnisd upgrade:

chkconfig adnisd on

Using NIS Command Line Utilities

The Delinea Network Information Service supports common command-line utilities for performing administrative and diagnostic tasks. The following table lists those you may find useful in the Delinea NIS environment.

Use this command To do this
ypwhich Display the name of the NIS server the client is connected to.
ypwhich -m List the maps that are served by the current NIS server.
ypwhich -x Display the nicknames that are defined for NIS maps.
ypcat -k map Display the contents of the specified map. This command displays both keys and values.
ypmatch key map Look-up the specified key in the specified map.
yppoll map Check the version number of the specified map. This command is only available on Solaris and HP-UX environments. The version number is displayed as an integer. The adnisd process does not use timestamps.

Configuring Logging for adnisd

By default, the adnisd process logs errors, warnings, and informational messages in the syslog and /var/log/messages files, along with other kernel and program messages. You might find it useful to log additional details about the operation of the adnisd process for troubleshooting purposes.

To enable logging for the Delinea Network Information Service:

  1. As root, set the logging level for the Delinea Network Information Service by modifying the log.adnisd parameter in the centrifydc.conf file.

    You might also want to suppress log messages from adclient to make it easier to collect and analyze the messages that are specific to adnisd operation. For example, set the log.adnisd parameter to DEBUG to log alladnisd operations, and the log parameter for adclient to INFO or WARN to limit messages generated by the adclient process:

    log: WARNlog.adnisd: DEBUG

    If you only want to collect diagnostic information for netgroup processing, set the log.adnisd.netgroup parameter instead of the log.adnisd parameter. For example:

    log.adnisd.netgroup: DEBUG

  2. Set the syslog facility to use for logging adnisd operations using the logger.facility.adnisd configuration parameter. This parameter enables you to log adnisd messages using a different syslog facility than the facilities used for logging general adclient messages or adclient audit messages.

    This parameter value can be any valid syslog facility. For example, set this parameter to log messages to auth (default), authpriv, daemon, security, or local0-7 facilities. For example:

    logger.facility.adnisd: auth

For performance and security reasons, only enable DEBUG logging when necessary – for example, when requested to do so by Delinea Support, or while diagnosing a problem.

Sensitive information may be written to this file. Evaluate the contents before giving others access to it.