Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

user account passwd issues 2

Status
Not open for further replies.

raggmopp

MIS
Feb 14, 2002
40
US
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 name:passwd: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?
 
Are you certain it's not still trying to change the NIS password? What does ypwhich passwd return?

Annihilannic.
 
# 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

 
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.
 
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

 
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.
 
Again, many thanks.

Yes, ssh is the connection of choice.

I will investigate the lastchg command as well.

Thanks!
 
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.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top