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

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