Operators from Active Directory or LDAP

Etminan can take a role from an operating-system group, so a bank with forty security admins does not keep a second list of forty people by hand. When HR disables somebody in the directory, they stop being able to log in to the verifier host, and with that they stop being an operator here.

This is off until you switch it on. With no group mapped, Etminan asks the operating system nothing and behaves exactly as it did before this page existed.

Etminan does not speak LDAP

There is no LDAP client in Etminan, no bind credential in its configuration, and no directory cache of its own.

Instead the verifier host is joined to the domain the way every other Linux server in your estate is, with sssd or winbind. The operating system then resolves a person to a UID and answers group membership, and it caches both. You already run that component and you already know how to operate it.

What Etminan adds is one mapping: an OS group grants a role.

What Etminan needs from your directory

Etminan reads nothing from the directory itself. It needs the host to be able to answer three questions, and how your directory is set up to allow that is your directory administrator's business, not this handbook's.

Etminan needs	Why	What you see if it is missing
A group whose members should hold a role	It is what gets mapped	Nothing to map
An account that may join a machine to the domain	The host has to become a member	Insufficient permissions to join the domain
The domain controller reachable by name, forward and reverse	Kerberos builds the service name from the host name; a missing PTR makes it build the wrong one	Server not found in Kerberos database during the join, even though the password was accepted
The controller's own ldap/ service principals present	The join authenticates against the directory's LDAP service	The same Server not found in Kerberos database, and kvno ldap/<dc-fqdn>@<REALM> fails from the controller itself

The last two are not things you configure in Etminan and not things we can fix from here. They are listed because the error you get is misleading — it says "insufficient permissions", and the permissions are fine.

We do not document your directory

There is no procedure here for creating a group, provisioning a controller, or repairing a service principal. Those differ between Active Directory, Samba and everything else, and a recipe that fitted one would quietly be wrong for another. What is above is what must be true; making it true is your directory administrator's work.

What to do on the Etminan host

This part is ours, and it is three steps.

1. Join the host to the domain with your normal tooling. On Debian and RHEL-family hosts that is realmd and sssd:

realm discover <your-domain>
realm join --user=<an-account-that-may-join> <your-domain>
realm list          # must show `configured: kerberos-member`

The verifier host needs to resolve the domain, so its DNS has to point at a domain controller. Etminan itself needs nothing from this step — it never talks to the directory.

2. Check what the host actually sees. Do this before touching Etminan, because the name you map has to be the name the host reports:

id <a-person-in-the-group>

uid=1426001105(max.mueller@example.test) gid=1426000513(domain users@example.test)
groups=1426000513(domain users@example.test),1426001103(etminan-admins@example.test)

The group name usually carries the domain

With sssd's defaults after a realm join, the group is etminan-admins@example.test, not etminan-admins. Map exactly what id prints. If you prefer the short form, that is an sssd setting (use_fully_qualified_names), and it is your choice — Etminan maps the string the host gives it either way.

3. Map the group:

etminan-verifier op directory map \
  --group 'etminan-admins@example.test' --role admin --scope '*'
etminan-verifier op directory list

--scope is required. One mapping can grant a whole department at once, so an omitted scope must not quietly mean every host. --scope '*' is the deliberate fleet-wide grant.

Mapping and unmapping are admin-only, and go through four-eyes wherever that covers the operator registry. A group mapping changes who may act, exactly like adding an operator by hand.

That is the whole of it. There is no local group to add anybody to afterwards — the mapping is what grants the role, and the daemon decides on the caller's UID. If you find an instruction to run usermod for an operator, it is out of date.

How a role is decided

1. An explicit op identity row for that UID wins.
2. Otherwise, the highest role among the mapped groups the person is in.
3. Otherwise nothing. An unmapped person gets no access, as before.

The audit row names the account and the group that carried the role — for example max.mueller (group sec-admins). Groups get re-mapped; a row that said only "admin" would not explain itself a year later.

If the directory is unreachable

Etminan keeps working. Attestation runs, checks run, and an operator who is logged in keeps working. The local UID-to-role store is what the daemon reads at runtime, and sssd handles the outage with its own cache — which is its job.

There is no configuration for this and nothing to switch on. It is a property of where the lookup happens.

What disabling an account does, and what it does not

A disabled directory account cannot authenticate, so it gets no session, so no process on this host carries its UID, so nothing reaches the daemon. That is where access ends — at login.

Three things survive a disable, and none of them is Etminan's to fix:

• A session that is already open. Disabling an account does not kill a running shell. Etminan's own session idle timeout is what stops a workstation left logged in from remaining an operator credential.
• sssd's offline cache. While the directory is unreachable, the cache that gives you outage tolerance will also let a disabled account log in. The cache lifetime is your setting, and it is a real trade-off in both directions.
• An SSH key in authorized_keys. It never consults the directory at all.

If offboarding has to be immediate, that is a host-hardening question — session limits and key management — not a directory-integration one. We would rather say so than let you believe otherwise.

Turning it off again

etminan-verifier op directory unmap --group sec-admins

Members lose the role at the next lookup. Explicit op identity rows are untouched. With the last mapping withdrawn, the operating system is not consulted again.