LDAPI autobind authentication for services#
This design proposed to use LDAPI autobind for some internal FreeIPA services, so they can be started and used before KRB5 KDC service is operational. The proposal makes use of 389 DS’ existing LDAPI autobind implementation and new LDAPI autobind DN rewriter feature, which will be available in early 2021.
LDAPI autobind is a form of authentication that uses the effective
UID and GID of a process as credentials. It uses
of unix socket
connection and SASL EXTERNAL mechanism. Autobind enables secure and
fast authentication for local services without using KRB5 KDC.
LDAPI autobind does not depend on Kerberos/GSSAPI. This fact permits services to authenticate and operate before KRB5 KDC is up and running. For example DNS services can be started before KDC, so a time sync daemon can synchronize clocks before KDC starts.
It’s faster than GSSAPI. On a test system
-Y EXTERNAL takes around 12ms real time. On the same system
-Y GSSAPI over LDAPI with a cached service ticket takes between
20ms to 500ms real time.
On Fedora and RHEL-based systems, FreeIPA’s keytabs are not only
protected by DAC permissions (discrete access control, also known as
Unix file permissions) but also by SELinux’s mandatory access control.
named.keytab is only readable by user
group members of group
named and processes that are
allowed to open files with SELinux type
authentication no longer verifies the SELinux context of a process.
It is possible to retrieve the security context of a peer process
SO_PEERSEC, but 389-DS does not implement the feature.
The risk is negligible for BIND named. Most process are allowed to
read files with
etc_t any way.
SO_PEERCRED based authentication works across containers if and
only if the 389-DS server process and LDAP client process can share a
mount point and a common user namespace. The mount point is required
to share the Unix socket file of the 389-DS process. The user namespace
must be shared, because the Kernel translates UID and GID numbers
between namespaces. Disjunct namespaces result in UID/GID
BIND named service, so
chronydcan be started before KDC.
krb5kdc and kadmin service (after dropping root privileges)
ipa-custodia (after dropping root privileges)
The implementation makes use of the new DN rewriter feature for
autobind. The feature enables FreeIPA to store the UID/GID mapping in
the local, non-replicated
cn=config backend and then map succesful
binds to a DN in the replicated domain database. The approach has two
FreeIPA does not depend on reserved and uniform UID/GID allocation across all servers. Each server can map its local UID/GID assignment to a principal.
FreeIPA can map UID/GID combination to a host-specific service principal. For example server
srv1can map UID
srv2can map the same UID and GID to its principal
LDAPI mappings, search base for UID/GID, and mapping base for
nsslapd-authenticateAsDN must be configured in
LDAPI DN rewriter feature comes with a new object class for mapping UID/GID to another DN. For example a mapping for BIND named would look like this:
NOTE 389-DS does not enforce referential integrity in
nsslapd-authenticateAsDN can reference DNs that do not exist yet. A
missing target results into authenticate error.
reload LDAPI mappings#
389-DS has an internal cache for LDAPI mappings. The cache must be
refreshed after mapping are added, removed, or changed. A refresh can
be accomplished by either restarting the server process or running the
reload ldapi mappings task. The implementation detail will be
handled automatically by new API and
backup / restore#
It is possible that UID or GID can change, when a server is reinstalled
and restored from a backup.
ipa-restore will refresh all mappings