The OpenLDAP server we use is behind the DMZ (i.e. within the corporate network). In order to protect access to that, I have an OpenLDAP proxy in the DMZ to which our clients connect. This proxy utilizes the LDAP-backend to transparently “feed” incoming requests into our network to our corporate LDAP directory servers and translates requests using the suffix and suffixmassage capabilities. So far everything has worked perfectly well. Famous Last Words™ During the change that we performed yesterday morning (was it only yesterday?), we simultaneously brought the version of the OpenLDAP proxy (the OpenLDAP server with the ldap-backend) up to the next best release (2.2.13), as dictated by our Linux distribution. This is not the latest OpenLDAP server software, but that which is issued by RedHat, unfortunately way behind the current version. (I have a colleague who appreciates it when I don’t fiddle with new software, but instead use packaged versions. Unfortunately I behaved. ;-) ) The problem only turned up now, because this version supports so-called LDAP controls which the client might utilize to “tune” its operation. In effect, when Outlook queries our server, it receives (from that server) a control named 1.2.840.113556.1.4.319 which signifies “paged results”. Outlook then queries the LDAP server and sets this control to be “critical”, meaning that if the server (that originally said it would support it) suddenly doesn’t support it, Outlook should fail. It did. ;-) ( code sample ) Outlook first does a base search with an empty DN for objectClass, supportedControl and supportedCapabilities and normally gets this from our server:

structuralObjectClass: OpenLDAProotDSE
namingContexts: o=whatever
namingContexts: ou=someplace,o=whateverelse
monitorContext: cn=Monitor
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.2.840.113556.1.4.1413
supportedControl: 1.2.840.113556.1.4.1339
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.826.0.1.334810.2.3
supportedLDAPVersion: 2
supportedLDAPVersion: 3
supportedSASLMechanisms: DIGEST-MD5
subschemaSubentry: cn=Subschema

The reason for the failure is that the LDAP backend of OpenLDAP (at least in the version we are now using) doesn’t support the paged-results control; it doesn’t pass the control to the origin server (i.e. the one “inside”), so it ignores the paged-control, or rather issues an error 0x12 (text=control unavailable in context) and simply stops. What I have now done, after actually identifying the issue (difficult when SSL is in operation ;-) ) is to simply deny access to any controls at all by adding an ACL to the ldap backend:

access to dn.regex=".*" attrs=supportedControl
   by * none

Outlook will therefore not see any controls being returned by our front-end server as they are actually filtered out (the supportedControl attribute types above don’t reach the client) so it will simply continue. I hope. There is another solution I found later on: BUG: Outlook 2002 and 2003 cannot query some OpenLDAP Servers, but I cannot imagine my Outlook customers wish to fiddle with their registries… ;-)

LDAP, Mail, and Linux :: 21 Jun 2007 :: e-mail