Warning: 2020 LDAP channel binding and LDAP signing requirement for Active Directory

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
gabaker
Posts: 19
Joined: Sat Sep 13, 2014 2:07 am
Location: Michigan, USA
ZCS/ZD Version: Release 8.8.11_GA_3737.RHEL7_64 P4

Warning: 2020 LDAP channel binding and LDAP signing requirement for Active Directory

Postby gabaker » Mon Jan 20, 2020 5:06 pm

According to this article by Microsoft https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows
in the March 2020 Windows updates, this LDAP channel binding and signing requirement for LDAP requests to AD will be mandatory. There are articles referenced in the above link on ways to enable/disable this through the registry. However, if admins simply update their AD servers in March, they may find that they can no longer authenticate users from Zimbra to external LDAP if they have not enabled SSL for the LDAP external authentication. Even then, they may have issues if they have not tested this.

I have not enabled SSL for my LDAP External Auth to AD, and have not tested yet. I am a bit concerned over this whole "Channel binding" and "Signing" requirement ... wondered if anyone had tried this yet (can be done prior to March 2020 with registry keys)... and could report here on procedure and results.

Note that this will affect all your clients which authenticate to AD, including regular Windows machines that are joined to your Domain and any other services that use AD to authenticate. I see this as a major PITA for people with legacy systems.

What are your thoughts and/or results?

Cheers,


7224jobe
Advanced member
Advanced member
Posts: 179
Joined: Sat Sep 13, 2014 1:55 am
ZCS/ZD Version: 8.8.15_GA_3869.RHEL7_64 Patch4

Re: Warning: 2020 LDAP channel binding and LDAP signing requirement for Active Directory

Postby 7224jobe » Wed Feb 19, 2020 1:39 pm

I bump this topic because I am not sure on how to enable SSL for Zimbra - AD authentication...Is this wiki still correct? https://wiki.zimbra.com/wiki/Secure_Aut ... bra_and_AD
7224jobe
Advanced member
Advanced member
Posts: 179
Joined: Sat Sep 13, 2014 1:55 am
ZCS/ZD Version: 8.8.15_GA_3869.RHEL7_64 Patch4

Re: Warning: 2020 LDAP channel binding and LDAP signing requirement for Active Directory

Postby 7224jobe » Fri Feb 21, 2020 1:40 pm

That Zimbra wiki says that you have to restart the domain controller to install Zimbra certificate...not that easy.

However I tried to follow that zimbra wiki but I did not get authentication working...here is the error that appears when I try to reconfigure authentication with port 636 and SSL active in zimbra admin interface:

javax.net.ssl.SSLHandshakeException: Couldn't kickstart handshaking
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:405)
at com.zimbra.common.net.CustomSSLSocket.startHandshake(CustomSSLSocket.java:95)
at com.zimbra.common.net.CustomSSLSocket.getOutputStream(CustomSSLSocket.java:392)
at com.unboundid.ldap.sdk.LDAPConnectionInternals.<init>(LDAPConnectionInternals.java:159)
at com.unboundid.ldap.sdk.LDAPConnection.connect(LDAPConnection.java:744)
at com.unboundid.ldap.sdk.LDAPConnection.connect(LDAPConnection.java:686)
at com.unboundid.ldap.sdk.LDAPConnection.<init>(LDAPConnection.java:518)
at com.unboundid.ldap.sdk.SingleServerSet.getConnection(SingleServerSet.java:229)
at com.zimbra.cs.ldap.unboundid.UBIDLdapContext.ldapAuthenticate(UBIDLdapContext.java:842)
at com.zimbra.cs.ldap.unboundid.UBIDLdapContext.externalLdapAuthenticate(UBIDLdapContext.java:892)
at com.zimbra.cs.ldap.unboundid.UBIDLdapClient.externalLdapAuthenticateImpl(UBIDLdapClient.java:124)
at com.zimbra.cs.ldap.LdapClient.externalLdapAuthenticate(LdapClient.java:190)
at com.zimbra.cs.account.ldap.LdapProvisioning.ldapAuthenticate(LdapProvisioning.java:5643)
at com.zimbra.cs.account.ldap.LdapProvisioning.checkAuthConfig(LdapProvisioning.java:5728)
at com.zimbra.cs.service.admin.CheckAuthConfig.handle(CheckAuthConfig.java:48)
at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEngine.java:646)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:491)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:278)
at com.zimbra.soap.SoapServlet.doWork(SoapServlet.java:307)
at com.zimbra.soap.SoapServlet.doPost(SoapServlet.java:216)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at com.zimbra.cs.servlet.ZimbraServlet.service(ZimbraServlet.java:211)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:821)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1685)
at com.zimbra.cs.servlet.CsrfFilter.doFilter(CsrfFilter.java:175)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at com.zimbra.cs.servlet.RequestStringFilter.doFilter(RequestStringFilter.java:54)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at com.zimbra.cs.servlet.SetHeaderFilter.doFilter(SetHeaderFilter.java:59)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at com.zimbra.cs.servlet.ETagHeaderFilter.doFilter(ETagHeaderFilter.java:47)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at com.zimbra.cs.servlet.ContextPathBasedThreadPoolBalancerFilter.doFilter(ContextPathBasedThreadPoolBalancerFilter.java:107)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at com.zimbra.cs.servlet.ZimbraQoSFilter.doFilter(ZimbraQoSFilter.java:125)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at com.zimbra.cs.servlet.ZimbraInvalidLoginFilter.doFilter(ZimbraInvalidLoginFilter.java:117)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at org.eclipse.jetty.servlets.DoSFilter.doFilterChain(DoSFilter.java:473)
at org.eclipse.jetty.servlets.DoSFilter.doFilter(DoSFilter.java:318)
at org.eclipse.jetty.servlets.DoSFilter.doFilter(DoSFilter.java:288)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1158)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1090)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:119)
at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:318)
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:437)
at org.eclipse.jetty.server.handler.DebugHandler.handle(DebugHandler.java:84)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:119)
at org.eclipse.jetty.server.Server.handle(Server.java:517)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:306)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:242)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:261)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:192)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:261)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:75)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:213)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:147)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.net.SocketException: Connection reset by peer (Write failed)
at java.base/java.net.SocketOutputStream.socketWrite0(Native Method)
at java.base/java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:110)
at java.base/java.net.SocketOutputStream.write(SocketOutputStream.java:150)
at java.base/sun.security.ssl.SSLSocketOutputRecord.flush(SSLSocketOutputRecord.java:251)
at java.base/sun.security.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:89)
at java.base/sun.security.ssl.ClientHello$ClientHelloKickstartProducer.produce(ClientHello.java:656)
at java.base/sun.security.ssl.SSLHandshake.kickstart(SSLHandshake.java:515)
at java.base/sun.security.ssl.ClientHandshakeContext.kickstart(ClientHandshakeContext.java:104)
at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:228)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:395)
... 72 more
User avatar
gabrieles
Advanced member
Advanced member
Posts: 141
Joined: Tue Feb 14, 2017 9:40 am

Re: Warning: 2020 LDAP channel binding and LDAP signing requirement for Active Directory

Postby gabrieles » Fri Feb 28, 2020 10:14 am

Don't follow that wiki. Basically it says you have to export zimbra's CA, import it in AD and use it as AD's main CA. That's not the point.
Simply you have to authenticate your domain against AD not using ldap but ldaps. Id means that you have to tell zimbra to trust the AD certificates (that could be self signed).
These are the steps that we take:

1 - For each domain that authenticates against an AD, get the ldap url:
zmprov gd mydomain.com zimbraAuthLdapURL
# name mydomain.com
zimbraAuthLdapURL: ldap://myad.mydomain.com:389

2 - Verify that ldaps port is reachable
telnet myad.mydomain.com 636

3 - Export the AD CA certificate, there are many guides on the internet:
https://www.sonicwall.com/support/knowl ... 319041199/
https://wiki.processmaker.com/3.1/Expor ... ertificate

4 - Copy the cert on the mailstore, add it to the Zimbra keystore, then restart mailboxd
vi /tmp/ad-ca.cer then paste the certificate in pem format
zmcertmgr addcacert /tmp/ad-ca.cer
zmmailboxdctl restart

5 - Modify ldap auth url for that domain pointing to ldaps
zmprov md mydomain.com zimbraAuthLdapURL "ldaps://myad.mydomain.com:636"

Some notes:
- Step 4 must be done for each mailstore that holds mailboxes that could need authentication against that AD
- If on step 1 the authentication is found to be not against ldap port 389 but against global catalog 3268, try to use the secure port 3269 instead of ldaps 636
- If you have multiple domain that authenticate against different ADs, all the steps must be repeated for each one
7224jobe
Advanced member
Advanced member
Posts: 179
Joined: Sat Sep 13, 2014 1:55 am
ZCS/ZD Version: 8.8.15_GA_3869.RHEL7_64 Patch4

Re: Warning: 2020 LDAP channel binding and LDAP signing requirement for Active Directory

Postby 7224jobe » Fri Feb 28, 2020 12:03 pm

Thanks a lot gabrieles!! :D Your solution worked perfectly.
I used "openssl x509 -inform der -in CA_AD.cer -out CA_AD.pem" to transform AD_CA certificate from cer to pem.

One notice: today i re-read Microsoft articles about this change, and, as far as I understood (since those articles are not very clear), on March they will be releasing an update that "add new audit events, additional logging, and a remapping of Group Policy values that will enable hardening LDAP Channel Binding and LDAP Signing", but the effective enabling of LDAPS authentication will be included in "A further future monthly update, anticipated for release the second half of calendar year 2020".

Source: https://portal.msrc.microsoft.com/en-us ... /ADV190023
User avatar
gabrieles
Advanced member
Advanced member
Posts: 141
Joined: Tue Feb 14, 2017 9:40 am

Re: Warning: 2020 LDAP channel binding and LDAP signing requirement for Active Directory

Postby gabrieles » Fri Feb 28, 2020 3:06 pm

7224jobe wrote:they will be releasing an update that "add new audit events, additional logging, and a remapping of Group Policy values that will enable hardening LDAP Channel Binding and LDAP Signing", but the effective enabling of LDAPS authentication will be included in "A further future monthly update, anticipated for release the second half of calendar year 2020".

Source: https://portal.msrc.microsoft.com/en-us ... /ADV190023


Thanks for the link! Good to hear it.
The original communication from MS was foggy and imprecise, and i think they sent many sysadmin into panic.
I think they underestimated the thing until they've been overwhelmed of explanation calls....
User avatar
maxxer
Advanced member
Advanced member
Posts: 190
Joined: Fri Oct 04, 2013 2:12 am
Contact:

Re: Warning: 2020 LDAP channel binding and LDAP signing requirement for Active Directory

Postby maxxer » Sat Feb 29, 2020 8:27 am

7224jobe wrote:a remapping of Group Policy values that will enable hardening LDAP Channel Binding and LDAP Signing

isn't this already an enforcing of new policies?

Return to “Administrators”

Who is online

Users browsing this forum: No registered users and 18 guests