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

Question

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

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

1. При создании и управлении пользователями в вашем приложении администраторы получают список всех пользователей AD или просто группу пользователей AD?
2. При создании новых групп безопасности в вашем приложении (мы называем их «Отделами», например, «Отдел кадров»), должно ли это создавать новые группы AD?
3. Назначают ли администраторы пользователей в группы безопасности в вашем приложении или вне его через AD? Имеет ли это значение?
4. Пользователь вошел в ваше приложение в силу того, что он вошел в Windows? Если нет, отслеживаете ли вы пользователей с помощью собственной таблицы пользователей и какого-то внешнего ключа в AD? Какой внешний ключ вы используете, чтобы связать пользователей приложения с пользователями AD? Нужно ли доказывать, что ваш логин защищает пароли пользователей?
5. Какой внешний ключ вы используете для связывания групп безопасности приложений с группами безопасности AD?
6. Если у вас есть компонент WinForms для вашего приложения (у нас есть и ASP.NET, и WinForms), используете ли вы членство в вашем приложении WinForms? В настоящее время наше управление членством и ролями предшествует версии платформы, поэтому мы не используем поставщика членства.

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

Дополнительный вопрос

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

Answer 1

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

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

3. возможность установить группу безопасности, например, «Пользователи ApplicationXYZ», которые будут использоваться для распространения программного обеспечения и прав (общие папки, ...), если это необходимо, но это должно соответствовать номеру 1. Таким образом, администратор создает защиту группа и сообщает серверу приложений, какой это.

4. единый вход (упрощает работу пользователей, поскольку им нужно только знать свой вход в Windows, и применяет политику паролей для всего домена)

5. деактивированный пользователь AD или пользователь AD, который больше не находится в «Пользователи ApplicationXYZ», не должен иметь возможность войти в систему

6. связать AD-Group с Application Group, но это было бы необязательно, я действительно могу жить без этого

НТН

Answer 2

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

Answer 3

Является ли пользователь вошедшим в ваше приложение в силу того, что он вошел в Windows?

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

Нужно ли доказывать, что ваш логин защищает пароли пользователей?

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

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

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

Answer 4

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

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

Answer 5

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