Overview

Many customers who use SSO are concerned about access to the strongDM Admin UI if their provider (e.g. Okta) goes down. They often establish "break glass" accounts for one or more SDM admins.

Details

Here are the relevant bits from the Settings page in the Admin UI:

 Additional explanation for the three setting options above: 

• Allow password login for admins: means that current or future Administrators can login with either SSO or password credentials. When they hit the Admin UI and enter their email, they'll see a screen like this:

  

They can enter their password and click Login or click Login with Okta and then enter their Okta credentials.

• Allow non-SSO users: this allows the creation of a special type **of user that can only login with password. Crucially, these accounts can only be Users. To create one, click the Add User button, then click the non-SSO checkbox at right:

Non-SSO users will only ever see the Login option:

i.e. they can only ever login with username and password.

• The corollary is that Okta users will only ever see the Login with Okta option.

How to create a non-SSo admin in SDM: 

Once you configure your organization for SSO, several seemingly-obvious workflows to create non-SSO admin result in failure, even if you have the most open settings enabled, as above. So the customer creates a non-SSO user, tries to elevate to Administrator and gets an error.

Solution

Just create a regular user (i.e. don't check the non-SSO box). Then promote them to Administrator. This may be a bit counter-intuitive: why create an "Okta-type" user in SDM if the intention is to login with password? Well, you just have to.

How to log in to the CLI or client with non-SSO account:

If you have an SDM-only account, and you enter your email into the CLI or client login field, you are automatically redirected to the enabled SSO app. But you don't have an SSO account.

Solution

Again, it's important to first distinguish between:

• A user or Admin in SDM that has no matching account in the SSO provider (e.g. Okta)
• A user explicitly created with the non-SSO checkbox enabled

The first type (SDM-only) can only log into the Admin UI, by design. This is in the code, and independent of any organization settings.

The latter type of account can log into the CLI or client, and in fact it was more or less designed for this. The idea being that type of user is a contractor or other third-party, but still needs to access e.g. some databases.

However, as noted above, a non-SSO account can only have User permissions, i..e cannot be an Admin. So the corollary is:

If you have SSO enabled in your org, and want to use the client or CLI, you must create a matching SSO account for your Admin account, or (for CLI only) use an Admin Token.