user account passwd issues 2

[raggmopp]

Hi all:

Working with Solaris 9. Recently removed NIS from the systems so we could have better security/audit capabilities for user accts and their passwds.

I have an acct that is setup, has the corresponding shadow entry, has the required entries in the shadow fields as listed below;
ediadmin:tjH7LEd7vg0SY:13220:1:90:10:30::
user acct nameasswd:date of last change:min change:max change:warning:inactive days::

The system never asks to change the passwd. Worse yet, if I try to change the passwd (as root) for the acct I get permission denied.

What is up?

 

[Annihilannic]

Are you certain it's not still trying to change the NIS password? What does ypwhich passwd return?

Annihilannic.

 

[raggmopp]

# ypwhich
ypwhich: can't communicate with ypbind
# ypwhich passwd
ypwhich: clnt_create error: RPC: Unknown host
#

The output from the 'ypwhich' & 'ypwhich passwd' commands are listed above

 

[Annihilannic]

It looks like you haven't *completely* disabled NIS. Did you put in a non-NIS /etc/nsswitch.conf? You also need to move or remove /var/yp/binding/<oldnisdomainname> and /etc/domainname.

You *should* get:

[tt]$ ypwhich passwd
ypwhich: the domainname hasn't been set on this machine.
$[/tt]


Annihilannic.

 

[raggmopp]

The nsswitch.conf file. (I am kicking myself - I know that one.) Many thanks Annihilannic!

Alone the same lines, why won't the passwd expire? As can be in my previous post I have the /etc.shadow file configured to for 90 days, 1 MIN_DAY, 10 WARN, 30 inactive.

Yet, the passwd will not expire. I can manually reset the passwd and I will get a new 90 day count down but when this time is reached the system will not warn or force a passwd change.

Help

 

[Annihilannic]

I just tested on a Solaris 9 box with that account and those settings and it seems to work fine.

With 13220 (today is 13297) the warning time hasn't been reached yet. I tried it with 13210 and got:

[tt]SunOS 5.9

login: ediadmin
Password:
Your password will expire in 3 days.
Last login: Mon May 29 12:01:57 from localhost
$[/tt]

HOWEVER, that was using telnet. With ssh (using OpenSSH_4.1p1) I don't get any warning; is that how you are connecting?

Having said that, when I set lastchg to 13200 I get prompted to choose a new password, whether connecting via telnet or ssh.

Annihilannic.

 

[raggmopp]

Again, many thanks.

Yes, ssh is the connection of choice.

I will investigate the lastchg command as well.

Thanks!

 

[WhiteVolg]

MANY versions of ssh aside from the one shipped by Sun for Solaris 9 or Solaris 10, are not configured using the --with-pam
option. No PAM = No password aging. It also causes wtmp/utmp problems as well. See here:

3.15 - OpenSSH versions and PAM behaviour.
Portable OpenSSH has a configure-time option to enable sshd's use of the PAM (Pluggable Authentication Modules) interface.

./configure --with-pam [options]

To use PAM at all, this option must be provided at build time. The run-time behaviour when PAM is built in varies with the version of Portable OpenSSH, and on later versions it must also be enabled by setting UsePAM to yes in sshd_config.

The behaviour of the relevant authentications options when PAM support is built in is summarised by the following table.

Version UsePAM PasswordAuthentication ChallengeResponseAuthentication
<=3.6.1p2 Not applicable Uses PAM Uses PAM if PAMAuthenticationViaKbdInt is enabled
3.7p1 - 3.7.1p1 Defaults to yes Does not use PAM Uses PAM if UsePAM is enabled
3.7.1p2 - 3.8.1p1 Defaults to no Does not use PAM [1] Uses PAM if UsePAM is enabled
3.9p1 Defaults to no Uses PAM if UsePAM is enabled Uses PAM if UsePAM is enabled

[1] Some vendors, notably Redhat/Fedora, have backported the PasswordAuthentication from 3.9p1 to their 3.8x based packages. If you're using a vendor-supplied package then consult their documentation.

OpenSSH Portable's PAM interface still has problems with a few modules, however we hope that this number will reduce in the future. As at the 3.9p1 release, the known problems are:

* Modules relying on module-private data (eg pam_dhkeys, pam_krb5, AFS) may fail to correctly establish credentials (bug #688) when authenticating via ChallengeResponseAuthentication. PasswordAuthentication with 3.9p1 and above should work.

You can also check bugzilla for current PAM issues.