On Monday, July 24, 2017 at 5:33:09 PM UTC-4, William Korb wrote: > > Hello fellow Puppeteers and thanks in advance for any assistance you may > be able to offer. > > We have a rather non-standard requirement on our Puppet-managed Linux > systems, and I'm trying to figure out if/how Puppet can satisfy it. > > We use some of our servers to run Oracle database software. If you are > familiar with Oracle DBs and Grid Infrastructure, then you know that if the > user and/or groups are unknown when a server boots that the Oracle stack > will not start properly. As such, even though we use WINBIND to join our > servers to our M$ Active Directory domain, we want to have the oracle user > be local...kind of...so that it's known at boot time even if there is an > issue with the AD/WINBIND connection. > > The solution up to now was to use the same UID as generated by WINBIND to > add an entry to /etc/passwd. However, we don't want the encrypted stored > password to exist on every server, so we instead leave out the entry for > /etc/shadow, and WINBIND is smart enough to authenticate the user to AD for > us (and at boot time, the local presence of the oracle entry in /etc/passwd > is sufficient to allow the oracle stack to start properly). > > With that in mind, is there any way to get an "oracle" entry added to > /etc/passwd, create HOME directory and profiles, etc. without also ending > up with an /etc/shadow entry? >
With winbind / krb5 authentication, you don't need any password set on the account-- just leave the password field in /etc/shadow as "!". In short-- create the account without a password. In our enterprise, due to the rather large size of our AD domain (more than 100k groups), we gave up on winbind-- we use puppet to create 'local' accounts that are all handled via PAM to authenticate against the AD realm via kerberos. We pull the SID from AD via ldap to calculate the RID, so we have persistent UID's across servers, and puppet adds/removes users based on AD group membership. It's a bit complicated (huge understatement!), but the end result is that we have accounts in /etc/passwd and /etc/shadow, but they have no passwords, and can only authenticate via krb5 (ie, AD). In the case of oracle (we have a few as well), we create the grid and oracle accounts as actual local accounts with no password (via puppet) and give the DBA's the ability to sudo to those accounts. Obviously, we also have passwordless login disabled. -- 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/a05a0ea3-ff0d-4db8-b27c-030fbac69393%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
