Skip to main content

Best Practices for SecureAuth IdP

Summary

SecureAuth IdP is designed for endless customization and possibilities. However, with every customization or configuration change, safety should be paramount.

Purpose

Use this guide to manage and follow best practices of all SecureAuth IdP deployment.

Prerequisites

Your SecureAuth IdP appliance should be installed, powered on, and deployed.

Network Infrastructure

These instructions contain best practices for integrating a SecureAuth IdP appliance into your network infrastructure.

High Availability

When using multiple SecureAuth appliances in a load balanced configuration, be aware of how sessions are handled. Normally, a load balancer routes each request independently to a node with the smallest load. While this method works fine for normal (stateless) web applications, it causes issues with SecureAuth which is a stateful application. In this case, the node which first handles the request from a user must continue to answer their requests until the session concludes. To accommodate this use case, most load balancers have a sticky session feature (also known as session affinity) which enables the load balancer to bind a user's session to a specific node. This ensures that all requests coming from the user during the session are sent to the same node.

Adding a SecureAuth IdP appliance to an Active Directory Domain

SecureAuth recommends that you do not add your SecureAuth appliance to an Active Directory Domain unless required for specific functionality (e.g. Integrated Windows Authentication) or if instructed to do so by a SecureAuth engineer. If there is a requirement for adding the appliance to a domain whether for functionality or management, please consider the following points:

  • The SecureAuth appliance needs to communicate with Domain Controller(s) in your environment to successfully join and participate in the Active Directory Domain. Ensure that the Windows Advanced Firewall on the appliance AND your corporate firewall allow the necessary communications.

  • Group Policies (GPOs) are applied to the SecureAuth appliance upon joining the domain. Please review the GPOs which are applied to the appliance before joining it to the domain to ensure there are no conflicts. We suggest filtering the application of Group Policies so they are not applied to the SecureAuth appliance (if possible).

SecureAuth IdP Appliance Maintenance

The instructions below provides best practices for maintaining your SecureAuth IdP appliance.

Backup

For our customers, SecureAuth appliances are the first line of defense for access control and identity management. It is crucial for you to protect these resources. To protect your organization's SecureAuth infrastructure, implement a data backup and recovery plan. Backing up your appliance(s) can protect against accidental loss of data, corruption, hardware failures (if applicable), and even natural disasters.

SecureAuth recommends that you integrate the appliances into your existing backup system to ease management. If no policy exists, we recommend developing one for SecureAuth at the earliest possible opportunity. SecureAuth includes a backup utility which can be run to ensure a complete backup. Please see the document SecureAuth Appliance Disaster Recovery Backup for further information.

Reporting & Logging

  • Log Instance ID: This ID is written to the logs as a way of uniquely identifying each realm which generated the content. We suggest one of two options when populating this value.

    • Use the realm number (e.g. secureauth11)

    • Use a functional description of the realms purpose (e.g. PasswordReset)

  • SecureAuth0 Logging: Unless required by your InfoSec policies, we suggest not enabling the database logging for SecureAuth0. In some cases, it can cause a degradation in appliance performance.

  • Log Rotation: If you are utilizing the text logging functionality of SecureAuth, ensure that log rotation is occurring at a consistent interval (e.g. every 7 days) and archived to a safe location. Log retention depends on your InfoSec policies.

    This should be done for two reasons: 1) to prevent a low disk space situation on the appliance; and 2) to keep historical records safe in case they are needed for analysis.

  • SQL Logging: If the SecureAuth Appliance is pointing to an external SQL server, consult with your DBA to ensure proper backups are performed on the schema.

File System

SecureAuthX folders where X is a number (e.g. SecureAuth1) are located in the D:\SecureAuth directory. These are the only folders that should be in that directory containing SecureAuth as part of the name. Any other folders in this directory with SecureAuth as part of the title should be moved to another location. The presence of these folders can cause both the FileSync service and SecureAuth idP to fail or behave erratically.

SecureAuth IdP Appliance Updates

To request an upgrade, please open a ticket with SecureAuth Support.

For additional information on the upgrade process, please see the support document SecureAuth IdP Software Upgrade Process.

Antivirus and Patch Management Best Practices

Please see the support document Antivirus and Patch Management Best Practices for SecureAuth Appliances for guidance on Windows Patch Management and Antivirus software configuration.

Realms

The instructions below contain best practices for creating and maintaining realms on a SecureAuth IdP appliance.

Setup and Design
Dual-Mode IP Restrictions (URL rewrite)

In workflows where a private (internal) and public (external) realms are utilized, we recommend using the URL rewrite module of IIS to facilitate the redirect. While the IP Address and Domain Restrictions functionality of IIS can be used to perform the task, it provides less functionality. Further, in SecureAuth environments where Windows Server 2008 and Windows Server 2012 appliances are mixed, the configurations do not translate properly. For further information on using the URL Rewrite module for IP restrictions, please see the SecureAuth support document URL Rewrite - IP Restrictions.

User Friendly URL

You can create User Friendly URLs (also known as Vanity URLs) which are easier for users to remember. For example, if SecureAuth3 on your appliance is a forgot password realm, you can make the URL https://idp.company.com/password instead of https://idp.company.com/SecureAuth3. This is much easier for users to remember then a realm number. In addition to the improved user experience, a User Friendly URL can also help increase the security of your SecureAuth environment.

By masking the realm numbers you make it harder for an intruder to sequentially probe the realms and determine their functionality. Please see the support document User Friendly URL Best Practice for further information.

In this section: