ICYMI: Active Directory will require LDAP over SSL in 2020

samuellarsson
New Contributor III

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

1 ACCEPTED SOLUTION

spalmer
Contributor III

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

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.

View solution in original post

44 REPLIES 44

CasperSally5432
New Contributor II

Has anyone gotten an answer from jamf if their bulit in binding set up via the GUI use SSL?

mark_mahabir
Valued Contributor

@CasperSally5432 I'm guessing not, as there are no checkboxes under Directory Bindings for SSL. It's why many (like us) use a binding script instead.

However, the relevant options are there in Jamf Pro if you want to use a Configuration Profile (in the Administrative section).

andrew_nicholas
Valued Contributor

If I'm reading the dsconfig man page and this Apple KB right, then it should be feasible to just add a followup script to simply run dsconfigad -packetencrypt ssl.

jazminepena
New Contributor III

I've tried issuing the command:

sudo dsconfigad -packetencrypt ssl

...in Terminal, as well as amending our existing AD bind script and also trying a Configuration profile in Jamf Pro with the relevant options set. But Wireshark still shows traffic being sent via ports 389/3268 rather than 636/3269.

Anyone have any ideas?

spalmer
Contributor III

If you read the manpage for dsconfigad it does state that packetsign and packetencrypt are set to allow by default.

-packetencrypt allow | disable | require | ssl By default packet encryption is allowed but not required, but can be required or disabled (for example if debugging a prob- lem). This ensures that the data to/from the server is encrypted and signed guaranteeing the content was not tampered with and cannot be seen by other computers on the network. -packetsign allow | disable | require By default packet signing is allowed but not required, but can be required or disabled (for example if debugging a problem). This ensures that the data to/from the server is not tampered with by another computer before received it is received.

I bind via a script and I have never explicitly set these values but they correctly default to allow on Macs that I have run this script on. Likewise, in testing a Jamf Pro Directory Binding I also see that after a successful bind these values also default to allow as expected.

Looking closely at the Apple KB article that @andrew.nicholas linked to I also see the following sentence in the Packet signing and encryption section:

The signed and encrypted LDAP connections also eliminate any need to use LDAP over SSL.

In the Microsoft KB article that @samuellarsson linked to it states that the update is requiring LDAP signing but does not state anything about requiring LDAP over SSL (which based on the Apple KB article is different than LDAP signing) :

Required: Security Update available on Windows Update for all supported Windows platforms that will enable LDAP channel binding and LDAP signing on Active Directory servers by default.

I am not an AD admin (and will definitely be discussing and testing this with ours) but this leads to the following questions:
1. Doesn't this imply that Macs will be fine after the MS Update with the default allow values for packetsign and packetencrypt?
2. We have our Jamf Pro LDAP Servers setting configured to use SSL but we aren't using an SSL certificate. Will this continue to work after the MS update since Microsoft is stating that only LDAP signing is required?

samuellarsson
New Contributor III
In the Microsoft KB article that @samuellarsson linked to it states that the update is requiring LDAP signing but does not state anything about requiring LDAP over SSL (which based on the Apple KB article is different than LDAP signing)

The Microsoft KB article I linked to states not only that LDAP signing is required, which I agree is irrelevant in our case, but also that LDAP channel binding type 2 is required (see this additional Microsoft KB for binding types), which is also necessary for LDAPS. What my AD admins were yelling about was that they saw a bunch of events on the domain controller event log, which were LDAP connections from our Macs made with binding type 0, which would by default be denied once the update goes live if we are to believe the original KB article that I linked to.

To answer your questions: I have discussed this in the Macadmins Slack channel #activedirectory as well, and the general take away is "don't worry, nothing will change for you". Most likely because the directory bind will go with the highest required level of signing/encryption, like you say. But it is definitely a good idea to test this before the domain controllers have the chance to update.

mvu
Valued Contributor

Hi @samuellarsson

Thanks a lot for this heads up. I'm still reading up on it. Like you, our AD admins flagged our Macs awhile ago because of all the events on the DC logs. Long story short, we connected with an Apple Engineer from Apple Enterprise support.

Our understanding is that the Macs will follow the security setting of the AD server/DC, which the admins set to REQUIRE for both packet sign and packet encryption. Even though there are logs, the Macs got a waiver.

So with that in mind, do we need to change how we bind after the 2020 update? We are still using the Jamf Pro Bind setting. Do existing AD bound Macs need to do anything, like unBind and re-bind?

Shamagi
New Contributor II

Hi, the Microsoft article is talking about "LDAP binding". It's not about binding devices. Here's another article:
https://blogs.technet.microsoft.com/russellt/2016/01/13/identifying-clear-text-ldap-binds-to-your-dcs/ It says that you can check Event ID 2887: "This event occurs every 24 hours and will report how many unsigned and clear text binds have occurred to this DC. .... " . I see approx 60 000 unsigned binds every 24 hours.

Regards.

mmajewski
New Contributor

Can someone confirm that even though the Mac's are now logging 2889 events on the domain controllers that they will not need to have anything done to them before/after the January 2020 update? And Im currently seeing the device itself showing as making the ldap connection. Ie it shows as DOMAINcomputername in the event log not DOMAINusername.

samuellarsson
New Contributor III

Yes, I'm also not entirely convinced until someone has tested. Has anyone done this?

mconners
Valued Contributor

Hello @samuellarsson have you tested lately for using a configuration profile directory payload with JSS 10.17.1? I have been finding it working well, but my colleague and I are concerned that others online here have suggested this isn't reliable. I would prefer built in solutions as opposed to scripted solutions that may fail later as the OS or JSS evolve.

EdLuo
Contributor II

Related issues
1. Outlook will also need the Use SSL to connect option checked after this update. I'm looking for an elegant way to get this checked without launching Outlook.
https://www.jamf.com/jamf-nation/discussions/25177/outlook-2016-advanced-settings
2. Those using NoMAD will need this line after the patch

defaults write com.trusourcelabs.NoMAD LDAPOverSSL -bool true

perryd
Contributor

Still a bit confused as to what needs to be done on existing domain bound macs and if they need a fix rolled out to them? I know there is a patch for Windows clients that has to be on the devices before the server patch goes live.

Would be nice if Microsoft or Apple would address the implications for MacOS as there is no documentation on this at all.

At the moment our work place is in a flap and we are being told to push forward with JAMF Connect for the whole estate by March which is a crazy short time frame to migrate existing clients and change our entire build process to remove AD binding and move to SSO with JAMF Connect.

EdLuo
Contributor II

In addition to my previous post, this is what I done to clear out the event logs monitored by our AD admin.
fa32e798dfc4402f86e75f05baa425c0

No rebinding of the computers needed.

DanJ_LRSFC
Contributor II

@EdLuo (or anyone else) - is there a way to use dsconfigad to check the current status of these options, for example as an extension attribute that we can use in a smart group criteria?

myronjoffe
Contributor III

Anyone know what impact if any this will have any Enterprise Connect?
and if it impacts running commands similar to below from CLI?
ldapsearch -h [host]-s sub -b "[SearchBase]" sAMAccountName=[SAN]

mvu
Valued Contributor

Same here, @perryd. I have a ticket open with Apple. They said 10.15 won't see impact, but older operating systems might be a different story. They are still testing. I'll forward the news when I hear back.

DanJ_LRSFC
Contributor II

I've just tried dsconfigad -packetsign require and dsconfigad -packetencrypt ssl on my office Mac and now I can't log in to it at all, not even through SSH. Is there a way to undo these settings from Recovery mode?

EdLuo
Contributor II

@DanJ_LRSFC try logging while off network using cached credentials and then running

sudo dsconfigad -packetsign allow

or

sudo dsconfigad -packetsign disable

EdLuo
Contributor II

@DanJ_LRSFC You can use the dsconfigad -show command to show the status and extract the line for "Packet encryption" and "Packet signing" and return the result through extension attribute.

dgreening
Valued Contributor II

And that would be:
dsconfigad -show | grep "Packet signing" | awk '{print $4}'
dsconfigad -show | grep "Packet encryption" | awk '{print $4}'

DanJ_LRSFC
Contributor II

@EdLuo thanks, I managed to get back in by unplugging the Ethernet cable.

So what other prerequisites are there for these commands to work successfully? Do we need to have the Jamf AD CS Connector installed in our environment?

I checked using ldp as described here that LDAPS is enabled in our environment, and I exported our AD CS CA root certificate to a .pem file and did openssl s_client -connect domaincontroller.domain.com:636 -CAfile CAcert.pem which succeeded.

But even though I've loaded the CA cert into the System keychain and told it to trust it, I'm still not able to log on using a network account on the Mac I'm testing it on. EDIT: yes I am, it works fine now

So it looks like adding the Jamf AD CS Connector to our environment will be the best way to enable this to work, as this will presumably manage and deploy those AD CS CA certificate automatically.

sintichn
New Contributor III

Just a word of warning, don't do this for computers still running 10.12 Sierra. it locks them up at the login screen, you need to disconnect from wifi and reverse back to allow. We unfortunately have a few stragglers left on Sierra and found this out the hard way. We use a firmware pw so we needed to remove it in recovery, then boot to single user mode and run this
networksetup -setnetworkserviceenabled Wi-Fi off to disable wifi, then we were able to log in and make the change back to sudo dsconfigad -packetencrypt allow. Mojave folks are fine.

wmehilos
Contributor

Here's some quick back of the napkin EA scripts.

#!/bin/bash
# -packetsign flag      'disable', 'allow', or 'require' packet signing
setting=`dsconfigad -show | grep "Packet signing" | awk '{print $4}'`

if [[ -z $setting ]]; then 
    echo "<result>Not Bound</result"
else
    echo "<result>$setting</result>"
fi
#!/bin/bash
# -packetencrypt flag   'disable', 'allow', 'require' or 'ssl' packet encryption
setting=`dsconfigad -show | grep "Packet encryption" | awk '{print $4}'`

if [[ -z $setting ]]; then 
    echo "<result>Not Bound</result"
else
    echo "<result>$setting</result>"
fi

abutterman
New Contributor III

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?

brianmcbride99
Contributor II
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
New Contributor III

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.

john-hsu
New Contributor III

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

DSI
New Contributor II

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 ?

jkaigler
Contributor II

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
Valued Contributor

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?

jazminepena
New Contributor III

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?

kquan
Contributor

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?

e7d55dfb0af64cbeb968b7dbc6138b01

mvu
Valued Contributor

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

samuellarsson
New Contributor III

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.

Mahendran
New Contributor

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

Mahendran
New Contributor

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

Thanks

schiemsk
New Contributor III

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

el2493
Contributor II

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?