- Primeros pasos
- Mejores prácticas
- Tenant
- Acerca del contexto de tenant
- Buscar recursos en un tenant
- Gestionar robots
- Conexión de los robots a Orchestrator
- Ejemplos de configuración
- Almacenar credenciales de robots en CyberArk
- Configuración de los robots atendidos
- Configuración de los robots desatendidos
- Almacenamiento de contraseñas de robot desatendido en Azure Key Vault (solo lectura)
- Almacenar las credenciales de robots desatendidos en HashiCorp Vault (solo lectura)
- Eliminar sesiones desconectadas y sin respuesta no atendidas
- Autenticación de Robot
- Autenticación de robots con credenciales de cliente
- Autenticación por SmartCard
- Auditoría
- Servicio de catálogo de recursos
- Contexto de carpetas
- Automatizaciones
- Procesos
- Trabajos
- Desencadenadores
- Registros
- Supervisión
- Colas
- Activos
- Depósitos de almacenamiento
- Test Suite - Orchestrator
- Otras configuraciones
- Integraciones
- Robots clásicos
- Administración de host
- Acerca del nivel del host
- Gestionar los administradores del sistema
- Gestión de tenants
- Configuración de las notificaciones por correo electrónico del sistema
- Registros de auditoría para el portal del host
- Modo de mantenimiento
- Administración de la organización
- Solución de problemas
Gestión de las capacidades de acceso y automatización
El nivel de acceso y las acciones que sus usuarios pueden realizar se controlan mediante dos elementos:
- cuentas, que establecen la identidad de un usuario y se utilizan para iniciar sesión en tus aplicaciones UiPath.
- roles, que se asignan a las cuentas para concederles determinados permisos en el ecosistema UiPath.
Las cuentas las crean y las gestionan los administradores de la organización. Las cuentas ya deben existir para poder asignarles roles.
Esta página, y las siguientes páginas, describen:
- cómo gestionar los roles
- cómo gestionar las capacidades de automatización, que se configuran como parte de la configuración de roles.
Una cuenta es una entidad de la plataforma UiPath con capacidades que dependen del acceso y cuya vista y control de Orchestrator dependen de los derechos de acceso asignados.
Las cuentas pueden:
-
creadas y gestionadas localmente (cuentas locales)
- crearse y gestionarse en un directorio externo (cuentas de directorio y grupos de directorio). Consulta la sección Integración de AD a continuación para obtener una mejor comprensión de las integraciones de directorios.
Las cuentas se añaden desde el portal de gestión de la organización y solo están disponibles dentro de la organización correspondiente.
Una vez que se ha añadido una cuenta satisfactoriamente, hay dos formas de concederle derechos de acceso a Orchestrator: añadiendo la cuenta a un grupo para que herede los roles del grupo, o asignando roles a cada cuenta a nivel de servicio. Puedes utilizar ambos métodos para tener un control detallado del acceso que tiene una cuenta en tu organización.
Un directorio activo (AD) referenciado en Orchestrator hace que sus miembros sean usuarios potenciales de Orchestrator. El nivel de acceso de una cuenta de directorio se configura en Orchestrator, ya sea a nivel de grupo (grupo de directorio) o de usuario (usuario de directorio).
Puedes integrarte con:
- un Active Directory local
-
Azure Active Directory
Nota: El uso de una integración AD junto con el autoaprovisionamiento de robots attended y carpetas jerárquicas permiten configurar fácilmente grandes implementaciones. Consulta Gestión de grandes implementaciones para obtener más información.
Requisitos previos
- El parámetro
WindowsAuth.Domain
se rellena con un dominio válido. Todos los dominios y subdominios de los bosques de confianza bidireccional con el dominio especificado en el parámetroWindowsAuth.Domain
están disponibles al añadir usuarios/grupos. - La máquina en la que está instalado Orchestrator se une al dominio establecido en el parámetro
WindowsAuth.Domain
. Para comprobar si el dispositivo está asociado al dominio, ejecutadsregcmd /status
desde el símbolo del sistema del sistema y dirígete a la sección Estado del dispositivo. - La identidad bajo la que se ejecuta el grupo de aplicaciones de Orchestrator debe formar parte del grupo de acceso de autorización de Windows (WAA).
Comportamiento
- Al añadir un grupo de directorio se crea una entidad de grupo de usuarios en Orchestrator para la que se configuran los derechos de acceso de la manera deseada. Esta entrada en Orchestrator sirve como referencia al grupo tal y como se encuentra en AD.
- Al iniciar sesión, Orchestrator comprueba la pertenencia a los grupos. Si se confirma, aprovisiona automáticamente tu cuenta de usuario, y luego se asocia a los derechos de acceso heredados del grupo. Los derechos heredados solo se conservan durante la sesión de usuario.
- Se realiza el aprovisionamiento automático la primera vez que inicias la sesión. Una cuenta de usuario aprovisionada automáticamente no se elimina al cerrar la sesión, ya que podrías necesitar la entrada para fines de auditoría.
-
Orchestrator comprueba la pertenencia a un grupo de una cuenta al iniciar la sesión o bien, cada hora durante las sesiones activas. Si la pertenencia a un grupo de una cuenta cambia, los cambios se aplicarán la próxima vez que la cuenta se conecte o, si ya se ha conectado, en el plazo de una hora.
Este intervalo de una hora para comprobar la pertenencia al grupo puede cambiarse estableciendo el valor de IdentityServer.GroupMembershipCacheExpireHours .
- Los grupos en AD se sincronizan con Orchestrator, si bien los cambios realizados en Orchestrator no afectan a la configuración de los usuarios en AD.
- Los usuarios de AD cuyos derechos de acceso heredados (de la pertenencia a un grupo) no pueden determinarse se comportan como usuarios locales, lo que significa que dependen únicamente de los roles asignados a la cuenta de usuario.
- La única forma de configurar derechos de acceso que persistan entre sesiones, independientemente de los cambios en la pertenencia a un grupo, es asignar directamente el rol a la cuenta de usuario en Orchestrator, en lugar de utilizar grupos para asignar roles.
Problemas conocidos
- Debido a diversos problemas de red o de configuración, existe la posibilidad de que no todos los dominios mostrados en el Nombre de dominio estén accesibles.
- Los cambios realizados en los nombres de usuarios o grupos en AD no se propagan a Orchestrator.
- La actualización de la lista de dominios con los nuevos dominios de confianza bidireccionales puede tardar hasta una hora.
- Las solicitudes
GetOrganizationUnits(Id)
yGetRoles(Id)
solo devuelven carpetas y roles establecidos explícitamente para un usuario aprovisionado automáticamente. Los heredados de la configuración del grupo pueden recuperarse a través del punto final/api/DirectoryService/GetDirectoryPermissions?userId={userId}
. - Lo mismo vale para la interfaz de usuario, donde solo se muestran carpetas y roles establecidos de forma explícita en la página Usuarios. En contraste, los heredados tienen una nueva ubicación independiente, la ventana Permisos de usuario (Usuarios > Más acciones > Comprobar permisos).
- Los usuarios no heredan la configuración de la suscripción a las alertas del grupo principal, ni reciben ninguna alerta de forma predeterminada. Para tener acceso a las alertas deberás otorgar los permisos correspondientes al usuario explícitamente.
- Eliminar un grupo de directorio no elimina la licencia de un usuario de directorio asociado, incluso si la eliminación del grupo quita al usuario de cualquier carpeta. La única forma de eliminar la licencia es cerrar la bandeja de Robots.
- En ciertos navegadores, iniciar sesión en Orchestrator utilizando tus credenciales de AD solo requiere tu nombre de usuario. No hace falta especificar también el dominio. Por tanto, si la sintaxis dominio/nombre de usuario no funciona, intenta rellenar solo el nombre de usuario.
Consideraciones de auditoría
- Membresía de usuario: el usuario [username] se asignó a los siguientes grupos de directorio [Grupos de directorio de los que el usuario hereda derechos de acceso en la sesión actual].
- Aprovisionamiento automático: el usuario [username] será aprovisionado automáticamente de los siguientes grupos de directorio [Grupos de directorio de los que el usuario hereda derechos de acceso en la sesión actual].
Grupo
Los grupos te permiten gestionar varios usuarios a la vez, aplicándoles las mismas funciones y la misma configuración a través del grupo.
-
La condición de miembro de un usuario se establece desde Admin > Cuentas y grupos.
-
Los grupos de usuarios permiten el acceso automático con los permisos de grupo, según los usuarios que se hayan añadido o eliminado del grupo sin necesidad de administrar los permisos de usuario de forma individual.
-
Hay 4 grupos locales predeterminados: administradores, usuariosde automatización, desarrolladoresde automatización y todos. Todos los grupos vienen con un conjunto de permisos predeterminado en cada nuevo servicio que creas. Los roles listos para usar se pueden personalizar más adelante para cada servicio de Orchestrator.
-
Si necesitas más niveles aparte de los 4 predeterminados proporcionados por UiPath, puedes crear grupos de usuarios personalizados. A diferencia de los grupos locales predeterminados, los grupos personalizados deben añadirse manualmente en Orchestrator para garantizar la correcta asignación entre la pertenencia a un grupo de un usuario y el rol correspondiente en Orchestrator.
Los roles de un grupo se transmiten a todos los usuarios que pertenecen al grupo, tanto los autoaprovisionados como los que se han añadido manualmente. Se denominan "roles heredados" en contraposición a los "roles asignados directamente", que solo pueden definirse por cuenta.
- Un usuario que pertenece a varios grupos hereda derechos de acceso de todos ellos.
- Un usuario que pertenece a varios grupos, y al que también se le han asignado funciones directamente, tiene la unión de todas las funciones heredadas de los grupos y asignadas directamente.
- No es necesario tener una cuenta de usuario explícita para acceder a Orchestrator si se pertenece a un grupo que se ha añadido a Orchestrator.
- Los roles heredados dependen del grupo de usuarios asociado. Si el grupo se elimina del servicio, también se eliminan los roles heredados de esa cuenta.
- Las funciones asignadas directamente no se ven influidas por los grupos a los que pertenece la cuenta. Persisten con independencia del estado del grupo.
Ejemplo
Por ejemplo, añado a John Smith a los grupos de Usuarios de automatización y Administradores en mi organización de Automation Cloud.
- El grupo Usuarios de automatización existe en el servicio de Finanzas de Orchestrator
- El grupo de Administradores existe en el servicio de RR. HH. de Orchestrator
- Asignación directa de roles a la cuenta de John en ambos servicios.
John tiene la unión de los derechos heredados y explícitos para cada servicio:
Servicio/Roles |
Grupos de usuario |
Roles heredados |
Roles explícitos |
Descripción general |
---|---|---|---|---|
Tenant definanzas |
Automation User | |||
Roles de tenant |
|
|
|
|
Roles de carpeta |
|
|
|
|
Tenant derecursos humanos |
Administradores | |||
Roles de tenant |
|
|
| |
Roles de carpeta |
|
|
|
|
Usuario
Según el mecanismo utilizado para añadir cuentas de usuario en Orchestrator, se pueden clasificar en dos categorías:
Usuarios añadidos manualmente
Usuarios que se han añadido manualmente a Orchestrator y a los que se le han otorgado permisos explícitos a nivel de tenant o de carpeta. Las cuentas de usuario añadidas manualmente heredan derechos de acceso de grupo si pertenecen a un grupo que también se ha añadido a ese servicio de Orchestrator.
Usuarios aprovisionados automáticamente
Usuarios que se han añadido a un grupo local y que inician sesión en Orchestrator. Pueden acceder a Orchestrator según los permisos heredados del grupo. Una vez que hayan iniciado sesión en Orchestrator por primera vez, se aprovisionan automáticamente.
Puedes comprobar todos permisos de un usuario, incluyendo los heredados, desde la ventana Más acciones > Comprobar permisos > Permisos de usuario, específica para dicho usuario.
Usuario añadido manualmente |
Usuario aprovisionado automáticamente | |
---|---|---|
Hereda derechos de acceso |
|
|
Puede tener derechos de acceso explícitos |
|
|
Cloud Portal es el núcleo central de información de usuarios |
|
|
SSO |
|
|
Robot
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. Este rol le otorga a tu Robot acceso a múltiples páginas, permitiéndole realizar diversas acciones.
En las páginas en las que se gestionan las cuentas, los grupos o los roles, se muestran iconos específicos para cada tipo para ayudarte a reconocer el tipo de cuenta o el tipo de grupo.
Iconos de la cuenta
- Cuenta de usuario UiPath: cuenta de usuario que está vinculada a una cuenta UiPath y que ha iniciado sesión mediante autenticación básica
- Cuenta de usuario SSO: cuenta de usuario vinculada a una cuenta UiPath que ha iniciado sesión mediante SSO; también se aplica a las cuentas de usuario que tienen tanto una cuenta de usuario UiPath como una cuenta de directorio
- Cuenta de usuario de directorio: la cuenta se origina en un directorio y se registra con Enterprise SSO
: Cuenta de robot
Iconos del grupo
: grupo local (o simplemente, grupo): el grupo fue creado por un administrador de host.
: Grupo de directorio: el grupo se origina en un directorio vinculado.
Orchestrator utiliza un mecanismo de control de acceso basado en roles y permisos. Los roles son colecciones de permisos, lo que significa que los permisos necesarios para utilizar determinadas funciones de Orchestrator están incluidos en los roles.
Por ejemplo, se muestra un rol personalizado en el que se pueden ver algunos de los permisos incluidos:
Hay dos tipos de permisos, de la siguiente manera:
- Los permisos de tenant definen el acceso de un usuario a los recursos en el nivel de tenant.
- Los permisos de carpeta definen el acceso y la capacidad del usuario dentro de cada carpeta a la que se asignan.
- Permisos de carpeta (tenant en el ámbito):
- permitir a un usuario crear, editar o eliminar todas las carpetas dentro de todo el tenant.
- normalmente se conceden a administradores o usuarios responsables de gestionar la organización.
- Permisos de subcarpeta (carpeta en ámbito):
- permitir a un usuario crear, editar o eliminar una carpeta en particular a la que están asignados, junto con cualquier subcarpeta bajo ella.
- ofrecen control más granular, permitiendo a los usuarios gestionar carpetas específicas sin tener control sobre las otras carpetas en el tenant.
Según los permisos que incluyan, existen tres tipos de roles:
- Roles de tenant, que incluyen permisos de tenant, y se requieren para trabajar en el nivel de tenant.
- Roles de carpeta, que incluyen permisos para trabajar dentro de una carpeta.
-
Roles mixtos, que incluyen ambos tipos de permisos.
Con los roles mixtos, para una operación global, solo se tienen en cuenta los permisos de tenant del usuario. Para una operación específica de carpeta, si se define un rol personalizado, los permisos de carpeta se aplican en favor de cualquier permiso de tenant presente.
Nota: los roles mixtos ya no son compatibles y no puedes crear otros nuevos. Si tienes roles mixtos, recomendamos reemplazarlos con una combinación de los roles de tenant y carpetas para otorgar los permisos necesarios.
Los siguientes recursos están disponibles para los usuarios según el tipo de roles que tengan:
Recursos de tenant |
Recursos de carpeta |
---|---|
|
|
UiPath.Orchestrator.dll.config
.
El tipo de rol es importante porque los roles se asignan de forma diferente en función de su tipo, y también depende de si las carpetas clásicas están habilitadas:
-
Si la opción Activar las carpetas clásicas está desactivada en Tenant > Configuración > General:
- Las funciones de los tenants y las funciones mixtas se asignan desde la pestaña Asignar roles o Roles de la página Tenant > Gestionar accesos.
- Las funciones de las carpetas y las funciones mixtas se asignan desde la página Carpetas o desde la página Configuración de la carpeta.
-
Si la opción Activar las carpetas clásicas está desactivada en Tenant > Configuración > General:
- La asignación de cualquiera de los tres tipos de roles se realiza desde las pestañas Asignar roles o Roles de la página Tenant > Gestionar accesos.
- Las funciones de las carpetas y las funciones mixtas se asignan desde la página Carpetas o desde la página Configuración de la carpeta.
Normalmente se pueden seleccionar todos los derechos disponibles (Ver, Editar, Crear o Eliminar) para cualquier permiso, aunque los siguientes derechos no tienen efecto sobre el permiso indicado y, por lo tanto, no se pueden editar:
Tipo de permiso |
Permiso |
Derechos no disponibles |
---|---|---|
Tenant |
Alertas |
|
Auditoría |
| |
Carpeta |
Medios de ejecución |
|
Registros |
| |
Supervisión |
|
Esto se debe a que, por ejemplo, no es posible editar los registros generados por el sistema.
Para poder realizar varias operaciones en las páginas Usuarios y Roles, deberás tener los permisos correspondientes:
- Ver en Usuarios: permite la visualización de las páginas Usuarios y Perfil.
- Editar en Usuarios: permite editar los detalles y la configuración del usuario en la página Perfil, así como activar/desactivar usuarios en la página Usuarios.
- Usuarios - Ver y Roles - Ver : muestra los permisos de usuario en la ventana Permisos de usuario.
- Editar en Usuarios y Ver en Roles: permite editar asignaciones de rol en la página Gestionar accesos > Asignar roles.
- Crear en Usuarios y Ver en Roles: permiten crear un usuario.
- Ver en Usuarios y Editar en Roles: permiten gestionar roles en la ventana Gestionar usuarios, que se abre desde la página Gestionar accesos > Roles.
- Eliminar en Usuarios: permite eliminar un usuario de Orchestrator.
De forma predeterminada, Orchestrator no permite el acceso de los usuarios a través de la autenticación básica. Esta funcionalidad puede habilitarse añadiendo y configurando los ajustes Auth.RestrictBasicAuthentication. Esto te permite crear cuentas locales que pueden acceder a Orchestrator usando tus credenciales de autenticación básica, lo que te permite mantener las integraciones existentes que dependían de la autenticación básica al llamar a la API de Orchestrator.
La activación de la autenticación básica puede hacerse al crear y editar cuentas.
Por defecto, después de 10 intentos fallidos de inicio de sesión, se bloquea durante 5 minutos.
Los administradores del sistema pueden personalizar la configuración Bloqueo de cuenta desde el portal de gestión del host.