Używanie defaultAuthenticationType z PowerShell Web Access

Dostęp do sieci PowerShell pozwala wybrać typ uwierzytelnienia. Domyślnie używa wartości Default, która ostatecznie jest Negotiate. Skonfigurowałem CredSSP, aby umożliwić logowanie się do samego serwera PSWA za pomocą CredSSP, aby uwierzytelnianie sieciowe działało z poziomu sesji (pozwala uniknąć problemu podwójnego przeskoku, bez delegowania poświadczeń w całej sieci).

W każdym razie chcę, aby CredSSP była domyślną opcją na stronie logowania.

Przyglądając się opcjom konfiguracji aplikacji internetowej PSWA w IIS, istnieje kilka wartości, które można ustawić w celu przesłonięcia wartości domyślnych.

Jeden z nich nazywa się defaultAuthenticationTypeco jest string, ale jest ustawiony 0.

To wydaje się właściwe ustawienie, ale nie mogę go uruchomić.

Jeśli sprawdzę stronę logowania, widzę, że pole wyboru ma następujące wartości:

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

3 brakuje.

JosefZ stwierdził, że 3jest to NegotiateWithImplicitCredentialzgodne z tą stroną , ale w Windows PowerShell 5.1.15063.966 dla mnie tej nazwy / wartości brakuje w wyliczeniu.

Jeśli ustawię defaultAuthenticationTypeliczbę, strona domyślnie przyjmuje nową opcję:

7   Admin Specified

Próbowałem 3i 4żadne z nich nie działa. Logowanie odbywa się przy użyciu Kerberos, a CredSSP nie jest używany.

Jeśli ręcznie wybiorę CredSSP, będzie działać zgodnie z oczekiwaniami.

Jeśli ustawię defaultAuthentcationTypeciąg podobny do CredSSP, żadna Admin Specifiedopcja nie pojawi się, a domyślnie zostanie ustawiona Defaultponownie i nadal będzie używane uwierzytelnianie Kerberos.

Czy ktoś był w stanie to ustawić? Brakuje wyników w sieci.

spróbuj postępować zgodnie z tym przewodnikiem, aby dostać się tam, gdzie chcesz. https://www.petri.com/powershell-web-access-configuration

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.