Nach Ausführung des Befehls mskutil wurden keine Ergebnisse im Active Directory gefunden

Zikos · 17. April 2024 - 11:45 Uhr

Guten Morgen,

WAPT2.5 / Debian 12 Bookworm

Das von mir beschriebene Problem tritt auf meinem produktiven Windows-Domänencontroller mit WAPT 2.5 auf.
Ich habe ebenfalls gerade einen Hyper-V auf einem neuen Testdomänencontroller unter Windows Server 2022 und einer Neuinstallation von Debian 12 / WAPT 2.5 installiert und beobachte das gleiche Problem.

Auf Empfehlung von @sfonteneau habe ich das Paket libnginx-mod-http-auth-spnego verwendet, das hier zu finden ist:
https://wapt.tranquil.it/debian/wapt-2. ... th-spnego/

Ich erhalte keine Aktualisierungen von meinem WPAT-Server „srv-wapt“ im von mir erstellten Ordner „prosioning“. Ich bin der Anleitung von It-Connect gefolgt, die ich bereits für WAPT 2.3 verwendet hatte.

Ich habe es sogar mit einem anderen Ordner einer Organisationseinheit getestet (ich habe dem Konto "wapt" die Rechte für beide Ordner gegeben (Delegation der Kontrolle für das Konto "wapt" mit nur Objekten vom Typ "Computer" mit Erstellungs-/Löschberechtigungen in "Erstellen" für alle untergeordneten Objekte).

Wenn ich meine kinit wapt (+Passwort) eingebe: kein Fehler
Dann liefert mir Klist korrekt das Kerberos-Ticket für das wapt-Konto:

Code: Alle auswählen

root@srv-wapt:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: wapt@ADTEST.LOCAL

Valid starting       Expires              Service principal
17/04/2024 11:14:59  17/04/2024 21:14:59  krbtgt/ADTEST.LOCAL@ADTEST.LOCAL
        renew until 18/04/2024 11:14:52
17/04/2024 11:16:54  17/04/2024 21:14:59  ldap/serv2022adtest.adtest.local@
        renew until 18/04/2024 11:14:52
        Ticket server: ldap/serv2022adtest.adtest.local@ADTEST.LOCAL
17/04/2024 11:16:54  17/04/2024 11:18:54  kadmin/changepw@ADTEST.LOCAL
        renew until 17/04/2024 11:18:54

Als Nächstes gebe ich die beiden Befehle ein:

Code: Alle auswählen

msktutil --server Serv2022ADTEST.adtest.local --precreate --host $(hostname) -b ou=Provisioning,dc=adtest,dc=local --service HTTP --description "host account for wapt server" --enctypes 24 -N

Dann :

Code: Alle auswählen

msktutil --server Serv2022ADTEST.adtest.local --auto-update --keytab /etc/nginx/http-krb5.keytab --host $(hostname) -N

Im Ordner „provisioning“ oder in anderen Testordnern passiert nichts (obwohl ich das bereits mit WAPT 2.3 getestet habe). Ich warte darauf, dass sich die srv-wapt-Maschine dort mit der Beschreibung „Hostkonto für den wapt-Server“ registriert.

Wenn ich versuche, noch einen Schritt weiterzugehen (Waptconsole auf einem Windows-Rechner zu installieren), melde ich mich bei der "waptconsole"-Konfiguration an, die Serveradresse ist in Ordnung, Benutzername und Passwort sind korrekt, und dann erhalte ich diese Fehlermeldung:

Falls jemand irgendwelche Hinweise hat, bin ich ganz Ohr.

DANKE.

Gregory.

Zikos · 23. April 2024 - 10:52 Uhr

Hallo zusammen,

Zur Information: Wenn ich von der Ermittlung des WAPT-Servernamens spreche, habe ich folgendes Tutorial von It-connect befolgt:

https://www.it-connect.fr/installer-wap ...logiciels/

Es verwendet dieselben Informationen wie hier, um die HTTP-Keytab zu erstellen:
https://www.wapt.fr/fr/doc-2.5/wapt-sec ... entication

Er fügte dem Befehl lediglich Folgendes hinzu:

Code: Alle auswählen

sudo msktutil --server DOMAIN_CONTROLER --precreate --host $(hostname) -b cn=computers --service HTTP --description "host account for wapt server" --enctypes 24 -N

Eine OR-Partition trennt die Daten und platziert sie in einer „Bereitstellungs“-OR-Partition, um zu verhindern, dass sie direkt in den Computer gelangen, wenn ich das richtig verstehe. Auf meinem System sieht das folgendermaßen aus:

Code: Alle auswählen

msktutil --server Serv2022ADTEST.adtest.local --precreate --host $(hostname) -b ou=Provisioning, dc=adtest,dc=local --service HTTP --description "host account for wapt server" --enctypes 24 -N

Wenn das irgendjemandem bekannt vorkommt, sehe ich nicht, wo ich bisher etwas falsch gemacht haben könnte.

DANKE,

Gregory.