O CREDSSP seria necessário neste cenário, alguém?
Estamos tentando se conectar a um servidor remoto via Powershell e usar o módulo ActiveDirectory. Ao tentar fazer isso localmente, tudo parece estar bem.
PS C:\Users\bar> Import-Module ActiveDirectory
PS C:\Users\bar> Get-ADUser 'baz'
DistinguishedName : CN=Foo Baz,OU=baz.myhost.com,OU=FooMachine,DC=foo,DC=blah,DC=loc
Enabled : True
GivenName : Baz
Name : Foo Baz
ObjectClass : user
ObjectGUID : <some guid>
SamAccountName : baz
SID : <more info here>
Surname : Baz
UserPrincipalName : baz@foo
Quando fazemos o samething remotamente, não temos muita sorte.
C:\> Enter-PSSession -ComputerName 172.1.2.3 -Credential foo\bar
[172.1.2.3]: PS C:\Users\bar\Documents> Import-Module ActiveDirectory
WARNING: Error initializing default drive: 'Unable to contact the server. This
may be because this server does not exist, it is currently down, or it does not
have the Active Directory Web Services running.'.
[172.1.2.3]: PS C:\Users\bar\Documents> Get-ADUser 'baz'
Unable to contact the server. This may be because this server does not exist, i
t is currently down, or it does not have the Active Directory Web Services runn
ing.
+ CategoryInfo :
+ FullyQualifiedErrorId : Unable to contact the server. This may be becaus
e this server does not exist, it is currently down, or it does not have th
e Active Directory Web Services running.,Microsoft.ActiveDirectory.Managem
ent.Commands.GetADUser
[172.1.2.3]: PS C:\Users\bar\Documents>
Christopher, temos controladores de domínio 2 - 2008 R2 em execução nesse domínio. O serviço da web do diretório ativo está sendo executado em ambos ("Import-Module ActiveDirectory" funciona bem no console do servidor - ele não é um controlador de domínio pela maneira
Aqui está um exemplo de como usar o CredSSP para resolver um problema similar. Eu testei isso, e ele funciona para resolver o erro do AD Web Services que você postou na sua pergunta.
Para resumir a partir do artigo, primeiro você precisa ativar o CredSSP no cliente e no servidor.
No cliente: Enable-WSManCredSSP -Role Client -DelegateComputer [computer name] -Force
No servidor: Enable-WSManCredSSP -Role Server –Force
Em seguida, você precisa obter ou fazer a credencial para se conectar à outra máquina e criar uma sessão que use essa credencial. Em seguida, você pode usar Invoke-Command para executar seus comandos / script do PowerShell em um bloco de script nessa nova sessão. Aqui está um exemplo parcial do artigo, usando os comandos da sua pergunta:
$credential = Get-Credential -Credential iammred\administrator
$session = New-PSSession -cn SQL1.Iammred.Net -Credential $credential -Authentication Credssp
Invoke-Command -Session $session -ScriptBlock { Import-Module ActiveDirectory; Get-ADUser 'baz' }
No entanto, isso interativamente pede suas credenciais, então, se você quiser evitar isso, precisará fazer algo parecido com isso com $credential :
$credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "DOMAIN\username",$pass;
em que $pass é uma string segura da senha associada à conta.
A partir deste link - link
Para usar o módulo do AD, além de ter uma máquina do Server 2008 R2 ou Windows 7 com o módulo AD PowerShell, se você não estiver executando servidores do Servidor 2008 R2, precisará:
Se você optar por um servidor AD Server 2003 ou 2008 com o complemento acima, você ainda precisará de um sistema Server 2008 R2 ou Windows 7 para poder utilizar o módulo AD. Usando o controle remoto do PowerShell, você seria capaz de usar qualquer sistema com o PowerShell v2 instalado para chamar os cmdlets do módulo AD remotamente, conforme descrito aqui:
você se conectou ao servidor usando um endereço IP. Dessa forma, o Kerberos não pode ser usado para autenticar (é por isso que você precisou usar credenciais). Então, quando o servidor tenta autenticar em seu nome, você se depara com um problema de segundo salto. O servidor não pode entregar as credenciais a terceiros, assim você recebe erros.
Seu cenário requer que você conecte o cliente via Kerberos ao servidor. Isso só é possível se o seu cliente for membro do domínio e você usar o nome do servidor e não o endereço IP dele.
Tobias www.powershell.com
Eu tive o mesmo problema com alguns dos nossos ambientes e o que funcionou foi uma alteração no firewall. Aparentemente, o ADWS usa porta 9389 que não era permitida no servidor que estava tentando administrar remotamente o DC usando o powershell. Uma vez que permitimos a porta, tudo está funcionando bem.