Network authentication using NIS fails

We've confirmed that the following changes work for us:

- nis server must provide a shadow.byname map for shadow passwords.

- nis user account passwords must be des encrypted.

I imagine there must be a way to configure pam on macos lion to support md5 or other encryption.

Oddly, ssh login as any user other than root is failing...not sure why yet. /var/log/secure.log reports:

Sep 21 13:06:37 x sshd[2770]: error: PAM: permission denied for x from x via x

Our NIS server does not provide a shadow.byname map for shadow passwords. As I mentioned before, encrypted passwords are merged into our passwd map. This works fine for us.

The root account is a local account and should never rely on NIS for password. How would you log on as root on a system that has no network access or that is booted in single-user mode? The admin account on MacOS does not have all the privileges that the root account has.

My mistake, I've tested again and find that shadow.byname is _not_ required.

However, I'm glad to know that it does in fact work to have nis shadow passwords with a macos lion nis client since shadow passwords preferable. The only reason we still support nis non-shadowed passwords on any of our nis servers is for older nis clients that can't/don't/won't use nis shadow passwords. This used to be the case with older macos nis clients.

I've been working with nis (yp) since the days of sunos 4 (circa 1990), so I'm well aware that root uses a local file password, not an nis password. But thanks for feedback! 🙂

Now, if someone can just tell us how to configure a macos lion nis client to allow md5 or newer encryption, that'd

be swell.

Look at the man page for "pwpolicy". It may help.

Maybe you can try something like:

pwpolicy -setglobalhashtypes MD5 on

To remove MD5:

pwpolicy -setglobalhashtypes MD5 off

To see the current global hashtypes:

pwpolicy -getglobalhashtypes

Yeah, maybe. I had already looked at that earlier today, but I'm reluctant to start mucking with that without

some more documentation and a bit more certainty than "maybe". 🙂

Confirmed... no change under 10.7.2.

We're also reasonably confident that the issue boils down to the NIS password encryption/hashing. Looks like Lion currently only supports DES (or rather, does not support MD5). We created a test Ubuntu 11.10 server running NIS using DES encryption, and were able to authenticate to Lion.

This is something of a pain since our current user passwords are all MD5 encrypted and I'm guessing that the only way forward would be to switch our NIS servers to DES and have all our users re-do their passwords. Which is definitely something we'd rather not do unless absolutely have to.

So partial progress, but all in all Lion is not worth the upgrade from Snow Leopard...

Now since apply 10.7.2, I all the sudden cannot resolve addresses from NIS. ypcat hosts seems to return the right result, and NIS/mydomainname is listed in odutil.

Anyone else experiencing this problem?

Yes. A quick check shows that hosts we have in NIS but not DNS are not being resolved on our sole 10.7.2 system.

I've seen this sort of thing now and then on my own Snow Leopard system, but in that case a reboot clears it. I've never been able to figure out exactly what causes his problem on SL. But this Lion issue sounds worse than that.

tom

So, I see that this (NIS authentication failing for Lion clients) issue persists.

My NIS server is running Solaris, which supports several password encryption schemes: DES, MD5, Blowfish, Sun's MD5 variant, SHA-256, and SHA-512 (my users are currently using MD5 but I'd like to migrate to SHA-512 one day). I performed an experiment this morning in which I tried to authenticate from a Lion (10.7.2) client, using each of these encryption methods on the server. With the exception of DES, they ALL failed.

As security professionals know, DES is easily broken these days, so using it on my network isn't going to happen. Until Apple fixes this major security regression, I will not use Lion. How this wasn't spotted in QA testing is beyond me...

I have updated my support call with Apple with the above info, so hopefully Apple's engineers will be able to solve this once and for all RSN.

We can get a successful authentication but only with 'crypt' password hashes.

Do you have your YP servers listed in the NIS plugin, or do you rely on auto discovery? We found that we had to explicitly list the YP servers in the NIS plugin whereas in 10.6 discovery worked fine.

Yep, my NIS server is listed in the plugin.

What makes this even more ironic is that Lion uses SHA-512 for local users. If Apple had broken MD5 NIS passwords such that one could use only SHA-512, I wouldn't be so distraught.

I can't express enough how surprised I am that this SNAFU got past Apple's QA and regression testing (they DO perform regression testing, don't they?!), nor how disappointed I am that a fix is taking so long to surface.

Perhaps if they spent less time changing UNIX stuff behind the scenes and more time on testing, this sort of thing wouldn't happen. (I mean, really: is there a reason to not use /etc/shadow to store local users' passwords?!)

So at this point has anyone heard as to whether or not Apple has committed to addressing this issue?

Also, I don't know why - and perhaps it is something I am doing wrong - but at this point it looks like LDAP authentication does not quite happen either. I've got a FreeIPA server running and it doesn't look like my Mac OS X Lion machine is in any hurry authenticating to it. Anybody know what the status is on that?

Thanks.

Boris.

I can now authenticate against a NIS user account with an MD5 password hash after updating to the latest developer build of 10.7.3. Looking Hopeful!

Matt