Configure SSO with Microsoft ADFS

Microsoft Active Directory Federation Services (ADFS) shares identity information between trusted parties over SAML 2.0. Connecting it to ScatterSpoke means your directory decides who can sign in — and therefore who consumes a seat.

Before you start

• SSO must be available on your plan — the add-on on Business, or included on Enterprise. See Single sign-on.
• You need administrator access to the ADFS management console and to ScatterSpoke.

1. Get the ScatterSpoke values

Go to Settings → SSO and select Enable SSO. Copy the two values from step 1 of the card:

• Entity ID / Issuer — the relying party trust identifier
• ACS / Callback URL — the relying party SAML 2.0 service URL

2. Add a relying party trust

In the ADFS management tool, expand Trust Relationships → Relying Party Trusts and select Add Relying Party Trust. In the wizard:

Prompt	Value
Display name	ScatterSpoke
Profile	ADFS profile
Certificate	Default
Configure URL	Enable support for the SAML 2.0 WebSSO protocol, then paste the ACS / Callback URL
Relying party trust identifier	Paste the Entity ID / Issuer — select Add before continuing
Multi-factor authentication	I do not want to configure multi-factor authentication settings for this relying party trust at this time
Issuance authorization rules	Permit all users to access this relying party

Finish the wizard and close it.

3. Edit the claim rules

Right-click the new trust and select Edit Claim Rules. You need two rules.

Rule 1 — send the email address. Add a rule using the Send LDAP Attributes as Claims template. Name it something like Get EmailAddress. Set Attribute store to Active Directory, then map E-Mail-Addresses (LDAP attribute) to E-Mail Address (outgoing claim type).

Rule 2 — transform it into the name ID. Add a rule using the Transform an Incoming Claim template. Set Incoming claim type to E-Mail Address, Outgoing claim type to Name ID, and Outgoing name ID format to Email. Leave Pass through all claim values selected.

The second rule is what lets ScatterSpoke create accounts: it puts the directory user’s email into the SAML NameID, which is where the default field mapping looks.

4. Export the token-signing certificate

In the ADFS management tool, go to Service → Certificates, right-click Token-signing, and choose View Certificate. On the Details tab select Copy to File, choose DER encoded binary X.509 (.CER), and save it.

ScatterSpoke needs the certificate in PEM format. Convert it with OpenSSL:

openssl x509 -inform der -in certificate.cer -out certificate.pem

5. Connect ADFS to ScatterSpoke

Back on Settings → SSO, step 2 offers three routes:

• Fetch from URL — point it at your ADFS federation metadata, typically https://adfs.example.com/FederationMetadata/2007-06/FederationMetadata.xml. It must be reachable from the public internet.
• Upload metadata.xml — if you downloaded that file instead.
• Or enter manually — for internal-only ADFS deployments. Paste the SSO URL (entry point), usually https://adfs.example.com/adfs/ls/, and the X509 certificate in PEM format from step 4.

Then set the mapping. With the claim rules above, ADFS sends the email as the NameID, so leave Name field and Email field at nameID and Name transform method on Extract from email. Leave Family name field empty unless you added a surname claim.

Select Save SSO Configuration.

Note

The certificate must be at least 100 characters for the form to accept it. Include the whole PEM block, -----BEGIN CERTIFICATE----- line and all, if Save stays disabled.

6. Test before enforcing

The card now shows SSO is enabled · Active. Sign in from a private browser window with a directory account and confirm you are handed to ADFS and returned signed in.

Only then turn on Enforce SSO for all users. Enforcement disables password login for everyone except organization administrators, who keep it as a recovery path.

Certificate rotation

ADFS token-signing certificates expire and roll. When yours does, sign-in fails until ScatterSpoke has the new one: select Reconfigure on the SSO card and re-fetch the metadata or paste the new PEM certificate. Put the expiry date in a calendar — this is the most common cause of a working SSO setup breaking without anyone touching it.