goauthentik / goauthentik/authentik
Kerberos and LDAP sources do not create source connections for existing users
- Dominant language
- Python
- Stars
- 25.6k
- Forks
- 2k
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 651
Description
### Describe the bug
A Kerberos source with "Link to a user with identical username" does not create source connections for existing Authentik users.
Therefore, Authentik does not use their Kerberos passwords even after a "successful" sync of the Kerberos Source.
#21326 describes a similar problem with (probably) the same root cause.
The same problem also applies to the LDAP source. So when LDAP and Kerberos are used together, new users get linked to either LDAP or Kerberos, depending on which source enrolled them.
### How to reproduce
1. Create a user in Authentik and Kerberos (with identical usernames)
2. Create a Kerberos Source with "User matching mode: Link to a user with identical username"
3. Run the "Sync Kerberos source" job
### Expected behavior
* A Kerberos source connection should be created for the user (as listed in `/api/v3/sources/user_connections/kerberos/`)
* The user should now be able to log in with their Kerberos password
* Password changes for the user should be passed on to Kerberos (if "User password writeback" is enabled)
### Screenshots
_No response_
### Additional context
_No response_
### Deployment Method
Docker
### Version
2026.8.0
### Relevant log output
```shell
Sep 10 15:40:19 authentik systemd-authentik-worker[162699]: {"domain_url": null, "event": "Mapping evaluated to None or is not a dict. Skipping", "level": "debug", "logger": "authentik.core.sources.mapper", "mapping": "", "pid": 18, "schema_name": "public", "source": "", "timestamp": "2026-09-10T13:40:19.751880"}
Sep 10 15:40:19 authentik systemd-authentik-worker[162699]: {"domain_url": null, "event": "Mapping evaluated to None or is not a dict. Skipping", "level": "debug", "logger": "authentik.core.sources.mapper", "mapping": "", "pid": 18, "schema_name": "public", "source": "", "timestamp": "2026-09-10T13:40:19.752052"}
Sep 10 15:40:19 authentik systemd-authentik-worker[162699]: {"domain_url": null, "event": "Mapping evaluated to None or is not a dict. Skipping", "level": "debug", "logger": "authentik.core.sources.mapper", "mapping": "", "pid": 18, "schema_name": "public", "source": "", "timestamp": "2026-09-10T13:40:19.752200"}
Sep 10 15:40:19 authentik systemd-authentik-worker[162699]: {"attributes": {}, "domain_url": null, "event": "Writing user with attributes", "is_active": true, "level": "debug", "logger": "authentik.sources.kerberos.sync", "path": "Users", "pid": 18, "schema_name": "public", "source": "", "syncer": "KerberosSync", "timestamp": "2026-09-10T13:40:19.752265", "type": "internal", "username": "enton"}
Sep 10 15:40:19 authentik systemd-authentik-worker[162699]: {"domain_url": null, "event": "Trying to link with existing object", "identifier": "enton@EXAMPLE.ORG", "level": "debug", "logger": "authentik.core.sources.matcher", "pid": 18, "query": "", "schema_name": "public", "source": "", "timestamp": "2026-09-10T13:40:19.753123"}
Sep 10 15:40:19 authentik systemd-authentik-worker[162699]: {"action": "", "connection": "", "domain_url": null, "event": "Action returned", "level": "debug", "logger": "authentik.sources.kerberos.sync", "pid": 18, "schema_name": "public", "source": "", "syncer": "KerberosSync", "timestamp": "2026-09-10T13:40:19.754442"}
Sep 10 15:40:19 authentik systemd-authentik-worker[162699]: {"domain_url": null, "event": "Synced User", "level": "debug", "logger": "authentik.sources.kerberos.sync", "pid": 18, "schema_name": "public", "source": "", "syncer": "KerberosSync", "timestamp": "2026-09-10T13:40:19.759919", "user": "enton"}
```
Contributor guide
Research direction
Start in the Kerberos sync entry point under authentik.sources.kerberos.sync and trace the existing-user matching path through authentik.core.sources.matcher. Compare how the sync handles a matched user with the expected source connection, then verify that syncing an existing matching user creates the connection and enables the documented Kerberos password behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- authentication
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 62/100