Have you established Cloud Kerberos Trust from Entra to onprem AD?

In last few weeks I was playing in my lab with similar setup to get kerberos token for Access Manager on Entry only joined devices (not hybrid) and after setting this up it started to work.

Hi Sebastijan,

thanks for the hint. I followed MS' docs to deploy cloud kerberos trust.

https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust?tabs=gpo

I am unsure if the created Kerberos-Server- and User-Objects should also be present in the Entra Tenant or just in the on prem AD.

But if I check the Entra joined device I get an Entra ticket and an on-prem ticket. dsregcmd /status shows:

OnPremTgt : YES
CloudTgt : YES

For me it seems to be deployed correctly. 

Unfortunately the device is still not receiving the ticket for the GroupWise server...

Does anybody else have any idea and/or experience with that? I have a question open over there at Microsoft but currently waiting for a response there aswell.

Should I reach out to OT support? Since it is a very uncommon "issue" I fear the case will take forever to reach a certain level of escelation...

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.

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

Is it possible to verify the credentials the client receives from the workstation on the workstation itself? Does it search for some registry keys? I am currently looking into the starting process of the client with process monitor.

By the explanation you gave, I assume that the windows login on an Entra joined device is done via UPN  username@my.domain.com and onprem via SAMAccountName DOMAIN\username. I guess this messes with the whole SSO thing.

I dont know on code level what/how the client exactly does, its not a reg setting but based on the log in the lab I see

POA log diag level with AD user on workstation authenticated to AD

12:52:46:659 D54F Novell client credentials received:
12:52:46:659 D54F Name = userID
12:52:46:659 D54F Tree = ROBVKDC
12:52:46:659 D54F LDAP GUID = A7F407F5562DAC44BBD36A844A8B6AC7

GWadmin user info
LDAP DN: CN=userID,OU=gwise,DC=robvk,DC=com
Directory: ADLAB
LDAP GUID: f507f4a7-2d56-44ac-bbd3-6a844a8b6ac7

windows whoami
robvkdc\userID

SSO working with the above

When I do not login as the user but Im on the workstation thats in the domain and starting GW i get asked for the password and see

14:22:47:455 D567 Novell client credentials received:
14:22:47:455 D567 Name = Administrator
14:22:47:456 D567 Attempting token authentication for user userID (userID)
14:22:47:456 D577 Resetting read descriptors
14:22:47:456 D567 Error: The authentication token is corrupt, malformed or otherwise invalid [D090] in _WpeGssAcceptContext (gss_accept_sec_context=>(0x10000, 0x0))

On a workstation not in the domain i see only this and asked for the password

14:26:25:394 D567 Novell client credentials received:
14:26:25:394 D567 Name = Administrator

If the LDAP DN or GUID is used on code level also is the question but regardless this the info needs to be there and is not i assume when the device is not joined onprem or not the same as what GW knows... 

Hm, seems like GW just doesn't even attempt to try token auth when joined onprem even tho the correct user is handed over:

10:46:23:380 B80A C/S Login Windows Net Id=philipp ::GW Id=philipp :: x.x.x.213
10:46:23:380 B80A Processing action: Login (philipp)
10:46:23:380 B80A Novell client credentials received:
10:46:23:380 B80A Name = philipp
10:46:23:381 B83B Resetting read descriptors
10:46:23:384 B80A Action done: Login (philipp)

While joined onprem:

14:19:02:114 AB52 C/S Login Windows Net Id=philipp ::GW Id=philipp :: x.x.x.213
14:19:02:114 AB52 Processing action: Login (philipp)
14:19:02:114 AB52 Novell client credentials received:
14:19:02:114 AB52 Name = philipp
14:19:02:115 B83B Resetting read descriptors
14:19:02:115 AB52 Attempting token authentication for user philipp (philipp)
14:19:02:127 AB52 Action done: Login (philipp)

But I see a difference to your lab after checking the GWAdmin info:

LDAP-DN: CN=Philipp Naether,OU=EDV,OU=DEZ1,OU=sv,DC=ad,DC=stadt-meissen,DC=de

So the CN is not the user ID that is reported in the log. Isn't it strange then that this does work with onprem joined device?