Microsoft SSO Setup for Vemco: Step-by-Step with Entra ID

It is 09:40 on a Tuesday. The regional manager clicks the Vemco dashboard link in Teams, gets bounced to a Microsoft login, enters her credentials, and lands on an error page that says AADSTS50011. She forwards the screenshot to the help desk, the help desk forwards it to you, and the person who built the integration left in March. This article is the Microsoft SSO setup you wish that person had documented: the exact sequence in Entra ID, what to test before anyone outside IT touches it, and the handful of errors that account for most failed first logins. If you are still deciding whether to federate at all, or what to put in an RFP, the tender checklist for Office 365 SSO covers that ground; this piece assumes the decision is made.

Before you open the Entra admin centre

Get four values from your Vemco implementation contact in writing, not over a call: the Entity ID (Identifier), the Reply URL (also called the ACS URL), the protocol in use (SAML 2.0 or OpenID Connect), and the attribute the platform uses to recognise a user — UPN, primary email or object ID. That last one decides whether 300 users end up with one account each or two. Also agree who owns the identity-provider side (you) and who owns the service-provider side (Vemco), because every error below sits on one side or the other and the fastest fix is knowing which.

Microsoft SSO setup: the step-by-step sequence

• 1. Create the enterprise application. In Entra ID, go to Enterprise applications, choose New application, then Create your own application and select the non-gallery option. Name it something your help desk will recognise in a sign-in log eighteen months from now — the platform name and environment, not an internal project code.
• 2. Select the sign-on method. Under Single sign-on pick SAML if that is what you agreed; if the platform uses OIDC, you will instead register the app under App registrations and configure a redirect URI and client secret or certificate. The remaining steps describe SAML, which is the more error-prone path.
• 3. Fill in Basic SAML Configuration. Paste the Identifier and Reply URL exactly as supplied. Check three things character by character: https rather than http, the presence or absence of a trailing slash, and the domain spelling. A copy-paste from an email that added a line break is a classic cause of a mismatch.
• 4. Set Attributes and Claims. The Unique User Identifier (NameID) defaults to user.userprincipalname. If your UPNs differ from primary SMTP addresses — common after a merger — and Vemco keys on email, change the source to user.mail now. If you plan to govern store-level versus head-office roles through directory groups, add a group claim here and agree with Vemco whether it should carry group object IDs or display names.
• 5. Hand over the federation metadata. Download the Federation Metadata XML or the Base64 certificate and send it to the Vemco side through a secure channel. While you are in the SAML Certificates panel, fill in the notification email field. It is optional, almost everyone skips it, and it is the only automatic warning you will get before the signing certificate expires.
• 6. Assign a pilot group. Under Users and groups, assign a security group rather than individual users. Put in it one head-office analyst, one regional manager who works mostly from a phone, and one external agency user if agencies pull reports. Do not assign all users yet.
• 7. Apply conditional access. Create a policy scoped to this application: require multifactor authentication outside trusted locations, block legacy authentication, and consider requiring a compliant device for accounts that hold export or admin rights on the analytics side.

How to test before you widen access

Run every test in a private browser window so cached Microsoft sessions do not mask a failure. First, use the Test button on the Entra single sign-on page; this is an IdP-initiated flow and confirms the assertion reaches the Reply URL. Second, start from the Vemco login page and let it redirect you — this SP-initiated flow is what real users experience and it exercises the Identifier matching that the Test button does not. Third, repeat the SP-initiated login on a mobile browser and, if applicable, in the mobile app. Fourth, log in as the guest account. Finally, open Sign-in logs in Entra, filter by the application, and confirm each successful login shows the expected user identifier in the claims — this is where you catch a UPN-versus-email mismatch before it creates duplicates.

Only after all five pass do you add the production groups to the assignment. Keep named local break-glass accounts active on the Vemco side for the first month, then ask for local authentication to be switched off. Office 365 single sign on only delivers automatic offboarding if there is no second door.

The errors you will actually see, and what each one means

• AADSTS50011 — reply URL mismatch. The URL Vemco's platform is sending in the request does not match any Reply URL in Basic SAML Configuration. Compare them literally: scheme, host, path, trailing slash.
• AADSTS700016 — application not found. The Identifier in the request does not match the one you configured. Usually a mistyped Entity ID, or a staging value supplied by mistake.
• AADSTS50105 — user not assigned. The user authenticated fine but is not in an assigned group. Check group membership and allow for a few minutes of propagation after adding someone.
• Login works but the user lands in an empty or second account. Not an Entra error at all. The NameID being sent does not match the identifier Vemco expected, so the platform created a new user. Fix the claim source, then ask Vemco to merge or remove the orphan.
• Guest users fail while employees succeed. B2B guest UPNs contain an #EXT# segment and their mail attribute may be empty. Either populate the attribute or agree a different identifier for external accounts.
• Everything worked for years, then stopped one morning. The SAML signing certificate expired; Entra issues them with a three-year lifetime. Generate a new certificate in Entra, send the updated metadata to Vemco, activate it, and this time put a renewal owner in a runbook rather than in someone's head.

For anything not on this list, the Entra sign-in log entry for the failed attempt contains a correlation ID and a timestamp. Send both to Vemco support with the error code; it shortens the diagnosis from days to hours because each side can see which half of the handshake broke.

Frequently asked questions

How long does a Microsoft SSO setup for the Vemco platform take? The configuration itself is typically an afternoon once the Identifier, Reply URL and user identifier are agreed. The elapsed time is set by coordination: getting values in writing, scheduling pilot users, and the month-long fallback window before local login is disabled.

Should we use SAML or OpenID Connect? Use whichever Vemco confirms for your deployment. If both are available, OIDC avoids certificate rotation and suits mobile access; SAML gives finer control over attribute mapping and is familiar to auditors.

Do users still need to be created in the platform before first login? That depends on whether provisioning is in place or the platform creates users on first federated login. Confirm this with Vemco during setup, because it changes whether the pilot group needs accounts prepared in advance.

If you are about to configure federation for a Vemco deployment and want the Identifier, Reply URL and identifier mapping confirmed before you touch Entra ID, contact Vemco Group's implementation team and get the values directly from the people who handle enterprise rollouts.