12
KERBEROS bzw. SPNEGOS Authentifzierung auf Terminalservern nicht funktional
Hallo zusammen,
leider kenne ich mich mit KERBEROS bzw. SPNEGOS (unser ERP-Dienstleister verwendet beide Begriffe simultan?) nicht aus und kann daher nicht viel Input geben, hoffe aber, dass Ihr dennoch einen Anhaltspunkt für mich habt, wie ich das folgende Problem lösen kann.
Folgende Ausgangssituation:
Wir nutzen das ERP System ABAS und haben hier vor wenigen Wochen von unserem ERP-Dienstleister ein vollwertiges Single-Sign-On System welches über Keycloak läuft erhalten. Alles was ich hierzu weiß ist, dass ein AD-User einer Sicherheitsgruppe zugewiesen werden muss und sich dann ab dem nächsten Tag (Sync AD <> Keycloak erfolgt Nachts) am ERP-System anmelden kann.
Das System läuft auf den Clients auch wunderbar. Allerdings nicht auf den Terminalservern. Dort scheint es, dass der Nutzer kein Kerberos-Ticket erhält und sich demnach nicht anmelden kann. ERP-System zeigt nämlich eine Login Maske für die SSO Daten an.
Für mich wäre nun die Frage, was an den Terminalservern eingestellt werden muss, dass die Nutzer die sich darauf einloggen ebenfalls ein Kerberos Ticket erhalten können und das SSO nutzen können.
Clients: Win 10 21H1 aufwärts
Terminalserver: Win Server 2016
Beide Server sind virtualisiert auf einem Hochverfügbarkeitscluster-Cluster welcher aus drei Hypervisoren besteht. Untereinander kommunizieren diese über 10 Gbit/s Leitungen.
ERP-Server: Debian 9.13
DC-Server: Win Server 2016
Sollten weitere Angaben von Nöten sein, dann bitte kurz melden, ich gebe dann raus was ich zu dem Thema weiß. Bin eben in diesem Thema blutiger Anfänger. Hat alles unser ERP-Dienstleister gemacht, sagt aber bei diesem Problem, dass Sie keine Schuld daran tragen und wir unsere Systeme korrekt einstellen müssen.
Vielen Dank im Voraus
Ben
leider kenne ich mich mit KERBEROS bzw. SPNEGOS (unser ERP-Dienstleister verwendet beide Begriffe simultan?) nicht aus und kann daher nicht viel Input geben, hoffe aber, dass Ihr dennoch einen Anhaltspunkt für mich habt, wie ich das folgende Problem lösen kann.
Folgende Ausgangssituation:
Wir nutzen das ERP System ABAS und haben hier vor wenigen Wochen von unserem ERP-Dienstleister ein vollwertiges Single-Sign-On System welches über Keycloak läuft erhalten. Alles was ich hierzu weiß ist, dass ein AD-User einer Sicherheitsgruppe zugewiesen werden muss und sich dann ab dem nächsten Tag (Sync AD <> Keycloak erfolgt Nachts) am ERP-System anmelden kann.
Das System läuft auf den Clients auch wunderbar. Allerdings nicht auf den Terminalservern. Dort scheint es, dass der Nutzer kein Kerberos-Ticket erhält und sich demnach nicht anmelden kann. ERP-System zeigt nämlich eine Login Maske für die SSO Daten an.
Für mich wäre nun die Frage, was an den Terminalservern eingestellt werden muss, dass die Nutzer die sich darauf einloggen ebenfalls ein Kerberos Ticket erhalten können und das SSO nutzen können.
Clients: Win 10 21H1 aufwärts
Terminalserver: Win Server 2016
Beide Server sind virtualisiert auf einem Hochverfügbarkeitscluster-Cluster welcher aus drei Hypervisoren besteht. Untereinander kommunizieren diese über 10 Gbit/s Leitungen.
ERP-Server: Debian 9.13
DC-Server: Win Server 2016
Sollten weitere Angaben von Nöten sein, dann bitte kurz melden, ich gebe dann raus was ich zu dem Thema weiß. Bin eben in diesem Thema blutiger Anfänger. Hat alles unser ERP-Dienstleister gemacht, sagt aber bei diesem Problem, dass Sie keine Schuld daran tragen und wir unsere Systeme korrekt einstellen müssen.
Vielen Dank im Voraus
Ben
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2263802250
Url: https://administrator.de/contentid/2263802250
Ausgedruckt am: 24.11.2024 um 15:11 Uhr
12 Kommentare
Neuester Kommentar
Hallo Ben.
Teste ganz simpel: melde dich an am TS, öffne als Nutzer eine Kommandozeile und nutze das Kommando
klist
->siehst Du da Tickets?
--
Edit: habe meinen Vorschlag gekürzt, da er Fehlinfos beinhaltete.
Teste ganz simpel: melde dich an am TS, öffne als Nutzer eine Kommandozeile und nutze das Kommando
klist
->siehst Du da Tickets?
--
Edit: habe meinen Vorschlag gekürzt, da er Fehlinfos beinhaltete.
Zitat von @DerWoWusste:
Teste ganz simpel: melde dich an am TS, öffne als Nutzer eine Kommandozeile und nutze das Kommando
klist
->siehst Du da Tickets?
Jup, vier Stück an der Zahl. Alle mit einer Startzeit von 16:15:25 Uhr, sprich zur Uhrzeit der Anmeldung. Dennoch keine Anmeldung an der ERP-Software möglich.Teste ganz simpel: melde dich an am TS, öffne als Nutzer eine Kommandozeile und nutze das Kommando
klist
->siehst Du da Tickets?
Habe das gleiche auch mal am Client gemacht, an welchem das SSO funktioniert und dort wird eine Fehlermeldung ausgeworfen: "Credentials Cache C:\Users\<NUTZER>\krb5cc_<NUTZER> not found".
EDIT: Bei einem Kollegen am Client funktioniert der klist Befehl ohne Fehler.
EDIT2:
Ja, wie du siehst ist es funktional, denn sonst würdest Du für die Fileserver keine Tickets bekommen.
Ich weiß nicht, was da vorgeht. Prüfe nach, auf einem Client wo es geht, nach erfolgreicher Verbindung wirklich ein Kerberosticket für den Zielserver (ERP) zu finden ist.
Ich weiß nicht, was da vorgeht. Prüfe nach, auf einem Client wo es geht, nach erfolgreicher Verbindung wirklich ein Kerberosticket für den Zielserver (ERP) zu finden ist.
1
Prüfe ich morgen, Ich melde mich
Zitat von @DerWoWusste:
Ja, wie du siehst ist es funktional, denn sonst würdest Du für die Fileserver keine Tickets bekommen.
Ich weiß nicht, was da vorgeht. Prüfe nach, auf einem Client wo es geht, nach erfolgreicher Verbindung wirklich ein Kerberosticket für den Zielserver (ERP) zu finden ist.
Ja, wie du siehst ist es funktional, denn sonst würdest Du für die Fileserver keine Tickets bekommen.
Ich weiß nicht, was da vorgeht. Prüfe nach, auf einem Client wo es geht, nach erfolgreicher Verbindung wirklich ein Kerberosticket für den Zielserver (ERP) zu finden ist.
Habe das nun prüfen können, auf einem Laptop mit meinem Useraccount. Es wird ein neues Ticket in der Liste angezeigt mit dem korrekten Prinzipal, welchen unser ERP-Dienstleister auch angegeben hat:
Was bringt mir diese Information nun? Damit weiß ich weiterhin lediglich, dass auf einem Terminalserver kein entsprechendes Ticket erstellt / abgerufen (Wie wird das korrekt bezeichnet?) werden kann
Das bringt dir zu wissen, dass die Authentifizierung wie vermutet über Kerberos läuft und nicht etwa über NTLM.
Zurück zu deiner ersten Antwort - du siehst am TS 4 Tickets. Aber keines davon wurde ausgestellt von Server http/srvdb010... ?
Zurück zu deiner ersten Antwort - du siehst am TS 4 Tickets. Aber keines davon wurde ausgestellt von Server http/srvdb010... ?
Zitat von @DerWoWusste:
Zurück zu deiner ersten Antwort - du siehst am TS 4 Tickets. Aber keines davon wurde ausgestellt von Server http/srvdb010... ?
Zurück zu deiner ersten Antwort - du siehst am TS 4 Tickets. Aber keines davon wurde ausgestellt von Server http/srvdb010... ?
Genau
Aber http/https-Ports des Zielservers kannst Du vom TS aus erreichen?
Ja, das funktioniert ebenso. Wenn ich die URL eintippe, wohin der Request geschickt wird, erhalte ich eine JSON Datei im Browser zur Ansicht mit einem Public Key, Token Service und Account Service:
Getestet in Firefox sowie Edge
Schade, ich glaube dann bin ich raus, da bin ich nicht sicher genug, um das nebenher aus dem Ärmel zu schütteln.
Dennoch ein Tipp: ich lese in der Doku https://documentation.abas.cloud/en/abas-keycloak/index.html im Beispiel nur von einem einzelnen DC. Habt Ihr beide/alle DCs eingetragen, also
kdc = srvdc001.welte-intern.de
kdc = srvdc002.welte-intern.de
...?
Wenn nein, fragt der TS evtl. nicht immer den eingetragenen DC bzw. kann den eingetragenen nicht erreichen.
Dennoch ein Tipp: ich lese in der Doku https://documentation.abas.cloud/en/abas-keycloak/index.html im Beispiel nur von einem einzelnen DC. Habt Ihr beide/alle DCs eingetragen, also
kdc = srvdc001.welte-intern.de
kdc = srvdc002.welte-intern.de
...?
Wenn nein, fragt der TS evtl. nicht immer den eingetragenen DC bzw. kann den eingetragenen nicht erreichen.
Da bin ich auch raus, weil auf die Konfiguration hab ich keinen Zugriff. Das macht eben alles der ERP-Dienstleister. Die lassen sich sowas nur teuer bezahlen, weshalb ich dachte, probierste mal hier, eventuell ist es Konfigurationssache am entsprechenden TS
Du solltest in jedem Fall vom TS aus mit Powershell prüfen, ob der Port TCP 88 auf allen DCs erreicht werden kann:
Test-NetConnection -Port 88 srvdc002.welte-intern.de
