Re: How insecure is NIS ? Possible alternatives ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Am 2018-03-26 10:28, schrieb isdtor:
Over the next month I have to setup a new network in a local school, and
I wonder if I should use NIS/NFS. I still have my own documentation,
it's simple and somewhat bone-headed to setup, and it just works.

In my opionion, there is a serious gap in this area. It's either NIS,
simple, easy to setup yet insecure, or LDAP/FreeIPA/RH Id management
server at a complexity at least one order of magnitude beyond NIS.

There's also the option of using AD if such infrastructure exists. RH
ID management has been completely dismissed by colleagues who know
both it and AD, and favour the latter.



The issue is that the problem itself isn't simple to begin with.

And so, the solutions have become quite complicated. Windows makes it all work quite nicely, apparently - but it works best with Windows.

I recently came across this article:

https://fy.blackhats.net.au/blog/html/2017/05/23/kerberos_why_the_world_moved_on.html


In W10/Server 2016, MSFT has added even more security to Kerberos to address the issues glanced at the above article.
Don't have a link for those, it was an article on paper.

Not sure if RedHat is ever going to implement those.


I've got the same problem. We should unify authentication to our servers. The problem is that we, being an MSP, operate what I call a very "balkanized" environment. For security-concerns, it was traditionally frowned upon to have a single authentication service. So each customer is on its own network and users are local.

I'm still looking into RedHat IPA - specifically for its ssh-key management and sudoers-file management capabilities - but I'm also considering running an internal CA and using certificates to authenticate (I'll have to read-up on this). This is AFAIK the way people like Facebook or Netflix run their shops.

Usually, if you're not Google, Amazon, Facebook or Netflix, it's also not a good idea to try to copy their "patterns" - but this might be an exception.

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]


  Powered by Linux