No post Administração de usuários e grupos no TFS/VSTS, foi descrito o funcionamento do cadastro de usuários e grupos. Em seguida um administrador do TFS/VSTS precisa entender como dar permissões para, usuários ou grupos, para que possam executar ações ou não, ou seja, liberar funções ou restringir.

O administrador do TFS deve dominar essas ferramentas, pois pode poupar um bom trabalho na admistração, tanto em uma migração como no dia a dia.

Níveis de acesso e suas ferramentas de configuração

O TFS/VSTS não tem uma ferramenta única de permissionamento, ao longo do temos é possível identificar uma consolidação no Web Portal, porém é possível realizar a configuração de permissão através de outras ferramentas, algumas de maneira exclusiva, como é o caso do Release Management, pelo menos até a versão atual, ou do Lab Management.

Na figura abaixo temos os diferentes níveis de acesso e quais ferramentas permitem a sua configuração.

Perceba que através do Web Portal ou com a TFSSecurity, uma ferramenta de linha de comando, é possível abrager a maioria dos níveis, fazendo a maior parte das configurações de permissões.

Built-in

Ao instalar o TFS, ou criar uma conta no VSTS, alguns grupos são criados, como os grupos locais do Windows ou do AD, são os built-in, não é possível apagá-los, e eles já tem permissões pré-definidas, que podem ser alteradas. O ideal é manter esses grupos da maneira que são criados, e para a exceções criar novos grupos.

Por exemplo, para adicionar um novo desenvolvedor em um Team Project, colocando-o em [Team Project]Contributors todas as permissões para a tarefas de produção de código já estarão setadas.

Estados das permissões

No post mencionado no início deste você encontra o significado para cada estado das permissões, resumidamente:

• Allow e Deny, são Permitir e Negar, respectivamente
• Inherited allow/Inherited deny, é quando o estado é herdado
• Not set, implicitamente é um Deny, mas se o usuário pertencer a outro grupo que tenha Allow será permitido

Alguns pontos interessantes:

• O TFS/VSTS usa a permissão mais restritiva, então se o usuário estiver em dois grupos, com Allow e no outro Deny, o último irá se sobrepor a primeiro, e o usuário estará negado. Exceto:
  • Quando foi em uma hierarquia, por exemplo:
    • Pastas do TFVC, é possível permitir acesso a uma pasta filha mesmo a pai estando negada
    • Repositórios Git
    • Area e Iteration
    • WIT shared querys e pastas de querys
  • Quando o usuário pertencer a um grupo de administradores, por exemplo Project Collection Administrators ou Team Foudation Administrators
• Inherit allow tem precedência sobre Not set.

Relatório

Não existe um relatório pronto para visualização das permissões configuradas, como os relatórios padrão de cada template de processo. Porém, pouco mais de um ano atrás os ALM Rangers lançaram um projeto para cobrir esse gap no produto, já que várias instituições precisavam de uma ferramenta para auditoria dos acessos ao TFS.

Permissions Extraction Tool, vem com o código e é preciso compilar para utilizá-lo pela primeira vez. O projeto foi movido para o Github, para baixar acesse:

https://github.com/ALM-Rangers/Extracting-effective-permissions-from-TFS

Leia o Whitepaper aqui.

A ferramenta é para console e bem simples de utilizar, os parâmetros são:

• –collection=<URL da TPC>
• –users=<user01> <user02>, domainuser para TFS ou e-mail para VSTS
• –f=<logfile>, o usuário é adicionado ao arquivo de log
• –html, além do XML gera o relatório em HTML

No próximo post sobre administração de usuários veremos a ferramenta de console TFSSecurity.

Emmanuel Brandão