Hi,

We're looking at the possibilities to implement our "Authentication and
Password Policy" on Solaris systems. We have mainly Solaris 8 systems
much more than Solaris 9 systems.

My question is if it is possible to implement such policy stated below:

--
Passwords that validate a candidate username's access to <ourCompany>
systems shall be at a minimum six characters in length for functional
users, 8 characters for administrators. Passwords shall include at
least two alphabetic, one numeric or special character (e.g., an
asterisk or a dash), and may contain at least one upper case and one
lower case character. Systems shall prohibit the use of simpler
passwords.
--

I wonder if anyone has experience with this kind of implementation on
Solaris 8/9 systems. If yes, would you recommend local solution or
Identity Management usage?

Thanks in advance,

-Bora

In article <1131718709.919771.300530@g49g2000cwa.googlegroups.com>,
 "BoraBaysal" <bora_baysal@hotmail.com> wrote:

> Hi,
> 
> We're looking at the possibilities to implement our "Authentication and
> Password Policy" on Solaris systems. We have mainly Solaris 8 systems
> much more than Solaris 9 systems.
> 
> My question is if it is possible to implement such policy stated below:
> 
> --
> Passwords that validate a candidate username's access to <ourCompany>
> systems shall be at a minimum six characters in length for functional
> users, 8 characters for administrators. Passwords shall include at
> least two alphabetic, one numeric or special character (e.g., an
> asterisk or a dash), and may contain at least one upper case and one
> lower case character. Systems shall prohibit the use of simpler
> passwords.
> --
> 
> I wonder if anyone has experience with this kind of implementation on
> Solaris 8/9 systems. If yes, would you recommend local solution or
> Identity Management usage?
> 
> Thanks in advance,
> 
> -Bora

Aside from the length requirement, this sounds like the default settings 
for Solaris passwords.  At least on Solaris 7, it was the case.  Now I 
don't know if you can require a specific length system-wide or on a per 
account basis.  I vaguely recall that it was system-wide, so you'll have 
to make administrators conform using the honor system.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...

It will be system-wide basis and we want to set this policy on all
Solaris systems. You say it is default settings on Solaris 7+. Do we
have to mess with PAM to do that. I believe PAM is not much mature
especially regarding authentication on Solaris 8.

Would be nice if you let me know any reference doc regarding this.

Thanks,

-Bora

In article <1131750940.965300.207690@g43g2000cwa.googlegroups.com>,
 "BoraBaysal" <bora_baysal@hotmail.com> wrote:

> It will be system-wide basis and we want to set this policy on all
> Solaris systems. You say it is default settings on Solaris 7+. Do we
> have to mess with PAM to do that. I believe PAM is not much mature
> especially regarding authentication on Solaris 8.
> 
> Would be nice if you let me know any reference doc regarding this.
> 
> Thanks,
> 
> -Bora

Don't have specifics.  I never did anything with PAMs, so you're on your 
own with that.  Have you looked at the man pages for stuff like passwd 
and /etc/passwd.conf (unsure of name)?

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...

Will look into that but I'm pretty sure default passwd won't help much,
extended authentication requires messing with either PAM or LDAP (via
IDM as such) involment.

-Bora

In article <1131718709.919771.300530@g49g2000cwa.googlegroups.com>,
	"BoraBaysal" <bora_baysal@hotmail.com> writes:
> Hi,
> 
> We're looking at the possibilities to implement our "Authentication and
> Password Policy" on Solaris systems. We have mainly Solaris 8 systems
> much more than Solaris 9 systems.
> 
> My question is if it is possible to implement such policy stated below:
> 
> --
> Passwords that validate a candidate username's access to <ourCompany>
> systems shall be at a minimum six characters in length for functional
> users, 8 characters for administrators. Passwords shall include at
> least two alphabetic, one numeric or special character (e.g., an
> asterisk or a dash), and may contain at least one upper case and one
> lower case character. Systems shall prohibit the use of simpler
> passwords.
> --
> 
> I wonder if anyone has experience with this kind of implementation on
> Solaris 8/9 systems. If yes, would you recommend local solution or
> Identity Management usage?


Possible?  Anything is possible, but that in particular isn't possible
without additional software; no idea whether anyone has anything that
does exactly that.

The passwd(1) man page

http://docs.sun.com/app/docs/doc/806-0624/6j9vek5cd?a=view

(for Solaris 8; also in Solaris 9) mentions PASSLENGTH in
/etc/default/passwd, but that's only one number, not one for users
and another for administrators.  So you'd have to set that to 8,
except that PASSLENGTH isn't enforced for root anyway, so you might as
well just set it to 6.

As for the rest, that man page says:

    Passwords must be constructed to meet the following requirements:

    * Each password must have PASSLENGTH characters, where PASSLENGTH is
      defined in /etc/default/passwd and is set to 6. Only the first eight
      characters are significant.

    * Each password must contain at least two alphabetic characters and at
      least one numeric or special character. In this case, "alphabetic"
      refers to all upper or lower case letters.

    * Each password must differ from the user's login name and any reverse
      or circular shift of that login name. For comparison purposes, an
      upper case letter and its corresponding lower case letter are
      equivalent.

    * New passwords must differ from the old by at least three characters.
      For comparison purposes, an upper case letter and its corresponding
      lower case letter are equivalent.


Before Solaris 10, there are no options to control any of that other than
the length, and none of those (even PASSLENGTH) restrict root, which can
set any password it wants for itself or any other account.  So you might
as well set PASSLENGTH to 6 and just expect administrators to voluntarily
comply with the length as well as the rest.  (Even if there were some
optional software that would enforce exactly your PHB's requirements, root
could always circumvent it pretty much tracelessly anyway.)  Other than
that, the default behavior is actually quite close to what they're asking
for.

In principle, one could write (in C, and compile as a shared object) an
alternative PAM module that implemented pam_sm_chauthtok(3PAM), and I
_think_ it could enforce any crazy policy that could be dreamed up,
although as I said, root could always take it out of the configuration or
get around it in other ways anyway.  And I'm not sure whether there's
enough info out there to create such an alternative PAM module just from
documentation.  It also looks like Solaris 10 has a lot more flexibility
(including multiple password encryption algorithms), and could probably
be adjusted to get very close indeed to your PHB's rules, but probably
nothing could accomodate any possible arbitrary policy without writing
code.

So (with PASSLENGTH set to 6), you're already very close indeed, and it
would take a fair amount of work (at least prior to Solaris 10) to get
closer, probably represent an ongoing support burden, if commercial
software were required would cost some actual $$, and not really be able
to enforce anything on an administrator anyway.  You might as well
persuade 'em that it's "good enough" as is.  Other things, like
configuring auditing to record account related events
(logins/logouts/password changes; audit class "lo") would arguably be more
useful in the real world anyway that splitting hairs on some policy. 
Typically, these policies come from some consultant or other
operates-in-a-vacuum sort, and a best effort with the existing systems
and software is usually accepted in the end.  There have also been
commentaries by those who think about such matters for a living to the
effect that some of these policies can get silly or even counterproductive;
google for

password policy schneier

if you want to see something that you really won't believe!

If it were me, I might try to write a list of suggestions for how to come
up with a good password; perhaps syllables from two different words,
squeezed into a personal shorthand and with the number or special
character thrown in somewhere - something people could still remember, yet
would neither be in a dictionary nor be something even someone that knew
them could guess.  Such a document, if well written (and to the extent
that users read anything you give 'em anyway; most people are far from
compulsive readers and probably couldn't name a common detergent
ingredient, even though it's on the label of every shampoo and toothpaste
container), and in combination with auditing, saving audit files, and
someone actually skimming through them for anomalies once in awhile, would
do far more that PHBs listening to consultants could ever accomplish.

Of course, both PHBs and consultants tend to offer up no-brainer
approaches, which are very nearly useless in nontrivial situations but
reduce the need to think (or evaluate) effectively, something neither most
PHBs (nor most other people, for that matter) are particularly consistent
at.  But process and policy are necessary but not sufficient (compared to
training, evaluation, and auditing), so the overhead (cost, ultimately) of
process and policy should be kept within bounds.  But maybe we're better
off if large organizations drown in policy; otherwise, there'd be no need
for new and independently owned startups. :-)


-- 
mailto:rlhamil@smart.net  http://www.smart.net/~rlhamil

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

In article <11ncobg4mleqef0@corp.supernews.com>,
 Richard.L.Hamilton@mindwarp.smart.net (Richard L. Hamilton) wrote:

> If it were me, I might try to write a list of suggestions for how to come
> up with a good password; perhaps syllables from two different words,
> squeezed into a personal shorthand and with the number or special
> character thrown in somewhere - something people could still remember, yet
> would neither be in a dictionary nor be something even someone that knew
> them could guess.  Such a document, if well written (and to the extent
> that users read anything you give 'em anyway; most people are far from
> compulsive readers and probably couldn't name a common detergent
> ingredient, even though it's on the label of every shampoo and toothpaste
> container), and in combination with auditing, saving audit files, and
> someone actually skimming through them for anomalies once in awhile, would
> do far more that PHBs listening to consultants could ever accomplish.

The best method I've found for rugged but memorable passwords is to use 
initial letters from favorite song lyrics, with numbers and symbols 
substituted where reasonable.  For instance, the Stones' "You Can't 
Always Get What You Want" might be:

      U!4g?uw.

Looks like gobbledygook at first, but the logic is there and somehow 
implants itself into your brain pretty well.  To be even more obscure, 
use a weird band with non-English lyrics.  For instance, if you're some 
freakish Rammstein fan <whistles & stares innocently into space> then 
you might have:

      Du hast mich gefragt und ich hab nicht gesagt
      [You have (me) asked and I have not spoken]

And that could become:

      dhm?&1h!G

The advantage here is that these passwords pass every security test, 
except for the occasional lame website or MS product that won't accept 
any non-alphanumerics except for an underline.

To get around the problem of having 80 different passwords for 80 
different secure websites, you can invent a system of (for instance) 
using 2 chars of the password to have unique site-specific initials... 
like "gm" for gmail... and put these at position 2 and 3 of your 
password.  So the first password becomes "Ugm!4g?uw." for gmail, and 
"Usd!4g?uw." for slashdot.  It's not NSA-level secure of course, but 
very unlikely that anyone will ever break your system (or suspect that 
you even have one) and it doesn't require any client-side software to 
burp up site-specific hashes for you.

> Of course, both PHBs and consultants tend to offer up no-brainer
> approaches, which are very nearly useless in nontrivial situations but
> reduce the need to think (or evaluate) effectively, something neither most
> PHBs (nor most other people, for that matter) are particularly consistent
> at.  But process and policy are necessary but not sufficient (compared to
> training, evaluation, and auditing), so the overhead (cost, ultimately) of
> process and policy should be kept within bounds.  But maybe we're better
> off if large organizations drown in policy; otherwise, there'd be no need
> for new and independently owned startups. :-)

Waaaay too much thinking, but you're probably right.

Thanks much for the long and detailed reply for my topic.

Looks like we will start with PASSLENGTH setting for regular users and
look into possibilities to restrict root somehow.

We have Novell's IDM project going on and all systems (including UNIX
systems) will be integrated sooner or later. While IDM restricts
regular UNIX users' password changes, most probably it won't do much
for system users.

I think the best way is to restrict both regular and system users with
one policy and do it locally once the system installed initially from
an image. But I just don't know how to accomplish that...

-Bora

In article <1131845347.436753.93390@g47g2000cwa.googlegroups.com>,
 "BoraBaysal" <bora_baysal@hotmail.com> wrote:

> Thanks much for the long and detailed reply for my topic.
> 
> Looks like we will start with PASSLENGTH setting for regular users and
> look into possibilities to restrict root somehow.
> 
> We have Novell's IDM project going on and all systems (including UNIX
> systems) will be integrated sooner or later. While IDM restricts
> regular UNIX users' password changes, most probably it won't do much
> for system users.
> 
> I think the best way is to restrict both regular and system users with
> one policy and do it locally once the system installed initially from
> an image. But I just don't know how to accomplish that...
> 
> -Bora

The problem with "restricting root" is that you really can't, for all 
intents and purposes.  What they did at my last contract was implement a 
multi-system sudo file using a commercial version of sudo called 
Powerbroker from Symark.  It would work just find with a working 
network--all the admins login to their regular user accounts and only 
use sudo when they need root with all the sessions logged to a logging 
host.  But if the net is down or your system is in single-user mode, you 
need the real root password.  That required paging a manager, getting a 
combination, and opening a safe with the root passwords inside a sealed 
envelop.  After the incident, they were changed, even for routine 
maintenance work by SUN.   That might be your start.  

Make the PHB who's pushing for this level of security the first person 
that's paged when you need to real root password.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...