Azure · Sitecore
Sitecore Identity Server y Azure AD security groups límite parte 2
No esperaba escribir otra entrada sobre Sitecore Identity Server y Azure AD Security Groups límite ya que pensé que al encontrar el número mágico la última vez y la solución reduciendo la membresía de los usuarios sería suficiente.
Si estás leyendo esto, ten en cuenta que ¡ERÉ YO! 🙂
En resumen, el primer blog sobre Sitecore Identity Server y los límites de Azure AD Security Groups, el usuario era miembro de 180 Security Groups y después de proporcionar sus credenciales, era redirigido a una página de error HTTP 431 o a una página en blanco pero nunca a Sitecore Experience Platform.
A diferencia de la vez anterior, el usuario está viendo el siguiente mensaje de error
You do not have access to the system. If you think this is wrong, please contact the system administrator.
Bueno, este es exactamente el error que describí en la guía de solución de problemas de mi última entrada, así que si aún no leíste, ¡hazlo! Y antes de continuar mi investigación, he seguido los tres pasos listados allí
- Azure AD Security Groups del usuario
- Verificar la existencia de los Azure AD Security Groups que reclaman un Sitecore Role en ..\sitecore\Sitecore.Plugin.IdentityProvider.AzureAd\Config\Sitecore.Plugin.IdentityProvider.AzureAd.xml
- Verificar la existencia del Sitecore Role
Además de eso, también verifiqué el número de los Azure AD Security Groups de los que el usuario era miembro, y para mi sorpresa el usuario tenía 54 grupos, lo cual está muy lejos del número mágico – 170 – que encontramos en la primera parte de esta serie.
Como el usuario no podía iniciar sesión y, aparentemente, no había nada mal con la cuenta, su membresía, etc., se abrió un ticket de Sitecore. Y para realizar un análisis más profundo, se solicitó una sesión de Fiddler del usuario problemático y de un usuario que funcionaba.
La sesión de Fiddler debe configurarse para dejar todas las llamadas en la sesión y verificar Tools -> Options -> HTTPS -> Decrypt HTTPS Traffic
Una vez que tienes la sesión de Fiddler, busca la siguiente línea /signin-oidc porque allí podrás encontrar el token utilizado para solicitar la autenticación en Azure AD.
Análisis de Fiddler del usuario problemático
- Buscar /signin-oidc
- Hacer clic en Inspectors
- Hacer clic en Raw
- Hacer clic en View in Notepad
- Copiar todo después de id_token=
- Acceder a jwt.ms, y pegar el contenido del ítem 5
Análisis de Fiddler del usuario que funciona
Básicamente, repite todos los pasos que hicimos para el usuario problemático y verifica su id_token en jwt.ms
Usuario que funciona vs Usuario problemático
Mientras que el usuario que funciona envía los grupos a través del token, el usuario problemático no lo hace, por lo que no hay forma de que el usuario se autentique correctamente.
Después de llegar a este análisis, el Soporte de Sitecore cree que el usuario podría pertenecer a grupos anidados que exceden los 170 Azure AD Groups, por lo cual no se están devolviendo las claims.
El soporte de Sitecore luego sugirió lo siguiente
- Disminuir el número de grupos de algunos de tus usuarios
- Crear un Azure Active Directory separado para gestionar solo grupos de Sitecore
- Mover los permisos de Sitecore de los “Azure AD Security Groups” a “Azure AD Application Roles”
Para mantener nuestra cordura aquí, voy a cubrir estas posibilidades en la parte 3 de este blog post.
¡Espero que te haya gustado, y nos vemos en mi próxima publicación!
Foto por Meritt Thomas en Unsplash