NIS Or Not?

Home » CentOS » NIS Or Not?
CentOS 40 Comments

Hi all,

We’re getting to a point in our linux environment where it’s starting to be cumbersome to keep shadow and passwd-files up-to-date for the users to login on each computer. Scripts can only get us so far. 8-/

I’ve looked a bit into central login systems for linux, and NIS and LDAP seem to be prevalent. NIS being the simpler-to-setup solution for small to medium networks as I understand it, while LDAP is the more modern and scalable solution. See eg http://www.yolinux.com/TUTORIALS/NIS.html or http://sysadmin-notepad.blogspot.se/2013/06/nis-server-setup-on-rhelCentOS.html.

NIS-wise, what is a “small to medium network“?
We have currently about 20-30’ish linux clients and servers, and the environment is not likely to increase much beyond this point. Is a 30ish-computer setup, a small network?

The only thing I’m trying to accomplish is a system which will allow me to keep user accounts and passwords in one place, with one place only to administrate. NIS seems to be able to do that.

Comments and insights are much appreciated!

40 thoughts on - NIS Or Not?

  • Hi Sorin we use here LDAP authentication and mail-control since more than 10 years. At that time, we did the conversion from passwd/shadow to LDAP using the tools on http://www.padl.com/download/
    which are still available, probably in a newer version…

    To represent a person or a service in LDAP we use the objectclasses:
    objectClass: account
    objectClass: posixAccount
    objectClass: top
    objectClass: shadowAccount
    objectClass: mailRecipient

    To represent a mail user for postfix we use the objectlcasses:

    objectClass: top
    objectClass: person
    objectClass: organizationalPerson
    objectClass: inetOrgPerson
    objectClass: qmailUser

    To represent a Domain which we serve mail-wise we use the objectclasses:
    objectClass: qmailControl objectClass: top

    We also have developed an LDAP via Web Interface, which we use exclusively for LDAP administration.

    We have two LDAP servers, syncronized via syncrepl.

    suomi

  • 2014-01-28 Sorin Srbu

    Use IPA. It combines LDAP with Kerberos, a server-client environment is easily setup and the documentation (RHEL deployment) is very helpful.

  • Thank you. Can I use just the user authentication (uid/pwd) part and skip the whole mail-cocacho, or do these two go hand in hand when using LDAP?

  • Hi Sorin of course: you may omit the mail cocacho and realize only the authentication cocacho in LDAP. For us, however, it has proven to be most advantageous to have both on LDAP. You may also select to do first the authentication in LDAP and later on, if you are familiar with LDAP, realize the mail.

    suomi

  • I used NIS for many years while working on Sun Solaris and it worked extremely well, although when it breaks it can be a real challenge to figure out the problems. I don’t know how well it’s implemented in Linux, bound to be a bit different than Solaris. In either case if it’s important be aware of the potential security issues related to NIS, mainly the clear text passing of the password which is what pretty much doomed it.

    Depending on how ansi your users get I would recommend a slave server as well, you might also consider using autofs to mount the user’s homes.

    The biggest potential problem that you might run into when you first implement NIS is to take a look at the uid of all the users on each host, you will need to ensure that they are the same before you start NIS or else it will be a mess for the users because they won’t own their own files.

    With all of that said I do think though that LDAP would be a better solution although I’ve not used LDAP.

    Good luck with it either way.

    Pete

  • Yeah, that last bit made me squirm over here. I don’t feel good about that, even though the linux machines are all pretty much localized to one spot, so that hardly any traffic goes out of the department.

    Thanks. I’ll look into LDAP some more.

    //Sorin

  • We have been using NIS for over a decade on our network, and it has been an effective solution. The network spans several subnets, and we have been able to deploy slave NIS servers on the various subnets. The reason for this is several fold:

    Quicker response for login and other domain requests Network policy requires slave servers to be on subnets to reduce network traffic.

    While the security is not as strong as it is for the LDAP solution, as long as you are employing NIS on an internal network, you should be all set.

    —–Original Message—

  • Where I work we use NIS + Kerberos (Active Directory). We have about 150
    machines at our site. It works quite well, as someone said, the big draw back to NIS is that it sends passwords insecurely, but if you use Kerberos for authentication it’s really quite easy to manage.

  • Security is a major consideration, and even though as you say most of the traffic is local, most problems are internal as opposed to external.

    Pete

  • We do have Active Directory as well, but only for the Windows clients.

    But I’d rather keep them separated.

    Kerberos on linux. Is that a pain or a bigger pain?
    Whenever I’ve worked with Kerberos on Windows I’ve come out all sweaty afterwards… 8-S

  • Then stop playing with yourself already! ;)

    Kerberos on linux works quite well; keep everyone’s clock within
    5min of the auth server and you will be ok. I have not done sssd yet though. I did have timeout with nfs automount issues due to expired tickets, but that setup is old.

  • A related question: is NIS or LDAP (or something else entirely) better if the machines are not uniform in their login configuration?

    That is, we have an ever-growing list of special cases. UserA can login to servers 1, 2 and 3. UserB can log in to servers 3, 4, and 5. Nobody except UserC can login to server 6. UserD can login to machines 2–6. And so on and so forth.

    I currently have a custom script with a substantial configuration file for checking that the actual machines are configured as per our intent. It would be nice if there was a single tool where the configuration and management/auditing could be rolled into one.

    Thanks!
    Matt

  • 2014-01-28 Laurent Wandrebeck

    Indeed, and IPA does this quite well.

    We use IPA on all servers and workstations.

    – Sudo information comes from IPA

    – Autofs information comes from IPA

    – Host based access control comes from IPA

    – Central user management/identity

    It all works really good.

  • 2014-01-28 Mauricio Tavares

    I can’t say how well it does compared to openLDAP but the replication is quick reliable.

    For example; we test IPA masters by (re)applying settings in user accounts etc. while “crashing” them at random (removing power; they were virtual machines)

  • Laurent Wandrebeck wrote:

    At this late date, I’d be really, *REALLY* leery of using NIS. You say that *most* of your traffic is local, suggesting that some of it is *not*. And, for that matter, how good are the firewalls keeping other traffic out?

    I’d say no to NIS. Yes, other answers may be more difficult to set up, but consider the alternatives.

    Here you may not realize you’re distinguishing between authentication and authorization.

    We have an in-house written set of scripts that administer relevant configuration files, including /etc/passwd. It copies the correct version of that file (among many others) to each host, and shell of /bin/noLogin works just fine.

    I’d vaguely heard of IPA, so I just looked it up. *chuckle* You do notice that it has its own implementation of LDAP and uses kerboros, right? So seems like several folks are recommending LDAP and kerboros.

    I sincerely hope it’s easier to set up and administer and upgrade than native LDAP. In ’06, after a discussion with the other admin and manager I
    was working with at that job, I volunteered to set up openLDAP. Let’s just say that the tools were NOT vaguely ready for prime time, though I did find that running webmin helped a *lot* to get it working.

    But that was nearly 8 years ago….

    mark

  • Sorin Srbu wrote:
    Remember, kerboros came from the Unix world, so you’d expect it to work well in Linux. M$ added it in much later….

    mark

  • Yeah, I forgot to mention that we already have Kerberos in place for authentication. It’s authorization that is currently done by hand and checked with a manual script. (I needed that for the secure mount options NFSv4 provides.)

    I know you can find a horror story for any piece of software on the Internet, but my impression is that LDAP has an unusually high number of scary-sounding anecdotes. I know random Internet blogs forum posts aren’t really authoritative, but they do give me a little trepidation regarding LDAP.

    Why set the shell to /bin/noLogin, rather than simply not create that user’s /etc/passwd entry?

    I don’t have /bin/noLogin on any of my systems – I assume you deliberately specified a non-existent program for the shell? What’s the difference between setting the user’s shell to a bogus program versus something like /bin/false?

  • Matt Garman wrote:

    /bin/noLogin

    There’s one master passwd file, and the scripts that centrally manage it set the shell, one way or another, depending on a different configuration file. Why noLogin? I know I’ve seen it elsewhere; I think I’ve also seen it as /bin/false. That’s a call above my pay grade….

    mark

  • What is it that your scripts tweak? I have a small setup using kerberos against an AD for authentication, but the linux servers have their own passwd files for the small subset of users there. /home is shared from one server to all of the others in the set. This worked when initially set up with matching users (w/matching uids) but when I
    added new ones, nfsv4 mapped them to ‘nobody’ until I rebooted the clients. Restarting nfs and/or idmapd didn’t help. Is there some way to make added users work?

  • Hi friend –

    what is your end goal with this effort to obtain security with your nodes over the ‘wire’ –

    there are some other solutions — kerberos is now used heavily by microsoft so that’s enough to make me run for the hills… just saying..

    i’ve set up other solutions to be sure — even against the blasted (not a real LDAP) AD.

    anyway.. just some thoughts… it’s not trivial. any of the solutions, btw. not at all..

    j/h San Francisco/Holland/Saudi Arabia

    389882830-$$ (for those that know)

  • I would like to thank you all for your hints, advice and suggestions. I now have quite a few leads to follow up on. Will probably be back later on with more questions if Google can’t help me.

    Thanks again.

  • Primarily to enable less administration in the long run with centralized logins, instead of keeping each single client updated with respect to shadow, passwd, bashrc, hosts and so on.

    Some sort of encryption would probably be wise to use, as NIS uses clear text passwords. I don’t trust our university network that much, even though the traffic should pretty localized.

    I’m aware that setting up Kerberos probably will be a big project, nevertheless, we must do something about the current mess. As I’m the single sysadmin at the department, my time is finite. Automation is good, but as I
    wrote before, regular bash-scripting (however powerful) will only take you so far. 8-/

  • FreeIPA provides an open source Active Directory equivalent. its pretty easy to setup a simple directory server, and it can expand to be an enterprise-wide directory. it allows both linux and windows computers to participate in the authentication domain.

    yes, its basically LDAP and Kerberos, with a management suite.

  • Hello Sorin,

    Good call – not sure how far your coding goes and with what/how languages and scripts… Make sure to have as much as possible on VM’s related to your security
    ‘servers’ — so that you also get a virtual built in Disaster recovery as well.

    KERBEROS is a very secure, albeit cumbersome component to implement (//
    network wide // think of… )

    Having said this, um, with the tools available with openSource.. and I’m assuming you’re such a shop due to running CentOS — you can customize the ticket transport aspect after the encrypted authentication token is created and ‘capture’ that and with some slight tweaks create your own ‘virtual Federated’ auth method by way having total control of your requests, successes, failures and the like.

    Note: I didn’t catch it are you using the Microsoft’s implementation of Kerberos?
    There’s a reason I ask, you said you need to do something,, sounds like fairly quick, probably a good thing, if nothing else get centralization = control! – more so — than before ~
    and so it goes, you will have encapsulated tickets on steroids, to be sure.. but if you’re the only person.. is your shop that big that SSL wouldn’t do the trick?
    with some slight coding and enhancements // customization // – usually not supported by a ‘given vendor’ so beware there…

    You will see performance over the other solutions in this space and some scalability – without know ‘a lot’ about your infrastructure — and appliances therefore entered into the equation –
    it’s hard to really say.

    But sounds like you have Unix/Linux backend and alot of Windows stuff
    (we can’t seem to ever get away from the highly faulty Windows suite) — maybe when I retire, but anyway, and you’re probably hitting a few AD servers

  • My Google Fu is usually okay. ;-)

    We’ve started offing physical servers in favour of virtual ones. So far mostly Windows servers, but I’ve started testing e.g. Owncloud on a virtualized CentOS guest. More Linux-machines are likely to be virtualized in due time. We (well, I actually…) decided on standardizing on Hyper-V as there was a really good P2V-tool available for migrating Windows servers. We had lots of them…

    We do have a Windows AD in place, it’s the main IT here, but it’s soon to be migrated to the central university IT-dept. One less thing to worry about…
    *nix was originally only a group-business at the dept., but over the years the Linux-ratio has upped considerably, what with backup-servers etc. running on Linux as well as us affording more machines for the original CADD-group.

    SSL? How do you mean? Can you elaborate a bit?

  • Hey Sorin,

    I’m getting ready to catch a plane to Dubai but wanted to answer you real quick and short:
    SSL for smaller networks in terms of authentication is fine and secure –
    as long as your infrastructure is secure.

    I’m glad to hear your using VM’s more and more. It give you a lot more control to manipulate, change and recover from ‘all kinds of errors’ – tweaking .conf files, someone having ‘root’ or ‘admin’ on you as you have to trust someone/sometime…

    .. anyway, um, I’m hoping you consider the SSL implementation if you have to do something ‘quick..’
    if not, Kerberos will certainly help you from getting ‘fired ..’ it won’t be the reason you do anyway..

    About the previous post about IPA – you’re hitting LDAP anyway (that is AD) and probably a few more out there if you’re somewhat of ‘shop’ with stuff everywhere……

    IPA was hacked by a user group (exploit) in Seattle – and you get what
    ‘you don’t pay for’ sometimes.

    Having said this, all these tools at the end of the day generally get the job done, the truth is ‘what are you protecting..’
    and from ‘what..’ usually determines the component and/or tool you’d want to entertain.

  • Almost forgot, //Sorin:

    SSL uses public key cryptography:

    1. You (or your browser) has a public/private keypair
    2. The server has a public/private key as well
    3. You generate a symmetric session key
    4. You encrypt with the server’s public key and send this encrypted
    session key to the server.
    5. The server decrypts the encrypted session key with its private key.
    6. You and the server begin communicating using the symmetric session
    key (basically because symmetric keys are faster).

    Kerberos does not use public key cryptography. It uses a trusted 3rd party. Here’s a sketch:

    1. You both (server and client) prove your identity to a trusted 3rd
    party (via a /secret/).
    2. When you want to use the server, you check and see that the server
    is trustworthy. Meanwhile, the server checks to see that you are
    trustworthy. Now, mutually assured of each others’ identity. You can
    communicate with the server.

    I’m always nervous about ‘trusted third parties..’ Can you imagine.. That’s what holds our credit cards and such, like, um, at Target.. the trusted ‘third-party…’ Damn, people really go for that??? See, it’s a hard call, isn’t it??

    // weigh it all out… // and make sure you get buy in and put the DISCLAIMERS in your documentation and on the Wiki’s because it will come back to you at some point ….. if it ever goes down…

    BEWARE of anything related to Security solutions on the Net — because most don’t have more than three or four years experience. Most.

    ~ later.

    j/h

  • Thanks for your insights. Appreciated.

    My boss just looks funny at me when I ask him about security and has he considered all those post-Snowden details. 8-)

    I’ve begun dabbling a bit with SSL while I did the Owncloud-testing and running.

  • –No, the other way around. Microsoft Active Directory sounds a lot like LDAP and Kerberos. Credit where credit is due …

    ;)

    Devin

  • No, the other way around. Microsoft Active Directory implements an LDAP like directory accessible interface for its own directory.

    Calling Active Directory “LDAP” is like calling vim `echo “xx” > yy`. If you are unaware of all the moving parts under Active Directory, it might prove very informative to explore it.

    Credit where credit is due …

    jlc

  • AD *is* a modified/extended LDAP+Kerberos based system, it just adds a ton more proprietary stuff around it to manage Windows workstations, the whole Group Policy Object stuff etc etc. Thats all implemented via LDAP extensions.

  • I’m sorry, with all due respect I disagree. There is an unfathomable quantity of functionality not accessible via LDAP.

    You can query some aspects made available through the LDAP interface, you cannot set nor modify plenty.

  • indeed, as I said, ‘extended/modified’. the GPO stuff has actually nothing to do with the directory service per say, its just dispatched via it, using kerberos tickets for authentication. LDAP itself doesn’t address replication either, and Microsoft made all that about as complicated as they could with their FSMO’s and whatnot. its really simple and easy until something goes south, then you discover there’s layers and layers of kludge under the skin and its amazing it works at all.

  • Pretty much right……..and is not truly X.500 compliant…This AD. It makes me nervous when one refers to it as LDAP…heh. Do a low level trace when running: ldapsearch .. Problem is AD has to be dealt with until Microsoft dies! Becomes Novell. And it will someday….

    Anyway…. The LDAP with CentOS is robust enough when built up as Master Master // rep. rep.

    Lots of thing get missed….

    “Paris in the the Spring”
    Did you catch that extra word there…..too much wrapper…Welcome to AD.

    Wizard of Hass!
    Rarely wrong; usually right….

LEAVE A COMMENT