ICYMI: Active Directory will require LDAP over SSL in 2020

[samuellarsson]

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

[CasperSally5432]

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

[mark_mahabir]

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

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]

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]

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]

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.

[obi-k]

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]

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]

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]

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

[mconners]

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]

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]

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]

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

No rebinding of the computers needed.

[DanJ_LRSFC]

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

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]

[obi-k]

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]

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]

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

sudo dsconfigad -packetsign allow

or

sudo dsconfigad -packetsign disable

[EdLuo]

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

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

[DanJ_LRSFC]

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

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]

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]

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?

[bmack99]

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]

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]

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]

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]

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]

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]

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]

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?

[obi-k]

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

[samuellarsson]

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]

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

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

Thanks

[schiemsk]

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

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?