The AcuConnect connection validation logic is described here to clarify the use of the server access file (AcuAccess) and the DEFAULT-USER configuration variable.
When a client process (running application) makes its first request to AcuConnect, AcuConnect performs the following access validation procedure.
To validate the requester's access privileges, AcuConnect:
1. opens the server access file
2. searches for a record that matches both the client machine name and the client user name
3. (if no match has been found) searches for a record that matches the client machine name and a "match all" (blank) client user name
4. (if no match has been found) searches for a record that has the "match all" ("*") client machine name and the client user name
5. (if no match has been found) searches for a record that has the "match all" ("*") client machine name and the "match all" (blank) client user name
6. (if no match has been found) refuses the connection.
When a match is found:
1. If the Local Username is valid, it is used.
2. If the Local Username is not valid, DEFAULT-USER is used.
3. If the Local Username is not valid and DEFAULT-USER is not valid, the connection is refused.
If the Local Username is valid and the password field is defined, a message is sent back to the requester asking for a password. For more about password handling, see the section that follows.
When a connection is established, AcuConnect returns the Local User Name to the requester runtime. The runtime uses this name when making subsequent access requests.
When the client process terminates, the client-server connection is broken. New client applications requesting AcuConnect services will go through the verification process to establish a connection.
More: