Chapter 15. LDAP

Table of Contents

1. LDAP schema specification
1.1. Used objectclasses
1.2. Supported attributes
1.3. Common definitions for distinguished names
1.4. Special definitions for user certificates
2. Sourcecodeorganization
2.1. Structure of the code
2.2. The relevant commands
2.3. export-import.lib
2.4. ldap-utils.lib
2.5. OpenCA::LDAP

Be warned - this is a developer documentation which only documents the possibilities and technical background of OpenCA ldap caode but this is not a howto or a user documentation.

1. LDAP schema specification

1.1. Used objectclasses

Of course we will not list top here.

STRUCTURAL

  • country

  • device

  • inetOrgPerson (inherits from organizationalPerson)

  • locality

  • person

  • organization

  • organizationalPerson (inherits from person)

  • organizationalRole

  • organizationalUnit

AUXILIARY

  • dcObject

  • pkiCA

  • pkiUser

  • opencaUniquelyIdentifiedUser

  • opencaEmailAddress

  • opencaSCEPDevice

1.2. Supported attributes

If you are missing a special attribute for your installation then please contact us (openca-users@lists.sf.net).

  • dc

  • c

  • o

  • st

  • l

  • ou

  • unstructuredName

  • unstructuredAddress

  • cn

  • sn

  • emailAddress

  • serialNumber

1.3. Common definitions for distinguished names

The following table describes what we use for objectclasses and attributes if we insert a node in the LDAP tree. The least significant component of the distinguished name is the "LSC of the DN". This doesn't document the used auxiliary classes.

Table 15.1. Schema usage

LSC of the DNfilled attributesfilled attributes if presentobjectclass stack
dcdc top, dcObject
cc top, country
stst top, locality
ll top, locality
oo top, organization
ouou top, organizationalUnit
unstructuredNamecnunstructuredName, unstructuredAddress, serialNumber, st, l, outop, device, opencaSCEPDevice
unstructuredAddresscnunstructuredName, unstructuredAddress, serialNumber, st, l, outop, device, opencaSCEPDevice
cncncn, st, l, ou, mailtop, organizationalRole (opencaEmailAddress)
sncncn, st, l, ou, mailtop, organizationalRole (opencaEmailAddress)
emailAddresscncn, st, l, ou, mailtop, organizationalRole (opencaEmailAddress)
serialNumbercnserialNumber, o, ou, ltop, device

If we add a node to the directory tree then we add at every time to the objectclass stack the classes pkiCA and pkiUser. This is perhaps not the cleanest solution but it is safe for every possible configuration. If we add a node with the class organizationalRole then we add the auxiliary class opencaEmailAddress if an emailaddress is present.

1.4. Special definitions for user certificates

If we add a node for the subject of a normal certificate to the directory tree then we use modified objectclass stacks to support ldap browsers which search for a special emailaddress. We don't do this generally to return only a node of the tree if this node contain a certificate. This was a problem in several old releases of OpenCA.

Table 15.2. Schema usage for user certificates

LSC of the DNfilled attributesfilled attributes if presentobjectclass stack
cncn,snmail, o, st, l, outop, person, organizationalPerson, inetOrgPerson
sncn,snmail, o, st, l, outop, person, organizationalPerson, inetOrgPerson
emailAddresscn,snmail, o, st, l, outop, person, organizationalPerson, inetOrgPerson
serialNumbercn,snmail, o, st, l, outop, person, organizationalPerson, inetOrgPerson, opencaUniquelyIdentifiedUser

If the distinguished name doesn't contain an emailaddress but OpenCA detects an emailaddress in the subject alternative name then we use this emailaddress.