Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Azure DevOps Server |Azure DevOps Server |Azure DevOps Server 2022 | Azure DevOps Server 2020
Gerenciar usuários no Azure DevOps Server é muito mais fácil se você criar grupos do Windows ou do Active Directory para eles, especialmente se sua implantação incluir o SQL Server Reporting Services.
Usuários, grupos e permissões em implantações do Servidor do Azure DevOps
O Azure DevOps Server e o SQL Server Reporting Services mantêm suas próprias informações sobre grupos, usuários e permissões. Para tornar mais simples o gerenciamento de usuários e permissões nesses programas, você pode criar grupos de usuários com requisitos de acesso semelhantes na implantação, conceder a esses grupos acesso apropriado nos diferentes programas de software e, em seguida, apenas adicionar ou remover usuários de um grupo, conforme necessário. Isso é muito mais fácil do que manter usuários individuais ou grupos de usuários separadamente em três programas separados.
Se o servidor estiver em um domínio do Active Directory, uma opção é criar grupos específicos do Active Directory para gerenciar seus usuários, como um grupo de desenvolvedores e testadores para todos os projetos na coleção de projetos ou um grupo de usuários que podem criar e administrar projetos na coleção. Da mesma forma, você pode criar uma conta do Active Directory para serviços que não podem ser configurados para usar a conta do sistema de Serviço de Rede como a conta de serviço. Para fazer isso, crie uma conta do Active Directory para a conta de origem de dados com acesso de leitura para relatórios no SQL Server Reporting Services.
Importante
Se você decidir usar grupos do Active Directory no Azure DevOps Server, considere a criação de grupos específicos cuja finalidade seja dedicada ao gerenciamento de usuários no Azure DevOps Server. Usar grupos anteriormente existentes que foram criados para outra finalidade, especialmente se forem gerenciados por outras pessoas que não estão familiarizados com o Servidor do Azure DevOps, pode levar a consequências inesperadas do usuário quando a associação muda para dar suporte a alguma outra função.
A opção padrão durante a instalação é usar a conta do sistema de Serviço de Rede como a conta de serviço do Azure DevOps Server e do SQL Server. Se você quiser usar uma conta específica como a conta de serviço para fins de segurança ou outros motivos, como uma implantação escalonada, você pode. Talvez você também queira criar uma conta específica do Active Directory para usar como a conta de serviço para a conta de leitor de fonte de dados do SQL Server Reporting Services.
Se o servidor estiver em um domínio do Active Directory, mas você não tiver permissões para criar grupos ou contas do Active Directory ou se estiver instalando seu servidor em um grupo de trabalho em vez de um domínio, poderá criar e usar grupos locais para gerenciar usuários no SQL Server e no Azure DevOps Server. Da mesma forma, você pode criar uma conta local para usar como a conta de serviço. No entanto, tenha em mente que grupos e contas locais não são tão robustos quanto grupos de domínio e contas. Por exemplo, no caso de uma falha de servidor, você precisaria recriar os grupos e contas do zero no novo servidor. Se você usar grupos e contas do Active Directory, os grupos e contas serão preservados mesmo se o servidor que hospeda o Servidor do Azure DevOps falhar.
Por exemplo, depois de examinar os requisitos de negócios para a nova implantação e os requisitos de segurança com os gerentes de projeto, você pode decidir criar três grupos para gerenciar a maioria dos usuários na implantação:
Um grupo geral para desenvolvedores e testadores que participarão totalmente de todos os projetos na coleção de projetos padrão. Esse grupo conterá a maioria dos usuários. Você pode nomear esse grupo TFS_ProjectContributors.
Um pequeno grupo de administradores de projetos que terão permissões para criar e gerenciar projetos na coleção. Você pode nomear esse grupo TFS_ProjectAdmins.
Um grupo especial e restrito de empreiteiros que só terão acesso a um dos projetos. Você pode nomear esse grupo TFS_RestrictedAccess.
Posteriormente, à medida que a implantação se expande, você pode decidir criar outros grupos.
Para criar um grupo no Active Directory
- Crie um grupo de segurança que seja um domínio local, global ou um grupo universal no Active Directory, conforme melhor atender às suas necessidades de negócios. Por exemplo, se o grupo precisar conter usuários de mais de um domínio, o tipo de grupo universal atenderá melhor às suas necessidades. Para obter mais informações, consulte Criar um novo grupo (Active Directory Domain Services).
Para criar um grupo local no servidor
- Crie um grupo local e dê a ele um nome que identificará rapidamente sua finalidade. Por padrão, qualquer grupo criado terá as permissões equivalentes do grupo padrão Usuários nesse computador. Para obter mais informações, consulte Criar um grupo local.
Para criar uma conta a ser usada como uma conta de serviço no Active Directory
- Crie uma conta no Active Directory, defina a política de senha de acordo com seus requisitos de negócios e verifique se a conta é confiável para delegação está selecionada para a conta. Para obter mais informações, consulte Criar uma nova conta de usuário (Active Directory Domain Services) e noções básicas sobre contas de usuário (Active Directory Domain Services).
Para criar uma conta local a ser usada como a conta de serviço no servidor
- Crie uma conta local para usar como conta de serviço e modifique sua associação de grupo e outras propriedades de acordo com os requisitos de segurança para sua empresa. Para obter mais informações, consulte Criar uma conta de usuário local.
Tente isto a seguir
Perguntas e Respostas
P: Posso usar grupos para restringir o acesso a projetos ou recursos no Servidor do Azure DevOps?
Um: Sim, você pode. Você pode criar grupos específicos para conceder ou restringir o acesso a recursos, funções e projetos selecionados, para gerenciar níveis de acesso e outras finalidades.