I just installed a AD site, and will be deploying Linux machines as well.

I would personally be afraid of ANY patch coming from Microsoft that after being applied, would put your LINUX services into question afterwards.

I am in a NIST/PCI compliance location, and I do not mix the two as a result. (i.e. LINUX<->OpenLDAP/Windows<->AD). Primarily because time is an issue, and trying to follow vendor patching with Microsoft is bad enough on a timeline, as it is, with their own products let along throwing LINUX in the mix. :-)

However, for this new location I AM going to be deploying a File Server (SAMBA) and asked my boss to try it, indicating it could save us some money. (Not necessarily time...which being salaried he loved that idea. :-)

But under the condition if it causes too many issues it would be easy enough to just buy a windows server license and replace it. I hope not, as I would love to reduce my dependance on Microsoft as much as possible.

In that regard, I am going to be building a patching test environment to give me a heads up on this sort of thing, so I can see what happens to my Windows Server AD test environment when I patch it, and see if my LINUX SAMBA machine still works.

BEFORE I PATCH.

I have that in place anyway to test patches and such with not just Microsoft but also vendors etc. So I will be adding a LINUX box (Really just a VM) to the test environment.

So I watch this list keenly for AD/LINUX integration issues and solutions.

But I would suggest in your position that you build such an environment, so you can test any such patches from Microsoft or even other Vendors and see what happens to your LINUX AD connectivity.

On Thu, Feb 6, 2020 at 4:15 AM David David modrik@seznam.cz wrote:

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://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-a... .

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

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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...