[GELÖST] Kerberos-Fehler 405

Marceld · 22. März 2023 – 13:54 Uhr

Hallo zusammen,

Wir haben unseren WAPT Enterprise Server (auf dem neuesten Stand) seit über einem Jahr produktiv auf einem Ubuntu-Server (ebenfalls auf dem neuesten Stand) im Einsatz.

Details zur Version:

WAPT 2.3.0.13516

Ubuntu 22.04.2 LTS

Wir wollten in unserer Domäne von NTLM wegkommen und nur noch Kerberos verwenden.

Wir haben uns daher daran gemacht, WAPT mit Kerberos zu konfigurieren.

- Alle Konfigurationen erfüllen die Voraussetzungen (Abschnitt Debian-Installation)
- Wir haben uns an die Dokumentation zur "Stärkung der Sicherheit Ihres WAPT-Servers" gehalten (mit Ausnahme des Firewall-Teils, den wir nach Kerberos implementieren werden).

Der gesamte „Kerberos-Konfigurations- und Nachkonfigurationsprozess“ verlief reibungslos.

Es ist jedoch derzeit nicht möglich, vom WAPT-Softwarezentrum aus eine Verbindung herzustellen.

Wenn ich der Dokumentation folge, ergibt sich Folgendes:
- use_kerberos=True ist sowohl auf Client- als auch auf Serverseite korrekt aktiviert
- Die Keytab-Datei ist gut und entspricht den Angaben in der Dokumentation
- Der Befehl "kinit -k -t /etc/nginx/http-krb5.keytab srvwapt\$@AD.TRANQUIL.IT" generiert tatsächlich ein Ticket für den Server (klist)
- Auf einem Client-PC kann ich das Gerät mithilfe der Systemkonsole und dem Befehl "wapt-get register" erfolgreich registrieren:

C:\windows\system32>wapt-get register
Verwende Konfigurationsdatei: C:\Program Files (x86)\wapt\wapt-get.ini
Registriere Host beim Server: https://srvwapt.toto.local
Host korrekt beim Server https://srvwapt.toto.local.

Wenn ich einen Test mit dem Curl-Befehl ausführe, erhalte ich die Fehlermeldung: http/1.1 405 METHOD NOT ALLOWED:

> GET /add_host_kerberos HTTP/1.1
> Host: frscmwapt.scmlemans.com
> Authorization: Negotiate CLE_EFFACE
> User-Agent: curl/7.81.0
> Accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Mark bundle as not supporting multiuse
< HTTP/1.1 405 METHOD NOT ALLOWED
< Server: nginx
< Date: Wed, 22 Mar 2023 12:33:32 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 178
< Connection: keep-alive
< WWW-Authenticate: Negotiate KEY_ERAS
< WWW-Authenticate: Basic realm=""
< Allow: OPTIONS, POST, HEAD
< Strict-Transport-Security: max-age=63072000
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>405 Method Not Allowed</title>
<h1>Method Not Allowed</h1>
<p>The method is not allowed for the requested URL.</p>
* Verbindung #0 zu Host srvwapt.toto.local wurde beibehalten

Wenn ich den Test in Firefox durchführe, wie er ein- oder zweimal im Forum beschrieben wurde, erhalte ich das gleiche Ergebnis (405 METHODE NICHT ERLAUBT)

Wenn ich von einem Benutzer-PC aus ein Ticket anfordere, erhalte ich folgende Antwort:

C:\windows\system32>klist get https://srvwapt.toto.local

LogonId ist 0:0x3e7
Fehler beim Aufruf der API LsaCallAuthenticationPackage (Unterstatus GetTicket): 0x6fb

klist fehlgeschlagen mit 0xc000018b/-1073741429: Die SAM-Datenbank des Windows-Servers verfügt über kein Computerkonto für die Vertrauensstellung mit dieser Arbeitsstation.

Schließlich kann nun kein Benutzer mehr das Softwarecenter nutzen (was für mich Sinn ergibt, da die Kerberos-Anfrage fehlgeschlagen ist)
Die Administratorkonsole funktioniert jedoch weiterhin (was Sinn ergibt, da sie kein Kerberos verwendet).

Entschuldigung für den langen Text und vielen Dank fürs Lesen.

22. März 2023 – 14:41 Uhr

Wenn die Meldung „Methode nicht zulässig“ angezeigt wird, ist alles in Ordnung

Sie können auch versuchen, die folgende URL in Ihrem Browser zu verwenden:

Code: Alle auswählen

https://srvwapt.mydomain.lan/api/v3/login_kerberos

Damit Kerberos auf der Self-Service-Seite funktioniert, müssen Sie Folgendes zur wapt-get.ini-Datei Ihrer Agenten hinzufügen:

Code: Alle auswählen

[global]
use_kerberos=1
service_auth_type=waptserver-ldap

Konfigurieren Sie auf dem Wapt-Server LDAP in der Datei /opt/wapt/conf/waptserver.ini

setzen :

Code: Alle auswählen

[options]
ldap_auth_server = srvads.mydomain.lan
ldap_auth_base_dn = DC=mydomain,DC=lan
ldap_auth_ssl_enabled = False
verify_cert_ldap = False
ldap_account_service_login = wapt-ldap@mydomain.lan
ldap_account_service_password = password

Starten Sie anschließend den WAP-Server neu:

Code: Alle auswählen

systemctl restart waptserver

Marceld · 22. März 2023 – 14:59 Uhr

Hallo Sfonteneau,

ALSO :

https://srvwapt.mydomain.lan/api/v3/login_kerberos

Zunächst wird „Authentifizierung OK“ angezeigt:

: ok.JPG (27,79 KB) 8189 Mal angesehen

[global]
use_kerberos=1
service_auth_type=waptserver-ldap

Genau das wollte ich ansprechen. Ich habe die Dokumentation und das Forum eingehend durchgesehen, und manchmal steht dort „1“, manchmal „True“. Sind beide Werte akzeptabel?

[options]
ldap_auth_server = srvads.mydomain.lan
ldap_auth_base_dn = DC=mydomain,DC=lan
ldap_auth_ssl_enabled = False
verify_cert_ldap = False
ldap_account_service_login = wapt-ldap@mydomain.lan
ldap_account_service_password = password

Ich hatte bereits versucht, sie hinzuzufügen (ich habe die Kommentarzeichen entfernt, aber das hat mein Problem nicht behoben)
Reicht ein Standardbenutzerkonto aus oder sind spezielle Berechtigungen erforderlich?

Vielen Dank für Ihre Zeit.

22. März 2023 – 16:48 Uhr

Marceld schrieb: ↑22. März 2023 - 14:59 Uhr

Genau das wollte ich ansprechen. Ich habe die Dokumentation und das Forum eingehend durchgesehen, und manchmal steht dort „1“, manchmal „True“. Sind beide Werte akzeptabel?

Ja, absolut, 1 = Wahr, also können Sie eingeben, was Sie wollen

Reicht ein Standardbenutzerkonto aus oder sind spezielle Berechtigungen erforderlich?

Es benötigt die Berechtigung, das memberof-Attribut von Benutzerdatensätzen zu lesen (Sie können dies mit der kleinen ldapadmin-Software testen)

Marceld · 22. März 2023 – 18:42 Uhr

Vielen Dank für das Tool.

Das erstellte Benutzerkonto kann das Attribut „Mitglied von“ tatsächlich lesen.

Wenn die Kerberos-Tests erfolgreich sind, die SSO-Prüfung im Softwarecenter jedoch nicht funktioniert, woran könnte das liegen?

23. März 2023 - 10:17 Uhr

Das Einzige, was wir noch nicht geprüft haben, ist Ihr Self-Service-Regelpaket.

Ist ein solches Paket installiert?

Erhalten Sie eine Fehlermeldung beim Öffnen?

Marceld · 23. März 2023 - 12:05 Uhr

Hallo,

ja, es gibt ein Self-Service-Paket für Benutzer.

Mit NTLM-Authentifizierung funktionierte es einwandfrei.

Es wird jedoch immer „Falsches Passwort oder falscher Benutzername“ angezeigt, egal ob ich ein Passwort eingebe oder nicht.

Ich kann es auch nicht mit einem Konto öffnen, das über lokale Administratorrechte verfügt.

Schönen Tag noch.

23. März 2023 - 12:19 Uhr

Wenn Ihr Agent auf diese Weise korrekt konfiguriert ist, sollte er nicht nach einem Passwort fragen:

Code: Alle auswählen

[global]
use_kerberos=1
service_auth_type=waptserver-ldap

Dann :

Code: Alle auswählen

net stop waptservice
net start waptservice

Marceld · 23. März 2023 – 15:23 Uhr

Wenn Ihr Agent auf diese Weise korrekt konfiguriert ist, sollte er nicht nach einem Passwort fragen:

Ah, okay, aber in einem anderen Thema haben Sie angegeben, dass Benutzername und Passwort immer erforderlich sind, wenn wir jemals zum Administrator wechseln müssen.

use_kerberos=1
service_auth_type=waptserver-ldap

Ich kann bestätigen, dass dies tatsächlich die Konfiguration ist, die ich auf meinem Testclient habe.

Ich finde in den clientseitigen Protokollen keinen Hinweis auf einen möglichen Fehler. Gibt es einen bestimmten Ort, an dem ich Protokolle zum Verbindungsversuch finden kann?

Marceld · 23. März 2023 – 17:10 Uhr

Zu Ihrer Information und nach Rücksprache mit dem Support am Telefon:

Das war ein Fehler von mir:

Ich habe die folgende Zeile geändert:

service_auth_type=waptserver-ldap

von :

service_auth_type=mywaptserver.toto.local

Das war ein Fehler meinerseits; diese Zeile hätte nicht geändert werden dürfen.

Nochmals vielen Dank für Ihre schnelle Reaktion!

Wir werden NTLM endlich loswerden können