Troubleshooting: SecureAuth Connector Does Not Apply Datastore Changes

Version Affected: All
 
 

Overview

One or more SecureAuth Connector servers do not apply changes saved to a datastore. Each Connector keeps its own copy of every datastore's configuration in its configuration file, so a Connector that has not received a change, or could not save it, keeps working from the old configuration. Only the requests handled by that Connector are affected, so where more than one Connector is installed, the failures can appear intermittent.

A user with a valid user ID can fail to log in to a realm, with an entry similar to this in the realm's Debug log:

Message="CloudMembershipManager.GetUser exception: Status(StatusCode=DeadlineExceeded, Detail="Deadline Exceeded")"

For a datastore the Connector has no configuration for at all, such as a newly created one, the Connector log shows No provider found for dataStore=#<datastore-id>. The Connector log is in C:\ProgramData\SecureAuth Corporation\SecureAuth Connector\logs on each Connector server.

There are two possible causes:

• See Cause 1 - The Connector service was not running, or could not be reached, when the datastore was created or updated.
• See Cause 2 - The Connector log shows Unable to save config to file after the datastore was saved.

In this article

• Cause 1: The Connector did not receive the change
• Cause 2: The Connector cannot save its configuration file

Cause 1: The Connector did not receive the change

A Connector receives a datastore's configuration when the datastore is created or saved. If the Connector was not installed, not running, or otherwise unreachable at that time, it never received that datastore's latest configuration.

Resolution 1:

To resolve this:

1. Confirm the Connector service is running on every Connector server.
2. In the Admin Console, retype the password for each datastore, then save that datastore. This sends the datastore's configuration to the Connectors again.
3. Confirm each Connector's configuration actually updated by checking the modified date on C:\Program Files\SecureAuth Corporation\SecureAuth Connector\SecureAuth.Agent.Service.exe.Config.
4. If the configuration still has not updated, check the Connector log for errors. If the log shows Unable to save config to file, see Cause 2.
5. If the configuration has updated but the user still cannot log in, check the same log for details on why the user lookup is failing.

Cause 2: The Connector cannot save its configuration file

A Connector saves a datastore change by writing the new configuration to a temporary file in the Connector folder, C:\Program Files\SecureAuth Corporation\SecureAuth Connector, then replacing SecureAuth.Agent.Service.exe.Config with the temporary file. If that save fails, the Connector logs the error below, and the change is not written to the file. The next time the Connector service restarts, it loads the old configuration without the change.

msg=Error applying configuration|exception=System.Configuration.ConfigurationErrorsException Unable to save config to file 'C:\Program Files\SecureAuth Corporation\SecureAuth Connector\SecureAuth.Agent.Service.exe.Config'.

The save can fail when:

• NETWORK SERVICE, the account the Connector service runs as, no longer has its default permissions on the Connector folder or on the configuration file. These permissions have been found changed in the field after installation.
• The configuration file is set to read-only.
• Antivirus software has the temporary file or the configuration file open for scanning at the moment the Connector replaces the configuration file.

Resolution 2:

To resolve this:

1. On the affected Connector server, right-click the Connector folder, C:\Program Files\SecureAuth Corporation\SecureAuth Connector, select Properties, then Security, then Advanced, and restore the default permissions for NETWORK SERVICE. A Connector server whose configuration is updating correctly can be used for comparison. The image below shows the defaults: NETWORK SERVICE has Special access to the folder itself and Write access to its subfolders and files, alongside the permissions the folder inherits from C:\Program Files.
   
2. Double-click the NETWORK SERVICE entry with Special access to see what it includes. By default it allows Create files / write data, Create folders / append data, Write attributes, Write extended attributes and Read permissions, applied to This folder only, as the image below shows. Create files / write data is what lets the Connector create its temporary file in the folder.
   
3. Restore the default permissions for NETWORK SERVICE on SecureAuth.Agent.Service.exe.Config in that folder too. The image below shows the file's defaults: NETWORK SERVICE owns the file and has Full control of it.
   
4. In the configuration file's Properties, make sure Read-only is not selected.
5. Exclude the Connector folder from antivirus scanning, both scheduled scans and on-access scans.
6. In the Admin Console, retype the datastore's password, or make another change to the datastore, and save it. This sends its configuration to the Connectors again.
7. Restart the Connector service on the affected server.
8. Check the log on each Connector server for the two lines below. They are logged when the Connector sets up the datastore, and are missing on a Connector that does not have it. The datastore's ID appears next to its name in the log line that starts with Applying configuration for DataStore.

msg=BaseMembershipProvider.Initialize is finished for DS_<datastore-id>
msg=BaseProfileProvider.Initialize is finished for DS_<datastore-id>

Special Considerations

Saving a datastore sends the change to every Connector at the same time, and each Connector applies and saves it on its own. One Connector can fail while the others succeed, so after a datastore change, check the log on every Connector server, not only one.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.