Available on an Enterprise agreement. Your identity team and ours do this together, usually in one session, and the order below is the order that works.
1. Claim your domain, first
Everything else waits on this, so start it now.
Settings to Single sign-on to Domains. Add your domain. We give you one record to publish in your DNS.
Until that record resolves, the claim asserts for nobody. That is deliberate: without proof, anyone could claim your domain and point their own provider at your people's addresses.
Publishing a DNS record inside a large company takes days more often than minutes. It is the step most likely to be what everything else is waiting on.
2. Connect the provider
Settings to Single sign-on to Connection.
We give you our service metadata. Your identity team creates the application on their side and sends back theirs, which you paste in. Either the metadata file or the three values by hand.
We support SAML 2.0. Your provider signs its assertions; we hold your signing certificate and accept two at once so you can rotate without a window where sign-in breaks.
Sign-in starts from us, not from your provider's application tile. A tile that starts the sign-in on your side is refused, because there is nothing for us to match the response against and that is the shape most single-sign-on attacks take.
3. Sign in once, for real
One person signs in through your provider.
This is the step that proves it. Requiring single sign-on for everyone is refused until a real sign-in has succeeded, on purpose: enforcing a connection that is subtly misconfigured locks a company out of its own account, and that is a worse morning than a delayed rollout.
4. Require it
Settings to Single sign-on to Require for everyone.
Now passwords, sign-in links and the Google and Microsoft buttons all stop working for your people. That is the point. Someone whose account you disabled in your directory cannot use a password they set last year.
It applies to anyone in your organization, including a contractor whose address is on their own domain rather than yours.
The way back in when your provider is down
Owners keep their password. That is a deliberate decision, not an oversight: an outage at your provider at two in the morning has to be recoverable by somebody.
Every such sign-in is written to your audit record, naming the person and which door they used. The exemption exists, and it is never silent.
If every owner is also unreachable, contact support and we can lift enforcement from our side.
Things worth knowing
Two-factor. Your provider owns the sign-in ceremony including its own second factor, so ours is not asked for on top. Enforce it in your provider.
A contractor on their own domain. They still get in through your provider once you add them, and enforcement still applies to them, because it follows membership of your organization rather than the shape of an address.
Someone who already had an account here. Their account becomes yours to administer. Their existing projects come with them.
Lowering your plan. If the agreement ends, enforcement stops applying rather than leaving your people with no way in. Your settings are kept, untouched, for if you come back.