Some time ago I wanted to let services like Apache, application servers, databases and stuff run as “Active Directory” users under Linux. Linux uses a component called “winbind”, which is part of the all famous “Samba” package, to connect to an “Active Directory”. What it does is basically map your AD (short for “Active Directory”) users to local users. One can log in, have a home directory, permissions, the users can become root by using the command “sudo” and so on. So why not use it for services?
Well, as mentioned “winbind” maps the users and to let a service run under a specific user the user has to be accessible (or better: the user must exist). AD users do not exist as long as “winbind” is not loaded and when a service tries to start as long as “winbind” is not loaded it will terminate in an error. This is also relevant when using AD users for virtual hosts in Apache. There is a way to let certain virtual hosts run as a specific user instead of “www-data”. Same goes for cron: When the cron service starts and should run a certain command at a certain time in space as AD user but “winbind” is not loaded it will throw an error even tough winbind would be running when the command is scheduled to be executed. If “cron” does not know the user when parsing the file “crontab” it will not execute the command. These are a few findings why it is a bad idea launching services as AD users.
My solution approach was to find something in “SystemD” like “winbind.target” and define my required services to only run if “winbind” is already loaded, but unfortunately there is no such thing. If anyone has an idea how to solve this feel free to contact me. Would be much appreciated.
The solution I came up for me now is to execute “SystemD” services as local service user that can not log in. If the service creates data it is stored in the local service users home directory. To manage and access this production data “winbind” can be utilized: Share the service users home directory via a directive in “smb.conf”:
[svcshare] comment = Service user directory browsable = yes writeable = yes path = /home/serviceuser valid users = @LinuxAdmins force user = serviceuser force group = serviceuser create mode = 0644 directory mode = 0755
This block allows members of the AD group “LinuxAdmins” to access the local service users home directory and upload and modify data. But data uploaded by this users is assigned “serviceuser” as username and group. This means the service an run even tough AD may not be accessible (server changed network, network error, etc.).
I have now several services running stable with this solution and it works like a charm for me.