Keyscan Aurora Kerberos only working when running as Administrator

[BFCS IT]

I'm working on implementing App Layering 1910, using Citrix MCS, XenServer 7.1 and XenDesktop 7.15 CU4. I'm having issues with an application, Keyscan Aurora, when running it on a Windows 10 box that is domain joined, Kerberos will kick in and log the user into the system automatically. This works great in a normal MCS image without App Layering or physical boxes. When I install it into its own Layer, it works just fine, but I have to run as administrator to get Kerberos to work for SSO.

 

Has anyone had issues with Keyscan or getting Kerberos based authentication working in Layers without admin rights? I'm trying to eliminate Admin rights on boxes and this one isn't helping my cause. Thank you for any help and pointing in any direction that might be helpful.

[Richard Buffone]

All SSO applications should be installed in the Platform layer. Please try installing Keyscan there and see if that corrects the issue.

 

 

Thank you

[BFCS IT]

23 minutes ago, Richard Buffone said:

All SSO applications should be installed in the Platform layer. Please try installing Keyscan there and see if that corrects the issue.

 

 

Thank you

 

Ok, I'll move it there and take a look. Thank you for the reply. :)

[BFCS IT]

36 minutes ago, Richard Buffone said:

All SSO applications should be installed in the Platform layer. Please try installing Keyscan there and see if that corrects the issue.

 

 

Thank you

 

Would an acceptable workaround be to logon the app layer to the domain, install the application, test kerberos, logoff the domain, ngen update and finalize?

[Richard Buffone]

7 minutes ago, BFCS IT said:

 

Would an acceptable workaround be to logon the app layer to the domain, install the application, test kerberos, logoff the domain, ngen update and finalize?

 

This might work if no other SSO objects are being layered, however this would be against best practices and how we QA test this. On the technical side the SSO entries in the registry all need to be in one place, the platform layer, so each application changing this key understands there are other applications with SSO functionality. If each one of these apps is layered in a different layer, then they will only see their own registry entry at the time of installation. Whichever layer has the highest priority will override that key from any layer below it. The platform layer will always be the highest priority of any other layer which helps eliminate this issue.

 

Depending on your environment you likely will still need to domain join your platform layer. When doing this please log in as a domain user once. Then reboot and log back in as the local admin and delete domain user's profile from the layer. Then you can finalize it. I am not sure if this is needed for this specific case but if you do need to perform a domain join, please do so using this process and only do so on the platform layer.

[BFCS IT]

7 minutes ago, Richard Buffone said:

 

This might work if no other SSO objects are being layered, however this would be against best practices and how we QA test this. On the technical side the SSO entries in the registry all need to be in one place, the platform layer, so each application changing this key understands there are other applications with SSO functionality. If each one of these apps is layered in a different layer, then they will only see their own registry entry at the time of installation. Whichever layer has the highest priority will override that key from any layer below it. The platform layer will always be the highest priority of any other layer which helps eliminate this issue.

 

Depending on your environment you likely will still need to domain join your platform layer. When doing this please log in as a domain user once. Then reboot and log back in as the local admin and delete domain user's profile from the layer. Then you can finalize it. I am not sure if this is needed for this specific case but if you do need to perform a domain join, please do so using this process and only do so on the platform layer.

 

Makes sense, I've already have my platform layer on the domain. I'll report back once I'm finished installing it here. Thanks for the help. :)

[BFCS IT]

Ok, so interestingly enough, the app is having the same issue in the platform layer. I'm wondering if something changed in Windows 1903. I have further testing to do...

[BFCS IT]

On 11/18/2019 at 11:31 AM, Richard Buffone said:

 

This might work if no other SSO objects are being layered, however this would be against best practices and how we QA test this. On the technical side the SSO entries in the registry all need to be in one place, the platform layer, so each application changing this key understands there are other applications with SSO functionality. If each one of these apps is layered in a different layer, then they will only see their own registry entry at the time of installation. Whichever layer has the highest priority will override that key from any layer below it. The platform layer will always be the highest priority of any other layer which helps eliminate this issue.

 

Depending on your environment you likely will still need to domain join your platform layer. When doing this please log in as a domain user once. Then reboot and log back in as the local admin and delete domain user's profile from the layer. Then you can finalize it. I am not sure if this is needed for this specific case but if you do need to perform a domain join, please do so using this process and only do so on the platform layer.

 

The application had some updates that fixed Kerberos issues on Server 2016+ and Windows 1803+. This is resolved. Thank you for your time and informative information. :)