Авторизация с использованием LDAP
Здравствуйте! Пытаюсь настроить авторизацию на Linux mint 17 через Active Directory 2003, делаю по статье Ссылка.
getent passwd не выводит доменных пользователей, но в логах появляется ошибка:
Если в ldap.conf выстовляю binddn Administrator@domen.loc то в логах ничего нету
Но зачем. У меня сабж авторизуется в АD (samba4). Всё сделал через samba
Вы твёрдо убеждены в том, что объект с DN=«cn=Administrator,dc=domen,dc=loc» — в Вашем каталоге вообще есть?
Пользуйтесь двойными кавычками только если Вам нужна интерполяция содержимого, либо если строка уже содержит одинарные кавычки! В противном случае использование одинарных кавычек — это не только быстрее (shift целее будет), но и безопаснее.
Использование «троекратно усиленной» опции -L для ldapsearch позволяет Вам видеть только результат запроса (если он есть), подавляя вывод служебной информации.
Указывай имя юзера для опции -D в виде DOMAIN\username
Авторизуетесь в AD через samba4 с использоваием winbind ??
Да. Авторизуюсь через samba4 winbind, в аналоге AD на samba4.
через winbind у меня работает, но мне нужен вариант через ldap пишут что через его лучше работает
sssd настрой, а nss-ldap удоли
указывал полный путь ничего не изменилось
Поставил sssd ошибка при запуске
Это как-же через ldap будет лучше? Что тебе предоставит ldap. Вход в систему? Не, ну если тебя такое устраивает то ок. А winbind можно запилить, чтоб билеты получало, сопровождало их, и ходить в шарах домена без пароля, получать корпоративные ресурсы через kerberos без пароля, в Интернет без пароля выходить.
через winbind у меня работает, но мне нужен вариант через ldap пишут что через его лучше работает
Я бы сказал: более предсказуемо, поскольку это всё равно что сравнивать federation access manager с кучей плагинов и просто базу данных в чистом виде. Понятно, что если данные запрашивать непосрещдственно из хранилища оных — это куда более прямолинейно и просто, нежели к тем же данным продираться через хитроумную логику какого-нибудь OpenAM’а. Тем не менее с точки зрения функциональности и гибкости конечно AM использовать логичнее.
winbind кстати тоже LDAP использует, что прекрасно видно из его логов при подробной отладке.
Записки Линуксоидов
У программиста есть два состояния: «Втупляю» и «Попёрло». (C) Gen
пятница, 1 августа 2014 г.
Авторизация через ldap на Linux сервере
В системах с большим числом машин почти всегда встает вопрос централизованного управления пользователями и группами (авторизации, аутентификации т.д.). Для этого удобно использовать LDAP. В этой статье я расскажу как настроить аутентификацию через LDAP и ограничить доступ к машине только для определенных групп.
Настройка авторизации через LDAP
Для начала нужно установить пакеты обеспечивающие нужные нам функции:
Во время установки нас спросят следующее:
- URI of LDAP server — URI нашего сервера, например, ldap://ldapserver.corp.local (ldap может быть доступен по протоколам ldaps и ldapi).
- Name of the LDAP search base — базовый каталог для поиска, обычно он похож на домен на котором расположен сервер, в нашем примере это будет dc=corp,dc=local
- Make local admin database admin — позволит локальным администраторам изменять учетные записи в LDAP, обычно нужно ответить нет.
- Does the LDAP database require login — требуется ли логиниться в LDAP для того чтобы авторизовать пользователя, как правило нет.
После этого нужно немного подправить файл /etc/ldap.conf:
Если ваш LDAP сервер использует зашифрованное соединение, то нужно скопировать корневой сертификат, которым подписан сертификат сервера LDAP в папку /etc/ssl/certs.
Включаем авторизацию через ldap:
И перезапускаем демоны отвечающие за авторизацию, чтобы новая конфигурация применилась:
Если все настроено верно, то мы сможем получить информацию о каком-либо пользователе из LDAP
Теперь пользователи из LDAP смогут авторизоваться на нашем компьютере и даже менять свой пароль при помощи passwd.
Автоматическое создание домашних директорий пользователям из LDAP
Ограничение авторизации
Помимо этого метода можно сделать через nss_base_ это позволит указывать LDAP на какие машины разрешено заходить пользователю или группе.
Information Security Squad
stay tune stay secure
Аутентификация LDAP в Linux
Это руководство покажет вам, как держать своих пользователей в LDAP и аутентифицировать некоторых из них.
Я не буду показывать, как устанавливать определенные пакеты, поскольку это зависит от дистрибутива / системы.
Я сосредоточусь на «чистой» конфигурации всех компонентов, необходимых для аутентификации / хранения пользователей в LDAP.
Предполагается, что вы переходите от обычной аутентификации passwd / shadow, но она также подходит для людей, которые делают это с нуля.
Требования
Введение
Мы хотим добиться того, чтобы наши пользователи сохранялись в LDAP, аутентифицировались через LDAP (direct или pam) и чтобы вы имели некоторый инструмент для управления этими всем понятным для человека способом.
Таким образом, мы можем использовать все программное обеспечение, поддерживающее LDAP, или возвратимся к модулю LDAP PAM, который будет действовать как шлюз PAM-> LDAP.
Более подробную информацию о идее LDAP можно найти в Википедии: LDAP wikipedia
Настройка OpenLDAP
OpenLDAP состоит из slapd и slurpd-демона.
Этот способ охватывает один сервер LDAP без репликации, поэтому мы сосредоточимся только на slapd.
Я также предполагаю, что вы установили и инициализировали установку OpenLDAP (в зависимости от системы / распространения).
Если да, перейдем к части конфигурации.
В моей системе (Gentoo) конфигурация OpenLDAP хранится в /etc/openldap, нас интересует файл /etc/openldap/slapd.conf.
Но сначала мы должны сгенерировать пароль для администратора LDAP, чтобы поместить его в файл конфигурации:
Конфигурация выглядит так:
Не забудьте изменить суффикс и пути.
Это варианты с некоторыми базовыми ACL, необходимыми для изменения паролей пользователем.
Если вам нужна дополнительная функциональность, прочитайте руководство по OpenLDAP.
Теперь, когда у нас есть надлежащая конфигурация для slapd, мы можем запустить демон:
Пожалуйста, не забудьте сделать что-то подобное в файле конфигурации, отвечающем за аргументы, переданные slapd (путь должен указывать на slapd.sock):
Теперь мы можем проверить, работает ли openldap и работает ли он правильно.
У нас еще нет данных в каталоге, но мы можем попытаться связать их как cn = Manager, dc = domain, dc = com.
Когда вас попросят ввести пароль, вы должны использовать тот, который вы создали (конечно, его текстовая версия :):
Миграция / добавление данных в каталог
Теперь, когда у нас есть работающий сервер LDAP, мы должны заполнить его данными, либо создать, либо перенести записи.
Я покажу вам, как переносить существующие записи из обычных /etc/ passwd, /etc/shadow, /etc/groups
Первый шаг — настроить mogrationtools.
Конфигурационный файл в Gentoo находится в /usr/share/migrationtools/migrate_common.ph.
Как правило, вам нужно изменить только эти моменты:
Теперь вы готовы перенести данные (на самом деле это работает даже без команды export):
Теперь у нас есть данные в формате, понятном серверу LDAP.
Пожалуйста, откройте один из файлов с текстовым редактором, чтобы привыкнуть к синтаксису.
После этого мы можем добавить данные из ldifs.
Вы можете попробовать найти некоторые данные:
Конфигурация клиента
Под клиентом я имею в виду машину, которая подключается к LDAP-серверу для получения пользователей и авторизации.
Это может быть и машина, на которой работает LDAP-сервер.
В обоих случаях мы должны отредактировать три файла: /etc/ldap.conf, /etc/nsswitch.conf и /etc/pam.d/system-auth
Начнем с ldap.conf, клиента ldap:
Теперь пришло время для nsswitch.conf и pam
Добавьте в nsswitch.conf:
И измените system-auth (или все, что у вас есть, например login, sshd и т. д.):
Время проверить его. Лучший инструмент для этого — хороший старый getent.
Выберите пользователя из вашей системы и введите:
Вы должны получить результат дважды, если nss_ldap работает нормально.
По часть pam , работоспособность может быть протестирована путем удаления пользователя из /etc/passwd и попытки входа в систему через ssh.
Apache mod_auth_ldap
Чтобы получить авторизацию LDAP в apache, вам необходимо загрузить модуль mod_auth_ldap
Теперь достаточно изменить .htaccess:
Обратите внимание, что этот метод можно также использовать для авторизации Subversion WebDAV
Средства администрирования LDAP
Есть несколько инструментов, которые я рекомендую использовать для администрирования сервера OpenLDAP
LDAP-«аутентификация» — это антипаттерн
Сегодня в любой организации есть LDAP-каталог, наполненный пользователями этой организации. Если присмотреться, вы найдете одно или несколько приложений, которые используют этот же каталог для «аутентификации». И кавычки здесь неспроста, ведь LDAP — это протокол доступа к каталогам, спроектированный для чтения, записи и поиска в службе каталогов. Это не протокол аутентификации. Термин «LDAP-аутентификация», скорее, относится к той части протокола (операции bind), где определяется, кто вы такой, и какие права доступа имеете к информации каталога.
Со временем LDAP стал службой аутентификации де-факто. Широко распространенные и доступные службы LDAP, такие, как Active Directory, стали лакомым кусочком для разработчиков программного обеспечения, которые хотят встроить аутентификацию в свои продукты. Клиентские библиотеки LDAP доступны практически для любого фреймворка, а реализовать интеграцию относительно легко.
Но несмотря на то, что применение LDAP может помочь решить задачу внедрения аутентификации пользователей в различных приложениях компании, оно создает множество проблем. В отличие от специально предназначенных протоколов аутентификации, при использовании LDAP возникают различные уязвимости информационной безопасности.
Чтобы разобраться в том, что это за уязвимости, сперва нужно понять, как работает LDAP-аутентификация.
Как работает LDAP-аутентификация
Представьте себе следующую ситуацию (она далека от реальности, но отлично передает суть).
Предположим, я делаю заказ в интернет-магазине так, чтобы его доставили мне домой в мое отсутствие. Курьер приезжает и оставляет под дверью записку с текстом «извините, мы вас не застали» и просит меня забрать заказ в ближайшем пункте выдачи в удобное время. В пункте выдачи сотрудник спрашивает мое имя, адрес и просит ключи от дома, чтобы подтвердить мою личность. Затем сотрудник службы доставки приезжает ко мне домой и открывает дверь моим ключом. Он заходит внутрь, чтобы убедиться, что я там живу, например, по фотографиям на стене или по имени адресата на корреспонденции. После этого сотрудник возвращается в пункт выдачи и сообщает мне, что успешно подтвердил мою личность, и я могу получить свою посылку! Ура!
Помимо проблем с логистикой, данная ситуация полна других вопросов. Что, если недобросовестный проверяющий сделал копию моего ключа? Или он оставил ключ надолго без присмотра, и это сделал кто-либо еще? Что, если на проверяющего напали и забрали мой ключ? Когда я отдаю ключ от своей квартиры незнакомцу, я не могу быть уверен в его порядочности и своей безопасности.
К счастью, в реальном мире у нас есть документы для подтверждения личности, например, водительские права или паспорт, которые выданы государственными органами, и их подлинность не вызывает сомнений. Я могу предоставить эти документы курьеру для собственной идентификации без передачи ключей.
В мире LDAP мы все еще должны передавать наши ключи, чтобы открыть дверь от нашего имени. Мы передаем наш пароль стороннему лицу, и он пытается с его помощью проникнуть на сервер LDAP. Если ему удается получить доступ, мы не можем быть уверены, что наши учетные данные не скомпрометированы. При этом злоумышленник получит не только возможность разблокировать дверь LDAP, но и доступ к любому приложению, использующему те же учетные данные.
К счастью, в более полном мире аутентификации у нас также есть паспорта и водительские права! Протоколы аутентификации, такие как Kerberos, SAML и OpenID Connect, выпускают токены третьим лицам. Токены подтверждают, что вы являетесь тем, за кого себя выдаете, и нет необходимости передавать кому-либо свои ключи. Поскольку LDAP никогда не разрабатывался как протокол аутентификации, соответствующие механизмы у него отсутствуют.
Недостатки LDAP как системы аутентификации
В 2007 году Шумон Хак выпустил фантастическую статью (LDAP Weaknesses as a Central Authentication System), в которой он описывает три конкретные проблемы при использовании LDAP в качестве системы аутентификации.
1. Приложение, вероятно, недостаточно защищено, чтобы оперировать учетными данными
Автор подчеркивает, что защитить от атаки небольшой набор серверов аутентификации гораздо проще, чем защитить большое количество серверов приложений.
В своем большинстве серверы аутентификации, как правило, находятся под тщательным присмотром специалистов, обладающих значительным опытом в области информационной безопасности.
С другой стороны, серверы приложений имеют совершенно иной уровень безопасности и более подвержены риску компрометации. Они менее защищены, работают с более сложными программными стеками и с большей вероятностью имеют уязвимости. И чаще они находятся под управлением людей, которые не имеют глубоких знаний о безопасности. Построение правильной системы безопасности — сложнейший процесс, в котором очень легко допустить ошибку.
Проблема заключается в том, что если один сервер приложений скомпрометирован, то все учетные данные, которыми пользовались их владельцы во время атаки, также скомпрометированы. Под угрозой находится и любая другая система, которая использует тот же каталог LDAP для аутентификации.
2. Сервер LDAP не может обеспечить безопасность механизма аутентификации, используемого для получения учетных данных
LDAP-сервер не может гарантировать безопасность транзакции. Несмотря на то, что LDAP-сервер, например, может обеспечить принудительное выполнение операции bind по TLS, чтобы гарантировать, что учетные данные не передаются в открытом виде, сам сервер никогда не принимал никакой роли в получении учетных данных от пользователя. Существует риск, что приложение будет получать пароль по небезопасному каналу.
3. Пользователь вынужден делиться своим секретом аутентификации с третьей стороной
Пароль пользователя или секрет аутентификации должен оставаться секретом. Он должен быть известен только самому пользователю и системе аутентификации. При использовании LDAP-аутентификации пользователь вынужден поделиться своим секретом с третьей стороной, чтобы она затем смогла использовать данный секрет для взаимодействия с LDAP-каталогом от имени пользователя.
Важно упомянуть, что при использовании специально предназначенных протоколов аутентификации, таких как Kerberos, и даже с более раннего — NTLM, секрет пользователя никогда не передается по сети. Клиентское устройство и сервер используют криптографические операции, чтобы доказать друг другу, что у них один и тот же секрет и при этом даже не обмениваются самим секретом.
К пунктам Шумона Хука добавлю описание нескольких нюансов LDAP-аутентификации, основываясь на собственном опыте. Прежде всего, тема касается использования Active Directory.
4. Многие разработчики знают о механизмах работы LDAP недостаточно, чтобы правильно его использовать
В одном из моих прошлых постов блога описывается, как анонимные и неаутентифицированные bind’ы позволяли обхитрить разработчиков приложений и заставляли пропускать неавторизованных пользователей. Возможность выполнения операции bind без проверки подлинности — одна из тонкостей протокола, о которой не знают даже самые опытные специалисты по LDAP.
Каталоги устроены непросто и способны хранить огромное количество организационной информации и предоставляют множество настраиваемых способов ее хранения. Я видел очень много случаев, когда разработчик приложения предполагал, что существует определенный класс объекта или атрибут, а когда их не обнаруживалось, приложение падало. Для аутентификации пользователя не должны требоваться и применяться знания о структуре данных, хранящихся в каталоге. Протокол аутентификации должен абстрагироваться от деталей хранилища объектов, расположенного уровнем ниже.
5. Администраторы приложений зачастую не настраивают LDAP-клиенты корректным образом
При управлении Active Directory в большой распределенной среде есть один неприятный нюанс: трудно определить, какие конкретно приложения используют Active Directory в качестве LDAP-каталога, и как именно администраторы приложений настроили LDAP-клиент.
Ниже представлены примеры ужасов некорректной настройки.
- Хардкодинг DN в приложениях или использование DN при выполнении операции bind. Постоянно случаются неприятности при переименовании или перемещении объектов внутри директории, а все потому, что кто-то где-то захардкодил DN. (Примечание для тех, кто выполняет простые операции bind с Active Directory: нет необходимости использовать DN. Active Directory также предоставляет альтернативные форматы DN, которые являются более надежными, чем использование традиционного формата).
- Для операции bind используется не сервисный аккаунт, а персональный аккаунт разработчика или администратора (представьте, что будет, когда владелец аккаунта покинет компанию).
- Отправка паролей в открытом виде на 389-й порт.
- Существуют приложения, где чекбокс «Валидировать сертификат» не является обязательным при подключении к AD с использованием TLS (порт 636). Почему такое вообще допустимо? Как можно передать пароль стороннему сервису, не убедившись в его достоверности?
Заставить LDAP-клиент работать легко. Но только тот факт, что он работает, не означает, что конфигурация правильная.
6. LDAP-аутентификация и современные сервисы аутентификации взаимоисключают друг друга
Приложение, использующее LDAP для аутентификации, всегда будет вынуждено опираться на имена пользователей и пароли. Попытка реализовать современные технологии, такие как многофакторная аутентификация и единый вход, практически невозможна (если только вы не собираетесь внедрять свои собственные технологии, что само по себе является плохой идеей). Альянс FIDO стремится сделать пароли пережитком прошлого, а каждое приложение, использующее аутентификацию LDAP, будет помехой на пути к беспарольной политике.
Какие есть варианты?
Сегодня веб-приложения действительно могут обойтись без LDAP-аутентификации. Существует множество прекрасных веб-протоколов аутентификации, таких как SAML, WS-Federation и OpenID Connect, которые не требуют учетных данных пользователя для работы со сторонними приложениями. Бесчисленное количество продуктов предоставляют эти услуги, включая Active Directory Federation Service (встроенные в Windows Server) или сторонние сервисы, такие как Microsoft Azure AD, Okta, Ping и другие. Если в организации нет федеративного IdP, первое, что нужно сделать — внедрить его.
Главное, на что стоит обратить внимание при выборе нового ПО — поддержка современных протоколов аутентификации. Даже если приложение требуется бизнесу здесь и сейчас, не стоит спешить с выбором решения, особенно, если этот выбор ограничен только продуктами с LDAP-аутентификацией. Стоит попробовать донести до выбранного вендора необходимость доработки продукта с использованием более современных протоколов аутентификации. Возможно он прислушается и пересмотрит свой план разработки.
Число десктоп-приложений с «толстым клиентом», поддерживающих современные протоколы аутентификации, растет, и это действительно радостная тенденция. Эти приложения обычно были оплотом LDAP-аутентификации. Растет число SDK, таких, как Microsoft Authentication Library (MSAL), которые позволяют разработчикам легко добавлять поддержку современных сервисов аутентификации в свои мобильные и десктоп-приложения.
В конечном счете, стоит признать, что в сегодняшней реальности не все приложения поддерживают современные протоколы аутентификации, и, возможно, никогда и не будут. Внедрение полного запрета LDAP-аутентификации, вероятно, невозможно ни в одной организации. Однако ни в коей мере не стоит поощрять применение LDAP-аутентификации внутри организации. Использование LDAP следует рассматривать только при отсутствии других вариантов.