Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?5B2796E0-14E3-4CD2-AC05-5A83EE2C0300>