Date: Sat, 14 Mar 2020 12:40:13 -0400 From: Chris Gordon <freebsd@theory14.net> To: Victor Sudakov <vas@sibptus.ru> Cc: freebsd-questions@freebsd.org Subject: Re: Centralized user/group/whatever management Message-ID: <5B2796E0-14E3-4CD2-AC05-5A83EE2C0300@theory14.net> In-Reply-To: <20200314055541.GF27346@admin.sibptus.ru> References: <20200313091923.GA98495@admin.sibptus.ru> <2F4CA1FD-FB90-4B2E-A2C3-9C009A67A5EE@theory14.net> <20200314055541.GF27346@admin.sibptus.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
>> LDAP and Kerberos are common solutions for this. There are many ways = you could do this, both or just one of them depending on your specific = needs. You could: >> - Setup servers yourself. For instance setting up OpenLDAP >> - Use some "pre-integrated" solutions: >> - FreeIPA. Underneath, this is just LDAP, Kerberos, DNS, etc. = You don't have to use SSSD to use FreeIPA as an auth source. Not sure = what "features" may or may not be there. >> - Active Directory. Yes, you could use a Windows solution. = It's fundamentally LDAP, Kerberos, DNS, etc. Note that FreeIPA is an = attempt to re-create AD with Open Source components -- if they state = that or not, it's what it is. >> - Samba acting as an AD server >=20 > There is one missing link which was never mentioned in the thread. > What's the bridge between nsswitch framework (or some other = replacement > of getpwent(), getgrent() and friends) to be used with all those LDAP > solutions mentioned above? >=20 > Kerberos is fine of course, when we have a user already. I use = FreeBSD's > build-in Heimdal a lot for SSH access, SVN access (duh!) and some = other > things. = https://www.freebsd.org/doc/en_US.ISO8859-1/articles/ldap-auth/index.html If the above doesn't cover sufficiently for you, a quick search of the = web with your favorite search engine will turn up many different = articles, tutorials and discussions. I just put in "freebsd ldap = client" into Google and found the above. > You could also look at using signed SSH keys. There are some articles >> about some of the hyper scale sites doing this to address the failure >> points and scalability problems you get with a centralized directory >> service. It's on my list to read up on, but I haven't gotten to it >> yet. >=20 > I did not quite understand how you can use SSH keys to create/delete = users > and manage group memberships. Could you elaborate or give a link? Like I said, I haven't read the details of how this works. "signed ssh = keys" in Google gives a link to an article from Facebook engineering on = the subject: = https://engineering.fb.com/security/scalable-and-secure-access-with-ssh/. = =46rom what I recall when I heard about this, a similar solution is = used and discussed by a number of other hyper-scale companies. As I've = not had time to research this myself, I'll leave it as an exercise to = the reader. >> Depending on your scale and needs, you could just keep it really >> simple and use some automation tool like Ansible, Puppet, Salt, Chef, >> etc to add/remove users across all of the machines. =20 >=20 > The closest thing to what I want is ansible's "user" and "group" > modules, I'll certainly consider them if I don't find a solution with = a > truly centralized user database with instantaneous lookups, like a > modern incarnation of NIS. >=20 > The major drawbacks with the "configuration push" approach have been > enumerated in my mail to Daniel Feenberg. Even though ansible can > parallel its jobs, the drawbacks still apply. I agree that there are drawbacks to this approach. That said, there are = drawbacks and compromises to every single approach to this problem. In = some cases this could be the "least evil" of the set of compromises, it = other cases these compromises may be absolutely unacceptable. (See more = below.) >> There are lots of options with varying degrees of work. It really >> depends on your actual requirements and resources (time, etc) to >> implement and operate. >=20 > I was of course interested in modern best practices and personal = success > stories rather than in "you can implement this or that thing I've read > about." >=20 > If any person who replied in this thread is using a centralized user > database, please share what *you* *particularly* use and why. >=20 > I've already shared mine: I use NIS (yp*) but want to migrate from it, > for the reasons I stated in the first mail. There is no single modern best practice. There are many different = options and solutions, the best of which will largely depend on the = details and scale of the problem you are trying to solve. If you could = describe your environment in more detail, people may be able to provide = some more concrete suggestions. The scale and nature of your = environment along with the resources you have to apply to this problem = (and to the entirety of the operation) have significant impact on the = solution. For instance if the environment is a small or home office = with a couple of servers and a handful of clients and lacking regulatory = or audit oversight, the ansible type approach may be most efficient and = appropriate. At the other end of the spectrum is the case of managing = hundreds of thousands or more instances where completely removing logins = to those instances (augmented by full telemetry off the systems of = concern) is a popular and highly desirable approach. In between are = various combinations of things typically built around LDAP and/or = Kerberos. =20 Now maybe I'm overreaching in what you want. If you just want to hear = about specific cases of implementations from those that have them, then = please disregard my entire email. =20 I hope that helps some. Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5B2796E0-14E3-4CD2-AC05-5A83EE2C0300>