Последние сообщения

Страницы: [1] 2 3 ... 10
1
Книги проекта Pro-LDAP.ru / Re: Книга "OpenLDAP и Ubuntu на практике"
« Последний ответ от egor 17 Июнь 2020, 13:00:58 »
Здравствуйте, sfmc!
Вы правы, там действительно не хватает этапа восстановления данных каталога. Перевод англоязычного ресурса предоставил Павел Булка (в оригинале, кстати, тоже нет этого этапа), а я не удосужился прогнать на макете все примеры. Приношу свои извинения.

Поправил текст. Спасибо за внимательность и неравнодушие!

С уважением, Егор.
2
Книги проекта Pro-LDAP.ru / Re: Книга "OpenLDAP и Ubuntu на практике"
« Последний ответ от sfmc 15 Июнь 2020, 19:36:03 »
Добрый день!
У меня вопрос по главе книги "10.2.1 Полная потеря сервера"

Там написано 

Цитировать
Где работаем: ldap-srv

Если сервер который крутит OpenLDAP сломается, то первым делом нам нужно будет найти другой или починить этот. Затем потребуется установить на него Ubuntu 14.04. Потом скопируйте на него файлы из резервной копии и выполните следующие команды:

#  apt-get install -y slapd ldap-utils krb5-kdc-ldap krb5-pkinit krb5-admin-server libnss-ldapd libpam-ldapd wamerican sudo-ldap
#  mv /etc/ldap /etc/ldap.install
#  cd / && tar zxvf /tmp/slapd.directory.20141215.tar.gz
#  update-rc.d slapd defaults
#  service slapd start
Это поможет Вам начать работать. Конечно, затем нужно будет перенастроить rsyslog. Смотрите раздел 2.3.


Мне кажется или там действительно не хватает пункта восстановления самой базы из бекапа?
такогоже как в главе "10.2.3 Повреждение данных (или человеческий фактор)"

zcat /root/backup/slapd/slapd.data.20141212.ldif.gz > /tmp/slapd.data.ldif
#  slapadd -v < /tmp/slapd.data.ldif
3
В этой теме вы можете оставлять свои замечания и предложения по усовершенствованию перевода книги Ивана Ристича "Рецепты OpenSSL" (https://pro-ldap.ru/tr/openssl-cookbook).
4
Простите, если ввёл Вас в заблуждение словом "правильно" =) . Оно относилось лишь работе с неочевидными возможностями инструмента ktpass, чтобы кто-то, решающий задачу формирования keytab-файла с несколькими SPN, избежал тех плясок вокруг KVNO, с которыми столкнулся я сам. Ни в коем случае я не претендую на "правильность" распределения сервисов по серверам или планирования dns-именования. Вообще, в unix-среде не принято позиционировать свои решения как единственно правильные =) .

С другой стороны, это решение оказалось жизнеспособным, уже сколько лет прошло, а ребята не жалуются =) . Вполне логично, если в конторе WINDOM Inc обращаются на корпоративный сайт по адресу http://windom.net , а не http://webserver.windom.net .

... описываете то, что в keytab включается помимо SPN-записи с fqdn сервера(или службы) ещё и SPN-запись с fqdn имеми домена оправдывая это "удобстовом" (типа теперь вообще можно будет разные имена использовать на веб-сервере)...
Перечитал статью, про подобное "удобство" там не сказано ни слова =( . Речь шла о том, что если www и sandbox являются CNAME для webserver, то для них не нужно добавлять отдельные SNP в keytab-файл, достаточно SPN для webserver.

Но смысл в том, что это неправильно и так делать нельзя. Это противоречит логике управления SPN в Active Directory.
Представьте, что условно завтра Вам потребуется развернуть ещe 2,3,4... новых веб-сервера аналогичных, и чтобы для каждого сервера поддерживалась кучка разных SPN...и следуя Вашей логике, можно будет сделать аналогичные keytab-файлы для каждого из этих серверов. Но это совсем не так, ибо утилиты управления SPN проверяют уникальность SPN-записей во всём домене.
Вы можете проверить это сами. Просто попытайтесь вручную создать одну и туже SPN-запись вида HTTP/windom.net@WIMDOM.NET двум разным учётным записям.

setspn -A HTTP/windom.net SERVER1
setspn -A HTTP/windom.net SERVER2

Охотно соглашусь, что Вы правы. Но снова хочу спросить: зачем так делать? Или лучше так: кто в здравом уме будет пытаться внедрять такой нелепый dns-план? Мне кажется, Ваши опасения немного преувеличены.

Егор

5
Егор, наверно Вы меня не поняли.

Вы пишете статью про "правильное" формирование keytab-файла и при этом описываете то, что в keytab включается помимо SPN-записи с fqdn сервера(или службы) ещё и SPN-запись с fqdn имеми домена оправдывая это "удобстовом" (типа теперь вообще можно будет разные имена использовать на веб-сервере). Но смысл в том, что это неправильно и так делать нельзя. Это противоречит логике управления SPN в Active Directory.
Представьте, что условно завтра Вам потребуется развернуть ещe 2,3,4... новых веб-сервера аналогичных, и чтобы для каждого сервера поддерживалась кучка разных SPN...и следуя Вашей логике, можно будет сделать аналогичные keytab-файлы для каждого из этих серверов. Но это совсем не так, ибо утилиты управления SPN проверяют уникальность SPN-записей во всём домене.
Вы можете проверить это сами. Просто попытайтесь вручную создать одну и туже SPN-запись вида HTTP/windom.net@WIMDOM.NET двум разным учётным записям.

setspn -A HTTP/windom.net SERVER1
setspn -A HTTP/windom.net SERVER2
6
Здравствуйте! А с какой целью Вы планируете добавлять ещё одну запись с тем же самым SPN?

Егор
7
Здравсвуйте, Егор.
 
Прочитал Вашу статью и у меня возникают большие сомнения относительно правильности использования метода, когда добавляется SPN с именем домена (без имени хоста или сервиса) к какой-либо учётной записи (имеется ввиду HTTP/windom.net@WIMDOM.NET).
А что Вы будете делать, когда потребуется создать аналогичные записи для других сервисов или серверов?
Повторное создание SPN с именем HTTP/windom.net@WIMDOM.NET для другой учётной записи уже будет выглядеть как явная ошибка, с точки зрения той же утилиты setspn, так как перед регистрацией SPN она всегда проверяет уникальность SPN-записей во всём каталоге Active Directory.
8
Общий раздел / Ссылки, добавленные в 2020 году
« Последний ответ от egor 26 Май 2020, 05:06:10 »
Ссылки, добавленные в 2020 году:

LDAP-«аутентификация» — это антипаттерн. Статья на Хабре, перевод статьи Ryan Newington. О том, какие проблемы могут возникнуть при использовании операции LDAP Bind в качестве универсального способа аутентификации пользователей и приложений. Также даёт некоторое представление о настоящих сервисах аутентификации и авторизации (Kerberos, SAML, WS-Federation, OpenID и других).
9
Общий раздел / Re: Postfix + ldap
« Последний ответ от egor 26 Май 2020, 02:02:25 »
По вопросу с отсылками (referrals). Теоретически, поисковый запрос LDAP можно заставить автоматически следовать по возвращаемым отсылкам и в настройках LDAP-карт Postfix предусмотрена опция chase_referrals:
chase_referrals = yesНо проблема в том, что переход по отсылкам происходит анонимно, а AD требует аутентификации, поэтому фактически в случае с AD  переход по отсылкам не выполняется.

То есть напрямую средствами Postfix задачу с такой рекурсией в AD решить не удастся. Можно в качестве обходного пути попытаться поднять прокси-каталог на OpenLDAP с бэкендом slapd-meta, который "склеит" AD-шные служебные каталоги в один, и перенаправить Postfix на него. Но стоит ли в данном случае игра свеч?

Егор
10
Общий раздел / Re: Postfix + ldap
« Последний ответ от egor 25 Май 2020, 05:32:53 »
Простите, что не сразу отвечаю -- дел очень много, даже в выходные =( .

По поводу virtual_transport я посмотрел в документации postfix -- всё-таки это не про транспортировку почты, а про раскладку писем в ящики. За транспортировку в чистом виде отвечает как раз transport_maps, так что всё верно. Поэтому предлагаю сделать так:
transport_maps = ldap:/usr/local/etc/postfix/transport/ldap_transport_map.cf, hash:/usr/local/etc/postfix/transport

А virtual_transport закомментировать вообще.

По второму вопросу посмотрю чуть позже.
Страницы: [1] 2 3 ... 10