Skip to main content

UPDATE 2020-02-04: Microsoft has postponed the update again from March 2020 to the second half of 2020.



UPDATE 2020-01-24: Microsoft has postponed the update from January 2020 to March 2020.



For y'all who are binding your devices to Active Directory, you are going to have to make sure that the LDAP connections are encrypted from mid-January 2020. Microsoft will release security updates across the board that requires all connections to be encrypted.



There are essentially only two things that need to be looked at: the Jamf Pro server LDAP bind options and, if you bind any of your clients, the client directory bind configuration.



For the Jamf Pro LDAP binding options, there is a great guide to follow here. The client directory bind configuration, however, can be applied in different ways, but the most usual ways are by configuration profile or binding via CLI. At the moment, the payload called Directory in the configuration profiles has an option under Packet encryption called "ssl" and another option under Packet signing called "require", which as far as I know both need to be set. To join a client with the built-in CLI called dsconfigad, there is the following command:



dsconfigad -add <domain> -username <user> -computer $(hostname) -password <password> -ou "<ou>" -packetencrypt ssl -force


As usual, it's a good idea to look over this now when there is still time. Nothing will happen until you actually run the Windows update to your domain controller(s), but you will need to update all the same.



Link to Microsoft article

I've been struggling with disastrous results of running dsconfigad -packetencrypt ssl on various machines. I have been testing on both Mojave and Catalina. On one of each, within 10 seconds of running the command either locally or pushed through Jamf, the computer slows to a crawl and the entire authentication service breaks. The users system preferences can no longer load and I am unable to log in with either local or network accounts should I log out unless I disconnect the network cable. Mysteriously, on another Mojave computer, it did not break following the execution of the command. On that particular computer, I was able to open Wireshark and see that during the LDAP request on 389, the cipher is changed and the connection switches to TLSv2. Is there some trick to getting this to work? Or will simply leaving the default of "allow" work once the LDAPS is the only option on the domain controllers?


@abutterman - I've been seeing the same performance issues in my testing. Hoping someone can shed some light on your question regarding leaving the default of 'allow' on and whether once the LDAPS security updates hit our DCs whether or not I need to change the way we bind our MACs to AD going forward? Currently we have a Directory Binding set in settings, and do the Bind after enrollment via Policy.

I wanted to share my experiences as it may help others.




  • Don't turn on anything until you test with either ldapsearch or openssl. (I was stupid and tested on my machine...don't be stupid like me...)


  • Test using Catalina 10.15 as it is more restrictive in terms of your certs. If it works there it should work on the rest of your fleet.(See: Here )


  • Also, make sure your CAs certs meet all the requirements in the link above. This ultimately resolved our issues. We had to increate our RSA key sizes.


It looks like Microsoft has delayed LDAP over SSL once again:



A further future monthly update, anticipated for release the second half of calendar year 2020, will enable LDAP signing and channel binding on domain controllers configured with default values for those settings.


Source: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

Hello, I tested Mojave.
My being connected to the AD, when I execute the command :
sudo dsconfigad -packetencrypt ssl



My station leaves all alone from the AD.



Do you have an idea ?

I am testing the packet signing and encryption. Importing the root cert from AD into keychain seems to work on 10.14 but not 10.15. probably because the cert is for 5 years. I have not tested on any 10.13 or older macs yet.

We made the change from allow/allow to require/ssl in our binds to AD last week and our DCs have been updated today. I'm seeing the authentication issues mentioned further up the thread on 5/325 machines so far. We're purely Mojave and High Sierra currently, we haven't yet made the jump to Catalina.



@mvu Has there been any progress on that ticket?

We're finding that some systems are losing their bind completely, so the proposed fix of logging in off network using cached credentials and then running:



sudo dsconfigad -packetsign allow


or



sudo dsconfigad -packetsign disable


...won't work, or am I missing something?

Hey Guys,



For DEP prestage for binding, are you using configuration profiles? I ask is because I have some legacy Prestages with the Directory Binding option still being used. I reached out JAMF and they suggested using Configuration Profiles. I have been testing the configuration profile method(with packet encryption/signing set, and adding the ROOT CA cert) on a test Prestage and getting 75% failure rate to bind(they've confirmed the same issue but didnt offer any solution...). When it works everything works great. When the configuration profile fails to install, the only way to get it to re-deploy is to wipe the machine and hope it works...



My other question is for existing machines, how are you guys pushing the CA cert to them? Is anybody also doing rebinding policy scripts as well?



@mark.mahabir I spoke to Apple a couple of times the past couple of weeks. The status is the same: Still in testing.

I recommend anyone who is having problems with this or want more information from the community about it, to go to the #activedirectory channel in the MacAdmins Slack. There have been a number of great discussions on the subject over there.

@samuellarsson Could you please share the Microsoft article that states they have postponed the update again from March 2020 to the second half of 2020?

@samuellarsson Never mind, got it in this same forum https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023



Thanks

@jbembry



wanted to share my experiences as it may help others.

Don't turn on anything until you test with either ldapsearch or openssl. (I was stupid and tested on my machine...don't be stupid like me...)

Test using Catalina 10.15 as it is more restrictive in terms of your certs. If it works there it should work on the rest of your fleet.(See: Here )

Also, make sure your CAs certs meet all the requirements in the link above. This ultimately resolved our issues. We had to increate our RSA key sizes.


Damn... I've just discovered a sha-1/rsa CA -_-'
Thanks you for this reminder.

I had seen previously on https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023 where it said the update had been pushed to the second half of 2020. If I look at the page now, it doesn't say that anymore. Instead it says:



Important The March 10, 2020 and updates in the foreseeable future will not make changes to LDAP signing or LDAP channel binding policies or their registry equivalent on new or existing domain controllers.


So does that mean we don't need to change anything in terms of binding, and that if we were using Jamf's built-in binding configurations we could keep doing that?

Does anyone have an update to this? The reports that I have seen in this thread mirror the experiences that I have had as well. When I apply the dsconfigad -packetsign require and dsconfigad -packetencrypt ssl commands on my test machines, AD becomes unresponsive. I cannot unlock my machine or any of the preference panes when trying to authenticate with AD credentials.

To cite @Cyrano5 : Any news on this?

It appears this is coming on 2.9.21, see here



I'm scouring splunk and our DCs for event ID 5829 which should be triggered by any vulnerable device attempting to connect over non secure channel Netlogon see here I'm not finding any of these eventIDs - does anyone know how I can confirm for certain on a macOS device whether it is configured for secure channel Netlogon?

@brianmcbride99 The article you linked to refers to Netlogon Domain Controller Enforcement Mode and references CVE-2020-1472. Are you sure that is the same issue?



This discussion thread was originally referring to CVE-2017-8563 with regards to Microsoft requiring LDAP Channel Binding and LDAP Signing.



A blog post from Microsoft states that it has backed off on forcing LDAP Channel Binding and LDAP Signing and is only now highly recommending it, leaving the decision up to the customer:



https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536



ATTENTION: before you continue reading I must emphasize that the MARCH 2020 update and FUTURE UPDATES WILL NOT MAKE ANY CHANGE. This means that we leave it to Customer to decide when to enforce these settings, now and in the future.
https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirem...

Our recommendation is to enforce both of them and not leave your environment at risk


If this is indeed a totally different issue it might be best to start a new discussion.

@spalmer My apologies, you are indeed correct. I have the two mixed up. Sorry for the false alarm, and thank you for the clarification.

Terms & ConditionsCookie settings