Why do we use NTLM/kerberos if we can have a secure connection with LDAP using SSL.
Related
In PostgreSQL with Password authentication , if SSL = on , in postgresql.conf file , then can the client connect without the SSL certificate on his side ?
Please help.
Enabling SSL (SSL = on) will still allow both normal and SSL connections. However, the pg_hba.conf file can be configured to allow only SSL (or both) through using the hostssl and clientcert option. See here for more info
In 2020, Microsoft will be addressing CVE-2017-8563 a set of unsafe default configurations for LDAP channel binding and LDAP signing which exist on Active Directory domain controllers that let LDAP clients communicate with them without enforcing LDAP channel binding and LDAP signing.
Due to above change the LDAP clients that do not enable or support signing will not connect.
LDAP Simple Binds over non-TLS connections will not work if LDAP signing is required.
This does not mean we have to move all LDAP applications to port 636 and switch to SSL/TLS. When SASL with signing is used, LDAP Clients that do enable or support signing will connect over port 389.
Hence, the LDAP simple binds now needs to be converted into SASL like DIGEST-MD5 and add a support for signing through qop as a "auth-int". However, in large applications ldap authentication happens at HTTP Server level instead of a java program and in my case it's Apache HTTPServer 2.4.x.
Currently, I'm having Basic authentication provider configured as below in Apache HTTPServer (Windows & Linux platforms), which needs to be replaced with an SASL authentication mechanism like GSSAPI, GSS-SPNEGO or DIGEST-MD5:
# Basic Authentication provider
<AuthnProviderAlias ldap MyEnterpriseLdap>
AuthLDAPURL "ldap://machine1.abcd.com:389/CN=Users,DC=abcd,DC=com?sAMAccountName?sub?(objectClass=*)"
AuthLDAPBindDN "CN=rohit,CN=Users,DC=abcd,DC=com"
AuthLDAPBindPassword "abc123"
LDAPReferrals Off
</AuthnProviderAlias>
# Authenticated resources
<LocationMatch ^/+WebApp/+(;.*)?>
AuthName "WebApp"
AuthType Basic
AuthBasicProvider MyEnterpriseLdap
Require valid-user
</LocationMatch>
I'm looking POC examples for any of the below 3 options for SASL with Apache & Active directory:
1. DIGEST-MD5 using mod_auth_digest: This mechanism does not look up in ldap and it has not yet implemented qop "auth-int".
Is there any other third party apache 2.4.x module for digest_md5 that will look-up in ldap and supports qop "auth-int"?
2. GSSAPI mod_auth_gssapi: Looks like using mod_auth_gssapi it's possible for Apache HTTPServer to lookup for users & their credentials in Active directory and thereby authenticate using GSSAPI mechanism.
Is there any documentation OR POC example stating the required configuration to do in Windows & Linux for Apache HTTPServer 2.4.x for GSSAPI, So as to authenticate using GSSAPI mechanism with Microsoft Active directory?
3. mod_authn_sasl & Cyrus SASL: A third party library which is now evolving for Windows platform.
I'm looking for an concrete documentation/POC example with any SASL mechanism to implement this library with Apache(Windows & Linux platforms) using Active directory.
OR Is there any other way to enable SASL for Apache HTTPServer with Active directory?
Also, checked SO for SASL LDAP authentication failure (Here, LDAPS is used) AND In apache httpd configuration, what LDAP SASL mechanism is used during ldap authentication? (Though Apache does not provide SASL as a OOB configuration, using modules like mod_auth_gssapi SASL is possible)
Note:
1. The application already supports LDAP(simple binds) & LDAPS configurations, So we don't want users to forcefully use LDAPS. Instead we want to enable/implement an SASL mechanism for non-SSL/TLS configurations.
2. Disabling the LDAP signing for non TLS connections is not an option because, When SASL with signing is used, LDAP Clients that do enable or support signing can connect over port 389.
I've posted this in detail, so that it can be helpful for others who are impacted with Microsoft's 2020 update for channel binding & signing.
Thanks.
Microsoft earlier decided to enroll an security update in 2020 to enable LDAPChannel Binding and LDAP Server Signing as a default configuration as in the below screenshot.
However, Due to customers raising concerns on this update & SASL limitations (Not supported by 3rd party authentication mechanisms like Apache HTTPServer). The Microsoft has now rolled-back this enforcement and have left to customer decide whether to enforce the settings or not.
Moreover, Microsoft has also confirmed that there will be no more updates related to the enforcement of LDAPChannel Binding and LDAP Server Signing in future.
That is the March 10th 2020's security update on LDAPChannel Binding and LDAP Server Signing will be the last update to these settings.
Microsoft have updated their article on security advisory as below: ADV190023
It is highly recommended to make use of LDAPS instead of LDAP or any SASL protocols.
I set up an FTPS server with Apache MINA in which clients cients authenticate via user/password. I now want to force clients to authenticate via an SSL certificate, but I could not find instructions nor examples for this. Anyone can help?
Got it:
ListenerFactory factory = new ListenerFactory();
SslConfigurationFactory ssl = new SslConfigurationFactory();
ssl.setClientAuthentication("true");
ssl.setTruststoreFile(new File("trust.jks"));
ssl.setTruststorePassword("trust-password");
ssl.setKeystoreFile(new File("certs.jks"));
ssl.setKeystorePassword("certs-password");
factory.setSslConfiguration(ssl.createSslConfiguration());
factory.setImplicitSsl(true);
The server will force clients to connect using a certificate, and will only accept those included in trust.jks.
Adobe documentation for AEM 6 says
"Check the Use SSL or Use TLS checkboxes when configuring the LDAP
Identity Provider."
What protocol will be used if I check both boxes? Does TLS override the SSL config option? It seems to work with one or both checked, but I can't verify which protocol was used. Is checking just TLS sufficient to ensure I have a connection using the TLS protocol?
There are 2 ways to secure LDAP connections :
One is to connect to the LDAPS port (636 by default) using SSL (or
the later TLS versions). This is the legacy and non-standard way to
do it, also generally known as "Use SSL".
One is to connect to the LDAP port (389), and then enable TLS using
the LDAP StartTLS extended operation (which negotiates SSLv3 or TLS
protocols). It is generally known as "Use TLS".
The underlying version of the protocol used (SSLv3, TLSv1.0, TLSv1.1...) depends on the settings of the LDAP server or the LDAP client library.
I hope this helps.
I have created a test environment. I have one ldap client, ldap listener (as a ldap proxy) and a ldap server. Ldap client sends ldap requests to ldap proxy on port 389 (SSL). Ldap proxy decodes the ldap requests and forwards them to the ldap server on port 389. And the proxy forwards the reply of the ldap server to ldap client successfully.
I created SSL certificate on ldap server. And this time I tested that ldap client sends ldap requests to ldap proxy on port 389 (SSL). Ldap proxy forwarded requests to the ldap server on port 636. And the proxy forwards the reply of the ldap server to ldap client successfully.
But there is a problem when I try to use SSL on both sides. I mean
ldap client (port 636) -> ldap proxy (port 636) -> ldap server (port
636)
My client throws an exception
javax.net.ssl.SSLHandshakeException: Remote host closed connection
during handshake
I am using unboundid ldap sdk and LdapDebugger example as a ldap proxy. How can I configure ldaplistener to accept SSL encrypted requests(port 636)?
thanks in advance...
If you're using the ldap-debugger tool provided with the LDAP SDK, it currently only supports SSL for communicating with the backend server, but not when communicating with a client. That is, the "--useSSL" option applies only for communication between the LDAP debugger and the backend directory server, and not between the client and the LDAP debugger. However, because this is potentially a very useful feature, I have just committed a set of changes that add this capability, so if you check out and build the latest version of the LDAP SDK, you will find that the ldap-debugger tool has a new "--listenUsingSSL" argument that controls this.
Note that regardless of whether you're using the ldap-debugger tool or you have created your own listener via Java code, you need to ensure that you have a Java keystore that contains the SSL certificate that will be presented to clients. If the LDAP server you're using is Java-based (e.g., the in-memory directory server provided with the LDAP SDK), then you probably already have this. Otherwise, you'll need to create one. If you're just doing this for testing purposes, a self-signed certificate should be just fine (as long as the client trusts it, or is configured to blindly trust all certificates).