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

Страницы: 1 ... 6 7 [8] 9 10
71
Работа с LDAP-клиентами / Помощь с LDAP клиентом в виде АТС
« Последний ответ от Akavir 06 Ноябрь 2020, 23:04:01 »
Добрый вечер! Старался выбрать нужный раздел для темы.

Речь совсем не про настройку АТС, речь про настройку сервера OpenLDAP. Задача состоит в том, чтобы АТС брала данные из каталога LDAP и обновляла информацию в контейнере. Проблема состоит в подключении к серверу, вся найденная информация по данному вопросу представлена на скане, прикрепленном к сообщению. Просьба направить в нужном направлении по настройке сервера LDAP.

Я пробовал вводить в поле User ID cn=admin,dc=panasonic,dc=local
но подключение не происходит. Я так понял, что нужна иная учетная запись с возможностью чтения каталогов LDAP, поэтому двигался в этом направлении. Также подозреваю, что для авторизации нужна запись, начинающаяся именно с uid.

Исходные данные:
1. АТС Panasonic NSX1000 с возможность подключения LDAP каталогов.
2. CentOS 7 с установленным OpenLDAP
3. Адресная книга по адресу ou=employees,dc=panasonic,dc=local которая успешно функционирует и загружается на телефонные аппараты с учетными данными cn=admin,dc=panasonic,dc=local и паролем

Я совсем новичок в LDAP, поэтому записал все команды, которы вводил при конфигурации сервера.

Последовательность настройки сервера:
1. Устанавливаем пакеты для OpenLDAP
yum install openldap*
2. Запускаем службу
systemctl start slapd
systemctl enable slapd

#Генерируем пароль и копируем его кэш
slappasswd
{SSHA}VsRTw20WYTiFsSaed75doks6rZMY4n9L

#Переходим в директорию с конфигурационными файлами
cd /etc/openldap/slapd.d/cn\=config
ls

#Проверяем значения в файле конфигурации базы данных olcDatabase
nano olcDatabase\=\{2\}hdb.ldif
#Создаем ldif файл для редактирования hdb.ldif
cd
nano db.ldif

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=panasonic,dc=local

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=admin,dc=panasonic,dc=local

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}VsRTw20WYTiFsSaed75doks6rZMY4n9L

#Модифицируем файл конфигурации db.ldif
ldapmodify -Y EXTERNAL -H ldapi:/// -f db.ldif
#Создаем ldif файл для редактирования monitor.ldif
cd
nano monitor.ldif

dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external, cn=auth" read by

dn.base="cn=admin,dc=panasonic,dc=local" read by * none

#Модифицируем файл конфигурации monitor.ldif
ldapmodify  -Y EXTERNAL -H ldapi:/// -f monitor.ldif
#Скопируем файл шаблона конфигурации и зададим права
cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
chown ldap:ldap /var/lib/ldap/*

#Добавляем шаблоны схем
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif

#Создаем ldif файл базы данных с нодами
nano base.ldif
dn: dc=panasonic,dc=local
dc: panasonic
objectClass: dcObject
objectClass: organization

dn: cn=admin,dc=panasonic,dc=local
objectClass: organizationalRole
cn: admin
description: LDAP Manager

dn: ou=employees,dc=panasonic,dc=local
objectClass: organizationalUnit
ou: employees

dn: ou=groups,dc=panasonic,dc=local
objectClass: organizationalUnit
ou: groups

dn: ou=equipment,dc=panasonic,dc=local
objectClass: organizationalUnit
ou: equipment

#Добавляем в базу данных информацию о нодах
ldapadd -x -D "cn=admin,dc=panasonic,dc=local" -W -f base.ldif
#Проверяем информацию
ldapsearch -D cn="admin,dc=panasonic,dc=local" -W -b "dc=panasonic,dc=local" objectClass=*
#Проверим, что учетная запись администратора имеет доступ к службе каталогов
ldapwhoami -WD cn=admin,dc=panasonic,dc=local
#Создадим пользователя для АТС
dn: uid=NSX1000,ou=equipment,dc=panasonic,dc=local
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
uid: NSX1000
cn: NSX1000
userPassword: 12345678
shadowLastChange: 15140
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
gidNumber: 1000
uidNumber: 1000
loginShell: /bin/false
homeDirectory: /home/NSX1000

#Установим пароль для пользователя NSX1000
ldappasswd -xZZWD cn=admin,dc=panasonic,dc=local -S uid=NSX1000,ou=equipment,dc=panasonic,dc=local
#Предоставляем доступ пользователю NSX1000 на чтение атрибутов учетных записей
nano nsx1000-acl-mod.ldif
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to *
  by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth" manage
  by * break
-
add: olcAccess
olcAccess: {1}to attrs=userPassword
  by self write
  by anonymous auth
-
add: olcAccess
olcAccess: {2}to *
  by self read
  by dn.base="uid=NSX1000,ou=equipment,dc=panasonic,dc=local" read

#Загрузим nsx1000-acl-mod.ldif, чтобы изменить ACL
ldapmodify -xZZWD cn=admin,dc=panasonic,dc=local -f nsx1000-acl-mod.ldif
#Проверим, что учетная запись NSX1000 имеет доступ на чтение каталогов
ldapsearch -D uid="NSX1000,ou=equipment,dc=panasonic,dc=local" -W -b "dc=panasonic,dc=local" objectClass=*
Если что-то необходимо предоставить, может какие-то файлы конфигурации, то скажите, пожалуйста.
72
Есть 3 машины (ubuntu):
-LDAP сервер
-NFS серве
-Клиент

На сервере NFS создаю шару и подтягиваю пользователей и группы LDAP. Устанавливаю на шару NFS права владения пользователя и группы ldap. Расшариваю папку клиенту.
На клиенте пользователи и группы с сервера LDAP подтянуты.

1) Если на клиенте сидишь, например, под локальным пользователем (права на шару назначены LDAP), монтирование проходит. Есть ли возможность каким то образом проводить аутентификацию на этапе монтирования NFS шары на клиенте?

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

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

С уважением, Егор.
74
Книги проекта 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
75
В этой теме вы можете оставлять свои замечания и предложения по усовершенствованию перевода книги Ивана Ристича "Рецепты OpenSSL" (https://pro-ldap.ru/tr/openssl-cookbook).
76
Простите, если ввёл Вас в заблуждение словом "правильно" =) . Оно относилось лишь работе с неочевидными возможностями инструмента 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-план? Мне кажется, Ваши опасения немного преувеличены.

Егор

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

Вы пишете статью про "правильное" формирование 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
78
Здравствуйте! А с какой целью Вы планируете добавлять ещё одну запись с тем же самым SPN?

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

LDAP-«аутентификация» — это антипаттерн. Статья на Хабре, перевод статьи Ryan Newington. О том, какие проблемы могут возникнуть при использовании операции LDAP Bind в качестве универсального способа аутентификации пользователей и приложений. Также даёт некоторое представление о настоящих сервисах аутентификации и авторизации (Kerberos, SAML, WS-Federation, OpenID и других).
Страницы: 1 ... 6 7 [8] 9 10
Эта страница

Содержание

Новости:
Форум проекта Pro-LDAP.ru
OpenLDAP 2.4 Руководство

Содержание

Введение в службы каталогов OpenLDAPБыстрое развёртывание и начало работыОбщая картина - варианты конфигурацииСборка и установка OpenLDAPНастройка slapd

 

Конфигурационный файл slapdЗапуск slapdКонтроль доступаОграниченияИнструментыМеханизмы манипуляции даннымиНаложенияСпецификация схемы

 

БезопасностьSASLTLSРаспределённая служба каталоговРепликацияОбслуживаниеМониторингПроизводительностьУстранение неполадок
Перевод официального руководства OpenLDAP 2.4 Admin Guide
Полное содержание здесь
LDAP для учёных-ракетчиков

Содержание

О книгеКонцепции LDAPОбъекты LDAPУстановка LDAPПримерыНастройкаРепликация и отсылкиLDIF и DSMLПротоколLDAP API

 

HOWTOНеполадкиПроизводительностьИнструменты LDAPБезопасностьЗаметкиРесурсы LDAPRFC и X.500ГлоссарийОбъекты
Перевод "LDAP for Rocket Scientists"
Полное содержание здесь
Ресурсы

Книги

Руководство OpenLDAP 2.4LDAP для учёных-ракетчиков

Другие

СтатьиТермины LDAPman-страницы OpenLDAP 2.4Список RFCКлиенты LDAPФайлы наборов схемы
Полезные ресурсы
Форум

 

Разделы форумаНепрочитанные сообщенияПоследние сообщения
Форум проекта
Главная

Pro-LDAP.ru

О проектеНовости проектаУчастникиСтаньте участником!Сообщите об ошибке!Об авторских правахСоглашения проекта
Присоединяйсь!