Дозволити віддалену команду лише з використанням облікових даних


0

У мене є server Aі server Bв тому ж домені (Windows Server 2012 R2):

PS C:\Deployment> $PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      -1     -1

У мене на сервері B є адміністратор, який викликається WORKGROUP\test.

На обох серверах я виконував:

enable-psremoting -force

На server AI виконується:

Invoke-Command -ComputerName RemoteServerName -ScriptBlock {
   get-childitem
   get-service
}

Це працює. Зараз я використовую облікові дані:

Invoke-Command -ComputerName COMPUTER3 -Credential you-user -ScriptBlock { get-service }

Коли я запускаю його, я отримав такий вигляд (зображення з Інтернету):

https://i-technet.sec.s-msft.com/dynimg/IC702024.png

Коли я надаю правильні облікові дані, вона працює, коли я надаю неправильні облікові дані, вона не працює. Так що це добре. Але коли я просто натискаю "Скасувати", це також працює. Схоже, що віддалений сервер ( server B) не вимагає облікових даних. Що я повинен змінити, щоб він також не зміг, якщо ви не надаєте облікові дані?


Users need to use the credential request- Чому? Що ви сподіваєтесь, що це вдасться досягти? За замовчуванням psremoting буде використовувати автентифікацію kerberos. Користувачі нададуть належні облікові дані при автентифікації у вихідній системі.
Зоредаче

Користувачі можуть запустити скрипт повноважень з одного сервера, який містить усіх користувачів (AD, всі користувачі є на всіх серверах, але не кожен має однакові можливості). Тому деякі користувачі можуть перевірити автентифікацію та запустити команду. Інші не можуть.
lvthillo

Відповіді:


0

У вашій Invoke-Commandкоманді ви можете використовувати опцію-credential

Від MSDN :

PS C:\> Invoke-Command -ComputerName server01 -Credential domain01\user01 -ScriptBlock {Get-Culture}

Користувачам потрібно скористатися запитом на вхід. Тому мені просто потрібно знайти спосіб, як я зобов’язуюсь надавати правильні облікові дані та не дозволяти жодних облікових даних (натискаючи скасувати). Тож я певно кажу на сервері B: доступ до доступу можуть мати лише правильні облікові дані (тепер це: лише права АБО НЕ ТАКОЖ)
lvthillo

Ви пробували з -Authenticationваріантом? За замовчуванням Invoke-Commandне потрібні облікові дані, тому, якщо ви скасуєте, це візьме на себе непотрібного користувача.
Сорча

0

Якщо поточному користувачеві дозволено отримати доступ до кінцевої точки PowerShell на віддаленій машині, він завжди зможе віддалятися, не надаючи явних даних.

Єдиний спосіб вимагати надання явних даних - це розірвати цей ланцюжок. Деякі варіанти:

  • Створіть нового користувача на віддаленому хості, який є адміністратором, та видаліть віддалених користувачів від членства в групах, дозволених підключатися. Це дещо еквівалентно sudoпідходу.
  • Переконфігуруйте кінцеву точку PowerShell за замовчуванням (або видаліть та створіть нову), щоб змінити дозволи дозволеного на підключення. За замовчуванням кінцева точка Microsoft.PowerShell виглядає так:

Get-PSSessionConfiguration

Ім'я: microsoft.powershell
PSVersion: 5.1
StartupScript:
RunAsUser:
Дозвіл: NT AUTHORITY \ INTERACTIVE AccessAllowed, BUILTIN \ Administrators AccessAllowed, BUILTIN \ Віддалене управління користувачами AccessAllowed

Поки віддалений користувач не перебуває в одній із цих груп - або ви вилучите ці групи та використовуєте нові - їм доведеться надати явний обліковий запис для підключення. Це може бути використане -Credentialбезпосередньо на Invoke-Commandсесії або під час створення сесії.

Якщо ви розглядаєте цей варіант, подумайте про те, щоб пройти весь шлях і подивитися на Just Enough Administration ( JEA), де можна вказати три основні варіанти:

  1. Хто може підключитися
  2. Що вони можуть зробити
  3. Хто буде виконувати їх команди.

JEA може стати початком потужної основи обмеження того, що адміністратори можуть зробити для конкретних обставин. Це може бути частиною рольового контролю доступу ( RBAC).

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.