Symantec web security solutions: securing legacy LDAP authentication scenarios

Modern authentication scenarios for web access usually include federated identities with claims-based authentication (SAML, Oauth2, etc), which is rapidly becoming a de-facto standard, especially with rapid growth of BYOD devices on client side and SaaS apps on the server side. Inside corporate networks, Kerberos is still a valid (and secure) option, plus it’s possible to expose it to external (public) clients by using Kerberos Constrained Delegation (KCD) protocol transition.

However, in some legacy environments, customers will still have no other option but to go with good old LDAP server, where identities are checked against Active Directory LDAP or any other LDAP server (OpenLDAP perhaps).

Nice to know that Symantec web security technologies (Secure web gateway) can adapt to all of the above authentication scenarios: from legacy to modern identity, thus providing secure web access to users, whether they’re in the organization HQ, remote office or road warriors!

Here we’ll take a closer look at how flexible LDAP configuration with ProxySG solution can be. What follows are some notes while playing with various options with my colleagues.

LDAP authentication usually implies that the client and server (or in this case secure web gateway proxy) exchange the username and password in clear-text by using the HTTP BASIC mechanism, which is of course a security risk as anybody with a tap or packet capture access can sniff credentials for any user (including administrators) on the network. Additionally, the communication between the proxy and LDAP server (for ex. Active Directory Domain Controller) is usually left unsecured, which is the default configuration for LDAP.

So, 2 flows are usually left unsecured:

  1. Client -> proxy credentials, during BASIC authentication exchange
  2. Proxy -> LDAP server, during credential verification with LDAP server

The obvious idea might be to secure both transports via TLS, without changing the underlying mechanisms. Let’s see how this might be solved.

First of all, the LDAP configuration options on the ProxySG are completely flexible as each possible parameter is exposed in the GUI: from multiple LDAP realms (each containing its own set of parameters), Base DN (multiple entries possible with order precedence!), search user DN, configurable User and group attributes, Object classes for groups and users, etc. This makes it possible to connect to virtually any LDAP server out there, from the well known Microsoft Active Directory to more arcane solutions. It also allows to configure LDAP over SSL or TLS, making the transport secure.

Figure 1: options for an LDAP auth realm

Secure Proxy -> LDAP server communications

Now, to secure the proxy -> LDAP server flow, ProxySG offers a simple and flexible solution: a Device profile, which is a container having both a trusted certificates list (CCL) and optionally a client/public keyring if you want to secure the communication with client authentication as well (not only server verification). That way, you might have multiple LDAP realms (domains), each accessing LDAP server(s) in the realm with its attached device profile, as if you were in a multitenant scenario.

More details on how to configure ProxySG to talk to LDAP server  via TLS on this link.

Figure 2: SSL options for LDAP configuration, including device profile

Secure client -> proxy credentials transport

Securing the client -> proxy flow with TLS is more complicated but doable. If you use transparent proxy, a possible solution is documented here.

If you’re using explicit proxy, here’s the idea:

  1. the client requests a web page
  2. the proxy redirects the client via a HTTP 302 to a special “web server” hosted on ProxySG and referenced as Virtual URL in the LDAP Realm configuration. It is crucial that this “web server” or listener is of type HTTPS reverse proxy, which will ensure encrypted credentials on the wire.
  3. The virtual web server issues a HTTP 401 “authentication required” message used typically by web servers (called also origin style redirect), and the client submits the HTTP Basic credentials, but this time via HTTPS (TLS).
  4. Once authenticated, the client is placed in an authentication cache (based on IP or Cookie), for which you can define the timeout at the LDAP realm level (default is 15 minutes).
  5. The “web server” finally redirects the client back to the original requested URL from step 1, but this time the request is accepted and forwarded, as the client is in the credential cache.
  6. All subsequent requests are accepted without any authentication, until the credential cache timeout expires, at which time the client is re-authenticated as described above.

Here are the key steps to configure this:

Create a HTTPS reverse proxy (a web site or ssl listener); make sure to use a certificate keyring trusted by your web clients and preferably use the default port 443:

Edit your LDAP realm’s virtual URL so it points to the HTTPS reverse proxy created earlier:

Go to Visual Policy Editor and in your authentication rule, configure authentication mode to “Origin IP redirect”:

This will redirect unauthenticated clients (not yet in authentication cache) to the “web server” on the configured virtual url via HTTPS.

Things to note and gotchas:

  • If the client is not authenticated yet and its first request is HTTPS, the proxy will return an error: “Cannot use origin-redirect or form-redirect for CONNECT method”. That’s actually expected behavior as most modern browsers will consider inappropriate to return a 302 redirect on a CONNECT http proxy method (used when accessing HTTPS sites), see explanation here. As a workaround, you might customize the exception page displayed by ProxySG to coach users to click on a HTTP site first (perhaps an intranet portal link) or make sure the first page loaded when opening a browser is HTTP and not HTTPS.

  • we might have used “Origin Cookie redirect” instead of IP redirect, which would rely on a client cookie to check if the client is already in the auth cache or not. Using the IP address is probably safer as some clients might not accept cookies. Be aware that if the clients are behind a NAT device (appearing to the proxy as a single IP address), you’ll have no alternative but to use cookie redirect.
  • It’s important the certificate for the web server on the virtual url is trusted by clients, so you avoid any certificate warnings on client side.
  • The virtual url request should not be proxied but accessed directly by the browser, so make sure the virtual url hostname or IP is in the proxy exclusion list on the client (in the browser).
  • The virtual url hostname should of course be resolvable by the clients (hostname present in DNS).
  • As with everything on ProxySG, you might test and roll out this gradually by turning the “origin IP redirect” mode for certain clients, for ex. a range of IP address, or certain user agents, or for certain web site requests, etc.

And that’s it: no more clear text credentials roaming across the network!