Что означает «интеграция с активным каталогом» в вашем .NET-приложении?
Наш маркетинговый отдел возвращается с «активной интеграцией каталогов», которая является ключевым запросом клиентов, но у нашей компании, похоже, нет достаточного внимания, чтобы (1) решить, какие функциональные изменения мы хотим внести с этой целью, (2) провести собеседование с широкий круг клиентов, чтобы определить наиболее востребованные функциональные изменения, и (3) эта проблема по-прежнему будет актуальной на следующей неделе. Чтобы помочь мне выйти за рамки широкой темы «интеграции активных каталогов», что это означает в вашем .NET-приложении, как ASP.NET, так и WinForms?
Вот несколько примеров изменений, которые я должен учесть:
- При создании и управлении пользователями в вашем приложении, предоставляется ли администраторам список всех пользователей AD или только группа пользователей AD?
- Следует ли при создании новых групп безопасности в вашем приложении (мы называем их отделами, например «Отдел кадров») новые группы AD?
- Распределяют ли администраторы пользователей по группам безопасности внутри вашего приложения или за его пределами через AD? Это имеет значение?
- Пользователь вошел в ваше приложение в силу того, что он вошел в Windows? Если нет, отслеживаете ли вы пользователей с помощью собственной таблицы пользователей и какого-то внешнего ключа в AD? Какой внешний ключ вы используете для связывания пользователей приложения с пользователями AD? Вы должны доказать, что ваш процесс входа в систему защищает пароли пользователей?
- Какой внешний ключ вы используете для связывания групп безопасности приложений с группами безопасности AD?
- Если в вашем приложении есть компонент WinForms (у нас есть как ASP.NET, так и WinForms), используете ли вы поставщик членства в своем приложении WinForms? В настоящее время наше управление членством и ролями предшествует версии фреймворка, поэтому мы не используем поставщика членства.
Мне не хватает каких-либо других функциональных изменений?
Последующий вопрос
Могут ли приложения, поддерживающие «интеграцию с активным каталогом», аутентифицировать пользователей более чем в одном домене? Не то, чтобы один пользователь аутентифицировался более чем в одном домене, но что разные пользователи одной и той же системы будут аутентифицироваться в разных доменах.
Ответы 5
Is the user signed on to your app by virtue of being signed on to Windows?
Для меня это в первую очередь то, что означает интеграция с AD (помимо блокировки Windows :-). Так, например, если организация внедрила вход с открытым ключом, вы получите его в своем приложении бесплатно.
Do you have to prove your login process protects user passwords?
Как правило, вы никогда не должны даже видеть пароль, если используете AD, если только у вас нет устаревшего NT4 (конечно, не нужно хранить пароль).
Do administrators assign users to security groups within your app or outside via AD? Does it matter?
Через AD. После единого входа основным преимуществом будет возможность использовать любые инструменты AD, которые у вас есть, для обеспечения безопасности, администрирования приложения, составления отчетов о разрешениях, создания списков контроля доступа и т. д. Вам не придется заново изобретать эти вещи для каждого приложения.
В большинстве случаев в этом нет необходимости - ваше приложение зарегистрировано в AD, так же как MS Word может получать доступ к общим файловым ресурсам без запроса учетных данных. Также в некоторых средах (правда, не во многих!) Пароля нет.
плохая формулировка - очевидно, что авторизован пользователь, а не ваше приложение. однако любое дальнейшее взаимодействие с безопасностью AD обычно прозрачно для вашего приложения, в зависимости от того, какие API вы используете для взаимодействия с вашим сервером.
Одним из основных преимуществ использования AD является то, что он позволяет специальной команде управлять всеми функциями пользователей / грантов. Обычно, когда приходит новый пользователь, его менеджер просит специальную группу предоставить ему доступ к приложениям A B и C, и эта группа может делать все это прямо из AD. Фактически, они часто дублируют другого пользователя (обычно его коллегу).
В качестве ключа для сопоставления пользователей / групп AD с содержимым приложения я обычно использую идентификатор безопасности (SID) от пользователя / группы AD.
Спасибо, что ответили на эту деталь. Мне кажется, у вас есть отдельная таблица для обработки сопоставления, если у вас есть другие клиенты, которые не используют интеграцию с AD.
Мне никогда не приходилось иметь дело со «смешанными методами аутентификации». Но если бы мне пришлось, я бы поступил так, как вы предлагаете. Придумайте «Application UserId», затем сопоставьте SID с этим UserId. Затем используйте UserId во всем приложении. Обычно я могу просто использовать SID, как в моих приложениях.
с точки зрения администраторов, я хочу, чтобы рекламная интеграция выполняла следующие действия
- никогда не пишите обратно в AD, я просто не доверяю стороннему программному обеспечению в этом вопросе
- возможность импортировать пользователей из AD
возможность установить группу безопасности, например, «Пользователи ApplicationXYZ», которая будет использоваться для распространения программного обеспечения и прав (общие папки, ...), если необходимо, но это должно соответствовать номеру 1., поэтому администратор создает группу безопасности и сообщает серверу приложений, какой один это.
единый вход (упрощает для пользователей, потому что им нужно только знать свой логин в Windows, и обеспечивает соблюдение политики паролей для всего домена)
деактивированный пользователь AD или пользователь AD, который больше не входит в "Пользователи ApplicationXYZ", не должны иметь возможность войти в систему
связать AD-Group с Application Group, но это было бы необязательно, я действительно могу жить без этого
hth
Как человек, который одновременно является администратором AD и в настоящее время разрабатывает внутреннее приложение, которое необходимо интегрировать с AD, вот мои мысли:
- Пользователи Active Directory имеют уникальный GUID; если ваше приложение должно поддерживать аутентификацию оба AD и AspNetSqlMembership, у вас может быть поле GUID FK в вашей таблице User / Person и флаг, обозначающий, к какому хранилищу информации принадлежит пользователь (формы или AD)
- Как администратор, я должен иметь возможность ограничивать доступ к своему приложению для пользователей, находящихся ниже данного подразделения - я не хочу, чтобы мои рабочие учетные записи SQL Server или BackupExec могли входить в систему!
- В своей документации используйте OU, отличное от стандартного OU «Пользователи» - большинство реальных реализаций перемещают своих пользователей из этого контейнера, и для начинающих администраторов это снова гарантирует наличие примера запроса LDAP, который включает OU (например, MyCompany / Пользователи / руководители или что-то в этом роде)
- Если вы используете аутентификацию с помощью форм AD, возможно, вы можете перехватить пароль и сделать что-то вредоносное. Лучше всего решить эту проблему в вашем юридическом отделе в вашем соглашении об обслуживании / гарантии.
Что означает OU? Кроме того, спасибо за ваши вдумчивые ответы.
@flipdoubt: OU = организационная единица. Это контейнер, в котором хранятся такие объекты, как учетные записи пользователей, компьютеры и т. д.
Я не собираюсь хранить пароли, но если пользователь должен ввести свое имя AD и пароль в мое приложение WinForms, как клиент узнает, что я не вхожу в систему и не сбрасываю карнизы? Вы вызываете какой-то родной элемент управления входом в Windows?