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

341
user1676874

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

Пользователь и пароль могут быть добавлены к одному ПК с помощью команды net use или Windows Credentials Manager, и ему предоставляется доступ к диску.

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

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

Как вы можете распространять такие учетные данные, скажем, на 100 компьютеров, не добавляя их один за другим?

Можно ли использовать net use на определенных устройствах, поскольку мы знаем их IP-адреса?

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

0
1) Есть ли компьютеры в домене? 2) Учитывая серьезный недостаток безопасности, связанный с этим подходом, есть ли конкретная причина, по которой вы не предоставляете доступ «Все» для общего ресурса? Twisty Impersonator 6 лет назад 0
Пользователи должны быть в списке аутентифицированных пользователей на общем диске / папке, чтобы получить доступ без ввода учетных данных. Щелкните правой кнопкой мыши диск / папку, к которой вы хотите предоставить общий доступ, вкладку безопасности / вкладку общего доступа и добавьте пользователя в список разрешений. В следующий раз, когда они пойдут на это, им не нужно будет вводить учетные данные? Narzard 6 лет назад 0
@ Twisty Impersonator: большинство компьютеров находятся в домене. Был создан один пользователь с определенными разрешениями, и все компьютеры должны использовать его учетные данные для работы с ресурсом. Вы говорите, что, возможно, следует разрешить всем вместо этого? user1676874 6 лет назад 0
@Narzard: Я еще не пытался добавлять пользователей к общему ресурсу вручную, позволит ли это доступ всем, кому требуется доступ, без необходимости что-либо делать на каждом компьютере? user1676874 6 лет назад 0
@ user1676874 Я рад, что они в домене. Это легко сделать в домене. Вы должны создать группу безопасности, предоставить ** it ** доступ к ресурсу, а затем сделать всех пользователей, которым нужен доступ, членами этой группы. Это правильный способ сделать то, что вы пытаетесь. Twisty Impersonator 6 лет назад 0
@TwistyImpersonator Я вижу, я попробую это завтра, я тоже надеюсь, что это работает. user1676874 6 лет назад 0

1 ответ на вопрос

0
Twisty Impersonator

Общие учетные данные небезопасны и сложны в управлении

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

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

Члены одного домена

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

  1. Создайте группу безопасности домена.
  2. Предоставьте группе доступ к целевому ресурсу.
  3. Сделайте каждый объект пользователя AD, которому необходим доступ к ресурсу, членом группы безопасности.

Не входящие в домен члены

Для пользователей, которым необходим доступ к ресурсу, но с компьютеров, которые не находятся в домене ресурса, наилучшим методом по-прежнему является предоставление доступа отдельным учетным записям пользователей следующим образом:

  1. Создайте учетные записи пользователей Active Directory, используя те же имена пользователей и пароли, которые используются для входа на компьютеры вне домена, которым требуется доступ к ресурсу.

    Если по какой-либо причине у вас нет доступа к паролям пользователей, вы можете либо:

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

    б. Создайте один объект пользователя AD, который будет использоваться всеми пользователями, не входящими в домен. (Не предпочтительно - см. Ниже.)

  2. Сделайте новые объекты пользователей AD членами группы, которую вы создали на шаге 1 в предыдущем разделе.

Зачем избегать использования одного пользовательского объекта при предоставлении доступа нескольким пользователям?

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

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

  • Общие пароли трудоемки для изменения. Мы предполагаем, что вы используете пароль, чтобы не пускать определенных пользователей, поэтому смена пароля неизбежна. Но вместо изменения пароля на одном устройстве вы должны изменить его на многих устройствах, большинство из которых часто управляются не централизованно. Что еще хуже, до тех пор, пока новый пароль не будет развернут, устройства, использующие старый пароль, не смогут получить доступ к ресурсу.

  • Общие учетные записи не идентифицируют авторизованных пользователей. Нигде в системе вы не сможете увидеть, кто имеет доступ через общую учетную запись. Вам (и кому-либо еще, кто управляет средой) нужно будет вести отдельный список. И в отличие от предоставления авторизации непосредственно объектам пользователя, нет гарантии, что внешний список является точным. Кроме того, при мониторинге доступа к ресурсу в режиме реального времени общая учетная запись не показывает, кто на самом деле использует ресурс.

  • Общие учетные записи более подвержены компрометации. Они привыкли к большему количеству людей из разных мест в большем количестве систем, каждая из которых представляет возможную точку компромисса. Обратитесь к вопросу № 1, чтобы узнать, с какими трудностями можно справиться, сменив пароль.

Массовое распространение учетных данных для единого входа

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

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

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

Похожие вопросы