Hi there.
Sorry if this has been asked and answered, but I am very new to opensuse and have followed the documentation, yet this problem is still kicking my rear end.
I have a active directory group with lets say a domain of example.com, in there I have a group of users who are members of the group linuxadmins.
my server is set up with the setup shown below
Replace the drawn-out bits with EXAMPLE for sake of argument.
My sudoers file is set as below
#Defaults targetpw
#ALL ALL=(ALL) ALL
example\\linuxadmins ALL=(ALL) ALL
From what i can tell, This is all set according to the spec. But when I go to run any command using my user when logged in to their account, such as sudo zypper-log, I get the following response.
EXAMPLE\user is not allowed to run sudo on opensuse
What am I doing wrong here. Domain login works, but after that, trying to do sudo actions fails.
I wonder if this might help:
https://www.suse.com/support/kb/doc/?id=000018877
I note that the domain\group values in the examples are in double quotes (and use a single backslash), but it looks like the value used depends on how you’re connecting the systems together.
While this is for SLE, it should be pretty much teh same for openSUSE.
I have tried every combination of quotes, no quotes, fowards and backwards.
Is your domain controller Windows with Active Directory or a SAMBA configuration?
How is your Leap box configured to authenticate via the domain?
its a genuine honest to goodness Windows server AD (2022 specifically)
What do you mean how is it configured to authenticate? Sorry i am incredibly new to suse/windows integration.
Do you mean how is user logon in YAST configured, Windows Domain Membership, Users and group management? I want to make sure I am providing the correct information.
Thanks - what I’m thinking is that it might be a quick thing for me to set up if I have the same tools. I’ll have to see if I can install a Windows server DC.
In terms of the openSUSE configuration, which tools were installed and used to configure the domain membership. If you did it in YaST, it’s probably going to be the same, but I’d hate to set it up with one set of tools when you’ve used another. 
I used the tools in Yast, back to the whole new to suse sort of thing. My understanding/comprehension of linux as a whole is beginner to moderate at best. So far, I like suse and definately want to learn more about it, but more specificaly, need to figure this issue out in order to build a server for my office where we require all authentication be able to be controlled by AD.
1 Like
Did you try:
"%linuxadmins" ALL=(ALL) ALL
Where linuxadmins is the name of your AD group?
Yes I did. Unfortunately I had the same results.
I just realized I left the % out of my initial post but it is there in the actually file
Whats interesting is I am also getting the same message on the built in administrator account when i try to install software.
Interestingly using su works fine though.
Digging into this further, it seems there are two options - winbind and sssd - which of these are you using?
I believe I am using SSSD, not entirely sure though. I have tried the configurations in the document for both.
for additional use, adding the sssd.conf file in its current state.
[sssd]
config_file_version = 2
services = pam,nss,sudo
domains = EXAMPLE.COM
[domain/EXAMPLE.COM]
id_provider = ad
auth_provider = ad
enumerate = false
cache_credentials = false
case_sensitive = true
[pam]
[nss]
override_homedir = /home/%u
[sudo]
[domain/default]
auth_provider = krb5
chpass_provider = krb5
krb5_realm = EXAMPLE.COM
krb5_server = Patch.example.com
krb5_validate = False
krb5_renewable_lifetime = 1d
krb5_lifetime = 1d
Patch is the host name of my domain controller for the sake of argument here.
Only things changed are the actual domain has been switched to example
That seems consistent with what I’ve managed to configure - I am to the point of getting the same message you are.
In another terminal window, as root, run journalctl -f while attempting the sudo command with your AD user. Do you see a message saying the user is not authorized on host:
Jul 13 16:19:06 localhost.localdomain sudo[29105]: jimh : user NOT authorized on host ; TTY=pts/0 ; PWD=/home/UNIVERSEDOMAIN.local/jimh ; USER=root ; COMMAND=/usr/bin/ls
Just want to make sure I’m seeing what you’re seeing before I troubleshoot further.
as run as builtin admin with -su on
administrator@opensusetest1:~> su
Password:
root@opensusetest1:/home/administrator> journalctl -f
Jul 13 19:18:32 opensusetest1 systemd-helper[2955]: running cleanup for 'root'.
Jul 13 19:18:32 opensusetest1 systemd-helper[2955]: running number cleanup for 'root'.
Jul 13 19:18:35 opensusetest1 PackageKit[2796]: daemon quit
Jul 13 19:18:35 opensusetest1 systemd[1]: packagekit.service: Deactivated successfully.
Jul 13 19:18:40 opensusetest1 dbus-daemon[708]: [system] Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)
Jul 13 19:20:15 opensusetest1 kernel: BTRFS info (device vda2): qgroup scan completed (inconsistency flag cleared)
Jul 13 19:20:15 opensusetest1 systemd-helper[2955]: running timeline cleanup for 'root'.
Jul 13 19:20:15 opensusetest1 systemd-helper[2955]: running empty-pre-post cleanup for 'root'.
Jul 13 19:20:16 opensusetest1 systemd[1]: snapper-cleanup.service: Deactivated successfully.
Jul 13 19:21:16 opensusetest1 systemd[1]: snapperd.service: Deactivated successfully.
as run as my AD user in my linuxadmins group
EXAMPLE\aduser@opensusetest1:~> sudo journalctl -f
[sudo] password for EXAMPLE\aduser:
EXAMPLE\aduser is not allowed to run sudo on opensusetest1.
I am not 100% sure i ran things as you wanted here, but am willing to run again if you can clarifiy what the commands needed are. followed along best i could.
Yeah, running the journalctl command as root is needed. Once that’s running, then try a sudo command as the AD user in the group.
How do i do that? sorry if it seems like a stupid question.
No worries.
You’ll need two terminal windows to do it. In one terminal window, just become root (su - root) and run the journalctl command.
In another window, become the AD user by typing:
su - aduser
replacing “aduser” with whatever your username is. Enter the user’s AD password, and you should be logged in.
Then run sudo ls and look at what new lines are added to the terminal with journalctl running.
I think I got it
opensusetest1:~ # journalctl -f
Jul 13 20:10:33 opensusetest1 su[32639]: pam_unix(su-l:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/0 ruser=administrator rhost= user=EXAMPLE\aduser
Jul 13 20:10:33 opensusetest1 su[32639]: pam_sss(su-l:auth): authentication success; logname= uid=1000 euid=0 tty=/dev/pts/0 ruser=administrator rhost= user=EXAMPLE\aduser
Jul 13 20:10:33 opensusetest1 su[32639]: (to EXAMPLE\aduser) administrator on pts/0
Jul 13 20:10:33 opensusetest1 su[32639]: pam_unix(su-l:session): session opened for user EXAMPLE\aduser by (uid=1000)
Jul 13 20:10:34 opensusetest1 dbus-daemon[31836]: [session uid=1000 pid=31836] Activating via systemd: service name='org.gtk.vfs.Metadata' unit='gvfs-metadata.service' requested by ':1.17' (uid=1000 pid=31894 comm="/usr/bin/gnome-shell ")
Jul 13 20:10:34 opensusetest1 systemd[31772]: Starting Virtual filesystem metadata service...
Jul 13 20:10:34 opensusetest1 dbus-daemon[31836]: [session uid=1000 pid=31836] Successfully activated service 'org.gtk.vfs.Metadata'
Jul 13 20:10:34 opensusetest1 systemd[31772]: Started Virtual filesystem metadata service.
Jul 13 20:10:34 opensusetest1 geoclue[31949]: Service not used for 60 seconds. Shutting down..
Jul 13 20:10:34 opensusetest1 systemd[1]: geoclue.service: Deactivated successfully.
Jul 13 20:11:56 opensusetest1 sudo[32700]: gkr-pam: unable to locate daemon control file
Jul 13 20:11:56 opensusetest1 sudo[32700]: gkr-pam: stashed password to try later in open session
Jul 13 20:11:56 opensusetest1 sudo[32700]: pam_unix(sudo:auth): authentication failure; logname= uid=21104 euid=0 tty=/dev/pts/0 ruser=MORONEYLABS\connor rhost= user=EXAMPLE\aduser
Jul 13 20:11:56 opensusetest1 sudo[32700]: pam_sss(sudo:auth): authentication success; logname= uid=21104 euid=0 tty=/dev/pts/0 ruser=MORONEYLABS\connor rhost= user=EXAMPLE\aduser
Jul 13 20:11:56 opensusetest1 sudo[32700]: EXAMPLE\aduser : user NOT authorized on host ; TTY=pts/0 ; PWD=/home/EXAMPLE\aduser ; USER=root ; COMMAND=/usr/bin/ls
Similar to what I’m seeing - but I notice that your log file shows the domain name in the username, while mine does not.
I believe I’ve figured it out, though - in YaST, when you go into Authentication Settings in the User and Group Administration tool to configure SSSD, do not check the “Super-User Commands (sudo)” box under “Enable domain data source”.
What this option does is pull the sudo configuration from the domain controller’s LDAP directory, which requires doing the configuration by creating LDAP objects. If you’re managing a large number of Linux systems’ sudo access this way, you might want to configure it, but that configuration looks to be a bit more involved.
I tracked this down by trying to make sure that local user sudo access was working, and it wasn’t - no matter what I did.
Disabling that option let me configure a local user again to be able to use sudo, and when I added the line:
%linuxadmins ALL=(ALL) ALL
Back into the sudoers file, I was able to run commands using sudo as a user in that group.
2 Likes
