From owner-freebsd-questions@freebsd.org Sat Mar 14 16:40:21 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5C6AB25E3F1 for ; Sat, 14 Mar 2020 16:40:21 +0000 (UTC) (envelope-from freebsd@theory14.net) Received: from bacon.theory14.net (bacon.theory14.net [45.55.200.27]) by mx1.freebsd.org (Postfix) with ESMTP id 48fpFv3x5yz4dSv for ; Sat, 14 Mar 2020 16:40:19 +0000 (UTC) (envelope-from freebsd@theory14.net) Received: from remote.theory14.net (remote.theory14.net [72.66.31.190]) by bacon.theory14.net (Postfix) with ESMTPSA id 7FCF9125ED0; Sat, 14 Mar 2020 12:40:13 -0400 (EDT) Received: from grackle.int.theory14.net (grackle.int.theory14.net [192.168.10.52]) by remote.theory14.net (Postfix) with ESMTPS id 580EB67D0; Sat, 14 Mar 2020 12:40:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=theory14.net; s=mail; t=1584204013; bh=ujSroHuWbfd4ddwSEnBia/nFChhLng64JNCjCz/lx60=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=qgrDJUJLW1YRzzodADiWMsscA1KMTMiUSkNnFoIWeqXHGN8hMgdEu6ce/zNmvshf4 sbPkV5EcAouL1VxHoWRGSuKV0KfGV+aqpM9JPNB7Iapnz6t2lLQ/Uc5BAEyRo4vwdN DmKj2dF0pUIGt5Ce+bpaJhptsWE8I2JfchhYrNVU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: Centralized user/group/whatever management From: Chris Gordon In-Reply-To: <20200314055541.GF27346@admin.sibptus.ru> Date: Sat, 14 Mar 2020 12:40:13 -0400 Cc: freebsd-questions@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5B2796E0-14E3-4CD2-AC05-5A83EE2C0300@theory14.net> References: <20200313091923.GA98495@admin.sibptus.ru> <2F4CA1FD-FB90-4B2E-A2C3-9C009A67A5EE@theory14.net> <20200314055541.GF27346@admin.sibptus.ru> To: Victor Sudakov X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Rspamd-Queue-Id: 48fpFv3x5yz4dSv X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=theory14.net header.s=mail header.b=qgrDJUJL; dmarc=pass (policy=none) header.from=theory14.net; spf=pass (mx1.freebsd.org: domain of freebsd@theory14.net designates 45.55.200.27 as permitted sender) smtp.mailfrom=freebsd@theory14.net X-Spamd-Result: default: False [2.80 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[theory14.net:s=mail]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[0.996,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[theory14.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[theory14.net,none]; NEURAL_SPAM_LONG(0.95)[0.947,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(1.26)[ipnet: 45.55.192.0/18(4.90), asn: 14061(1.43), country: US(-0.05)]; ASN(0.00)[asn:14061, ipnet:45.55.192.0/18, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[190.31.66.72.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 16:40:21 -0000 >> 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