Re: Solaris NIS+ and Password Aging

From: Darren Moffat (Darren.Moffat@Sun.COM)
Date: 08/22/02


Date: Thu, 22 Aug 2002 10:42:01 -0700 (PDT)
From: Darren Moffat <Darren.Moffat@Sun.COM>
To: Shawn.Henson@motorola.com



>Trying to assist someone with activating password aging. They are currently
>running Solaris 2.x using NIS+. They have indicated that the NIS+ password
>aging feature is broken. I have searched and find a lot of articles about
>this problem. Can you confirm this? This functionality is necessary for an
>appropriate security implementation.

1. Make sure you have the current NIS+ patches for the OS release you
   are deploying.
   
2. What are the errors ?

3. How has this been tested ?

4. What password aging policy are you attempting to use ?
   Note that Account Expiry is on a per host basis, this maybe what is
   meant when someone says password aging and NIS+ don't work.
   
   Password aging does work, account exiry is not useful in a network
   environment.
      

--
Darren J Moffat

INFODOC ID: 16699
SYNOPSIS: Description of "Password Aging"
DETAIL DESCRIPTION:

There are 3 policies implemented by the shadow file (and/or NIS+).

The format of /etc/shadow is:
        
  username:password:lastchg:min:max:warn:inactive:expire:flag

When using NIS+ the shadow field in passwd.org_dir holds:

  lastchg:min:max:warn:inactive:expire:flag

Each of the following policies is implemented using the fields in ()

Policy 1: Password Aging (lastchg, min, max, warn}
This determines when the time periods for which the users password is
active. This is set by using the min/max and warn fields. The
lastchg field refers to the date the user last updated their password.
The warn field is the number of days of warning the user gets on login
before the password actually expires -- note that the warn field and
the expire field perform very distinct functions that are in no way related.

Policy 2: Login Activity (inactive)

This determines the maximum time period a user is allowed between logins.

The intention here is for when a user is away for a long period. For
example, a user goes on holiday for 2 months and does not log in to their
system. The account should be disabled after a week so that it can not
be used while they are out of the office. Set inactivity to 7 days.

This is on a per machine basis and the information about the lastlogin
is taken from the machine's lastlog file.

Policy 3: Account Validity (expire)

The absolute date at which an account expires. There is no warning
given to the user about this.

The intention for this is for contractor/guest/temporary accounts.

Notes

The three policies are distinct and any combinatation of them can be used.

It would be nice if Policy 2 (Login Activity) could be held as a network
wide database, ideally there would be a line in /etc/nsswitch.conf so
that the administrator could define the mix of network/host.

We do not currently implement this in the standard OS, See RFE 4014885
for further details. Solstice Security Manager does have this feature
(but does not do it via NIS/NIS+, instead uses a private DB).

Technically, it is possible to implement this using PAM in Solaris
2.6 onwards, to do this you would write a PAM module that implements:

  pam_sm_open_session() for writing the network lastlog and
  pam_sm_acct_mgmt() for checking the network lastlog

Setup and Default values

The passwd(1) command can be used to set each of the fields for an already
existing user. AdminSuite usrmgr and admintool(1M) prompt for the fields
when creating a new user.

Default values for Min, Max, Warn can be set by giving values to the
variables MINWEEKS, MAXWEEKS, WARNWEEKS in /etc/default/passwd. Note
that setting the default values does NOT enable password aging for
all accounts on the system. The values in /etc/default/passwd are only
used to update the fields in /etc/shadow or the passwd.org_dir table when
a user changes their password (or a priviledge user changes it for them) and
there are no existing values for those fields.

If /usr/bin/admintool is used to create a user and set their intial password,
the values from /etc/default/passwd are NOT used. The admin should setup
the required values in the fields of the admintool(1M) form at the time of
creating the user.

To enable any of the password aging policies on a system wide basis
either use the passwd(1) command with approriate flags to set the fields
for each user or setup defaults in the /etc/default/passwd file and then
expire the passwords of all users on the system by using:

  # passwd -f <login_name>

for each account.



Relevant Pages

  • Re: /etc/default/passwd and SSH
    ... SYNOPSIS: Description of "Password Aging" ... The warn field is the number of days of warning the user gets on login ... the expire field perform very distinct functions that are in no way related. ... The account should be disabled after a week so that it can not ...
    (Focus-SUN)
  • Re: password aging on NIS+ client
    ... > We're running a NIS+ environment on Solaris 8. ... But they can log in on other NIS+ client machines without ... NIS+ password aging does not work and also ...
    (comp.unix.solaris)
  • Re: NIS password change forcing
    ... >> Is it possible to implement password expiration with NIS? ... password aging and expiration where not implemented on NIS. ... DeeDee, don't press that button! ...
    (comp.unix.admin)
  • Re: expired password warnings when logging in via an xterminal
    ... The Shadow password are actually on what was our NIS server. ... the RHEL box uses Shadow password files for NIS and we ... password aging is set to 13 weeks, and the account I'm testing doesn't ...
    (comp.sys.hp.hpux)
  • Re: Password Mgmt
    ... There are 3 policies implemented by the shadow file (and/or NIS+). ... Policy 1: Password Aging (lastchg, min, max, warn} ... the expire field perform very distinct functions that are in no way related. ... The account should be disabled after a week so that it can not ...
    (Focus-SUN)