Как требования безопасности Microsoft Active Directory влияют на мое приложение C# - PullRequest
Новая
       5

Как требования безопасности Microsoft Active Directory влияют на мое приложение C#

0 голосов
/ 28 марта 2020

Я пытаюсь получить некоторую ясность относительно рекомендаций / требований, которые Microsoft выпустила в этом месяце в отношении AD и LDAP. Моя компания производит программное обеспечение, которое запрашивает AD для групп и пользователей. Мы используем несколько. NET классов в пространстве имен System.DirectoryServices.AccountManagement для почти всего этого. Мы используем класс PrincipalContext с параметрами по умолчанию (Negotiate, Signing, Sealing) для выполнения привязки.

У нас есть клиент, которому требуется поддержка LDAPS, поскольку он считает, что это предписано Microsoft. Из того, что я смог собрать, требование состоит только в том, чтобы привязки выполнялись в безопасном имении, а не обязательно, чтобы они выполнялись с использованием одного конкретного подхода. Однако я все еще не совсем уверен, что моя интерпретация верна. Если бы я мог получить ответы на следующие вопросы, я был бы в лучшем положении, чтобы знать, что нам нужно сделать для этого клиента. Пожалуйста, имейте в виду, что нас интересует только Active Directory.

  1. Насколько я понимаю, подписывание и печать безопасны, и именно это связывает большинство клиентских и серверных приложений Microsoft. Это правильно?
  2. LDAPS, вероятно, необходим только для поддержки клиентов, которые не могут использовать подписывание / запечатывание (возможно, потому что клиент не поддерживает NTLM или Kerberos). Это правильно?
  3. Домен с поддержкой LDAPS должен по-прежнему поддерживать LDAP (с поддержкой подписи / запечатывания). Вы не можете каким-то образом удалить поддержку обычного LDAP, поскольку это сломало бы много клиентов, верно?
  4. Если первые три утверждения верны, есть ли реальная причина, почему клиентское приложение, которое уже поддерживает подписывание / запечатывание, должно хотеть для поддержки LDAPS?

Если ответ на последний вопрос «Нет», но вам все еще нужно было обеспечить поддержку LDAPS, чтобы клиент был доволен, вы можете реализовать эту поддержку одним из двух способов. , Первый потребует, чтобы пользователь явно выбрал LDAPS для AD, где мы настраиваем другие подобные параметры. Второй подход заключается в том, чтобы сначала попытаться выполнить привязку LDAPS, а в случае неудачи выполнить откат к привязке LDAP с параметрами по умолчанию (согласование, подписание, запечатывание). Второй подход кажется более простым на первый взгляд, но я думаю, что есть несколько проблем с ним. Итак, вот еще несколько вопросов, в частности об этой последней реализации.

  1. Для доменов, которые поддерживают как LDAPS, так и LDAP, хотим ли мы связываться с SSL, если бы мы могли выполнить связывание с подписанием / уплотнение? Действительно ли мы предпочитаем неправильный подход к связыванию, просто чтобы связать то, что запрашивает один клиент?
  2. Я экспериментировал с попыткой связывания SSL, когда LDAPS не настроен для тестирования резервной логики c. С классом PrincipalContext или методом Bind класса LdapConnection требуется около 30 секунд, прежде чем истечет время ожидания и он сдастся. Я не нашел способа контролировать это время ожидания. Если бы я шел по этому маршруту go, я бы хотел, чтобы он проваливался быстрее (скажем, через 3–5 секунд), чтобы я мог вернуться к обычному связыванию и продолжить работу. Есть ли способ установить фактическое время ожидания операции связывания с помощью одного из этих классов. NET классов?

Заранее спасибо всем, кто может дать ответы на любой или все эти вопросы.

...