Identifying replicas behind a load balancer

["Sean Burford" <unix.gurus@gmail.com>]

Hi,

To help with troubleshooting I would like to identify my replicas through
an ldap search, even when they are behind a load balancer.  I was
wondering what method and attribute other people generally use for this
purpose.

The RootDSE may be unique for each host, I can add a RootDSE config
line to slapd.conf to insert an ldif into the root DSE, so it seems to
be the ideal spot for per server identification.

Other spots include cn=monitor, cn=config, cn=Subschema or the main
directory tree.  The monitorConnectionPeerAddress attribute in
cn=monitor isn't useable for identifying the server, since the address
appears as IP=0.0.0.0:389.  cn=config isn't generally accessible so
also isn't suitable.  The subschema could conceivably be twisted for
this purpose.  The main directory tree is replicated so is not
suitable for identifying unique servers.

The RootDSE schema specifies that it may have a cn.  OpenLDAP does not
provide one by default.  Is it safe to use cn=hostname.domain.name?

It seems easiest to use CN for the host name, if it isn't earmarked for
something else in the RootDN.

The alternative would be to supplement the rootDSE with one or more
new attributes.  I've had a look at how Active Directory and Novell
Directory Service identify servers.  They both use attributes with
similar names and definitions.  Active Directory has three attributes
that are used in the root DSE to identify the host. Novell
Directory Service has the same three attributes with very similar
names and equivalent descriptions/usage.  The attributes
are:
* dnsHostName: The DNS name of this DC.
* serverName: DN for the server object for this directory server as
defined in the Configuration container.
* ldapServiceName: The UPN (User Principal Name) of the domain
controller hosting this instance of RootDSE. Computer objects are just
special forms of User objects, so they can have UPNs. The dollar sign
is Microsoft shorthand dating back to classic NT and SAM. It indicates
a hidden or secret object.
eg:
$ ldapsearch -x -W -D unix.gurus@example.com -H ldaps://dc.example.com
-b "" -s base serverName dnsHostName ldapServiceName
dnsHostName: dc.example.com
serverName: CN=DC,CN=Servers,CN=Configuration,DC=example,DC=com
ldapServiceName: example.com:dc$@EXAMPLE.COM

The schema for these attributes is described in various places.  The
existing schema is somewhat unsatisfactory with the dnsHostName OID
(1.2.840.113556.1.4.619) being a duplicate of the lazy commit control
OID and serverName syntax being a Directory String rather than a
Distinguished Name.

For my testing I've defined the following non standard attributes.
There doesn't seem to be a need for an equality matching rule since
these are single valued rootDSE attributes:
# Non standard AD dNSHostName attribute (defines a max length in the syntax)
attributetype ( 1.2.840.113556.1.4.619 NAME 'dNSHostName'
       SYNTAX '1.3.6.1.4.1.1466.115.121.1.15{256}'
       DESC 'DNS name of the directory server hosting this RootDSE.'
       SINGLE-VALUE )
# Non standard AD serverName attribute (DN syntax instead of Directory String)
attributetype ( 1.2.840.113556.1.4.223 NAME 'serverName'
       SYNTAX '1.3.6.1.4.1.1466.115.121.1.12'
       DESC 'DN for the server object for this directory server.'
       SINGLE-VALUE )

-- 
Thanks,
Sean Burford