Управление учетными данными другого пользователя для доступа к сети

У меня есть учетная запись Windows, которая используется для запуска служб (т. Е. Никто не должен входить в систему под этой учетной записью). Оказывается, одна из служб должна иметь доступ к удаленному сетевому ресурсу, находящемуся на компьютере в другом домене Windows, и поэтому должна предоставить удаленные учетные данные для доступа к этому общему ресурсу.

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

Конечно, я могу решить эту проблему. Я временно повышаю привилегии учетной записи службы, чтобы разрешить интерактивные входы в систему, затем вхожу в систему как этот пользователь и использую диспетчер учетных данных для хранения правильных удаленных учетных данных. Затем я удаляю права интерактивного входа. Но это кажется очень смешным, и я не должен этим заниматься.

Итак, мой вопрос: есть ли другой способ сохранить удаленные учетные данные для учетной записи, отличной от той, в которую вы вошли как? Любой лучший способ решить мою проблему.

Источник

4 ответа

Решение

Если вы можете получить доступ к удаленному компьютеру, вы можете добавить свою учетную запись службы в локальную группу "Пользователи" и сопоставить имя пользователя / пароль с тем, что вы будете использовать. Не забудьте дать ему административные привилегии.

Затем перейдите на вкладку удаленного входа в системном меню и добавьте этого пользователя в качестве пользователя, которому разрешен удаленный вход. Это то, что я делаю, когда мне нужно поразить определенные машины, которые находятся в нашей сети, но по какой-то причине не являются частью домена.

Источник

Хотя это оказалось неуместным для вашей ситуации, для будущих пользователей, ответ на актуальный вопрос "Управление учетными данными другого пользователя для доступа к сети":

runas /user:serviceaccountname "%windir%\system32\cmdkey.exe /add:server.domain.com /user:username /pass:password"

Это создаст учетные данные в serviceaccountnameхранилище для server.domain.com с помощью username/password,

/user также поддерживает domain\username а также username@domain стили.

Источник

В качестве дополнительной альтернативы я использую PsExec:

psexec -u otheruser -p otheruserpassword cmdkey.exe /add:server.domain.com /user:username /pass:password

Источник

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

Подключитесь к соответствующему компьютеру с помощью учетной записи администратора через Enter-PSSession -ComputerName target_machine (или запустите команды через Invoke-Command).

С участием SeBatchLogonRight уже установлен

Если учетная запись пользователя, для которой вы хотите добавить учетные данные через cmdkey уже есть SeBatchLogonRight set (обычно только админы), то это довольно просто:

$job = Register-ScheduledJob -ScriptBlock {
     cmdkey /add:target_machine:target_port /user:target_domain\target_user /pass:target_user_password
} -Name "Add user credentials" -Credential (New-Object System.Management.Automation.PSCredential("source_domain\source_user", (ConvertTo-SecureString "source_user_password" -AsPlainText -Force))) -RunNow

Unregister-ScheduledJob -InputObject $job

Без SeBatchLogonRight уже установлен

Если учетная запись пользователя, для которой вы хотите добавить учетные данные через cmdkey не имеет SeBatchLogonRightуже установлен, то вам нужно (временно) предоставить ему право. Простой способ сделать это удаленно - использовать модуль PowerShell от Тони Помбо:

Invoke-WebRequest https://gallery.technet.microsoft.com/scriptcenter/Grant-Revoke-Query-user-26e259b0/file/198800/1/UserRights.psm1 -OutFile UserRights.psm1

# You might need to setup at least the following execution policy, if you haven't already:
# Set-ExecutionPolicy AllSigned

Import-Module .\UserRights.psm1

Grant-UserRight -Account "source_machine\source_user" -Right SeBatchLogonRight

$job = Register-ScheduledJob -ScriptBlock {
     cmdkey /add:target_machine:target_port /user:target_domain\target_user /pass:target_user_password
} -Name "Add user credentials" -Credential (New-Object System.Management.Automation.PSCredential("source_domain\source_user", (ConvertTo-SecureString "source_user_password" -AsPlainText -Force))) -RunNow

Unregister-ScheduledJob -InputObject $job

Revoke-UserRight -Account "source_machine\source_user" -Right SeBatchLogonRight

В приведенных выше скриптах использовались следующие заполнители:

  • source_domain = Домен source_user принадлежит.
  • source_user = Пользователь, для которого cmdkey команда будет выполнена (cmdkey выполняется в контексте этого пользователя).
  • source_user_password = Пароль source_user Счет.
  • target_machine = Целевой компьютер, используемый в cmdkey команда.
  • target_port = Целевой порт, используемый в cmdkeyкоманда (необязательно). (Например, используйте 1433 для проверки подлинности Windows в сочетании с SQL Server.)
  • target_domain = Домен target_user принадлежит.
  • target_user = Целевая учетная запись пользователя, используемая в cmdkey команда. source_user будет выдавать себя за этого пользователя при подключении к target_machine.
  • target_user_password = Пароль target_user Счет.
Источник
Другие вопросы по тегам