We currently run our openLDAP service on our campus behind an F5 load
balancer which preserves the IP address of the connecting client through
to the backend servers, which we rely on for a small amount of IP
address based authorization differentiating between on-campus and
However, management is strongly pushing us to migrate the service to the
Amazon cloud, using Amazon's load balancer. Unfortunately, Amazon's load
balancer only supports client NAT for directing connections to the back
end servers, so they have no idea who the actual client is, it just
appears to be the load balancer itself.
Amazon's solution for that is to support HAProxy's proxy protocol in
their load balancer:
Basically, this is an in band signaling mechanism that inserts an
additional header in the initial connection data containing the original
client IP address/source port and destination IP address/source port,
allowing the server to utilize that information for the connection
rather than the actual details of the network connection from the proxy
This requires support from the application running on the server, as it
must remove and process that proxy header from the connection data
before moving on with whatever data would normally be passed on the
There are some fair number of services that support this proxy,
including of course HAProxy itself, such as the apache web server and
the postfix mail server.
openLDAP does not support the protocol, and I was unable to find any
past discussion of it.
I was wondering if this feature would be something acceptable for
inclusion to openLDAP, or if from an architectural perspective it would
be considered undesirable.
In general, I believe applications listening on a specific port are
either expecting the proxy protocol header, or not, I do not think it is
dynamically determined. As such, from an implementation perspective, my
initial thought is that it would be implemented in terms of
configuration as an additional URL specified via the -h option,
something like "ldapp://" or "ldap_p://", "ldapsp://" or "ldaps_p://" or
whatever seems most desirable. A server might listen on the standard
ports accepting only proxied connections, or it might listen for normal
connections on the standard ports and for proxy connections on
When a connection is accepted on a port marked as requiring the proxy
protocol, it would read and process the proxy header to populate the
appropriate data structures regarding connection, and then move on as it
normally would to deal with the connection.
If this feature is of interest, I will probably spend a little time
poking at it and seeing how much trouble it will be to implement.
After reading the slapo-constraint man page and searching online for a
possible solution it is clear that the overlay doesn't conveniently allow
setting a constraint with a negated regex.
The root cause is that negative lookahead isn't supported by extended POSIX
regex. One could argue that the complement of a regular language is itself
regular again and therefore it is certainly possible to write a regex that
doesn't allow certain values, however any regex of this sort quickly becomes
Taking grep as an example (i.e. --invert-match), I propose adding a constraint
type that allows using a regex in a negated way. When a match is found a
constraint error is raised. Looking at the constraint overlay code it seems
pretty trivial and I am willing to submit myself a patch that allows setting
constraint_attribute mail negregex ^.*(a)somedomain\.com$
I already have an initial implementation and first tests seem to work as
intended. Would such a patch be accepted? If so, could anyone guide me with
getting the patch merged?
Thanks in advance,