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?

with the userID still it can get the LDAP DN and/or GUID in GW and use that with what the workstation is providing more with the user credentials and see if this matching so i still think onprem gives the actual info needed back to do this.

So at the end of the day - Entra is just not supported because GW sees the device simply as a "not AD joined device" and therefore doesn't even try to start the token authentication process.

Since I am positive, an Entra joined device is able to provide the necessary information in theory, is it possible to get this topic handed over to development? 

I just checked the docu on this and its stated there as well:

• Make sure both the POA Server and the user workstation are joined to the same Active Directory domain.

https://www.novell.com/documentation/groupwise24/gw_guide_admin/data/b1f0s9uy.html

If you can provide in the case thats open the data that shows the needed/right data based on the above is provided with Entra not in the domain we can look at this

Hm, I don't understand. How should I know which data is needed or right for GW? That's why I asked if it can get handed over to development since they should know what the code does or does not. To give information about data an Entra joined device provides, I first have to know which data to search for, don't I? Or did I get something wrong?

Based on different LAN traces taken on the workstation (with user login and with user not login) and  the AD server you see exactly what happens and you can compare a working and non working SSO login.

There is a big difference in traffic from the workstation(OS) to the AD server in the working against the not working one meaning when the workstation is not in the domain or  in the domain but not a user login ( so local administrator)

The working one shows the Kerberos actions happen on OS level and are done before even the client is contacting the POA after starting.

The OS requesting a Kerberos ticket after the client startup only happens when in the domain and the user did login on the workstation, then the OS is the one using this ticket to do a LDAP search for getting the GUID and the sAMAccountName based on the user on the workstation, the result is used later on by the POA to do a LDAP search for the GUID as provided by the OS to the client, based on this the POA verification happens for the user to get the Full DN as mentioned earlier you can see in the general tab in gwadmin. The POA does the LDAP search using the defined LDAP server that is used to associate the user to the AD object. If all is matching the client starts without a password question

There is a lot more done between the workstation and the AD server in relation to LDAP and Kerberos but the above is a short version. The key is that the OS itself is first of all the one using Kerberos between the workstation and AD server but only when it finds it is part of the AD domain. 

So with a LAN trace all will be clear in what happens when and where, you can make them and compare in your system as well

Based on different LAN traces taken on the workstation (with user login and with user not login) and  the AD server you see exactly what happens and you can compare a working and non working SSO login.

There is a big difference in traffic from the workstation(OS) to the AD server in the working against the not working one meaning when the workstation is not in the domain or  in the domain but not a user login ( so local administrator)

The working one shows the Kerberos actions happen on OS level and are done before even the client is contacting the POA after starting.

The OS requesting a Kerberos ticket after the client startup only happens when in the domain and the user did login on the workstation, then the OS is the one using this ticket to do a LDAP search for getting the GUID and the sAMAccountName based on the user on the workstation, the result is used later on by the POA to do a LDAP search for the GUID as provided by the OS to the client, based on this the POA verification happens for the user to get the Full DN as mentioned earlier you can see in the general tab in gwadmin. The POA does the LDAP search using the defined LDAP server that is used to associate the user to the AD object. If all is matching the client starts without a password question

There is a lot more done between the workstation and the AD server in relation to LDAP and Kerberos but the above is a short version. The key is that the OS itself is first of all the one using Kerberos between the workstation and AD server but only when it finds it is part of the AD domain. 

So with a LAN trace all will be clear in what happens when and where, you can make them and compare in your system as well

Hi!

Unknown said:

The key is that the OS itself is first of all the one using Kerberos between the workstation and AD server but only when it finds it is part of the AD domain

When cloud Kerberos trust is established between onprem AD domain and Entra, domain computer does not need to be member local AD domain for Kerberos to work. It is enough to be member of that specific Entra domain. Evidence for that is that manually requesting Kerberos ticket from onprem domain controller works on Entra only joined computer (see above where Philipp mentions "klist get groupwise/server.my.domain.com" command)

In general, Kerberos authentication on AD joined computer works like this:

1. User on AD joined computer wants to access service with a client (e.g. groupwise client connecting to POA or web browser  connecting to web service requiring Kerberos authentication) 
2. Client (groupwise client or web browser) needs to request Kerberos token for that specific service from OS
3. Window OS requests Kerberos token for authenticated user from KDC (AD DC in "traditional" setup)
4. KDC issues token to client
5. Client (groupwise client or web browser) presents Kerberos token to service (groupwise POA or web server)
6. Service (groupwise POA or web service) extracts user information from Kerberos token (in Linux environment using keytab file). Extracted information is in format <samAccountName>@<kerberos realm> (kerberos realm is same as AD domain in ALLCAPS). Kerberos ticket can also hold additional information when using PAC.
7. Service (groupwise POA or web service) uses extracted information to find user in backend directory and authenticates user

When this is Entra only joined device and cloud Kerberos trust is established, difference is only in step 3.

In step #3, Windows OS requests Kerberos token from onprem KDC (domain controller) by presenting a partial TGT that it received from Microsoft Entra ID from a previous Microsoft Entra authentication to the domain controller. The partial TGT contains only the user SID, and it's signed by Microsoft Entra Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client.

So in theory, there should be no need to change anything on client or service, client should just request Kerberos token from OS, because everything regarding getting Kerberos token is handled internally by MS.

My guess is that problem lies in step #2 and Groupwise client is not requesting Kerberos token at all. If it would, everything would work, since Windows OS is able to provide correct Kerberos token for authenticated user. Probably Groupwise client is doing some internal checks to decide if Kerberos token can be requested and those checks take into account only "traditional" on-prem AD joined computers.

Kind regards,

Sebastijan

In different ways we see the same thing you know more about the details then i do, i was looking at the traces on what happens. I agree the problem most likely is the request done or not and this would be a request for enhancement for the client