- 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
- Almacenar credenciales de robots en CyberArk
- Almacenamiento de contraseñas de robot desatendido en Azure Key Vault (solo lectura)
- Almacenar las credenciales de robots desatendidos en HashiCorp Vault (solo lectura)
- Almacenamiento de credenciales de Unattended Robot en AWS Secrets Manager (solo lectura)
- Eliminar sesiones desconectadas y sin respuesta no atendidas
- Autenticación de Robot
- Autenticación de robots con credenciales de cliente
- Asignar roles
- Gestionar roles
- Roles por defecto
- Configuring access for accounts
- Habilitación de usuarios para ejecutar automatizaciones personales
- Habilitación de usuarios para ejecutar automatizaciones en infraestructura desatendida por medio de robots desatendidos
- Configuración de cuentas de robot para ejecutar automatizaciones desatendidas
- 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
- Administración de host
- Servidor de identidad
- Autenticación
- Administración de la organización
- Otras configuraciones
- Integraciones
- Robots clásicos
- Solución de problemas
Tipos de cuenta
Here's an overview of the different account types available in the UiPath platform, helping you understand and manage identities within the platform. Identities can come in the form of user accounts, robot accounts, external applications, and groups.
All objects or individual ones can be viewed and managed from their dedicated tabs.
Una cuenta ya creada y que se puede gestionar desde Orchestrator, a través del Portal de gestión, se considera local en el ecosistema de UiPath.
Para las cuentas locales, todos los atributos de la cuenta, como el nombre y la dirección de correo electrónico, se almacenan en Identity Server.
Las cuentas de usuario que se originan en un directorio fuera del ecosistema UiPath (por ejemplo, desde Azure Active Directory) son usuarios de directorio. Estas cuentas pueden acceder a Orchestrator y pueden recibir roles si se integra con el directorio.
Para los usuarios de directorio, solo se gestionan las asignaciones de roles y los ajustes específicos de Orchestrator dentro del ecosistema UiPath, en Identity Server y Orchestrator. El administrador del directorio externo gestiona los atributos específicos de la cuenta (nombre, correo electrónico, pertenencia a un grupo de directorio).
Hay dos maneras de que un usuario del directorio obtenga acceso a Orchestrator:
- Un administrador asigna roles a su cuenta de directorio en Orchestrator; a esto se le denomina cuenta añadida de manera individual.
- Un administrador añade la cuenta de directorio a un grupo y el usuario inicia sesión con su cuenta de directorio.
- Un administrador de Orchestrator añade un grupo de directorio a un grupo local y, a continuación, un administrador de directorio añade la cuenta de usuario al grupo de directorio, lo que se denomina cuenta autoaprovisionada.
Independientemente de su tipo, la cuenta de directorio siempre hereda los roles de los grupos a los que pertenece, si existen en Orchestrator.
Los grupos locales son entidades que se originan en Identity Server y que representan una colección de cuentas de usuarios y robots. Se pueden asignar roles y licencias a grupos en lugar de asignarlos a usuarios individuales. Todo lo que se asigna al grupo se asigna automáticamente a todos los miembros del grupo.
Una entidad creada mediante la referencia a un grupo de un directorio vinculado en tu instancia de Orchestrator. Todos los miembros del grupo son usuarios potenciales de Orchestrator. Todos los roles asignados a un grupo son heredados por los usuarios que pertenecen a ese grupo, autoaprovisionados o agregados individualmente.
- Un usuario que pertenece a varios grupos hereda los roles de todos ellos.
- Un usuario que pertenece a varios grupos, y al que también se le han concedido roles explícitamente, tiene la unión de todos los roles heredados y asignados explícitamente.
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.
Las cuentas de los robots son útiles para cuando se necesita ejecutar procesos desatendidos de administración que no deben ser responsabilidad de ningún usuario en particular. Se trata de nuestro equivalente de cuentas de servicio específicas de RPA. Al igual que las cuentas que los servicios de Windows ejecutan como identidades de aplicación en el modelo OAuth, son una identidad de no usuario que se utiliza para ejecutar procesos desatendidos.
Trabajar con cuentas de los robots
Las cuentas de los robots se comportan como las cuentas de los usuarios en cuanto a permisos. En UiPath Orchestrator, se pueden añadir cuentas de robot y configurar los permisos para ellas del mismo modo que para cualquier otra cuenta.
Las únicas diferencias con respecto a las cuentas de usuario son:
- las cuentas de los robots no pueden configurar ningún proceso relacionado con la interactividad
- no se requiere una dirección de correo electrónico para crear una cuenta de robot.
Puedes encontrar y trabajar con las cuentas de los robots prácticamente de la misma manera que trabajas con las cuentas de los usuarios:
-
Los administradores de la organización pueden crear y gestionar las cuentas de los robots desde la página Admin > Cuentas y grupos, pero no desde la pestaña Usuarios, sino desde la pestaña Cuentas de robot dedicada.
Las cuentas de los robots también pueden incluirse en grupos y administrarse como parte del grupo.
- Al asignar roles en Orchestrator, la búsqueda de cuentas muestra usuarios, grupos y también cuentas de robots para su selección.
En las carpetas clásicas, al implementar manualmente un robot en Orchestrator, 
se crea automáticamente y se puede ver en la pestaña Robots .
Los usuarios de UiPath Robot tienen asignado el rol de Robot de forma predeterminada.
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.
