Re: Password aging on Suns with NIS?
From: Craig (huffcs@mc.net)Date: 02/11/02
- Previous message: Ken Ashe: "Re: Microsoft finally acknowledges the security drumbeats"
- In reply to:(deleted message) Michael Vilain
- Reply: Pontus Skold: "Re: Password aging on Suns with NIS?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 10 Feb 2002 21:56:21 -0600 From: Craig <huffcs@mc.net>
"Michael Vilain " wrote:
> In article <3C67113A.79E0E98F@mc.net>, Craig <huffcs@mc.net> 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 (http://www.arlut.utexas.edu/gash2/)
> or the perl script (http://www.vais.net/~efinch/pwaging.html).
>
> >
> > 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
> rolfer@vilain.com
> http://www.vilain.com
>
> 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?
- Next message: Alan Coopersmith: "Re: Password aging on Suns with NIS?"
- Previous message: Ken Ashe: "Re: Microsoft finally acknowledges the security drumbeats"
- In reply to:(deleted message) Michael Vilain
- Reply: Pontus Skold: "Re: Password aging on Suns with NIS?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
