#6464 [RFE] Allow proxying LDAP traffic over HTTPS
Opened 7 years ago by dpal. Modified 7 years ago

Use case:

Environment wants to deploy IdM in DMZ with trust setup with AD without exposing AD and not opening any ports to AD because it is against a security policy. The acceptable solution would be to make LDAP proxy information over HTTPS in the similar way how KDCproxy does it.


In a IdM-like scenario clients contact the IdM server which acts as a proxy for LDAP requests already.
A proxy over HTTPS would require changes to client libraraies, and would have issues with GSSAPI authentication for example. It would also have issues dealing with LDAPS.
LDAP is a fundamentally different protocol from krb5, and cannot as easily be proxied that way.

Windows clients won't do it for example, they know which servers are AD and which are not so they will not contact the proxy in the first place. But assuming we can configure them to do it, they use GSSAPI for authentication, which the proxy cannot handle transparently (same for IPA clients, but for those we do not need a proxy, as an IPA server already is the single point of contact for clients, so a proxy is not needed).

We could simply forward all packets to the AD servers, w/o even looking at them but then it isn't much of a proxy, and it is the same as firewall punching.

It is a tunnel that allows to forward LDAP traffic over HTTPS from a specific client i.e. IPA not just any client.

I think it was not clear. I suggest teaching only IPA to use it when it talks to AD so that the change is only in one place/path. Clients will talk to IdM using LDAP as they are now without any changes and IdM will talk to AD but the customer would not need to poke a hole in his FW. I think it is a very simple solution that needs to work only in one specific case.
Let us not over-complicate things and make all LDAP clients work with such proxy, one would be enough. Since it is a much simpler use case it can be a special component on IPA that will wrap and forward LDAP traffic over HTTPS.

Can we use HTTP/2 or websocks?

Replying to [comment:4 cheimes]:

Can we use HTTP/2 or websocks?

Whatever works and solves the problem. The simpler the better.

Please add description of what clients would use this, in exactly what configuration.

As an administrator deploying IdM in DMZ I want to close all access from DMZ to the internal network for any clients and servers that are in DMZ. My AD is inside and I want to use trust so I can expose internal accounts to the systems in DMZ. I am OK with using HTTPS to proxy traffic. I do not want to open an LDAP port at all since it is against the policy and thus nearly impossible to do. If allthe Kerberos and LDAP traffic between IdM and its clients in DMZ and AD can be proxied over HTTPS without opening any new ports I solved my challenges.

Is this good enough?

Metadata Update from @dpal:
- Issue assigned to someone
- Issue set to the milestone: Ticket Backlog

7 years ago

Login to comment on this ticket.

Metadata