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 <[email protected]>
> Sent: Thursday, February 6, 2020 5:20 PM
> To: [email protected] <[email protected]>
> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
> Fedora Code of Conduct: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&amp;data=02%7C01%7Condrej.valousek%40adestotech.com%7C3894620c31a14f0fefad08d7ab2073f3%7C2ccd8edaa14a4b4f825ce6ad71d71b81%7C0%7C0%7C637166028194115487&amp;sdata=Icr5AIwrrPCefv%2B8f9dxDyWB1Rq8%2B8jPR4D5OWqRC%2B4%3D&amp;reserved=0
> List Guidelines: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines&amp;data=02%7C01%7Condrej.valousek%40adestotech.com%7C3894620c31a14f0fefad08d7ab2073f3%7C2ccd8edaa14a4b4f825ce6ad71d71b81%7C0%7C0%7C637166028194115487&amp;sdata=gptDfOknTZrcdE0stDWLWfCcB8mFagNR7DvIvvZtFhU%3D&amp;reserved=0
> List Archives: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted.org&amp;data=02%7C01%7Condrej.valousek%40adestotech.com%7C3894620c31a14f0fefad08d7ab2073f3%7C2ccd8edaa14a4b4f825ce6ad71d71b81%7C0%7C0%7C637166028194115487&amp;sdata=Nk7vVUzmoKBn%2Bv%2FKwE2UwlYP07oE6I0ccafbV1SkORQ%3D&amp;reserved=0

> _______________________________________________
> 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