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 )
"Sean Burford" unix.gurus@gmail.com writes:
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.
This would be the easiest way, just create a ldif file with an empty dn, objectClass OpenLDAProotDSE and cn with hostname as value, but cn is a user attribut and not an operational attributtype, thus cn would not be presented when searching all operational attributes of rootDSE.
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.
You may run slapd(8) listening on a dedicated IP, this IP will be reported in cn=monitor.
-Dieter
openldap-technical@openldap.org