Access Server ignoriert das post_auth-Skript, das Sie auf der Platte bearbeitet haben

Ein bearbeitetes mac.py, das nichts ändert, ist das übliche erste Symptom. Die Datei auf der Platte ist nicht das, was Access Server ausführt; der Authentifizierungsdienst lädt das Skript aus der Konfigurationsdatenbank des Servers, und genau diese gespeicherte Kopie entscheidet über eine Anmeldung. Bis der gespeicherte Wert ersetzt ist, beweist jeder Test nur, dass das alte Skript noch funktioniert.

Drei Bedingungen bestimmen die Arbeit: ob der Wert jemals in die Konfigurationsdatenbank geschrieben wurde, ob der Dienst angewiesen wurde, ihn neu zu laden, und ob der geänderte Code tatsächlich bei jeder Verbindung läuft. Jede hat ein anderes Symptom, und die falsche zu beheben verschwendet ein Wartungsfenster.

Die Datei ist eine Quelle, nicht die laufende Kopie

Access Server hält das post-auth-Skript unter dem Schlüssel auth.module.post_auth_script. Die Datei zu bearbeiten aktualisiert nur Ihre Arbeitskopie. Der Daemon liest den gespeicherten Wert, daher bleibt die Änderung unsichtbar, bis Sie den alten Eintrag löschen und die neue Datei an seine Stelle setzen. Dieser gespeicherte Wert ist die einzige Kopie, die der Authentifizierungsdienst heranzieht.

Lesen Sie ihn, bevor Sie ihn ändern. Stimmt er bereits mit der Datei überein, die Sie bearbeitet haben, liegt das Problem nicht in der Ablage, und Sie sollten zur Frage des Geltungsbereichs springen. Zeigt er eine ältere Version, hat die Änderung den Dienst nie erreicht.

./sacli -k auth.module.post_auth_script ConfigGet

Ersetzen Sie die gespeicherte Kopie, dann wenden Sie sie an

Vor dem Schreiben zu löschen ist keine Zierde. ConfigPut mit --value_file ersetzt den Wert in einem Schritt, und ConfigDel zuerst macht es unmöglich, einen veralteten oder beschädigten Eintrag zurückzulassen. Bewahren Sie vor dem Beginn eine Kopie des funktionierenden Skripts außerhalb des Skriptverzeichnisses auf.

./sacli -k auth.module.post_auth_script ConfigDel
# store the file, then apply it
./sacli -k auth.module.post_auth_script --value_file=/root/post_auth.py ConfigPut
./sacli start

sacli start wendet die geänderte Konfiguration auf die internen Dienste an, und das bringt das neue Skript zur Wirkung. Es ist nicht dasselbe wie ein Neustart des ganzen Rechners oder des Daemons und sollte nicht dadurch ersetzt werden, es sei denn, Ihre Änderung verlangt es.

Verwenden Sie einen absoluten Pfad für die Wertdatei und bestätigen Sie, dass root sie lesen kann. Ein Pfad, der aus Ihrer Shell aufgelöst wird, aber nicht aus dem Dienstkonto, erzeugt einen gespeicherten Wert, der in ConfigGet in Ordnung aussieht und bei der ersten Anmeldung scheitert. Prüfen Sie das gespeicherte Ergebnis nach sacli start noch einmal, nicht davor.

Modulumfang oder pro Verbindung: wohin die Abfrage gehört

Python führt Anweisungen auf Modulebene einmal aus, beim Laden des Skripts. Eine Datenbankabfrage oben in der Datei liest die Tabelle daher zur Ladezeit und behält diese Antwort für jede spätere Verbindung. Das ist der zweite Grund, warum eine Änderung wirkungslos erscheint: Der Code läuft, aber nicht dann, wenn Sie es erwarten.

Legen Sie die Abfrage in den post_auth-Handler, damit sie bei jeder Authentifizierung ausgeführt wird. Behalten Sie die dokumentierte Signatur bei, passen Sie das Authentifizierungsergebnis an, das der Handler erhält, und geben Sie dasselbe Objekt statt einer nackten Zahl zurück.

Halten Sie auch die Verbindungsbehandlung im Handler. Eine beim Import geöffnete Verbindung kann vom Server geschlossen werden, bevor der erste Benutzer sich anmeldet, und der resultierende Fehler sieht wie abgelehnte Anmeldedaten aus, nicht wie ein defektes Skript.

Zwei Ablehnungswege, ein Eigentümer

Ist die Entscheidung eine lokale Abfrage, gehört das Ergebnis dem Python-Handler. Ist es eine externe HTTP-Prüfung, soll der Exit-Status des Befehls die Antwort tragen: Ein Wrapper, der mit einem Wert ungleich null endet, lehnt die Anmeldung ab, und der Status des letzten Befehls wird der Status des Skripts ohne explizites exit.

Halten Sie das Geheimnis aus der Prozessliste heraus. Eine für root lesbare Datei oder ein vom Dienst übergebener Umgebungswert ist sicherer als ein Argument, das jeder lokale Benutzer aus ps lesen kann. Fixieren Sie den Endpunkt vor dem Aufruf in einer Variablen, damit ein Tippfehler zur Konfigurationszeit scheitert und nicht während der Anmeldung von jemandem. Rotieren Sie dieses Geheimnis wie jede andere Anmeldeinformation.

Wählen Sie einen Eigentümer pro Prüfung. Ein Skript, das sowohl die Datenbank abfragt als auch einen HTTP-Dienst aufruft, braucht eine erklärte Vorrangregel für den Fall, dass beide nicht übereinstimmen, sonst passt der Ablehnungsgrund im Protokoll nicht zu dem, was dem Benutzer gesagt wurde.

Wenden Sie es an, ohne den Administrator auszusperren

Zwei Absicherungen machen die Änderung umkehrbar: ein zweites Administratorkonto, das nicht vom Skript abhängt, und eine bekannt gute Kopie außerhalb des Skriptverzeichnisses. Wenden Sie die Änderung in einem Wartungsfenster an und beobachten Sie dann eine Testanmeldung und eine absichtliche Ablehnung, bevor Sie die Verbindung trennen. Zeigt das Protokoll einen Syntaxfehler statt einer Authentifizierungsentscheidung, ist das gespeicherte Skript defekt und jede Anmeldung wird scheitern.

Zwei Bedingungen sagen warten: Sie können die Wertdatei nicht als root lesen, oder Sie haben keinen zweiten Weg in die Admin-Oberfläche. Beide machen aus einer kleinen Änderung eine Aussperrung, und keine davon ist es wert, am Ende des Tages auf einem Produktivserver getestet zu werden. Die Access Server-Dokumentation behandelt die post-auth-Schnittstelle und ihre unterstützten Felder.