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