In Microsoft Active Directory environments, how is SecureLogin configured for fault tolerance and resilience?

Question

In Microsoft Active Directory environments, how is SecureLogin configured for fault tolerance and resilience?

Answer

SecureLogin is mature, proven and stable and has been developed with fault tolerance and resilience in mind. Since (in Microsoft environments) data is stored in Active Directory (e.g. credentials stored against user objects) SecureLogin leverages the built in fault tolerance and service resolution of Active Directory and the existing backups, security, and management of the AD environment.

For example, if SecureLogin is unable to locate one Domain Controller for some reason (i.e. the DC is down), it will contact another DC to access SSO data stored against the user object as per standard Microsoft processes.

The entire Directory (including all Domain Controllers) must fail for SecureLogin to completely fail to contact the Directory. Even if this does occur, Single Sign-on will still operate using the offline cache (which is configured using SecureLogin preferences). When the Directory comes back online, synchronization would occur between the Directory and the offline cache and time stamps determine which data (e.g. credentials that may have changed) is more recent.

Since SecureLogin leverages Active Directory for storage and management of Single Sign-on data, data is also replicated between Domain Controllers using standard Microsoft methodologies. This means users can move between offices and still have access to their Single Sign-on data.

One of the advantages of using Active Directory is that you do not have to install and configure servers or appliances specifically for Single Sign-on and then concern yourself with;

• What happens if the server/appliance crashes? Do I need multiple devices in each office with replication between devices? What happens if they fail?
• How is SSO data replicated around the network (e.g. a user in London flies to Hong Kong to work, how do they access their SSO data and how is performance affected?)
• Installation, configuration and maintenance of the appliance/servers (significant increase in the total cost of ownership of SSO).
• How can I manage the solution?
• What happens when a user leaves or moves the organization - do I have to copy and manage their Single Sign-on profile on and between appliances/servers?