Configuração de delegação para ADFS/SAML, servidores de arquivos e DFS no Active Directory

 

Visão geral

Este artigo descreve as etapas de configuração de delegação para que o ADFS/SAML funcione corretamente com qualquer arquivo back-end e servidores DFS no Active Directory. Quando os compartilhamentos de arquivos estiverem localizados em um servidor diferente do Servidor MyWorkDrive (MWD), serão alcançados por meio de DFS ou os usuários serão autenticados usando ADFS/SAML, para passar corretamente os tokens do usuário para os compartilhamentos de arquivos de back-end, é necessário que o Servidor MyWorkDrive é confiável por quaisquer Servidores de Arquivos e Servidores DFS para delegação.

Tipos de Delegação

Existem dois tipos de delegação que você pode escolher para usar com o MyWorkDrive.

• Delegação restrita/Delegação restrita de Kerberos ou KCD
• Delegação restrita de Kerberos baseada em recursos (RBKCD)

A delegação restrita ou a delegação restrita de Kerberos (KCD) podem ser definidas por meio da interface do usuário do ADUC ou por meio do Powershell. É o tipo mais comum, usado nos casos em que você possui um único domínio sem trusts externos.
Com a Delegação Restrita, você está limitando o acesso a um serviço específico (no caso do MyWorkDrive, CIFS)
Com a delegação restrita de Kerberos (KCD), você está limitando o tipo de autenticação para Kerberos e o serviço para CIFS.

A delegação restrita de Kerberos baseada em recursos só pode ser definida por meio do Powershell. Com o RBKCD, você também especifica quais servidores (recursos) permitirão solicitações de acesso.
É mais comumente usado quando uma confiança externa está em uso (ou seja, há recursos em dois domínios diferentes que você está acessando, como um servidor MyWorkDrive e usuários no Domínio1, com compartilhamentos de arquivos no Domínio2.). Com um Trust, os recursos devem ser informados especificamente de onde aceitar solicitações de autorização, eles não aceitam solicitações de autorização entre domínios, a menos que especificamente autorizados. Saiba mais sobre a configuração de confiança em Este artigo.

Você pode aprender mais sobre os diferentes tipos de delegação nestes artigos
Visão geral da delegação restrita de Kerberos
Fazendo o segundo salto no PowerShell Remoting, que tem uma boa visão geral dos casos de uso para KCD e RBKCD
Delegação Kerberos, Uma boa discussão sobre a implementação de KCD/RBKCD

Esses artigos mencionam outras formas de autenticação, como credSSP e JEA, que não são usadas com o MyWorkDrive, e a delegação irrestrita, que não recomendamos devido às implicações de segurança.

Habilitar via MyWorkDrive

A partir do servidor MyWorkDrive 6.3, os scripts integrados auditarão para ver se a Delegação restrita está habilitada e se oferecerão para definir a delegação para você diretamente do MyWorkDrive.

Esta auditoria e oferta para corrigir está disponível na guia de compartilhamentos e no novo Painel de saúde (também um novo recurso do 6.3)
Esse recurso funciona com delegação restrita, definida com mais frequência por meio da configuração de delegação da GUI baseada em ADUC. Ele não detecta KCD/RBKCD e os avisos podem ser ignorados com segurança nesses casos.

Na lista de compartilhamentos, você pode observar um ícone de aviso de que a delegação é necessária, mas não está definida corretamente para um determinado compartilhamento ou compartilhamentos.

 

Clicar para editar o compartilhamento mostrará um aviso de delegação E um botão solicitando Adicionar delegação.

Clicar no botão “Adicionar delegação” exibirá uma mensagem sobre os requisitos da conta – você deve estar conectado ao MyWorkDrive como Administrador de domínio para usar o recurso de delegação automatizada. Se a conta com a qual você administra o MyWorkDrive não for um administrador de domínio, você pode continuar habilitando a delegação com uma das etapas descritas abaixo.

 

Os scripts integrados que auditam para ver se a delegação está habilitada e se oferecem para definir a delegação para você diretamente no MyWorkDrive também aparecem no novo Painel de saúde com a mesma oferta para definir o recurso de delegação.

Observe que o método automatizado pode não funcionar para todos os ambientes, principalmente aqueles que exigem uma forma específica de delegação, como KCD. Se o método automatizado não funcionar para você, revise as opções adicionais abaixo para obter o método mais adequado para seu ambiente.

Delegação Restrita

Configurando a delegação restrita via ADUC UI Active Directory Users and Computers

O método mais comum de configuração da delegação é por meio das propriedades do servidor MyWorkDrive em usuários e computadores do Active Directory. Configure a Delegação do Active Directory no objeto de computador do Servidor MyWorkDrive para adicionar quaisquer Servidores de Arquivos e Servidores DFS em sua organização.

– De um Controlador de Domínio – Gerenciador de Servidores – Ferramentas – Usuários e Computadores do Active Directory – Computadores – {selecione o computador onde o MWD está instalado} – Propriedades – Delegação – Confiar neste computador apenas para delegação a serviços especificados – Usar qualquer protocolo de autenticação – Adicionar – Usuários ou Computadores – {selecione o(s) computador(es) que contém os compartilhamentos de rede necessários e o(s) computador(es) com a função DFS instalada} – OK – Serviços disponíveis – selecione cifs – OK

Nós fortemente recomendo você NÃO SELECIONE a opção que diz "Confiar neste computador para delegação a qualquer servidor (somente Kerberos)". (delegação irrestrita) Nós fortemente recomendamos que você adote uma abordagem de acesso menos privilegiado especificando os servidores e serviços conforme descrito acima (delegação restrita). Você pode ler mais sobre como proteger seu diretório ativo e riscos de delegação em Petri. com e ADSecurity.org

Exemplo de configuração para permitir que o MWD confie na delegação por meio de File-Server1 e DFS-Server1: – MWD instalado no computador MYWORKDRIVE-SERVER1 – Servidor de compartilhamento de arquivos de rede: FILE-SERVER1 – Servidor DFS: DFS-SERVER1

Com Powershell

Também é possível atribuir delegação restrita ao CIFS por meio do Powershell, no entanto, é recomendável usar o método GUI por meio do ADUC.

Este exemplo de script criará uma matriz de todos os servidores de arquivos e habilitará a delegação para esses servidores de arquivos específicos no protocolo CIFS para o(s) servidor(es) MyWorkDrive

—

# Importar o módulo ActiveDirectory
ActiveDirectory do módulo de importação

# Crie uma matriz e atribua-a a uma variável. No componente @, adicione os nomes de seus servidores de arquivos ou
Servidores host #DFS.
$TargetComputers = @(“FileShare1”, “DFSshare1”)

# Percorre cada elemento do array e configura a delegação
ForEach ($Computer em $TargetComputers) {

# Conecte-se ao MyWorkDrive Server – substitua a frase “MWDServer” pelo nome netbios do seu
Servidor #MYWorkDrive. Se você tiver mais de 1, executará todo esse script mais de uma vez.
Get-ADComputer -Identity MWDServer

# Adicione o SPN CIFS do computador atual à lista de serviços que o FileServer pode delegar
Set-ADComputer -Identity MWDServer -Add @{'msDS-AllowedToDelegateTo'= “cifs/$Computer”}
}

—

Teste

Para testar qual delegação existe usando o Powershell, este comando fornecerá uma lista dos servidores de arquivos que confiam em seu servidor MyWorkDrive para delegação. No script abaixo, substitua “MWDServer” pelo nome netbios do seu servidor MyWorkDrive.

—

Get-ADComputer MWDSERVER -Propriedades msDS-AllowedToDelegateTo,Displayname | selecione Displayname -ExpandProperty msDS-AllowedToDelegateTo | lista de formatos

—

*Observe que leva pelo menos 15 minutos para os tíquetes do Kerberos serem reciclados e possivelmente mais tempo para o Active Directory propagar as alterações – Aguarde pelo menos 15 minutos antes de iniciar o teste de acesso.

Você pode usar os argumentos “purge” e “–li 0x3e7” com o klist commandon os servidores de arquivos e servidores MyWorkDrive para agilizar a parte de reciclagem, mas não achamos que seja particularmente eficaz.

Delegação restrita de Kerberos baseada em recursos

Alguns ambientes podem exigir o método de configuração alternativo, Delegação restrita de Kerberos baseada em recursos (RBKCD) .

Para clientes com vários domínios (confianças de domínio) ou aqueles que estão hospedando seu Active Directory no Azure AD Domain Services (isso não é o mesmo que o Azure AD), a delegação deve ser habilitada usando a delegação restrita baseada em recursos no powershell. O RBKCD é necessário para domínios confiáveis, pois é o único método de delegação seguro que oferece suporte à autenticação de salto duplo. Mais detalhes estão disponíveis neste Artigo da Microsoft. Alguns clientes em ambientes de alta segurança ou ao usar dispositivos de serviço de arquivo também podem exigir delegação restrita baseada em recursos.

As etapas de configuração do Powershell para domínios do Server 2012 ou superior estão localizadas no artigo da Microsoft sobre como habilitar a delegação restrita de Kerberos (KCD) em um domínio gerenciado e Como configurar a delegação do computador com powershell.

Um exemplo de comando do servidor MyWorkDrive para um servidor de arquivos e servidor MyWorkDrive é o seguinte:

 

Domínio único:

Set-ADComputer MyWorkDriveServer -PrincipalsAllowedToDelegateToAccount (Get-ADComputer FileServer)

 

Múltiplos Domínios onde o Servidor MyWorkDrive, Usuários ou Recursos estão em domínios diferentes:

No servidor Windows que hospeda os compartilhamentos de arquivos reais, que confiarão no servidor MyWorkDrive, execute um dos seguintes comandos powershell: onde $MyWorkDriveServer é o nome do servidor MyWorkDrive e $FileServer é o nome do servidor de arquivos que está inserindo seu domínio onde o O servidor MyWorkDrive está localizado em sua consulta na base de pesquisa ou usando o controlador de domínio especificado do qual o servidor MyWorkDrive é membro:

 

Controladores de domínio múltiplos/confiáveis e vários servidores MyWorkDrive:

É importante observar que a execução do comando Set-ADComputer no powershell irá apagar quaisquer entradas de delegação existentes e substituir com suas novas entradas. Se você já configurou a delegação para serviços existentes, isso pode ter consequências indesejáveis. Usando o método recomendado, você primeiro pesquisará as configurações de delegação existentes e incluirá esses servidores na entrada de delegação, preservando as configurações de delegação existentes enquanto adiciona novas configurações para seu servidor MyWorkDrive.

Você pode baixar um arquivo zip deste script PS1 aqui.

Aqui está o conteúdo do script:

—

#IMPORTANTE NOTA: Este script irá sobrescrever quaisquer configurações existentes de delegação baseada em recursos nos computadores de destino.
#Execute o seguinte comando para visualizar as configurações de delegação existentes e anexá-las à lista $MWDServer:
Get-ADComputer -Identidade $Computer -servidor $domain -Propriedades PrincipalsAllowedToDelegateToAccount

#A lista pode usar SIDs se for de um domínio confiável. Se você receber um SID, use o seguinte comando para traduzir o SID de
#o domínio confiável:
Get-ADComputer –Filter * | Onde-objeto {$_.SID –like “*1111”} | Select-Object –Nome da propriedade, SID
#roque “1111” pelos últimos 4 dígitos do SID

# Importar o módulo ActiveDirectory
ActiveDirectory do módulo de importação

# Crie uma matriz e atribua-a a uma variável
#TargetComputers é para a lista de servidores de arquivos e compartilhamentos DFS no ambiente.
#roque “FileShare1”, “DFSSHare1” pelos nomes netbios de seus compartilhamentos de arquivos e hosts DFS.
#Adicione quantos forem necessários.
#Domain é o seu nome de domínio no formato URL, ou seja, domínio.local
$TargetComputers = @(“FileShare1”, “DFSShare1”)
$Domain = “domain.tld”

$CurrentDelegation
$MWDServer1 = (Get-ADComputer -Identity MWDServer1)
$MWDServer2 = (Get-ADComputer -Identity MWDServer2)

# Loop através de cada arquivo/servidor DFS configurar delegação para o servidor MyWorkDrive
ForEach ($Computer em $TargetComputers) {

# Adicionar o recurso do computador atual à lista de serviços que o FileServer pode delegar
# o “-server domain.tld” pode ser removido se todos os servidores/computadores estiverem contidos no mesmo domínio; caso contrário, especifique o domínio.
Set-ADComputer -Identity $Computer -server $domain -PrincipalsAllowedToDelegateToAccount $MWDServer1, $MWDServer2

# Verifique se o valor do atributo inclui o MyWorkDrive Server. Se for de um domínio confiável, aparecerá como um SID.
Get-ADComputer -Identidade $Computer -servidor $domain -Propriedades PrincipalsAllowedToDelegateToAccount
} Base de pesquisa:
$MyWorkDriveServer= Get-ADComputer -Filter {Name -eq “MYWORKDRIVE-SERVER”} -SearchBase “DC=MWF,DC=local” -Server “mwf.local”
$FileServer= Get-ADComputer -Filter {Name -eq “FILE-SERVER”} -SearchBase “DC=MWF,DC=local” -Server “mwf.local”
Set-ADComputer $FileServer -PrincipalsAllowedToDelegateToAccount $MyWorkDriveServer

—

Teste

Para testar se suas alterações foram bem-sucedidas, execute o comando para visualizar as configurações de delegação da etapa 1 deste processo.
#Get-ADComputer -Identidade $Computer -servidor $domain -Propriedades PrincipalsAllowedToDelegateToAccount

Agora você deve ver as entradas pré-existentes junto com os novos recursos adicionados.

*Conforme observado anteriormente neste artigo, leva pelo menos 15 minutos para os tíquetes do Kerberos serem reciclados e possivelmente mais tempo para o Active Directory propagar as alterações – Aguarde pelo menos 15 minutos antes de iniciar o teste de acesso.

Você pode usar os argumentos “purge” e “–li 0x3e7” com o klist commandon os servidores de arquivos e servidores MyWorkDrive para agilizar a parte de reciclagem, mas não achamos que seja particularmente eficaz.

 

Conta de usuário de armazenamento dos serviços de domínio do Azure AD

Para habilitar a delegação com Azure AD Domain Services e uma conta de usuário de armazenamento, precisamos usar o comando powershell abaixo para definir a conta de usuário de armazenamento para confiar no computador servidor MyWorkDrive com permissão para delegar usando KCD. Também devemos mover a conta do computador do servidor MyWorkDrive e a(s) conta(s) de usuário para os compartilhamentos de arquivos do Azure das OUs padrão para uma OU personalizada. Os detalhes estão disponíveis em este artigo da Microsoft. A delegação não funcionará se as contas no Active Directory não forem removidas das UOs padrão.

OU
As contas para o computador servidor MyWorkDrive e os usuários de compartilhamentos de arquivos do Azure devem estar em uma OU personalizada onde você tem permissões para configurar o KCD baseado em recursos. Você não pode configurar o KCD baseado em recursos para uma conta de computador no contêiner interno AAD DC Computers.

Comandos Powersell
$ImpersonatingAccount = Get-ADComputer -Identity
Set-ADUser -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

Observe que, para StorageUserAccount, pode ser necessário usar o nome da conta SAM, não o nome/nome comum. Encontre o nome da conta SAM como o nome anterior ao Windows 2000 na guia da conta dos itens no ADUC ou com Get-ADUser no Powershell

Exemplo de Powershell

MWD01 – nome do servidor MyWorkDrive
SA_81e0bcb563 – SAMAccountName do Compartilhamento de Arquivos do Azure

$ImpersonatingAccount = Get-ADComputer -Identity MWD01
Set-ADUser SA_81e0bcb563 -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

 

Teste

Para verificar a delegação, execute o seguinte comando do powershell:

Get-ADComputer $MyWorkDriveServer -Propriedades * | Format-List -Property *delegat*,msDS-AllowedToActOnBehalfOfOtherIdentity

Ou

A partir do servidor MyWorkDrive 5.4 ou superior, você pode optar por executar os testes no painel de administração do servidor MyWorkDrive em cada compartilhamento usando nosso Compartilhar ferramenta de teste, em vez de entrar em um cliente como usuário.

Casos Especiais – DFS e AzureFiles

DFS

Ao usar o DFS com SSO e MyWorkDrive, você deve configurar a delegação para o servidor MyWorkDrive para os computadores/hosts DFS E os servidores de compartilhamento de arquivos.

IE, se você tiver os seguintes servidores

DFS1 DFS2

Configurado para compartilhar arquivos dos seguintes servidores de arquivos (dispositivos de armazenamento Windows ou AD Joined) FileShareSanJose FileShareHouston FileShareNewYork

Em seguida, todos os cinco membros do AD devem aparecer como aprovados para delegar via CIFS na guia Delegação do AD do Servidor MyWorkDrive

Arquivos do Azure

Quando você tiver concluído com êxito nosso guia de configuração para usar os Arquivos do Azure com MyWorkDrive, sua conta de armazenamento de arquivos do Azure será um membro do domínio. Esse membro de domínio precisa ser adicionado à Delegação para o servidor MyWorkDrive para que o SSO apresente adequadamente essa unidade como um compartilhamento para os usuários.

Solução de problemas

Se seus compartilhamentos estiverem em branco quando os usuários fizerem login via SSO, é provável que a Delegação não esteja configurada corretamente. Se você acredita que configurou corretamente a Delegação via KCD ou Active Directory, você pode usar o Powershell para testar se o servidor/dispositivo de compartilhamento de arquivos está aceitando corretamente a delegação. Isso informará se o usuário conectado pode acessar arquivos e pastas no compartilhamento de arquivos delegado.

Você pode usar um script Powershell muito simples para testar se a Delegação está configurada corretamente, usando uma técnica conhecida como “Double Hop”. Informações adicionais sobre este teste podem ser encontradas em https://4sysops.com/archives/solve-the-powershell-multi-hop-problem-without-using-credssp/ Para realizar este teste, você precisará de 3 máquinas em seu diretório ativo

• Cliente – pode ser qualquer máquina associada ao domínio; como uma estação de trabalho Windows 10. Você executará o comando Powershell da máquina.
• Servidor MyWorkDrive – o servidor que deve poder acessar o compartilhamento via delegação
• Servidor de Arquivos – o servidor que está definido para Delegação no Servidor MyWorkDrive.

Você também precisará saber o caminho de um compartilhamento no servidor de arquivos que contém arquivos, que o usuário conectado pode acessar. O comando powershell é Invoke-Command -ComputerName $MyWorkDriveServerName -ScriptBlock {Get-ChildItem -Path \\$FileServer\ShareName } Você substituirá $MyWorkDriveServerName pelo nome de rede do seu servidor MyWorkDrive. Você substituirá $FileServer\ShareName pelo servidor de arquivos e compartilhamento que deseja testar. O compartilhamento deve conter arquivos, aos quais você espera que o usuário tenha acesso. E execute o comando da estação de trabalho do cliente Exemplo Em nosso exemplo, estamos testando a delegação para um Linux Samba Share de dois servidores MyWorkDrive diferentes. Um servidor MyWorkDrive tem delegação definida, o outro não. Estamos testando a partir de um cliente Windows 10 no domínio. Delegação não configurada Neste teste, testaremos a delegação em um servidor em que intencionalmente não configuramos a delegação e esperamos um erro.

• Servidor MyWorkDrive: mwf-scott6
• Servidor de arquivos: ubuntu-samba
• Compartilhe: todos

Execute o Powershell no membro de domínio do Windows 10 e execute o seguinte comando Invoke-Command -ComputerName mwf-scott6 -ScriptBlock {Get-ChildItem -Path \\ubuntu-samba\everyone } Os resultados que obtemos são: Um erro informando que o caminho do arquivo não existe. A delegação não funcionou e nosso usuário não conseguiu acessar o compartilhamento. Nesse cenário, o compartilhamento aparecerá em branco quando o usuário fizer login no MyWorkDrive via SSO. Este é o resultado esperado, pois não configuramos a delegação. Também pode indicar que seu servidor de arquivos/dispositivo não está aceitando delegação, se configurado corretamente. Configuração de delegação Neste teste, testaremos a delegação em um servidor onde a delegação está configurada corretamente

• Servidor MyWorkDrive: mwf-scott5
• Servidor de arquivos: ubuntu-samba
• Compartilhe: todos

Execute o Powershell no membro de domínio do Windows 10 e execute o seguinte comando Invoke-Command -ComputerName mwf-scott5 -ScriptBlock {Get-ChildItem -Path \\ubuntu-samba\everyone } Os resultados que obtemos são: Uma lista de arquivos e pastas no diretório. A delegação funcionou e nosso usuário conseguiu acessar o compartilhamento.

Atualização do Windows de novembro de 2021

Os patches lançados pela Microsoft durante a Patch Tuesday de novembro de 2021 em 9 de novembro causam compartilhamentos em branco no login com SSO de maneira semelhante a não ativar corretamente a delegação. O problema foi resolvido com patches no final de novembro e finalmente corrigido nos Roll Ups de dezembro e janeiro.

A partir de meados de 2022, não deverá haver mais casos disso, pois essas atualizações não são mais relevantes.

Incluímos esta informação para fins de arquivo

Se os Logins aparecerem repentinamente em branco em uma instalação existente do MyWorkDrive que anteriormente funcionava bem, você precisará corrigir o patch com falha, veja este artigo para detalhes.

Se você estiver configurando o SSO pela primeira vez no servidor MyWorkDrive, consulte o artigo para obter detalhes sobre como aplicar a correção aos seus controladores de domínio, além de configurar a delegação conforme descrito abaixo.
A correção do patch fornecida pelo Windows Update deve ser aplicada manualmente. Sem adicionar a correção para o patch do Windows Update, os logins resultarão em compartilhamentos em branco.