----- Mail message ----- > From: "צביקה הרמתי" <haramaty.zv...@gmail.com> > To: "Paul Robert Marino" <prmari...@gmail.com> > Cc: "Tam Nguyen" <tam8gu...@gmail.com>, "scientific linux users" > <scientific-linux-users@fnal.gov> > Sent: 24. februar 2014 17:33:43 > Subject: Re: Sharing users among few hosts > > Hi. > After reading about (and a little bit experimenting with) NIS, LDAP and > Kerberos, I concluded that: > - Using NIS is really easy - however, it's too insecure > - Using LDAP is too complicated for my 3-4 servers network > > Many criticize NIS as being insecure; I haven't seen such criticism about > LDAP. > However, as Nico Kadel-Garcia pointed out, "Kerberos (is the) Underlying > authentication technology for most LDAP setups".
LDAP can be used for authorization and authentication, or you can couple it with Kerberos so only authorization is done with LDAP. IMHO, either of these approaches are safer than NIS. If letting LDAP do the authentication, it should definitely happen over SSL, otherwise the password passes over the network. However, with both LDAP and Kerberos, it's not possible to read out the passwords (even hashed ones) if the authentication server is well protected and privileges/ACLs are set correct. Hence, lack of criticism on LDAP security. But, with LDAP the password is transferred over the network. With Kerberos, the password never leaves the client, which makes it even safer. It's a many years (late 90s) since I looked at NIS last time, but I believe password hashes are transferred unencrypted over the network when data is needed. > So, if it's a common practice to setup LDAP and then fortify it with > Kerberos; wouldn't it be easier to setup NIS and fortify it with Kerberos? > > Is this combination possible/feasible? > Anyone can point to some reference about how to achieve that combination? If choosing the NIS path, Kerberos is a must. But I doubt you'll find too much information about this combination, as NIS really is considered legacy. You get far better control using LDAP. I see your point with only a few handful servers. But that's now, what about the future? In addition, if you couple LDAP+Kerberos (or use idm, mentioned by others) you can really get an easy client setup using sssd, which caches needed information in case of network failures. Adding additional workstations to an LDAP or LDAP+Kerberos setup is easy. Without that cache, it will be impossible to log into boxes not having local accounts (even from the console) *if* you have network issues. So in that regards, it's more fragile without this cache. And another point ... if you want Kerberos (due to NIS), you anyway need a proper DNS setup and NTP. All this, including LDAP, can be tackled via idm. In addition, with proper DNS setup all clients don't necessarily have to have much complicated configs. It can actually pull much of the information dynamically on-the-fly via DNS lookups (like _ldap._tcp.example.com, _kerberos.example.com, _kerberos._udp.example.com, etc, etc). Which means your client configs can be really minimal and standardised for a very long time, just enabling LDAP or LDAP+Kerberos features, and you have the rest of the configuration centralised instantly. But if you really want the simplest approach, I'd go for LDAP only, maybe in conjunction with DNS SRV pointers. The server setup requires some work (but can in fine run on a secured internal server together with other services). But once the LDAP server is in place, then the client side requires very little efforts. The hardest nut to crack, no matter which setup, is getting Kerberos right and to ensure the needed extra services are running and correctly configured too. (Having that said, Kerberos gives other neat features too, such as SSO, especially if enabled on workstations/laptops) -- kind regards, David Sommerseth