There may be several causes for this but, fundamentally, when using the mouseclick and keystroke mechanism we are in fact configuring a position in the screen where PAM should be writing the values specified. Since we are not putting a reference to a class, this is purely positional.
This means that if the final screen where we are writing the data to differs from the one we used when doing the initial Transparent Login configuration, the system may be trying to write to the wrong position in the browser. There are at least two situations when this may be occurring
- If the target machine is not configured to hide the taskbar. Under these circumstances, when we do the transparent login configuration the screen positions will be recorded taking into account the positions filled by the taskbar, whereas when we attempt transparent login in production the backend will not show the taskbar, effectively shifting the positions in the screen
- If the screen resolution is different when capturing the transparent login screen positions and when clients use the configuration. If we have, for instance, done the configuration with full screen, the relative positions may be different from the case where the remote screen that users open (for instance 1024x768)
Besides this we need to take into account that starting 2.8, the passwords are not being sent from the PAM server to the Transparent login backend, but instead they are being pulled by the transparent login backend from the PAM server. This means that any miscommunication, for instance, because of a DNS name resolution failure from the transparent login backend to the PAM server, or if a load balancer is configured without session persistence, may result in the transparent login machine not being efficiently communicating with the PAM server and it may not be retrieving the password for writing.