Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
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 Ative 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 de DevOps do Azure
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 simplificar 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 Ative Directory, uma opção é criar grupos específicos do Ative Directory para gerenciar seus usuários, como um grupo de desenvolvedores e testadores para todos os projetos da 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 Ative Directory para serviços que não podem ser configurados para usar a conta do sistema Serviço de Rede como a conta de serviço. Para fazer isso, crie uma conta no Active Directory para a conta de acesso de leitura à fonte de dados para relatórios no SQL Server Reporting Services.
Importante
Se você decidir usar grupos do Ative Directory no Servidor de DevOps do Azure, considere criar grupos específicos cuja finalidade seja dedicada ao gerenciamento de usuários no Servidor de DevOps do Azure. Usar grupos previamente existentes que foram criados para outra finalidade, particularmente se eles forem gerenciados por outras pessoas que não estão familiarizadas com o Servidor de DevOps do Azure, pode levar a consequências inesperadas para o usuário quando a associação for alterada para dar suporte a alguma outra função.
A opção padrão durante a instalação é usar a conta do sistema do Serviço de Rede como a conta de serviço do Azure DevOps Server e do SQL Server. Se quiser utilizar uma conta específica como conta de serviço por motivos de segurança ou outras razões, como uma implantação ampliada, pode fazê-lo. Você também pode querer criar uma conta específica do Ative 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 Ative Directory, mas você não tiver permissões para criar grupos ou contas do Ative Directory, ou se estiver instalando o 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 os grupos e contas locais não são tão robustos quanto os grupos e contas de domínio. Por exemplo, no caso de uma falha do servidor, você precisaria recriar os grupos e contas do zero no novo servidor. Se você usar grupos e contas do Ative Directory, os grupos e contas serão preservados mesmo se o servidor que hospeda o Servidor de DevOps do Azure falhar.
Por exemplo, depois de analisar 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. Este grupo conterá a maioria dos utilizadores. Você pode nomear esse grupo TFS_ProjectContributors.
Um pequeno grupo de administradores de projeto 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 contratantes que só terão acesso a um dos projetos. Você pode nomear esse grupo TFS_RestrictedAccess.
Mais tarde, à medida que a implantação se expande, você pode decidir criar outros grupos.
Para criar um grupo no Ative Directory
- Crie um grupo de segurança que seja um domínio local, global ou grupo universal no Ative Directory, conforme melhor atenda às suas necessidades comerciais. 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 (Serviços de Domínio Ative Directory).
Para criar um grupo local no servidor
- Crie um grupo local e dê-lhe um nome que identifique rapidamente o seu propósito. Por padrão, qualquer grupo criado terá as permissões equivalentes ao grupo padrão Usuários nesse computador. Para obter mais informações, consulte Criar um grupo local.
Para criar uma conta para usar como uma conta de serviço no Ative Directory
- Crie uma conta no Ative Directory, defina a política de senha de acordo com seus requisitos comerciais e verifique se a opção Conta confiável para delegação está selecionada para a conta. Para obter mais informações, consulte Criar uma nova conta de usuário (Serviços de Domínio Ative Directory) e Noções básicas sobre contas de usuário (Serviços de Domínio Ative Directory).
Para criar uma conta local para usar como a conta de serviço no servidor
- Crie uma conta local para usar como conta de serviço e, em seguida, modifique sua associação ao 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 isso a seguir
Perguntas e Respostas
P: Posso usar grupos para restringir o acesso a projetos ou recursos no Servidor de DevOps do Azure?
Um: Sim, tu podes. 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.