Використання defaultAuthenticationType за допомогою веб-доступу PowerShell

Веб-доступ PowerShell дозволяє вибрати тип аутентифікації. За замовчуванням він використовує значення Default, яке в кінцевому підсумку є Negotiate. Я встановив CredSSP, щоб дозволити вхід на сам сервер PSWA за допомогою CredSSP, щоб мережна автентифікація працювала зсередини сеансу (уникає проблеми подвійного переходу, без делегування облікових даних по всій мережі).

У будь-якому випадку, я хочу, щоб CredSSP був типовим параметром на сторінці входу.

Розглядаючи параметри конфігурації веб-програми PSWA в IIS, є кілька значень, які можна встановити, щоб змінити значення за замовчуванням.

Один з них називається, defaultAuthenticationTypeякий є, stringале встановлений 0.

Це здається правильним налаштуванням, але я не можу змусити його працювати.

Якщо я перевіряю веб-сторінку входу, я можу побачити, що у полі вибору є такі значення:

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

3 відсутня.

JosefZ виявив, що 3це NegotiateWithImplicitCredentialзгідно з цією сторінкою , але для Windows PowerShell 5.1.15063.966 для мене це ім'я / значення відсутнє у переліку.

Якщо я встановив defaultAuthenticationTypeчисло, то веб-сторінка за замовчуванням нова опція:

7   Admin Specified

Я спробував 3і 4, але жоден не працює. Вхід відбувається за допомогою Kerberos, а CredSSP не використовується.

Якщо я виберу CredSSP вручну, він працює як очікувалося.

Якщо я встановив defaultAuthentcationTypeтакий рядок CredSSP, Admin Specifiedпараметр не з'являється, і він просто за замовчуванням Defaultзнову, і все-таки використовується автентифікація Kerberos.

Хтось міг успішно встановити це? Веб-результатів дуже бракує.

спробуйте, дотримуючись цього посібника, воно повинно вас перевести туди, куди ви хочете піти. 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.