3

I feel like I am overlooking something obvious.

My goal is to run a systemd service with an LDAP service account at system startup. THAT WAY, if I disable the account in LDAP, then the next time the service attempts to start, it will fail, because the user is not authorized. (Eventually, I need to get my Kerberos setup for the service to use ticketing, but I'm not there yet, and that may be my problem overall here)

I have a functioning LDAP that I can use to control user logins, so my user is cn=cbrand,ou=people,dc=jcolebrand,dc=info and I can login with this user on the connected machines in my network. I've got a sudoers setup through LDAP, so myself and one other user on my system can log in and run sudo commands, but others who have login privileges can't run sudo commands. I have other users who can use LDAP to authenticate to various applications on my servers (so they don't have system login privileges, but they do have basic accounts with passwords).

I have ldap2pg setup to handle readers/writers/superusers on my system which I would like to use to also restrict access for services running on the network that are connected to the LDAP instance.

I would like to be able to define an account in LDAP for some service X (as a real-world example, I'm going to install gogs, or perhaps I will migrate my jellyfin service to run under a similar account as well), and then use that service account to run the service (so I would expect something like cn=gogs,ou=services,dc=jcolebrand,dc=info or cn=jellyfin,ou=services,dc=jcolebrand,dc=info). What I would like to avoid doing is to have to create a local user/group by hand to run as, because that would have to be managed per-server. Instead I would like to be able to use ldap2pg to revoke database access, or use LDAP to deny login/access privileges at the directory level.

If I were going to create a local account, I would just modify my service target to use the User= directive, but that seems incorrect for connecting to LDAP, especially if I want to force a password (this may require some automation around rotating that password for the service account, that's another story, I suspect, but maybe not! I know I don't know enough about this to know if I'm overlooking something "obvious".)

As a partial configuration snippet, if this helps, I have:

cat /etc/openldap/ldap.conf
<snip>
BASE dc=jcolebrand,dc=info
<snip>

If this were a Windows Active Directory Domain I would use gMSA accounts and this would be seamless, or I would even be able to just create a generic service account in the directory with a password, but I do not know how to do this in Fedora/Linux. Specifically what I do not know how to replicate from a Windows world is this step:

Windows -> Open services.msc -> Find the service -> Goto Properties -> set the user credentials on the security tab to either the gMSA or the account/password, as appropriate.

Looking at the systemd docs I see the LoadCredential documentation, but that does not seem to make sense (by the way the documentation is written) for supplying the password to run as an LDAP account.

Am I overthinking this and I should have a passwordless objectClass applicationProcess LDAP entry and set the service configuration for User="cn=gogs,ou=services,dc=jcolebrand,dc=info" and then just stop doing extra thinking?

Nota bene: Eventually I would also like this same service to talk to postgres using the same information, but that likely just requires an appropriate connection string, which I can use the environment file for the systemd service configuration. Pointers for this are also welcome.

11
  • You describe what you tried, but not what you want to achieve, and to what end. Are you talking about system or user services? You want the service to authenticate with remote services using a LDAP identity? That's the only practical use case. In general, LDAP is a directory, a tree-structured database, neither authentication nor an authorisation mechanism, rather a thing underlying both. Your Un*x uid may be uIDNumber, and a PAM module handles that. Auth is handled differently on different systems, from kerb to matching SLDAP TLS key you've bound with. Commented Mar 1, 2023 at 4:27
  • I could've sworn I started with the best version of what I want to achieve: My goal is to run a systemd service with an LDAP service account at system startup. I then tried to go into detail to help shape the conversation and discuss what I know and what I don't know. I will add another sentence after that, however, to be a little more clear.
    – jcolebrand
    Commented Mar 1, 2023 at 20:00
  • I'm sorry about the confusion. “My goal is to run a systemd service with an LDAP service account” sounds to me not as a goal, but the means of achieving the goal. I.e., why run a service as a LDAP identity, with all the drawbacks of it? We could think together about a better solution, if you wish. BTW, this Q seems well-suited for the ServerFault.SE, as it's about managing an enterprise network. X-posts are usually frowned at, but if you start with the problem there, then asking “is running my unit with a LDAP identity the best solution?" then it would be a different question. :) Commented Mar 2, 2023 at 4:29
  • I see the change. So the goal is, at phase 1, to have a central "kill switch" for certain services on all machines, and, the next phase, use the asserted identity to connect to PostgreSQL over the network, correct? Yeah, the phase 2 is often done with kerb deployment. Look at sssd as a way of federation: it abstracts identity providers. An important parameter in the unit is PAMName=, see systemd.exec(5): you may need to create a custom PAM profile to invoke providers to establish the required identity. I don't know much about postgres security to be helpful, sorry. :( Commented Mar 2, 2023 at 4:49
  • I had considered SF for the post, but it seemed more linux-specific as a problem and less SF ish, esp since there are clearly details I don't know. I've been having issues figuring out Kerb because I cleverly decided to start my lab setup on Fedora 37 and I'm a little too far in to change course (ZFS drive is filling up) so working through the SELinux and the like over there.
    – jcolebrand
    Commented Mar 2, 2023 at 23:18

1 Answer 1

1

I would create a linux system user (an objectClass: posixAccount in LDAP) and simply set the systemd unit file to have User=< uid value from the LDAP record

If PAM is properly configured, this should populate a uid and linux username which systemd will be able to spawn the executable process under. You'll need a service user with a linux UID on the maine chfor the kernel to track the process anyway, so I don't think you can avoid using objectClass: posixAccount

Your LDAP record will likely look something like:

dn: cn=gogs,ou=services,dc=jcolebrand,dc=info
objectClass: posixAccount
uid: gogs
cn: gogs
loginShell: /bin/nologin
uidNumber: 9999
gidNumber: 9999
homeDirectory: /path/to/gogs/install
description: gogs service user

I believe that you can add objectClass applicationProcess to this entry as well, should you want to.

You can then either edit the gogs systemd unit directly, or create an override (E.G. with sudo systemctl edit gogs.service) and add:

[Service]
User=gogs

(you may need a objectClass: posixGroup entry for gogs as well, and then you can use Group=gogs in the systemd unit)

I am confused by these parts of your question:

would just modify my service target to use the User= directive, but that seems incorrect for connecting to LDAP, especially if I want to force a password

and

Looking at the systemd docs I see the LoadCredential documentation, but that does not seem to make sense for supplying the password to run as an LDAP account

Under Linux, service accounts generally don't have passwords in my experience. They're simply a separate user that the processes for that service run as. Database authentication can be done with a password string (which you could distribute using LDAP) or via Kerberos (probably? I'm not sure how the service gets a ticket) but the service POSIX account has no password -- because nobody ever logs in to it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .