Что означает "активная интеграция каталогов" в вашем приложении .NET?

Наш отдел маркетинга возвращается с "активной интеграцией с каталогом", являющейся ключевым клиентом, но наша компания, похоже, не уделяет внимания (1) решению о том, какие функциональные изменения мы хотим сделать в этом направлении (2 ) интервью с широким кругом клиентов, чтобы определить наиболее востребованные функциональные изменения, и (3) все еще есть проблема "горячего картофеля" на следующей неделе. Чтобы помочь мне выйти за рамки широкой темы "активной интеграции каталогов", что это означает в вашем приложении .NET, как ASP.NET, так и WinForms?

Вот некоторые примеры изменений, которые я должен рассмотреть:

При создании и управлении пользователями в вашем приложении администраторы представляют список всех пользователей AD или только группу пользователей AD?
При создании новых групп безопасности в вашем приложении (мы называем их департаментами, например "Человеческие ресурсы" ), должны ли они создавать новые группы AD?
Администраторы назначают пользователей для групп безопасности в вашем приложении или вне его через AD? Это имеет значение?
Подключен ли пользователь к вашему приложению в результате его подписания на Windows? Если нет, вы отслеживаете пользователей с вашей собственной пользовательской таблицей и каким-то внешним ключом в AD? Какой внешний ключ вы используете для связи пользователей приложений с пользователями AD? Вам нужно доказать, что ваш процесс входа в систему защищает пароли пользователей?
Какой внешний ключ вы используете для связывания групп безопасности приложений с группами безопасности AD?
Если у вас есть компонент WinForms для вашего приложения (у нас есть как ASP.NET, так и WinForms), используете ли вы поставщик членства в своем приложении WinForms? В настоящее время наше управление членством и ролями предшествует версии фреймворка, поэтому мы не используем поставщика членства.

Не хватает ли каких-либо других областей функциональных изменений?

Последующий вопрос

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

Ответ 1

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

никогда не пишите в AD, я просто не доверяю стороннему программному обеспечению в этой точке
возможность импорта пользователей из AD
возможность установить группу безопасности, например "Пользователи ApplicationXYZ", которая будет использоваться для распространения и прав на программное обеспечение (общие папки,...), если это необходимо, но это должно соответствовать номеру 1., поэтому администратор создает защиту group и сообщает серверу приложений, какой он есть.
единый вход (упрощает для пользователей, потому что им нужно только знать их регистрацию в Windows и применяет политику пароля домена)
деактивированный AD-пользователь или пользователь AD, который больше не находится в "UsersXYZ Users", не может войти в систему
свяжите AD-Group с группой приложений, но это будет необязательно, я действительно могу жить без этого

HTH

Ответ 2

В качестве ключа для сопоставления пользователей/групп AD для приложений в приложении я обычно использую идентификатор безопасности (SID) от AD-пользователя/группы.

Ответ 3

Подключен ли пользователь к вашему приложению, поскольку он подписан на Windows?

Для меня это в первую очередь то, что означает интеграция AD (кроме Windows lockin:-). Например, если организация внедрила вход в открытый ключ, вы ничего не получите в своем приложении.

Вам нужно доказать, что ваш процесс регистрации защищает пароли пользователей?

Обычно вы никогда не видите пароль, если используете AD, если у вас нет устаревшего NT4 (конечно, не нужно хранить пароль).

Предоставляют ли администраторы пользователям группы безопасности внутри вашего приложения или вне его через AD? Это имеет значение?

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

Ответ 4

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

Ответ 5

Как и тот, кто является Администратором AD и в настоящее время разрабатывает внутреннее приложение, которое должно быть интегрировано в AD, вот мои мысли:

У пользователей Active Directory есть уникальный идентификатор GUID; если ваше приложение должно поддерживать аутентификацию AD и AspNetSqlMembership, у вас может быть поле GUID FK в вашей таблице User/Person и флаг, обозначающий, к какой информации принадлежит пользователь (формы или AD).
Как администратор, я должен иметь возможность ограничить доступ к моему приложению пользователям под определенным подразделением - я не хочу, чтобы мои рабочие учетные записи SQL Server или BackupExec могли входить в систему!
В своей документации используйте OU, отличное от стандартного OU - "Пользователи". Большинство реализаций в реальном мире вытесняют своих пользователей из этого контейнера, а для начинающих администраторов он повторно подтверждает, что имеет пример запроса LDAP, который включает в себя OU ( например, MyCompany/Users/Executive или somesuch)
Если вы используете аутентификацию форм AD, возможно, вы можете заманить в ловушку и сделать что-то вредоносное с паролем. Это лучше всего решать вашим юридическим отделом в вашем соглашении/гарантии на обслуживание.