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 <[email protected]> 
> Sent: Thursday, February 6, 2020 10:18 AM
> To: [email protected]
> 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 <[email protected]>
> > Sent: Thursday, February 6, 2020 12:09 PM
> > To: [email protected] 
> > <[email protected]>
> > 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.microsoft.com%2Fen-us%2Fhelp%2F4520412%2F2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows&amp;data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&amp;sdata=mOMOGpy%2Ba6mP8LSgtdcKob%2FvNSees%2BR8cTNBYtaYEaM%3D&amp;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.freedesktop.org%2Frealmd%2Fadcli%2Fcommit%2Fa6f795ba3d6048b32d7863468688bf7f42b2cafd&amp;data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&amp;sdata=cqlfhhdRVQSoYYY%2BqP0qhkoiWrZMcCwHO8xso6a7hSM%3D&amp;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%2Fgitlab.freedesktop.org%2Frealmd%2Fadcli%2Fcommit%2F85097245b57f190337225dbdbf6e33b58616c092&amp;data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&amp;sdata=jJYANH4pJYj%2BI8EQGKh1%2BiArpn4PwSIxUFve7t8YmZI%3D&amp;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 -- [email protected] To 
> > unsubscribe send an email to [email protected]
> > Fedora Code of Conduct: 
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&amp;data=02%
> > 7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C
> > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&amp;sdat
> > a=v3APmwlHF3i9zi1WE950DEAqCMJCirnyPC4YyF2xJPQ%3D&amp;reserved=0
> > List Guidelines: 
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> > raproject.org%2Fwiki%2FMailing_list_guidelines&amp;data=02%7C01%7Cmote
> > r%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5bdd
> > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507304667&amp;sdata=QUgcpi82T
> > TRy7qanAkjRey8ZpC2GDy7%2BJ7yXeOrtb8I%3D&amp;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&amp;data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2ae
> > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6371660275
> > 07314661&amp;sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2Bx4%3D&
> > amp;reserved=0
> 
> > _______________________________________________
> > sssd-users mailing list -- [email protected] To 
> > unsubscribe send an email to [email protected]
> > Fedora Code of Conduct: 
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&amp;data=02%
> > 7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C
> > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&amp;sdat
> > a=b%2Fu1IXQ%2F42XEq3c6DYwzTyYno4azJb3qvUtPiZmOdrc%3D&amp;reserved=0
> > List Guidelines: 
> > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> > raproject.org%2Fwiki%2FMailing_list_guidelines&amp;data=02%7C01%7Cmote
> > r%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5bdd
> > 8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&amp;sdata=CIJal5z4E
> > nNOIQFsuveKmlEK1wMzIx79ZaXavinrtsk%3D&amp;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&amp;data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2ae
> > f608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6371660275
> > 07314661&amp;sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2Bx4%3D&
> > amp;reserved=0
> _______________________________________________
> sssd-users mailing list -- [email protected] To unsubscribe 
> send an email to [email protected]
> Fedora Code of Conduct: 
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&amp;data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&amp;sdata=b%2Fu1IXQ%2F42XEq3c6DYwzTyYno4azJb3qvUtPiZmOdrc%3D&amp;reserved=0
> List Guidelines: 
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines&amp;data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&amp;sdata=CIJal5z4EnNOIQFsuveKmlEK1wMzIx79ZaXavinrtsk%3D&amp;reserved=0
> List Archives: 
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted.org&amp;data=02%7C01%7Cmoter%40austin.utexas.edu%7Cc0f76fa86d4d42c2aef608d7ab204bc2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637166027507314661&amp;sdata=oDU3WxA3dStxFQ09%2Fc8qU7qGh1P5w3a9rSe9trG8%2Bx4%3D&amp;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 -- [email protected]
> To unsubscribe send an email to [email protected]
> 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/[email protected]
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]

Reply via email to