[GELÖST] Agent registriert sich nicht bei WAPT

[PaulSLA]

Guten Morgen,

Nach der Implementierung der Kerberos-Authentifizierung auf unserem WAPT-Server und der Konfiguration einer Test-Workstation mit aktiviertem Kerberos tritt ein Problem bei der Bereitstellung neuer Workstations über WADS auf. Die Workstations sind im Bereich „Betriebssystembereitstellung“ sichtbar, Windows wird installiert, die Workstation startet jedoch normal, wird aber nicht bei WAPT registriert. Wir müssen den Befehl `register` ausführen, der uns zur Eingabe von WAPT-Benutzername und -Passwort auffordert und anschließend die Workstation registriert und Paketaktualisierungen wie gewohnt startet. Wir haben versucht, das Workstation-Skript `conf` wie folgt zu modifizieren:

Code: Alle auswählen

ping 127.0.0.1 -n 30
net stop waptservice
"C:\Program Files (x86)\wapt\wapt-get.exe" update 
"C:\Program Files (x86)\wapt\wapt-get.exe" install base_software
net start waptservice
"C:\Program Files (x86)\wapt\wapt-get.exe" register --wapt-server-user=XXXXX --wapt-server-passwd=XXXXX

Der Computer sollte sich nach der Windows-Installation automatisch registrieren, bleibt aber in der Phase „Benutzer: Skript wird nach der Installation ausgeführt“ hängen, die nie abgeschlossen wird. Der Computer verbleibt in einer Endlosschleife auf dem Windows-Startbildschirm (Windows-Logo mit dem kleinen Punkt). Nach einem Neustart lässt er sich manuell registrieren.

Mit der WAPT-Verwaltung haben wir keine weiteren Probleme; die Workstations sind erreichbar und Aktualisierungen werden korrekt durchgeführt, unabhängig davon, ob Kerberos auf 0 oder 1 steht.

Ist dieses Problem schon einmal aufgetreten, und wenn ja, wie wurde es gelöst?



Falls erforderlich:

waptserver.ini-Datei:

Code: Alle auswählen

[options]
server_uuid = 
secret_key = 
wapt_password = 
clients_signing_key = /opt/wapt/conf/ca-srv-wapt.XXXX.dom.pem
clients_signing_certificate = /opt/wapt/conf/ca-srv-wapt.XXXX.dom.crt
ldap_auth_server = XXXX.dom
ldap_auth_base_dn = DC=XXXX,DC=dom
ldap_account_service_login = wapt@XXXX.dom
ldap_account_service_password = 
token_secret_key = 
clients_signing_crl = /var/www/ssl/ca-srv-wapt.XXXX.dom.crl
clients_signing_crl_url = http://srv-wapt.XXXX.dom/wapt/ssl/ca-srv-wapt.XXXX.dom.crl
ssl_additional_crls = /var/www/ssl
waptwua_enable = True
allow_unauthenticated_registration = False
wads_enable = True
login_on_wads = False
use_kerberos = True
ldap_auth_ssl_enabled = False

wat-get.ini von der Teststation:

Siehe beigefügte Datei poste1.png

Poste1.png (234,66 KB) 9322 Mal angesehen

wat-get.ini Produktions-Workstation:

Siehe beigefügte Datei poste2.png

Poste2.png (226,96 KB) 9322 Mal angesehen

Vielen Dank im Voraus für Ihre Antworten
Aufrichtig,

[dcardon]

Hallo Paul,

hast du Postconf nach der Änderung der waptserver.ini-Datei neu gestartet? Einige Änderungen müssen in der Nginx-Konfigurationsdatei übernommen werden.

Viele Grüße,

Denis

[PaulSLA]

Hallo,

ich habe es zur Sicherheit noch einmal versucht (obwohl ich mir sicher bin, dass ich es schon getan hatte), aber es hat nichts geändert.

Die Workstations hängen derzeit beim Postinstall-Skript fest und ich muss sie unsachgemäß herunterfahren, neu starten und sie dann bei WAPT registrieren.

Ich habe das Postinstall-Skript um den Befehl "C:\Program Files (x86)\wapt\wapt-get.exe" register --wapt-server-user=XXXX--wapt-server-passwd=XXXX" ergänzt,
in der Hoffnung, dass dies die Registrierung bewirken würde, aber das hat nicht funktioniert. Nachdem ich das Skript wieder in den Originalzustand zurückversetzt habe, besteht das Problem weiterhin (während vor der Änderung die Windows-Installation auf dem PC normal abgeschlossen wurde, die Registrierung bei WAPT aber fehlschlug).

Hier ist das aktuelle Skript:
ping 127.0.0.1 -n 30
net stop waptservice
"C:\Program Files (x86)\wapt\wapt-get.exe" update
"C:\Program Files (x86)\wapt\wapt-get.exe" install base_software
net start waptservice

Mit freundlichen Grüßen

[dcardon]

Hallo Paul,

Funktioniert die Kerberos-Registrierung auf einem WAPT-Agenten außerhalb von WADs?

Zum Testen können Sie einen sauberen Rechner oder einen bereits integrierten Rechner verwenden. Wenn der Rechner integriert ist, müssen Sie ihn aus dem Inventar entfernen und die Clientzertifikatsdateien c:\program files (x86)\wapt\private\*.{crt,p12,pem} löschen

Anschließend führen Sie eine Rechteausweitung im lokalen System mithilfe von psexec durch

Code: Alle auswählen

psexec -i -s cmd.exe

Anschließend führen Sie ein wapt-get register ohne Benutzername/Passwort aus, um zu überprüfen, ob sich der Rechner korrekt bei Kerberos registrieren kann.

Aufrichtig,

Denis

[PaulSLA]

Hallo,

ich habe es getestet. Nachdem ich `use kerberos` auf dem Agenten auf 1 gesetzt und den WAPT-Dienst neu gestartet habe, funktioniert die Authentifizierung direkt ohne Passwort. Wenn `use kerberos` auf 0 gesetzt ist, sind Benutzername und Passwort erforderlich. Die

Kerberos-Registrierung scheint also zu funktionieren. Anschließend habe ich die Self-Service-Option ausprobiert und erhalte die Fehlermeldung „Falsches Passwort“. Nach Eingabe meines Windows-Passworts funktioniert alles. Sollte das mit Kerberos nicht automatisch erfolgen?

Das wirft weiterhin das Problem der Registrierung neuer PCs auf. Wie kann ich die standardmäßig bereitgestellte Konfiguration einsehen und überprüfen, ob Kerberos verwendet wird? Falls nicht, kann ich einfach einen neuen Agenten generieren, der Kerberos verwendet, um das Problem zu beheben?

Was passiert dann mit den aktuell bereitgestellten Agenten? Müssen sich diese alle neu registrieren?

Mit freundlichen Grüßen

[dcardon]

Hallo nochmal Paul,

Test abgeschlossen: Nach dem Setzen von `use kerberos` auf 1 auf Agentenseite und dem Neustart des WAPT-Dienstes funktioniert die Authentifizierung direkt ohne Passwort. Wenn `use kerberos` auf 0 gesetzt ist, sind Benutzername und Passwort erforderlich.

Okay, das bedeutet, dass der Kerberos-Teil korrekt konfiguriert ist.

Die Kerberos-Registrierung scheint zu funktionieren. Ich habe die Selbstbedienungsoption ausprobiert, erhielt aber die Fehlermeldung „Falsches Passwort“. Nachdem ich mein Windows-Passwort eingegeben hatte, funktionierte alles. Sollte das bei Kerberos nicht automatisch erfolgen?

Ja, es sollte automatisch funktionieren. Auf dem Testrechner ist `service_auth_type=waptserver-ldap` konfiguriert, auf dem anderen jedoch nicht. Wurde der Test auf dem Testrechner durchgeführt?

Dies führt immer wieder zu Problemen bei der Registrierung neuer PCs. Wie kann ich die Standardbereitstellungskonfiguration einsehen und überprüfen, ob Kerberos verwendet wird? Falls nicht, kann ich einfach einen neuen Agenten generieren, der Kerberos nutzt, um das Problem zu beheben?

Zeigen die neu bereitgestellten Workstations die korrekte Uhrzeit an? Kerberos reagiert etwas empfindlich auf die Uhrzeit. WinPE speichert die BIOS-Zeit in UTC, während ein lokal installiertes Windows-System die BIOS-Zeit in der lokalen Zeitzone speichert. Dies ist recht inkonsistent. Im BIOS gibt es keine Zeitzoneneinstellungen, und Windows verwendet die Zeit im BIOS nicht einheitlich. (Linux speichert die Zeit ebenfalls in UTC.).

Falls ja, was geschieht mit den derzeit eingesetzten Agenten? Werden sich alle erneut registrieren?

Wenn ein Agent registriert ist, verfügt er über ein Clientzertifikat (.pem / .p12) und verwendet dieses zur Authentifizierung am Server. Die Kerberos-Authentifizierung wird nur dann verwendet, wenn kein Clientzertifikat vorhanden ist oder dieses ungültig ist (z. B. widerrufen wurde). Daher ist eine erneute Registrierung bereits bereitgestellter/registrierter Arbeitsstationen nicht erforderlich.

Aufrichtig,

Denis

[PaulSLA]

Hallo,

vielen Dank für die Antworten. Ich habe die Zeile "service_auth_type=waptserver-ldap" in der Datei [global] auf dem Testrechner. Ich füge sie noch nicht auf den Produktivsystemen hinzu, da ich mir noch nicht ganz sicher bin, ob ich alle Details dieser Konfiguration verstehe.
Ich habe auch die Zeile "ldap_auth_ssl_enabled=False", die ich im Forum gefunden habe und die damals ein ähnliches Problem gelöst hat.

Ich konnte das Problem auf den neuen PCs beheben. Aus mir unbekannten Gründen bleibt das Post-Install-Skript hängen und die Installation wird nicht fortgesetzt. Da dieses Skript keine wichtige Funktion mehr erfüllt, konnte ich es löschen, und die Installation wird fortgesetzt. Nach Abschluss der Installation registriert sich der PC korrekt bei Kerberos (nachdem natürlich ein neuer Agent generiert wurde, der Kerberos unterstützt).


Vielen Dank für die Informationen zu den bestehenden Systemen. Kann ich also `use_kerberos` auf meinen Systemen von 0 auf 1 ändern? Hat das Auswirkungen auf die Produktivsysteme? Aber wenn ich es richtig verstehe, ist das kaum nützlich, außer vielleicht für eine eventuelle erneute Registrierung.

Das einzige verbleibende Problem ist also, dass die Self-Service-Funktion trotz der oben genannten Zeilen und der bereits geposteten Serverkonfiguration nicht mit SSO funktioniert.
Wenn die Zeile „service_auth_type=waptserver-ldap“ vorhanden ist, startet der Self-Service mit einer roten Fehlermeldung, dass das Passwort falsch ist. Entferne ich sie, erscheint keine Meldung, und ich werde einfach nach dem Passwort gefragt. Ich habe leider keine weiteren Ideen, um dieses Problem zu beheben.

Mit freundlichen Grüßen

[dcardon]

Hallo Paul,

ich komme bei der Konfiguration per Selbstbedienung nicht weiter. Ihre Organisation hat einen Telefonsupport abonniert. Am besten eröffnen Sie ein Ticket, damit sich jemand die Konfiguration live mit Ihnen ansehen kann; das sollte nicht allzu schwierig sein.

Viele Grüße,

Denis

[PaulSLA]

Hallo,

ich habe weiter recherchiert, und Methode 2 aus der Dokumentation funktioniert:

„ldap_auth_ssl_enabled = True
verify_cert_ldap = False“

. Die dritte Methode funktioniert jedoch nicht. Da wir aber ohnehin die Zertifikatsprüfung aktivieren möchten, werden wir für beide Probleme gleichzeitig ein Ticket erstellen, da sie beide anscheinend mit einem Zertifikatsproblem zusammenhängen.

Vielen Dank für Ihre Hilfe!

Mit freundlichen Grüßen