Desktop - macOS comply with MS ADV190023

This page serves as a record for eliminating the use of unsigned protocols or plaint text LDAP from macOS computers bound to an Active Directory domain.

Updates

2020-05-22:

Support engineer has reproduced that EC-reconnect sequences use SASL/GSSAPI, and not TLS.

2020-05-04:

Further experimentation, and advanced logging, exposed previously unseen patterns in client behavior:

Terminal runs dscl - TLS+SASL/GSSAPI
Terminal runs eccl - SASL/GSSAPI only
EC script uses dscl - EC uses TLS, dscl uses SASL/GSSAPI only
EC script uses eccl - ES uses TLS, eccl uses SASL/GSSAPI only

Log output, Wireshark traces, and scripts used, uploaded to Apple.

NOTE: For SASL/GSSAPI-only connections, all LDAP data is GSSAPI-encrypted. No cleartext data is sent.

2020-04-30:

Moved the Apple case from "Other (Medium)" to "Performance (Medium)" in Apple's portal. 

Apple SE requested a case review on our behalf.

2020-04-18:

Testing was paused for several weeks as work shifted to remote. Apple asked for retesting to confirm our findings of the tools not using TLS.  Retesting confirmed the behaviors of dscl/eccl using SASL/GSSAPI. Uploaded new Wireshark traces.

2020-03-07:

On Wednesday March 3, WSG updated the domain controller certificates to meet the Catalina certificate requirements. We have verified that the client now binds successfully.

2020-02-26:

Issues separate into two forks.

  • RESOLVED• Catalina fails to bind to AD.UCI.EDU using the `ssl` directive.
    • Apple states they can bind Catalina via the `ssl` directive.
    • Catalina tightened requirements for trusted certificates. (see References)
    • Desktop/WSG are evaluating the certificate status on the DCs.
      • Asked Apple for assistance on definitively demonstrating that Catalina refuses to trust the DC certificates.
  • Command line utilities `dscl` and `eccl` make queries using 389/GSSAPI, regardless of `ssl` directive.
    • Apple confirms they can successfully make `dscl` queries in an ssl configuration, but they do not use SSL.
      • Asked Apple to investigate whether the underlying AppleLDAP framework may be a point of error.

Apple confirms that using the `require` directives, macOS still generates the nonfatal 2995 error events.

2020-02-05:

Filed with Apple as:

  • AppleCare Enterprise 101019106553
  • Feedback FB7565297

 

References

Text of EventCode 2889

The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection

Text of Client Bind Type

A value of 1 indicates a simple bind, and a value of 0 indicates an unsigned bind.

Splunk Searches

EventCode 2889

index="winevent_dc_index" source="wineventlog:directory service" EventCode="2889"

EventCode 2889, exposing Binding Type

index="winevent_dc_index" source="wineventlog:directory service" EventCode="2889"
| rex field=_raw "(?ms)Binding\s+Type:\s+(?<typeBind>\d)"
| table _time, host, EventCode, ClientIdentity, ClientIPAddress, typeBind

 

Truth Tables

 Build notesBind Method / ConfigurationpacketsignpacketencryptAD CertificateLoginWindowECdsclecclNotes
10.14.6
MacBook Air (Early 2013)
USB installer
Setup Assistant by hand
BigFix/dsconfigad        

 

 

 

allowallowNAD\atl-mba-1014$
2889
typebind=0
1.8.1AD\atlauren
2889
typebind=0
n/a 
   requireallowN

AD\atl-mba-1014$
2889
typebind=0

1.8.1AD\atlauren
2889
typebind=0
n/a 
   allowrequireNAD\atl-mba-1014$
2889
typebind=0
1.8.1AD\atlauren
2889
typebind=0
n/a 
   requirerequireNAD\atl-mba-1014$
2889
typebind=0
1.8.1AD\atlauren
2889
typebind=0
n/a 
   allowallowYAD\atl-mba-1014$
2889
typebind=0
1.8.1AD\atlauren
2889
typebind=0
n/a 
   allowsslY(none)1.8.1AD\atlauren
2889
typebind=0
n/adscl does not observe bind configuration.

MS ATP warning - DC offered RC4 for Kerberos negotiation.
   requiresslY(none)1.8.1AD\atlauren
2889
typebind=0
n/aMS ATP warning - DC offeredc RC4 for Kerberos negotiation.
   allowallowNAD\atl-mba-1014$
2889
typebind=0
2.0.5AD\atlauren
2889
typebind=0
AD\atlauren
2889
typebind=0

eccl does not respect bind configuration.

inconsistent user-context results.
Maybe caching connection configuration?
Could be latency in DC->Splunk data.

   requireallowNAD\atl-mba-1014$
2889
typebind=0
2.0.5AD\atlauren
2889
typebind=0
AD\atlauren
2889
typebind=0
 
   allowrequireNAD\atl-mba-1014$
2889
typebind=0
2.0.5AD\atlauren
2889
typebind=0
AD\atlauren
2889
typebind=0
 
   requirerequireNAD\atl-mba-1014$
2889
typebind=0
2.0.5AD\atlauren
2889
typebind=0
AD\atlauren
2889
typebind=0
 
   allowallowYAD\atl-mba-1014$
2889
typebind=0
2.0.5AD\atlauren
2889
typebind=0
AD\atlauren
2889
typebind=0
 
   allowsslY(none)2.0.5AD\atlauren
2889
typebind=0
AD\atlauren
2889
typebind=0
(MS ATP warning - DC offered RC4 for Kerberos negotiation.)
   requiresslY(none)2.0.5AD\atlauren
2889
typebind=0
AD\atlauren
2889
typebind=0
(MS ATP warning - DC offered requested RC4 for Kerberos negotiation.)

10.15.x
MacBook Pro (2017)

USB installer
Setup Assistant by hand

BigFix/dsconfigad        
10.15.2  allowallowNAD\atl-mbp-1015$
2889
typebind=0
1.8.1AD\atlauren
2889
typebind=0
n/a 
10.15.2  requirerequireNAD\atl-mbp-1015$
2889
typebind=0
1.8.1AD\atlauren
2889
typebind=0
n/a 
10.15.2  requiresslY 1.8.1 n/a

dsconfig -add -packetsign=require packetencrypt=ssl fails

Must do packetencrypt=require first, then change to packetencrypt=ssl in separate operation.

Computer becomes inoperable. Must reinstall.

   allowallowNAD\atl-mbp-1015$
2889
typebind=0
2.0.5AD\atlauren
2889
typebind=0
AD\atlauren
2889
typebind=0
dscl does not observe bind configuration.

eccl does not respect bind configuration.
   requirerequireN 2.0.5  not attempted
   requiresslY 2.0.5  not attempted
10.15.3  allowallowNAD\atl-mbp-1015$
2889
typebind=0
1.8.1AD\atlauren
2889
typebind=0
n/a 
10.15.3  requirerequireNAD\atl-mbp-1015$
2889
typebind=0
1.8.1AD\atlauren
2889
typebind=0
n/a 
10.15.3  requiresslY 1.8.1  

dsconfig -add -packetsign=require packetencrypt=ssl fails

Must do packetencrypt=require first, then change to packetencrypt=ssl in separate operation.

Computer becomes inoperable. Must reinstall.

   allowallowN 2.0.5  not attempted
   requirerequireN 2.0.5  not attempted
   requiresslY 2.0.5  not attempted

 

Wireshark - SASL bind behavior

In observing the behavior of macOS connections, a SASL bind sequence is observed. This sequence is seen when macOS sits at the login screen, or when dscl runs queries. This sequence triggers a 2889 event code.

Client: LDAP search for base properties of the directory.
Server: Result indicating that it support SASL GSSAPI bind.
Client: SASL bindRequest of type GSSAPI, on port 389.
Server: saslBindInProgress using GSS-API and specifying encryption type.
Client: SASL bindRequest of type GSSAPI, sending from port 88 (Kerberos).
Server: saslBindInProgress using GSS-API and hashes.
Client: SASL bindRequest of type GSSAPI, declaring credential hash.
Server: Bind success.

 

 

Appendix: Raw text from Fall 2019 testing

Splunk: index="winevent_dc_index" source="wineventlog:directory service" EventCode="2889"

 

ATL-MBP-018

 

Which Airwatch OU? — macOS

 standard supported policies

 

AD record?

 NOPE

 reassign profile

 YEP

 

EventCode="2889"

 

events as “AD\oidadder” during machine bind

events as “AD\atl-mbp-018$” thereafter, periodically

with login events too

 

create “atlauren” Andrew Fake

logout

login as “atlauren” local account

 -> events as machine account

login to EC

 events as “ad\atlauren”

EC reconnect

 events as “ad\atlauren”

machine events on logout

events from machine and user on login/EC

 

** move to Airwatch OU Experimental **

AD/Certificate profile lands

new events for rebinding as oitadder, machine record

in New Computers OU

*is a complete rebind*

move to OU

 

EC reconnect

 no events

logout

 no events

reboot

 events as machine record

login atlauren

 event as atlauren

EC reconnect

 event as atlauren

 

Appendix: DNS notes

Be sure and use AD's DNS servers.