This is one of the common issues reported by multiple customers in XenApp environment using Kerberos. As such, Account Lockout is itself a big nightmare for any System admin, there are couple of excellent articles on Microsoft site around this topic on how to troubleshoot, what tools are require, etc (e.g. http://technet.microsoft.com/en-us/library/cc773155%28v=ws.10%29.aspx) . However, from Citrix side, especially XenApp side, things are bit different, depends how environment is configured. Users facing Account Lockout issue for ICA session to XenApp servers configured to use Constrained or Unconstrained Kerberos delegation, can use below tips to isolate the issue. Citrix Kerberos can be enabled for Pass-through (w/ or w/o smartcard) authentication method.
When Citrix Kerberos is enabled, the login to a session is based on Kerberos ticket. XenApp servers needs to be ‘Trusted for delegation’, same is true if Authentication point is not ‘At Web Interface’. Check http://technet.microsoft.com/en-us/library/cc995228.aspx for information on how Kerberos Constrained Delegation. The one important aspect of this is that there is no way to failback to NTLM as we don’t have access to credentials. Most of the time, if there is any issue related to Account lockout in Citrix Kerberos environment than is the reason. The best way to troubleshoot the issue is to identify the backend and isolate it.
Tools that can be used – Network Trace – Start Network trace on target XenApp server, either through console or rdp. Trace the session launch, once you reproduce the issue save the trace and open it.
Handy WireShark Filter for looking at Kerberos ticket requests/responses
kerberos.msg.type == 12 || kerberos.msg.type == 13 || kerberos.msg.type == 30 || kerberos.msg.type == 10 || kerberos.msg.type == 11
(Above is just an example)
Things to look into the trace– 1. Check for Krb_Error_ messages and 2. ntlmssp messages (ntlmssp_challenge, etc).
In both cases, check which server\service is in picture and try to eliminate it from environment. Other things to try is a new test user without and profile, just to check if issue is happening because of something mapping in logon script. Once you identified the server\service check if it can understand Kerberos ticket or not, some server\service needs manual configuration changes to enable Kerberos and in some cases may be backend is not compatible or doesn’t understand Kerberos. If that’s the case, then we need to involve 3rd-party vendor.
Things to try– Hotfix Rollup Pack 1 has a fix around this –
- When running a published instance of Internet Explorer using Program Neighbourhood Agent or the online plug-in, the following error message can appear: “The page cannot be displayed.” As a result, users can be incorrectly locked out of their accounts when launching applications or accessing other resources in a Kerberos environment. To address the issue, Fix #184053 was introduced to skip NTLM authentication by setting the following registry key:Key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxSSP\NTLM
Data: 0 (use the previous authentication handling); 1 (use the new handling)
However, this resolution might not be satisfactory for customers who want users to authenticate using NTLM, especially for Web browsers. This fix adds a bit to the registry value as follows:
Data: 0 (use the previous authentication handling); 1 (skip NTLM authentication); 10 (skip NTLM authentication for all but Web browser processes)
Other Tools– There are some good tools from MS side to understand and check Kerberos ticket on a machine like: –
1. Kerbtray – GUI based tool to check Kerberos ticket
2. Klist – command-line tool for same purpose but you can purge ticket also.
3. A/c lockout tools – Netlogon Parser, LockoutStatus, etc
Most of the time with above steps and tools, we are able to address 90% of issues in Escalation related to Account Lockout in Citrix Kerberos environment.