I'm trying to publish IE9 on Win2008R2x64 with XenApp6.5 and have it work with some websites that will leverage IWA (Integrated Windows Authentication). I have GPOs configured to work using Loopback Processing and the IE settings GOP does work correctly for all of my users on their desktops, as well as our XenApp5 (Windows 2008 32-bit) servers.
The problem is that IWA (for Sharepoint 2007 and a SAML 2.0 website) doesn't seem to work correctly with XenApp 6.5 ICA sessions only. I can manually login with no problem, but it should be able to pull my logged in credentials.
I can launch a RDP session to the same server using the same credentials and open up IE and it will work perfectly. I've even tried publishing an ICA server desktop to the specific server and it reacts the same way as the IE published application. And, as I said earlier, it does work fine for published desktops and IE published applications in a XenApp5/Win2008(32-bit) ICA session using the same GPOs and credentials.
Essentially, in all XenApp 6.5 ICA sessions, the IE browser does not allow for Integrated Windows Authentication to use the logged in users credentials to open up webpages.
Doesn't make sense to me. Any help?
Thanks,Chris
Hi Chris
I think I have a similar problem with IE through n ICA session. I've published IE and then pass the website as an argument. This website requires the user to enter their credentials to access the application. If they enter the correct credentials the website just reprompts for credentials. If they enter incorrect details then the website displays an error page as expected. I tried this on another XenApp 6.5 Windows 2008R2 and had the same issue. If the user logs onto the server by RDP it works fine the next time they logon through ICA.
But it works fine if I publish Firefox instead of IE.
Ive posted my problem under the XenApp forums.
Ian
I probably should have posted my solution. It actually came down to an issue with the Computer Object for the Xen Server in AD.
Somehow the object had the "Trust this computer for delegation to any service (Kerberos Only)" checked. I don't recall doing it, but since I'm really the only administrator that would have messed with this object, I must have done it... When I changed it to "Do not trust this computer for delegation" things started working properly.
I have no idea why this works through. To me, it seems slightly counter-intuitive, like I'm turning off Kerberos authentication, but at this point, it's working and I'm not messing with it. =)
Your problem sound very similar, if not identical, to mine. I would start with checking your AD objects for this setting under the Delegations tab. If you do find out more about how/why this setting is applied, I'd love to hear about it.
Hi Chris,
Thanks for your response.
Unfortunately my servers were already set to "Do not trust this computer for delegation".
We've resolved the problem (thanks to my collegue) by changing a settings within the GROUP POLICY, for some reason ICA connection seemed to have unticked "Automatically detect intranet network" within Internet Options > Security > Local Intranet > Sites. Once I modified the GROUP POLICY to tick Automatically detect intranet Network and Include all network paths (UNCs).
This did resolve the issue.