LDAPI autobind: authenticate as target DN

[tiran]

Is your feature request related to a problem? Please describe.

UPDATE tl;dr I would like to have the uid/gid mapping in a local, non-replicated DB and the effective user in a shared, replicated DIT. This improvement would allow FreeIPA to use autobind for services without pre-allocated and reserved uids across all servers in a cluster. See FreeIPA ticket https://pagure.io/freeipa/issue/8544#comment-696374 for more information.

Describe the solution you'd like

LDAPI autobind allows to authenticate by mapping the effective UID and GID of a process to an LDAP entry. Some UIDs and GIDs for system services are hard-coded and preallocated. Others are assigned randomly when a service is installed The Fedora project is reluctant to grant UIDs any more. The range of allocated UIDs is very limited. UID/GID may also be different on others OSes (e.g. Debian).

Therefore I like to request an extension to autobind feature. When a search for (&(uidNumber=<uid>)(gidNumber=<gid>)) return one entry and the entry contains a specific attribute of syntax type DN, the bind as the value of that attribute.

Example:

dn: cn=config
nsslapd-ldapientrysearchbase: cn=autobind,cn=config
nsslapd-ldapiauthenticateasdntype: authenticateAsDN

dn: cn=bind-dyndb-ldap,cn=autobind,cn=config
cn: bind-dyndb-ldap
uidNumber: 25
gidNumber: 25
authenticateAsDN: krbprincipalname=DNS/server.ipa.example@IPA.EXAMPLE,cn=services,cn=accounts,dc=ipa,dc=example

An LDAPI connect for 25:25 would bind as user krbprincipalname=DNS/server.ipa.example@IPA.EXAMPLE,cn=services,cn=accounts,dc=ipa,dc=example instead of cn=bind-dyndb-ldap,cn=autobind,cn=config. If the target entry does not exist, then authentication would fail. If an entry does not have authenticateAsDN then bind as the direct entry instead.

Describe alternatives you've considered Alternative would be proper support for referential integrity and memberof for cn=config backend. I assume that this would be harder to implement for you and less useful for FreeIPA.

Additional context n/a

[Firstyear]

" Others are assigned randomly when a service is installed"

This already kind of breaks your suggestion doesn't it? That the id is randomly assigned per server. This means it could have UID 20 on one server, and 56 on another. So what UID would we store in the directory for the bind? What happens when these uid's begin to overlap and conflict? That would become a security issue where a different server could then authenticate a service to something else (ie httpd could auth as dns or something like that). Systemd dynamic users also comes to mind here ...

So I think just the fact that these random/dynamic user id's exist, and they are per service, that this is not really workable :(, and probably does open the door to security risks. uid numbers as a "security id" means that must be static and correct through the fleet of servers hosting directory server for us to be able to trust them with autobind.

I think what I would want to ask is "what is the problem you are trying to solve" here because this suggestion doesn't exist in a vacuum, and clearly you have a problem in mind you are trying to fix.

Thanks,

[tiran]

This already kind of breaks your suggestion doesn't it? That the id is randomly assigned per server. This means it could have UID 20 on one server, and 56 on another. So what UID would we store in the directory for the bind?

That's correct. That's why we cannot create the autobind mapping entry in a replicated database and choose to store the mapping entries in the cn=config backend. The cn=config database is local and does not get replicated. That allows each and every server to have a uid/gid mapping that reflects local uids and gids for system account. For example server1 can map 25:25 to cn=bind-dyndb-ldap,cn=autobind,cn=config and server2 can map 53:53 to cn=bind-dyndb-ldap,cn=autobind,cn=config. Although the entries have the same DN they are not related because the database is not replicated. That avoids any cross-machine conflicts.

It doesn't work with local dynamic users like systemd DynamicUser=yes. IPA doesn't use dynamic users for any service yet. In the future DS could add SO_PEERSEC based authentication to map SELinux context to a user.

My proposal would enable us to map uid 25:25 on server1 and only on server1 to krbprincipalname=DNS/server1@REALM,.... 25:25 on server2 would not get mapped to the principal. The combination of non-replicated autobind configuration with autobind target alias would allow us to replace keytab-based GSSAPI authentication with SO_PEERCRED based authentication. Services then can authenticate securely before KDC is available.

[mreynolds389]

f965835a5..77e1e4146 389-ds-base-1.4.4 -> 389-ds-base-1.4.4