GroupWise SSO with Azure / Entra joined device

Question

Hi everyone, 
 
 I am currently trying to make GroupWise SSO work with an Azure/Entra joined device. 
 So the device is not domain joined, it is only Entra joined. But has line of sight to the domain controllers so it actually receives the Kerberos TGT. 
 The problem is, the client does not receive the Kerberos ticket for the groupwise SPN (service principle name). 
 If I join the device to the onprem AD, everything works fine, the ticket for groupwise gets granted and I am able to login seamlessly. 
 
 Does anyone have an idea or experience what can be done here? 
 
 Regards, 
 Philipp 
 
 PS: The reason behind going the Entra way is I want to implement a way for our users to work in office and mobile / in home office as seamlessly as possible.

Sebastijan Sef · Answer

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: 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) Client (groupwise client or web browser) needs to request Kerberos token for that specific service from OS Window OS requests Kerberos token for authenticated user from KDC (AD DC in "traditional" setup) KDC issues token to client Client (groupwise client or web browser) presents Kerberos token to service (groupwise POA or web server) Service (groupwise POA or web service) extracts user information from Kerberos token (in Linux environment using keytab file). Extracted information is in format @ (kerberos realm is same as AD domain in ALLCAPS). Kerberos ticket can also hold additional information when using PAC. 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

Menu

GroupWise Discussions

GroupWise SSO with Azure / Entra joined device

Tags:

Top Replies

Resources