Wapt-Selbstbedienung auf macOS

yoann.montouchet · 2. März 2026 – 13:08 Uhr

Hallo zusammen,

Es tut mir leid, Sie mit einem Problem zu belästigen, das mir so trivial erscheint, aber ich bin am Verzweifeln wegen der Konfiguration eines wapt-Agenten unter macOS 26.3.
Die Workstation ist neu installiert, die Verbindung zur Domäne funktioniert und das VPN ist eingerichtet.
Wir können den Beitrag in der wapt-Konsole deutlich sehen, wir können von dort aus problemlos Pakete übertragen.

Sie können die auf dem Server verfügbaren Pakete auch über "wapt-get search" anzeigen und problemlos installieren.

Die Selbstbedienungsfunktion funktioniert jedoch nicht. Es wird stets die Meldung „Keine Ergebnisse gefunden“ angezeigt

: Screenshot 2026-03-02 130303.png (222,37 KB) 4847 Aufrufe

Ich weiß, dass wir einen anderen Mac bereits erfolgreich konfiguriert haben, und er funktioniert auch heute noch. Aber ich kann nicht herausfinden, was bei diesem hier fehlt... Gibt es irgendwo ein Protokoll, das wir verwenden könnten?

Hier ist die aktuelle wapt-get.ini-Datei (identisch mit der des anderen, aktuell funktionierenden MacBook m1):

Code: Alle auswählen

[global]
repo_url=https://wapt.xxx.xx/wapt
wapt_server=https://wapt.xxx.xx
verify_cert=/opt/wapt/ssl/server/wapt.xxx.xx.crt
use_ad_groups=1
allow_remote_reboot=1
allow_remote_shutdown=1
service_auth_type = waptserver-ldap
use_kerberos = True
notify_user = 0
locales  = fr,en
loglevel=warning
log_to_windows_events=0
use_http_proxy_for_repo=0
use_http_proxy_for_server=0
tray_check_interval=2
use_hostpackages=1
ad_groups_use_nested_group=1
timeout=10
wapt_server_timeout=30
maturities=PROD
default_maturity=
http_proxy=
token_lifetime=86400
trust_all_certs_in_pems=0
default_sources_root=/var/root/waptdev
default_package_prefix=tis
default_sources_suffix=wapt
default_sources_url=
upload_cmd=
upload_cmd_host=
after_upload=
personal_certificate_path=
check_certificates_validity=1
use_fqdn_as_uuid=0
uninstallkey_timeout=120

Wir verwenden definitiv „wapt enterprise“, Version 2.6.1.17705, der Mac befindet sich in der richtigen Organisationseinheit, und es gibt ein „Self-Service“-Paket, das ich manuell ohne Änderungen installiert habe … Hilfe!!!

NACHTRAG: Ein Detail, das vielleicht nützlich ist: Ich habe es mit Domänenbenutzern getestet, die Administratoren des Macs sind bzw. nicht sind, und es hat sich nichts geändert.

2. März 2026 – 13:11 Uhr

Guten Morgen

Ich verstehe :

Code: Alle auswählen

service_auth_type = waptserver-ldap
use_kerberos = True

Das ist genau die Konferenz, die funktioniert.

Auf dem Wapt-Server können Sie einen Befehl starten, um den LDAP-Teil zu testen

Code: Alle auswählen

/opt/wapt/waptserver/scripts/testing-ldap-connectivity.sh

Wenn es funktioniert, sollten Sie Folgendes sehen:

Code: Alle auswählen

[OK] Test SSO SELFSERVICE LDAP with ldap_account_service_login

yoann.montouchet · 2. März 2026 – 13:22 Uhr

Ich bestätige, dass die Konfiguration auf dem Server für mich in Ordnung zu sein scheint:

Code: Alle auswählen

----------------------------------------------------------------
Test SSO SELFSERVICE LDAP with ldap_account_service_login
----------------------------------------------------------------
Username : yoann.montouchet
Group test member : Domain Users
----------------------------------------------------------------
[OK] Test SSO SELFSERVICE LDAP with ldap_account_service_login
----------------------------------------------------------------
Test ldap with direct Login
----------------------------------------------------------------
Username ldap: yoann.montouchet
Password ldap:
Group test member : Domain Users
--------
ALL GOOD
--------

Aber ich fasse mich kurz: Ich habe versucht, den Protokollierungsgrad auf Debug zu ändern. Dann habe ich den wapt-Dienst neu gestartet, und danach verstehe ich nicht mehr weiter Ich kann nun den angezeigten Inhalt sehen...

: Screenshot 2026-03-02 132241 (Small).png (155,2 KB) 4830 Aufrufe

Hinsichtlich der heute durchgeführten Maßnahmen sehe ich nur zwei Dinge: die Installation des Self-Service-Pakets und den anschließenden Neustart des wapt-Dienstes. Könnten diese beiden Elemente erklären, warum es jetzt funktioniert?

Ansonsten verstehe ich es nicht...

NACHTRAG: Okay, das war's, es lag am Hinzufügen des Self-Service-Pakets, das die Funktion freigeschaltet hat, möglicherweise gefolgt von einem Neustart des Dienstes... Ich werde das in meiner Dokumentation vermerken!

2. März 2026 – 13:27 Uhr

Interessant.

Funktioniert es, wenn Sie den Selbstbedienungsbereich schließen und dann wieder öffnen?

yoann.montouchet · 2. März 2026 – 13:31 Uhr

Ja, es funktioniert noch. Ich kann bestätigen, dass das fehlende Self-Service-Paket das Problem war. Ich weiß nicht, warum das Hinzufügen vorher nicht geholfen hat, aber jetzt funktioniert es einwandfrei.
Wenn man das Paket entfernt, ist der Self-Service-Bereich leer; durch das erneute Hinzufügen wird der Inhalt wiederhergestellt.
Eine weitere Frage, die möglicherweise normal ist: Self-Service sollte für alle Rechner in einer Organisationseinheit (OU) installiert sein, aber der Mac ist nur in der Gruppe „(Alle)“ sichtbar; er verschwindet, sobald ich eine OU in der Verzeichnisstruktur aufrufe.
Ist das normal für Macs? Windows-Rechner werden korrekt in der entsprechenden OU angezeigt, die Macs jedoch nicht.

Nachtrag: Korrektur: Nur *dieser* Mac wird nicht in der richtigen OU angezeigt; die anderen Macs funktionieren einwandfrei (und Self-Service wurde für sie automatisch installiert).

2. März 2026 – 14:11 Uhr

Sie können versuchen, das Video auf dem Mac anzusehen:

Code: Alle auswählen

wapt-get shell
>>> get_domain_info()

yoann.montouchet · 2. März 2026 – 14:57 Uhr

Das ist seltsam, anscheinend kann er keine Verbindung zu AD herstellen, obwohl es erreichbar ist, und ich konnte auf meiner Seite einen AD-Benutzer hinzufügen:

: Screenshot 2026-03-02 145457 (Small).png (131,96 KB) 4788 Mal angesehen

Ich werde versuchen, das System neu zu starten und von vorne anzufangen

NACHTRAG: Das Problem besteht auch nach einem Neustart, trotz bestehender VPN-Verbindung und selbst nach einem Neustart des Dienstes. Die Selbstverwaltung funktioniert, aber Active Directory scheint nicht erreichbar zu sein

Code: Alle auswählen

Python 3.10.19 (main, Dec 22 2025, 15:32:31) [Clang 14.0.0 (clang-1400.0.29.202)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> get_domain_info()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/opt/wapt/setuphelpers_unix.py", line 112, in get_domain_info
    error('Failed connect to active directory')
  File "/opt/wapt/waptutils.py", line 2093, in error
    raise EWaptSetupException('Fatal error : %s' % reason)
waptutils.EWaptSetupException: Fatal error : Failed connect to active directory

yoann.montouchet · 2. März 2026 – 16:26 Uhr

Ich habe gerade einen anderen Mac aufgerufen, der korrekt in der Organisationseinheit angezeigt wird, aber wir erhalten dieselbe Fehlermeldung wie bei dem Mac, der uns heute Probleme bereitet. Könnte das mit unserer Infrastruktur zusammenhängen? Wir verwenden einen Samba-AD-Server auf Active Directory-Ebene, der aber nur über ein VPN erreichbar ist.

NACHTRAG: Ich habe denselben Befehl auf einem Windows-Rechner ausprobiert, er liefert noch weniger Informationen; seltsamerweise wird der Befehl dort einfach nicht erkannt!

Code: Alle auswählen

Python 3.10.19 (main, Jan 28 2026, 14:09:14) [MSC v.1929 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> get_domain_info()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
NameError: name 'get_domain_info' is not defined
>>> get_domain_info()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
NameError: name 'get_domain_info' is not defined
>>>

2. März 2026 – 17:19 Uhr

Sie können Folgendes versuchen:

Code: Alle auswählen

wapt-get shell
>>> client = pyldap.PyLdapClient(domain_name="mydomain.lan")
>>> print(client.bind_sasl_kerberos())

Und das hier:

Code: Alle auswählen

wapt-get shell
pyldap.cldap_get_domain_info(domain_name="mydomain.lan")

yoann.montouchet · 2. März 2026 – 17:24 Uhr

Okay, der erste Befehl schlägt auf dem problematischen Mac fehl:

Code: Alle auswählen

>>> client = pyldap.PyLdapClient(domain_name="ad.xxx.xx")
>>> print(client.bind_sasl_kerberos())
(False, '')

Auf dem Windows-Rechner funktioniert es; mein AD-Konto wird korrekt angezeigt.

Der zweite Befehl funktioniert:

Code: Alle auswählen

>>> pyldap.cldap_get_domain_info(domain_name="ad.xxx.xx")
{'nt_version': 5, 'logon_type': 'Anonymous', 'flags': 'PDC,GC,LDAP,DS,KDC,TimeServer,Closest,Writable,GoodTimeServer', 'guid': '{7492B563-849C-4422-B7E6-FDF790A36BBE}', 'forest': 'ad.xxx.xx', 'domain': 'ad.xxx.xx', 'host_name': 'xxx-xxx-xxx.ad.xxx.xx', 'netbios_domain': 'xx', 'netbios_hostname': 'xxx-xxx-xxx', 'unk': '', 'user': '', 'ip': 'xxx.xxx.xxx.xxx:389', 'server_site': 'Default-First-Site-Name', 'client_site': 'Default-First-Site-Name'}

Und hier habe ich auf beiden Maschinen die gleiche Zeile.

Ich werde den Mac überprüfen, der seine Organisationseinheit wiederherstellen konnte.
NACHTRAG: Ich habe das gleiche Verhalten bei dem Mac, der seine Organisationseinheit wiederherstellen konnte:

Code: Alle auswählen

>>> client = pyldap.PyLdapClient(domain_name="ad.xxx.xx")
>>> print(client.bind_sasl_kerberos())
(False, '')