[TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor]

On 11/06/2018 03:29 PM, Dan Cross wrote:
> It wouldn't do it, but I guess it depends on how much you trust your 
> environment and your users etc.

That's not quite what I had expected, but it is an answer to the 
question that I asked.

> If you're intent on using a network directory service, I'd bite the 
> bullet and invest in setting up Kerberos and LDAP. The thing with pairing 
> Kerberos (for authentication) with NIS is that while you'll have decent 
> authentication security, nothing prevents a malicious third party from 
> modifying the answer from `ypserv` for some user to set the UID to 0, 
> thus making that user root.

ACK

> If authentication is happening by users typing passwords into SSH clients, 
> which then get sent to SSH servers to be validated against the KDC on 
> machines that have been so cracked, an attacker can steal passwords by 
> subverting the SSH server processes.

What would the user be typing their password into?  The SSH client to 
authenticate to the SSH daemon?  Or kinit (et al) on the remote system?

I would have thought that the ideal situation would be for the user to 
kinit on their client, then authenticate to ssh using Kerberos.

I'm guessing they would need to do something to extend their Kerberos 
tickets therefrom.  I don't know if they would need to kinit on the 
remote system, or if there's something like agent forwarding for Kerberos.

> However, if you trust your users not to do that and you're on a 
> relatively small, self-contained and decently secured network, then it 
> may be fine.

ACK

> From what you described earlier I think generating text files and 
> distributing them around (possibly with rdist or rsync) and pairing that 
> with kerberos would be less work and more robust.

Possibly.

Though I don't consider that to be a central directory server.  Instead 
I consider it to be replicating information locally.  I'm sure it has 
it's pros and cons.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181106/64fa7fea/attachment.bin>