ldap389ds

How to add ldapPublicKey schema to 389DS

I have installed 389 Directory Server 2.0.0 on Oracle Linux 9 and am migrating from another VM that runs OpenLDAP server 2.4. I have managed to copy all the user entries by exporting and importing.

389DS does not have ldapPublicKey schema out-of-the box. Neither did openldap-servers. Going by the documentation and Google, I added these lines to /etc/dirsrv/slapd-<myinstance>/schema/99user.ldif:

dn: cn=schema
objectClasses: ( 1.3.6.1.4.1.24552.500.1.1.2.0
  NAME 'ldapPublicKey'
  SUP top
  AUXILIARY
  DESC 'MANDATORY: Service that accepts LDAP public keys'
  MUST sshPublicKey
  X-ORIGIN 'user defined' )
dn: cn=schema
attributeTypes: ( 1.3.6.1.4.1.24552.500.1.1.1.13
  NAME 'sshPublicKey'
  DESC 'MANDATORY: OpenSSH Public key'
  EQUALITY octetStringMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
  X-ORIGIN 'user defined' )

When managing the instance using Apache Directory Studio,

  1. Imported user entries should the sshPublicKey attribute as text instead of binary data

  2. Adding a new attribute does not show sshPublicKey as an available attribute

  3. Adding a new entry from scratch does not show ldapPublicKey as a structural class

In the 99user.ldif, I have also tried changing ldapPublicKey class from AUXILIARY to MANDATORY.

Solution
    1. Imported user entries should the sshPublicKey attribute as text instead of binary data

    The attribute shows as binary data because that's literally how you defined it in the schema. The syntax OID 1.3.6.1.4.1.1466.115.121.1.40 is "Octet string", i.e. opaque 8-bit-byte string without a defined structure.

    Given that SSH public keys are UTF-8 strings (mainly ASCII but let's use UTF-8 to allow for the comment), the attribute should rather have 1.3.6.1.4.1.1466.115.121.1.15 aka "Directory string" (aka Unicode string) as its syntax.

    Accordingly, the equality rule should be changed from octetStringMatch to caseExactMatch.

    It would also be a good idea to have SUBSTR caseExactSubstringsMatch as that would allow you to search e.g. for all users that have an obsolete DSA key using (sshPublicKey=ssh-dss*). Without an SUBSTR(INGS) matching rule, this would always give 0 results.

    After making this change you'll need to refresh the client cache as described below. (Also, you can add custom renderer and editor overrides in Apache Directory Studio preferences, but better define the attribute right in the first place.)

    pedantry
    Also, your descriptions are wrong because an auxiliary objectClass is by definition not mandatory, and an attribute by itself cannot decide whether it is mandatory or not (some objectClasses can have it as MUST while other objectClasses can have it as MAY at the same time), so the MANDATORY: prefixes are meaningless.
    "Service that accepts LDAP public keys" also doesn't make sense given that 1) it deals with SSH public keys and not LDAP public keys (which would be X.509 certificates); 2) it lets you define entities that have public keys, which has nothing to do with whether those entities accept keys.
    1. Adding a new attribute does not show sshPublicKey as an available attribute

    This is a client issue. Being able to add the user entry at all indicates that the attribute schema definition is loaded into the server – it's just the client that has cached an old schema.

    In Apache Directory Studio, connect to your server, then go to "LDAP → Open Schema Browser" and click the yellow "Reload Schema" button in the top-right corner. The app caches the schema upon first connection and does not automatically detect changes.

    1. Adding a new entry from scratch does not show ldapPublicKey as a structural class

    The class doesn't show as structural because it is defined as AUXILIARY in your schema definition, which is the opposite of STRUCTURAL.

    The class also cannot be a structural class, because you're trying to attach it to user entries, and user entries already have a structural class (generally the inetOrgPerson class). An entry cannot have more than one 'branch' of structural classes, so if you were to make ldapPublicKey structural, it could no longer be combined with inetOrgPerson.

    You could in theory make ldapPublicKey structural with inetOrgPerson as its superior, but that makes no sense semantically – a "public key" is not a subclass of a "person".

    If you want to make the attribute mandatory, make a new structural class that inherits from your existing "user" class (for example, foocorpPerson) and additionally has sshPublicKey as MUST – as well as any other attributes that Foo Corp. users are required to have.

    NAME macrosoftPerson SUP inetOrgPerson STRUCTURAL MUST ( sshPublicKey $ someAttr )

    To be able to generate your own OIDs, you can get a Private Enterprise Number assignment from IANA under the 1.3.6.1.4.1 root, or you can use Microsoft's 1.3.6.1.4.1.311.21.8.a.b.c… which Active Directory Certificate Services uses for randomly-generated OIDs.

    If you don't want to fill the form, technically you can "repurpose" someone else's OID branch and most likely nobody will notice, but I wouldn't recommend doing so in production.