Общие учетные данные небезопасны и сложны в управлении
Как вы обнаружили, безопасное предоставление нескольким пользователям доступа к ресурсу с использованием одной учетной записи пользователя проблематично. В конце этого ответа я объясняю, что делает это трудным и почему его следует избегать.
Но сначала правильный способ предоставления доступа к ресурсу - использование индивидуальных учетных записей для каждого пользователя, которому необходим доступ. То, как вы это сделаете, будет отличаться для машин, которые являются частью домена хоста целевого ресурса, и тех, которые не являются таковыми.
Члены одного домена
Для пользователей, которые получают доступ к ресурсу с компьютеров, которые находятся в том же домене, что и компьютер, на котором размещен ресурс, вам просто нужно предоставить доступ к существующим учетным записям пользователей AD, которым требуется доступ.
Метод наилучшей практики заключается в следующем:
- Создайте группу безопасности домена.
- Предоставьте группе доступ к целевому ресурсу.
- Сделайте каждый объект пользователя AD, которому необходим доступ к ресурсу, членом группы безопасности.
Не входящие в домен члены
Для пользователей, которым нужен доступ к ресурсу, но с компьютеров, которые не находятся в домене ресурса, наилучшим методом по-прежнему является предоставление доступа отдельным учетным записям пользователей следующим образом:
Создайте учетные записи пользователей Active Directory, используя те же имена пользователей и пароли, которые используются для входа на компьютеры вне домена, которым требуется доступ к ресурсу.
Если по какой-либо причине у вас нет доступа к паролям пользователей, вы можете либо:
а. Создайте учетные записи пользователей AD для каждого пользователя, не входящего в домен, и назначьте пароль по вашему выбору. В этом случае вы должны указать имена пользователей, отличные от тех, которые используются на компьютере, не являющемся доменом, в противном случае имя пользователя будет совпадать, а пароль - нет, блокируя успешный вход в систему. (Предпочтительный.)
б. Создайте один объект пользователя AD, который будет использоваться всеми пользователями, не входящими в домен. (Не предпочтительно - см. Ниже.)
Сделайте новые объекты пользователей AD членами группы, которую вы создали на шаге 1 в предыдущем разделе.
Зачем избегать использования одного пользовательского объекта при предоставлении доступа нескольким пользователям?
Как вы можете видеть, наилучший подход избегает использования одного имени пользователя и пароля для предоставления доступа к ресурсу. На это есть несколько причин:
Общие учетные записи негибки для изменения требований доступа. Когда приходит время аннулировать доступ пользователя, общая учетная запись не прощает. Вы должны изменить пароль в учетной записи, что требует изменения его на всех устройствах, которые все еще требуют доступа, что приводит к ...
Общие пароли трудоемки для изменения. Мы предполагаем, что вы используете пароль, чтобы не пускать определенных пользователей, поэтому смена пароля неизбежна. Но вместо изменения пароля на одном устройстве вы должны изменить его на многих устройствах, большинство из которых часто управляются не централизованно. Что еще хуже, до тех пор, пока новый пароль не будет развернут, устройства, использующие старый пароль, не смогут получить доступ к ресурсу.
Общие учетные записи не идентифицируют авторизованных пользователей. Нигде в системе вы не сможете увидеть, кто имеет доступ через общую учетную запись. Вам (и кому-либо еще, кто управляет средой) нужно будет вести отдельный список. И в отличие от предоставления авторизации непосредственно объектам пользователя, нет гарантии, что внешний список является точным. Кроме того, при мониторинге доступа к ресурсу в режиме реального времени общая учетная запись не показывает, кто на самом деле использует ресурс.
Общие учетные записи более подвержены компрометации. Они привыкли к большему количеству людей из разных мест в большем количестве систем, каждая из которых представляет возможную точку компромисса. Обратитесь к вопросу № 1, чтобы узнать, с какими трудностями можно справиться, сменив пароль.
Массовое распространение учетных данных для единого входа
Возможно, вы обнаружите, что для предоставления доступа к ресурсу вы все равно должны использовать общее имя пользователя и пароль. Если вы окажетесь в этом случае, плохая новость заключается в том, что нет никакого способа удобно распространять его в автоматическом режиме, который поддерживает какое-либо подобие безопасности.
Основная проблема автоматизации заключается в том, что необходимо использовать / сохранять общие учетные данные в контексте входа пользователя, обращающегося к ресурсу. Это исключает любые процессы удаленной автоматизации (если вы не знаете пароль каждого пользователя, в этом случае вам не нужно использовать общие учетные данные).
Осталось только один за другим получить доступ к компьютерам, когда пользователь присутствует, чтобы они могли войти в систему, пока вы сохраняете общие учетные данные, или предоставить учетные данные непосредственно пользователям, чтобы они могли ввести их самостоятельно.
