Чем отличается AD от "нормальных" LDAP каталогов?

Active Directory
Распространнным заблуждением является то, что Active Directory — вроде бы какой-то особый LDAP-сервер с присущими ему «волшебными» таинственно-проприетарными свойствами.
Вкратце скажу, что это не так: Active Directory вполне обычный LDAP-каталог, со своими плюсами и минусами и способы доступа к нему тоже вполне обычны.
Например, возьмём операцию BIND. BiND — это не только самый популярный DNS-сервер в мире от известной компании ISC, но ещё и операция аутентификации пользователя на LDAP-сервере, ассоциирующая его с тем или иным DN, либо же, в случае, если пользователь предпочёл оставаться инкогнито, он будет ассоциирован с таким всеобъемлющим понятием как «anonymous» (кстати, совершенно не факт, что DN будет ассоциирован с одним единственным пользователем, в данном случае устанавливается лишь односторонняя связь пользователь->DN). Каким бывает BIND? BIND бывает «простым», то есть simple — и в этом случае пользователь сам называет DN того объекта, от имени которого он хочет обращаться к услугам Каталога, а бывает ещё и стандартный… основной для LDAP v3, SASL, кхм… в общем, "НЕ SIMPLE" BIND, использующий абстрактный слой аутентификации (SASL) или какие-либо иные внешние и, разумеется, доверенные, механизмы аутентификации. В случае «не simple» BIND'а пользователь может предоставлять в общем случае какую угодно информацию о себе в каком угодно виде, а уже внешний механизм аутентифкации преобразует его в LDAP-совместимую форму DN. Последняя, кстати, чаще всего проходит ещё ряд преобразований на стороне сервера каталогов (см., например, описание инструкции authz-regexp в конфигурационном файле OpenLDAP).
В этом контексте мне часто приходится сталкиваться с таким заблуждением относительно особенностей реализации simple BIND в AD: якобы Microsoft — это такая неправильная компания, у которой сервер каталогов «пускает пользователей» по login@DOMAIN вместо DN, как это принято в других каталогах. К сожалению, неверно данное утверждение «чуть более, чем полностью»…
Во-первых, AD прекрасно авторизует и по отличительному имени (DN), в особенности если в этом отличительном имени нет хитрых элементов, содержащих кавычки или обратные слэши (такие символы нуждаются в кодированном представлении или хотя бы в экранировании теми же back-slash'ами). Во-вторых, например, все серверы каталогов, ведущие своё происхождение от iPlanet без проблем умеют авторизовать по значению какого угодно вообще атрибута. Отсюда возникает резонный вопрос: так почему же AD, потомки iPlanet, Tivoli AM или даже какой-нибудь CommuniGate LDAP позволяют делать simple bind по чему-либо, отличному от DN? Да, это противоречит стандартам, но это не более, чем фича, которую вы можете использовать, а можете и не использовать. Фича, позволяющая клиенту «сэкономить» на одном лишнем LDAP-поиске, который тем не менее всё равно будет иметь место на уровне внутренней логики самого сервера каталогов, берущего, таким образом, «сей скорбный труд» по розыску DN, требуемого для simple BIND, на себя.
В любом случае вы можете и, мало того, — при написании LDAP-enabled кода вы просто обязаны использовать только DN для simple BIND'а. Проблемы же с этим возникают только у тех, кто смутно представляет, что такое эта загадочная технология LDAP, лежащая в основе AD и начинают «пороть горячку» или хуже того — уже откровенную отсебятину (я встречал даже окровенно странный код, автор которого на полном серьёзе предполагал, что baseDN в AD обязан состоять из чего-то вроде OU=Организация,DC=Раз,DC=Два).

Другим непонятным мне заблуждением, связанным с аутентификацией в AD является то, что якобы само по себе использование LDAP-каталога от Microsoft в качестве средства авторизации даст возможность пользователям получать доступ к сервисам организации по принципу SSO. Понятно, из чего исходят те наивные граждане, которые так думают: они просто не понимают, что AD — это часть гораздо более масштабного продукта Microsoft Windows Server, реализующего собственно логику доменов в сетях с рабочими станциями под управлением Windows, в том числе и SSO. При этом вполне очевидно, что сам по себе LDAP-катлог ни выдать Kerberos-тикет, ни проверить его не может — для этого нужно взаимодействие с другими компонентами Windows Server, которое на самом низком уровне обращения непосредственно по протоколу LDAP — здесь никак не реализовано. Если же вам всё же нужно реализовать SSO в Windows-домене — используйте Samba в UNIX или стандартные механизмы «общения» с контроллером домена из-под Windows. Причём использйте с осторожной оглядкой на то, что SSO обязан быть реализован не только на стороне сервера, но и на стороне клиента. Например, даже Microsoft Internet Explorer без дополнительной настройки и не подумает доставать из системных «загашников» билет Kerberos, выданный при логине в домене. Что уж говорить в этом плане о Firefox или Google Chrome… А ведь чаще всего нужна именно единая аутентификация пользователей на различных интранет-ресурсах организации, которые к тому же тоже далеко не всегда на Microsoft IIS хостятся (я такое встречал крайне редко — всё чаще встречаются Apache, nginx уже с ними).
Кстати, к написанию этого гневного опуса меня подтолкнула документация к SAMS, в которой чёрным по белому написано, что настройка аутентификации с использованием AD — это дело крайне непростое и, мол, пожалуйста, вопросов мне по этому поводу не задавайте, а лучше читайте зело полезную документацию, специально посвящённую этому вопросу. При этом SAMS умеет осуществлять доменную аутентификацию исключительно с использованием морально устаревшего ещё 10 лет назад протокола NTLM, а вся суть громкого термина «авторизация в Active Directory» там сводится, разумеется, к тому же самому набившему оскомину simple BIND'у. Но для того, чтобы просто проверять пароль пользователя в AD, нужно не документацию на technet.microsoft.com'е читать, а элементарно знать хотя бы «детсадовские» азы LDAP наподобие того, что такое DN и как делать search! Здесь нет ничего AD-специфичного и уж тем более сложного, ведь LDAP тем и хорош прежде всего что он, как швейцарский нож, открывает двери к пониманию великого множества продуктов, его использующих и позволяет взглянуть на многие частные проблемы с высоты общей технологии, объединяющей такие разные вещи, как, например, Windows Server и Lotus Domino.

3 комментария

avatar
Хорошо поругал, что тут сказать. Но толку от этогой записить чуть больше чем нисколько.
В забитых головах молодых специалистов размытые знания размылись еще сильнее.
Гораздо интереснее был бы разбор на примере обоих типов авторизаци и описание коротенько основных принципов. Это было бы круто.
avatar
Разбор — это как? Показать команду ldapsearch по AD-каталогу с BIND'ом по DN?
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.