- Introdução
- Melhores práticas
- Tenant
- Contexto de Pastas
- Automações
- Processos
- Trabalhos
- Gatilhos
- Logs
- Monitoramento
- Filas
- Ativos
- Armazenar Buckets
- Test Suite - Orchestrator
- Outras configurações
- Integrações
- Robôs Clássicos
- Administração do host
- Sobre o nível do host
- Gerenciamento dos administradores do sistema
- Gerenciando Tenants
- Configurando notificações de e-mail do sistema
- Logs de auditoria para o portal do host
- Modo de Manutenção
- Administração da organização
- Solução de problemas
Tipos de conta
O UiPath Identity Server armazena contas locais e as funções atribuídas a elas, mas também valida qualquer conta de diretório usada no Orchestrator.
Uma conta que foi criada e pode ser gerenciada a partir do Identity Server por meio do Portal de gerenciamento é considerada local para o ecossistema da UiPath. Para contas locais, todos os atributos de conta, como nome e endereço de e-mail são armazenados no Identity Server.
As contas de usuário que se originam de um diretório fora do ecossistema da UiPath (por exemplo, do Azure Active Directory) são usuários de diretório. Essas contas podem acessar o Orchestrator e podem receber funções se você integrar com o diretório.
Para usuários de diretório, apenas as atribuições de funções e as configurações específicas do Orchestrator serão gerenciadas dentro do ecossistema da UiPath, no Identity Server e no Orchestrator, enquanto que o administrador do diretório externo gerencia atributos específicos de conta (nome, e-mail, associação ao grupo do diretório).
Há duas maneiras de conceder acesso ao Orchestrator para um usuário de diretório:
- Ao atribuir funções no Orchestrator ao usuário do diretório, nos referimos a ele como um usuário adicionado individualmente.
- Ao fazer login com uma conta que pertence a um grupo de diretório, que foi previamente adicionado ao Orchestrator, nos referimos a ele como um usuário autoprovisionado. Consulte Sobre os usuários para obter mais informações.
Independentemente de seu tipo, os usuários do diretório sempre herdam as funções dos grupos aos quais pertencem, se existirem no Orchestrator.
Grupos locais são entidades que são originadas no Identity Server e representam uma coleção de contas de usuário e robô. Você pode atribuir funções e licenças a grupos, em vez de atribuí-las a usuários individuais. Qualquer coisa atribuída a um grupo é atribuída automaticamente a todos os membros do grupo.
Uma entidade criada ao referenciar um grupo a partir do diretório vinculado na sua instância do Orchestrator. Todos os membros do grupo são possíveis usuários do Orchestrator. Todas as funções atribuídas a um grupo são herdadas pelos usuários que pertencem a ele, sejam provisionadas automaticamente, sejam adicionadas individualmente.
- Um usuário que pertence a vários grupos herda as funções de todos eles.
- Um usuário que pertence a vários grupos, além de ter sido atribuído a funções explicitamente, tem a combinação de todas as funções herdadas e atribuídas explicitamente.
O uso de grupos de diretórios habilita o acesso automático com as permissões de grupo, com base nos usuários que são adicionados ou removidos do grupo de diretórios (ao mudar de departamento, por exemplo) sem precisar gerenciar as permissões do usuário individualmente.
Exemplo
|
Grupos de diretório |
Direitos herdados |
Direitos explícitos |
|---|---|---|
|
Adicionados o grupo X com o conjunto X de direitos de acesso e o grupo Y com o conjunto Y de direitos de acesso. |
John Smith pertence aos grupos X e Y. Ele faz logon no Orchestrator.Seu usuário é provisionado automaticamente com os seguintes direitos: X, Y. |
Além dos conjuntos X e Y, John também recebeu a atribuição do conjunto Z explicitamente. John agora tem os seguintes direitos: X, Y, Z. A exclusão dos grupos X e Y deixa John com o Z. |
- Você não precisa de uma entrada de usuário explícita para fazer login no Orchestrator se você pertencer a um grupo que foi adicionado ao Orchestrator.
- Direitos de acesso herdados dependem do grupo do diretório associado. Se o diretório for excluído, também serão excluídos os direitos de acesso herdados.
- Os direitos de acesso explicitamente definidos são independentes do grupo de diretório. Eles persistem entre sessões, independentemente do estado do grupo.
As contas de Robô são úteis para quando você precisa executar processos de back-office não assistidos que não devem ser de responsabilidade de nenhum usuário específico. Esses são nossos equivalentes específicos de RPA de contas de serviço. Semelhante às contas que os serviços do Windows executam como identidades de aplicação no modelo OAuth, elas são uma identidade de não usuário a ser usada para executar processos não assistidos.
Trabalhando com contas de robôs
As contas de Robôs se comportam como contas de usuários em termos de permissões. No UiPath Orchestrator, você pode adicionar contas de robô e configurar permissões para elas da mesma forma que para qualquer outra conta.
As única diferenças em relação às contas de usuários são :
- contas de robô não têm permissão para nenhuma configuração de processo relacionada à interação
- não é necessário um endereço de e-mail para criar uma conta de robô.
Você pode encontrar e trabalhar com contas de robô de uma maneira geral da mesma forma que você trabalha com as contas de usuários:
-
Os administradores podem criar e gerenciar contas de robô na página Administrador > Contas e grupos — não na guia Usuários, mas sim na guia dedicada a Contas de robô.
As contas de Robô também podem ser incluídas em grupos e gerenciadas como parte do grupo.
- Ao atribuir funções no Orchestrator, a pesquisa de contas mostra as contas de usuários, grupos e também contas de robô para seleção.
Para pastas clássicas, quando você implanta manualmente um robô no Orchestrator, é criada automaticamente uma entidade de robô, visível na guia Robots.
Os usuários do Robot têm a Função de Robot atribuída a eles por padrão.
Uma conta de serviço é uma conta não humana usada para fornecer um contexto de segurança para executar cargas de trabalho que não envolvem a existência de uma conta humana, como autenticações de servidor para servidor. Nesses casos, o Orchestrator assume a identidade da conta de serviço.
Apenas uma conta de serviço é criada por instância do orquestrador, não é visível na interface do usuário e só pode ser identificada nas tabelas do banco de dados.
Não há informações de autenticação anexadas a esse tipo de conta e, como tal, não pode fazer login interativamente por meio de navegadores ou cookies.
Recomendamos não desativar ou excluir a conta de serviço, pois isso terá um impacto direto nas cargas de trabalho em execução.
