Remote Authentication

Remote Authentication

Communications

Communications Settings

Compatibility (All XA Client versions)

Note: This communication port does not support QwickACCESS client connectivity.

Note: It is recommended that when configuring client workstations for remote authentication to change the client port (on the end point, not in this server configuration) to 20001 to use the advanced communications. The default ExactAccess client installation will use Compatibility communications (on this port: 20000) which is less secure than using the advanced settings.

Listening Port

Port 20000 is used as the default port for Remote Authentication Server operations. If this port is updated on the server, a corresponding update must be made to the client workstations using this server.

Communications Thread Pool Limit

This protocol allows for selecting the thread cache limit for connections to help improve performance. The default 200 is sufficient for most installations, but can be configured as needed in high load environments, or may be lowered for low load environments. The number specified here means that the server will (pre)allocate this number of threads in the server process to handle incoming requests.

Warning: When using this protocol and port configuration, the following settings must also be configured to exactly match the client workstation.

Compression Class

This may be either NONE or VCLZIP

Encryption Class

This may be either RIJNDAEL (which is AES 192 bit) or Blowfish. Older client versions support only these options.

Preshared Key

This is the encryption key that will be used to encrypt the data for client/server communications. It must be configured on the endpoint.

Advanced (XA client version 4.8.3 and above)

Note: This communication port supports ExactAccess and QwickACCESS client connectivity.

Listening Port

Port 20001 is used as the port for Remote Authentication Server operations when QwickACCESS clients are deployed. If this port is updated on the server, a corresponding update must be made to the client workstations using this server. This communication protocol supports the Unicode character set for directory service names.

Communications Thread Pool Limit

This protocol allows for selecting the thread cache limit for connections to help improve performance. The default 200 is sufficient for most installations, but can be configured as needed in high load environments, or can be lowered for low load environments. The number specified here means that the server will (pre)allocate this number of threads in the server process to handle incoming requests.

Local Server Management Port

This is the port bound to only the local address (127.0.0.1 or ::1) that the ExactAccess Server Monitor tool will use to query the server status of the service.

Connection Hash Class

The available options are MD5 and WHIRLPOOL.

MD5 is a lightweight hash algorithm that generates 128-bit hashes but is only recommended if the client workstations connecting to the system are slow (less than 2GHz).

WHIRLPOOL is a hash algorithm that generates 512-bit hashes. The larger number of bits means it is more secure, but it also requires slightly more CPU cycles to generate. WHIRLPOOL is the recommended choice if your workstations are 2GHz or better.

Warning; Not all HealthCast products support the Whirlpool hash algorithm. Ensure that the client product you are deploying supports the feature configuration for the server.

Database

Database Settings

There are no database settings for Remote Authentication.

Other

Access Settings

Secured File Location

In order for Remote Authentication to function, you must configure the secured file location using Windows File Security

The secured file location is the full path and file name to the HasAccess.txt text file where security permissions are defined for users. Any user that is denied access to read this file will be denied access to log into ExactAccess Kiosk Mode. If desired, apply the domain user's full permissions to this file using standard Windows security procedures. Then add users or groups that should never be allowed to remote authenticate and set the deny permissions on this file.

Note: This allows restrictions to be placed such that only certain users may authenticate via the Remote Authentication service. This is useful in situations such as when not all users (e.g. domain users) have access to a TS/RDS/Citrix server, and you want to limit connecting to the remote machine by requiring a remote authentication first - thus preventing unauthorized users from even attempting the connection to the TS/RDS/Citrix server.

A best practice is to create an Active Directory security group that includes non-specific AD user accounts such as service and generic accounts. This group is then given explicit deny permissions to network resources including "HasAccess.txt". This prevents unauthorized anonymous access to network resources and prevents users from associating their badge with an account not explicitly provided to them. Ensure that a group with the authorized users has been given READ permission to this folder/file. Domain Users group can be used along with the specific group for DENY permissions. The security with the most restrictive permissions will be used in the case the user exists with both READ and DENY permissions, meaning the user account will be denied access.

Enable fine-grained password

When using Windows 2012 and above, it is possible for different users in different organizational units to have different password expiration policies. If your domain has been configured with this feature in Active Directory, and you want ExactAccess to prompt users at their correct expiration times, ensure this check box is checked.

Local Security Policies

To complete configuration, the following Local Security Policies must be applied:

Here is a list of some of the benefits, limitations, and security concerns around Local and Remote authentications.

Note: Domain Users (or the restricted set of users allowed to perform remote authentication) must be added to "Log on as Batch Job"

• Start the Local Security Policy application (click Start, Run and open secpol.msc).
• In the left-hand pane, select Security Settings > Local Policies > User Rights Assignment.
• In the right-hand pane, right-click Log on as a batch job and select Properties.
• Click Add User or Group... and enter the group, such as Domain Users, that will log onto the remote session through a HealthCast client product. Click OK.
• Deny rules may also be added at this time. These users/groups can also be denied access to the file using file permissions rather than log-on permissions as indicated above.
  • In the left-hand pane, select Security Settings > Local Policies > User Rights Assignment.
  • In the right-hand pane, right-click Deny Log on as a batch job and select Properties.
  • Click Add User or Group... and enter the group, which will be DENIED log-on rights. Click OK.
  • It may also be necessary to add the SERVICE ACCOUNT in the Act as part of the Operating System and Impersonate a client after authentication policies.
• In the right-hand pane, right-click Impersonate a client after authentication and select Properties.
• Click Add User or Group... and enter the domain account that the service is running as in the “Enter the object names to select” box. Click OK.
• In the right-hand pane, right-click Act as part of the operating system and select Properties.
• Click Add User or Group... and enter the domain account that the service is running as in the “Enter the object names to select” box. Click OK.