Creating a user without a shadow entry

[William Korb]

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?

Thanks again,
Bill

[jcbollinger]

On Monday, July 24, 2017 at 4:33:09 PM UTC-5, William Korb wrote:

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.

[...]

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?

There is, but not straight out of the box via Puppet's User resource type.  By default, Puppet uses the local tools on each machine for managing the properties associated with User resources.  On Linux hosts, that generally means the useradd command and its siblings, or perhaps an analogous group of commands, and on systems that use a shadow file (which should be all of them) these commands manage entries in the passwd and shadow files together.

Of course, it makes sense that Puppet doesn't serve your use case out of the box, because the setup you are trying to achieve is non-standard for the systems you are configuring.  There are several ways you could approach it, among them:

1. Write a custom provider for the User resource type, and employ it to manage your shadow-less user(s) via User resources.  This is probably the cleanest to use, but it is unquestionably the most work to implement.
   
2. Manage the oracle user via a User resource with the default provider, and also ensure via a separate resource that the corresponding line is removed from the shadow file when necessary.  The file_line resource of the puppetlabs/stdlib module can help with the latter.
   
3. Manage the passwd line for the oracle user by managing the passwd file directly, for instance by using a File_line instead of a User.
   

Each of those approaches has both advantages and disadvantages.  They are listed in descending order of complexity.

Were I to choose, and supposing that this one user is a unique special case, I would probably choose (2).  It is tremendously easier to do than (1), albeit a bit more complex than (3).  Option (2) has the advantages over option (3) that

• It will remove the unwanted shadow line if it (or a conflicting one) is added by other means.
• It will notice and flag an error if you should happen to add another User resource for the oracle user to your manifest set.
• It will be very clear to whomever comes after you (maybe future you) just what you're doing, and that avoiding the shadow line is intentional.

John

[John Gelnaw]

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.