- Primeros pasos
- Mejores prácticas
- Tenant
- Acciones
- Contexto de carpetas
- Automatizaciones
- Procesos
- Trabajos
- Desencadenadores
- Registros
- Supervisión
- Colas
- Activos
- Depósitos de almacenamiento
- Test Suite - Orchestrator
- Catálogos de acciones
- Perfil
- Administrador de sistema
- Servidor de identidad
- Autenticación
- Otras configuraciones
- Integraciones
- Robots clásicos
- Solución de problemas
Tipos de usuario
Los usuarios locales solo se pueden crear en Orchestrator. Los atributos como el nombre y el correo electrónico se gestionan en Orchestrator, junto con los roles y otros ajustes específicos de Orchestrator. Se utiliza para iniciar sesión en Orchestrator, tener una vista personalizada de Orchestrator, en función de tu posición dentro del equipo de automatización y, de forma opcional, para recibir alertas de correo electrónico. No puedes cambiar el nombre de usuario de este tipo de usuario.
Los usuarios locales se añaden creando el usuario, estableciendo sus atributos, y asignando roles. Dos páginas contienen información relativa al usuario: la página Usuario y la página Perfil. Al rellenar cualquiera de las dos se sobrescribe la información correspondiente en la otra (nombre, apellidos, dirección de correo electrónico).
Hay dos maneras de convertir a los usuarios locales que inician sesión con las credenciales AD en usuarios de directorio:
- Establece el parámetro WindowsAuth.ConvertUsersAtLogin en
True
. Esto convierte a cada usuario de AD local en un usuario de directorio después del primer inicio de sesión con credenciales de AD. - Mediante el siguiente script. Esto convierte a todos los usuarios locales de AD que han iniciado sesión con credenciales de AD a la vez.
Esta función solo es válida para los usuarios que se conectan a través de la página de Inicio de sesión de Orchestrator. No funciona para los usuarios que se registran a través de Studio, utilizando el Inicio de sesión interactivo.
DECLARE @domain VARCHAR(100) = 'your-domain-name-here'
UPDATE u
SET
u.[UserName] = CONCAT(u.[UserName], '@', lower(@domain)),
u.[Type] = 2
FROM
[dbo].[Users] u
JOIN [dbo].[UserLogins] l ON u.[Id] = l.[UserId]
WHERE
u.[Type] = 0
AND l.[LoginProvider] = 'Windows'
AND u.[IsDeleted] = 0
DECLARE @domain VARCHAR(100) = 'your-domain-name-here'
UPDATE u
SET
u.[UserName] = CONCAT(u.[UserName], '@', lower(@domain)),
u.[Type] = 2
FROM
[dbo].[Users] u
JOIN [dbo].[UserLogins] l ON u.[Id] = l.[UserId]
WHERE
u.[Type] = 0
AND l.[LoginProvider] = 'Windows'
AND u.[IsDeleted] = 0
En el caso de los usuarios del directorio, solo se gestionan en Orchestrator las funciones y la configuración específica de Orchestrator, mientras que el administrador del directorio externo gestiona los atributos específicos del usuario (nombre, correo electrónico, pertenencia a un grupo).
Se puede crear un usuario de directorio de dos maneras:
- Al añadir un usuario AD por sí mismo, nos referimos a él como usuario añadido de forma individual.
- Al iniciar sesión con un usuario perteneciente a un grupo AD previamente añadido, nos referimos a él como usuario aprovisionado automáticamente. Consulta más información en la página Acerca de los usuarios.
Los usuarios del directorio siempre heredan los derechos de acceso del grupo principal si este existe en Orchestrator.
Acceso |
Usuario local | Usuario del directorio |
---|---|---|
Hereda los derechos de acceso |
|
|
Puede tener derechos de acceso explícitos |
|
|
AD es el hub central de la información de usuario |
|
|
SSO |
|
|
Una entidad de usuario creada haciendo referencia a un grupo de AD en tu instancia de Orchestrator. Todos los miembros del grupo son usuarios potenciales de Orchestrator. Todos los derechos de acceso establecidos para un grupo se pasan a cualquier usuario de directorio que pertenezca al grupo, sean aprovisionados automáticamente o añadidos individualmente. Los llamamos «derechos de acceso heredados» en lugar de «derechos de acceso explícitos» que solo pueden establecerse individualmente por usuario.
- Un usuario que pertenezca a varios grupos heredará los derechos de acceso de todos ellos.
- Un usuario que pertenezca a varios grupos, y al que también se le hayan otorgado derechos de acceso de forma explícita, disfruta del conjunto de todos los derechos heredados de sus grupos principales y de los que se le hayan otorgado de forma explícita.
El uso de grupos de directorio permite el acceso automático con los permisos del grupo, en función de los usuarios que se añadan o eliminen del grupo de directorio (por ejemplo, al cambiar departamento) y sin necesidad de gestionar los permisos de usuario de forma individual.
Ejemplo
Grupos del directorio |
Derechos heredados |
Derechos explícitos |
---|---|---|
Se ha añadido el grupo X con un conjunto de derechos de acceso X y el grupo Y con un conjunto de derechos de acceso Y. |
John Smith pertenece tanto al grupo X como al Y. Se conecta a Orchestrator. Su usuario está autoaprovisionado con los siguientes derechos: X, Y. |
Además de los conjuntos X e Y, a Juan también se le concede explícitamente el conjunto Z. Juan tiene ahora los siguientes derechos: X, Y, Z. La eliminación de los grupos X e Y deja a Juan con Z. |
- No necesitas una entrada de usuario explícito para iniciar sesión en Orchestrator si perteneces a un grupo añadido a Orchestrator (paso 1: sección Comportamiento).
- Los derechos de acceso heredados dependen del Grupo de directorio asociado. Si se borra el directorio, también se eliminan los derechos de acceso heredados.
- Los derechos de acceso establecidos explícitamente son independientes del Grupo de Directorio. Persisten entre sesiones, independientemente del estado del grupo.
El usuario Robot se crea automáticamente cuando implementas manualmente un Robot en Orchestrator. Los usuarios de UiPath Robot tienen el rol Robot de forma predeterminada.
El rol Robot otorga acceso a tus Robots a varias páginas, lo que permite realizar diversas acciones. Consulta aquí los permisos exactos del rol Robot.
Una cuenta de servicio es una cuenta no humana que se utiliza para proporcionar un contexto de seguridad para ejecutar cargas de trabajo que no implican la existencia de una cuenta humana, como las autenticaciones de servidor a servidor. En estos casos, Orchestrator asume la identidad de la cuenta de servicio.
Solo se crea una cuenta de servicio por instancia de Orchestrator; no es visible en la interfaz de usuario y solo se puede identificar en las tablas de la base de datos.
No hay información de autenticación adjunta a este tipo de cuenta y, como tal, no puede iniciar sesión de forma interactiva a través de navegadores o cookies.
Recomendamos no deshabilitar o eliminar la cuenta de servicio, ya que esto tendrá un impacto directo en las cargas de trabajo en ejecución.