I just found out that the Entra joined device is actually able to manually receive a Kerberos ticket for the groupwise specific SPN if I run the command

klist get groupwise/server.my.domain.com

Yet SSO still does not work and I get prompted for a password when trying to start the GW client even with the received Kerberos ticket. I guess I have to hand this over to support.

Based on the initial info "the device is not domain joined, it is only Entra joined, If I join the device to the onprem AD, everything works fine."

I seem to see the logic as GW is using the user association to an AD object an this info in GW must match the AD info provided/found from the workstation info. 

Is this available and has a match with the associated objected info GW the userID for this user in GW is used to start the mail with SSO, if this is not available ( no match) then SSO will not work

Also the POA might give more info based on the error reported in verbose level when SSO is not working

Which exact info is GW client requesting from the workstation in the background to decide whether to use SSO or not?

For example if I run a "whoami" on a on-prem client and the Entra client both give me the same username "ad\philipp".

Imho the POA log does not log useful information while trying to SSO on the Entra device.

Which exact info is GW client requesting from the workstation in the background to decide whether to use SSO or not?

For example if I run a "whoami" on a on-prem client and the Entra client both give me the same username "ad\philipp".

Imho the POA log does not log useful information while trying to SSO on the Entra device.

This is the workstation user credentials the client gets at startup when the admin has set Allow single sign-on via Network authentication (eDirectory or Active Directory) and the client has the option set "No password required with eDirectory" as this used like the admin option for both AD and eDirectory

If the POA sees the AD credentials, network authentication is enabled and the POA is on a machine that is part of an AD domain then the POA will try to verify those credentials, based on this the client logon happens or the password is asked when it fails

The match should be with the full LDAP DN/GUID that can be seen in GW on the user (general tab) as this is the only info GW has about the AD user when it was associated with the AD object over LDAP in GW

This is the only way to match the GW user 100% with an user thats on the workstation so the key is what the user credentials are on the workstation at the time the client starts. 

For this reason i believe as you wrote "If I join the device to the onprem AD, everything works fine" the issue is the credentials in GW do not match the workstation credentials when this is not the case