ldapPublicKey in 389DS: Are You Doing It Right?

• 🛡️ Using ldapPublicKey in 389 Directory Server centralizes SSH key management for secure, large infrastructure.
• ⚙️ 389DS supports loading schemas on the fly, which cuts down on downtime during schema changes.
• 🕵️ Failing to restart client-side services like sssd can cause LDAP schema changes to be ignored.
• 🔐 TLS is mandatory for secure transfer of SSH keys via LDAP to keep them from being seen by others.
• 📂 Correct OID formatting and making sure attribute names don't clash prevent common schema import errors.

Centralized SSH key management is important for keeping access controls secure and working well in large setups. By adding the ldapPublicKey schema into 389 Directory Server (389DS), administrators get a strong, standard way to store and give out SSH public keys right from an LDAP directory. This article offers a detailed guide to setting up ldapPublicKey correctly in 389DS—from loading schemas and fixing problems to good security steps and ways to automate things.

What is the ldapPublicKey Schema?

The ldapPublicKey schema is a standard way to store SSH public keys in an LDAP directory. RFC 4523 defines this schema. It gives a steady structure that lets SSH services and agents get public keys right from LDAP queries.

This is very important for groups that manage hundreds or thousands of systems and users. In these cases, updating authorized_keys files by hand is not practical and not safe.

Key Attributes in the ldapPublicKey Schema

Understanding each attribute in the schema helps make sure it is set up right:

• objectClass: ldapPublicKey
  This is a structural or auxiliary Object Class that lets you store SSH keys as part of an LDAP entry.

• sshPublicKey
  This is an attribute that can hold many values. It has the user's SSH public key(s). These should be formatted like OpenSSH standards (e.g., ssh-ed25519 AAAAC...).

• uid
  This is the unique ID that links the LDAP entry—and thus the SSH key(s)—to a specific user or account.

These attributes let you look up keys from one place when tools like OpenSSH are set up to work with LDAP.

Why Use 389 Directory Server for ldapPublicKey?

389 Directory Server (389DS) is a business-grade, open source LDAP server made by Red Hat. It has become a very flexible and works for many users as a directory solution. It is good for managing identities and credentials for Linux/UNIX systems.

Main Benefits of 389DS

• Schema System that works in parts
  389DS supports schemas that can change on the fly. This lets administrators add or change schema definitions without restarting the server. This is a big plus for places where servers must always be up.

• Works fast and for many users
  It is made to work well with many identities. 389DS can handle thousands of connections at the same time, which makes it good for big setups.

• Strong system and help guides
  Red Hat supports 389DS. It has well-made command line and visual tools, detailed access controls, ways to copy data, and good help guides.

• Adding your own schemas
  Whether you are adding external schema packages like ldapPublicKey or making your own, 389DS gives you simple ways to add more features.

Groups that want to manage SSH keys from one place using LDAP will find 389DS helpful. It mixes business features with open-source flexibility.

How to Add the ldapPublicKey Schema to 389DS

Adding the ldapPublicKey schema into 389DS correctly needs careful setup of the schema file and then loading it. Here is a step-by-step guide.

Step 1: Create the Schema Definition File (60ldapPublicKey.ldif)

Create a file named 60ldapPublicKey.ldif with the following contents:

dn: cn=schema
objectClass: top
objectClass: ldapSubentry
objectClass: subschema
attributeTypes: ( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME 'sshPublicKey' DESC 'OpenSSH Public Key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
objectClasses: ( 1.3.6.1.4.1.24552.500.1.1.2.0 NAME 'ldapPublicKey' DESC 'OpenSSH LPK objectclass' SUP top AUXILIARY MAY ( sshPublicKey $ uid ) )

🚨 Important: All entries must follow correct LDIF syntax. This means:

• No trailing spaces at the end of lines
• Multi-line values must begin with a space-character in the second line
• AttributeTypes and ObjectClasses must have globally unique OIDs

Step 2: Load the Schema

You have two ways to apply the schema:

Option A: Use ldapmodify (Best for Production)

ldapmodify -x -D "cn=Directory Manager" -W -f /path/to/60ldapPublicKey.ldif

This method means you don't need to restart the server and makes sure the schema loads right away.

Option B: Put File in Schema Directory (Not Recommended for Live Systems)

Place the file in the schema directory:

/etc/dirsrv/slapd-YOUR_INSTANCE/schema/60ldapPublicKey.ldif

And then restart the 389DS instance:

systemctl restart dirsrv@YOUR_INSTANCE

Use this method only when you first set things up or during maintenance times, because it stops the service.

Common Problems When Adding ldapPublicKey Schema

Even small errors can stop the schema from being set up or used. Here are common problems to avoid.

Malformed Object Identifiers (OIDs)

Every attribute or object class must have a valid ASN.1-style OID. Example of a correct OID: 1.3.6.1.4.1.24552.500.1.1.1.13
Avoid non-numeric values or duplication of existing OIDs already in use in your schema.

Attribute Conflicts With Existing Schemas

Make sure sshPublicKey is not already defined in any other schema you have brought in. If attribute definitions clash, they will be turned away, leading to schema loading problems.

LDIF Format Errors

Small mistakes, like forgetting a space in multi-line parts or wrong capitalization for attributes, will cause errors that are hard to understand. Use ldapmodify -d 1 for troubleshooting info when loading.

Avoiding Client-Side Caching Issues

After schema updates or adding new user entries with ldapPublicKey, client machines might still use old data. Restarting or flushing directories helps show changes right away.

Services to Restart or Reset

• sshd: If SSH keys are not being pulled, check sshd_config and restart.
• sssd: If SSSD is used for LDAP access, restart it to clear its cache.
• Name Service Caches (nscd or systemd-resolved): These might hold old LDAP entries or DNS info for linked domains.
• Local keyring caches or nslcd: Clear these by hand if they are set up.

Update or add the correct LDAP URI and base settings in your /etc/ssh/sshd_config:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

This is very important for systems that use SSSD's LDAP part to give authorized keys to the SSH daemon.

Testing the Setup with ldapsearch

Use ldapsearch to confirm that LDAP entries contain the new attributes and schema has been applied:

ldapsearch -x -b "dc=example,dc=com" "(uid=john.doe)" sshPublicKey

Expected output:

dn: uid=john.doe,ou=users,dc=example,dc=com
sshPublicKey: ssh-ed25519 AAAAC3N... user@host

Then attempt a login to confirm that public key authentication works:

ssh john.doe@host.example.com

If the key is valid and matches, the login should occur without a password when sshd is correctly configured.

Fixing Schema Problems

Schema issues often give hard-to-understand error messages. Here’s how to understand them:

🔍 Make a list of active object classes to check again:

ldapsearch -x -s base -b "cn=schema" "(objectClass=*)" objectClasses

Search through the list to make sure ldapPublicKey is there.

Managing SSH Keys Through LDAP

The point of adding the ldapPublicKey schema is for easier management from one place. To keep it working well for a long time and secure, automate and standardize how keys are managed.

Good Practices

• 📏 Standardize Key Types — Use ed25519 for current security and small size.
• 🔄 Automate Key Rotation — Use scheduled jobs or CI/CD pipelines (with ldif files or automation tools like Ansible).
• 🔔 Monitor Key Updates — Use slapd logs or audit tools to tell you about key changes.
• 🔐 Use ACLs — Make sure only the right roles can write to the sshPublicKey attribute.

Automating Key Setup

You can automate key adding with the following command:

ldapmodify -x -D "cn=Directory Manager" -W <<EOF
dn: uid=john.doe,ou=users,dc=example,dc=com
changetype: modify
add: sshPublicKey
sshPublicKey: ssh-ed25519 AAAAC3NzaC1... user@host
EOF

This makes it easy to use with setup management systems or scripts.

Security Things to Think About

It’s very important to note that ldapPublicKey is for saying who can access, not for proving who someone is. SSH itself does the authentication using the key, but LDAP only helps give out the list of authorized keys.

Good Security Steps

• 🛡️ Use TLS — Always connect to your LDAP server over ldaps:// or turn on startTLS. Traffic that is not encrypted can let key data be seen.
• 🔐 Use ACLs — Only certain admin groups should be able to write to the sshPublicKey field.
• 🧩 Log Changes — Turn on audit logs in 389DS to keep track of schema and entry changes.
• 🔄 Rotate Keys Regularly — Set rules for how long keys last that make sure keys change often.

Other Options Besides ldapPublicKey

Not everyone needs or gets something from ldapPublicKey. Bigger or more complex setups might need solutions made just for them.

Options

• FreeIPA
  This is an identity management platform built on 389DS, Kerberos, and other parts. It gives you built-in SSH key and certificate management.

• Keycloak
  Keycloak is mainly for web and app single sign-on. But you can add to it with your own parts to handle the SSH key process.

• Your Own Agents or Scripts
  Write a go-between layer that works with databases or APIs to add keys right away into authorized_keys.

These other options give more features like auditing, key signing, and limits for each session.

Keeping Track of Schema Versions in 389DS

As your infrastructure changes, your schema needs might also change. Keep a clear way of working to handle schema changes.

Tips for Schema Management

• 📑 Keep LDIF Files Under Version Control — Store all schema definitions in a place like Git for tracking.
• 🔄 Use Schema Loading on the Fly — Change schemas while they are running to avoid restarts when you can.
• 🆔 Never Reuse OIDs — Each set of changes must have new, different OIDs.

Look at Red Hat’s official guides to change schemas safely when they are in use.

Final Thoughts: Getting ldapPublicKey Right in 389DS

When set up correctly, ldapPublicKey in 389 Directory Server can be a strong, scalable, and secure way to give out SSH public keys. Managing things from one place not only makes things safer but also makes work easier.

Checklist for Checking the Setup

✅ Schema added and checked with ldapsearch
✅ Test user created with ldapPublicKey and sshPublicKey attributes
✅ SSH setup updated to use LDAP authorized keys
✅ TLS turned on for LDAP connection
✅ Write permissions limited using ACL
✅ Client caches cleared and services restarted

A successful setup of ldapPublicKey in 389DS makes sure SSH key access is steady and does not hurt security or how well things work.

Ready-to-Use LDIF Templates

Schema Definition LDIF (60ldapPublicKey.ldif)

dn: cn=schema
objectClass: top
objectClass: ldapSubentry
objectClass: subschema
attributeTypes: ( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME 'sshPublicKey' DESC 'OpenSSH Public Key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
objectClasses: ( 1.3.6.1.4.1.24552.500.1.1.2.0 NAME 'ldapPublicKey' DESC 'OpenSSH LPK objectclass' SUP top AUXILIARY MAY ( sshPublicKey $ uid ) )

Example User Entry

dn: uid=john.doe,ou=users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: ldapPublicKey
uid: john.doe
sshPublicKey: ssh-rsa AAAAB3Nz... insert key here ... user@host

References

• IETF. (2006). RFC 4523: LDAP Schema Definitions for X.509 Certificates. Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/rfc4523

• Red Hat. (n.d.). 389 Directory Server Documentation. https://access.redhat.com/documentation/

• OpenSSH. (n.d.). Using LDAP public keys for SSH Authentication. https://man.openbsd.org/sshd_config