sssd-users February 2020

sssd-users@lists.fedorahosted.org

23 participants
31 discussions

Re: sssd 1.16.4. ADV190023.
by Sumit Bose 13 Feb '20

13 Feb '20

On Thu, Feb 13, 2020 at 01:42:33PM +0000, Mote, Todd wrote: > I'll work on getting that today. This is what I know so far. > > > > Test system updated through our Satellite, so nothing special or different. Yum updated everything: > > RHEL 7.7 > > sssd-1.16.4-21.el7_7.1.x86_64 > > adcli-0.8.1-9.el7.x86_64 > > > > Domain: > > Windows Server 2016 > > regkey ldapserverintegrity=2 > > regkey ldapenforcechannelbinding=1 > > > > we splunk our domain logs and my coworker wrote a dashboard to display the entries when either simple binds or unsigned sasl occur. Over the last 24 hours my test host triggered the unsigned sasl entry 13 times. Each entry corresponds precisely to the adcli check password attempt in the logs. It doesn't log an unsigned sasl event every hour, and a couple of times not at all for several hours. I'm not sure what's behind that. Times here are UTC -6. I’m in the 7:00 hour here. The most recent entry is below. I’ll work to get a trace running by the next hour, in case it logs it again. Hi, can you try to run the following ldapsearch commands and check which one causes a message in the event log? ldapsearch -H cldap://ad-server.ADTEST.domain.com -b '' -s base '(&(DnsDomain=ADTEST.domain.com)(NtVer=\14\00\00\00))' netlogon ldapsearch -H ldap://ad-server.ADTEST.domain.com -x -b '' -s base '(&(DnsDomain=ADTEST.domain.com)(NtVer=\14\00\00\00))' netlogon ldapsearch -H ldap://ad-server.ADTEST.domain.com -x -b '' -s base kinit 'ANTI-TEST$(a)ADTEST.DOMAIN.COM' ldapsearch -H ldap://ad-server.ADTEST.domain.com -Y GSSAPI -b '' -s base kinit 'ANTI-TEST$(a)ADTEST.DOMAIN.COM' ldapsearch -H ldap://ad-server.ADTEST.domain.com -Y GSS-SPNEGO -b '' -s base bye, Sumit > > > > This behavior also happens with RHEL 8, sssd 2.2 and adcli 0.8.2. I see the same entries logged in both the sssd log on the device and the domain. > > > Timestamp<https://splunk.security.utexas.edu/en-US/app/ut_itsy-ad-monitoring/search?e…> > User Name<https://splunk.security.utexas.edu/en-US/app/ut_itsy-ad-monitoring/search?e…> > Binding Type<https://splunk.security.utexas.edu/en-US/app/ut_itsy-ad-monitoring/search?e…> > 02-13-2020 07:12:33 > ADTEST\ANTI-TEST$ > Unsigned SASL > 02-13-2020 05:12:34 > ADTEST\ANTI-TEST$ > Unsigned SASL > 02-13-2020 03:12:34 > ADTEST\ANTI-TEST$ > Unsigned SASL > 02-13-2020 02:12:35 > ADTEST\ANTI-TEST$ > Unsigned SASL > 02-13-2020 01:12:34 > ADTEST\ANTI-TEST$ > Unsigned SASL > 02-12-2020 23:12:34 > ADTEST\ANTI-TEST$ > Unsigned SASL > 02-12-2020 22:12:34 > ADTEST\ANTI-TEST$ > Unsigned SASL > 02-12-2020 19:12:34 > ADTEST\ANTI-TEST$ > Unsigned SASL > 02-12-2020 17:12:34 > ADTEST\ANTI-TEST$ > Unsigned SASL > 02-12-2020 14:12:34 > ADTEST\ANTI-TEST$ > Unsigned SASL > 02-12-2020 13:12:34 > ADTEST\ANTI-TEST$ > Unsigned SASL > 02-12-2020 09:12:35 > ADTEST\ANTI-TEST$ > Unsigned SASL > 02-12-2020 08:12:34 > ADTEST\ANTI-TEST$ > Unsigned SASL > > > > > > (Thu Feb 13 07:12:33 2020) [sssd[be[adtest.domain.com]]] [ad_machine_account_password_renewal_done] (0x1000): --- adcli output start--- > > * Found realm in keytab: ADTEST.domain.com > > * Found computer name in keytab: ANTI-TEST > > * Found service principal in keytab: host/ANTI-TEST > > * Found service principal in keytab: host/anti-test.adtest.domain.com > > * Found host qualified name in keytab: anti-test.adtest.domain.com > > * Found service principal in keytab: RestrictedKrbHost/ANTI-TEST > > * Found service principal in keytab: RestrictedKrbHost/anti-test.adtest.domain.com > > * Using fully qualified name: anti-test.adtest.domain.com > > * Using domain name: adtest.domain.com > > * Calculated computer account name from fqdn: ANTI-TEST > > * Using domain realm: adtest.domain.com > > * Sending netlogon pings to domain controller: cldap:// xxx.xxx.xxx.xxx > > * Received NetLogon info from: dc01a.adtest.domain.com > > * Wrote out krb5.conf snippet to /tmp/adcli-krb5-RCmgmC/krb5.d/adcli-krb5-conf-vPdhBf > > * Authenticated as default/reset computer account: ANTI-TEST > > * Looked up short domain name: ADTEST > > * Looked up domain SID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx > > * Using fully qualified name: anti-test.adtest.domain.com > > * Using domain name: adtest.domain.com > > * Using computer account name: ANTI-TEST > > * Using domain realm: adtest.domain.com > > * Using fully qualified name: anti-test.adtest.domain.com > > * Enrolling computer name: ANTI-TEST > > * Generated 120 character computer password > > * Using keytab: FILE:/etc/krb5.keytab > > * Found computer account for ANTI-TEST$ at: CN=ANTI-TEST,OU=Dev,OU=Linux,OU=moter,OU=ITSY-Staff,OU=ITSY,OU=Departments,DC=adtest,DC=domain,DC=com > > * Retrieved kvno '6' for computer account in directory: CN=ANTI-TEST,OU=Dev,OU=Linux,OU=moter,OU=ITSY-Staff,OU=ITSY,OU=Departments,DC=adtest,DC=domain,DC=com > > * Password not too old, no change needed > > * Sending netlogon pings to domain controller: cldap://xxx.xxx.xxx.xxx > > * Received NetLogon info from: dc01a.adtest.domain.com > > * Checking RestrictedKrbHost/anti-test.adtest.domain.com > > * Added RestrictedKrbHost/anti-test.adtest.domain.com > > * Checking host/anti-test.adtest.domain.com > > * Added host/anti-test.adtest.domain.com > > * Checking RestrictedKrbHost/ANTI-TEST > > * Added RestrictedKrbHost/ANTI-TEST > > * Checking host/ANTI-TEST > > * Added host/ANTI-TEST > > ---adcli output end--- > > > > Todd > > > > -----Original Message----- > From: Sumit Bose <sbose(a)redhat.com> > Sent: Thursday, February 13, 2020 1:36 AM > To: sssd-users(a)lists.fedorahosted.org > Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023. > > > > On Wed, Feb 12, 2020 at 01:11:14PM +0000, Mote, Todd wrote: > > > Sumit > > > > > > Any idea on when your SASL/GSS-SPNEGO patch for adcli might make it downstream? It seems that adcli is checking once an hour on the age of the password and is the only thing left on my test hosts that is triggering the Unsigned SASL event on our domain controllers. I have tinkered with the GSSAPI and other settings in ldap.conf, so none of the connections are simple, just unsigned, which isn't terrible, but it'd be nice to eliminate them altogether, ya know? > > > > Hi, > > > > they are planned for the next RHEL releases and I'm about to prepare Fedora packages. > > > > I did some tests with older RHEL7 versions and didn't come across issues even with only SASL/GSSAPI when I enforce channel binding and LDAP signing on AD. Would it be possible to send a network trace which covers the connection attempt of adcli which causes the issue? > > > > bye, > > Sumit > > > > > > > > Todd > > > > > > -----Original Message----- > > > From: Sumit Bose <sbose(a)redhat.com<mailto:sbose@redhat.com>> > > > Sent: Thursday, February 6, 2020 10:18 AM > > > To: sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.org> > > > Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023. > > > > > > On Thu, Feb 06, 2020 at 03:05:13PM +0000, Ondrej Valousek wrote: > > > > did you try refreshing the machine password in AD?Looks like it's too old. > > > > O. > > > > ________________________________ > > > > From: David David <modrik(a)seznam.cz<mailto:modrik@seznam.cz>> > > > > Sent: Thursday, February 6, 2020 12:09 PM > > > > To: sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.org> > > > > <sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.org>> > > > > Subject: [SSSD-users] sssd 1.16.4. ADV190023. > > > > > > > > Hello, > > > > i guess that you probably heard about ADV190023. Our AD admin told me that linux servers which are under my responsibility send an unsigned request to AD, what could be a problem related to this incomming Ad patch: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.m…p;reserved=0. > > > > > > > > I am using sssd in "sssd-ad mode." The communication between a linux servers and our AD is crypted by kerberos, so this should be ok. > > > > > > > > I found only one kind of request which could result in potential failure. After mentioned patching implementation. See please below: > > > > > > > > (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] [be_ptask_execute] (0x0400): > > > > Task [AD machine account password renewal]: executing task, timeout > > > > 60 seconds (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] [be_ptask_done] > > > > (0x0400): Task [AD machine account password renewal]: finished > > > > successfully (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] > > > > [be_ptask_schedule] (0x0400): Task [AD machine account password > > > > renewal]: scheduling task 86400 seconds from last > > > > > > Hi, > > > > > > Ondrej is right, those messages are related to adcli trying to update > > > the machine account password if it is too old. To check when the > > > password was last updated adcli uses LDAP with SASL/GSSAPI. I've added > > > a patch so that SASL/GSS-SPNEGO is used when it is available in the AD > > > DC side > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl > > > ab.freedesktop.org%2Frealmd%2Fadcli%2Fcommit%2Fa6f795ba3d6048b32d78634 > > > 68688bf7f42b2cafd&data=02%7C01%7Cmoter%40austin.utexas.edu%7C87719 > > > 229ad54467ff98808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1 > > > %7C637171761658405405&sdata=rPcG9mknHufVZUy6ege6n2vx%2B1Hy5XQhDn7H > > > 8ugqlzA%3D&reserved=0 With SASL/GSS-SPNEGO all requirements are > > > negotiated automatically and signing should be switched on if required. > > > > > > With SASL/GSSAPI you might be able to tune this manually, see e.g. the SASL and GSSAPI options in man ldap.conf for details. > > > > > > There is also a patch for adcli which tells adcli to use ldaps > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl > > > ab.freedesktop.org%2Frealmd%2Fadcli%2Fcommit%2F85097245b57f190337225db > > > dbf6e33b58616c092&data=02%7C01%7Cmoter%40austin.utexas.edu%7C87719 > > > 229ad54467ff98808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1 > > > %7C637171761658405405&sdata=9dY6eOGTKimEYqydWbRFROldOTNRM16t1caeUh > > > bBTiY%3D&reserved=0 but this is currently not used by SSSD. And in > > > general I think using GSS-SPNEGO is sufficient since there is no requirement to switch to ldaps (if I read the advisory correctly) and AD does not enable ldaps by default as well. > > > > > > bye, > > > Sumit > > > > > > > > > > > Everytime, this task is executed, our AD write into its log that an unsighned request came from my linux server. I tried to set ldap_tls_cert and ldap_tls_key into sssd.conf which point to the cert and key generated by our AD, but without success. > > > > > > > > I tried to find a proper solution how to sign the request that AD stop complaining, but nothing usefull found. > > > > > > > > My question is. Should I be affraid that after the patching, our AD will stop to communicate with my linux servers? > > > > > > > > Really thanks in advance for your answer. I really appreciate your effort. > > > > _______________________________________________ > > > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.org> To > > > > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@lists.fedorahosted.org> > > > > Fedora Code of Conduct: > > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdo > > > > cs > > > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=0 > > > > 2% > > > > 7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2% > > > > 7C > > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&sd > > > > at > > > > a=v3APmwlHF3i9zi1WE950DEAqCMJCirnyPC4YyF2xJPQ%3D&reserved=0 > > > > List Guidelines: > > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffe > > > > do > > > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmo > > > > te > > > > r%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5b > > > > dd > > > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&sdata=QUgcpi8 > > > > 2T > > > > TRy7qanAkjRey8ZpC2GDy7%2BJ7yXeOrtb8I%3D&reserved=0 > > > > List Archives: > > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > > > st > > > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahost > > > > ed > > > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2 > > > > ae > > > > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C63716602 > > > > 75 > > > > 07314661&sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2Bx4%3 > > > > D& > > > > amp;reserved=0 > > > > > > > _______________________________________________ > > > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.org> To > > > > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@lists.fedorahosted.org> > > > > Fedora Code of Conduct: > > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdo > > > > cs > > > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=0 > > > > 2% > > > > 7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2% > > > > 7C > > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&sd > > > > at > > > > a=b%2Fu1IXQ%2F42XEq3c6DYwzTyYno4azJb3qvUtPiZmOdrc%3D&reserved=0 > > > > List Guidelines: > > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffe > > > > do > > > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmo > > > > te > > > > r%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5b > > > > dd > > > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&sdata=CIJal5z > > > > 4E > > > > nNOIQFsuveKmlEK1wMzIx79ZaXavinrtsk%3D&reserved=0 > > > > List Archives: > > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > > > st > > > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahost > > > > ed > > > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2 > > > > ae > > > > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C63716602 > > > > 75 > > > > 07314661&sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2Bx4%3 > > > > D& > > > > amp;reserved=0 > > > _______________________________________________ > > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.org> To > > > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@lists.fedorahosted.org> > > > Fedora Code of Conduct: > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=02% > > > 7C01%7Cmoter%40austin.utexas.edu%7C87719229ad54467ff98808d7b0576033%7C > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sdat > > > a=CY5%2B8lrh6B9UIqXNYXSzpIyeRI93sHge9cuKB8KDBdk%3D&reserved=0 > > > List Guidelines: > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo > > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmote > > > r%40austin.utexas.edu%7C87719229ad54467ff98808d7b0576033%7C31d7e2a5bdd > > > 8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sdata=uFxkGT3GV > > > Y3moV7TxfDo%2BNHyz%2B8AUbVpApIxs3PTmzs%3D&reserved=0 > > > List Archives: > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted > > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C87719229ad54467ff9 > > > 8808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C6371717616 > > > 58415397&sdata=qZHqxPWZzftm51GK%2F29gM3NM9f5QnsoRQE2kqWGs3Os%3D&am > > > p;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 -- sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.org> To > > > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@lists.fedorahosted.org> > > > Fedora Code of Conduct: > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=02% > > > 7C01%7Cmoter%40austin.utexas.edu%7C87719229ad54467ff98808d7b0576033%7C > > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sdat > > > a=CY5%2B8lrh6B9UIqXNYXSzpIyeRI93sHge9cuKB8KDBdk%3D&reserved=0 > > > List Guidelines: > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo > > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmote > > > r%40austin.utexas.edu%7C87719229ad54467ff98808d7b0576033%7C31d7e2a5bdd > > > 8414e9e97bea998ebdfe1%7C1%7C1%7C637171761658415397&sdata=uFxkGT3GV > > > Y3moV7TxfDo%2BNHyz%2B8AUbVpApIxs3PTmzs%3D&reserved=0 > > > List Archives: > > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted > > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7C87719229ad54467ff9 > > > 8808d7b0576033%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C1%7C6371717616 > > > 58415397&sdata=qZHqxPWZzftm51GK%2F29gM3NM9f5QnsoRQE2kqWGs3Os%3D&am > > > p;reserved=0 > > _______________________________________________ > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.org> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org<mailto:sssd-users-leave@lists.fedorahosted.org> > > Fedora Code of Conduct: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedo… > > List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > > List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… > > >> This message is from an external sender. Learn more about why this << > > >> matters at https://links.utexas.edu/rtyclf. << > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > 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/sssd-users@lists.fedorahosted.…

2 2

Re: sssd 1.16.4. ADV190023.
by Sumit Bose 13 Feb '20

13 Feb '20

On Wed, Feb 12, 2020 at 01:11:14PM +0000, Mote, Todd wrote: > Sumit > > Any idea on when your SASL/GSS-SPNEGO patch for adcli might make it downstream? It seems that adcli is checking once an hour on the age of the password and is the only thing left on my test hosts that is triggering the Unsigned SASL event on our domain controllers. I have tinkered with the GSSAPI and other settings in ldap.conf, so none of the connections are simple, just unsigned, which isn't terrible, but it'd be nice to eliminate them altogether, ya know? Hi, they are planned for the next RHEL releases and I'm about to prepare Fedora packages. I did some tests with older RHEL7 versions and didn't come across issues even with only SASL/GSSAPI when I enforce channel binding and LDAP signing on AD. Would it be possible to send a network trace which covers the connection attempt of adcli which causes the issue? bye, Sumit > > Todd > > -----Original Message----- > From: Sumit Bose <sbose(a)redhat.com> > Sent: Thursday, February 6, 2020 10:18 AM > To: sssd-users(a)lists.fedorahosted.org > Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023. > > On Thu, Feb 06, 2020 at 03:05:13PM +0000, Ondrej Valousek wrote: > > did you try refreshing the machine password in AD?Looks like it's too old. > > O. > > ________________________________ > > From: David David <modrik(a)seznam.cz> > > Sent: Thursday, February 6, 2020 12:09 PM > > To: sssd-users(a)lists.fedorahosted.org > > <sssd-users(a)lists.fedorahosted.org> > > Subject: [SSSD-users] sssd 1.16.4. ADV190023. > > > > Hello, > > i guess that you probably heard about ADV190023. Our AD admin told me that linux servers which are under my responsibility send an unsigned request to AD, what could be a problem related to this incomming Ad patch: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.m…p;reserved=0. > > > > I am using sssd in "sssd-ad mode." The communication between a linux servers and our AD is crypted by kerberos, so this should be ok. > > > > I found only one kind of request which could result in potential failure. After mentioned patching implementation. See please below: > > > > (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] [be_ptask_execute] (0x0400): > > Task [AD machine account password renewal]: executing task, timeout 60 > > seconds (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] [be_ptask_done] > > (0x0400): Task [AD machine account password renewal]: finished > > successfully (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] > > [be_ptask_schedule] (0x0400): Task [AD machine account password > > renewal]: scheduling task 86400 seconds from last > > Hi, > > Ondrej is right, those messages are related to adcli trying to update the machine account password if it is too old. To check when the password was last updated adcli uses LDAP with SASL/GSSAPI. I've added a patch so that SASL/GSS-SPNEGO is used when it is available in the AD DC side > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.fr… > With SASL/GSS-SPNEGO all requirements are negotiated automatically and signing should be switched on if required. > > With SASL/GSSAPI you might be able to tune this manually, see e.g. the SASL and GSSAPI options in man ldap.conf for details. > > There is also a patch for adcli which tells adcli to use ldaps > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.fr… > but this is currently not used by SSSD. And in general I think using GSS-SPNEGO is sufficient since there is no requirement to switch to ldaps (if I read the advisory correctly) and AD does not enable ldaps by default as well. > > bye, > Sumit > > > > > Everytime, this task is executed, our AD write into its log that an unsighned request came from my linux server. I tried to set ldap_tls_cert and ldap_tls_key into sssd.conf which point to the cert and key generated by our AD, but without success. > > > > I tried to find a proper solution how to sign the request that AD stop complaining, but nothing usefull found. > > > > My question is. Should I be affraid that after the patching, our AD will stop to communicate with my linux servers? > > > > Really thanks in advance for your answer. I really appreciate your effort. > > _______________________________________________ > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To > > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > > Fedora Code of Conduct: > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=02% > > 7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&sdat > > a=v3APmwlHF3i9zi1WE950DEAqCMJCirnyPC4YyF2xJPQ%3D&reserved=0 > > List Guidelines: > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmote > > r%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5bdd > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&sdata=QUgcpi82T > > TRy7qanAkjRey8ZpC2GDy7%2BJ7yXeOrtb8I%3D&reserved=0 > > List Archives: > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2ae > > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6371660275 > > 07314661&sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2Bx4%3D& > > amp;reserved=0 > > > _______________________________________________ > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To > > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > > Fedora Code of Conduct: > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=02% > > 7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&sdat > > a=b%2Fu1IXQ%2F42XEq3c6DYwzTyYno4azJb3qvUtPiZmOdrc%3D&reserved=0 > > List Guidelines: > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmote > > r%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5bdd > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&sdata=CIJal5z4E > > nNOIQFsuveKmlEK1wMzIx79ZaXavinrtsk%3D&reserved=0 > > List Archives: > > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted > > .org&data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2ae > > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6371660275 > > 07314661&sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2Bx4%3D& > > amp;reserved=0 > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedo… > List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… > >> This message is from an external sender. Learn more about why this << > >> matters at https://links.utexas.edu/rtyclf. << > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > 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/sssd-users@lists.fedorahosted.…

2 1

Re: sssd 1.16.4. ADV190023.
by Sumit Bose 13 Feb '20

13 Feb '20

On Mon, Feb 10, 2020 at 12:17:22PM +0000, Ondrej Valousek wrote: > Hmm, > The solution with ldap_uri=ldaps://.... is bit ugly and personally I wonder that it works (unless you used public CA to sign AD connections which is, I'd say, quite rare to see) because normally to do that you need to import AD certs. > I guess sssd developers could shed some light into it as I'm not sure either. Hi, you are right, I would recommend to stay with 'id_provider = ad' and use the default LDAP port 389. SSSD uses a SASL bind with GSSAPI in this configuration and as long as the SASL security strength factor (SSF) is higher than 1 in integrity requirement from AD (LDAP signing) should be satisfied. I did some tests yesterday again with some older versions of RHEL7 and AD where channel binding and LDAP signing were required by registry settings as recommended by Microsoft and didn't run into issues with the default SSSD configuration on this platform. If you are seeing issues, it would be nice if you can send some network traces covering the LDAP connections causing the issue or warning on AD. Thanks. bye, Sumit > > Ondra > ________________________________ > From: David David <modrik(a)seznam.cz> > Sent: Thursday, February 6, 2020 5:20 PM > To: sssd-users(a)lists.fedorahosted.org <sssd-users(a)lists.fedorahosted.org> > Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023. > > Ahoj Ondro, > well my knowledge about sssd is limited, but I would say that the daemon did it instead me. See the middle message: > Task [AD machine account password renewal]: finished successfully > > This task is by default scheduled after restart of sssd service always. > > However, I probably found another way how to stay safe after AD patching - I have switched from id_provider = ad, to id_provider = ldap, that allowed me to specify ldap_uri = ldaps://our_ad_machine.domain. After restart sssd AD has stopped complaing about unsighned request, because all communication is handled over TSL 1.2. > > But I am still curious if there is another solution in case that I would like to keep the setting in mode id_provider = ad. Is there any way to sighn this kind of request? We were affraid that AD will refuse all unsigned communication after the AD patch is applied. > > Thanks a lot for your knowledge sharing :) > > > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedo… > List Guidelines: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > List Archives: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > 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/sssd-users@lists.fedorahosted.…

1 0

Re: sssd 1.16.4. ADV190023.
by Sumit Bose 12 Feb '20

12 Feb '20

On Thu, Feb 06, 2020 at 03:05:13PM +0000, Ondrej Valousek wrote: > did you try refreshing the machine password in AD?Looks like it's too old. > O. > ________________________________ > From: David David <modrik(a)seznam.cz> > Sent: Thursday, February 6, 2020 12:09 PM > To: sssd-users(a)lists.fedorahosted.org <sssd-users(a)lists.fedorahosted.org> > Subject: [SSSD-users] sssd 1.16.4. ADV190023. > > Hello, > i guess that you probably heard about ADV190023. Our AD admin told me that linux servers which are under my responsibility send an unsigned request to AD, what could be a problem related to this incomming Ad patch: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.m…p;reserved=0. > > I am using sssd in "sssd-ad mode." The communication between a linux servers and our AD is crypted by kerberos, so this should be ok. > > I found only one kind of request which could result in potential failure. After mentioned patching implementation. See please below: > > (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] [be_ptask_execute] (0x0400): Task [AD machine account password renewal]: executing task, timeout 60 seconds > (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] [be_ptask_done] (0x0400): Task [AD machine account password renewal]: finished successfully > (Wed Feb 5 16:57:21 2020) [sssd[be[AD]]] [be_ptask_schedule] (0x0400): Task [AD machine account password renewal]: scheduling task 86400 seconds from last Hi, Ondrej is right, those messages are related to adcli trying to update the machine account password if it is too old. To check when the password was last updated adcli uses LDAP with SASL/GSSAPI. I've added a patch so that SASL/GSS-SPNEGO is used when it is available in the AD DC side https://gitlab.freedesktop.org/realmd/adcli/commit/a6f795ba3d6048b32d786346… With SASL/GSS-SPNEGO all requirements are negotiated automatically and signing should be switched on if required. With SASL/GSSAPI you might be able to tune this manually, see e.g. the SASL and GSSAPI options in man ldap.conf for details. There is also a patch for adcli which tells adcli to use ldaps https://gitlab.freedesktop.org/realmd/adcli/commit/85097245b57f190337225dbd… but this is currently not used by SSSD. And in general I think using GSS-SPNEGO is sufficient since there is no requirement to switch to ldaps (if I read the advisory correctly) and AD does not enable ldaps by default as well. bye, Sumit > > Everytime, this task is executed, our AD write into its log that an unsighned request came from my linux server. I tried to set ldap_tls_cert and ldap_tls_key into sssd.conf which point to the cert and key generated by our AD, but without success. > > I tried to find a proper solution how to sign the request that AD stop complaining, but nothing usefull found. > > My question is. Should I be affraid that after the patching, our AD will stop to communicate with my linux servers? > > Really thanks in advance for your answer. I really appreciate your effort. > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedo… > List Guidelines: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > List Archives: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > 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/sssd-users@lists.fedorahosted.…

2 1

Re: sssd 1.16.4. ADV190023.
by David David 10 Feb '20

10 Feb '20

Ahoj Ondro, well my knowledge about sssd is limited, but I would say that the daemon did it instead me. See the middle message: Task [AD machine account password renewal]: finished successfully This task is by default scheduled after restart of sssd service always. However, I probably found another way how to stay safe after AD patching - I have switched from id_provider = ad, to id_provider = ldap, that allowed me to specify ldap_uri = ldaps://our_ad_machine.domain. After restart sssd AD has stopped complaing about unsighned request, because all communication is handled over TSL 1.2. But I am still curious if there is another solution in case that I would like to keep the setting in mode id_provider = ad. Is there any way to sighn this kind of request? We were affraid that AD will refuse all unsigned communication after the AD patch is applied. Thanks a lot for your knowledge sharing :)

2 1

Stored copy of corrupted mmap cache in file ’/var/lib/sss/mc/group_corrupted#012’
by Tom 10 Feb '20

10 Feb '20

Is there a way to analyze the corrupted cache file to identify which group or user triggered the message? I'm interested in finding out what triggered this. Cheers, Tom Sent from my iPhone

2 1

Re: ldap_id_mapping=False then AD user's password not availabe
by James Cassell 07 Feb '20

07 Feb '20

On Thu, Feb 6, 2020, at 9:13 PM, Grant Longhurst wrote: > > Out of interest how did you solve it as have the same issue? > I don't see the referenced mail since you didn't quote it, but usually, you need both a uidNumber and gidNumber defined for each user to work everywhere including older sssd version if you're using the ldap_id_mapping=False setting. V/r, James Cassell

1 0

Re: ldap_id_mapping=False then AD user's password not availabe
by Grant Longhurst 06 Feb '20

06 Feb '20

Out of interest how did you solve it as have the same issue?

1 0

Re: Resolving User Groups - SSSD AD
by Sumit Bose 06 Feb '20

06 Feb '20

On Thu, Feb 06, 2020 at 01:40:46PM +0000, Sangster, Mark wrote: > Hello, > > I am switching our SSSD to use the AD provider but have found that the setup has issues with group membership. > > The following is my domain configuration: > > [domain/<DOMAIN>] > id_provider = ad > auth_provider = ad > access_provider = ad > ad_access_filter = (memberOf=<FILTER>) > ad_hostname = <CLIENT_HOST> > ad_domain = <DOMAIN> > dns_discovery_domain = <DOMAIN> > ldap_id_mapping = false > ldap_sasl_mech = GSSAPI > ldap_referrals = false > dyndns_update = false > cache_credentials = true > enumerate = false > ldap_purge_cache_timeout = 0 > > This setup works just not completely, user authentication and user/group lookups work. However if I attempt to list full group membership of a user (“id user” or “groups user”), then I am provided with only the primary group. Interestingly if I do the following: clear user from cache, lookup group, lookup user, then the information indicates the primary group and additional group. > We utilise an AllowGroups restriction within SSHD which fails, claiming the user isn’t in the group. Hi, what version of SSSD are you using on which platform? It would be best to have debug logs. For this please add 'debug_level = 9' to the [domain/...] and [nss] section of sssd.conf, restart SSSD and call 'id user' again. You can find more details at https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html. Since you are using 'ldap_id_mapping = false' it might be worth to try to disable the Global Catalog lookups by adding 'ad_enable_gc = false' to the [domain/...] section of sssd.conf. bye, Sumit > > Any suggests would be welcome. > > Thanks > Mark > > ------------------------------------------------------------------------ > Mark Sangster > Server Infrastructure Specialist > > Information Technology Services | University of Aberdeen > t: +44 (0)1224 27-3315 | e: mark(a)abdn.ac.uk<mailto:mark@abdn.ac.uk> | u: http://www.abdn.ac.uk/it/ > > > The University of Aberdeen is a charity registered in Scotland, No SC013683. > Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir. SC013683. > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > 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/sssd-users@lists.fedorahosted.…

1 0

Resolving User Groups - SSSD AD
by Sangster, Mark 06 Feb '20

06 Feb '20

Hello, I am switching our SSSD to use the AD provider but have found that the setup has issues with group membership. The following is my domain configuration: [domain/<DOMAIN>] id_provider = ad auth_provider = ad access_provider = ad ad_access_filter = (memberOf=<FILTER>) ad_hostname = <CLIENT_HOST> ad_domain = <DOMAIN> dns_discovery_domain = <DOMAIN> ldap_id_mapping = false ldap_sasl_mech = GSSAPI ldap_referrals = false dyndns_update = false cache_credentials = true enumerate = false ldap_purge_cache_timeout = 0 This setup works just not completely, user authentication and user/group lookups work. However if I attempt to list full group membership of a user (“id user” or “groups user”), then I am provided with only the primary group. Interestingly if I do the following: clear user from cache, lookup group, lookup user, then the information indicates the primary group and additional group. We utilise an AllowGroups restriction within SSHD which fails, claiming the user isn’t in the group. Any suggests would be welcome. Thanks Mark ------------------------------------------------------------------------ Mark Sangster Server Infrastructure Specialist Information Technology Services | University of Aberdeen t: +44 (0)1224 27-3315 | e: mark(a)abdn.ac.uk<mailto:mark@abdn.ac.uk> | u: http://www.abdn.ac.uk/it/ The University of Aberdeen is a charity registered in Scotland, No SC013683. Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir. SC013683.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users February 2020