GitLab ist – wie der Name schon erahnen lässt – ein Git-basiertes Entwicklungsmanagement auf Ruby-Basis. Zusätzlich zur Versionsverwaltung gibt es auch Issue-Tracker, Wikis, CI/CD und Vieles mehr. Im Gegensatz zu GitHub lässt es sich auch lokal auf eigenen Systemen installieren, in der Community Edition dabei unter freier Lizenz. Als Alternative wäre noch Forgejo zu nennen, welches weniger kommerziell daher kommt.
Auf einer GitLab-Instanz hatte ich nun eine etwas andere Aufgabe: Ein verwendeter Zugang wurde als potentiell unsicher eingestuft. Nichts, was eine direkte Aktion notwendig machte, aber man sollte es auch nicht ignorieren. Normalerweise erzwinge ich in solchen Fällen einen Passwortwechsel beim nächsten Login. So wird der Nutzer zu geeigneter Zeit aktiv auf das Problem hingewiesen und es sind keine alternativen Kommunikationskanäle notwendig. Während GitLab prinzipiell einen erzwungenen Passwortwechsel unterstützt, gibt es offenbar keine Option dies über die üblichen Wege manuell auszulösen.
Der offizielle Weg
Die Offizielle Empfehlung ist recht klar: Als Admin unter Overview→User→Edit und dort ein neues Passwort festlegen. Dies ist temporär, der User muss es beim nächsten Login ändern. Hierbei wird auch sichergestellt, dass die aktuellen Kennwortrichtlinien eingehalten werden.
Für mich in diesem Fall kein sinnvoller Weg, da durch den Kennwort-Wechsel der Zugang umgehend nicht mehr möglich ist und ein separater, sicherer Kommunikationskanal notwendig ist um das neue, temporäre Kennwort zu übermitteln.
Eingeweide
Offiziell geht es also nicht, aber die Funktion selbst ist ja da. Über einige Tricks kann man dafür sorgen, dass der Passwortwechsel mit dem aktuellen Kennwort angefordert wird. Notwendig ist dazu ein Konsolenzugang zum Server, auf dem GitLab ausgeführt wird. Hier startet man eine Rails-Konsole (ggf. mit sudo), sucht den User und setzt das Ablaufdatum des Kennworts auf die aktuelle Zeit.
gitlab-rails console
user = User.find_by_username('bernd')
user.password_expires_at=Time.now
user.save
quitBeim nächsten Login sollte nun der Passwortwechsel angefordert werden. Tipp: Es gibt auch ein verlockendes user.password_automatically_set. Dieses sorgt nicht für einen Passwortwechsel, sondern sperrt den interaktiven Login vollständig.
Eigentlich schade, dass so eine einfache und technisch vorhandene Möglichkeit nicht in den Dialogen angeboten wird. Auch wenn ich sicherheitstechnisch nachvollziehen kann, dass eine Sperrung und temporäres Passwort oft die bessere Wahl ist, sollte man den Admins nicht die Wahl vorenthalten Prozesse zu nutzen, welche den eigenen Anforderungen bessern entsprechen.
