Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
En este artículo se proporcionan respuestas a las preguntas más frecuentes sobre la administración de usuarios y permisos en Azure DevOps. Las preguntas más frecuentes se organizan por tema para ayudarle a encontrar rápidamente información sobre la administración de usuarios, permisos, niveles de acceso, suscripciones de Visual Studio, integración de GitHub Enterprise y tareas administrativas relacionadas.
Permisos generales
P: ¿Qué ocurre si olvido mi contraseña?
R: Puede recuperar la contraseña de la cuenta Microsoft o recuperar la contraseña de la cuenta profesional o educativa si su organización ha activado esta característica. De lo contrario, póngase en contacto con el administrador de Microsoft Entra para recuperar su cuenta profesional o educativa.
P: ¿Por qué no puedo administrar usuarios?
R: Ser miembro del Grupo de administradores de colecciones de proyectos o Propietario de la organización para administrar usuarios en el nivel de organización. Para que te agreguen, consulta Cambio de permisos a nivel de organización o de colección.
P: ¿Cómo encontrar el propietario de la organización?
R: Si tiene al menos acceso básico, puede encontrar el propietario actual en la configuración de la organización. Para obtener más información, consulte Consultar al propietario de la organización.
P: ¿Cómo encontrar un administrador de colecciones de proyectos?
R: Si tiene al menos acceso Básico, puede encontrar un miembro del grupo Administradores de la colección del proyecto en la configuración de la organización o de la colección.
Para obtener más información, consulte Consultar un administrador de la colección de proyectos.
P: ¿Por qué los usuarios no pueden acceder a algunas características?
R: Es posible que necesiten un nivel de acceso diferente asignado, además de los permisos concedidos a través de grupos de seguridad. Por ejemplo, el nivel de acceso de las partes interesadas proporciona compatibilidad parcial para seleccionar características, lo que permite a los usuarios ver y modificar elementos de trabajo, pero no usar todas las características.
P: He quitado accidentalmente mis permisos y no puedo concederlos de nuevo. ¿Cuál debo hacer?
R: La única manera de resolver este escenario es solicitar un aumento en los niveles de permisos.
Suscripciones de Visual Studio
P: ¿Cómo se detectan los suscriptores de Visual Studio?
R: Azure DevOps reconoce automáticamente a los suscriptores de Visual Studio que tienen Azure DevOps como ventaja en función de la dirección de correo electrónico de los usuarios o de la identidad alternativa asociada a la suscripción. Los administradores pueden elegir el nivel de acceso "Suscriptor de Visual Studio", pero independientemente del nivel de acceso que asignen inicialmente, se detectará el acceso a la suscripción de Visual Studio al iniciar sesión.
P: ¿Cuándo se selecciona "Suscriptor de Visual Studio/MSDN"?
R: Asigne este nivel de acceso a los usuarios que tienen suscripciones de Visual Studio activas y válidas. Azure DevOps reconoce y valida automáticamente a los suscriptores de Visual Studio que tienen Azure DevOps como ventaja. Necesita la dirección de correo electrónico asociada a la suscripción.
Si el usuario no tiene una suscripción de Visual Studio activa válida, solo puede trabajar como parte interesada.
P: ¿Qué suscripciones de Visual Studio puedo usar con Azure DevOps?
P: ¿Por qué no se valida mi suscripción de Visual Studio?
P: ¿Por qué cambian los niveles de acceso del suscriptor de Visual Studio después de que el suscriptor inicia sesión?
R: Azure DevOps reconoce suscriptores de Visual Studio. Los usuarios tienen acceso automáticamente, en función de su suscripción, no en el nivel de acceso actual asignado al usuario.
Administrar suscripciones de Visual Studio expiradas
P: ¿Qué cambia para los suscriptores de Visual Studio expirados en Azure DevOps?
R: Históricamente, los usuarios con suscripciones de Visual Studio expiradas continuaron accediendo a Azure DevOps en organizaciones donde se agregaron mientras su suscripción estaba activa. A partir de febrero de 2026, los administradores pueden ver qué usuarios han expirado las suscripciones. Los administradores tienen un período de gracia durante febrero y marzo para actuar antes de que estos suscriptores expirados comiencen a recibir acceso a las partes interesadas en abril.
P: ¿Cómo puedo saber si mis usuarios se ven afectados?
R: Azure DevOps muestra un banner en Configuración de la organización>Usuarios si su organización ha afectado a los usuarios. Los usuarios con una suscripción expirada se identifican con un nivel de acceso no válido, pero siguen teniendo acceso completo durante febrero y marzo. Use el filtro Nivel de acceso para mostrar solo a los usuarios con una suscripción de Visual Studio no válida.
P: ¿Qué ocurre con las canalizaciones gratuitas para los usuarios de Visual Studio Enterprise?
R: Si tiene suscriptores de Visual Studio Enterprise (VSE) con suscripciones próximas a expirar, puede ver cuántas concurrencias de canalizaciones autohospedadas de VSE gratuitas se perderán. Compruebe el informe de concurrencia autoalojada y considere la posibilidad de aumentar la concurrencia autoalojada de pago según sea necesario. No perderá ninguna simultaneidad autohospedada a partir de la expiración de los suscriptores de Visual Studio Enterprise hasta abril de 2026.
P: ¿Los usuarios perderán el acceso inmediatamente?
R: No. En febrero y marzo de 2026, los suscriptores de Visual Studio expirados conservan su acceso actual en Azure DevOps. Durante estos meses, el objetivo es hacer que los administradores sean conscientes y darles tiempo para ajustar las licencias o las reglas de grupo. Los suscriptores de Visual Studio con suscripciones expiradas comienzan a expirar en abril de 2026 y, después, expiran en Azure DevOps cuando pierden el acceso en el portal de administración de Visual Studio.
P: ¿Qué ocurre cuando ya no se detecta una suscripción de Visual Studio?
R: Cuando un usuario ya no tiene una suscripción de Visual Studio, se trata como un nuevo usuario.
- Si el nivel de acceso predeterminado de la organización es Básico, se les asigna básico automáticamente.
- Si la organización estableció reglas de grupo, el usuario recibe el acceso especificado por su pertenencia a grupos.
- Si el usuario tiene una licencia de GitHub Enterprise, se le asigna GitHub Enterprise.
- De lo contrario, los usuarios que ya no tienen acceso a través de una suscripción de Visual Studio mantienen el acceso de las partes interesadas hasta que un administrador les asigne acceso de pago.
En febrero y marzo de 2026, si el nivel de acceso predeterminado de la organización o una regla de grupo proporcionan al suscriptor expirado el mismo nivel de acceso (por ejemplo, Basic para un suscriptor de Visual Studio Professional), se les asigna automáticamente un nuevo nivel de acceso. Sin embargo, si el usuario tiene acceso a Basic + Test Plans (por ejemplo, un suscriptor de Visual Studio Enterprise), pero el nivel de acceso predeterminado o la regla de grupo solo proporcionaría Basic, seguirá teniendo acceso con su nivel de acceso de suscriptor de Visual Studio.
A partir de abril de 2026, un usuario sin una suscripción activa de Visual Studio se degrada. Se les asigna un nuevo nivel de acceso en función del nivel de acceso predeterminado de la organización o las reglas de grupo aplicables. Si ninguna de las dos opciones se aplica, se marcan como no válidos con acceso de Stakeholder.
P: ¿Puedo automatizar la asignación de nivel de acceso antes de que expiren las suscripciones de Visual Studio?
R: Sí. Considere la posibilidad de actualizar el nivel de acceso predeterminado de la organización o establecer reglas de grupo para que los usuarios que pierdan acceso a una suscripción de Visual Studio o los nuevos usuarios que se unan a la organización puedan recibir automáticamente el acceso que necesitan sin intervención manual.
P: ¿Cómo se restaura el acceso a los usuarios que ya no tienen una suscripción activa de Visual Studio?
R: Asigne acceso Básico o Básico + Planes de prueba a los usuarios que ya no tienen una suscripción de Visual Studio:
Seleccione
Configuración de la organización>Usuarios.Seleccione el filtro Nivel de acceso y elija un tipo de suscripción no válido, como la suscripción de Visual Studio Enterprise (no válida).
Marque la casilla Todos.
Seleccione
Más acciones y Cambie el nivel de acceso.
Seleccione Básico o Básico + Planes de prueba.
Guarde los cambios.
GitHub Enterprise
P: ¿Qué clientes de GitHub Enterprise son aptos para el acceso a Azure DevOps?
R: Clientes de GitHub Enterprise Cloud que acceden a GitHub y Azure DevOps con el mismo inquilino de Microsoft Entra. Los usuarios deben iniciar sesión con la misma identidad en GitHub y Azure DevOps.
P: ¿Cómo se detectan los usuarios de GitHub Enterprise?
R: Azure DevOps comprueba automáticamente si un usuario tiene GitHub Enterprise cuando el usuario inicia sesión. Su nivel de acceso puede tardar hasta 24 horas en elevarse a GitHub Enterprise. No hay cargos por un usuario con el nivel de acceso de GitHub Enterprise.
P: ¿Cómo se identifican los usuarios de GitHub Enterprise en las regiones de residencia de datos?
R: Los clientes de regiones de residencia de datos habilitan la detección mediante la instalación de la aplicación Azure Boards y la vinculación de su instancia de ghe.com. Una vez configurado, los usuarios se detectan automáticamente.
P: ¿Qué tipo de acceso obtienen los usuarios de GitHub Enterprise en Azure DevOps?
R: Acceso básico, que incluye todas las características, excepto los planes de prueba. Para más información, consulte Precios de Azure DevOps.
P: ¿Qué ocurre si un usuario de GitHub Enterprise necesita acceso a los planes de prueba?
R: A los usuarios de GitHub Enterprise que necesitan acceso a los planes de prueba se les puede asignar el nivel de acceso Basic + Test Plans.
P: ¿Qué ocurre cuando ya no se detecta una licencia de GitHub Enterprise?
R: Cuando un usuario ya no tiene GitHub Enterprise, se trata como un nuevo usuario.
- Si el nivel de acceso predeterminado de la organización es Básico, se les asigna básico automáticamente.
- Si la organización estableció reglas de grupo, el usuario recibe el acceso especificado por su pertenencia a grupos.
De lo contrario, los usuarios que ya no tienen acceso a través de GitHub Enterprise mantienen el acceso de las partes interesadas hasta que un administrador les asigne acceso de pago.
En el ejemplo siguiente se muestra que la licencia ya no se detecta: 
P: ¿Cómo se restaura el acceso básico a los usuarios que ya no tienen una licencia de GitHub Enterprise?
R: Realice los pasos siguientes para restaurar el acceso básico a los usuarios que ya no tienen una licencia de GitHub Enterprise:
Seleccione
Configuración de organización.Seleccione Usuarios.
Seleccione el filtro Nivel de acceso y elija GitHub Enterprise (no válido).
Marque la casilla Todos.
Seleccione Administrar y cambiar el nivel de acceso.
Seleccione Básico y Guardar.
P: ¿Se detecta que los usuarios que usan GitHub Enterprise Server tienen GitHub Enterprise?
R: No, solo se detectan usuarios en la nube de GitHub Enterprise en Azure DevOps. Los clientes que usan GitHub Server pueden sincronizar el uso de licencias entre GitHub Enterprise Server y GitHub Enterprise Cloud.
P: ¿Qué nivel de acceso debo seleccionar si un usuario tiene una licencia de GitHub Enterprise?
R: Si sabe que un usuario tiene una licencia de GitHub Enterprise, la mejor opción para elegir es "Stakeholder" para evitar los cargos de "Basic" antes de que el usuario inicie sesión por primera vez.
P: ¿Qué ocurre si un usuario de GitHub Enterprise también tiene una suscripción de Visual Studio?
R: Si un usuario que accede a Azure DevOps tiene una suscripción de GitHub Enterprise y Visual Studio, se detecta como suscriptor de Visual Studio. Una suscripción de Visual Studio siempre proporciona el mismo acceso Básico y puede proporcionar acceso a los planes de prueba, en función del nivel de suscripción.
Acceso de usuario
P: ¿Qué significa "Último acceso" en la vista Todos los usuarios?
R: El valor de Last Access es la última fecha en que un usuario ha accedido a los recursos o servicios. El acceso a Azure DevOps incluye el uso de OrganizationName.visualstudio.com directamente y el uso de recursos o servicios indirectamente. Por ejemplo, puede usar la extensión Azure Artifacts o puede insertar código en Azure DevOps desde una línea de comandos o IDE de Git.
P: ¿Un usuario que paga por el acceso básico puede unirse a otras organizaciones?
R: No, un usuario solo puede unirse a la organización para la que el usuario pagó por el acceso básico. Pero un usuario puede unirse a cualquier organización en la que los usuarios gratuitos con acceso básico sigan estando disponibles. El usuario también puede unirse como usuario con acceso gratuito a las partes interesadas.
P: ¿Por qué los usuarios no pueden acceder a algunas características?
R: Asegúrese de que los usuarios tengan asignado el nivel de acceso correcto.
Aprenda a administrar usuarios y niveles de acceso para Azure DevOps.
Aprenda a cambiar los niveles de acceso de Azure DevOps Server.
Algunas características solo están disponibles como extensiones. Debe instalar estas extensiones. La mayoría de las extensiones requieren que tenga al menos acceso básico, no acceso de partes interesadas. Compruebe la descripción de la extensión en el Marketplace de Visual Studio, en la pestaña Azure DevOps.
Por ejemplo, para buscar en el código, puede instalar la extensión de búsqueda de código gratuita, pero necesita al menos acceso básico para usar la extensión.
Para ayudar a su equipo a mejorar la calidad de la aplicación, puede instalar la extensión gratuita Test & Feedback, pero obtendrá diferentes funcionalidades en función del nivel de acceso y si trabaja sin conexión o está conectado a Azure DevOps Services.
Algunos suscriptores de Visual Studio pueden usar esta característica de forma gratuita, pero los usuarios básicos deben actualizarse al acceso de Basic + Test Plans para poder crear planes de prueba.
- Aprenda a obtener extensiones para Azure DevOps.
- Obtenga información sobre cómo obtener extensiones para Azure DevOps Server.
- Aprenda a comprar acceso a Azure DevOps Server Test.
P: ¿Por qué un usuario pierde el acceso a algunas características?
R: Un usuario puede perder el acceso por los siguientes motivos (aunque el usuario puede seguir funcionando como parte interesada):
La suscripción de Visual Studio del usuario ha expirado. Mientras tanto, el usuario podrá trabajar como Parte interesada o podría conceder al usuario acceso Básico hasta que renueve su suscripción. Una vez que el usuario inicie sesión, Azure DevOps restaurará el acceso automáticamente.
La suscripción de Azure usada para la facturación ya no está activa. Todas las compras realizadas con esta suscripción se ven afectadas, incluidas las suscripciones de Visual Studio. Para corregir este problema, visite el Portal de cuentas de Azure.
La suscripción de Azure usada para la facturación se quitó de la organización. Para obtener más información, consulte Vinculación de la organización.
Su organización tiene más usuarios con acceso básico que el número de usuarios que paga en Azure. Su organización incluye cinco usuarios gratuitos con acceso básico . Si necesita agregar más usuarios con acceso básico, puede pagar por estos usuarios.
De lo contrario, en el primer día del mes natural, los usuarios que no han iniciado sesión en su organización durante el tiempo más largo pierden primero el acceso. Si su organización tiene usuarios que ya no necesitan acceso, elimínelos de su organización.
P: ¿Cómo hereda mi cuenta de usuario los permisos de otros grupos de Microsoft Entra?
R: Si un usuario está en más de un grupo de Microsoft Entra, un conjunto de permisos DENY en un grupo se aplica al usuario de todos los grupos en los que se encuentra el usuario. Dado que el permiso se establece en DENY para el usuario en el nivel más bajo posible, el uso del usuario del recurso se ve afectado en todos los grupos en los que se encuentran porque la denegación siempre tiene prioridad.
Por ejemplo, si un usuario está en el grupo Colaborador y en el grupo Administrador de proyectos y DENY está establecido para un permiso específico en el grupo Colaborador, también se deniega ese permiso para el usuario en el grupo Administrador de proyectos. En este escenario, puede usar la opción No establecer .
Para obtener más información sobre los estados de permisos, consulte Estados de permisos.
P: ¿Cómo quitar usuarios de Azure DevOps?
R: Consulte Cómo quitar usuarios de Azure DevOps.
P: He agregado un usuario a mi proyecto. ¿Por qué no puede ver el proyecto?
R: Verifique que el usuario no se agregue a un grupo en el que el permiso Ver información a nivel de proyecto no esté establecido o esté establecido en Denegar. Para más información, consulte Cambio de permisos de nivel de proyecto.
P: ¿Por qué no pueden los usuarios invitados buscar usuarios de Microsoft Entra?
R: De forma predeterminada, Acceso a través de las preguntas frecuentes de Microsoft Entra. Los invitados de Microsoft Entra no pueden buscar en el ID de Microsoft Entra de la manera requerida por Azure DevOps.
Cambio de las directivas de acceso a aplicaciones para su organización
P: ¿Puedo seguir usando PAT para la autenticación?
R: Sí, los tokens de acceso personal (PAT) siguen funcionando para la autenticación, pero los tokens de Microsoft Entra son la alternativa recomendada siempre que sea posible. Los tokens de Microsoft Entra son de corta duración (una hora), se administran automáticamente y reducen el riesgo de fugas de credenciales que los PAT de larga duración pueden introducir.
Si usa PAT para procesos automatizados o cuentas de servicio, tenga en cuenta estas alternativas más seguras:
- Tokens de Microsoft Entra - Úsalos en lugar de la mayoría de los PAT (tokens de acceso personal) para escenarios basados en el usuario. Para más información, consulte Autenticación en Azure DevOps con Microsoft Entra.
- Entidades de servicio. Utilice para aplicaciones y servicios que necesitan su propia identidad y permisos. Para obtener más detalles, consulte Uso de entidades de servicio e identidades administradas.
- Identidades administradas : use para cargas de trabajo que se ejecutan en recursos de Azure para eliminar completamente la administración de credenciales.
Para obtener una comparación completa de los métodos de autenticación, consulte Guía de autenticación.
P: Si deniego el acceso a un método de autenticación en una organización, ¿eso afecta a todas las organizaciones que posee?
R: No, todavía puede usar ese método en todas las demás organizaciones que posee. Los tokens de acceso personal se aplican a organizaciones específicas o a todas las organizaciones, en función de la selección al crear el token.
P: Si deniego el acceso a un método de autenticación, ¿seguirán funcionando las aplicaciones que necesitan acceso?
Organizations
P: Cómo quitarme de una organización cuando el propietario no está disponible para quitarme?
R: Para quitarse de una organización, siga estos pasos:
- Vaya a aex.dev.azure.com.
- Seleccione la organización y, a continuación, elija Salir.
- Confirme que desea abandonar la organización.
P: ¿Por qué no puedo crear una organización?
R: Póngase en contacto con el administrador para determinar si su organización usa la directiva de inquilinos de Microsoft Entra para restringir la creación de la nueva organización.
Licencias basadas en grupos
P: ¿Perderán mis usuarios el nivel de acceso y la pertenencia a proyectos si se quita una regla de grupo?
R: Los usuarios del grupo TestGroup pierden el acceso a los recursos de grupo si los usuarios no se han asignado explícitamente a los recursos o se han asignado a través de una regla de grupo diferente.
P: ¿Se eliminará mi grupo de Azure DevOps o Microsoft Entra si elimino su regla de grupo?
R: No. Los grupos no se eliminan.
P: ¿Qué hace la opción "Quitar <group> de todos los grupos de nivel de proyecto"?
R: Esta opción quita el grupo de Azure DevOps o Microsoft Entra de cualquier grupo predeterminado de nivel de proyecto, como lectores de proyectos o colaboradores del proyecto.
P: ¿Qué determina el nivel de acceso final si un usuario está en más de un grupo?
R: Los tipos de reglas de grupo se clasifican en el orden siguiente: Suscriptor > Básico + Planes de prueba > Básico > Partes interesadas. Los usuarios siempre obtienen el mejor nivel de acceso entre todas las reglas de grupo, incluida la suscripción de Visual Studio.
Vea los siguientes ejemplos, que muestran cómo la detección de suscriptores influye en las reglas de grupo.
Ejemplo 1: regla de grupo me proporciona más acceso.
Si tengo una suscripción de Visual Studio Pro y estoy en una regla de grupo que me da planes básicos y de prueba, ¿qué ocurre?
Esperado: obtengo Basic + Test Plans porque lo que la regla de grupo me da es mayor que mi suscripción.
Ejemplo 2: regla de grupo me da el mismo acceso.
Tengo una suscripción de Visual Studio Test Pro y estoy en una regla de grupo que me da acceso a Basic + Test Plans. ¿Qué ocurre?
Esperado: Se me detecta como suscriptor de Visual Studio Test Pro, porque el acceso es el mismo que la regla del grupo y ya estoy pagando por Visual Studio Test Pro, así que no quiero pagar de nuevo.
Agregar miembros a proyectos
P: ¿Por qué no puedo agregar más miembros a mi proyecto?
R: Su organización es gratuita para los cinco primeros usuarios con acceso básico. Puedes agregar Partes interesadas y suscriptores ilimitados de Visual Studio sin cargo adicional. Después de asignar los cinco usuarios gratuitos con acceso Básico, puede seguir agregando Partes interesadas y suscriptores de Visual Studio.
Para agregar seis o más usuarios con acceso Básico, debe configurar la facturación en Azure. A continuación, puede pagar por más usuarios que necesiten acceso básico, volver a su organización, agregar estos usuarios y asignarles acceso básico. Cuando se configura la facturación, se paga de forma mensual por el acceso de los usuarios adicionales. Puedes cancelar cuando quieras.
Si necesitas más suscripciones de Visual Studio, descubre cómo comprar suscripciones.
P: ¿Por qué no pueden iniciar sesión algunos usuarios?
R: Este problema puede ocurrir porque los usuarios deben iniciar sesión con cuentas de Microsoft a menos que su organización controle el acceso con el identificador de Microsoft Entra. Si su organización está conectada a Microsoft Entra ID, los usuarios deben ser miembros del directorio para obtener acceso.
Si es administrador de Microsoft Entra, puede agregar usuarios al directorio. Si no es administrador de Microsoft Entra, trabaje con el administrador de directorios para agregarlos. Obtenga información sobre cómo controlar el acceso de la organización con el identificador de Entra de Microsoft.
P: ¿Por qué algunos usuarios perdieron el acceso a determinadas características?
R: La pérdida de acceso puede ocurrir por diferentes motivos.
P: ¿Cómo quitar usuarios de mi organización?
R: Aprenda a eliminar usuarios en todos los proyectos de su organización. Si paga por más usuarios, pero ya no necesita acceso a su organización, debe reducir los usuarios de pago para evitar cargos.
P: ¿Por qué no puedo encontrar miembros de mi ID de Microsoft Entra conectado, aunque soy el administrador global?
R: Probablemente usted sea un invitado en la instancia de Microsoft Entra que sustenta Azure DevOps. De forma predeterminada, los invitados de Microsoft Entra no pueden buscar en Microsoft Entra ID, por lo que no están encontrando usuarios en su Microsoft Entra ID conectado para agregar a su organización.
En primer lugar, compruebe si es un invitado de Microsoft Entra:
Vaya a la sección Configuración de su organización. Mira la sección inferior de Microsoft Entra ID. Anote el inquilino que respalda la organización.
Inicie sesión en el nuevo Azure Portal portal.azure.com. Compruebe su perfil de usuario en la tenencia del paso 1. Compruebe el valor tipo de usuario que se muestra de la siguiente manera:
Si es invitado de Microsoft Entra, realice uno de los pasos siguientes:
- Haga que otro administrador de Azure DevOps, que no sea invitado de Microsoft Entra, administre los usuarios de Azure DevOps por usted. Los miembros del grupo Administradores de colecciones de proyectos dentro de Azure DevOps pueden administrar usuarios.
- Haga que el administrador de Microsoft Entra quite la cuenta del directorio conectado y lo lea. El administrador debe hacer que sea miembro de Microsoft Entra en lugar de un invitado. Consulte ¿Se pueden agregar usuarios de Microsoft Entra B2B como miembros en lugar de invitados?
- Cambie el tipo de usuario del invitado de Microsoft Entra mediante Microsoft Graph PowerShell. No se recomienda usar el siguiente proceso, pero funciona y permite al usuario consultar el identificador de Microsoft Entra desde Azure DevOps posteriormente.
Descargue e instale Microsoft Graph PowerShell.
PowerShell Install-Module -Name Microsoft GraphAbra PowerShell y ejecute los siguientes cmdlets.
a. Conéctese a Microsoft Entra ID:
PowerShell Connect-MgGraph -Scopes 'User.Read.All'b. Busque el objectId del usuario:
PowerShell Get-MgUser -Filter "UserPrincipalName eq '<YourUPN>'"c. Compruebe el atributo usertype de este usuario para ver si es un invitado o miembro:
PowerShell Get-MgUser -UserId <Id> -Property DisplayName, ID, UserPrincipalName, UserType | Select DisplayName, ID, UserPrincipalName, UserTyped. Cambie el tipo de usuario de miembro a invitado:
PowerShell Update-MgUser -UserID <replace the ID for the result of the command to search> -UserType Member
P: ¿Por qué los usuarios no aparecen o desaparecen rápidamente en Azure DevOps después de agregarlos o eliminarlos en el centro de usuarios?
R: Si experimenta retrasos en la incorporación de nuevos usuarios o en la rápida eliminación de usuarios ya eliminados de Azure DevOps (por ejemplo, en desplegables y grupos) después de agregarlos o eliminarlos, abra un informe de problemas en la Comunidad de Desarrolladores para que podamos investigar.
¿Por qué necesito elegir entre una "cuenta profesional o educativa" y una "cuenta personal"?
Elija una "cuenta profesional o educativa" o una "cuenta personal" al iniciar sesión con una dirección de correo electrónico (por ejemplo, jamalhartnett@fabrikam.com) que comparten ambas cuentas. Aunque ambas identidades usan la misma dirección de inicio de sesión, son independientes y tienen perfiles, configuraciones de seguridad y permisos diferentes.
Seleccione Cuenta profesional o educativa si usó esta identidad para crear la organización o iniciar sesión con ella anteriormente. El directorio de la organización en microsoft Entra ID autentica la identidad y controla el acceso a su organización.
Seleccione Cuenta personal si usó su cuenta Microsoft con Azure DevOps. El directorio global de las cuentas de Microsoft autentica su identidad.
¿Por qué no puedo iniciar sesión después de seleccionar "cuenta microsoft personal" o "cuenta profesional o educativa"?
Si la dirección de inicio de sesión la comparte su cuenta personal de Microsoft y su cuenta profesional o educativa, pero la identidad seleccionada no tiene acceso, no puede iniciar sesión. Aunque ambas identidades usan la misma dirección de inicio de sesión, son independientes y tienen perfiles, configuraciones de seguridad y permisos diferentes.
Para resolver este problema, cierre sesión completamente desde Azure DevOps e inicie sesión de nuevo con su otra identidad. Cerrar el explorador podría no cerrar la sesión por completo, por lo que debe completar los pasos siguientes:
Cierre todos los exploradores, incluidos los exploradores que no ejecutan Azure DevOps.
Abra una sesión de exploración privada o de incógnito.
Ir a
https://aka.ms/vssignout.Aparece el mensaje "Cerrar sesión en curso". Una vez finalizada la cierre de sesión, el explorador le redirige a la página web de Azure DevOps.
Tip
Si la página de cierre de sesión tarda más de un minuto, cierre el explorador e inténtelo de nuevo.
Inicie sesión en Azure DevOps y seleccione su otra identidad.
¿Cómo obtengo ayuda o soporte técnico para Azure DevOps?
Consulte Obtener soporte técnico y proporcionar comentarios.
Cambio entre cuentas en Azure Portal y Azure DevOps
P: Como administrador, ¿cómo puedo facilitar el cambio entre cuentas en Azure Portal y Azure DevOps?
R: La administración de varias cuentas puede ser complicada y lenta. Para simplificar el proceso, tenga en cuenta las siguientes acciones:
- Usar diferentes exploradores o perfiles: Usar diferentes exploradores web o perfiles de explorador para cada cuenta para mantener la sesión iniciada en varias cuentas simultáneamente sin cambiar hacia atrás y hacia delante.
- Usar exploración incógnita/privada: Usar una ventana de exploración privada o de incógnito para acceder temporalmente a una cuenta diferente sin afectar a la sesión actual.
- inicio de sesión único (SSO): Si es compatible con su organización, implemente el inicio de sesión único (SSO) para simplificar el proceso de inicio de sesión en todos los servicios de Azure.