Re: Password aging on Suns with NIS?

From: Craig (
Date: 02/11/02

  • Next message: Alan Coopersmith: "Re: Password aging on Suns with NIS?"

    Date: Sun, 10 Feb 2002 21:56:21 -0600
    From: Craig <>

    "Michael Vilain " wrote:

    > In article <>, Craig <> wrote:
    > > We want to start enforcing password aging on our Sun workstations and
    > > servers.
    > >
    > > Problems:
    > > 1) We must support selected systems running SunO/S 4.1.4, Solaris 5.3,
    > > Solaris 5.5, and Solaris 5.5.1 due to old apps that won't run on newer
    > > systems and/or need to be kept around to support products for our own customers.
    > >
    > > 2) We run NIS (better than nothing and with our mixed environment, we
    > > wouldn't benefit from NIS+ even if we liked banging our heads against the wall).
    > > 3) NIS table sources aren't kept in /etc.
    > You've painted yourself into a corner. NIS doesn't support password
    > aging. Never did. Sun's responce is "use NIS+".

    True, but Linux-PAM sources apparently do. For Solaris versions already using
    PAM, it looks like I could drop in a replacement for pam_unix_acct, but I suspect
    the tentacles run in unexpected paths. I'd like to try and pin that down before I
    spin my wheels too much.

    > An easy way to get password aging on the Solaris (but not the SunOS)
    > systems is by maintaining a universal password and shadow file and
    > rdist'ing it out. This is inherently insecure in itself.
    > I don't remember when PAM was introduced but I'm sure it's not part of
    > older systems. So, coding your own PAM module isn't an option for you
    > here.

    Perhaps. I was hoping that it would be possible to replace Sun O/S tools like
    telnet, ftp, rsh, login, etc. with ones from pam-tools sources so they'd be the
    PAM-aware along with the whole PAM authentication set from Linux-PAM.
    Then again, I may be able to lock the pre-PAM O/S systems so users can
    only get on remotely from one of the systems that IS PAM-aware already.
    But I'd still need to make them age passwords.

    > Replacing passwd with npasswd (search google--I've heard good things
    > about so check it out)
    > or ganymede (
    > or the perl script (
    > >
    > > Other relevant facts:
    > > We DO use shadow files.
    > SunOS 4.x doesn't support them. How are you getting around that? There
    > was a /etc/secure/adjunct modification out there but I don't know how it
    > worked. Perhaps someone can fill that in.

    True, not locally. But we're using NIS, remember?

    > > We would be using gcc to compile.
    > > Sun platforms range from SPARCstations to UltraSPARC systems, both
    > > workstations and servers.
    > > Users mainly log in to compute servers running Solaris 8 and then go
    > > from there to the systems running old O/S versions with rlogin or telnet,
    > > but that's not an absolute.
    > > Some users have Solaris 5.5.x desktops and there's at least one SunO/S
    > > 4.1.4 desktop. (A case could be made for locking the SunO/S and Solaris 5.3
    > > systems so users could only log in remotely, but that hasn't been brought up
    > > previously.)
    > >
    > > Before I dive headlong into an empty pool, I'd like to find out how much
    > > trouble I'd be in for. I see that others have been looking into using PAM
    > > sources from public domain sites to enable password aging with NIS on Solaris, but it
    > > isn't clear to me if anyone has been successful. There was even a good Perl script,
    > > but unfortunately, it depends on the passwd command run on the NIS server
    > > and that depends on the NIS passwd and shadow files being in /etc. Besides,
    > > scripts can send mail to warn users but ultimately, the only enforcement is to lock
    > > accounts and that just means more calls to sysadmin to re-enable accounts. I'd
    > > prefer proactively making the users change their passwords when they attempt to log in if
    > > they haven't responded to warnings before the old password "times out".
    > I don't recall if an aged password will force selecting a new one. I
    > vaguely recall that it just fails on the next login. You may have your
    > operations staff doing a lot of password resets for people who don't
    > know the requirements for a valid password (man passwd). We had to
    > explain that a lot to users who still didn't get it.

    I won't swear to it, 'cause all the code scanning I've done is starting to run together,
    but I thought the pam_unix_acct module in the Linux-PAM sources issued different
    tokens for passwords that were about to expire ("max - warn" days) vs. ones that
    hadn't been changed in "max" days.

    Yeah, we try to explain password rules, but...

    > >
    > > Given this background, here are my questions:
    > > A) Can I even get PAM to work on SunO/S 4.1.4 without a sledgehammer?
    > Got sources?

    For PAM, yes. For SunO/S, no.

    > > B) Am I in for a lot of work massaging Make files to build the code on
    > > Sun systems for the various O/S versions? ...for the various hardware types?
    > NIS in an all SunOS/Solaris environment didn't need any sort of
    > specialized make for it in 4.1.4/2.3 days. Don't think it will be a
    > problem now, if you drop the password aging requirment.

    At least I risk having to deal with 32- vs. 64-bit and SunO/S vs. Solaris compatible
    binaries, but it may suffice to use the least-common denominator -- what works on
    SunO/S may be usable on Solaris as well. I am being open to the possibility that
    there could be code generation issues between SPARC and UltraSPARC or
    SS5/10/20 vs. E250/450/3000 vs. SunBlade 1000, etc.

    > > C) How far-reaching would this be?
    > > (It looks like I'd need to do pam_unix_acct from Linux-PAM-0.75 at
    > > a minimum, and if I want to, add pam_cracklib to encourage better
    > > passwords.) Would I have to compile replacements for other tools? (e.g.,
    > > yppasswdd or others from a ypbind, yp-tools, or ypserv source package?)
    > > Probably it would take the whole Linux-PAM-0.75 package (and
    > > yp-tools, as well) to implement on the SunO/S systems, right? (And what
    > > else, besides?)
    > Something you may not even have though about is password history which
    > Solaris doesn't do. At best, it can prevent the previously expired
    > password from being used again by limiting the age of the password
    > change (e.g. user's password expires, they change it, then can't change
    > it again for N days).

    Yep. In for a penny, in for a dollar. I could add the pam_unix_passwd module from
    Linux-PAM and, if it doesn't already support a password history, it could be added.

    > > D) What huge gaping sinkhole(s) haven't I thought of?
    > You might want to consider doing a business risk analysis which outlines
    > the development costs of supporting AND MAINTAINTING this requirement
    > with the security risks. Let upper management know what it will cost in
    > dollars, time, and people to do this project. You may end up with it
    > backburnered or the orders to "make it so".

    Love to. Need more info first.
    It won't get killed, but at least they'd be warned up-front about the cost.

    > --
    > Michael Vilain, Certified Advanced Rolfer
    > Envision a just and peaceful world, in which
    > all people achieve their full potential and
    > live with love, respect, and compassion.

    Appreciate your input so far. Any more? Anyone else?