RHEL 7 Problem with Postgres AD/LDAP Service Account?

I checked the latest docs (v. 10) regarding the PostgreSQL user account,
and I did not see mention of running it as an LDAP account (in the User
Account section).

https://www.postgresql.org/docs/10/static/postgres-user.html

I have done this on RHEL 6 using VAS integration with Active Directory,
using <domain>\postgres, as the service account and it worked fine.

A Linux Sys Admin reported to me a problem on RHEL 7, described below.

I would appreciate feedback on this potential issue. Is this true, that we
should not run Postgres as an AD account on RHEL 7? Is it okay to run
Postgres as an AD account on any Linux distro?

I assumed that since we run MySQL, Oracle, and SQL Server with AD service
accounts that we should be able to do the same with Postgres, but I am
having difficulty finding explicit documentation for this.

Sys Admin Description of problem on RHEL7:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"I’m running into a problem with RHEL7 where the /var/run/postresql
directory doesn’t get created and this appears to be due to the fact that
it is built much earlier via systemd, before VAS runs, so the postgres user
is not found at run time.

Either I need to remove the postgres AD account or run postgres under a
different account that I set up locally."

"Running postgres on RHEL 7 using the postgres user account in AD doesn’t
work. What happens is that there’s a process that runs at boot time to
create /var/run/postgresql, but on RHEL7 using a directory account, this
fails because the system cannot find the ID as it runs before VAS starts.
And because Postgres does not have a run directory for the pid file, it
also fails to start."

I asked him to investigate if this can be addressed using RHEL 7 systemd
and service manager to control service dependencies and startup order? This
RHEL doc is what I am referring to: https://access.redhat.com/
articles/754933

His response was:

"It doesn’t work on our RHEL7 test server. We just never rebooted it, so we
never saw the problem. I just rebooted test server and if you look now in
/var/run, there is no postgres directory for the pid.

[sys-admin(at)tst-server run]$ sudo systemctl status
systemd-tmpfiles-setup.service
[sudo] password for sys-admin:
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service;
static; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2017-05-04 10:52:05 EDT; 5min
ago
Docs: man:tmpfiles.d(5)
man:systemd-tmpfiles(8)
Process: 828 ExecStart=/usr/bin/systemd-tmpfiles --create --remove --boot
--exclude-prefix=/dev (code=exited, status=1/FAILURE)
Main PID: 828 (code=exited, status=1/FAILURE)

May 04 10:52:05 tst-server.com systemd[1]: Starting Create Volatile Files
and Directories...
May 04 10:52:05 tst-server.com systemd-tmpfiles[828]:
[/usr/lib/tmpfiles.d/ppas-9.5.conf:1] Unknown user 'postgres'.
May 04 10:52:05 tst-server.com systemd-tmpfiles[828]:
[/usr/lib/tmpfiles.d/ppas-9.5.conf:2] Unknown user 'postgres'.
May 04 10:52:05 tst-server.com systemd-tmpfiles[828]:
[/usr/lib/tmpfiles.d/ppas-9.5.conf:3] Unknown user 'postgres'.
May 04 10:52:05 tst-server.com systemd[1]: systemd-tmpfiles-setup.service:
main process exited, code=exited, status=1/FAILURE
May 04 10:52:05 tst-server.com systemd[1]: Failed to start Create Volatile
Files and Directories.
May 04 10:52:05 tst-server.com systemd[1]: Unit
systemd-tmpfiles-setup.service entered failed state.
May 04 10:52:05 tst-server.com systemd[1]: systemd-tmpfiles-setup.service
failed.

I tried adjusting the order of services, but the systemd-tmpfiles-setup
service has to run before sysinit.target, which is very early in the boot
process. If you attempt to make this start after VAS, it breaks and then
doesn’t create any of the tmpfile directories.

The big issue here is that Postgresql uses the default postgres user as
both an OS account and the default database user account. The OS account
needs to be local, not in AD.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thanks for reading!

David