5 Nov
2018
5 Nov
'18
1:24 p.m.
On Mon, Nov 5, 2018 at 9:19 AM Grant Taylor via TUHS
<tuhs(a)minnie.tuhs.org> wrote:
I would say that expecting to just pull password hashes from the
directory service – using it as nothing more than networked
/etc/shadow – is a bad approach to begin with. Let the client handle
authentication via Kerberos (or via whatever else is apropriate for
AD).
Could you elaborate on that?
Standard TLS.
--
Mantas Mikulėnas
On 11/04/2018 08:16 PM, Robert Brockway wrote:
There was `ypcat passwd`, wasn't there?
I used NIS a lot in the 90s and early 2000s. I
think it continues to be
underrated. The main gripe people had was lack of security but if all
of the hosts were in the same security domain anyway it wouldn't matter.
I'd like to hear more about the security issues.
Did NIS(+) ever encrypt it's communications? (I'm not counting things
like IPsec transport.)
I'm fairly certain that it was possible to enumerate the directory or
otherwise scrape most (if not all) of it's contents. I did a lot of
LDAP around 2007-2010. I got quite good at writing
filters as we were using for a lot more than juse user auth.
Ya. The LDAP filters are why I tried to avoid just using LDAP against
AD. That and the fact that the Unix passwords were actually a separate
field that could have different values from what the Windows systems used. Most
installations I'm seeing today auth to AD, which is of course now
supported.
I'm curious what "supported" actually means. I think there is
preconfigured LDAP against AD templates, and things like Samba+Winbind.
But all seem to be less native / seamless than NIS. In my
experience LDAP is preferred in a pure *nix environment these
days. I've never played much with Kerberos.
Does that mean that the authentication is also done across LDAP? I hope
that it's encrypted LDAP.