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(a)seznam.cz> wrote:
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:
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
(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
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:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines