Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Mar 2020 12:40:13 -0400
From:      Chris Gordon <>
To:        Victor Sudakov <>
Subject:   Re: Centralized user/group/whatever management
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <>

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
> There is one missing link which was never mentioned in the thread.
> What's the bridge between nsswitch framework (or some other =
> 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 =
> build-in Heimdal a lot for SSH access, SVN access (duh!) and some =
> things.


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.
> I did not quite understand how you can use SSH keys to create/delete =
> 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:  = =
 =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
> 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 =
> 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 =

>> 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 =
> stories rather than in "you can implement this or that thing I've read
> about."
> 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. =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.


Want to link to this message? Use this URL: <>