On Fri 31 Mar 2023 09:41:16 +0200, Marc Haber wrote: > Please add your reasons to this bug, so that the sudo maintainers can > properly consider the reasons in their decision.
I personally DON'T need sudo-ldap anymore. 1. I ran sudo-ldap + slapd on an Ubuntu 10.04 farm until 2022. It was mainly for things like "sudo eject" (back when blank CDs were expensive, and HAL was still a thing) and "sudo ldapadduser" (to let managers onboard staff & create mailing lists without sysadmin help). I was planning to replace it with a "pure" samba AD stack, but the Windows-iness just got Too Hard, so I ended up going back to plain /etc/shadow and /etc/sudoers.d, now managed by ansible. 2. I set up sssd in 2022 at another site, on SLES 12, aimed at a Windows AD stack. I wasn't allowed to use sssd for sudo, though, so that site is still using sudoers.d (also via ansible). It wasn't clear if sssd-sudo required me to add additional schemata to AD, like sudoers-ldap does. If NOT, that would definitely be an advantage for sssd-ldap over sudo-ldap :-) 3. I run de Jong's libnss-ldapd / libpam-ldapd at another site, and it works well there, but again, the sudo rules are simple enough they get hard-coded into sudoers.d. I like https://manpages.debian.org/slapo-ppolicy. 4. For automated machine-to-machine jobs (e.g. zfs send/receive) I prefer to skip sudo altogether. For example, I now use https://manpages.debian.org/zfs-allow to let a non-root system user "zfs-receive-trinity" have permission to mess with ZFS dataset "morpheus/srv/backup/trinity". I've been thinking about https://archive.org/details/lca2020-Zero_Trust_SSH but right now I'm still just using Ed25519 keypairs for everything. 5. One thing I do really appreciate is that the sudoers.ldap objects are MUCH easier to understand than an equivalent sudoers.d config file. dn: cn=responsible,ou=groups,o=cyber objectClass: posixGroup description: Staff responsible for OUR systems and networks. description: I often reflect that if "privileges" had been called "responsibilities" or "duties", I would have saved thousands of hours explaining to people why they were only gonna get them over my dead body. -- Lee K. Gleason, VMS sysadmin gidNumber: 2049 memberUID: twb memberUID: REDACTED dn: cn=defaults,ou=sudoers,o=cyber objectClass: sudoRole sudoOption: always_set_home sudoOption: env_reset sudoOption: ignore_dot sudoOption: ignore_local_sudoers sudoOption: insults sudoOption: !setenv sudoOption: set_logname dn: cn=%responsible,ou=sudoers,o=cyber objectClass: sudoRole sudoUser: %responsible sudoHost: ALL sudoRunAsUser: ALL sudoRunAsGroup: ALL sudoCommand: ALL sudoOption: !authenticate dn: cn=bbq,ou=sudoers,o=cyber description: Staff need this to burn CDs and DVDs on BBQ. objectClass: sudoRole sudoUser: %cyber sudoHost: bbq sudoRunAsUser: sudoRunAsGroup: cdrom sudoCommand: /usr/bin/wodim sudoCommand: /usr/bin/cdrecord sudoOption: noexec When I read an /etc/sudoers.d/ugh.conf I often start by reading https://manpages.debian.org/sudoers.ldap just so I don't go mad. If sudo could have the sudo-ldap format in flat file, I'd be happier. At least in cases when I have more than "%sudo (ALL:ALL) NOPASSWD: ALL". As an analogy, consider how much nicer it is now we can use /etc/apt/sources.list.d/debian.sources (deb822 format) instead of the old /etc/apt/sources.list.d/debian.list (legacy format)
