Включить делегирование учетных данных пользователя windows 10 - Доктор Windows

Имеется сервер виртуализации Hyper-V Server 2016 и клиентское рабочее место на Windows 10 Pro. После установки RSAT требуется получить доступ через диспетчер Hyper-V к серверу виртуализации. Оба компьютера находятся в рабочей группе Workgroup.
Пингуются оба. Настройки производил следующим образом:

На клиентском месте:

winrm quickconfig
Служба WinRM уже выполняется на этом компьютере.
Служба WinRM уже настроена для удаленного управления на этом компьютере.

winrm set winrm/config/client '@{TrustedHosts="hyper-v_server"}'

Client
NetworkDelayms = 5000
URLPrefix = wsman
AllowUnencrypted = false
Auth
Basic = true
Digest = true
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = true [Source="GPO"]
DefaultPorts
HTTP = 5985
HTTPS = 5986
TrustedHosts = hyper-v_server

Set-Item WSMan:localhostClientTrustedHosts -Value "hyper-v_server"

Данная команда изменяет список TrustedHosts для клиента WinRM. Возможно, не будет проверяться подлинность компьютеров,
указанных в списке TrustedHosts. Также возможно, что клиенты будут отправлять на эти компьютеры учетные данные. Вы
действительно хотите изменить этот список?
[Y] Да - Y [N] Нет - N [S] Приостановить - S [?] Справка (значением по умолчанию является "Y"): y

Enable-WSManCredSSP -Role client -DelegateComputer "hyper-v_server"

Настройка проверки подлинности CredSSP для службы WS-Management
При проверке подлинности CredSSP разрешена отправка на удаленный компьютер учетных данных пользователей на данном
компьютере. Если проверка подлинности CredSSP используется при подключении к компьютеру, который содержит вредоносные
программы или к которому осуществляется несанкционированный доступ, то этот компьютер получит доступ к имени
пользователя и паролю. Дополнительные сведения см. в разделе справки для команды Enable-WSManCredSSP.
Вы хотите включить проверку подлинности CredSSP?
[Y] Да - Y [N] Нет - N [S] Приостановить - S [?] Справка (значением по умолчанию является "Y"): y

cfg : http://schemas.microsoft.com/wbem/wsman/1/config/client/auth
lang : ru-RU
Basic : true
Digest : true
Kerberos : true
Negotiate : true
Certificate : true
CredSSP : CredSSP

Где hyper-v_server — сетевое имя компьютера сервера виртуализации

В групповых политиках Конфигурация компьютера -> Административные
шаблоны -> Система -> Передача учетных данных -> Разрешить передачу новых учетных данных с проверкой подлинности сервера «только NTLM» Добавил строку:

wsman/hyper-v_server

В свойствах компьютерах через команду dcomcnfg.exe
изменил ограничения права доступа, добавил разрешения к группе анонимного доступа к удаленному подключению.

Далее смотрю результат работы команды:

Get-WSManCredSSP
Параметры компьютера позволяют делегировать новые учетные данные следующим конечным объектам: wsman/hyper-v_serv
er;wsman/hyper-v_server;
В настройках компьютера не разрешено получение учетных данных от удаленных клиентских компьютеров.

На сервере виртуализации ввел команды:

Enable-PSRemoting Enable-WSManCredSSP -Role server

При использовании проверки подлинности CredSSP серверу разрешено принимать учетные данные пользователей от удаленных
компьютеров. Если включить проверку подлинности CredSSP на сервере, он получит доступ к имени пользователя и паролю для
клиентского компьютера, если клиентский компьютер отправит их. Дополнительные сведения см. в разделе справки для
команды Enable-WSManCredSSP.
Вы хотите включить проверку подлинности CredSSP?
[Y] Да - Y [N] Нет - N [S] Приостановить - S [?] Справка (значением по умолчанию является "Y"): y

cfg : http://schemas.microsoft.com/wbem/wsman/1/config/service/auth
lang : ru-RU
Basic : false
Kerberos : true
Negotiate : true
Certificate : false
CredSSP : true
CbtHardeningLevel : Relaxed

Также смотрю результат:

Get-WSManCredSSP

Параметры компьютера позволяют делегировать новые учетные данные следующим конечным объектам: wsman/hyper-v_server;wsman/hyper-v_server В настройках компьютера разрешено получение учетных данных от удаленных клиентских компьютеров.

Подключаюсь к машине введя имя компьютера hyper-v_server и учетные данные

логин — hyper-v_serverАдминистратор

пароль ******

На чекбоксе отмечаю, чтобы сохранил пароль

Думает секунд 20 и выдает ошибку:

Сбой операции на компьютере hyper-v_server:Клиенту WinRM не удается обработать запрос. Политика компьютера запрещает делегирование учетных данных пользователя целевому компьютеру. Удостоверение целевого компьютера можно проверить, если настроить службу WSMAN на использование действительного сертификата с помощью следующей команды: winrm set winrm/config/service @{CertificateThumbprint="<thumbprint>"} Кроме того, с помощью средства просмотра событий можно найти событие, указывающее на невозможность создания существующего имени субъекта-службы: WSMAN/<computerFQDN>. Если событие не найдено, то можно создать имя субъекта-службы вручную с помощью программы setspn.exe. Если имя субъекта-службы существует, но CredSSP не может использовать Kerberos для проверки удостоверения целевого компьютера, а вы все же хотите разрешить делегирование учетных данных пользователя целевому компьютеру, то можно открыть оснастку gpedit.msc и найти в ней следующую политику: Делегирование учетных данных - Разрешить свежие учетные данные с использованием проверки подлинности сервера, ограниченной NTLM. Убедитесь, что политика включена и для нее настроено имя субъекта-службы, соответствующий целевому компьютеру. Например, для имени целевого компьютера "myserver.domain.com" имя субъекта-службы может иметь следующий вид:WSMAN/muserver.domain.com или WSMAN/*.domain.com. После внесения этих изменений повторите запрос

Что я делаю не так, требуется ли произвести дополнительные настройки и, если да, то какие именно?

Источник

Успешно развернутая инфраструктура Hyper-V управляется с помощью диспетчера Hyper-V или центра администрирования Windows. Это можно сделать локально или удаленно, но во многих случаях удаленное управление является более эффективным способом, особенно если у нас больше серверов. Начиная с Windows 8, Microsoft интегрировала клиент Hyper-V в выпуски Professional и Enterprise операционной системы (Windows 8, Windows 8.1 и Windows 10). Это дает дополнительную гибкость, поскольку вам, как ИТ-администратору, нужно делать это не с Windows Server, а с вашего клиентского компьютера с Windows.

Процедура подключения к удаленному серверу Hyper-V проста. Все, что нам нужно, это открыть диспетчер Hyper-V и подключиться к удаленному серверу виртуализации, нажав Подключиться к серверу … на правой стороне консоли диспетчера Hyper-V.

Некоторые ИТ-администраторы испытывают проблемы при подключении с клиента Windows к удаленному серверу Hyper-V. Существуют разные причины, по которым эта проблема может возникнуть, но в этой статье мы поговорим об отсутствии доверия между исходным и целевым компьютером. Ошибка известна как: «Произошла ошибка при попытке подключения к серверу «ServerName». Убедитесь, что служба управления виртуальными машинами запущена и у вас есть права на подключение к серверу. Не удалось подключиться к удаленному серверу: клиент WinRM не может обработать запрос. Политика компьютера не позволяет делегировать учетные данные пользователя целевому компьютеру… » как показано на скриншоте ниже.

Поскольку причина очевидна, на следующих нескольких шагах мы проведем вас через процесс включения доверия между клиентским компьютером Windows и удаленным сервером Hyper-V.

Разрешить делегирование новых учетных данных с помощью проверки подлинности сервера только для NTLM

Включение доверия на клиентском компьютере Windows может быть выполнено через графический интерфейс или Powershell. В этой статье мы сделаем это с помощью редактора локальной групповой политики (GUI). Политика называется Разрешить делегирование новых учетных данных с помощью аутентификации сервера только для NTLM. Этот параметр политики применяется к приложениям, использующим компонент Cred SSP (например, подключение к удаленному рабочему столу). Протокол поставщика поддержки безопасности учетных данных (CredSSP) — это поставщик проверки подлинности, который обрабатывает запросы проверки подлинности для других приложений. Если вы включите этот параметр политики, вы можете указать серверы, на которые могут быть делегированы свежие учетные данные пользователя (свежие учетные данные — это те, которые запрашиваются при выполнении приложения). Если вы не настроите (по умолчанию) этот параметр политики, после правильной взаимной аутентификации делегирование новых учетных данных разрешается узлу сеансов удаленных рабочих столов, работающему на любом компьютере (TERMSRV / *). Если этот параметр политики отключен, делегирование новых учетных данных не разрешается ни одному компьютеру. В нашем примере мы включим политику на исходном компьютере Windows, с которого мы подключаемся к удаленному серверу Hyper-V. Итак, начнем.

Щелкните правой кнопкой мыши на Стартовое меню и найдите редактор групповой политики, набрав gpedit
открыто Изменить групповую политику
Перейдите к Настройки компьютера> Административные шаблоны> Система> Делегирование полномочий
Двойной клик по Разрешить делегирование новых учетных данных с проверкой подлинности сервера только для NTLM
Активируйте политику, нажав на включить
Нажмите Шоу… рядом с Добавить серверы в список
Нажмите на поле и введите имя сервера WSMAN / Hyper-V. В нашем примере сервер называется hyperv01, поэтому мы введем wsman / hyperv01
Нажмите Хорошо подтвердить
Нажмите Применять а потом Хорошо

По умолчанию групповая политика компьютера обновляется в фоновом режиме каждые 90 минут со случайным смещением от 0 до 30 минут. Поскольку мы не хотим ждать этого, мы будем принудительно обновлять с помощью CMD или Powershell. Пожалуйста, следуйте процедуре ниже. Также мы можем изменить интервал обновления для групповой политики, начиная с 0 минут до 31 дня.

Щелкните правой кнопкой мыши на Стартовое меню и открыть Windows PowerShell (администратор) или же Командная строка (администратор)
Нажмите да в подтвердить открытие в качестве администратора
Тип gpupdate / force и нажмите Политика будет обновлена через несколько секунд.
открыто Диспетчер Hyper-V на клиентской машине Windows
Нажмите на Подключиться к серверу … на правой стороне консоли диспетчера Hyper-V
Введите имя сервера Hyper-V 2019 в поле Другой Компьютер, Выбрать Подключитесь как другой пользователь. а затем нажмите на Установить пользователя …. В нашем примере мы подключаемся к удаленному серверу Hyper-V, который называется hyperv01
Введите имя пользователя и пароль. Имя пользователя должно быть в формате или. В нашем примере мы используем имя сервера hyperv01 Administrator.
Нажмите Хорошо а потом Хорошо снова
Вы успешно подключились к удаленному серверу Hyper-V
Наслаждайтесь игрой со своими виртуальными машинами

Источник

Remove From My Forums

Question
Hi,

Im got hands on some used iron i want to play with Hyper-V with.

I have a work laptop i want to remote manage a hyper-v setup that not in a domain.
- Hyper-V server:
  OS: Windows 10 PRO
  IP: 192.168.1.5
  Hostname: dev
  In domain: NO
- Client:
  IP: 192.168.1.10
  OS: Windows 10 PRO
  Hostname: WRK001
  In domain: YES
Anyone know if this is possible and how do i get it up running. Or point me in the right direction.

Have modified the HOSTS file on the client so i can ping the Hyper-V server by it name «dev»

#LnQ¯_(ツ)_/¯
- Edited by
  
  Tuesday, November 22, 2016 7:19 PM
  solved

Answers

Hi LongQuo,

>>Getting this: Enable delegation of user credentials?

Is there a button to choose to allow?

You could enable delegation in local group policy.

Open Local Group Policy Editor(gpedit.msc), choose to the following path: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation.

Enable the following settings and click Show to add server Hyper-V/*:
- Allow delegating default credentials with NTLM-only server authentication.
- Allow delegating default credentials.
- Allow delegating saved credentials.
- Allow delegating saved credentials with NTLM-only server authentication
Restart to let the policy take effect.

Best Regards,

Leo

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact
tnmff@microsoft.com.
- Edited by
  Leo Han
  Monday, November 7, 2016 8:15 AM
- Proposed as answer by
  Taylor Brown, Microsoft
  Tuesday, November 22, 2016 12:13 AM
- Marked as answer by
  LongQuo
  Tuesday, November 22, 2016 7:15 PM

Источник

Remove From My Forums

Question
Hi,

Im got hands on some used iron i want to play with Hyper-V with.

I have a work laptop i want to remote manage a hyper-v setup that not in a domain.
- Hyper-V server:
  OS: Windows 10 PRO
  IP: 192.168.1.5
  Hostname: dev
  In domain: NO
- Client:
  IP: 192.168.1.10
  OS: Windows 10 PRO
  Hostname: WRK001
  In domain: YES
Anyone know if this is possible and how do i get it up running. Or point me in the right direction.

Have modified the HOSTS file on the client so i can ping the Hyper-V server by it name «dev»

#LnQ¯_(ツ)_/¯
- Edited by
  
  Tuesday, November 22, 2016 7:19 PM
  solved

Answers

Hi LongQuo,

>>Getting this: Enable delegation of user credentials?

Is there a button to choose to allow?

You could enable delegation in local group policy.

Open Local Group Policy Editor(gpedit.msc), choose to the following path: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation.

Enable the following settings and click Show to add server Hyper-V/*:
- Allow delegating default credentials with NTLM-only server authentication.
- Allow delegating default credentials.
- Allow delegating saved credentials.
- Allow delegating saved credentials with NTLM-only server authentication
Restart to let the policy take effect.

Best Regards,

Leo

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact
tnmff@microsoft.com.
- Edited by
  Leo Han
  Monday, November 7, 2016 8:15 AM
- Proposed as answer by
  Taylor Brown, Microsoft
  Tuesday, November 22, 2016 12:13 AM
- Marked as answer by
  LongQuo
  Tuesday, November 22, 2016 7:15 PM

Источник

Встроенная в Windows возможность удаленного подключения, конечно, не так продвинута, как тот же UltraVNC, но чем она удобна, так это как раз встроенностью.

При совершении подключения к удаленному компьютеру есть возможность сохранить пароль от своей учетной записи. Это удобно при частых подключениях и если Вы уверены, что это никак не скажется на безопасности. Однако не исключено, что Вы встретите и вот такое сообщение: Системный администратор запретил использовать сохраненные учетные данные для входа в систему удаленного компьютера, так как его подлинность проверена не полностью. Исправим это досадное недоразумение.

Непосредственно ошибка.

Причина ошибки кроется в том, что по умолчанию сохранение учетных данных запрещено локальной групповой политикой. Для редактирования данной политики нажимаем Пуск → Выполнить и вводим gpedit.msc. Откроется редактор локальных групповых политик.

Нам нужно перейти в ветку Конфигурация компьютера → Административные шаблоны → Система → Передача учетных данных и найти пункт Разрешить делегирование сохраненных учетных данных с проверкой подлинности сервера «только NTLM».

Зайдя в политику, поставьте переключатель в положение Включить и нажмите кнопку Показать возле Добавить серверы в список.

В открывшемся окне надо вручную добавить компьютеры, к которым Вы хотите подключаться с сохранением пароля. Синтаксис имеет следующий вид:

TERMSRV/[имя или адрес удаленного компьютера] — сохраняет учетные данные при подключении к конкретному компьютеру;

TERMSRV/*.domain.com — сохраняет учетные данные при подключении к компьютерам в домене domain.com;

TERMSRV/* — сохраняет учетных данные при любом подключении.

TERMSRV в данном случае должно быть написано именно заглавными буквами. После сохранения внесенных изменений можно форсировать применение новой политики командой gpupdate /force. После этого система начнет запоминать Ваши учетные данные при RDP-подключении.

↑

Источник

Проблемы с подключениями к удаленному рабочему столу являются общими. При попытке подключиться к сети удаленного рабочего стола многие пользователи сообщили об ошибке: Ваши учетные данные не работают, попытка входа не удалась . Если вы столкнулись с этой проблемой, очевидно, первым шагом должна быть проверка учетных данных. Однако значительное количество пользователей отметили, что учетные данные были правильными и во многих случаях раньше работали нормально. Пользователи сообщили об этой проблеме во вновь установленных версиях операционной системы и сразу после переустановки Windows.

Ваши учетные данные не работали в удаленном рабочем столе

Вероятно, проблема вызвана политиками безопасности Windows или, возможно, недавно изменилось имя пользователя. Последнее особенно актуально при переустановке Windows и вводе нового имени пользователя. Учетные данные для подключения к удаленному рабочему столу Windows не изменяются автоматически.

Чтобы устранить проблему, мы будем последовательно придерживаться следующего подхода:

1] Запустите средство устранения неполадок сетевого адаптера

Средство устранения неполадок сетевого адаптера поможет проверить недостатки сети (если есть) и исправить их.

Перейдите в Пуск> Настройки> Обновления и безопасность> Устранение неполадок. Выберите средство устранения неполадок сетевого адаптера из списка.

2] Изменить профиль сети с общего на частный

Сообщалось, что эта проблема возникла в системах, где сетевой профиль был установлен как общедоступный. Изменение на частное помогло в решении проблемы.

Перейдите в Пуск> Настройки> Сеть и Интернет> Состояние. Нажмите Изменить свойства соединения .

Переключите переключатель «Профиль сети» на «Частный».

Подождите несколько секунд, пока система изменит настройки.

3] Изменить имя пользователя аккаунта

Одна из причин этой проблемы заключается в том, что когда пользователи переустанавливают свою копию Windows 10, они изменяют имя пользователя для системы, но оно не изменяется для подключения к удаленному рабочему столу. В этом случае вы можете изменить имя пользователя на прежнее до переустановки и посмотреть, поможет ли это.

4] Изменить политику безопасности Windows

Существует политика безопасности Windows, которая при включении не разрешает пользователям без прав администратора входить в подключение к удаленному рабочему столу. Если вам нужно разрешить пользователям без прав администратора использовать подключение к удаленному рабочему столу, вам придется изменить эту политику. Это очевидно возможно, если вы сами являетесь администратором системы.

Нажмите Win + R, чтобы открыть окно «Выполнить» и введите команду secpol.msc. Нажмите Enter, чтобы открыть локальную политику безопасности. В окне Локальная политика безопасности на левой панели выберите Локальные политики> Соглашение о правах пользователя .

На правой панели дважды нажмите « Разрешить вход в систему через службы удаленных рабочих столов ».

В следующем окне выберите Добавить пользователя или группу .

В разделе «Введите имена объектов для выбора столбца» введите имя пользователя, не являющегося администратором. Нажмите Проверить имена, чтобы разрешить имя пользователя.

Выберите Ok, чтобы сохранить настройки и перезагрузить систему.

5] Использование редактора групповой политики

Если вам нужно установить эту политику для нескольких систем, то же самое можно сделать через редактор групповой политики. Процедура для того же состоит в следующем:

Нажмите Win + R, чтобы открыть окно «Выполнить» и введите команду gpedit.msc. Нажмите Enter, чтобы открыть редактор групповой политики. Перейдите по следующему пути:

Конфигурация компьютера> Административные шаблоны> Система> Делегирование полномочий.

На правой панели дважды щелкните политику « Разрешить делегирование учетных данных по умолчанию с проверкой подлинности сервера только для NTLM », чтобы открыть окно редактирования.

Установите переключатель в положение «Включено» и нажмите «Показать».

В поле «Значение» введите TERMSRV/* и нажмите «ОК».

Повторите то же самое для следующих политик:

Разрешить делегирование учетных данных по умолчанию
Разрешить делегирование сохраненных учетных данных
Разрешить делегирование сохраненных учетных данных с проверкой подлинности сервера только для NTLM

Проверьте, помогает ли решение проблемы.

Надеюсь, что-нибудь поможет!

Связанное чтение . Ошибка при входе в систему при подключении к удаленному рабочему столу.

Источник

Я новичок в powershell, и у меня возникли проблемы с делегированием учетных данных. У меня есть следующий скрипт:

$session = New-PSSession myserver -Authentication CredSSP -Credential DOMAINAdministrator
Invoke-Command -Session $session -ScriptBlock { <Some PowerShell Command> }

прежде чем запустить его, я сделал следующее:

Run Enable-PSRemoting на myserver.
Run Enable-WSManCredSSP Server на myserver.
Run Restart-Service WinRM на myserver.
Run Enable-WSManCredSSP Client –DelegateComputer myserver на клиенте.
перезагрузил сервер и клиент.

но как только я запускаю сценарий, я получаю следующее сообщение об ошибке:

[myserver] Connecting to remote server failed with the following error message : The WinRM client cannot process the request. A computer policy does not allow the delegation of
 the user credentials to the target computer. Use gpedit.msc and look at the following policy: Computer Configuration -> Administrative Templates -> System -> Credentials Delega
tion -> Allow Delegating Fresh Credentials.  Verify that it is enabled and configured with an SPN appropriate for the target computer. For example, for a target computer name "m
yserver.domain.com", the SPN can be one of the following: WSMAN/myserver.domain.com or WSMAN/*.domain.com. For more information, see the about_Remote_Troubleshooting Help topic.
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportException
    + FullyQualifiedErrorId : PSSessionOpenFailed

Я проверил политики, как указано в сообщении об ошибке, но все, кажется, в порядке. Что еще может блокировать меня?

4 ответов

мне пришлось сделать на сервере следующее:

Enable-WSManCredSSP -Role Server

Я должен был сделать следующее на клиенте:

set-item wsman:localhostclienttrustedhosts -value *

Enable-WSManCredSSP -Role Client –DelegateComputer *

использовать gpedit.msc на клиенте, чтобы включить делегирование свежих учетных данных WSMAN/*:

расширения Local Computer Policy, затем Computer Configuration разверните
Administrative Templates, затем System и нажмите кнопку Credential Delegation.
на дважды щелкните Allow Delegating Fresh Credentials with NTLM-only Server Authentication.
на окне выполните следующий:
клик Enabled.
на Options щелкните Show.
в поле Значение введите WSMAN/* и нажмите кнопку OK. Убедитесь, что
Concatenate OS defaults with input above, а затем
нажмите OK.

теперь работает следующая команда (после запроса пароля):

Invoke-Command { dir fileserverdevtools } -computer appserver01 -authentication credssp -credential domainuser

посмотреть форумы MSDN.

посмотреть TechNet

Я, наконец, получил его на работу, спасибо на этой странице. Он предоставляет сценарий, который задает необходимые политики делегирования учетных данных путем установки соответствующих разделов реестра непосредственно. Как только я запустил этот скрипт с правами администратора, я смог успешно установить соединение CredSSP с myserver:

Enable-WSManCredSSP -Role client -DelegateComputer *.mydomain.com

$allowed = @('WSMAN/*.mydomain.com')

$key = 'hklm:SOFTWAREPoliciesMicrosoftWindowsCredentialsDelegation'
if (!(Test-Path $key)) {
    md $key
}
New-ItemProperty -Path $key -Name AllowFreshCredentials -Value 1 -PropertyType Dword -Force            

$key = Join-Path $key 'AllowFreshCredentials'
if (!(Test-Path $key)) {
    md $key
}
$i = 1
$allowed |% {
    # Script does not take into account existing entries in this key
    New-ItemProperty -Path $key -Name $i -Value $_ -PropertyType String -Force
    $i++
}

расширение ответа Акиры выше, в gpedit.msc я должен был установить «разрешить делегирование свежих учетных данных с аутентификацией сервера только NTLM», а не»разрешить делегирование свежих учетных данных».

мне пришлось полностью автоматизировать мое решение, особенно раздел части в решении, в котором вы заходите в Редактор GPO.

1) включить Удаленный PS

Enable-PSRemoting -force

2) Включить CredSSP

Enable-WSManCredSSP -Role Server -Force
Enable-WSManCredSSP -Role Client -DelegateComputer locahost -Force
Enable-WSManCredSSP -Role Client -DelegateComputer $env:COMPUTERNAME -Force
Enable-WSManCredSSP -Role Client -DelegateComputer $domain -Force
Enable-WSManCredSSP -Role Client -DelegateComputer "*.$domain" -Force
Set-Item -Path "wsman:localhostserviceauthcredSSP" -Value $True -Force

3) включить свежие учетные данные NTLM через Registery:

New-Item -Path HKLM:SOFTWAREPoliciesMicrosoftWindowsCredentialsDelegation -Name AllowFreshCredentialsWhenNTLMOnly -Force
New-ItemProperty -Path HKLM:SOFTWAREPoliciesMicrosoftWindowsCredentialsDelegationAllowFreshCredentialsWhenNTLMOnly -Name 1 -Value * -PropertyType String

только после этого я смог запустить сценарий powershell в качестве локального администратора, который мог работать в PSSession и preform AD actions.

$secpasswd = ConvertTo-SecureString $adPassword -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential ("$domainAdmin", $secpasswd)
$adminSession = New-PSSession -Credential $credential -Authentication Credssp;

$sb = {
  param($p1, $p2)

  whoami

  New-ADUser ....
}

Invoke-Command -Session $adminSession -Script $sb -ArgumentList $domain,$userPassword

Источник

Разрешить делегирование новых учетных данных с помощью проверки подлинности сервера только для NTLM

Question

Answers

Question

Answers

Ваши учетные данные не работали в удаленном рабочем столе

4 ответов