Network Information Services Administration

This section provides a brief overview of Network Information Services (NIS), including the basic advantages and limitations of using NIS to publish information. It also describes the Centrify solution for using NIS to respond to client authentication and lookup requests.

You should use this section to help you determine whether the Centrify Network Information Service (adnisd) is an appropriate solution for your organization's needs.

Introduction to the Basics of NIS

In some environments, a Network Information Server (NIS) provides centralized storage and distribution of information that needs to be known throughout the network. In a typical NIS environment, one or more NIS servers are used to centrally manage a set of database maps that correspond to the system configuration files that are commonly found on UNIX systems. For example, there are NIS maps that correspond to the /etc/passwd, /etc/group, /etc/hosts, and /etc/services files. The maps provide the centralized information to a given set of computers that make up a NIS domain.

Each NIS map corresponds to a specific configuration file, such as the /etc/passwd or /etc/hosts file, and consists of a set of keys and values, and a version number for the data. When computers on the network require information stored in NIS maps, they send a NIS client request to the NIS listening port to query the NIS server for the information.

When a computer needs the information stored in a NIS map, it runs the ypbind process to identify and connect to the NIS server best suited to respond to its requests. When the NIS server receives a request, it replies with the appropriate information from its set of NIS maps.

Limitations of using NIS

Although NIS can be very efficient in responding to queries for network information, it is not a secure mechanism for providing authentication and authorization services. For example:

• If NIS clients use the broadcast service to locate NIS servers on the network, intruders can easily introduce their own NIS server with their own privileged accounts. Once a client binds to the rogue NIS server, the intruder can gain access to that client and perform unauthorized operations.
• The NIS server’s only security policy is the securenets setting. The securenets setting identifies which NIS clients to accept queries from. If an intruder impersonates a client that the securenets setting allows the NIS server to accept, he can download all of the NIS data. Even if an intruder fails the securenets test, he could potentially inspect all of the NIS requests and decode the data to gain access.
• If NIS is used for authentication, password hashes are sent around the network in clear text and can be easily captured and cracked, making client systems vulnerable.

Because of these security risks, in most cases, you should plan to replace any legacy NIS environment with Active Directory as the central repository of identity information and the Centrify Agent for *NIX (adclient) as the “client” requesting information. In some cases, however, if may not be practical or desirable to completely replace an existing NIS infrastructure. To handle those cases, Centrify provides its own Network Information Service (adnisd) that enables existing NIS clients to remain in place and co-exist with Active Directory.

Deciding to Maintain NIS in your Environment

Active Directory and the Centrify Agent for *NIX (adclient) provide more secure authentication, authorization, and directory services than provided by traditional NIS client-server communication. Therefore, when you install the Centrify Agent and join a domain, the Name Service Switch configuration file, nsswitch.conf, is normally modified so that account lookup requests are passed to Active Directory through the adclient process. This change to the nsswitch.conf file effectively bypasses the NIS client and server environment.

There are some situations, however, in which maintaining an ongoing or temporary NIS environment may be desirable or necessary. For example:

• If you have a legacy Network Information Server (NIS), you may have configured network information, such as netgroup or automount maps, that you want to make available in response to client requests.
• You may have applications that require access to a NIS server because they send requests directly to the NIS port and expect a NIS process to be listening there.
• You may have computers or devices, such as Network Attached Storage devices or computers with older or unsupported operating systems where you cannot install the Centrify Agent, that need access to information normally stored in NIS maps. Those computers or devices cannot join an Active Directory domain, but are capable of submitting NIS client requests. For those computers or devices, a NIS server may be the only option for providing authentication and look-up services.

If any of these scenarios apply to your organization, you may want to plan a deployment that includes the Centrify Network Information Service to complement the agent.

Using the Network Information Service

To support computers and applications that are capable of submitting NIS client requests to a NIS server, the Verify Privilege Server Suite provides its own Network Information Service. The Centrify Network Information Service, adnisd, is an optional process that can be installed on any computer where adclient is installed.

Once installed and running, the Centrify Network Information Service functions like a standard NIS server, but it responds to NIS client requests using the information stored in Active Directory, including any information imported from passwd and group NIS maps or from /etc/passwd and /etc/group files. The Centrify Network Information Service has some of the same security limitations as a standard NIS server, but it does allow you to provide encrypted authentication and directory service to computers where adclient cannot be installed.

The Centrify Network Information Service can be useful in environments where you plan a phased migration from existing NIS servers and clients or when the environment includes legacy systems that you cannot migrate or upgrade to support the Centrify Agent for *NIX.

How NIS Client Requests are Processed

If you have decided to maintain a NIS environment, on either an ongoing or temporary basis, you can use the Centrify Network Information Service to replace existing NIS servers and the Access Manager console to migrate NIS map data to Active Directory.

The Centrify Network Information Service (adnisd) can run on any computer that has the adclient agent service installed. Computers that need access to the information stored in Active Directory can then be configured as NIS clients that send their NIS queries to the computer where both the adclient and adnisd service run.

When adnisd receives a request from the NIS client, it checks its local cache of map data, then responds to the client that made the request. The local cache of map data is generated from the map data adnisd receives from Active Directory.

The following figure provides a simplified view of operation.

Derived and Explicitly-defined Maps

Within the local cache, there are two types of maps: explicitly-defined maps and derived maps. Explicitly-defined maps are NIS maps imported into Active Directory from an existing NIS domain, imported from text files, or created manually using the Centrify Access Manager console. Derived maps are maps that are automatically generated from the information stored in Active Directory. Derived maps access the same data as the explicitly-defined maps using different keys. For example, the user and group maps in the local cache are not retrieved directly from Active Directory, but are generated based on the users and groups that have been enabled for the local computer’s zone.

The maps derived from the zone information are passwd.byname, passwd.byuid, group.byname, and group.bygid. These automatically generated maps are placed in the local cache, and can then be used to look up or authenticate users by user name or by UID value, and groups by group name or by GID value. The Centrify Network Information Service also generates derived maps for explicitly-defined network maps that are stored in Active Directory. If adnisd finds a NIS map defined in Active Directory with a name it recognizes, such as netgroup or services, it automatically derives related maps. For example, a netgroup map will automatically generate the netgroup.byhost and netgroup.byuser maps. A services base map will generate the services.byname and services.byservicename maps.

Accessing NIS Maps in the Local Cache

Periodically, theadnisdprocess connects to Active Directory through the adclient process to locate updates to explicitly-defined NIS maps. It then synchronizes the local cache of NIS map data to mirror any changes detected in Active Directory. After polling Active Directory for updates to explicitly-defined maps, the adnisd process retrieves all users and groups in the current zone from adclient, and generates the derived maps for user and group information.

In essence, the computer where both adclient andadnisdrun acts as the NIS server for the local computer’s zone. The NIS clients on the network communicate withadnisdusing Remote Procedure Calls (RPC) sent to the NIS port on the Centrify-managed computer. The adclient process is responsible for all communication with Active Directory and maintains its own separate cache of data from whichadnisdcan derive the user and group information for the zone. Theadnisdprocess then stores all of the explicitly-defined and derived maps in its own local cache of map data (in most cases, /var/centrifydc/nis/*). Becauseadnisdalways responds to NIS client requests using the data in its local cache, it can respond even when Active Directory is not available.

The following figure provides a simplified summary of operation.

Migrating Information from Existing Maps

If you have a legacy NIS environment, you can import user, group, and network information from existing NIS servers and domains. To import the information directly from an existing NIS server, you need to be able to access the NIS server and NIS domain from the Windows computer where the Access Manager console is installed. For example, if you have configured an existing NIS server to be accessible over the Windows network using Samba or a similar program, you can connect directly to that server and NIS domain to import maps. If the NIS server and NIS domain are not accessible from the Windows computer where the Access Manager console is installed, you should export the NIS maps to text files, then import the text files.

For more information about importing existing user, group, or network information, see Importing and managing NIS maps.

Managing Automounts without Using NIS

If your primary reason for wanting to use NIS is to manage automount information, you have the option of storing the information in Active Directory then retrieving it through the adnisd process or directly through an LDAP request that bypasses the adnisd process.

As an alternative to using the adnisd process, you can use the optional adauto.pl script located in the /usr/share/centrifydc/etc directory to get automount data. The adauto.pl script gets mount point information directly from Active Directory using LDAP. With the adauto.pl script, you can automount home directories using the information from NIS maps without running the adnisd server process.

The adauto.pl script uses the information you store in the auto.home NIS map for the joined zone and any parent zones up the zone hierarchy from which the local computer inherits NIS map entries. Once you add the script to your automount configuration, the automounter program invokes the script and passes it the user name of the user logging on. The adauto.pl script then uses the ldapsearch command to retrieve the mount point information from Active Directory and returns the path to the remote home directory for the user logging on. The automounter will then attempt to connect to that home directory.

To use the adauto.pl script:

1. Add the appropriate auto.home mount points to Active Directory by importing or creating automount NIS maps.

   For more information about importing existing auto.home or auto_home NIS maps, see Importing Network NIS Maps. For information about creating NIS network maps directly in Active Directory, see Creating new NIS Maps in Active Directory.

   For example:

   • Open Access Manager to navigate to a specific zone.

   • Expand the zone to display NIS Maps.

   • Select NIS Maps, right-click, then click New > Automount.

   • Type auto.home or auto_home as the map name, then click OK.

   • Select the new map, right click, then click New to add a new individual map record. For example, create a map record similar to this for all users in a zone:

     Name: * Network Path: lmrh2:/home/&
     Comments: This is the automount path for users in this zone

2. If you are managing mount points on Linux or Solaris, edit the /etc/nsswitch.conf file to change the automount entry from nis to files. For example:

    vi /etc/nsswitch.conf  
    ...  
    automount: files

For other platforms, such as AIX, you can skip this step.

3. Verify the adauto.pl file is available in the /usr/share/centrifydc/etc/ directory and is executable. For example:

   ls -l /usr/share/centrifydc/etc/adauto.pl
   total 1208
   -rwxr-xr-x 1 root root 1921 Sep 27 10:37 adauto.pl

4. Create a symbolic link for /etc/auto.home or /etc/auto_home to the adauto.pl file. For example, on Linux computers:

   ln -s /usr/share/centrifydc/etc/adauto.pl /etc/auto.home

   On AIX computers, create the link to /etc/auto_home:

   ln -s /usr/share/centrifydc/etc/adauto.pl /etc/auto_home

5. Edit the /etc/auto.master or /etc/auto_master file to call the /etc/auto.home file.

   For example, on Linux computers add the following line to the auto.master file:

   /export/home program:/etc/auto.home

   The specific syntax for the entry is different on different platforms. For example, not all platforms allow you to specify the program keyword in the /etc/auto.master file. For more information about the format of the entry, see the main page for auto.master. For example, on SuSE Linux, the entry should look like this:

   /export/home /etc/auto.home

   On SuSE Linux 10, the corresponding entry is:

   /export/home program /etc/auto.home

   On AIX and Solaris computers, add an entry like this to the /etc/auto_master file:

   /export/home /etc/auto_home

   On some platforms, you can invoke automount from the command line without editing the /etc/auto.master file. For example, you can invoke automount without editing the /etc/auto.master file by running a command similar to the following on Linux:

   automount /export/home/ program /etc/auto.home

   Command line mount points are not supported by automount on AIX.

6. Restart the autofs process. For example, on Linux:

   service autofs restart

   On AIX:

   automount

   On Solaris 10, the automount service is managed by the service management facility, smf, under the service identifier:

   svc:/system/filesystem/autofs:default

   You can use svcadm to perform administrative actions, such as stopping and restarting the service.

Mounting Home Directories with the nosuid Option

To increase security when automatically mounting file systems, you might want to configure the auto_home or auto.home NIS map to prevent users from switching their user or group identity. You can prevent users from mounting file systems with a different user context by specifying the nosuid option.

To set the nosuid option in the auto_home or auto.home NIS map:

1. Open Access Manager to import or create a NIS map to be stored in Active Directory.

2. Expand the appropriate zone and the UNIX Data node to display NIS Maps.

3. Select NIS Maps, right-click, then click New > Automount.

4. Type auto.home or auto_home as the map name, then click OK.

5. Right-click the new map.

6. Click New > Map entry to add a new individual map record.

7. Set the fields in the map record similar to the following, to enable mounting of home directories with the nosuid option for all users in a zone:

   Name: * Network Path: homeservername:/home/&
   Options: -nosuid

   You can use a similar approach to specify other or additional mount options—such as noexec and nodev—to the map entry.

Using Executable Maps

On some platforms, local maps that have the execute bit set in their file permissions can be executed by the automount program and provided with a key to be looked up as an argument. The executable map is expected to return the content of an automount map entry on its stdout or no output if the entry cannot be determined. Direct maps cannot be made executable.

For more information about executable maps, see the main page forautomount.

Testing the Status of the Automount Service

After restarting the automount service, you can check the status of the service. For example, on Linux run the following command:

service autofs status

On all platforms, you can run the following command and check the output to verify automount operation:

/usr/sbin/automount -V

You should see output similar to the following:

automount: /export/home mountedautomount: no unmounts

Running the adauto.pl script

You can run the adauto.pl script with no command-line options to manually refresh the automount NIS maps on demand. Alternatively, you can manually add the adauto.reloadtime configuration parameter to the /etc/centrifydc/centrifydc.conf file to control how frequently automount NIS maps are retrieved for the zone. If you manually add this parameter to the configuration files, you can set the value to specify that maps with a time stamp older than the specified number of minutes should be reloaded.

By default, the adauto.pl script gets automount NIS maps from the zone to which the local computer is joined. If the maps are not found in the joined zone, the script will attempt to get the maps from its parent zone of the joined zone. Alternatively, you can create the file /var/centrifydc/kset.automap and type the common name (CN) of the specific Centrify zone from which you want to load the automount NIS maps.

Testing the adauto.pl script results

After you have configured the auto.home and auto.master maps, you can test that the adauto.pl script is working by entering one of the following commands:

/etc/auto.home userid /etc/auto_home userid

This command should return the path from the auto.home or auto_home NIS map stored in Active Directory. For example:

/server/home/userid

Restarting the Automount Service

If you make any changes to the NIS maps in Active Directory, you should restart the automount service.

Distributing Automount Maps

You can create auto.master and auto.home files as NIS maps in Centrify zones and distribute them using symbolic links to the adauto.pl script. In this scenario, you can take advantage of the capability to support executable maps. Depending on your operating system, however, you might be able to take advantage of the Centrify NSS module to automatically mount home directories instead. If your operating system allows you to use the Centrify NSS module, you can add centrifydc to the automount line in the /etc/nsswitch.conf file.

In most cases, you can use the Centrify NSS module to distribute auto.home maps. You cannot use this approach, however, to distribute the auto.master map on most operating systems. For the auto.master map, your options are typically limited to doing one of the following:

• using NIS.
• using LDAP.
• using a local file.

For information about using LDAP, see “Using the Centrify LDAP proxy service” in the Administrator’s Guide for Linux and UNIX. If you use a local file, you can use an adedit script to synchronize the auto.master map to a local /etc/auto.master file. The following example illustrates the steps to synchronize the auto.master map to a local /etc/auto.master file.

1. Add the File Copy group policy to a Group Policy Object that applies to Centrify-managed computers.
2. Enable the group policy to copy a script similar to the following to the directory /usr/share/centrifydc/mappers/machine:

#!/bin/sh  
# Restart adedit using tclsh \
exec adedit "$0" "$@"  
# Bind to an Active Directory domain \
bind -machine domain  
# Select a zone context \
select_zone zone  
catch  {  
     select_nis_map auto.master  
     set output [open /etc/auto.master w 0644]  
     foreach line [gnm] {  
     puts $output [regsub ":1" $line ""]  
       }  
     close $output  
     }  
}

By adding a script similar to this sample script to a GPO, every 90 to 120 minutes the group policy update will execute the script to read the contents of the auto.master map in Active Directory and create a local copy of the /etc/auto.master file.

You can also use this same approach to synchronize all of the maps stored in Active Directory to the local /etc directory. For example:

#!/bin/sh  
 # Restarts using tclsh \
 exec adedit "$0" "$@"  
 bind -machine [adinfo domain]  
 slz [adinfo zone]  
 foreach map [get_nis_maps] {  
    if ([regexp "auto*" $map]) {  
       slnm $map  
       set output [open /etc/$map w 0644]  
          foreach line [gnm] {  
          puts $output [regsub ":1" $line ""]  
       }  
    close $output  
    }  
}

Discontinuing Use of Legacy NIS Servers

If you have existing NIS servers running on your network, you can configure your NIS clients to use the Centrify Network Information Service over time, as needed. Once you have the Network Information Service running, you can also incrementally update the NIS data that’s stored in Active Directory using the Access Manager console. Any updates you make are then propagated to all of theadnisdservers automatically.

When you are satisfied that you have all of the appropriate NIS information stored in Active Directory and have deployedadnisdacross the enterprise, as needed, you can then stop any remaining legacy NIS servers and complete the migration to Active Directory for secure, centralized directory service.