With this configuration, the administrator can specify the ThinMan Server address.
It is very important to specify the referenced ThinMan in order the device be able to send the ThinMan Server more information about the Thin Client itself (Serial, Subnet, etc.).
Mandatory Configuration for using specific ThinMan Features
This configuration is necessary in order to use the following ThinMan features: Scheduled Activities, Event Activities, ThinMan Profile Manager, ThinMan Login).
More information
Read How to Setup ThinMan Address on Thin Client to find more information about how the ThinMan is contacted.
¶ Connection tab
-
Enable Communication with ThinMan: allows the thin client to communicate with ThinMan.
-
Safe: allows the thin client to establish a WSS Safe connection with ThinMan. For more information, read WSS - EndPoint Security Communication.
-
DHCP Option: the number of DHCP Option to set ThinMan Address. The default value is 163. Read also, How to configure DHCP option 163
-
ThinMan Address: whether the DHCP Option is not configured the thin client will use this address to communicate with ThinMan. The default value is PRAIMSERVER. We highly suggest to configure a DNS Server with PRAIMSERVER hostname
Using a different port on ThinMan Server than the standard 443
The standard port used by ThinMan to receive the thin client connections is the default 443 port (HTTPS) (for more information, read Networking Configuration Requirements). If you change this port using the ThinMan Server Menu you have to provide this information to the devices in the form "ThinManServerNameOrIPAddress:port".E.g. in the screenshot below the ThinMan Address on a ThinOX model is manually configured to use the port 1443.
-
Timeout: timeout used to communicate with ThinMan(expressed in seconds).
-
Listening Port: Is the port used by the device to receive communication from ThinMan. For more information, read ThinMan - Ports for ThinOX11.
Click Test Connection to verify the device and ThinMan can communicate.
Click OK to close the configuration window and save the parameters.
Use DHCP Option 163 or DNS PRAIMSERVER options
Providing the ThinMan Server address via network parameters (DHCP Option 163 or DNS PRAIMSERVER) can be useful to avoid local changes on the device configuration. Also, brand new installed devices will automatically notify to the ThinMan Server.Praim strongly suggests using this practice to provide the ThinMan Server information to the devices in a production environment.
In a test environment, you can use the ThinMan IP Address (or the FQDN name). But, this is not suggested in a production environment.
¶ Authentication tab
¶ ThinMan Authentication Options
It allows defining the options for the ThinMan Login.
-
802.1x / Imprivata OneSign / VPN Agent - Credentials Passthrough: when one of the options is enabled, then the ThinMan Login will use the same credential given on the network login without asking it again. See VPN Configuration, Imprivata OneSign Agent and Port Based Authentication for more information on those clients.
-
Logoff 802.1x at ThinMan Logoff: when enabled the thin client will log off the Port Based Authentication when the user logoff the ThinMan Login.
-
Show last logged user: will pre-compile the ThinMan Login with the last username logged in the thin client.
-
Behaviour if ThinMan not available: select the behavior of the thin client when ThinMan Login is not available at the startup of the thin client or during the user authentication.
¶ Behaviour if ThinMan not available
-
Force Retry: is strictly connected to the timeout parameter in the previous tab. When the thin client tries to contact the ThinMan Server at the thin client startup and this parameter is enabled then the thin client waits and eventually retries the connection during the timeout seconds before accepting that the ThinMan Server does not respond to the request. Be aware there is a ThinMan Server on the network; otherwise, this flag will increase the boot-time of the thin client. This parameters is useful when a thin client has been configured with static IP Address.
-
The other parameters instead are used when the ThinMan is not reachable during the user authentication:
- Use local configuration: Since ThinMan is not reachable, the user credentials cannot be checked; the thin client starts with the local configuration.
- Use last cached profile: in this case, if the user has already logged in the past, the last profile associated to that user is loaded into the thin client configuration.
- Force authentication: in this case, the thin client is locked; the credentials request is shown repeatdly until the ThinMan Server answers.