Working on deploying new thin clients and encountered an issue where a single "bad password" would cause the account to become locked out. That shouldn't occur since the domain is set to lockout after 3 failed attempts.
Background:
Windows 2012 Active Directory
Citrix XenApp 6.5
Citrix Web Interface 5.4 (in this case hitting a services site aka PNAgent)
HP T520 Thin Client with ThinPro 5.1.0 build 07
The Citrix client installed was Receiver / icaclient 13.0.3
Active Directory set to lockout after 3 attempts
Issue:
User attempts to login from the thin client and with even a single mistyped password causes the users account to be locked out and ignores the AD three attempts policy.
Details:
The thin clients are replacing various flavors of thin clients (Wyse C30LE, HP t5530, HP t5540) all running Windows CE 5.0 and 6.0.
My understanding is that these older clients use the old style Program Neighborhood which enumerates the applications via XML. Typically out of the box hitting the dns record "ica" which was normally setup with round robin dns to multiple XenApp / Presentation Servers. This gave a list of possible applications to the end user prior to authentication.
The newer style thin clients based on Citrix receiver are a little different in that they authenticate at the thin client through Web Interface or Storefront and then present the application list to the user.
The problem with the new receiver method is that the user can authenticate, enumerating the apps available, and then walk away. Then another user can walk up, launch the desktop or app they want and they just got access to the wrong user. The old style prevented this because the user would launch the app and then have to authenticate. The auto launch feature that some of these new thin clients helps with this alongside the "logout on last application close" options that many of the good ones are including.
HP took this a step farther and made it so that you could have multiple "connection profiles" in their connection manager! So now we can make receiver profiles for various apps / desktops with their respective auto launch options we want based on the target user. So, user walks up, clicks the familiar app / desktop they want and it prompts for credentials, they enter them and their desktop starts launching. When they are done they logout and it automatically logs them out of the thin client once the app closes. It mimics the old style, no need to train 50 - 65 yr old users how to do it differently! WIN
Problem:
Issue #1
The issue is that when "auto start resource" field is populated in ThinOS 5.x it will attempt to auto start the resource regardless of an authentication failure. This results in 3 consecutive login attempts with the bad password and depending on the domain lockout threshold causes a lockout.
It looks to me based on the thin clients logs that the following is occurring.
- Attempts to use credentials - strike one
- Attempts to auto launch resource even though credentials failed - strike two
- Attempts to auto launch resource a second time! - strike three you're locked ou
Connection starting
2014-12-09 09:12:33.256109510: XEN_WRAPPER: Starting xen_wrapper
2014-12-09 09:12:33.259483293: XEN_WRAPPER: Setting global vars
2014-12-09 09:12:33.390955220: XEN_WRAPPER: --UUID: {23285ceb-40f5-45f2-a09b-022148aa6608}
2014-12-09 09:12:33.394073686: XEN_WRAPPER: --ADDRESS: http://pna/Citrix/PNAgentTest/config.xml
2014-12-09 09:12:33.397168672: XEN_WRAPPER: --AUOSTARTRESOURCE: Desktop
2014-12-09 09:12:33.400411749: XEN_WRAPPER: --FORCE_HTTPS: 0
2014-12-09 09:12:33.403555042: XEN_WRAPPER: Finished setting global vars
2014-12-09 09:12:33.418721583: XEN_WRAPPER: Current XEN_CONN_METHOD: pnagent
2014-12-09 09:12:33.422322255: XEN_WRAPPER: Xen_wrapper_lock started
2014-12-09 09:12:33.433700476: XEN_WRAPPER: Xen_wrapper_lock finished (lock obtained)
2014-12-09 09:12:33.437209663: XEN_WRAPPER: startConnection started
2014-12-09 09:12:33.440670478: XEN_WRAPPER: clearOldData started
2014-12-09 09:12:33.565426467: XEN_WRAPPER: clearOldData ended
2014-12-09 09:12:33.568579181: XEN_WRAPPER: verifyPrereqs started
2014-12-09 09:12:33.584631374: XEN_WRAPPER: Skipping server connectivity check
2014-12-09 09:12:33.588346773: XEN_WRAPPER: Getting credentials
2014-12-09 09:12:33.604419882: XEN_WRAPPER: Attempting to use credentials from SSO manager
2014-12-09 09:12:33.685276288: XEN_WRAPPER: Saving the credentials
2014-12-09 09:12:33.737677029: XEN_WRAPPER: Finished saving credentials
2014-12-09 09:12:33.741336400: XEN_WRAPPER: Finished getting credentials
2014-12-09 09:12:33.747522104: XEN_WRAPPER: verifyPrereqs finished
2014-12-09 09:12:33.750782250: CONFIGURATION: setting up config files
WARNING /etc/templates/xen/appsrv.in/64: Could not find regkey root/ConnectionType/xen/general/type
WARNING /etc/templates/xen/appsrv.in/66: Could not find regkey root/ConnectionType/xen/general/application
WARNING /etc/templates/xen/appsrv.in/69: Could not find regkey root/ConnectionType/xen/general/directory
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.
2014-12-09 09:12:34.200041676: CONFIGURATION: finished setting up config files
2014-12-09 09:12:34.203440412: SETUPUSBR: Setting up USBR
2014-12-09 09:12:34.504068780: SETUPUSBR: Finished setting up USBR
2014-12-09 09:12:34.508365874: CONNECTIVITY: Autolaunchresource started
2014-12-09 09:12:34.568366574: XEN_WRAPPER: Calling: hptc-citrix-connect -g 'CitrixReceiver Linux HP ThinPro' -f /tmp/citrix/{23285ceb-40f5-45f2-a09b-022148aa6608} -c /tmp/{23285ceb-40f5-45f2-a09b-022148aa6608}.credentials '-L' 'Desktop' '-a' 'pnagent' 'http://pna/Citrix/PNAgentTest/config.xml'
/etc/xen/helperscripts//xen_err: line 98: 19959 Terminated nice xmsg -pixmap /usr/share/icons/hptc-icons/48x48/hourglass.png -message "$msg" -caption "$caption" > /dev/null 2>&1
2014-12-09 09:12:36.918657058: XEN_WRAPPER: Processing Citrix connect error output in file /tmp/citrix/{23285ceb-40f5-45f2-a09b-022148aa6608}/error.log
2014-12-09 09:12:36.922922526: XEN_WRAPPER: Error info: Exit Code 2 ERR_CRE_BAD_CREDENTIALS ERR_INFO_URL: http://pna/Citrix/PNAgentTest/launch.aspx ERR_INFO_HTTP_CODE_ERROR: 500 ERR_INFO_DP_ERROR_ID: CharlotteErrorBadCredentials (V1.0.3-26636-19972-C.138-C.351-L.166-M.611)
2014-12-09 09:12:36.929542118: PNAGENT CONNECTION: pnagent launchapp function ended
2014-12-09 09:12:36.933493717: CONNECTIVITY: Failed to autolaunch resource: Desktop
2014-12-09 09:12:36.936785230: CONNECTIVITY: We will try again later after obtaining the full resource list
2014-12-09 09:12:36.940211790: CONNECTIVITY: Autolaunchresource finished
2014-12-09 09:12:36.943772291: CONNECTIVITY: Getresourcelist started
2014-12-09 09:12:36.947373640: PNAGENT CONNECTION: PNAgent list function started
2014-12-09 09:12:36.960696717: XEN_WRAPPER: Calling: hptc-citrix-connect -g 'CitrixReceiver Linux HP ThinPro' -f /tmp/citrix/{23285ceb-40f5-45f2-a09b-022148aa6608} -c /tmp/{23285ceb-40f5-45f2-a09b-022148aa6608}.credentials '-E' '-a' 'pnagent' '-i48x32' 'http://pna/Citrix/PNAgentTest/config.xml'
2014-12-09 09:12:37.140691247: XEN_WRAPPER: Processing Citrix connect error output in file /tmp/citrix/{23285ceb-40f5-45f2-a09b-022148aa6608}/error.log
2014-12-09 09:12:37.144597435: XEN_WRAPPER: Error info: Exit Code 2 ERR_CRE_BAD_CREDENTIALS ERR_INFO_URL: http://pna/Citrix/PNAgentTest/enum.aspx ERR_INFO_HTTP_CODE_ERROR: 500 ERR_INFO_DP_ERROR_ID: CharlotteErrorBadCredentials (V1.0.3-26636-20050-C.138-C.351-E.425-M.607)
2014-12-09 09:12:38.685672448: XEN_WRAPPER: Xen_wrapper_unlock started
2014-12-09 09:12:38.695702911: XEN_WRAPPER: Xen_wrapper_unlock finished
Connection stopped
Issue #2
Regardless of whether "auto start single application" checkbox is marked or not it will attempt to auto start the resource. According to HP support, you should have to populate the "auto start resource" AND check mark the "Auto start single application". In the below image attempting to launch the connection will auto launch Desktop even though the box is not checked.
I see this as a "so what" issue since you can simple blank the resource field to fix.
HP Support:
Working with HP support has been... challenging. This is my typical experience with HP support. In fact, some 4 or 5 years ago we had been deploying HP t5530 / 5540 units and we had a horrid, no good, very bad experience which led us to start buying Wyse C30LE's instead. Currently there is an open ticket and we've finally after much back and forth to sort out what the issue really is have gotten to where we have a call in a few days to talk directly with what they call "3ls" techs regarding the issue.
Update: 12/11/2014
Our call today went extremely well! The 3ls techs looked at the issue and acknowledged that it this is not intended and is not correct functionality. They are reviewing the Receiver launching scripts and debugging. These techs where wonderful to work with.
In addition, it helped that I had just received more of these units in the mail yesterday with ThinPro 5.0.0 build 34 installed (Receiver 13.0.1) and they do NOT have this issue.
So, hopefully we should see a fix for this very soon.
Update: 12/15/2014
I received a potential fix from our tech. After replacing one of the xen scripts it now does 2 login attempts on a failed password. So, closer, but still a little ways to go. I've let the tech know, but have not gotten a response back yet. I'm very impressed with the amount of time it took HP 3ls from our call until getting a potential fix back to me, only 4 days (2 working days)!
Update: 1/27/2015
As much as I wish I could say that my experience with HP support only went uphill since the 12/11 remote meeting I can't. After that meeting the communication with HP Level 1 support was no good, horrible, very bad. In that communication they said that due to the way Citrix enumerates they believed this would be a difficult issue to resolve. They then said that I could work around the issue by enabling Auto reconnect under the Xen Connection General Settings Manager. I enabled the setting there and still no go.
I of course responded regarding the poor communication and slow speed on the issue and copied our reseller stating we would be looking at our "options".
Never have I had such a quick and excellent response to a "nasty gram" that I've sent. Next day we now have a workaround to the issue. 3LS got in touch with me directly and let me just say that working with them (twice now) has been a treat. I just wish I could get straight to them faster / easier as this issue probably would have been resolved within the week. They are the support that I would expect from HP. As for level 1, communication skills are severely lacking. Half the responses I couldn't even translate into something that made sense!
It turns out that the "enable auto reconnect" was actually a pretty close call, but level 1 communicated the incorrect location to enable this setting to me. There are actually 2 locations this is set. The one that resolves the multiple lockout issue is located under each individual connections settings! Just ensure that the following is enabled for each connection "Auto reconnect applications on logon" and bingo, all is well again.
