Symantec Privileged Access Management

  • 1.  Tech Tip:  Something to Check When Autoconnect Doesn't Work to a Windows Server

    Posted May 09, 2018 01:34 PM

    A customer recently opened a ticket because there was a problem getting autoconnect to work.  It turned out that there was a GPO that was requiring the credentials to be entered a second time.  This broke autoconnect.  Please keep this in mind if you run into a problem with autoconnect.



  • 2.  Re: Tech Tip:  Something to Check When Autoconnect Doesn't Work to a Windows Server

    Posted Oct 28, 2018 02:26 PM

    BTW What was the GPO? can you share the setting details.



  • 3.  Re: Tech Tip:  Something to Check When Autoconnect Doesn't Work to a Windows Server

    Posted Dec 05, 2018 11:06 AM

    I'm sorry.  I was not given the details of the GPO.  I was just told that it was corrected on the Windows server, and autoconnect worked afterwards.



  • 4.  Re: Tech Tip:  Something to Check When Autoconnect Doesn't Work to a Windows Server

    Broadcom Employee
    Posted Dec 06, 2018 12:26 PM

    I've seen something similar at another client - the PAM RDP applet launches, connects to the target device, but it stops at the windows logon screen (wants the user to input user-name and password) -- not sure if this is the behavior you are referring to - can you please clarify / provide screenshots of the behavior you're seeing?

     

    I've been investigating this in my windows 2016 / PAM 3.2.2 lab and enabling / disabling the "Always Prompt for Password upon connections" GPO:

     

    Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security

     

    However, i cannot recreate the same behavior seen at the client. The GPO doesn't seem to affect PAM's RDP applet, only the native windows RDP (MSTSC.exe) tool.

     

    When the policy is enabled, running MSTSC outside of PAM and connecting to the target device produces a Re-Auth prompt requiring the user to enter the password even though the credentials might be accurately stored in the RDP profile and 'Re-Authentication' was not forced prior to enabling the GPO.

     

    However, I do not see this behavior with the PAM 3.2.2 RDP Applet whilst remoting into a windows 2016 target - in this case there's no re-auth forced and the user is auto-logged-on to the target - (I haven't tested 2008 / 2012)

     

    WRT launching MSTSC from PAM (as a service) - i don't actually know if we can do auto-logon with vaulted credentials with mstsc as a service in PAM.

     

    Addendum 1/3/2019:

    There is a registry setting that overrides the GPO behavior:

    Reg Key:         HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-TCP\

    Value Name:   fInheritAutoLogon

    Value Data:     0 /1

     

    This registry setting controls the 'RDP-Tcp Connection Settings' shown in the below image. When set to 0, it is equivalent to the option 'Always use the following log on information" (in image below) being selected. The effect of this configuration is that the Client-Side credentials (ie those supplied by PAM or user via MSTSC) are ignored and the credentials specified in the Log on Settings tab of the RDP-Tcp connection settings are used. If this option is selected and the credential fields are blank in the Log on Settings tab, then you see the behavior described above, where the PAM RDP Applet launches but it doesn't auto-connect, the windows logon screen is displayed and the user is prompted for credentials.

     

    To configure the RDS Session Host to use the client-provided credentials, ie to use the credentials from PAM, set this registry value to 1 (equivalent to the RDP-Tcp connection option 'Use Client Provided Log on information');

     

    The change takes effect immediately, no restarts of any kind required.

     

    Here are a few other references that further discuss this matter:

    MS Technet Forum Post

    MS Technet wiki article

    MSDN Article

    Spiceworks Community Post



  • 5.  Re: Tech Tip:  Something to Check When Autoconnect Doesn't Work to a Windows Server

    Broadcom Employee
    Posted Jan 03, 2019 04:54 PM

    See Addendum 1/3/2019 above