problème self service suite à passage WAPT 2.7

yoann.montouchet · 08 oct. 2026 - 15:12

Bonjour,
Nous sommes passés hier en version 2.7.19598, sur notre serveur (licence enterprise). Le serveur tourne sous Debian 13 trixie (montée de version également hier, avant on était en Debian 11 puis Debian 12).
Depuis ce passage nous avons eu un changement de comportement par rapport au self-service, l'authentification que nous utilisions n'est plus fonctionnelle.
C'est un peu en lien avec ce sujet : viewtopic.php?t=4581 sur lequel nous n'avions pas continué.
A l'époque, pour les macs que nous déployions, nous avions finalement pris la décision de ne pas les intégrer dans notre annuaire AD (qui n'apportait en pratique rien d'utile concrètement), et pour faire marcher le self-service nous avions configuré tous les agents (windows+macos) avec :
service_auth_type=waptserver-ldap
use_kerberos = False

Avec cette configuration, lors de l'ouverture du self-service le login/pass était demandé par le self-service ce qui était contrôlé par le serveur auprès de l'AD (samba-ad). Globalement cela nous convenait bien.
Le serveur WAPT est bien authentifié correctement auprès de l'AD, j'ai pu demander un ticket kerberos et m'authentifier ensuite avec (via le "curl -v --negotiate -u : https://si-wapt-01.ad.xxx.fr/api/v3/login_kerberos -k") sans soucis :

Code : Tout sélectionner

{"success":true,"msg":"Authentication OK","request_time":0.04843854904175,"result":{"auth_result":{"auth_method":"kerb","user":"yoann.montouchet@ad.xxx.fr","auth_date":"2026-10-08T12:58:39.508967+00:00","roles":[],"auth_otp_validated":false},"server_uuid":"xxx","version":"2.7.0.19598","server_domain":"ad.xxx.fr","edition":"enterprise","user_acls":{},"token":null}}

Depuis la montée de version, avec la même configuration (waptserver-ldap et sans kerberos), nous obtenons l'erreur suivante sur les postes windows :

: Capture d'écran 2026-10-08 150108.png (11.35 Kio) Consulté 6449 fois

sur les macs :

: Capture d'écran 2026-10-08 150225.png (55.57 Kio) Consulté 6449 fois

En gardant waptserver-ldap et en activant Kerberos, plus d'erreur côté Windows, mais aucun paquet visible.
Et erreur côté mac :

: Capture d'écran 2026-10-08 150436.png (48.22 Kio) Consulté 6433 fois

On a essayé d'autres combinaisons (system, waptagent-ldap) sans succès et la seule qui semble remettre en place côté Windows serait de mettre en filetoken, là on retrouve bien le contenu attendu dans le self-service, mais côté mac on continue de ne rien voir, comme au mois de mars dernier je pense.

Bref je suis un peu perdu et ne sais plus où chercher, et on est planté avec un peu moins d'une vingtaine de macs qui ne peuvent plus ouvrir le self-service depuis hier.

Auriez-vous une idée de la cause et de comment y remédier svp?

EDIT : une information importante mais le test "testing-ldap-connectivity.sh" est ok :

Code : Tout sélectionner

----------------------------------------------------------------
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
--------

EDIT 2 : j'ai une première explication, mon self service utilise des noms courts "groupname" et non des noms complets "groupname@ad.xxx.fr".
En ajoutant un groupe comme ça en configuration waptserver-ldap+kerberos, côté Windows je vois les paquets arriver dans le self-service.
Mais côté mac ça reste en erreur...

EDIT 3 : autre information potentiellement intéressante mais côté mac l'authentification kerberos semble bien fonctionnelle :

Code : Tout sélectionner

yoann.montouchet@XXX~ % kinit yoann.montouchet@ad.xxx.fr
yoann.montouchet@ad.xxx.fr's password: 
yoann.montouchet@XXX~ % klist
Credentials cache: API:91B80912-6A34-4F3E-A1EC-B450011A2DAA
        Principal: yoann.montouchet@AD.XXX.FR

  Issued                Expires               Principal
Oct  8 16:05:17 2026  Oct  9 02:05:12 2026  krbtgt/ad.xxx.fr@AD.XXX.FR

yoann.montouchet · 08 oct. 2026 - 16:43

J'ai un peu progressé, il faut utiliser avoir le nom kerberos en majuscule : yoann.montouchet@AD.XXX.FR au niveau du kinit, et utiliser un fichier temporaire en stockant le jeton, et exporter le chemin vers le jeton :
kinit -c FILE:/tmp/krb5cc_$(id -u) yoann.montouchet@AD.XXX.FR
export KRB5CCNAME=FILE:/tmp/krb5cc_$(id -u)

puis lancer à la main dans le même terminal :
/Applications/WAPT/WAPT\ Self-service.app/Contents/MacOS/waptself

A ce moment là le self-service s'ouvre bien avec les paquets attendus. Mais pas de bouton pour gérer les paquets!

: Capture d'écran 2026-10-08 162907 (Petit).png (143.38 Kio) Consulté 6354 fois

Clairement ça va être vachement difficile d'industrialiser ces étapes pour les collègues... Est-ce que vous auriez une idée plus propre svp?

12 oct. 2026 - 10:47

Bonjour Yoann,

pour le bug d'affichage dans le selfservice, on l'a reproduit et c'est en cours de correction (pb différence de comportement en mac intel vs mac arm).

Par rapport au problème d'auth / récupération de groupe selfservice, un correctif a été poussé en nightly vendredi pour corriger certain soucis, je vais voir avec les collègues si ça prend en compte le pb des postes hors domaines avec une auth login/pwd sur domaine.

Ceci dit, perso je recommande d'intégrer les macOS au domaine (ça marche bien de nos jours, ça n'a pas été toujours le cas

). Ca permet notamment de garantir la rotation des mots de passes.

On fait une dernière batterie de test et on pousse une mise à jour rapidement.

Cordialement,

Denis

yoann.montouchet · 13 oct. 2026 - 09:07

Bonjour Denis,
Le problème dans notre cas pour les macs c'est que notre domaine n'est pas joignable par les machines lors de leur login, uniquement via vpn qui ne tourne qu'une fois la session ouverte.
Du coup la rotation des mots de passe ne fonctionne pas notamment.
On a du déployer un MDM sur ces machines spécifiquement pour gérer les rotations de mot de passe et déployer des stratégies comme un AD ferait sur un poste Windows (et ne fait pas sur un mac).
Du coup on n'a pas perçu d'intérêt à continuer de tenter de les intégrer dans l'AD...
On avait un exemple d'un mac intégré dans notre AD, le mot de passe du compte était toujours reconnu et accepté sur le mac malgré un changement côté AD, même plusieurs semaines après changement, et malgré le vpn connecté (après l'ouverture de session).
Bref on est preneur d'une solution, au pire on a fait un contournement qui permet de refresh un token kerberos localement avant de lancer le self-service, on l'a packagé et déployé via wapt, ça semble fonctionner en tant que solution de repli temporaire.