Это плохая практика для размещения внешних пользователей в Active Directory? - PullRequest
12 голосов
/ 06 февраля 2009

У нас есть веб-приложение, и мы хотим перейти с пользовательского решения для проверки подлинности на службы федерации Active Directory, чтобы наши партнерские организации могли управлять авторизацией своих пользователей на их стороне.

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

В дополнение к партнерским организациям, которые будут аутентифицировать своих пользователей и получать доступ через ADFS, у нас есть внутренние пользователи, которые находятся в нашем домене Active Directory. Эти пользователи также могут проходить аутентификацию через ADFS.

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

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

ADFS может подключаться только к хранилищам учетных записей Active Directory или Active Directory.

Поскольку ADFS поддерживает только эти хранилища учетных записей, логичным решением является создание учетных записей для внешних пользователей в нашем домене Active Directory.

Это будет означать, что мы будем обновлять наши регистрационные страницы, чтобы создавать новые учетные записи пользователей в активной Active Directory, а не создавать новые записи в нашей пользовательской базе данных.

Так это плохая практика? Следует ли использовать AD для пользователей, не входящих в свою организацию? Как другие справляются с ситуацией такого типа при использовании ADFS?

Ответы [ 3 ]

10 голосов
/ 06 февраля 2009

Создайте новый лес AD для внешних пользователей. Возможно, вам потребуется настроить более высокий уровень безопасности, но эти два могут быть связаны для бесшовной аутентификации.

При входе в систему необходимо указать им использовать другой домен (например, обычные пользователи используют «mycorp», внешние - «externalcorp»), но в остальном он полностью прозрачен.

2 голосов
/ 06 февраля 2009

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

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

2 голосов
/ 06 февраля 2009

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

...