Веб-доступ 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.