Configuring the Server Suite NIS server

This section describes how to install and configure the Delinea Network Information Service (adnisd). Theadnisd process allows a Delinea-managed computer to act as the NIS server for NIS clients in a joined domain. Using adclient and adnisd together, you can store authentication, authorization and network information in Active Directory, and respond to NIS client requests from computers and devices even where adclient cannot be installed.

Installing the Delinea NIS Server

Whether you want to use the Delinea Network Information Service for agentless authentication, managing network information, or publishing custom maps, you must install and configure adnisd on at least one computer in at least one zone before you can begin responding to NIS client requests.

In most cases, adnisd is installed as part of a custom installation of the Server Suite or as a separate software package, independent of the installation of adclient. The naming convention for the standalone software package is:

centrifydc-nis-n.n.n-os-architecture

Keep in mind:

  • You must install adnisd on a computer whereadclient is also installed.
  • The Active Directory domain and zone the local computer has joined defines the NIS domain, and therefore the information available to NIS clients.
  • You cannot use adnisd to serve NIS maps if your managed computer joined the domain using the --workstation option.
  • Using the --workstation option adds a computer to the single Auto Zone where user and group profiles are generated automatically. Computers in the Auto Zone cannot be used as NIS servers or NIS clients.
  • You can install adnisd using any installation program appropriate for the local operating environment, such as RPM, SMIT or YAST.
  • If you are upgrading from a previous release of Server Suite and have an earlier version of adnisd, stop the existing adnisd service and use install.sh to remove the old packages before installing the new version of adclient and adnisd.

The following steps are only an example of how to installadnisd locally on a computer. The specific steps required depend on the local operating environment and the installation program you choose.

  1. As root on the managed computer, use adinfo to verify that adclient is installed, and that the local computer is joined to a domain and can connect to Active Directory:
    su -  
    Password:  

    adinfo  

    Local host name:     magnolia  
    Joined to domain:    ajax.org  
    Joined as:           magnolia.ajax.org  
    Current DC:          ginger.ajax.org  
    Preferred site:      Default-First-Site-Name  
    Zone:                ajax.org/Program Data/Centrify/Zones/default  
    Last password set:   2006-12-28 14:47:57 PST  
    CentrifyDC mode:     connected
  1. Copy the package appropriate to the local computer’s operating environment, from the Server Suite CD or a download directory, to a local directory.

    For example, if the operating environment is Solaris 9 SPARC:

    cp /tmp/centrifydc-nis-n.n.n-sol8-sparc-local.tgz .

  2. If the package is a compressed file, unzip and extract its contents. For example, on Solaris:

   gunzip -d centrifydc-nis-n.n.n-sol8-local.tgz
   tar -xf centrifydc-nis-n.n.n-sol8-sparc-local.tar
  1. Run the appropriate command for installing the package. For example, on Solaris:

    pkgadd –d CentrifyDC-nis -a admin

Adding IP Addresses from Which to Accept Requests

By default, the Network Information Service accepts only local NIS client requests. To accept requests from any other NIS clients in a network, modify nisd.securenets in the /etc/centrifydc/centrifydc.conf file to specify the computer subnets from which to accept NIS requests. This parameter configures adnisd to filter NIS client requests by IP address. It ignores all other NIS client requests.

For example, to restrict NIS requests to the single trusted subnet 172.68.0.0, add a line similar to the following to nisd.securenets:

nisd.securenets: 172.68.0.0/255.255.0.0

To specify multiple subnets, separate the entries with commas or spaces:

nisd.securenets: 172.68.0.0/255.255.0.0,196.48.0.0/0

To accept NIS client requests from any computer, use this:

nisd.securenets: 0/0

On systems with multiple Ethernet interfaces, adnisd configures RPC to the first interface. If an NIS client is trying to communicate on a different interface, adnisd will not receive the request.

Before creating sockets, adnisd reads the centrifydc.conf file to see if an IP address and TCP and UPD ports are specified. If not, it uses localhost and random port numbers assigned by the operating system.

You set the IP address, TCP port and UDP port using the nisd.net_addr, nisd.port.tcp, and nisd.port.udp configuration parameters, respectively in the centrifydc.conf file.

For more information, see the Configuration and Tuning Reference Guide.

Starting the adnisd Process

After you have specified the subnets from which to accept NIS client requests, you can either manually start theadnisd process at the command line, or reboot the local computer. By default, theadnisd process starts automatically whenever the computer is rebooted. If you don’t want the process started automatically, you should modify the startup script on the local computer to removeadnisd from the processes started.

The installer adds theadnisd process to a computer’s startup script for you. If you are not importing NIS maps right away, you may want to modify the startup script to prevent theadnisd process from starting before you are ready to begin servicing client requests.

To start theadnisd process at the command line:

  1. Verify that adclient is running and the local computer is joined to a domain.

  2. Verify that RPC is running on the local computer. For example:

    rpcinfo -p localhost

    Theadnisd process requires RPC services. If you restart RPC, you also need to restart theadnisd process.

  3. Type the appropriate start command. For example, on Red Hat Linux, type:

    /sbin/service adnisd start

    On most other platforms, run:

    /etc/init.d/adnisd start

    On Solaris 10 or later, the daemon is controlled through the Solaris Service Management Facility. For example:

    svcadm enable nis/centrifydc-server

When theadnisd process starts, it connects to Active Directory through adclient and does the following:

  • Retrieves the current user, group, network and custom information stored in Active Directory for its zone.
  • Generates additional maps derived from the retrieved information, such as netgroup.byuser, netgroup.byhost, passwd.byuid, passwd.byname, group.byname, and group.bygid.
  • Stores the information retrieved or derived from Active Directory in a local cache of NIS map data.

After the initial connection,adnisd periodically connects to Active Directory through adclient to retrieve updated information for its zone. However,adnisd always responds to NIS client requests using the data in its local cache so that it can respond to NIS requests even if Active Directory is unavailable.

Customizing the Update Interval for NIS Maps

By default, every 30 minutes (1800 seconds),adnisd uses adclient to connect to Active Directory. At the update interval,adnisd does the following:

  • Checks for network NIS maps explicitly defined in Active Directory to determine whether any records have changed.

  • Generates derived maps for any explicitly defined network maps thatadnisd recognizes. For example, if the netgroup map is found in Active Directory,adnisd generates thenetgroup.byuser and netgroup.byhost maps.

  • Updates the local cache with all changes to the network NIS maps.

  • Updates the local cache with changes to the derived maps for user and group information in the zone.

    In most cases, updating the local cache of NIS data does not require you to restart any services.

In most organizations, the default update interval is adequate. In a more volatile or stable NIS map environment, reduce or increase the time between updates, as appropriate, by modifying the nisd.update.interval parameter in /etc/centrifydc/centrifydc.conf to specify a different number of seconds between updates; for example:

nisd.update.interval: 900

For more information, see the Configuration and Tuning Reference Guide.

Customizing the NIS Maps to PUblish

By default, theadnisd process retrieves all NIS maps stored in Active Directory at each update interval, updates its local cache as needed, and makes all such data available to its NIS clients. In some cases, you may want to prevent NIS clients from accessing data in specific maps or from looking up information using a specific key.

If you want to customize the list of maps to make available to NIS clients, modify the nisd.maps or nisd.exclude.maps parameter in /etc/centrifydc/centrifydc.conf, or apply a group policy.

  • With the nisd.maps parameter, you explicitly list the NIS maps, including derived maps, to include in the local cache of map data; for example:

    nisd.maps: hosts.byname,hosts.byaddr,automount

  • With the nisd.exclude.maps parameter, you list the NIS maps to exclude from responses to NIS client requests (typically user and group information). When you specify a map, its derived maps are excluded as well. For example:

    nisd.exclude.maps: group passwd

For more information, see the Configuration and Tuning Reference Guide.

Configuring the Maximum Number of Map Sets

Whenadnisd receives data for explicitly-defined NIS maps, the data comes from the domain controller selected by the adclient process. If the domain controller the adclient process has changed – for example, if it is unavailable – the adclient process attempts to find another available domain controller.

To ensure the data consistency of the NIS maps retrieved from Active Directory,adnisd keeps a separate set of NIS records from each domain controller. This enablesadnisd to switch between domain controllers efficiently, but uses more space in the local cache.

You can control the maximum number of alternate sets of NIS maps to maintain (default is two) by modifying the nisd.maps.max parameter in /etc/centrifydc/centrifydc.conf. For example, to keep up to four sets of NIS maps, specify:

nisd.maps.max: 4

For more information, see the Configuration and Tuning Reference Guide.

Handling Large Active Directory Groups

In most cases, the NIS server cannot send more than 1024 characters of data to NIS clients in response to a query. This limitation can create problems when the NIS client requests information for a large group with a long membership list. By default, theadnisd process automatically truncates the list at 1024 characters.

You can configureadnisd to split large groups into several groups of conforming size and names using nisd.largegroup.suffix and nisd.largegroup.name.length in /etc/centrifydc/centrifydc.conf.

Splitting a single large group into multiple new groups

If you specify any value for the nisd.largegroup.suffix parameter,adnisd splits large groups into multiple new groups automatically, creating a new group whenever a group’s data size exceeds 1024-character limit by appending the string you define in nisd.largegroup.suffix plus a sequential number.

For example, if you have a large group named performix-worldwide-corp, and have defined the suffix string as “-all”, when the performix-worldwide-corp group membership is split into multiple groups, the groups are named as follows:

performix-worldwide-corp-all1  
 . . .  
 performix-worldwide-corp-all n

All of the new groups have the same group identifier (GID) as the original group.

Setting the maximum length of new group names

If the new group names would exceed the maximum length for group names on a platform, use the nisd.largegroup.name.length parameter. If you do this,adnisd` truncates the original group name so as not to exceed the maximum name length.

For the example above, if you set a maximum name length of 14, the split groups are named:

performix-all1  
 ...  
 performi-all10  
 ...  
 perform-all100

All of the new groups have the same group identifier (GID) as the original group.

For more information, see the Configuration and Tuning Reference Guide.

Making the NIS Server Available

After you install and configureadnisd on a computer, you must configure other computers or devices on the network to use the computer runningadnisd for NIS client requests.

In general, configuring NIS clients to use the Delinea Network Information Service involves:

  • Stopping any existing legacy NIS server processes.
  • Modifying the NIS client’s configuration file to identify the zone and computer name of the computer where theadnisd process is installed.
  • Sending a bind request from the NIS client to the new Delinea NIS server.

For more information, see Configuring NIS clients.