We have several issues, and resolving them would be very easy if we can get information from the users session request, specifically duration. we have turned off ESA and log off on disconnect due to business use requirements so if a user does not sign out of an RDO session properly the privileged account will become locked after password safe does a post release password reset. in the most recent case the user is getting locked out and we find this through a daily lockout report from our SEIM. the user is notified and claps back that she has not been on the machine in days. in researching we see she accessed this sever and failed to logout properly 7 days earlier. we assume the user requested this session for 7 days, however the user does not remember. we would like to address this but with no solid evidence we cannot do that. any suggestions?
Hello Frank,
You can get the information you are looking for by clicking Password Safe and clicking the Sessions Tab and Completed Sessions.
If you don't see the sessions tab you may need to login to BI using an administrator account.
Regards,
John
As John has indicated, from the Password Safe side the Password Safe > Completed Sessions interface should allow you to see when sessions requests were made as well as when the sessions started and ended, to add those pieces to your puzzle - I think you’re probably on the money, based upon your observations.
If your hypothesis is proved correct, one possible route to help avoid the situation is to define RDP settings which will limit the permitted duration of a disconnected session, or perhaps to refine them if they are already configured. Depending upon how you manage these devices, the best approach to configure this may differ, but the relevant setting is “Set time limit for disconnected sessions”, which if you are configuring via GPO can be found under:
Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Session Time Limits
ok guys you have gone way off track. I need to see what the user requested when the session started. we do not need to change our session time limits or our access policy controls. we need to know the duration that the session was checked out for, and what access policy was used. apparently that was not clear in my original posting. Paul, “ Password Safe > Completed Sessions interface should allow you to see when sessions requests were made as well as when the sessions started and ended,” in my view it does not show anything about the request, duration of request or access policy used. has no one else had this issue?
Hi
Requests and Sessions are visible separately as the two may occur at different times (e.g., I may request access for a future change window), and obviously requests may also be to retrieve credentials rather than start a session. However, the two may occur together, for example if using the ‘Start RDP Session’ option or Direct Connect with an auto-approval policy in place.
The Approvals view, filtered to the “All requests” Status will show all of the access requests which have been made, including those completed - which will have a Response of ‘Checked-In’ if they have been used (i.e., a credential has been checked out, or a managed session started), or ‘Expired’ if the request was never used. You can obviously use the additional filtering in this view to identify the specific requests made by your user to the target system.
Viewing the ‘Request Details’ (via the kebab menu item on the far right of the grid), you can see the requested Start and End times and the duration in the ‘Requested Date’ field, along with any user supplied reason information and the approval history for the request. Note that the Request ID value may not be visible by default in the grid view, but can be toggled on via the field chooser (the three vertical lines between the refresh and cog icons on the right of the screen, in the grid controls).
Noting down the ‘Request ID’ for the relevant request(s) (visible at the top of the ‘Request Details’ panel, or the grid if the column is selected), you can switch to the Sessions section and the ‘Competed Sessions’ tab, and by adding the Request ID filter parameter, you can identify the specific session corresponding to the request - assuming one has been completed.
The grid view should show both the Session Start and Session End times, or by selecting the the ‘Session Details’, again accessed via the kebab menu on the far right of the grid, you can see the duration explicitly.
I hope I’ve got the correct end of the stick this time and not just another adjacent branch!
Paul, thanks, that may fill in some of the blanks however it appears that there is only a few days in this area, that is because the status is either, all requests, pending or approved, there is no selection for expired. nor is there an option for access policy used. is there a report for this.
Paul, thanks, that may fill in some of the blanks however it appears that there is only a few days in this area,
In the Approvals tab, make sure you have the Status as ‘All requests’ and Request Date as ‘All dates’, this should ensure you see all the requests your account is permitted to see. If you don’t see the results you are expecting, as John suggested, you could check what is visible when logged in under the BI Admin account to confirm whether changes might be required to your account’s permissions:
In Sessions section, make sure you are in ‘Completed Sessions’ and the Protocol filter is set correctly:
we can see all the sessions except for the “view”
we are able to get the view sessions from the approvals
the duration can be found when you view the the request detail, under the sessions tab it does not give us the information we need, however i still cannot identify what access policy is used to request the session. I know direct connect as well as quick launch use the default access policy, but users may have other access policies available to them. I would like to know what access policy a user chooses
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.