NIS#

NIS (Network Information System) in the current name for what was once known as yp (Yellow Pages). The purpose of NIS is to allow many machines on a network to share configuration information, including password data. NIS is not designed to promote system security. If your system uses NIS you will have a very short /etc/passwd file that includes a line that looks like this:
+::0:0:::i

To view the real password file use this command `ypcat passwd`

Many people are interested in migrating away from NIS. NIS and NIS+ are often being replaced by LDAP (Lightweight Directory Access Protocol).

one of the limitations of NIS, besides several security vulnerabilities, is the limit of the number of users within a group. The client had set up group1, group2 and group3 to overcome this limitation in NIS.

A Novell IDM Solution#

We implemented the following for a large (2,100 users and 1,900 hosts) as follows.

Project Objectives#

  • Allow Migration from NIS
  • Limit impact to the users.
  • Manage all posix Attributes centrally.

Solution Overview#

One of the items that was important was the ability to not force every Unix/Linux account ot change their password's at the same time or on the same system. We wanted the users to continue to use their existing passwords to be able to login to the systems.

Unix and Linux use a crypt() one-way-hash for passwords. We made use of the "Simple Password method" to be able to allow the users to use their existing passwords to login to the "User Application" in order to manage their passwords.

Solution user and Group Management#

After being implemented, new users:
  • Can be created with minimal population of attributes (surname, username and password)
  • The NxSettings driver then populated the posix attributes with defaults which could be edited.
  • Add the user to the appropriate Gorups.
  • Add the user to the appropriate PlatformSet Group(s)

We did the following modifications for the IDV:

Created a java program to create LDIF files from the passwd and group files from NIS. The LDIF added the users as members correct groups as they were set within NIS. Spent a lot of time, as always, dealing with dirty data. We had some groups with the same gidNumbers and some users witht he same username and different uidnumbers.

NxSettings Driver#

Although this driver is usually used with the bi-directional driver, it was a perfect fit for this solution as we wanted to manage the posix Attributes form the IDV and be able to use the existing posix attribute values for the current users.

BTW, We liked this driver. It is like a loop-back driver but has some cool features specific to managing the posix attributes. The driver will actually search the IDV for the uidNumber or gidNumber before assigning to a user. The driver is capable of using LUM if it is available, but will worked fine using a stylesheet to store the number ranges and last number used.

The NxSettings driver allowed this to work.

We did the following modifications to the NxSettings driver.

  • Add the posixAccount objectclass to user objects
  • Add the posixAccount objectclass to group objects
  • Set the driver to only set the posix attribute values, never overwrite existing values.
  • Had the driver set the homeDirectoy to the value of the GCV plus "/CN" so user one was like /home/user1.
  • Had the driver set the loginShell to a default value of the GCV; like /bin/bash
  • Create the gecos from full name or surname if it was not present.
  • Had the driver set the uidNumber to the value of the of the NxSetting.xsl
  • Had the driver set the gidNumber to the value of the of the NxSetting.xsl

Unix/Linx Fan-out#

The Fan-Out driver was used to deploy the actual users to the individual hosts. We implemented the following modifications:
  • Added the posixAccount attributes to the User in the filter.
  • Added the posixGroup attributes to the Group in the filter
  • Modified the platform receiver scripts to Utilize the posix Attributes

How we used the driver:

  • Wrote everything to files with no PAM modifications. (passwords stored locally) The client's desire was not to change too much at a time.
  • One-Way only, no password changes on the local host would be sent to IDV.
  • Managed each PlatformSet by using a Search Object pointed to a individual group. This allows the client to add the user to a group and the user is deployed to all systems (even if it was only one) defined in the PlatformSet.

UNIX/Linx Bi-Directional Driver#

The Bi-Directional Driver was implemented to deploy new users to the existing NIS server. This allowed the client to manage the users and groups centrally while maintaining the two systems for deployment.

The following modifications were done on the Bi-Directional Driver.

  • Added the posixAccount attributes to the User in the filter.
  • Added the posixGroup attributes to the Group in the filter

How we used the driver:

  • One-Way only, no changes on the local host would be sent to IDV.

Limitations?#

Here are some of the items that maybe limitations:
  • No method of having different UID/GID numbers on any hosts, they would all be the same.
  • Likewise the loginShell and homeDirectory would always be the same on each host.
  • No Management for NIS Maps like netgroup, automounts, printers etc.

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-26) was last changed on 08-Dec-2016 09:16 by jim