Skip to main content
Solved

ICYMI: Active Directory will require LDAP over SSL in 2020

  • November 21, 2019
  • 44 replies
  • 174 views

Show first post

44 replies

Forum|alt.badge.img+9
  • Valued Contributor
  • February 3, 2020
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.


jbembry
Forum|alt.badge.img+2
  • New Contributor
  • February 3, 2020

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.


Forum|alt.badge.img+12
  • Contributor
  • February 5, 2020

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


Forum|alt.badge.img+3
  • New Contributor
  • February 5, 2020

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 ?


Forum|alt.badge.img+7
  • Valued Contributor
  • February 5, 2020

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.


mark_mahabir
Forum|alt.badge.img+15
  • Jamf Heroes
  • February 12, 2020

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?


Forum|alt.badge.img+4
  • Contributor
  • February 12, 2020

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?


Forum|alt.badge.img+8
  • Contributor
  • February 12, 2020

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?


mvu
Forum|alt.badge.img+20
  • Jamf Heroes
  • February 12, 2020

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


Forum|alt.badge.img+10
  • Author
  • Contributor
  • February 18, 2020

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.


Forum|alt.badge.img+4
  • New Contributor
  • February 19, 2020

@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?


Forum|alt.badge.img+4
  • New Contributor
  • February 19, 2020

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

Thanks


Forum|alt.badge.img+3
  • New Contributor
  • February 21, 2020

@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.


Forum|alt.badge.img+9
  • Contributor
  • May 28, 2020

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?


Forum|alt.badge.img+4
  • New Contributor
  • June 23, 2020

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.


Forum|alt.badge.img+12
  • Valued Contributor
  • November 3, 2020

To cite @Cyrano5 : Any news on this?


Forum|alt.badge.img+9
  • Valued Contributor
  • January 21, 2021

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?


spalmer
Forum|alt.badge.img+23
  • Valued Contributor
  • Answer
  • January 21, 2021

@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.


Forum|alt.badge.img+9
  • Valued Contributor
  • January 21, 2021

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