Terminal Server: - Windows 2008 x64 Server Standard - Kerberos token size set to maximum - Citrix XenApp 5.0 Issue: When we log into our XenApp Servers using single sign-on (SSO) through the Citrix Web Interface, authentication within the session behaves differently than when the server is logged into explicitely. If we log into a server explicitely, everything behaves as expected. However, when we log into the server using SSO, we are unable to map drives to non-kerberos-enabled file shares without being prompted to enter our domain credentials. In addition, Integrated Windows Authentication within Internet Explorer does not appear to be functioning on all of our internal websites when we logon to the server using SSO (we either get prompted to authenticate to the proxy server even though the site is defined in the proxy bypass rules, or the URL prompts for authentication). Neither of these issues occur when we login to the server explicitely.
Hi David, did you mange to fix this? Have spent 3 days fighting with same problem, no joy so far
I still have a case open with Citrix but have since implemented a workaround so I haven't spent a great deal of time doing any additional troubleshooting. The problem lies with using kerberos authentication to the XenApp servers. As a workaround, we use kerberos to authenticate to the Web Interface. However, we still use NTLM to authenticate to the XenApp servers (SSO still functions).
I've spoken to multiple consultants and technicians regarding this issue and am pretty sure the ultimate conclusion from Citrix will be that kerberos (trusted for delegation) is required on all systems that the XenApp server will communicate with. In other words, your entire enterprise has to support kerberos authentication if you intend on authenticating to your XenApp servers via kerberos.
When you authenticate to the XenApp server using kerberos (via ICA), it doesn't generate any NTLM credentials for you (although an RDP connection does). That is why you get prompted to authenticate to non-kerberos resources. A crummy workaround is to lock/unlock your session. The act of typing in your username and password to unlock the session generates NTLM credentials.
This is not a Web Interface issue. It can easily be reproduced using the Program Neighborhood by manipulating the INI files to toggle kerberos off/on. It can be reproduced on all versions of the ICA client that support kerberos authentication. This is not a new issue. It has existed from day one. Citrix simply doesn't acknowledge this as an issue as they will tell you their requirement is that every server (including non-XenApp servers) be "trusted for delegation" (in other words, kerberos-enabled).
Thanks David, we've Kerberos (trusted for delegation) enable on all the relevent systems, in our case it did turn out to be a web authentication issue resulting from cloning our XenApp servers.
Only figured this out late on the 23rd December and have been out the office since so haven;t had a chance to post it.
One of the apps on our XenApp servers is Visual Studio 2008, which some of our students (we're an further education college) use for developing asp.net web sites as part of their A-Level, HND or Foundation Degree projects. As a consequence we had to install on IIS on the servers and therefore when we installed XenApp we went for the share a port with IIS option for the XML service.
When you share a port with IIS some of the required data for the XenApp XML service ends up in IIS web.config files, (usernames/passwords etc..) these entries in the config files get encrypted with the servers IIS machine encryption key. In theory this shouldn't have been a problem, but the MS sysprep utility removes these keys and generates new ones, as a result the cloned servers couldn't access the encrypted sections of the config files as they no longer had access to the private key corresponding to the public key that was used to encrypt the data.
There wasn't anyting showing up any of the logs pointing towards this as the problem, only discovered it when i tried to access the XML service URL via Internet Explorer, just to see what came up, and got the IIS/asp.net error page that told me exactly what the problem was.
We got round this by going back to the drawing board bulding a new template/master server and not shairng the port for the XML Service with IIS - once we did this everything worked great.
Thanks you for the post. Hi guys, Im a newbie. Nice to join this forum.
Watch Free Movies Online