This would allow us to use that one size fits all trick but selectively execute if the user was internal or external. The next thing we tried is using EUM to write a special environment variable called EXTERNAL that we could then test against in a batch file kicked off by the normal scheduled task workaround. It would probably satisfy the security concerns but not help with the resource freeing. ha! But of course, this was after all of the time being idle. Then it locked and disconnected immediately. We tried using this but it seems as though once the GPO for locked screen saver kicked in after an idle period, the session doesn’t ACTUALLY lock until the user goes to move the mouse on the screensaver. The closest thing we found was a Workstation Locked trigger. This UEM setting is the condition we want to use but unfortunately, there aren’t any idle timeout triggers. We wanted to disconnect the session if it was external and the user had eclipsed the idle time but if the user was internal, we would do nothing. They wanted to leverage UEM’s ability to recognize and target external/internal connections to do different things. This is fine for a one size fits all solution I guess but this week, my client wanted more. This task would be triggered on a user idle period and then trigger an action to disconnect using the TSDISCON.EXE command. The closest ‘solution’ I can find on the internet is some hacky setup using a Scheduled Task in the golden images. Seems like a pretty useful thing for a VDI solution.įor whatever reason, there is absolutely no timeout settings in the Horizon infrastructure or UEM (User Environment Manager). This frees up the connections, makes for a happy security team and dumps the resources back into the pool to be made available for non idle workers. Have the system check to sure that if a user is idle for a certain amount of time, it disconnects them, waits some more time and then logs off the session. For day to day usage with a RADIUS solution that's validated and working, this message is specific enough to get by.I’ve done quite a few VMware Horizon installations and almost every time, no matter what version I am installing, I end the engagement wondering How did VMware yet again forget to include an idle timeout setting in their Horizon solution? Anyone who has worked with Citrix knows this is a pretty common and useful setting. But for someone in the midst of troubleshooting an integration it's vague and can lead to confusion. Making matters worse, while further info can be gleaned from the debug logs on your Horizon server, there are still blind spots from the perspective of a VDI admin. When a Horizon Connection server, acting as a RADIUS client, has a RADIUS request rejected it's not necessarily entitled to any explanation from the RADIUS server why the request was rejected. Sometimes all that's received from the RADIUS server is a terse Access-Reject packet, with no specifics on why the rejection occurred. This can cause things to get dicey in the context of a RADIUS integration, particularly because VDI admins don't necessarily have access to the RADIUS server or its logs. Leveraging utilities to verify RADIUS connectivityĪn Access-Accept is sent when authentication has fully completed and the user is granted access.Using network captures from Wireshark and Tcpdump.After providing a brief overview of how RADIUS authentication works, I'm going to detail the following strategies: This post will detail a few strategies for troubleshooting RADIUS integrations with Horizon. The Access-Accept packet includes a list of parameters, in the form of attribute-value pairs, that are required for access to the service.Īn Access-Reject is issued when you're request for access is rejected. Your username or password might be wrong or you're just not authorized. Leveraging Utilities To Verify RADIUS Connectivity Using Network Captures From Wireshark And Tcpdump Whatever the reason, you get nothing but the terse rejection of an Access-Reject, often without the courtesy of any explanation why.Īn Access-Challenge is issued if the RADIUS server requires another piece of information, like a secondary password, PIN, token, or card.Ĭisco offers an excellent primer on RADIUS titled, "How Does RADIUS Work." Here's a link: Also, if you're looking for some really exciting Friday night reading, here's a description of the standard by the Internet Engineering Task Force: #Vmware horizon client timeout error password I ran across several utilities that can make RADIUS requests as a client against a RADIUS server for testing purposes.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |