This domain has been configured for Single Sign On you can't create an account

Help
1

Hello, we have multiple clients that are using SSO to login to our platform. We also have some that doesn’t but just use email/password.

Recently a colleague of mine have registered a new client and enabled SSO. my colleague is now on vacation in brazil (Great) and I know nothing about this configuration. Obviously exactly now we are running into a very non trivial case:

Some user is added as member to client-A (who does not have SSO enabled), he gets an email with a sign up link but when he tries to signup he sees this message:

10
We’re sorry, something went wrong when attempting to sign up.

I can see from the response of the signUp request that this is due to his email domain is @client-B.com which is the organization that we just signed configured SSO for last week.

{“code”:“signup_on_sso_domain”,“domain”:“client-B.com”,“error”:“This domain client-B.com has been configured for Single Sign On and you can’t create an account. Try signing in instead.”}

Now client-A complains that they have a user that cannot sign up.

I have just been given access to the auth0 dashboard, and I am not sure where to look for configuration or what to do. When I click the ‘SSO Integration’, the page just shows “No items have been added to this section.”

What should I look for? Please help…

Rasmus

2

Hi Rasmus,

Welcome to the Auth0 community.

I’m assuming the “SSO” that you are referring to in this post, is to allow users login your platform with external IdP (such as your company’s AD, Google Gmail or G suite, Facebook and etc, we call it enterprise connections, and social connections), instead of a user created in Auth0 database (we call it Auth0 Database Connection).
In this case, the user is not signup through Auth0, but from the external IdP. Does it make sense?

Regarding the issue you are experiencing, most probably the new client that your colleague registered, has enabled an enterprise connection for SSO, and that enterprise connection has set “client-B.com” as the its email domain, which means, any account with email in “client-B.com” is treated as an external IdP account.
If you don’t need the “SSO” ability for this new client, you can disable the connection from your tenant dashboard: Applications → Select the new client → select Connections tab → toggle OFF the unwanted connection

1 Like
3

Hi. thanks, I think you are on to something here. I can see many of our clients under Applications but client-B does not appear on in this section. We have a backup/auth0.conf.json in our source code, which is generated from some script, and in this config file I do see client-B. Maybe if I show you how it looks you would know where I should look in the dashboard?

"connectionList": [
  {
    ...
  },
  {
    "id": "con_jSOMEID732131",
    "options": {
      "use_wsfed": false,
      "useCommonEndpoint": false,
      "basic_profile": false,
      "ext_profile": false,
      "ext_groups": false,
      "ext_nested_groups": false,
      "api_enable_users": false,
      "waad_protocol": "openid-connect",
      "identity_api": "microsoft-identity-platform-v2.0",
      "domain": "client-B.com",
      "tenant_domain": "client-B.com",
      "client_id": "ad88811-1111-11aa-1111-11aa11a111aa",
      "app_domain": "our-domain.eu.auth0.com",
      "thumbprints": [
        "12FC12FC12FC12FC12FC12FC12FC12FC12FC12FC",
        "33AD33AD33AD33AD33AD33AD33AD33AD33AD33AD"
      ]
    },
    "strategy": "waad",
    "name": "client-B",
    "provisioning_ticket_url": "https://our-domain.eu.auth0.com/our-domain/p/waad/some-id",
    "is_domain_connection": false,
    "realms": [
      "client-B"
    ],
    "enabled_clients": [
      "rhBLABLABLABLABLABLAuv51AQYc"
    ]
  }
]

within connectionList i see things like
…“strategy”: “google-oauth2”
…“strategy”: “auth0”
…“strategy”: “oauth2”
and then this newly added “waad” thing named client-B.

In this conf file I am also able to find all of our other clients, but they appear under clientList and not connectionList. - maybe that is why I see those under Applications in the dashboard, but not clint-B?

From reading your message, it sounds like turning off “tenant_domain”: “client-B.com”, would allow emails with that domain to be signed up with email/pw again, but would the SSO still work for that client then?

I still can’t find client-B in the dashboard anywhere, so if you could please point me in the right direction here that would be very helpful.

EDIT: I have found it under Connections → Enterprise → Microfost Azure AD but I have no clue what to do from here. It is very important that their SSO still works, but their employees must also be able to signup with email/password authentication as well - as they might be member of other organisations who uses our system.

Rasmus

4

Hi Rasmus,

You are looking at the right place () to find the “client” “client-B.com”.

In Auth0 terminology, Application and Client means the same thing. Actually Client is the term used by OAuth2 protocol, but it often confuses people so we renamed it to Application in the tenant dashboard.
Auth0 Connection means the source of user identity, it could be an external IdP (such as your company’s AD, Google Gmail or G suite, Facebook and etc, we call it enterprise connections, and social connections),and also an Auth0 database (we call it Auth0 Database Connection).

Since you were referring “client-B.com” as Client (it’s named client-B) but actually it is a connection of Microsoft Azure AD type. So let’s bear this in mind in the following discussion.

For any Application you need to enable one or more connections for it, which will be used by the application to authenticate uses. If an enterprise connection is enabled (such as the Client-B connection in your case), if the input user email falls in the domain of Client-B.com, it is assumed the user is from that enterprise connection and is to be authenticated against it.

Back to your questions

It is very important that their SSO still works

As long as you enabled Client-B connection for the Application, the SSO works (as explained above).

but their employees must also be able to signup with email/password authentication as well - as they might be member of other organisations who uses our system.

For the Applications that enabled Client-B connection, the users cannot signup with email address from client-b.com domain. For the Applications that are not enabled Client-B connection, the users could signup with emails from client-b.com domain without issue.