Configuring central identity providers
Using a central identity provider system is like having a large, secure gate protecting your employee’s digital identities. It is important to make sure you configure it correctly so there are no loopholes or gaps that attackers could use to bypass your security controls, like multi-factor authentication (MFA).
Below are steps you can follow to configure your central identity provider system securely. This guide assumes your business has decided to use a central identity provider system, such as Microsoft Azure Active Directory or Okta Identity Management.
When you are using a central identity provider, you will need to choose which systems use it for authentication. These could be systems that you host on-premise or cloud-based applications, like software-as-a-service (SaaS).
MFA needs to be configured at the central identity provider level in order for it to be enforced for each connected system.
As mentioned in our MFA critical control, MFA needs to be configured and enrolled for every user. Details on configuring MFA can be found in our MFA critical control guide.
Disable legacy protocols
Some central identity provider systems allow you to set configurations that disable legacy protocols or protocols that only use basic (username and password) authentication. Using this configuration will stop an attacker from downgrading the security of your system and bypassing the MFA.
Understand the business context and risks
Linking systems by using the same identity provider for each can make for a better user experience. However, it also increases the risk if an account is compromised, as that account can be used to access more and more systems. Work with your your business to consider each system, particularly what data it holds or what processes it supports. You can then work together to determine whether it makes sense to integrate with the central identity provider.
Understand the authentication methods available
For each system that you connect to your identity provider, you need to understand:
- the authentication methods available, and
- the authentication protocols it requires for single sign-on (SSO).
Adding central identity authentication - particularly SSO options - to your systems may be more complicated, or cost extra. However, as this would provide a better user experience, and allow you to use the central provider to enforce MFA on applications that otherwise would not support it, this expense may be justified.
You might find that some of your systems cannot support the modern authentication protocols that your identity provider uses to ensure that security controls such as MFA are used. You might also find systems that support both modern and legacy protocols. This includes older mail systems that support IMAP4, POP3, or ActiveSync. Where both modern and legacy protocols are supported, ensure you disable the legacy protocols in your systems.
Systems that only support legacy protocols are considered legacy systems and should be replaced with systems that use up-to-date protocols. These legacy systems should not be connected to central identity systems as they will create a door into that system that only requires a username and password to enter. These doors are often abused by attackers and are targets for credential stuffing and password spraying attacks.
Monitor your central identity system
Regular reviews of your central identity provider system will help you catch misconfigurations before they cause an incident. These reviews should take place once a year and should involve reviewing which systems are connected and what methods and protocols they use. Manage and mitigate any systems only using legacy protocols as legacy systems. Make a plan to segregate or remove them from the network.
Logging should be configured on the central identity provider system and sent to a secure central store for analysis.
The logs should include security events that capture security and authentication configuration changes, and suspicious login attempts. Unusual login behavior should trigger an alert. Examples include:
- multiple failed login attempts
- unusual user geolocation, such as unexpected overseas access or rapid unexplained changes in location
- when accounts are created, deleted, disabled, or enabled.