Hi,
In the past I've setup simple centralized authentication with NIS and NFS, without bothering about possible security implications.
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.
RHEL/CentOS 7 still provide NIS, and I vaguely wonder how exactly it is insecure. So I thought I'd simply ask on this list.
I know there's FreeIPA available. I gave it a spin some time ago on a local machine, but I think it's a bit overkill.
Anyone here who uses central authentication (CentOS server + CentOS clients) ? Any suggestions ?
Cheers,
Niki
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.
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_move...
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.
Le 26/03/2018 à 10:28, isdtor a écrit :
There's also the option of using AD if such infrastructure exists.
There are no Windows clients in the network, only CentOS 7.
Le 26/03/2018 à 10:28, isdtor a écrit :
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.
I gave FreeIPA a spin a while back. I installed it on a sandbox server, and from what I recall, it pulled in a tsunami of dependencies, and first thing it wanted to replace my Dnsmasq with BIND... so I didn't look much further.
Am 26.03.2018 um 11:59 schrieb Nicolas Kovacs info@microlinux.fr:
Le 26/03/2018 à 10:28, isdtor a écrit :
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.
I gave FreeIPA a spin a while back. I installed it on a sandbox server, and from what I recall, it pulled in a tsunami of dependencies, and first thing it wanted to replace my Dnsmasq with BIND... so I didn't look much further.
Quite time ago we had a stripped setup here working only with Openldap and PAM modules. LDAP with replication for redundancy, centralized communication with local CA and over TLS. It worked very well. The successor of such setup is SSSD for EL7 but the above should be still a feasible solution.
-- LF
I also looked into FreeIPA and the complexity is significant, at the time FreeIPA's DNS integration seemed to rely on a Fedora patch and I wasn't willing to introduce that into a production environment. Does anyone know if this has changed? Also, concerning alternatives, does anyone have experience with Shibboleth or OmniAuth?
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Leon Fauster Sent: Monday, March 26, 2018 6:41 AM To: CentOS mailing list centos@centos.org Subject: [EXTERNAL] Re: [CentOS] How insecure is NIS ? Possible alternatives ?
Am 26.03.2018 um 11:59 schrieb Nicolas Kovacs info@microlinux.fr:
Le 26/03/2018 à 10:28, isdtor a écrit :
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.
I gave FreeIPA a spin a while back. I installed it on a sandbox server, and from what I recall, it pulled in a tsunami of dependencies, and first thing it wanted to replace my Dnsmasq with BIND... so I didn't look much further.
Quite time ago we had a stripped setup here working only with Openldap and PAM modules. LDAP with replication for redundancy, centralized communication with local CA and over TLS. It worked very well. The successor of such setup is SSSD for EL7 but the above should be still a feasible solution.
-- LF
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 2018-03-26, Leon Fauster leonfauster@googlemail.com wrote:
Quite time ago we had a stripped setup here working only with Openldap and PAM modules. LDAP with replication for redundancy, centralized communication with local CA and over TLS. It worked very well. The successor of such setup is SSSD for EL7 but the above should be still a feasible solution.
Likely an even longer time ago, I did an even more stripped down version of this, where I just set up an OpenLDAP server, used their tools to import from our existing NIS to it, and ran it unencrypted (all the hosts were either on the same switch or over VPN so having no encryption on the network channel was less of a concern). It was fairly straightforward, and I imagine that nowadays, setting up TLS for slapd and clients is probably fairly straightforward too.
I wonder how much support there is for NIS any more in recent distros. Is it possible CentOS 7 doesn't support NIS, or does but is buggy?
--keith
Le 29/03/2018 à 06:44, Keith Keller a écrit :
I wonder how much support there is for NIS any more in recent distros. Is it possible CentOS 7 doesn't support NIS, or does but is buggy?
I'm planning to test this very soon, probably during the next week, and I'll report back.
Cheers from another ex-Slackware user who migrated to CentOS. :o)
Niki
Am 2018-03-29 09:38, schrieb Nicolas Kovacs:
Le 29/03/2018 à 06:44, Keith Keller a écrit :
I wonder how much support there is for NIS any more in recent distros. Is it possible CentOS 7 doesn't support NIS, or does but is buggy?
I'm planning to test this very soon, probably during the next week, and I'll report back.
Cheers from another ex-Slackware user who migrated to CentOS. :o)
Niki
According to this:
https://access.redhat.com/solutions/7247
it's still possibly.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi!
Am 29.03.2018 um 09:38 schrieb Nicolas Kovacs:
Le 29/03/2018 à 06:44, Keith Keller a écrit :
I wonder how much support there is for NIS any more in recent distros. Is it possible CentOS 7 doesn't support NIS, or does but is buggy?
I'm planning to test this very soon, probably during the next week, and I'll report back.
We are using the OpenLDAP + pam_ldap / sssd solution in several smaller networks (up to ~40 Linux clients), but I think it should scale well for larger networks, too.
The OpenLDAP solution can also support Samba as domain controller, if you have to support windows clients, too.
- From that point on we usually integrate other services like an IMAP server (we use Cyrus IMAP), groupware server (we use SOGo) and many other services which suport LDAP authentication. You can apply LDAP password policies, too.
We use GOSa (or it's successor FusionDirectory, see https://www.fusiondirectory.org/) as web frontend, so the users can change their passwords, mail settings etc. on their own (if they are given the rights to do so)
With all that you get a nice, easy to manage, well integrated and secure network with a central authentication service all with open source software!
It should run with almost all modern linux distributions, even mixed together in the same network.
HTH
- - andreas
- -- Andreas Haumer | mailto:andreas@xss.co.at *x Software + Systeme | http://www.xss.co.at/ Karmarschgasse 51/2/20 | Tel: +43-1-6060114-0 A-1100 Vienna, Austria | Fax: +43-1-6060114-71
Le 29/03/2018 à 06:44, Keith Keller a écrit :
I wonder how much support there is for NIS any more in recent distros. Is it possible CentOS 7 doesn't support NIS, or does but is buggy?
I fiddled around with it for a few days, and I can say that NIS is still perfectly supported under CentOS 7.
https://blog.microlinux.fr/serveur-nis-centos/
https://blog.microlinux.fr/client-nis-centos/
Cheers,
Niki
On 03/26/2018 02:59 AM, Nicolas Kovacs wrote:
I gave FreeIPA a spin a while back. I installed it on a sandbox server, and from what I recall, it pulled in a tsunami of dependencies, and first thing it wanted to replace my Dnsmasq with BIND... so I didn't look much further.
FreeIPA should be installed on its own server or VM, in which case its dependencies and what it replaces shouldn't be a cause for concern. You can still run dnsmasq on a different host. Use FreeIPA's DNS for the internal, private domain only.
FreeIPA takes all of one command to install, and one to set up. It provides a web UI for both administrative and end-user management of users, passwords, login and sudo policy, etc. Anything you find overly complex can simply be unused.
On 26/03/2018 15:14, Gordon Messmer wrote:
FreeIPA takes all of one command to install, and one to set up. It provides a web UI for both administrative and end-user management of users, passwords, login and sudo policy, etc. Anything you find overly complex can simply be unused.
FreeIPA is easy to set up, but it is quite a complex beast under the hood. I've had some nasty debugging sessions with it before when things like Kerberos trust relationships failed.
Am 26.03.2018 um 16:31 schrieb Tom Grace lists-in@deathbycomputers.co.uk:
On 26/03/2018 15:14, Gordon Messmer wrote:
FreeIPA takes all of one command to install, and one to set up. It provides a web UI for both administrative and end-user management of users, passwords, login and sudo policy, etc. Anything you find overly complex can simply be unused.
FreeIPA is easy to set up, but it is quite a complex beast under the hood. I've had some nasty debugging sessions with it before when things like Kerberos trust relationships failed.
Time synchronization for all nodes is crucial for kerberos ...
-- LF
On 26/03/2018 16:18, Leon Fauster wrote:
Time synchronization for all nodes is crucial for kerberos ...
In my case, somehow Bind lost the required kerberos tokens to be able to talk to the LDAP server on the same host, so DNS didn't work, so it couldn't attempt to refresh the token. Never worked out what the root cause was, but I do remember it being quite fun to get it working again...
On Mon, Mar 26, 2018 at 9:07 PM, Nicolas Kovacs info@microlinux.fr wrote:
Hi,
In the past I've setup simple centralized authentication with NIS and NFS, without bothering about possible security implications.
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.
RHEL/CentOS 7 still provide NIS, and I vaguely wonder how exactly it is insecure. So I thought I'd simply ask on this list.
I know there's FreeIPA available. I gave it a spin some time ago on a local machine, but I think it's a bit overkill.
Hi, as you why it is insecure the biggest reason is that it is trivial for a user to get sensitive information about other users. Particularly things like password hashes, and with the compute power available today cracking a hash is not impractical. It also discourages some of the more standard practices today like user private groups.
It would still take a fair amount of work but if you want something a little less than FreeIPA or integrating with AD look into http://directory.fedoraproject.org/
Anyone here who uses central authentication (CentOS server + CentOS clients) ? Any suggestions ?
Cheers,
Niki
Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Am 2018-03-26 10:46, schrieb Clint Dilks:
Hi, as you why it is insecure the biggest reason is that it is trivial for a user to get sensitive information about other users. Particularly things like password hashes, and with the compute power available today cracking a hash is not impractical.
You don't even need to crack them yourself. If you have the hashes, you can just use rainbow-tables available online, sometimes for a small fee.
Still relying on NIS is barely different from not having a password at all and just using a login. In both cases, you have to trust your users - it's no different.
-
Andreas Haumer -
Clint Dilks -
Gordon Messmer -
isdtor -
Keith Keller -
Leon Fauster -
Leroy Tennison -
Nicolas Kovacs -
rainer＠ultra-secure.de -
Tom Grace