Использование defaultAuthenticationType с PowerShell Web Access
Веб-доступ 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.
Кто-нибудь смог успешно установить это? Веб-результатов очень не хватает.
1 ответ
Попробуйте следовать этому руководству, оно должно привести вас туда, куда вы хотите. 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.