Usando defaultAuthenticationType com o PowerShell Web Access

Question

O acesso à Web do PowerShell permite escolher o tipo de autenticação. Por padrão, ele usa um valor de Default , que acaba sendo Negotiate . Configurei o CredSSP para permitir o login no próprio servidor PSWA com o CredSSP, para que a autenticação de rede funcionasse na sessão (evita um problema de salto duplo, sem delegar credenciais por toda a rede).

De qualquer forma, quero que o CredSSP seja a opção padrão na página de login.

Examinando as opções de configuração do aplicativo da Web PSWA no IIS, há vários valores que podem ser definidos para substituir os padrões.

Um deles é chamado defaultAuthenticationType , que é string , mas está definido como 0 .

Esta parece ser a configuração certa, mas não consigo fazer funcionar.

Se eu inspecionar a página da web de login, poderei ver que a caixa de seleção tem os seguintes valores:

0   Default
1   Basic
2   Negotiate
4   CredSSP
5   Digest
6   Kerberos

3 está faltando.

JosefZ descobriu que 3 é NegotiateWithImplicitCredential de acordo com esta página , mas no Windows PowerShell 5.1.15063.966 para mim esse nome / valor está faltando no enum.

Se eu definir defaultAuthenticationType para um número, a página da web será padronizada para uma nova opção:

7   Admin Specified

Eu tentei 3 e 4 , mas nenhum deles funciona. O login acontece usando o Kerberos e o CredSSP não é usado.

Se eu selecionar CredSSP manualmente, isso funciona como esperado.

Se eu definir defaultAuthentcationType como uma string como CredSSP , nenhuma opção Admin Specified será exibida e o padrão será Default novamente, e ainda será usada a autenticação Kerberos.

Alguém conseguiu definir isso com sucesso? Os resultados da Web têm sido muito deficientes.

    

Answer 1

tente seguir este guia para chegar onde você quer ir. link

here is the section you want. 
PowerShell
1
Add-PswaAuthorizationRule : This command must be run by a user account with permissions to perform Active Directory queries.
If you run the command in an interactive (i.e. not via remoting) session on the server it should work just fine. The problem here is the second hop. The Add-PSwaAuthorizationRule cmdlet needs to make a connection to a domain controller, which by security design is not allowed in PowerShell Remoting. This second-hop limitation can be overcome by enabling CredSSP authentication. Note: This is not be done lightly as there are security ramifications, so research this fully before employing.

But in my situation, since I want to use remoting, I’ll exit out of the remote session and enable CredSSP on my desktop for CHI-WEB01.

PowerShell
1
PS C:\> Enable-WSManCredSSP -DelegateComputer chi-web01 -Role Client
Next, I need to enable the server side.

PowerShell
1
PS C:\> invoke-command {enable-wsmancredssp -Role Server -Force} -ComputerName chi-web01
With this in place, I can now re-establish my remote session specifying CredSSP and my credentials.

PowerShell
1
PS C:\> enter-pssession chi-web01 -Authentication Credssp -Credential globomantics\jeff
Now when I run the authorization command, it works as you can see below in Figure 3.