On Wednesday, August 14, 2019 at 5:35:13 AM UTC-5, LinuxDan wrote: > > On August 14, 2019 at 5:15 AM, Martin Alfke <tux...@gmail.com > <javascript:>> wrote: > > Hi Dan, > > On 14. Aug 2019, at 04:12, 'Dan White' via Puppet Users < > puppet...@googlegroups.com <javascript:>> wrote: > > > On Aug 13, 2019, at 9:30 PM, Garrett Honeycutt <g...@garretthoneycutt.com > <javascript:>> wrote: > > > On 8/13/19 6:10 PM, 'Dan White' via Puppet Users wrote: > > On Aug 13, 2019, at 9:04 PM, 'Dan White' via Puppet Users > > <puppet...@googlegroups.com <javascript:> <mailto: > puppet...@googlegroups.com <javascript:>>> > > wrote: > > > Is there any current documentation about how to create user resources > > with an ldap provider ? > > > Let me be a bit more specific on this question. I am looking for the > > setup details to allow Puppet to get the user information from ldap. I > > am guessing this is a “read-only” thing and that the user must exist in > > ldap before Puppet can use it. > > > Hi Dan, > > > Surprised by this idea and curious about your use case. Puppet is better > > for modeling resources on a system as opposed to data in an external > > database, which is what users are in LDAP. Normally you would use Puppet > > to manage local users as well as the setup necessary for nsswitch, > > sssd/nscd and pam so the system can resolve users and groups from LDAP. > > > Best regards, > > -g > > > -- > > Garrett Honeycutt > > Tailored Automation > > https://tailoredautomation.io > > > Hi, Garret > > > The use case is simple. > > Centralized credentials in LDAP. > > Minimal local accounts other than system and service users and a non-root > admin login with sudo permissions as an emergency back door. > > > We also have lots of appliances, applications, and network devices that > can use LDAP or RADIUS for authentication. I found multiple references for > a FreeRADIUS service with the credentials in LDAP. > > > I see the PE documentation about connecting to an external directory > service, but it looks like that is only for PE console users and not for > Puppet managed node user accounts. > > > Yes. PE external directory refers to PE console logins only. > > > If I set up the system as you describe with sssd/nsswitch/pam for users > defined in LDAP, can I then just create appropriate user resources with > “provider => ldap” and expect the login to be created on the node server ? > Or is it like with FreeIPA where you just log in with the LDAP credentials > and your home directory is created the first time ? > > > You can use the provider ldap to manage users in ldap: > https://puppet.com/docs/puppet/6.6/types/user.html#user-provider-ldap > > "This provider requires that you have valid values for all of the > LDAP-related settings in puppet.conf, including ldapbase. You will almost > definitely need settings for ldapuser and ldappassword in order for your > clients to write to LDAP." > > I would try to use that config on a single system with write access to > your ldap master. > > Any other system should just be configured to make use of pam_ldap/sssd > using a module from puppet forge: > e.g. https://forge.puppet.com/sgnl05/sssd > > hth, > Martin > > > ?? Write to LDAP ?? What would it be writing ? Like I said above: > > I am guessing this is a “read-only” thing and that the user must exist in > ldap before Puppet can use it. > >
Why would you *not* want to write to the data store backing your User resources? If you cannot write, then you cannot manage resources -- neither create new ones nor modify existing ones nor remove unwanted ones. These things are what User resources are for. Without being able to write, the most you could do is use dependencies on User resources to cause other resources not to be applied in the event that a User configuration does not match your expectation. If you simply want to configure systems to authenticate users against an LDAP directory and draw their information from there, then User resources are the wrong approach. For Linux, at least, you may want to look into configuring systems for LDAP itself, or for SSSD. You will probably want to manage nsswitch.conf, too. There are available modules for all these things. If you're looking to manage system-level access control, too, then you probably still want to come from that direction. In my own house, for example, I authenticate Linux users against institutional Active Directory with use of SSSD (the managed machines are domain-joined). I manage which users are permitted to log in to which machines through SSSD configuration, not User resources. That approach can work for other data sources, too -- in particular, SSSD supposedly can work (directly) with LDAP directories, though I've never configured it that way. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/39a270c5-958d-40d6-a469-183a429e3c65%40googlegroups.com.
