Hi,
I am building a demo environment using a windows 2016 server with RDP access via a Web HTML5 portal, always using the same windows username/password credentials at the URL, but obscured by link cloaking. The purpose is to let users access an account protected
website, via the Chrome browser installed in that server, where software packages can be demoed in real time but cannot be purchased. Users cannot have the website password ( because that will allow them to access the same website from their own computer,
which cannot be allowed). So, it is as if the windows 2016 server is used as a client to access a website, this setup was initially thought to be used concurrently by some 10-20 people. I have edited Group Policy accordingly to allow multiple connections,
time limit connections , logoff for disconnected sessions and took other Security measures to mitigate attacks and etc. Once users have logged via HTML5 RDP Portal, they get a tdp-rdp Session ID and can access the website, which has a JWT token stateful authorization
strategy. Under normal conditions, from any user direct access to this website using his/her own computer, the JWT token would be loaded in the user computer upon the first access and later access would be validated by the JWT token loaded and by concurrently
accessing the website domain page, and during the JWT token time-to-live (15 days), entering with website account username/password again is NOT required. My problem with moving this arrangement to the demo server is that, Session IDs are unpredictable!
I realized that whenever I get again a RDP Session ID where the web site credentials have been already been provided, I am logged directly to the website, but when a new session ID is used by the server, I have the target website Login screen asking for username/password
credentials. In other words, the JWT token seems to be "trapped" inside the RDP Session ID. Second problem is that, under tests, RDP Session IDs being unpredictable, they cannot be restricted to a certain number of Sessions like
1 to 5 to match 5 RDP allocated ports. Session IDs start to spiral towards Session 10,11,12,13 etc unpredictably ... I have read in many posts here the RDP Session ID algo has never been published so the pattern is completely unknown, sometimes it reverts
back to lower Session IDs like 2 or 3 and works as expected (described above), and sometimes it continues to move upwards numerically and with that behavior, Users will be faced with the website login page, instead of falling directly at the validated demo
content inside the website account area. I activated "Do not use temporary folders per session" Group Policy rule to enable the following = "If you enable this policy setting, per-session temporary folders are
not created. Instead, a user's temporary files for all sessions on the remote computer are stored in a common Temp folder under the user's profile folder on the remote computer.", but this had no effect on the problem. I expected that would create
a common pool for the JWT token at the server, and address the problem, but all remained the same.
Hence, I either need a way to contain RDP Session IDs in a certain range ( 1 to 5) which seems to be impossible, or a way to allow JWT token loaded by a kick start access using webste account username/password to be seen by the following RDP sessions and
do not require username/password after the first username/password 'kickout" access. Note that all RDP HTLM5 Portal sessions to the windows 2016 server use the same Windows Username/password, so I was expecting that to work as it does over the Web/HTTP,but for some reason the JWT token appears to get trapped inside the RDP Session ID.
Apologies if my explanation was not technical enough but this is not exactly my core expertise. All comments are Welcome!
Many Thank indeed!