Network authentication using NIS fails

Things have been quiet here for a while. Does this mean people have found a way around this? I'm still having no luck. Please post if you have a working NIS authentication on Lion with instructions.

Best

Since I only have one system in this situation, I decided to reinstall from scratch. I backed-up users' data and reinstalled Snow Leopard, but I did not configure NIS at this point. I upgraded to Lion then I configured NIS. I finally reinstalled all applications, restored users' data and recreated all local accounts. Everything is working fine now.

Like others here, we have also been using linux nis servers and macos nis clients for years, and we've run into the same problem that others have reported here with our first deployment of a macos lion nis client.

What is working for us on the macos lion nis/nfs client:

- nis domain name is set as shown with 'domainname' command.

- nis is bound to the server and shown with 'ypwhich' command.

- nis maps can be retrieved from nis server as shown, for example, 'ypcat passwd'.

- nfs-mounted path from server shows expected uids/gids found from nis server.

What is not working yet:

- ssh logins with password (key-based logins without password work fine).

- anything else that authenticates against a user's password (eg. console login).

What we find in logs:

/var/log/opendirectory.log

2011-09-20 09:56:02.233 EDT - failed to get YP map list

/var/log/secure.log

Sep 20 09:55:58 x sshd[14081]: error: PAM: authentication error for x from x via x.x.x.x

macos lion is using pam? is that new for macos?

that's where we're stuck right now. has anyone else gotten this far, noticed similar behaviour, and then gotten past this problem?

Hi, have you:

1. Re-enabled the checkbox under NIS in Directory Utility that tells it to "Use NIS domain for authentication"? Installing Lion seems to disable this.
2. Added a complete list of ypservers's IP addresses to the "Servers" box on that same screen? Lion seems to refuse to authenticate if ypservers are discovered through broadcast.

Let me say that as far as #2 goes, this has been considered unsafe for ages. On the other hand, all security decisions are context based, and we were using broadcast safely within our particular context. So it's not surprising that Apple has done this, but it really wasn't strictly necessary.

I have done both. Authentication works for me. On the other hand, I still get that "failed to get YP map list" error. And I get the yellow light with "Some network accounts are available". I'm not sure why since the only network accounts we are using are NIS, and that's now working. But that's where I stand now.

tom

I've now also been able to eliminate the "Some network accounts are available" message.

In Directory Utility, under Search Policy, I had both BSD/mydomain and NIS/mydomain. I think NIS/mydomain was added automatically when I checked the checkbox to authenticate with NIS, and I think that BSD/mydomain was left over from (Snow) Leopard. Basically they've changed the name as it appears there and the old name was cruft that was confusing things. After dropping the BSD/mydomain from that list, the yellow light and "Some network..." message disappared (and authentication continued to work properly).

I am still getting tons of "failed to get YP map list" in my opendirectory.log file though. They seem to happen every five to ten seconds, in groups of three or more.

tom

I am getting "failed to get YP map list" messages too.

I looked at the log file on the NIS server my Mac Pro is binded to and found a lot messages like this one:

Sep 20 13:47:08 fn1 ypserv[3033]: refused connect from aaa.bbb.ccc.ddd:753 to procedure ypproc_match (imi,master.passwd.byname;-4)

where aaa.bbb.ccc.ddd is the IP address of the Mac Pro.

The map "master.passwd.byname" does not exist in my NIS environment. It seems to be specific to MacOS.

Denis

Yes, we have nis enabled and properly configured in directory utility.

In your case, how are your passwords encrypted? des, md5, blowfish, or something else?

Are your encrypted passwords merged into your nis passwd map, or do you have an nis shadow password

map?

We are not using shadowing. We've experimented with it in the past. Under Leopard I remember an interoperability issue where Leopard wanted shadow.byname map, and Linux/Solaris wanted passwd.adjunct (or something like that). Maybe that changed?

AHA! We use predominately DES passwords, but some systems have been inserting MD5 passwords. We've been tolerating this because basically only our old Solaris 8 systems don't understand this. BUT, I just tested one of these accounts on Lion and it is NOT authenticating that account.

On most modern systems, MD5 passwords are handled seamlessly via the system crypt call. And on some systems this call is configurable. Maybe there's a way to turn on or off various hash algorithms? Or did Apple just break it?

tom

We've been through this before with apple nis clients and modern linux nis servers that default to blowfish encryption. In those cases we've had to configure pam on our linux nis servers to use md5 or des encrypted passwords.

- If your encrypted password string begins with a $1$ then it's encrypted with md5.

- If it begins with a $2a$ then it's encrypted with blowfish.

- If there is no $ prefix then it is encrypted with des.

- There may be other prefixes I'm not aware of yet.

For the particular linux nis server that we're dealing with in this thread, all users have md5-encrypted passwords, and these all work fine from macos {snow}leopard nis clients.

We don't have any evidence that this is the cause of the problem with our macos lion nis client, but I suppose it's possible that macos lion, as configured by default, is requiring either des (a step backwards) or blowfish (a step forwards) or some other encryption scheme.

it would be nice to find this clearly documented somewhere. I recall finding a wikipedia page in the past that documented the history of macos password encryption but I can't find that now.

Can you manually edit an account and give it a DES password? I'm pretty confident it will work.

In FreeBSD you can configure various crypt hash algorithms this with /etc/login.conf, but I see no evidence that this is available in any version of OS X.

I'm thinking they simply broke md5. And maybe others, we don't have any blowfish passwords to test.

tom

I've submitted a bug report to apple regarding broken md5 passwords under NIS on Lion.

tom

On our NIS server, encrypted passwords are merged into our nis passwd map. Based on the information you gave about the encrypted password beginning string, most of the passwords are DES. Only a few are md5. I looked at the NIS password of the users that logged on successfully on the Mac Pro using ssh and they are all DES. I will find a way to change my NIS password so it is md5 instead then I will try to log on the Mac Pro.

The way the NIS password is encrypted depends on how the client from which you set your password is configured.

Denis

I changed my NIS password from a Linux system using "passwd" instead of the usual "yppasswd". The password now begins with $6$ and I cannot log anymore on the Mac Pro (running Lion) using ssh. I was able to log on before with my DES encrypted password. Looks like "passwd" generates a password with a different encryption type than "yppasswd" does. I always ask my users to use "yppasswd" to change their password.

This confirms that the problem is caused by the password encryption type. If the password is not DES encrypted, it won't work on Lion.

I tried to revert to a DES password using "yppasswd" from the same Linux system but the password still begins with $6$ and it does not work on the Mac Pro. To revert to a DES encrypted password, I had to log on as root on my NIS master server, edit the passwd file and clear the password, run "make -C /var/yp" and then change the password (still logged as root) using "yppasswd". Now my password DES encrypted and it works on the Mac Pro.

Those are SHA 256 passwords. We've never used those. Do they work under Snow Leopard?

tom

No, they don't work under Snow Leopard.

Denis