When we introduce CA PAM infrastructure, what all the possible way to preserve the current user access method and experience. For example if they end use was using putty or other convenient RDP tool, after having CA PAM solution in place, can use still continue to access through the same methods and continue to have the same end-user experience? or will there be a end user experience change ie., they need to be forced to go via a password checkout/checkin process or access only via CA PAM client?
When you have CA PAM infrastructure in place then the end user will have to use PAM client or the browser to access their devices, While doing so they may not feel much difference because PAM offers applet for ssh and rdp, which is very much similar to native application with some security features.
Now as PAM admin one needs to decide weather they need to force user to use only PAM infra to access device or not.
If they requirement is yes then PAM needs to start changing their password doing so user will not have the password to access their device and hence he will be left with no option but to continue using PAM.
@AsifShaikh's answer above is correct. I would just like to add that it is possible to set up CA PAM to allow users to use Putty or similar applications through CA PAM using the "TCP/UDP services" feature. (they would still need to log into CA PAM to get account access though).
Thanks Asif and Lutch.
Your answers are helpful.
@lutch, When you say service, it is like invoking an utility in the local machine and establishing access from there is what I understand. How can this be achieve seamlessly (auto-connect), if you can get some reference on achieving this that will help.
Btw, what I am really trying to understand is, some of the other product on this domain has got a concept of proxy.
There is no change in user access experience, they continue to use whatever 3rd party util they were using to access the devices. (may be only few access parameters get added) and all their access are via proxy and proxy takes care of interactions with the vault and injecting credentials to devices.
Is there any approach of this kind in CA PAM? which can bring in seamless integration of CA PAM controls, with no/very little user access/experience change.
Hello mrcm ,
So the word 'service' may be a little misleading. When you login to CA PAM you will see a page like the screenshot below. This page lists out all of the servers which your account has access to and allows you to select them. The Access Methods column is for our built-in access methods like SSH & RDP which use built-in java applets. Once you have set up your service you would see the services column, which allows you to select your service. Basically from here the end user would just click on the word PuTTY and a PuTTY window would be launched & logged into automatically (depending on your settings). If the user has access to multiple accounts they would instead be given a list of accounts and need to click on the one they want to use.
Once you have selected the server from teh GUI CA PAM does act similarly to a proxy between the end user and the target device (user talks to CA PAM, CA PAM talks to target device, target device & user NEVER talk). Specifically talking about the "TCP/UDP services" there is a loopback tunnel created when you login to PAM where all the traffic for the putty session (as an example, but others work too) would go through.
CA PAM is not really set up for 'seamless' control. For the end user it will feel like an catalog of servers that they have access to and it could replace other applications they may use for keeping their servers in order such as PuTTY Manager or mRemote.
I am not familiar with other similar products and I would suggest contacting sales if you have any more specific questions about differences.
See this can preserve the end user experience to a greater extend, only that they first have to have a session with CA PAM - launch pad.
Do you have any reference around achieving this above said putty scenario.
What I am missing is, CA PAM capability/configuration to inject the device details and credential sets in to the 3rd party tool (like putty), which is invoked as part of the service.
It is a very simple configuration. Basically you choose the local loopback address & port, define the Application protocol as SSH & set the default location where your users will have PuTTY installed. In the Client Application box you would put this (where C:\ is changed to the location where putty is usually going to be located, end users can change their personal path if needed): "C:\putty.exe" -ssh <Local IP> <First Port> -l <username>
This string lets CA PAM know how to call the application on the users workstation & lets the executable know what information to expect (without the -l putty would not know to try logging in). Because CA PAM acts as a proxy for this connection, and this is using SSH protocol; the credentials never reach PuTTY and are instead passed to the remote server automatically using SSH protocol. The end user cannot see the credentials and would actually only see whatever you put after the -l in the command string (see screenshot below).
Here is an example of my PuTTY service:
What user sees when PuTTY starts:
This was helpful. Btw managed to have this configured before with out the '-l' flag and when putty pops will prompt and an entry will use the user part of the policy. -l flag is helpful.
Btw, trying other utility now, like for RDP using mstsc , using
C:\WINDOWS\system32\mstsc.exe /v:<Local IP> /w:3389
Also, wish this work for mobaxterm like utils.
During this process, understand lot of sockets get created and now get below error,
Any idea on how to go about this.
As per my understanding, the loopback can open on one socket at time, so may be the socket is occupying that port from your previous pam session. Only option for now is to kill the session by closing all the pam session and pam client (if open).
updating to CA PAM 3.2.2 will resolve the issue seen.
You can there use random port assignments for the secure channel, e.g. 22:*
(there was also an issue with RDP application which did not support this before 3.2.2)