password ageing in non-trusted sites: sorry

[Managed Services]

Hi All
We have a password changing issue an a non-trusted Unix site running hp-ux11.00, when ageing is set, or forced change is activated. Changing root passowords or user passwords via root has no problems.

However, when users try to change their own passwords they get the message 'sorry':
----
HP-UX charter1 B.11.00 U 9000/800 (td)

login: test
Password:
Your password has expired. Choose a new one
You can now choose the new password.

A valid password should be a mix of upper and lower case letters,
digits and other characters. You can use a 6 character long

password with characters from at least 3 of these 4 classes.
Characters that form a common pattern are discarded by the check.

Enter new password:
Re-type new password:
Changing password for test
Sorry.
login:

-----------
Any ideas to get around this? PASSWD_HISTORY_DEPTH has been set to 1 for now.

Thanks
Stephen

[Bruno Vidal]

Hi,
It seems that you don't have the standart passwd command, because there is not this kind of messages when password expire. I think you have a passwd software instead of the standart. Try to do "what /usr/bin/passwd".

Cheers.

[Managed Services]

Update
------
1. The user is able to change the password when logged in as themselves, however if passwd -f *user* is invoked by root then it gives the above problems when trying to log in.
2. This is a non-trusted site but there are quite a few stringent password changing procedures being activated e.g. similarity to the previous login and recognised strings (like user), which i would only expect trusted sites to use.

[Darren Prior]

Hi,

Can you post the results of:

which passwd (from a non-root user)
what /passwd
ll /passwd

regards,

Darren.

[A. Clay Stephenson]

Are you, by any chance, running NIS? This sounds a lot like the messages that yppassdd will issue (and then relax after 3 attempts).

[Managed Services]

As non Root
-----------
test (charter1) > whence passwd
/bin/passwd
test (charter1) > what /bin/passwd
/bin/passwd:
$Revision: 82.10.1.5 $
PATCH_11_00: passwd.o 01/05/23
test (charter1) > ll /bin/passwd
-r-sr-xr-x 5 root bin 49152 May 23 2001 /bin/passwd

As Root
--------
# whence passwd
/usr/bin/passwd
# what /usr/bin/passwd
/usr/bin/passwd:
$Revision: 82.10.1.5 $
PATCH_11_00: passwd.o 01/05/23
# ll /usr/bin/passwd
-r-sr-xr-x 5 root bin 49152 May 23 2001 /usr/bin/passwd


Same patch, different location. Any ideas??

[Keely Jackson]

Hi

Have you checked whether there is a minimum time set between password changes. If the user tries to change the password before that time is up they will get a 'sorry' message.

Cheers
Keely

[Tyler Easterling]

Hi Stephen,

Just a guess but I have seen similar issues while using a machine on an NIS domain. If you don't have the nsswitch.conf file configured to the contrary, your system may attempt to change the NIS password before the /etc/passwd file password. This could lead to the "Sorry." you mentioned.

Make sure you are explicite when selecting the repository in which the user should change their password.

# passwd -r files -f

Where did you set up PASSWD_HISTORY_DEPTH?
To my knowledge PASSWD_HISTORY_DEPTH is only currently supported through trusted system.

Tyler

[Caesar_3]

Hello!

In trusted mode i use the /usr/bin/passwd command and as i see your root also
so try to use as non root /usr/bin/passwd
and see if it will help you.

Caesar

[Bill Hassell]

The /etc/default/security file has a number of possible settings, but the majority are ignored (silently) in non-Trusted systems. Specifically, the password history is kept in a Trusted directory so h=no history is kept in a non-Trusted system.

It is important to retire the use of which and whereis to determine where a command is found. POSIX shells (ksh, HP's sh, bash, etc) all have the right command: type

type passwd

(type is an alias to whence -v) To see how which and whereis are ineffective, try this:

which let
whereis let
type let

The let command is indeed a valid task within the shell but which and whereis have no clue. And which is actually a csh script! But it gets worse: which and whereis do NOT follow the $PATH values so the following shows how an unwitting user might run the wrong command:

cat /dev/null > ./su
export PATH=.:$PATH
which su
whereis su
type su

The last command (type su) shows what is going to happen and it is the only action that counts! The user will run something called su in the current working directory--a very bad situation. So type (or whence -v) should always be used to determine where a command is located.

In the example above, the ordinary user seems to be getting passwd from a non-existant directory: /bin YES, /bin is NOT a directory and like Solaris and other Unix's that follow the V.4 standard for filesystem layout, /bin disappeared and became /usr/bin. Now for the last 10 years or so, /bin (and /lib) have existed as a transition crutch (actually a symbolic link) but will someday disappear or at least become optional rather than the default. /bin should look like this:

ll /bin
lr-xr-xr-t 1 root sys 8 Dec 19 2002 /bin@ -> /usr/bin

If instead you get a list of files, you've been hacked or at least someone with root privileges has messed up a critically important directory link. If the link is OK, then you'll need to find out why /bin/passwd is being located by which rather than /usr/bin. This behavior can be duplicated with:

export PATH=/bin:$PATH

but that is a bad situation since it is a non-standard PATH value. In HP-UX, the PATH variable is set in /etc/profile and /etc/csh.login by reading /etc/PATH, so check /etc/PATH for non-standard locations. /etc/PATH can be a big security risk if it includes directories with world-writable permissions (perhaps /usr/local/bin?).

So to make sure you are really running ANY command, always use a full pathname as in:

/usr/bin/passwd -f

[Scott Cheadle]

Hi,

The password changing mechanism for aged passwords, or forced change passwords does not use the passwd command at all. It uses a pam.conf entry, so this would be where to look. This is why root changes work, ie you are using the passwd command, whereas pam.conf entries do not.

I had problems with this when implementing eTrust Access Control for password aging, meaning that native aging needed to be switched off, as replacing the passwd executable with sepasswd, (eTrusts passwd program) did not make any difference as the pam library routine was called rather than the program.

[Managed Services]

After detailed investigation this has been tracked down to pam.conf policies. These had been changed - and probably not tested sufficiently - by the previous system admins. Although the syntax is correct the pam libraries are producing spurious outputs.
The password management section of pam.conf is:
#
# Password management
#
login session required /usr/lib/security/libpam_updbe.1
login password required /usr/lib/security/pam_passwdqc.so ask_oldauthtok
=update check_oldauthtok min=disabled,6,6,6,6 max=8 passphrase=0 enforce=users r
etry=3 random=0 match=3
login password required /usr/lib/security/libpam_unix.1
passwd session required /usr/lib/security/libpam_updbe.1
passwd password required /usr/lib/security/pam_passwdqc.so ask_oldauthtok
=update check_oldauthtok min=disabled,6,6,6,6 max=8 passphrase=0 enforce=users r
etry=3 random=0 match=3
passwd password required /usr/lib/security/libpam_unix.1 use_first_pass

The use_first_password argument is causing the premature abort and 'sorry' message, and the pam_passwdqc.so is very restrictive yet does not change the password!

I've turned them off... :) Anyone any ideas why they don't? work. Curious.
Stephen

[Steven E. Protter]

Things to think about:

I won't be able to follow up.

Was this system ever trusted? Maybe the downgrade failed.

pwck

grpck

These two commands look for inconsistencies in the /etc/passwd file.

Check the permissions of the passwd command. It must have root suid priveledges or regular users won't be able to change their passwords, they'll get the sorry command.

Here are the correct permissions.
-r-sr-xr-x 5 root bin 45056 Nov 14 2000 /usr/bin/passwd

Whereever password history is being kept: Who owns the file, and what are the permissions.

Getting a common theme?

Good Luck,

SEP
The Sundance Wyoming Sysadmin
Any 9000 Servers in these hills?

[Managed Services]

not ever a trusted site - as far as I'm aware.

passwd permissions ok

pwck .. produced a couple of errors for invalif homes directories. not bad for 500+users
grpck... clear

The issue it appears is pam.comf and the login entries.

I'm submitting a new thread for this.
Stephen