----- Mail message -----
> From: "צביקה הרמתי" <[log in to unmask]>
> To: "Paul Robert Marino" <[log in to unmask]>
> Cc: "Tam Nguyen" <[log in to unmask]>, "scientific linux users" <[log in to unmask]>
> 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