PAM users running Windows 10\MacOS consistently get connection refused errors when trying to launch an RDP session from the PAM Access page. The connection is to local IP 127.0.0.200 and a random port. Other users running Windows 7 don't have this problem. How can we debug this problem?
The PAM client establishes multiple Listener sockets on local IP addresses such as 127.0.0.200 that local applications or built-in access methods like RDP connect to. The PAM client will then forward these connections to the PAM appliance, and the PAM appliance will establish the connection to the target device. When an RDP access method is launched, the connection is like this:
RDP applet <-> PAM client <-> PAM appliance <-> PAM target device
If the problem is observed by selected users only, it is very unlikely to be with the last part, PAM appliance <-> PAM target device.
Given that the user was able to log in to PAM and get to the access page, the problem also is very unlikely to be with the middle part, PAM client <-> PAM appliance, since that has to work for login and for presentation of the access page.
This leaves us with the first connection RDP applet <-> PAM client. For the built-in applets the PAM client listens on random ports on IP address 127.0.0.200, so that the problem most likely is that some sort of local firewall prevents connections to local IPs other than 127.0.0.1. This is a known problem for the MAC OS, which is the reason why the PAM clients includes a MAC assistant (not required in PAM 3.4) that has to run to allow these local connections. Windows traditionally did consider all 127.X IPs as local IPs and did not restrict inter-process communication on these IPs. But more recently we've seen this problem several times, particularly with Windows 10.
PAM client or browser session running on a Windows 10 desktop or MacOS
Other Windows\MacOS releases potentially could have the same problem.
Attached is a java utility that launches a server socket on a specified local IP and port. This requires Java to be installed, which is required anyway for the PAM access methods to work. If you use a browser to logon to PAM, you must have a JRE installed and enabled the Java plugin in the browser. If you use the PAM client, it comes with a JRE that you can use to launch the java utility. Use it as follows:
- Extract the TestServerSocket.class from the server_socket.zip file
- Open a Cmd window and go to the folder that contains the class file
- Launch the utility with this command (change the path to the java executable as needed, and make sure to choose a port that is not in use):
>"C:\Program Files (x86)\Java\jre1.8.0_201\bin\java" -cp . TestServerSocket 127.0.0.200 55555
You should see the following output:
Listening on IP 127.0.0.200 and port 55555
- Launch a telnet client and connect to 127.0.0.200 on port 55555, or whatever port you chose. If you have a PuTTY client installed, you can launch PuTTY, select connection type telnet, and enter IP and port, then connect.
If the connection is allowed, you will see text "Enter any text to stop me >>" on the client, and the utility will show message "Client connected, sending message and waiting for response ...". Once the response is received the utility will exit and the client will report that the connection is lost. This is fine.
If the connection is not allowed, the client will not be able to connect and most likely report a timeout error after a while. You will have to change whatever policy blocks the connection and get the test case to work. Once the local connections work, the PAM client should work as well.
In case if you are getting error "Unsported major.minor version 52.0" error, it is because you are running on different version of Java (such as JRE 1.7.0_xx)
Please refer to https://en.wikipedia.org/wiki/Java_class_file
Java SE 8 = 52, meaning you need to use JRE 1.8.0_xxx
Note: The Java paths provided show a test on a Windows host, but the TestServerSocket class can be run on MacOS or Linux as well.