Tranquil IT Forum

Good morning,
We upgraded to version 2.7.19598 yesterday on our server (enterprise license). The server is running Debian 13 Trixie (also upgraded yesterday; previously we were on Debian 11 and then Debian 12).
Since this transition, we have had a change in behavior regarding self-service; the authentication we were using is no longer functional.
This is somewhat related to this topic: viewtopic.php?t=4581 which we had not continued on.
At the time, for the Macs we were deploying, we finally decided not to integrate them into our AD directory (which didn't offer any practical benefit), and to enable self-service, we configured all the agents (Windows and macOS) with:
service_auth_type=waptserver-ldap
use_kerberos = False

With this configuration, when the self-service area opened, the login/password was requested by the self-service system, which was then verified by the server with Active Directory (samba-ad). Overall, this worked well for us.
The WAPT server is correctly authenticated with AD; I was able to request a Kerberos ticket and then authenticate with it (via "curl -v --negotiate -u: https://si-wapt-01.ad.xxx.fr/api/v3/login_kerberos -k") without worry: Since the version upgrade, with the same configuration (waptserver-ldap and without kerberos), we are getting the following error on Windows machines: on Macs: By keeping waptserver-ldap and enabling Kerberos, there are no more errors on the Windows side, but no packages are visible.
And an error on the Mac side: We tried other combinations (system, waptagent-ldap) without success and the only one that seems to restore the Windows side would be to put it in filetoken, there we find the expected content in the self-service, but on the mac we continue to see nothing, as in last March I think.

In short, I'm a bit lost and don't know where to look anymore, and we're stuck with just under twenty Macs that haven't been able to open the self-service system since yesterday.

Do you have any idea what the cause might be and how to fix it, please?

EDIT: Important information, but the "testing-ldap-connectivity.sh" test is OK: EDIT 2: I have an initial explanation; my self-service system uses short "groupnames" and not full namesgroupname@ad.xxx.fr".
By adding a group like this in waptserver-ldap+kerberos configuration, on the Windows side I see the packages arriving in the self-service.
But on the Mac side, it's still showing an error...

EDIT 3: Another potentially interesting piece of information, but on the Mac side, Kerberos authentication seems to be working correctly:

I've made some progress; you need to use the name Kerberos in capital letters: yoann.montouchet@AD.XXX.FR at the kinit level, and use a temporary file to store the token, and export the path to the token:
kinit -c FILE:/tmp/krb5cc_$(id -u) yoann.montouchet@AD.XXX.FR
export KRB5CCNAME=FILE:/tmp/krb5cc_$(id -u)

then launch manually in the same terminal:
/Applications/WAPT/WAPT\ Self-service.app/Contents/MacOS/waptself

At that point, the self-service area opened correctly with the expected packages. But there was no button to manage the packages! Clearly, it's going to be extremely difficult to industrialize these steps for colleagues... Do you have a cleaner idea, please?

Hi Yoann,

regarding the display bug in the self-service interface, we've reproduced it and it's being fixed (the issue is a difference in behavior between Intel and ARM Macs).

Concerning the self-service authentication/group retrieval problem, a patch was pushed to the nightly build on Friday to address certain issues. I'll check with my colleagues to see if it covers the problem of non-domain machines using domain login/password authentication.

That said, I personally recommend joining macOS to the domain (it works well these days, though it wasn't always the case ). This notably ensures password rotation.

We're running one last set of tests and will push an update soon.

Best regards,

Denis

Hi Denis,
The problem in our case with the Macs is that our domain isn't accessible to the machines when they log in, only via a VPN that only runs once the session is open.
As a result, password rotation doesn't work, among other things.
We had to deploy MDM on these machines specifically to manage password rotations and deploy policies like Active Directory would on a Windows machine (but not on a Mac).
So we didn't see any point in continuing to try to integrate them into Active Directory...
We had an example of a Mac integrated into our Active Directory; the account password was still recognized and accepted on the Mac despite a change in Active Directory, even several weeks after the change, and despite the VPN being connected (after logging in).
In short, we're open to a solution. As a last resort, we've created a workaround that allows refreshing a Kerberos token locally before launching self-service. We've packaged and deployed it via Wapt, and it seems to work as a temporary fallback solution.

Hello Denis,
I saw this morning that a new version (2.7.0.19633) has been released. I haven't seen a changelog yet, but I've noticed that Mac authentication (without using a manually generated Kerberos token) is still broken I had to roll back the self-service package configuration; I had modified the group names to put a kind of UPN (by adding @ad.xxx.fr to each group). This was necessary on the previous version, but after the switch to 19633 I no longer saw any packages on the machines.
By removing this from the groups and redeploying the new self-service package on the machines, I can see the packages again, and I can see the install/update/uninstall buttons on the Macs with Apple Silicon processors!

I made an "app" with Automator to generate a Kerberos ticket for the user, then launch the real self-service on the Macs using the generated token; it seems to work pretty well, I will probably deploy this initially on our fleet.

Good morning

So that I can do a test

Your configuration is as follows:
?