ldap

One of the beauties of LDAP is how simply it lets the user or application perform searching. The various attribute types hint how to intelligently perform searches such as case sensitivity with strings, whether dashes should be treated as relevant characters in the case of phone numbers, etc... However, there are circumstances when you need to override this intelligence and make your search more or less strict. For example: in the case of case sensitivity of a string. That is the purpose of the extensibleMatch.

Look at this bit of schema:

On a particular instance of OpenGroupware Coils the switch from an OpenLDAP server to an Active Directory service - which should be nearly seamless - resulted in "Failure to apply LDAP pages results control.". Interesting, as Active Directory certainly supports paged results - the 1.2.840.113556.1.4.319 control.

But there is a caveat! Of course.

All the interesting objects in an Active Directory DSA have an objectSID which is used throughout the Windows subsystems as the reference for the object. When using a Samba4 (or later) domain controller it is possible to simply query for an object by its SID, as one would expect - like "(&(objectSID=S-1-...))". However, when using a Microsoft DC searching for an object by its SID is not as straight-forward; attempting to do so will only result in an invalid search filter error.

So you have a lovely LDIF file of Active Directory schema that you want to import using the ldbmodify tool provided with Samba4... but when you attempt the import it fails with the error:

Error: First line of ldif must be a dn not 'dn'
Modified 0 records with 0 failures

Eh? @&^$*&;@&^@! It does start with a dn: attribute it is an LDIF file!

Once you cool down you look at the file using od, just in case, and you see:

LINUX has long been plagued with a rather lousy identity management scheme. Beyond the limitations of POSIX's getent and related calls [which can be very inefficient] the attempts to stub in network-aware identity services such as LDAP have only piled onto the rough edges. NSCD attempted to work around performance problems via caching - and did not do very well. Then was NSLCD the next evolution of NSCD which was better, but still inflexible. Identity management in more complex networks is a tedious business and what administrators need more than anything else is flexibility.

With either a Windows Active Directory server or a Samba4 Active Directory server very little information is exposed for anonymous searches via LDAP. This means every search has to bind. Simple binds are insecure and in many cases not supported - for good reason, they are hopelessly insecure. But often times one doesn't want to bother with Kerberos (even as great as Kerberos is) due to ticket expiration, keytab paths, etc...