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

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


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


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.


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?


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?


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.


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?


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.


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.


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


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.


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

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.


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.


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


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]


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.


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?


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



sudo dsconfigad -packetsign allow


or



sudo dsconfigad -packetsign disable

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


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


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


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.


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

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?


Reply