HealthCast

Prox Card Server
Communications
7703720.png
Communications Settings
Compatibility (All XA Client versions)

Info

This communication port does not support QwickACCESS client connectivity.

Listening Port

Port 30000 is used as the default port for ProxCard 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.

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.

Advanced (XA client versions 4.8.3 and above)

Info

This communication port supports ExactAccess and QwickACCESS client connectivity.

Listening Port

Port 30001 is used as the port for ProxCard 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 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.

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 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
11960898.png
11960899.png
Database Settings
Database Class

The only available database provider for this version of ExactAccess server services is FireDAC. It provides connectivity to Microsoft SQL Server using Microsoft Native Drivers or Microsoft SQL ODBC drivers.

Connection Timeout

This indicates how long the drivers will wait for a successful connection to a SQL server. If this ExactAccess installation will be using service database fail-over connection strings (multiple database connection strings are configured for the service), this number should be set as low as possible to improve fail-over responsiveness to secondary connections. For high availability configurations (SQL clustering, Active Group Listener configurations), this number should be set high enough for the drivers to allow clustering fail-over logic to promote a SQL server to the active state when the primary server has failed and not immediately return a connection failure to the service.

Command Timeout

This indicates how long any single transaction made by the service can take to complete. For highly stressed SQL servers, this number should be configured to allow for the appropriate workload to be completed even if the server is at maximum capacity. If there is excess capacity on the server, all service operations are expected to take less than 10 seconds to complete for normal operations.

Database Encryption Class

For those server services that support updated database encryption, choose an encryption method to use to protect the data. During upgrades, choose the LEGACY or PROX_LEGACY option. After upgrade has been completed for all servers, choose a method other than LEGACY or PROX_LEGACY. AES192 is recommended, but any of the other options are valid. Consult your security officer for recommendations for your organization.

Important

During an upgrade scenario, the first server to be upgraded should be considered the "master" server. From this server, click the EXPORT button to save the auto-generated database encryption keys for each of the services (SSO and Prox) and save them to separate files (ProxDBKeys.key and XADBKeys.key) - provide a password to protect these files when prompted. It is a good idea to have more than one person export these keys, and keep them in a secure offsite location for disaster recovery.

Once these keys have been exported, they will need to be imported on each of the servers during the upgrade.

To import the keys to an existing server, Open the configuration tool, select Database, then choose the appropriate TAB (Prox or SSO/ExactAccess). Click the IMPORT button. Locate the correct file (ProxDBKeys.key for ProxCard, XADBKeys.key for SSO/ExactAccess keys) and click OK to open the file. Provide the password used to secure the exported keys. A message will indicate the success or failure of the import. Repeat this step for each server to be upgraded.

Servers

This lists the currently configured connection string for each configured SQL server in the organization. The ExactAccess server services support as many fail-over connection strings as desired. The first connection string entered in this list will be considered the primary server. The remaining servers listed will not be utilized unless the primary server Connection Timeout is reached and the server is deemed off-line. In primary server fail conditions, each of the servers will be attempted in the order in which they are entered in this list until a connection is made or all servers have been attempted and an error is returned to the client

Adding a new connection

Click the plus (7703609.png) button to bring up the Data Link Properties (FireDAC) window

7703382.png
Connections
Select a driver

Microsoft provides several connectivity drivers for SQL server. You may choose SQL server as the driver (which is available by default on Windows 2012 R2 and above) - or optionally, install one of the later Microsoft SQL Server Native Drivers which will provide other connectivity options (such as ODBC)

Info

it may be necessary to install the Native SQL drivers. This is typically only necessary for Windows 2008 R2, but newer SQL drivers may also improve performance. See the note below on downloading an appropriate driver.

Driver Download

Check with the Microsoft Site for newer or additional drivers for supporting the latest versions of SQL server.

4980921.pngODBC Drivers for SQL Server

Select a server (by using the browsing service) or manually enter a SQL server database name and instance.

If this SQL server is part of the High Availability Group configuration (available in SQL server 2012 and above), check the box for Server is Availability Group Listener. This will notify the Microsoft Driver to expect multiple IP addresses from multiple SQL servers configured in this group/cluster so that the driver can provide appropriate fail-over if the primary node fails.

Authentication Type

If the service has been configured to run under a service account, that service account must have been granted DB Owner permissions for the service database (SSO, Prox, Deploy, Audit) when choosing to use Windows NT Integrated Security. In this case, a password does not need to be supplied in this configuration, as the security credentials are configured on the service using MMC services management tools provided by Windows.

Warning

When choosing to use Windows NT Integrated security during configuration, please note that the user account to launch the tool MUST match the account that is to be used for authentication to ensure the proper permissions and connectivity tests can be completed. The tool also requires UAC elevation, so this user must also be a local administrator on the server for configuration to be completed.

If you choose to use SQL server authentication, then pick the "Use a specific user name and password" that has been configured in SQL server as the DB owner of the service database (SSO, Prox, Deploy, Audit). This username and password will become part of the connection string and will be stored encrypted in the registry.

Enter a database name

Manually type if the name for the database associated with this service, or click the drop down to show a list of available databases to connect to.

Warning

If the current user (that the tool is running under) does not have access to the SQL server, the browse function will fail, as the tool is unable to connect to the SQL server with the current user. This is only applicable when using Windows NT Integrated Security.

When using SQL server authentication by supplying a user name and password, the browse feature for the database will only fail if the user has not been granted access to any databases, or the account information is not valid.

Other
11960924.png
Password Expiration Options
Always save passwords

If you have PIN login enabled, then the users password must always be available in the server to allow a user to log in using a badge tap and PIN prompt authentication without having to enter a password.

Never save passwords

This option forces users to always enter a password after tapping a card. It is similar to a Card+PIN workflow, but more secure as the password is also validated against active directory, and can be enforced to have a certain character requirement such as must contain an uppercase, lowercase or numeric letter with a certain minimum length.

Expire passwords for inactive cards

This option indicates how often in minutes a users password will be deleted if the card has been used recently. This is the most secure option, as the encrypted password is physically removed from the database if the user has not tapped a card within the interval specified here. The lower this time can be set, the more secure the users passwords will be. This corresponds to the time the user may tap-out of one workstation and move to another workstation and not have to enter a password to log in.

License Count Automated Management Options

These features are intended to automate the process of removing prox card enrollments for users that are not active. There are 3 ways a user can be considered inactive.

  1. The user enrollment is a temporary thing only intended to be active for a short amount of time (1 hr minimum) or up to a month.

  2. The user is an AD account that is created and used while the user is employed at the organization and deleted when the user leaves employment.

  3. The user is an AD account that is created and used while the user is employed at the organization and disabled when the user leaves employment, but may some day return to be re-activated.

This server handles Temporary Badge Schedule

Temporary Badge schedules are intended for handling high turnover situations where a set number of cards will be frequently changing enrollment from one user to another. These schedules allow the badges to be unregistered (deleted) over shifts (Daily schedule by hour, weekly, or monthly) so that they may be re-enrolled with a different user name. Normally, once a card is enrolled to a user, it may not be enrolled with a different user name, even if a new name is supplied after taping an unauthenticated card on the client. Temporary badge schedules also overcome this limitation.

Tip

At least one server must be configured to handle temporary badge schedules for the feature to function. Prox card enrollments are physically deleted from the database by the server(s) that have this setting enabled. If no server has this setting enabled, temporary badge schedules are disabled.

Link accounts with Active Directory

The Proxcard server may synchronize active directory accounts so that if a user is renamed in AD, the badge enrollment can be automatically updated to use the currently enrolled users updated name. If this setting is not enabled, the user must call the help desk and have their badge manually deleted using the ProxCard Administrator so that they can re-enroll with their correct name.

Tip

At least one server must be configured to be linked to Active Directory for name change synchronization to function. If no server has this setting enabled, then name changes are not synchronized with Active Directory. Users that have a name change must be manually deleted to allow for re-enrolling their card.

Delete Prox Enrollments for Missing AD Accounts.

If the server has the Link accounts with AD feature enabled, the server can also remove prox card enrollments for user accounts that have been deleted from active directory. This automates the removal of accounts that are no longer valid for sign-on at the organization.

Info

This feature is only helpful when a limited number of ProxCard user license have been purchased. Enterprise licenses do not enforce user enrollment restrictions and will not reject a user enrollment.

Delete Prox Enrollments for Disabled AD Accounts.

If the server has the Link accounts with AD feature enabled, the server can also remove prox card enrollments for user accounts that are present, but have been disabled in active directory. This automates the removal of accounts that are no longer valid for sign-on at the organization.

Info

This feature is only helpful when a limited number of ProxCard user license have been purchased. Enterprise licenses do not enforce user enrollment restrictions and will not reject a user enrollment.

Black listing domain groups to prevent enrollment

To prevent users from being able to enroll credentials to a card for sensitive accounts, add a group to the Blacklisted Groups section of the configuration tool.

Click the plus (7703609.png) button and enter the domain/group name of the group of users to be prevented from enrolling. To remove a previously defined group, select it in the list and click the delete (11960928.png) button.

Access Control for ProxCard Administration

To enable limited access control for the ProxCard Administrative tool, the associated ProxCardAdmin_server.xml must be registered with ExactAccess.

Registering the ProxCard Administrator Control Item

Import the registration file c:\program files (x86)\HealthCast\ExactAccess\ProxCardAdmin_server.xml using the XA Administrator. See Application Registration for importing the XML file.

After the file has been registered, ensure that the control item "ExactAccess ProxCard Administrator" has been added to the Organization Map. Also, ensure that the sub-items registered with the application have been added under the ExactAccess ProxCard Administrator. Then, drag and drop the appropriate roles onto the ExactAccess ProxCard Administrator control item for all Administrative users. Drag and Drop Help Desk users onto the appropriate sub-items: Allow Delete, Allow Enrollment, Allow Search, and Modify Temporary Schedules.

Supporting Temporary Badge view

The ProxCard database must be updated with the Update4111.sql script to allow the administrative tool to query the schedules associated with a badge.

Updating the ProxCard database
  • Using SQL Server Management Studio (or a similar tool), connect to the database server on which you wish to upgrade the Prox database.

    This upgrade will need to be completed on each SQL instance that hosts a Prox database.

  • Connect to the existing database on the database server (ensure any scripts will be executed against this existing database)

  • Use SQL Server Management Studio to open the file called Update4111.sql and execute the update against the Prox database.

    Located in c:\program files\healthcast\ExactAccess\SQL\MSSQL\prox.

    New for 4.11.1