Skip to main content

System error from uncommitted user account changes

Symptom

I've configured a new SecureAuth realm or we've made changes to user account names. When browsing to a SecureAuth realm to access my site I receive an error on the page "System Error: We are unable to continue at this time because of uncommitted user account changes. Please log off your system, log back in, and try again."

Cause

This is caused by a mismatch between what the relying party (webpage or device) is expecting and what is being presented (assertion, credentials, etc.) The information being presented to the relying party may be cached, therefore requiring the client system or the SecureAuth appliance to be restarted, or stored in the browser cache requiring the browser to be closed and restarted.

Resolution

Mis-configuration of the Workflow and Post Auth tabs are also a common causes. Verify the IIS authentication methods are correct on the workflow tab (Windows Authentication and impersonation specifically). Additionally, verify any defined pre-authentication page (WindowsSSO.aspx) is intentional as these pages are intended to collect browser credential information or attributes and pass it as part of an authentication process. Verify the Post Authentication tab has the appropriate configuration information based upon the post authentication action required for accessing the device, application or website. (E.g. SAML assertion information (SPinit vs IdPInit), Microsoft Forms Based Authentication, etc.

Also, remember that if a realm was copied to create a new realm, the settings for that realm are also copied. If the original realm was configured for SSO, but the new realm is intended only for 2 factor, username password, etc. There is a good chance that the SSO settings will conflict with the intended workflow.

Example: If a website is not intended to be accessed using SecureAuth Single Sign On realm but WindowsSSO.aspx is defined as the start page on the Workflow tab, the information passed for authentication will not be expected, therefore giving you this error.

Example: If a website is intended to be accessed using SecureAuth Single Sign On realm and WindowsSSO.aspx is defined as the start page but "Windows Authentication" is not set to true on the Workflow tab, the start page can not collect the credential or attribute information to pass on to the relying page therefore the information passed for authentication will not be expected, therefore giving you this error.

Example: I just changed a user today and when the tried to login to our Postini access, which uses Desktop SSO AD credentials, the page reported back: "System Error: We are unable to continue at this time because of uncommitted user account changes. Please log off your system, log back in, and try again." Is this normal behavior or is there something we can do to prevent it from happening when i make the next change? This error typically occurs when there is a name change and the cached mappings between the SID and the user name in the local cache on the domain member computer do not match. Rebooting the SecureAuth Server should refresh the cache and the issue should be resolved.

See our article on dealing with LSA Cache Issues for more information