Qué vas a conseguir
Que una aplicación de terceros (aquí un gestor de gastos ficticio, "Fabrikam Expenses") se abra con la cuenta de la empresa, sin contraseña propia, solo para quien esté en el grupo correcto. Y saber qué mirar cuando el proveedor dice "el SAML está bien" y el usuario sigue viendo un error.
Antes de empezar
- Rol de Cloud Application Administrator (o Application Administrator).
- Del proveedor de la aplicación: su Identifier (Entity ID), su Reply URL (ACS) y qué atributo espera como identificador de usuario (normalmente el correo o el UPN).
- Un grupo de seguridad con los usuarios que deben tener acceso (
sg-app-expenses-users). La asignación siempre va por grupo, nunca usuario a usuario. - Un usuario de prueba en ese grupo que no sea tú.
1. Crear la aplicación empresarial
Si la aplicación está en la galería, úsala: trae las URLs y las reclamaciones ya puestas y, a menudo, el aprovisionamiento SCIM. La opción manual es para las que no están.
2. Configurar SAML
Lo que le das al proveedor: la URL de metadatos de federación (y con eso tiene todo) o, si no la acepta, el certificado Base64, la URL de inicio de sesión y el identificador de Entra, que están en la sección 4 de la misma página. Apunta la fecha de expiración del certificado en el calendario del equipo: dentro de tres años esto falla a las 00:00 de ese día.
3. Asignar el grupo y probar
Asignación necesaria: Sí es lo que hace que solo el grupo entre. Con "No", cualquier usuario del tenant puede iniciar sesión en la aplicación. Después, con el usuario de prueba, abre https://myapps.microsoft.com o la URL de la aplicación y comprueba que entra. El botón Probar de la página de SAML también sirve, pero prueba con tu cuenta y tú eres administrador: no es la prueba que importa.
4. Cuando no entra
Los tres que verás casi siempre:
| Código | Qué significa | Qué haces |
|---|---|---|
| AADSTS50105 | El usuario no está asignado | Comprobar que está en sg-app-expenses-users (y que el grupo es de seguridad, no un grupo de M365 dinámico sin sincronizar) |
| AADSTS700016 / 50011 | El identificador o la URL de respuesta que envía la aplicación no coinciden con los de Entra | Comparar carácter a carácter con lo que el proveedor tiene configurado (http frente a https, barra final) |
| AADSTS7500529 / "The signing certificate…" | El proveedor tiene el certificado antiguo | Enviar el nuevo o la URL de metadatos; pasa justo cuando caduca |
Si Entra da Correcto y el error lo pone la aplicación ("user not found", "invalid NameID"), el problema está en la reclamación: el proveedor espera el correo y recibe el UPN, o al revés. La extensión My Apps Secure Sign-in del navegador o el botón Probar enseñan la aserción SAML que se envía, reclamación por reclamación.
5. Lo que revisas cada mes
- Certificados SAML que caducan en menos de 90 días:
Aplicaciones empresariales → filtro "Expiración del certificado", o el repo 20 de mi GitHub, que lo lista con calendario. - Aplicaciones con Asignación necesaria: No que deberían tenerla.
- Aplicaciones sin propietario: cuando falle, nadie sabrá a quién llamar.
- Consentimientos de usuario a aplicaciones nuevas (
Aplicaciones empresariales → Consentimiento y permisos).
Siguientes pasos
- OIDC en lugar de SAML para aplicaciones modernas: se hace en Registros de aplicaciones, con URI de redirección y ámbitos en lugar de ACS y reclamaciones. La guía de Microsoft Graph usa uno.
- Aprovisionamiento SCIM: que la alta y la baja en el grupo creen y desactiven la cuenta en la aplicación. Es lo que cierra el ciclo con la guía de Active Directory del Nivel 1.
- Añade la aplicación a una política de Conditional Access concreta (guía anterior) si exige MFA siempre, aunque el usuario esté en un equipo conforme.
¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.
What you'll get
A third-party application (here a fictional expense manager, "Fabrikam Expenses") that opens with the company account, with no password of its own, only for people in the right group. And knowing what to look at when the vendor says "SAML is fine" and the user still sees an error.
Before you start
- The Cloud Application Administrator role (or Application Administrator).
- From the application vendor: their Identifier (Entity ID), their Reply URL (ACS) and which attribute they expect as the user identifier (usually the email or the UPN).
- A security group with the users who should have access (
sg-app-expenses-users). Assignment always goes through a group, never user by user. - A test user in that group who is not you.
1. Create the enterprise application
If the application is in the gallery, use it: it comes with the URLs and claims pre-filled and, often, SCIM provisioning. The manual option is for those that are not.
2. Configure SAML
What you give the vendor: the federation metadata URL (and with that they have everything) or, if they don't accept it, the Base64 certificate, the Login URL and the Entra identifier, which are in section 4 of the same page. Put the certificate expiry date in the team calendar: in three years this fails at 00:00 on that day.
3. Assign the group and test
Assignment required: Yes is what makes only the group get in. With "No", any user in the tenant can sign in to the application. Then, with the test user, open https://myapps.microsoft.com or the application URL and check they get in. The Test button on the SAML page works too, but it tests with your account and you are an administrator: that is not the test that matters.
4. When they can't get in
The three you will see almost every time:
| Code | What it means | What you do |
|---|---|---|
| AADSTS50105 | The user is not assigned | Check they are in sg-app-expenses-users (and that the group is a security group, not an unsynced dynamic M365 group) |
| AADSTS700016 / 50011 | The identifier or reply URL the application sends do not match Entra's | Compare character by character with what the vendor has configured (http vs https, trailing slash) |
| AADSTS7500529 / "The signing certificate…" | The vendor has the old certificate | Send the new one or the metadata URL; happens right when it expires |
If Entra says Success and the error comes from the application ("user not found", "invalid NameID"), the problem is in the claim: the vendor expects the email and receives the UPN, or the other way round. The My Apps Secure Sign-in browser extension or the Test button show the SAML assertion that is sent, claim by claim.
5. What you review each month
- SAML certificates expiring in under 90 days:
Enterprise applications → "Certificate expiration" filter, or repo 20 on my GitHub, which lists them with a calendar. - Applications with Assignment required: No that should have it.
- Applications without an owner: when it breaks, nobody will know whom to call.
- User consents to new applications (
Enterprise applications → Consent and permissions).
Next steps
- OIDC instead of SAML for modern applications: done in App registrations, with redirect URIs and scopes instead of ACS and claims. The Microsoft Graph guide uses one.
- SCIM provisioning: so that joining and leaving the group creates and disables the account in the application. It closes the loop with the Level 1 Active Directory guide.
- Add the application to a specific Conditional Access policy (previous guide) if it must always require MFA, even on a compliant device.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →