Re: sssd upgrade from 2.2.3-20 to 2.3.0-9 breaks sudo

[Alexey Tikhonov]

On Mon, Nov 30, 2020 at 9:37 PM Mote, Todd  wrote:
> > Could you please set "debug_level = 9" in "[sudo]" section of /etc/sssd.conf, restart sssd and provide /var/log/sssd_sudo.log (sanitized if needed)?
>
> Here ya go.

[sbus_dbus_request_name] (0x0020): Unable to request name on the system bus [3]
This error code (3) stands for `DBUS_RELEASE_NAME_REPLY_NOT_OWNER ` here.
This is expected if you didn't disable systemd sssd-sudo service.

Did you have it enabled when you upgraded?
> I did verify on a clean install that only removing "sudo" as a service from the sssd.conf file does in fact allow it to work again.  Enabling the socket does not seem to be required.
>
> Todd
>
> -----Original Message-----
> From: Alexey Tikhonov 
> Sent: Monday, November 30, 2020 1:58 PM
> To: End-user discussions about the System Security Services Daemon 
> Subject: [SSSD-users] Re: sssd upgrade from 2.2.3-20 to 2.3.0-9 breaks sudo
>
> On Mon, Nov 30, 2020 at 8:43 PM Mote, Todd  wrote:
> > Hi all
> >
> > I updated my RHEL 8 test box today and got sssd-2.3.0-9.el8.x86_64 as an update from sssd-2.2.3-20.el8.x86_64.  Prior to the upgrade everything worked fine.  Immediately after upgrade sssd fails to restart the critical service [sudo], and fails to start sssd at all, as noted in journalctl -xe.
>
> Could you please set "debug_level = 9" in "[sudo]" section of /etc/sssd.conf, restart sssd and provide /var/log/sssd_sudo.log (sanitized if needed)?
> > Are there things that needs to be done to affect a successful upgrade from 2.2.3 to 2.3.0?  a conf file change perhaps?  I saw mentions of “required conf file changes” in other issues reported in github.
> >
> > Downgrading back to 2.2.3 and removing the database returns sssd to starting and working.
> >
> > Removing “sudo” as a service from sssd.conf allows sssd to start with 2.3.0-9 installed.
> >
> > I attempted to use “systemctl enable sssd-sudo” like the man page suggests and the result in the journal is “Dependency failed for SSSD Sudo Service responder socket.”
> >
> > I also noted this in the sssd-sudo man page:  “It's important to note
> > that on platforms where systemd is supported there's no need to add
> > the "sudo" provider
> >    to the list of services, as it became optional. However, sssd-sudo.socket must be enabled instead.”
> >
> > having enabled the sockect and removed “sudo” from the list of services, it does seem to work and retrieve rules from AD for the user.
> >
> > Is all of this correct?  Is removing “sudo” as a service the answer to this or is it just a workaround?  If it is the solution, is there any documentation about changes to configurations from version to version like sudo no longer allowing the service to start if it’s explicitly listed as a service?
> >
> > Just trying to figure out the scope of what will need to change on my fleet.  The evidence so far seems to point to just removing “sudo” as a service in sssd.conf.  Is that enough?  Should “systemctl enable sssd-sudo” be run as well?
> >
> > Thanks in advance for your insights.
> >
> > Todd
> >
> > sssd-users mailing list -- [e-mail] To
> > unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=04%
> > 7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%7C
> > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnknow
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > JXVCI6Mn0%3D%7C1000&sdata=oceNDHl05MPSDYn52tAb5Mnsqb0bnHKlAO1tpoaU
> > hrE%3D&reserved=0 List Guidelines:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> > raproject.org%2Fwiki%2FMailing_list_guidelines&data=04%7C01%7Cmote
> > r%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%7C31d7e2a5bdd
> > 8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnknown%7CTWFpbGZ
> > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > D%7C1000&sdata=WbMFjIprD%2BbYocMn0uoTgOscDL%2Fp4jlH7icPneGL3v8%3D&
> > amp;reserved=0 List Archives:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted
> > .org&data=04%7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c460005
> > a208d8956a3d92%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6374236308
> > 15484265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Yl5fnjkNmK37oRoQFQhA1Sj
> > XigQNO0orE4IY%2FRe%2FjgA%3D&reserved=0
>
> sssd-users mailing list -- [e-mail] To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedor...
> List Guidelines: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproj...
> List Archives: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedo...
> > > This message is from an external sender. Learn more about why this <<
> > > matters at https://links.utexas.edu/rtyclf.                        <<
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/[e-mail].o...

sssd upgrade from 2.2.3-20 to 2.3.0-9 breaks sudo

[Mote, Todd]

We have an in-house created rpm that sets up everything needed for sssd, krb, the conf file, etc. due to having all the way from rhel6 to rhel 8 in our environment, and the rpm requires sssd >= 1.14 I think.  RHEL 8 installs sssd 2.2.3, sets up everything, adds all the files and all the paths for sudo to the cond files, etc., does the join, then at the end of the kickstart it does yum update and upgrades it to 2.3.0, and the system, after deployment, leaves sssd not working.

This is how it looks just after deployment
> systemctl status sssd-sudo

● sssd-sudo.service - SSSD Sudo Service responder
   Loaded: loaded (/usr/lib/systemd/system/sssd-sudo.service; indirect; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:sssd.conf(5)
           man:sssd-sudo(5)

so seems to be disabled, but loaded?

At this point, I can either downgrade to sssd 2.2.3, remove the db, and restart sssd, making no other changes, and sssd 2.2.3 loads and works as I expect it to

Or

I can edit sssd.conf and remove sudo as a service, remove the db, and restart sssd, making no other changes, and sssd 2.3.0 loads and works as I expect it to.

Todd

-----Original Message-----
From: Alexey Tikhonov  
Sent: Monday, November 30, 2020 2:52 PM
To: End-user discussions about the System Security Services Daemon 
Subject: [SSSD-users] Re: sssd upgrade from 2.2.3-20 to 2.3.0-9 breaks sudo

On Mon, Nov 30, 2020 at 9:37 PM Mote, Todd  wrote:
> > Could you please set "debug_level = 9" in "[sudo]" section of /etc/sssd.conf, restart sssd and provide /var/log/sssd_sudo.log (sanitized if needed)?
>
> Here ya go.

[sbus_dbus_request_name] (0x0020): Unable to request name on the system bus [3] This error code (3) stands for `DBUS_RELEASE_NAME_REPLY_NOT_OWNER ` here.
This is expected if you didn't disable systemd sssd-sudo service.

Did you have it enabled when you upgraded?
> I did verify on a clean install that only removing "sudo" as a service from the sssd.conf file does in fact allow it to work again.  Enabling the socket does not seem to be required.
>
> Todd
>
> -----Original Message-----
> From: Alexey Tikhonov 
> Sent: Monday, November 30, 2020 1:58 PM
> To: End-user discussions about the System Security Services Daemon 
>
> Subject: [SSSD-users] Re: sssd upgrade from 2.2.3-20 to 2.3.0-9 breaks 
> sudo
>
> On Mon, Nov 30, 2020 at 8:43 PM Mote, Todd  wrote:
> > Hi all
> >
> > I updated my RHEL 8 test box today and got sssd-2.3.0-9.el8.x86_64 as an update from sssd-2.2.3-20.el8.x86_64.  Prior to the upgrade everything worked fine.  Immediately after upgrade sssd fails to restart the critical service [sudo], and fails to start sssd at all, as noted in journalctl -xe.
>
> Could you please set "debug_level = 9" in "[sudo]" section of /etc/sssd.conf, restart sssd and provide /var/log/sssd_sudo.log (sanitized if needed)?
> > Are there things that needs to be done to affect a successful upgrade from 2.2.3 to 2.3.0?  a conf file change perhaps?  I saw mentions of “required conf file changes” in other issues reported in github.
> >
> > Downgrading back to 2.2.3 and removing the database returns sssd to starting and working.
> >
> > Removing “sudo” as a service from sssd.conf allows sssd to start with 2.3.0-9 installed.
> >
> > I attempted to use “systemctl enable sssd-sudo” like the man page suggests and the result in the journal is “Dependency failed for SSSD Sudo Service responder socket.”
> >
> > I also noted this in the sssd-sudo man page:  “It's important to 
> > note that on platforms where systemd is supported there's no need to 
> > add the "sudo" provider
> >    to the list of services, as it became optional. However, sssd-sudo.socket must be enabled instead.”
> >
> > having enabled the sockect and removed “sudo” from the list of services, it does seem to work and retrieve rules from AD for the user.
> >
> > Is all of this correct?  Is removing “sudo” as a service the answer to this or is it just a workaround?  If it is the solution, is there any documentation about changes to configurations from version to version like sudo no longer allowing the service to start if it’s explicitly listed as a service?
> >
> > Just trying to figure out the scope of what will need to change on my fleet.  The evidence so far seems to point to just removing “sudo” as a service in sssd.conf.  Is that enough?  Should “systemctl enable sssd-sudo” be run as well?
> >
> > Thanks in advance for your insights.
> >
> > Todd
> >
> > sssd-users mailing list -- [e-mail] To 
> > unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdo
> > cs 
> > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=0
> > 4% 
> > 7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%
> > 7C 
> > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnkn
> > ow 
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> > LC 
> > JXVCI6Mn0%3D%7C1000&sdata=oceNDHl05MPSDYn52tAb5Mnsqb0bnHKlAO1tpo
> > aU
> > hrE%3D&reserved=0 List Guidelines:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffe
> > do 
> > raproject.org%2Fwiki%2FMailing_list_guidelines&data=04%7C01%7Cmo
> > te 
> > r%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%7C31d7e2a5b
> > dd 
> > 8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnknown%7CTWFpb
> > GZ
> > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > %3 
> > D%7C1000&sdata=WbMFjIprD%2BbYocMn0uoTgOscDL%2Fp4jlH7icPneGL3v8%3
> > D&
> > amp;reserved=0 List Archives:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> > st 
> > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahost
> > ed
> > .org&data=04%7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c4600
> > 05
> > a208d8956a3d92%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C63742363
> > 08 
> > 15484265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> > iL 
> > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Yl5fnjkNmK37oRoQFQhA1
> > Sj
> > XigQNO0orE4IY%2FRe%2FjgA%3D&reserved=0
>
> sssd-users mailing list -- [e-mail] To 
> unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=04%
> 7C01%7Cmoter%40austin.utexas.edu%7C97c6c3a3314b4db7b1f908d89571dbb0%7C
> 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423663534337090%7CUnknow
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> JXVCI6Mn0%3D%7C1000&sdata=4cEksddCWG1FE2grSho5Rq1D8ozAvpYots4l5W1P
> YZU%3D&reserved=0 List Guidelines: 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> raproject.org%2Fwiki%2FMailing_list_guidelines&data=04%7C01%7Cmote
> r%40austin.utexas.edu%7C97c6c3a3314b4db7b1f908d89571dbb0%7C31d7e2a5bdd
> 8414e9e97bea998ebdfe1%7C1%7C0%7C637423663534337090%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C1000&sdata=B%2FMEGD4j2%2Ba9L0DJPhZVtAZqcff6lX5%2BqmwTCBLLEAw%3
> D&reserved=0 List Archives: 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted
> .org&data=04%7C01%7Cmoter%40austin.utexas.edu%7C97c6c3a3314b4db7b1
> f908d89571dbb0%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6374236635
> 34347089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sH3ponuPgAATyTVWPnuJLkF
> Z1aLkDfPpF2ViYV7ig2E%3D&reserved=0
> > > This message is from an external sender. Learn more about why this <<
> > > matters at https://links.utexas.edu/rtyclf.                        <<
>
> sssd-users mailing list -- [e-mail] To 
> unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&amp;data=04%
> 7C01%7Cmoter%40austin.utexas.edu%7C97c6c3a3314b4db7b1f908d89571dbb0%7C
> 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423663534347089%7CUnknow
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> JXVCI6Mn0%3D%7C1000&amp;sdata=Y42vA1NdOaa5NAH3j3YanIsN5TAyKjMrNSsBH8OZ
> Hn4%3D&amp;reserved=0 List Guidelines: 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> raproject.org%2Fwiki%2FMailing_list_guidelines&amp;data=04%7C01%7Cmote
> r%40austin.utexas.edu%7C97c6c3a3314b4db7b1f908d89571dbb0%7C31d7e2a5bdd
> 8414e9e97bea998ebdfe1%7C1%7C0%7C637423663534347089%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C1000&amp;sdata=NdyTXynsAzON%2B2bgwkLzn2vQ%2BuFXAYwVab7RBgEeHqE%3D&
> amp;reserved=0 List Archives: 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted
> .org&amp;data=04%7C01%7Cmoter%40austin.utexas.edu%7C97c6c3a3314b4db7b1
> f908d89571dbb0%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6374236635
> 34347089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=sH3ponuPgAATyTVWPnuJLkF
> Z1aLkDfPpF2ViYV7ig2E%3D&amp;reserved=0

_______________________________________________
sssd-users mailing list -- [e-mail] To unsubscribe send an email to [e-mail]
Fedora Code of Conduct: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedor...
List Guidelines: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproj...
List Archives: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedo...
> > This message is from an external sender. Learn more about why this <<
> > matters at https://links.utexas.edu/rtyclf.                        <<