By the way - thank you for bringing this question in here. I had always wanted to take a look at how using a centralized identity store worked with Linux, but never had a reason to set it up. This was a very interesting issue to troubleshoot, and I learned quite a bit digging into it this afternoon. 
2 Likes
Written at like 9pm EST on 7/13 unable to post till now due to being too new
IT WORKED
Out of curiosity, is there any literature on setting up the sudo configuration from the domain controller? I think for now, this solution given its limited scope of one machiene will work, but in the future being able to do something at a controller level would be much more useful.
Below this point is written on 7/14
Thank you for being so helpful and welcoming, As stated, still very new to the world of suse, I am coming from debian based stuff. Wanted to learn RHEL like but with the chaos that is RHEL currently figured suse would be better. So far, LOVING how open opensuse is as far configuration, choice, and everything else.
You bet!
What I found when I was looking yesterday was pretty thin, looks like an LDAP schema extension that has you then defining the sudo configuration lines as objects within the directory.
Sudoers LDAP Manual | Sudo appears to be the definitive documentation on it (which I hadnât previously found).
Right, itâs an LDAP schema which can store sudo configuration. Itâs neat once set up for enforcing the configuration across multiple hosts.
Hereâs an example entry for a user:
dn: cn=%mygroup,ou=SUDOers,ou=syscid-system,dc=syscid,dc=com
sudoUser: %mygroup
sudoCommand: /usr/bin/make build
objectClass: top
objectClass: sudoRole
cn: %mygroup
sudoOption: !authenticate
sudoRunAsUser: someuser
sudoHost: playground01
sudoOrder: 6
Thatâs the rough equivalent to:
%mygroup playground01=(someuser) /usr/bin/make build
That being said, I think proper configuration management systems are more popular nowadays.
So I have a new problem, I am able to log in and run applications and run the sudo command, but in order to launch gui applications as the ad user such as YAST that require root login, i am greeted by the following message
Is there a remedy for this.
That looks like âgnomesuâ - which doesnât use the sudoers configuration (something thatâs bugged me for years). Iâve never really looked to see what the options are for that.
kde - using sudo on GUI applications - Unix & Linux Stack Exchange seems to have some ideas about how this might be made to work with some environment preservation configuration options in the sudoers file.
I tried adding the line
Defaults env_keep += "DISPLAY XAUTHORITY"
and uncommented
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE"
No difference.
After doing that, are you using sudo or gnomesu? gnomesu doesnât use the sudoers configuration.
What command are you executing thatâs leading to this? (I ask because when running yast2 as a non-root user, I start it with gnomesu -c '/sbin/yast2')
i just did an outright
sudo /sbin/yast2
unfortunately that only brings up the text command interface for yast.
Additionally, is there a kde equivalant of gnomesu? the current box is gnome based, but i eventually plan on moving to kde for deployment as its my preferred interface these days.
kdesu is the KDE equivalent of gnomesu.
I wonder if you add xhost +localhost as a local command before running sudo, with the modifications youâve made in sudoers would result in the GUI. You might have to force it with --qt.
gnomesu and kdesu are both going to behave more like su than sudo - Iâve done a little digging, and I canât find an equivalent for sudo thatâs GUI-based - so defining rules per application is going to prove to be challenging.
It looks like there may be a way to configure polkit to use sssd, but thereâs no âeasyâ button for that (no GUI to edit the configuration).
not sure.
not even entirely sure how that kind of command would be written. Honestly, if i can just launch the gui mode for yast from command line, thats good enough here. the final setup can contain a root account with known sudo password that is a pain to type in, i just want AD mainly to make things easier for everyone else.
Iâd try just:
xhost +localhost
sudo /sbin/yast2 --qt
And see what happens.
Maybe someone else will jump in here with an idea about how to accomplish what youâre looking to do using polkit - Iâve not worked at all with it, and donât know where to start with it for something like this.
You do not say where you added it nor what you are actually doing. I added this line to a file in /etc/sudoers.d (file name is arbitrary) and it certainly works on Leap 15.5. When doing sudo yast2 I get YaST2 GUI. If you are using some other program, how is sudo configuration relevant then?
Interesting.
So I just tried adding those two variables to the sudoers file with visudo, and from a terminal window, I also got the YAST GUI without using --qt.
What I did was I added them to the existing env_keep string, though a separate line with += also works (just tested that).
But it definitely requires using sudo, as kdesu or gnomesu wonât use that (su not being the same as sudo).
I didnât need to use my xhost command either.
Of course not. Exporting XAUTHORITY ensures that programs started by sudo have necessary secrets to access Xserver - as long as those programs can access file to which $XAUTHORITY refers. When using sudo to run programs as root it is usually the case (but of course can be blocked by AppArmor, SELinux, namespacing etc) but not when running programs as another ânormal userâ, so using pam_xauth offers more general way to provide the same information.
1 Like
Well, if the only source of user information is LDAP (or AD) then obviously LDAP must define user ârootâ to be able to âswitch userâ to ârootâ. Or SSSD must be configured to use local user database as the second (or the primary) source of information. My understanding is that SSSD does support multiple backends.
1 Like
I did this in the default sudoers file. It currently looks as such
**Defaults always_set_home
Defaults env_reset
Defaults env_keep += "DISPLAY XAUTHORITY"
## Change env_reset to !env_reset in previous line to keep all environment variables
## Following list will no longer be necessary after this change
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE DISPLAY XAUTHORITY"
## Comment out the preceding line and uncomment the following one if you need
## to use special input methods. This may allow users to compromise the root
## account if they are allowed to run commands without authentication.
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE XMODIFIERS GTK_IM_MODULE QT_IM_MODULE QT_IM_SWITCHER DISPLAY XAUTHORITY"
## Do not insult users when they enter an incorrect password.
Defaults !insults
## Use this PATH instead of the user's to find commands.
Defaults secure_path="/usr/sbin:/usr/bin:/sbin:/bin"
##
## Uncomment to send mail if the user does not enter the correct password.
# Defaults mail_badpass
##
## Uncomment to enable logging of a command's output, except for
## sudoreplay and reboot. Use sudoreplay to play back logged sessions.
## Sudo will create up to 2,176,782,336 I/O logs before recycling them.
## Set maxseq to a smaller number if you don't have unlimited disk space.
# Defaults log_output
# Defaults!/usr/bin/sudoreplay !log_output
# Defaults!REBOOT !log_output
# Defaults maxseq = 1000
## In the default (unconfigured) configuration, sudo asks for the root password.
## This allows use of an ordinary user account for administration of a freshly
## installed system. When configuring sudo, delete the two
## following lines:
#Defaults targetpw # ask for the password of the target user i.e. root
#ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!
##
## Runas alias specification
##
##
## User privilege specification
##
root ALL=(ALL) ALL
%linuxadmins ALL=(ALL) ALL
## Uncomment to allow members of group wheel to execute any command
# %wheel ALL=(ALL:ALL) ALL
## Same thing without a password
# %wheel ALL=(ALL:ALL) NOPASSWD: ALL
## Read drop-in files from /etc/sudoers.d
@includedir /etc/sudoers.d
**
Should I have added the DISPLAY XAUTHORITY line elsewhere?
That is my understanding as well - though the configuration of multiple backends seems to not be the default for some things (like sudo) but it is for others (like authentication). It makes sense to me, tough, that sudo would be handled with a single backend rather than multiple - reconciling conflicts is easier when thereâs just one source.
You do realize that unconditional assignment later in the configuration file resets whatever value has been assigned earlier, do not you?
You added the += line to the top, and then the later environment line overrides it. Iâd just add the two variables to the end of the longer line.
Thatâs probably what the issue is.