Linux run service as domain user

How to run systemd service as specific user and group in Linux

Table of Contents

By default most of the systemd services are configured to run by root user but there is also an option to create a custom systemd service unit file and run it as a speciic user or group or both. So in this article we will check and verify the steps to run systemd service as specific user and group using CentOS/RHEL 7/8 Linux environment.

I have installed Oracle VirtualBox on a Linux server, where I will use a Virtual Machine with RHEL/CentOS 7/8 to verify the steps from this article.

Some more articles on similar topic:

Step 1: Overview on systemd

I hope you are already familiar with below topics

Step 2: Create user and Group

Now this is an optional steps assuming you already have your user and group ready for next steps. But if you do not then you can follow this article to create a new user and assign a custom group (primary or secondary) to the respective user.

Here I have already created a user deepak who is part of deepak and admin group

To verify the groups of any user

So we wish to create a systemd service unit file and run systemd service as specific user and group which for us will be deepak user part of admin group

Step 3: Create Sample Script

We will use our startup script from old articles with some tweaks to check and run systemd service as specific user and group in Linux

So in this script we have added an explicit check for user, so unless the user executing the script is » deepak «, the script will fail to execute. If successful the script will continue to write in /opt/golinuxcloud/file for 3 minutes with 1 minute interval. This will also help us make sure that the script does not exits before completing it’s defined task

Change the ownership of the script file to deepak

Provide executable permission to the script

We will execute the script manually to make sure it works as expected

Step 4: Create unit file to run systemd service as specific user and group

Now as highlighted under step 1, I have already written another article with the steps to create a new systemd unit file. Here we will name our systemd unit file as run-as-user.service under /etc/systemd/system . Below is the content of run-as-user.service

Here we have defined User=deepak and Group=admin to make sure the script will be executed only as user deepak which is part of admin group.
You can also use many other directives if required in your environment such as WorkingDirectory , EnvironmentFile etc. For more information check man page of systemd.exec

Refresh the systemd configuration files

Next enable the service (if required) to start automatically at boot

Step 5: Verify the systemd unit file configuration

Now since we are done with the setting up of systemd. Let us verify our configuration. Before starting I have cleared the content of /opt/golinuxcloud/file which is where our script /opt/golinuxcloud/startup_script.sh will place dummy content every minutes for 3 minutes.

We will only start the run-as-user.service runtime as a reboot is not required to validate the configuration here:

Next check the status of the service

Well looks like everything was good as we were able to run systemd service as specific user and group, you can check the ps status to make sure our script is running using below command:

Now you can monitor the content of /opt/golinuxcloud/file for couple of minutes as configured in the script

Lastly I hope the steps from the article to run systemd service as specific user and group in CentOS/RHEL 7/8 Linux was helpful. So, let me know your suggestions and feedback using the comment section.

Related Searches: run service as user linux. systemd allow user to start service. systemd start service as user on boot. linux systemd service run as root. Restarting systemd service only as a specific user? systemd services fail with User= in service file. Start process as a specific user. how to run a service a non-root user completely?

Didn’t find what you were looking for? Perform a quick search across GoLinuxCloud

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

For any other feedbacks or questions you can either use the comments section or contact me form.

Thank You for your support!!

to stay connected and get the latest updates

21 thoughts on “How to run systemd service as specific user and group in Linux”

what is the “admin” group? I have a “root” group, but not an admin group.

admin group used here is an example

Shouldn’t systemd’s “–user” feature be used to allow non-root accounts run their own services — without bothering the root-wielding admin every time they want to change something?

I’d love an actual example of that…

Any application level service is executed by normal user such as apache

Man you really helped me thanks a lot dude!

Loved! Very well explained!

This is really helpful, thank you. It is also rather timely as I’m trying to get a service to work with a little twist and maybe you have some insight to this.

I’m running VirtualBox with a Ubuntu 20.04 guest and a Windows 10 host. The VM is defined with a shared folder on the host.
I need to run the service as my user and it has to create some files and directories in the shared folder.
There are some really weird things happening.
– I am unable to write anything to the shared folder when I run the script as a service. I always get “Permission Denied” errors.
No problem if I run the service as “sudo service xxx start”, only when it is started on system init. I specifically have an
“After=.mount” in the Init section.

– If I run using “+” before the script name on ExecStart, it runs as root and creates files, but then they just disappear. Actually,
they show up only in the script (e.g. if I issue an “ls” command) but by the time I get to log in, they are gone.

Anyway, I’m tearing what little hair I have out on this and can’t get anywhere. Any insight would be greatly appreciated.

Sorry, I didn’t realize I couldn’t use angle brackets. My “After=.mount” should have been “After=shared-folder-dir.mount”, copied from the systemctl list-units list.

Hi Alan,
If there is a requirement for a certain file system then instead of After= you should use RequiresMountsFor=/path/to/fs .
Few questions:
If you just run the script as the user, is the script able to perform write operations in the shared folder? – I assume yes?
Because if this works, there is no reason it will fail as systemctl service.
Or do you see problems writing at reboot stage?
If I have more information, I may try to replicate the behaviour in my environment.

I see there are lot of comments. Can you please consolidate and send me a mail

Thanks for the response and for taking a look at this, to answer your questions:

– Just running the service after I log in, everything works, I can write to the shared folder with the service.
– the really weird thing is that I have echo statements showing that when I run as root:
– I can write to the shared folder
– the script sees the files and directories via ls right after creation
– they go away at some point. there is no delete for these files anywhere, but some of them are accessed
by a java program that the script is calling. some are not. but they all disappear by the time I can log in
and look.

Thanks for sharing the additional information, I will not approve the script as that may be confidential.
Give me time till tomorrow, let me try to replicate this and come back. I am also little occupied with my office work.
I assume you are using samba for file sharing.
We can further communicate using your mail address. You can send mail to admin@golinuxcloud.com

First, Thanks a lot for this nice tutorial. This is what i am looking for.

But I faced a problem. In my one test VM, it works fine and then I have tried to do the same procedure in another machine (important vm) but the service has not started. I have tried to start the application manually it works fine (owner of statsup.sh is non-root user).

Then I commented out the User and Group in a Unit file under systemd and it works again. So I guess the problem is with the systemd service file. Kindly give me some idea what to do?

Thank you for your feedback.
Does if work if you try to start the application using the systemd service manually?
Did you checked “journalctl -b” logs for any hint?

One hint from Journalctl >> catalina.sh said permission denied (as my application call catalina.sh)
In my VM no tomcat service and owner of catalina.sh is root
but in my target machine (where i have problem) there is a tomcat service and its stopped and owner of catalina.sh is tomcat
And What does it mean to start the application using the systemd service manually? (i am a newbie)
Can you please give me any idea what to do?

I am not sure if I understand the scenario completely. On your target VM if your service is supposed to be started as root then you can remove the User and Group argument in the systemd unit file. The idea is to understand the requirement first, you mentioned that systemd service fails to start the service automatically so does that mean the service ends up being ‘dead’ or the service is not started at all.

Can the service use a domain user instead of the local user when running.
E.g We have a domain user that will have access to the MSSQL DB on some server
Our client machine is redhat linux on which tomcat is running as a service.
Our client machine is already added to the same domain as the MSSQL DB
The servlet in our tomcat needs to access the MSSQL DB
Instead of SQL Authentication, we want to use windows authentication for this purpose
Now how can we run the tomcat as the same domain user that has access to the MSSQL DB ?

You can just place the username in the User=USERNAME field without any domain details. For ex if your mysqldb user is dbadmin then just place User=dbadmin and it should work. Unless you also have a local user names dbadmin in which case there can be conflict so you will have to delete the local user.

How can I check whether we have systemd privileges or not ?

By default non root users don’t have privilege to use systemd to restart/start/stop services but they should have permission to check the status. You may try to restart any service such as sshd and if you don’t have privilege then the same should fail

That’s a horrible place to put the example script, in /tmp
On many systems like fedora, tmp is a tmpfs file system and the script will disappear on reboot.
Even on “normal” /tmp’s not on tmpfs , files that don’t change in a certain time will be removed from /tmp via systemd-tmpfiles-clean.service

Yes, that makes sense. With later releases of RHEL, CentOS I realized by default tmp will be either tmpfs or the tmpfiles-clean service will clean up /tmp frequently. I have updated the path.

Источник

Linux в домене Active Directory

Перед администраторами иногда встают задачи интеграции Linux серверов и рабочих станций в среду домена Active Directory. Обычно требуется:
1. Предоставить доступ к сервисам на Linux сервере пользователям домена.
2. Пустить на Linux сервер администраторов под своими доменными учётными данными.
3. Настроить вход на Linux рабочую станцию для пользователей домена, причём желательно, чтобы они могли при этом вкусить все прелести SSO (Я, например, не очень люблю часто вводить свой длинный-предлинный пароль).

Обычно для предоставления Linux системе пользователей и групп из домена Active Directory используют winbind либо настраивают библиотеки nss для работы с контроллером домена Active Directory по LDAP протоколу. Но сегодня мы пойдём иным путём: будем использовать PowerBroker Identity Services (Продукт известен также под именем Likewise).

Установка.

Есть две версии продукта: Enterprise и Open. Мне для реализации моих задач хватило Open версии, поэтому всё написанное далее будет касаться её.
Получить Open версию можно на сайте производителя, но ссылку Вам предоставят в обмен на Ваше имя, название компании и e-mail.
Существуют 32-х и 64-х пакеты в форматах rpm и deb. (А также пакеты для OS X, AIX, FreeBSD, SOlaris, HP-UX)
Исходники (Open edition) доступны в git репозирории: git://source.pbis.beyondtrust.com/pbis.git
Я устанавливал PBIS на Debian Wheezy amd64:

Содержимое пакета устанавливается в /opt/pbis. Также в системе появляется новый runscript lwsmd, который собственно запускает агента PBIS.
В систему добавляется модуль PAM pap_lsass.so.
Утилиты (большей частью консольные), необходимые для функционирования PBIS, а также облегчающие жизнь администратору размещаются в /opt/pbis/bin

Ввод в домен.

Перед вводом в домен следует убедиться, что контроллеры домена доступы и доменные имена корректно разворачиваются в ip. (Иначе следует настроить resolv.conf)
Для ввода в домен предназначены две команды: /opt/pbis/bin/domainjoin-cli и /opt/pbis/bin/domainjoin-gui. Одна из них работает в командной строке, вторая использует libgtk для отображения графического интерфеса.
Для ввода в домен потребуется указать: имя домена, логин и пароль доменного пользователя с правами для ввода ПК в домен, контейнер для размещения объекта компьютера в домене — всё то же самое, что и при вводе в домен windows ПК.

После ввода в домен потребуется перезагрузка.
Обратите внимание — PBIS умеет работать с сайтами Active Directory. Клиент PBIS будет работать с контроллерами того сайта, в котором он находится!

После перезагрузки.

После перезагрузки и id, и getent выдадут вам пользователей и группы домена (национальные символы обрабатываются корректно. Пробелы заменяются на символ «^»).
В доменной DNS зоне появится запись с именем вашего ПК.
Не спешите входить от имени доменного пользователя. Сначала имеет смысл (но вовсе не обязательно) настроить PBIS.

Одно из отличий Enterprise версии — возможность управлять этими настройками через GPO.
Стоит обратить внимание на HomeDirPrefix, HomeDirTemplate.
Я также сразу задал «RequireMembershipOf» — только пользователи, члены групп или SID из этого списка могут авторизоваться на компьютеры.
Описание каждого параметра можно получить, например так:

Значение параметра устанавливается например так:

Обратите внимание — PBIS не использует атрибуты SFU либо иные другие атрибуты Acrive Directory для получения loginShell пользователя, а также его uid и gid.
loginShell для доменных пользователей задаётся в настройках PBIS, причём установка различных loginShell различным пользователям — возможна только в Enterprise версии.
uid формируется как хэш SID пользователя.
gid — как хэш SID primaryGroup пользователя.
Таким образом на двух ПК пользователь получит всегда одинаковые uid и gid.

Теперь можно входить в систему от имени доменного пользователя. После входа доменного пользователя обратите внимание на вывод klist — PBIS получит для пользователя необходимые билеты kerberos. После этого можно безпроблемно обращаться к ресурсам на windows ПК (Главное, чтобы используемое ПО поддерживало GSSAPI). Например: теперь я без дополнительных запросов паролей (и пароль мой нигде не сохранён!) открываю любые smb ресурсы домена в Dolphin. Также Firefox (при настройке network.negotiate-auth.trusted-uris) позволяет использовать SSO при доступе к Web-порталам с доменной авторизацией (естественно если SSO настроена на сервере)

А как же SSO при доступе к ресурсам на Linux ПК?

Можно и так! PBIS заполняет /etc/krb5.keytab и поддерживает его актуальным. Поэтому серверное ПО с поддержкой GSSAPI может быть сконфигурировано для SSO.
Например, для доступа к серверу по ssh, в конфигурационный файл /etc/ssh/sshd_config (путь в вашей системе может отличаться)
И при подключении указать доменное имя компьютера (присутствующее в его SPN — иначе билет kerberos не сможет быть выписан)
UsePAM yes

(PBIS предоставляет модуль для PAM в том числе)
Также логично будет добавить директиву «AllowGroups» и указать через пробел доменные группы, пользователям которых вы намерены дать доступ к ssh серверу.

На клиентском Linux ПК в конфигурацию клиента ssh достаточно включить:

Естественно на клиентском Linux компьютере должен быть настроен kerberos. Простейший способ выполнить это условие — так же ввести клиентский компьютер в домен и работать от имени доменного пользователя.

На клиентском Windows ПК (члене домена) при использовании Putty следует в свойствах SSH соединения установить флаг «Attempt GSSAPI authentification (SSH-2 only)» (В разных версиях этот пункт называется по-разному).

Также в секции Connection —> Data можно поставить переключатель в позицию «Use system username»

Если вы намереваетесь организовать таким образом ssh доступ администраторов к linux серверам — хорошей идеей будет запретить на них вход root по ssh и добавить linux-администраторов (а ещё лучше их доменную группу) в файл sudoers.

Это не единственные сценарии применения PBIS. если статья покажется Вам интересной — в следующей напишу как организовать samba файловый сервер в домене для доменных пользователей без winbind.

Дополнительную информацию по теме можно получить на форуме сообщества PowerBroker Identity Services: forum.beyondtrust.com

UPD. К преимуществам PowerBroker Identity Services я могу отнести:

1. Хорошую повторяемость (сравните последовательность действий этой статье с инструкцией по настройке winbind)
2. Кэширование данных из каталога (доменный пользователь может войти на ПК, когда домен не доступен, если его учётные данные в кэше)
3. Для PBIS не требуется формирование в каталоге AD дополнительных атрибутов пользователя
4. PBIS понимает сайты AD и работает с контроллерами своего сайта.
5. Большую безопасность (samba создаёт учётку компьютера с не истекающим паролем)
6. В платной версии (если возникнет такая необходимость) PBIS агент управляем через GPO (хотя это можно и вычеркнуть. если вы не намерены её покупать)

UPD 2 Пришла обратная связь от пользователя sdemon72. Возможно кому-то будет полезно.

Здравствуйте! Попробовал ваш рецепт на свежей linuxmint-18-mate-64bit, все получилось с некоторыми оговорками:
1. С получением программы через сайт у меня возникли сложности (не захотел писать реальный номер телефона, а бутафорский не прокатил — пришло письмо с сомнениями по его поводу), зато нашел репозиторий с наисвежайшими версиями: repo.pbis.beyondtrust.com/apt.html
2. При запуске программы выдает ошибки, чтобы их избежать, нужно перед запуском сделать следующее:
2.1. Установить ssh:
sudo apt-get install ssh
2.2. Поправить /etc/nsswitch.conf:
hosts: files dns mdns4_minimal [NOTFOUND=return]
(т.е. переносим dns с конца строки на вторую позицию)
2.3. Поправить /etc/NetworkManager/NetworkManager.conf:
#dns=dnsmasq
(т.е. комментируем эту строчку)
2.4. Перезапустить network-manager:
sudo service network-manager restart

После этого все сработало на ура! Буду очень благодарен, если внесете эти дополнения в статью, т.к. в поиске по сабжу она выпадает в первых строках. Оставлять комментарии я не могу (запрещает сайт), поэтому пишу вам лично.

Если интересно — история моих изысканий тут: linuxforum.ru/topic/40209

С уважением, Дмитрий

UPD 3: Почему бесплатную версию PBIS не получится применить в большой компании
В бесплатной версии работает только один алгоритм генерации UNIX iD (uid и gid) по SID доменного пользователя. Так вот он не обеспечивает уникальности
этих идентификаторов. Когда у вас очень старый домен или просто много пользователей очень высок риск, что два и более пользователя получат одинаковые идентификаторы в системе с OpenPBIS. В платной версии есть возможность выбора между алгоритмами генерации id, но она стоит значительно дороже аналогичного продукта от Quest Software ;(.

Источник