We're switching authentication from NIS to LDAP. I'm new to Linux so I'm not sure how this is going to affect our group. We're told the process will change the id associated with files but that it should be fairly transparent as our user names will stay the same. New passwords, but other than that, no big effect. LDAP will only be used for authentication, other uses of NIS will remain intact.

A systems team is doing the switch. I'm with an application programming team. I'm not new to programming so I'm not 100% believing the story.

We use NFS mounts extensively (even for our home directories so that it shows up the same regardless of machine logged into) so there is a timing issue there. It will have to be all at once.

I'm guessing sudo to a non-root user will be transparent?

Am I missing anything? There has to be a gotcha hiding somewhere.

It's always * possible* that someone has deployed something in a weird way that will break, but in a well managed environment, it won't make any difference.

the system has no idea where the user names come from. the list of users is built but nss and returned to any application that needs it in a way that says nothing at all about where it came from. Run "getent passwd" and that's your list. Part lcoal file sources, part NIS, part LDAP etc.

Similarly for the authentication (you say it's ONLY authentication but I presume you actually mean user information AND authentication). Again here for auth, PAM will handle the authentication in most instances. An app authenticates to the OS and the OS then takes that request and does whatever it sees fit. The app doesn't need to care.

1 members found this post helpful.

Thanks, Chris. That was informative. I'm new to Linux and didn't know about getent. One area I thought might be a problem was where code would take credentials and try to authenticate, to the database for example. It sounds like the OS will take care of hiding the source. I was thinking the code might need to know NIS vs LDAP. I'm not familiar with that part. Maybe this will be as easy as they suggest?

Dennis

IF they are good at what they do.

The project is large and our group isn't scheduled for the change until a couple of months from now. We'll get to see how the other groups fared and hopefully the gotcha items will have been figured out by the time they get to us. I just wanted to get ahead of the situation.

It's not as easy as it sounds. LDAP is merely a repository of data. There is more client and auth semantics built into NIS by default.

So.. in general, when people say "LDAP handles auth", that that means is that a successful authenticated bind means auth. So... unlike NIS (in general, because again LDAP is a general purpose repo), LDAP doesn't contain your password in either encrypted or hashed form... that happens a function of the service to "bind" to the LDAP server... really has nothing to do with LDAP data.

UID changes are always a pain. So hopefully they'll do their home work on that one.

But the real gotcha is handling NIS client side. Sure, you can disable the use of NIS password by effectively nuking the hashes with invalid base64... and yet still allow "passwd" for identities... but it's possible they are taking out both passwd and group tables altogether... which will limit the things you can do with NIS greatly. If not, if they are smart to just nuke the hashes, you still have a minor sync issue required to make sure the NIS tables are updated with relevant data from LDAP. All is doable of course (again, if they know what they are doing).

It's also possible they might be using some sort of weird "bridge" thing.

I'm rambling a bit, but I cannot over emphasize the potential conundrum on the NIS client side. NIS does it all. LDAP doesn't because semantics are really built in. Now it's possible they have semantics around LDAP data that they are deploying... but it's all custom at that point (though there are some common deployed semantic patterns out there, but many cause more problems because they claim "standards", but don't work with vendor specific LDAP implementations (which forces an all or nothing convert to.. for example... OpenLDAP on all clients).

In short, having done this many times.. it's NOT as simple as some make it sound... Those that claim simplicity usually mean that your going to lose some features.... just saying.

1 members found this post helpful.

Right. We're using a customized LDAP so a local password file is used. That file is updated by the LDAP processes. That lets us keep local systems accounts out of LDAP.

They claim to have handled this well in the past on similar projects.

As above.

Fingers crossed... I fully expect some down time.