NIS authentication issues

Hello,
I’ve recently set up a suse 10.3 machine with ypserv to replace an old Solaris NIS server which was dieing.
All clients can bind to this new nis server, however many redhat and Irix machines are unable to authenticate. All nodes can bind, and I can ‘su’ to any user. However I cannot log in via ssh.

Please help. :slight_smile: I’ve tried many solutions, many modifications to nsswitch.conf.

Will

On Mon, 2008-06-09 at 15:06 +0000, wedsall wrote:
> Hello,
> I’ve recently set up a suse 10.3 machine with ypserv to replace an old
> Solaris NIS server which was dieing.
> All clients can bind to this new nis server, however many redhat and
> Irix machines are unable to authenticate. All nodes can bind, and I can
> ‘su’ to any user. However I cannot log in via ssh.
>
> Please help. :slight_smile: I’ve tried many solutions, many modifications to
> nsswitch.conf.

What hash are you using inside of NIS for the passwords?

Chris,
Thanks for your reply.

I have to admit i’m not sure how to properly answer your question.

An example of one of my passwords, one starts with $2a

My nis server’s pam passwd file contains the following:
password requisite pam_pwcheck.so nullok cracklib
password required pam_unix2.so use_authtok nullok

My redhat nis client pam passwd file contains the following:
password required /lib/security/pam_cracklib.so retry=3 type=
password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow nis
password required /lib/security/pam_deny.so

On Mon, 2008-06-09 at 16:56 +0000, wedsall wrote:
> Chris,
> Thanks for your reply.
>
> I have to admit i’m not sure how to properly answer your question.
>
> An example of one of my passwords, one starts with $2a

I won’t swear to this, but it’s likely the problem. That means
your password hashes are stored in blowfish format.

Try editing your /etc/default/passwd file and changing (or adding)
CRYPT_YP=des or if you don’t mind some loss of protability (in
favor of better security) CRYPT_YP=md5. Actually, you might
want to use CRYPT=des if this is the NIS server… that way
the accounts created locally have a DES hashed password
and will be exported that way when the NIS maps are created
and pushed (on my SLES 10 based NIS server we have the following
in our /etc/default/passwd):

This file contains some information for

the passwd (1) command and other tools

creating or modifying passwords.

Define default crypt hash

CRYPT={des,md5,blowfish}

CRYPT=des

Use another crypt hash for group passwowrds.

This is used by gpasswd, fallback is the CRYPT entry.

GROUP_CRYPT=des

We can override the default for a special service

by appending the service name (FILES, YP, NISPLUS, LDAP)

for local files, use a more secure hash. We

don’t need to be portable here:

CRYPT_FILES=des

sometimes we need to specify special options for

a hash (variable is prepended by the name of the

crypt hash).

BLOWFISH_CRYPT_FILES=10

For NIS, we should always use DES:

CRYPT_YP=des

Then create a new NIS user with a password and see if
things work better at least for that user.

There’s probably a way to get the RH client to do blowfish.
The only thing guaranteed to work is DES, but it’s easy
to password crack (especially since they’re all exposed
via NIS). MD5 is better and should work across Linux hosts, but
some Unix’s especially older ones will only support DES.

>
> My nis server’s pam passwd file contains the following:
> password requisite pam_pwcheck.so nullok cracklib
> password required pam_unix2.so use_authtok nullok
>
> My redhat nis client pam passwd file contains the following:
> password required /lib/security/pam_cracklib.so retry=3 type=
> password sufficient /lib/security/pam_unix.so nullok use_authtok
> md5 shadow nis
> password required /lib/security/pam_deny.so
>
>

Chris,
Thanks for your reply.

This was exactly the problem. I had changed a few passwords manually from the command line on the NIS Server, which set them to blowfish. On the next push of maps, it had pushed those passwords in blowfish.

Thank you!