---
type: issue
id: "0091"
status: open
created: 2026-08-11
milestone: M1
priority: high
area: security
projekt: gitops
gitlab_iid: "61"
related:
  - "docs/adr/0011-enrollment-localpart-kollision-verweigern.md"
---
# Enrollment: kollidierender Localpart übernimmt bestehendes Konto (on_conflict: add)

> Adoptiert aus [gitops#61](https://git.lab/axion1337.chat/axion1337.chat-gitops/-/issues/61) (2026-08-18, ADR-0019). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei.
> Bei der Adoption ergänzt: Meilenstein M1 (fehlte auf GitLab); von den zwei
> area-Labels trägt das Schema eines — `security` bleibt, `authentik` entfällt.

## Befund

Der MAS-Upstream-Provider für Authentik verknüpfte eine neu registrierte
Upstream-Identität mit einem **bestehenden** lokalen Konto, sobald der
abgeleitete Localpart kollidiert:

```yaml
claims_imports:
  localpart:
    action: force
    template: "{{ user.preferred_username }}"
    on_conflict: add      # <-- verknüpft statt abzubrechen
```

Zusammen mit Authentiks Benutzernamen-Eindeutigkeit, die **nur innerhalb von
Authentik** und **case-sensitive** greift, ergibt sich ein Übernahmeweg:

1. Ein Inhaber eines Einladungstokens registriert in Authentik einen Namen, der
   als Matrix-Konto bereits existiert (oder eine Groß-/Kleinschreibungsvariante
   davon — `boje` neben `Boje` ging live durch).
2. Authentiks Eindeutigkeit meldet keine Kollision, weil das Ziel-Matrix-Konto
   für Authentik unsichtbar ist bzw. sich in der Schreibweise unterscheidet.
3. Beim ersten Login verknüpft MAS die neue Identität mit dem bestehenden Konto
   — inklusive Räumen und Historie.

**Besonders exponiert:** Konten ganz ohne Upstream-Link, weil dort nichts
vorher da sein muss. Betroffen wären u. a. die Dienstkonten `draupnir`,
`alerts`, `maintenance-notify` sowie `frank`, `crank`, `shank`, `stank`,
`bojeledoggo`, `scanner-test`.

> Der Übernahmeweg wurde **nicht** aktiv ausprobiert (das wäre eine echte
> Kontoübernahme gewesen). Die Aussage stützt sich auf MAS' dokumentierte
> Semantik für `on_conflict` und auf die live reproduzierte case-sensitive
> Dublette `boje`/`Boje`.

## Wie es aufgefallen ist

Beim Anlegen eines Testkontos über den Einladungsflow entstand versehentlich
ein zweites Konto `boje` neben dem bestehenden `Boje` — kein Fehler, keine
Warnung. Die Nachprüfung der MAS-Claims-Konfiguration legte `on_conflict: add`
als Ursache offen.

## Fix (erledigt)

`on_conflict: fail` in `apps/production/custom-configs/mas-secret.yaml` — ein
kollidierender Localpart bricht die Provisionierung ab, statt zu verknüpfen.
Bestehende Verknüpfungen bleiben unberührt.

Commit `ef04d86`, gepusht nach git.lab. Rollt über Flux aus.

## Rest, bewusst offen

- **Authentiks case-sensitive Eindeutigkeit** verhindert `boje` neben `Boje`
  weiterhin nicht. Der MAS-Fix fängt die Übernahme ab (Login schlägt fehl statt
  zu verknüpfen), aber der Nutzer bekommt erst beim Login eine Fehlermeldung,
  nicht schon bei der Registrierung. Eine Eindeutigkeitsprüfung (case-insensitive)
  im Prompt-Stage des `matrix-invitation`-Flows wäre die saubere Ergänzung.
- **Verwaiste Zweitkonten** aus dieser Lücke (`apo2`, das gelöschte `boje`)
  sind Altlasten, keine offene Verwundbarkeit.