Ruhiges IT-Forum

Hallo,
wir betreiben hauptsächlich Windows-Rechner, die im Allgemeinen sehr gut funktionieren. Wir möchten jedoch WAPT auf den wenigen Macs installieren, die wir notgedrungen nutzen müssen.
Die Registrierung in der WAPT-Konsole verlief problemlos; die Macs werden korrekt angezeigt, und wir können Pakete problemlos darauf übertragen und installieren.
Allerdings ist das Self-Service-Repository erschreckend leer, und es scheint kein Äquivalent zum WAPT-Tray zu geben (was sehr schade ist!).
Wir vermuteten, dass dies daran liegt, dass die Macs nicht in Active Directory (genauer gesagt Samba-AD) eingebunden sind, und haben sie daher in dieselbe Organisationseinheit (OU) wie die Windows-Rechner verschoben. Leider hat nichts geholfen; das Self-Service-Repository ist weiterhin leer.
Das „Self-Service“-Paket, das die Pakete enthält, die wir den Mitarbeitern zur Verfügung stellen möchten, ist korrekt auf den Macs installiert. Es enthält Gruppendeklarationen, die die an den Macs angemeldeten Benutzer auflisten, sowie die für diese Gruppen bereitgestellten Anwendungen und Anwendungen, die auch in einer macOS-Version im Repository verfügbar sind.
Die Authentifizierung im Self-Service-Portal erfolgt über „System“, sofern ich mich nicht irre.
Wir verwenden WAPT 2.6.0.16767, das heute aktualisiert wurde.
Ich habe in der waptservice.log-Datei nachgesehen, aber dort werden nur 0 Pakete angezeigt.
Hat jemand eine Idee, woran das liegen könnte?

Hallo,

haben Sie auf dem Mac ein lokales Benutzerkonto mit demselben Namen wie der angemeldete Domänenbenutzer?

Existiert auf dem Mac eine Datei `/etc/krb5.conf`?

Werden die Active Directory-Informationen für den Mac in der Konsole korrekt angezeigt (z. B. die Organisationseinheit des Rechners)?

Welche Version von Samba Active Directory verwenden Sie?

Alternativ könnten Sie den Modus `
service_auth_type=waptserver-ldap`

. Dadurch wird die Authentifizierung an den WAPT-Server übertragen (die LDAP-Authentifizierung muss auf dem WAPT-Server konfiguriert sein).

Vielen Dank für eure Antworten!
Hier ist mein Feedback:
Haben Sie auf Ihrem Mac ein lokales Benutzerkonto mit demselben Namen wie der Domänenbenutzer? => Nun ja und nein. Wir verwenden sogenannte „mobile“ Benutzerkonten, die über die Active Directory-Verbindung mit den Namen der Active Directory-Konten erstellt werden. Diese Konten werden automatisch beim Anmelden angelegt, sind aber keine wirklich lokalen Konten.

Gibt es eine /etc/krb5.conf-Datei auf dem Mac? => Ja, ich bestätige, mit den korrekten Active Directory-Verbindungsinformationen

Die Administratorinformationen für den Mac werden in der Konsole korrekt angezeigt. (Zum Beispiel die Organisationseinheit des Rechners?) => Ja, ich sehe die Rechner in der richtigen Organisationseinheit in der Baumansicht links

Welche Samba Active Directory-Version verwenden Sie? => 4.19.9

Ich sehe jedoch in der Konsole, dass das angemeldete Konto, wie von wapt erkannt, das lokale Konto mit Administratorrechten ist. Das AD-Konto hat auf dem Rechner keine Administratorrechte (daher scheint die Verwendung von wapt-get-Befehlen, anders als unter Windows, unmöglich).
Wenn ich jedoch das Self-Service-Portal öffne, erscheint mein AD-Benutzer in der unteren linken Ecke.

Für den Betrieb mit: Wir haben es nach dem Upgrade auf Version 2.6 auf Windows-Rechnern getestet, stießen dabei aber auf zahlreiche Fehler und mussten eine Agentenkonfiguration auf allen Rechnern verteilen, um den Systemmodus wiederherzustellen; andernfalls wäre die Selbstbedienung nicht möglich gewesen. Die gesamte LDAP-Konfiguration erfolgte serverseitig auf dem WAPT-Server; die Tests mit dem Skript verliefen erfolgreich Das sind die Fehler, die wir gemacht haben:

yoann.montouchet schrieb: ↑13. Januar 2025 - 09:30 Für den Betrieb mit:

Code: Alle auswählen

 service_auth_type=waptserver-ldap

Wir haben es auf Windows-Rechnern ausprobiert, nachdem wir auf Version 2.6 aktualisiert hatten. Dabei traten jedoch viele Fehler auf, und wir mussten eine Agentenkonfiguration auf alle Rechner übertragen, um eine Rückkehr in den "System"-Modus zu erzwingen. Andernfalls funktionierte die Selbstbedienung nicht.
Das sind die Fehler, die wir gemacht haben:

Code: Alle auswählen

2025-01-10 14:13:37,294 [wapttasks CP Server Thread-11 19600] WARNING check_auth_groups: Self service authentication failed for yoann.montouchet: Invalid input name: builtin\utilisateurs
2025-01-10 14:13:44,111 [wapttasks CP Server Thread-10 23876] WARNING check_auth_groups: Self service authentication failed for yoann.montouchet: Invalid input name: builtin\utilisateurs
2025-01-10 14:13:50,884 [wapttasks CP Server Thread-5 19640] WARNING check_auth_groups: Self service authentication failed for yoann.montouchet: Invalid input name: builtin\utilisateurs
2025-01-10 14:13:57,681 [wapttasks CP Server Thread-4 9412] WARNING check_auth_groups: Self service authentication failed for yoann.montouchet: Invalid input name: builtin\utilisateurs
2025-01-10 14:14:04,475 [wapttasks CP Server Thread-6 23348] WARNING check_auth_groups: Self service authentication failed for yoann.montouchet: Invalid input name: builtin\utilisateur

Haben Sie "builtin\user" in Ihr Self-Service-Regelpaket aufgenommen?

In diesem Fall wäre es besser, „Domänenbenutzer“ zu verwenden

Ich kann das bestätigen! Tatsächlich sind die meisten Pakete im Self-Service-Bereich dieser Gruppe zugeordnet!
Ich kümmere mich um die Behebung und führe die Tests mit waptserver-ldap erneut durch.
Ich halte dich auf dem Laufenden, danke!

Ich kann bestätigen, dass waptserver-ldap nun einwandfrei funktioniert (SSO ist also in Ordnung! ) und dass das Problem mit der Selbstbedienung auf Macs behoben wurde.
Ich schlage vor, die Dokumentation zu aktualisieren und die Änderung des Standardparameters für „service_auth_type“ deutlicher hervorzuheben. Auf unserem System führte das Upgrade von Version 2.5.5 auf 2.6.0 dazu, dass die Selbstbedienung aufgrund dieser Änderung nicht mehr funktionierte!
Vielen Dank für Ihre Hilfe!

Danke für das Feedback.

Normalerweise sollte filetoken funktionieren.

Ich frage mich, ob nicht builtin\utilisateurs den Absturz verursacht hat!

Eine weitere Möglichkeit, wie bereits erwähnt, ist, dass ein lokales Konto mit demselben Namen existiert.