Centralized user/group/whatever management
freebsd at theory14.net
Sat Mar 14 16:40:21 UTC 2020
>> 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
> 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?
> 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
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
> 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/. From 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.
> 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.
> 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.
> 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
> If any person who replied in this thread is using a centralized user
> database, please share what *you* *particularly* use and why.
> 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.
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.
I hope that helps some.
More information about the freebsd-questions