LDAP NetWare против LDAP OES

[Андрей Добров]

Имеется рабочая связка LDAP+NetWare для работы SSO на FortiGate
Т.е. работает устройство для разрешения выхода в инет. И пропускает как и в бордюре по информации о принадлежности пользователя к определенной группе.
Смотрит FortiGate на сервер NW 6.5.8 (eDirectory 8.8.5) j и запросы идут по LDAP. Работало лет 5 и без проблем.
Решил убрать NetWare и перевести забросы на OES 2015.sp1.

И ..... и выяснилось несколько ОРИГИНАЛЬНАЯ вещь. Я не могу с устройства FortGate выбрать необходимые группы. Они просто не отображаются.
В наличии видны группы только типа www и novlxtier.

Можно конечно и работать через назначения на пользователя и работает. Но это такой гемор с раздачей прав. Врагу только пожелаешь.
Вопрос - что такое может или не может отдавать сервер LDAP на OES 2015. И чем группы www и novlxtier отличаются от создаваемых в процессе текущей работы. Лично я не смог найти отличий.

[Константин Ошмян]

Хм, странно. Может, нужные группы просто не лежат в реплике, расположенной на сервере OES?
LDAP прекрасно работает при функционировании eDirectory и на NetWare, и на Linux-е. Скорее всего, отличаются какие-то настройки, специфичные для сервера (например, маппинг имён атрибутов LDAP <-> eDirectory или что-нибудь в этом роде).

[Иван Левшин aka Ivan L.]

Проверяйте реплики на сервере OES, www и novlxtier есть на каждом сервере OES и от наличия реплики они не зависят. LDAP что там, что там - одинаковый (надо, конечно, понимать, что есть и разница, т.к. сам LDAP на месте не стоит, а в NW никаких изменений давно не вносится). Маппинг - нет, не думаю, что он может быть причиной.
Еще один нюанс: если на OES поднят DSfW, то стоит помнить, что фактически на сервере два LDAP-сервера: "классический" слушает порты 1389 и 1636, на 389 и 636 сидит "самый православный", понимающий "стандарт" MS AD (который, мягко говоря, от нормального LDAP отличается чуть более, чем полностью). Это, кстати, основная причина того, почему в DNS/DHCP Management Console надо обязательно ставить галку "DSfW Server", иначе она подключиться не сможет. Возможно, проблема в этом.

[Андрей Добров]

Проверяйте реплики на сервере OES, www и novlxtier есть на каждом сервере OES и от наличия реплики они не зависят. LDAP что там, что там - одинаковый (надо, конечно, понимать, что есть и разница, т.к. сам LDAP на месте не стоит, а в NW никаких изменений давно не вносится). Маппинг - нет, не думаю, что он может быть причиной.
Еще один нюанс: если на OES поднят DSfW, то стоит помнить, что фактически на сервере два LDAP-сервера: "классический" слушает порты 1389 и 1636, на 389 и 636 сидит "самый православный", понимающий "стандарт" MS AD (который, мягко говоря, от нормального LDAP отличается чуть более, чем полностью). Это, кстати, основная причина того, почему в DNS/DHCP Management Console надо обязательно ставить галку "DSfW Server", иначе она подключиться не сможет. Возможно, проблема в этом.

С репликами и синхронизации предполагаю всё в порядке.
На NetWare 6.5.8 стояла реплика R\O.
Перенаправил запросы на Master реплику.

Дополнительно из удивительного - в разделе(точнее OU), где находиться сервер с мастер-репликой имеются 3 группы которые создавались при инсталляции, но видим только www и novlxtier.
Всё что бросается в глаза при сравнении свойств этих групп - это наличии в www и novlxtier атрибута uamPosixWorkstationList.

С пользователями нет ни каких проблем - видны во всех плоскостях...
В FortiGate имеется возможность манипулировать атрибутами по которым будет идти запросы с фильтрацией по cn/uid/uniqueID/member/...... Отрабатывает на все 100%. Буду выбирать\увижу именно те объекты для которых выставлю атрибут. Но только если в качестве источника LDAP сервер на NetWare.

[Иван Левшин aka Ivan L.]

Для того, чтобы найти, что именно не так в Вашей конфигурации, информации, к сожалению, очень сильно не хватает. Могу сказать, что никогда никаких проблем с LDAP ни в OES, ни в NW ни у меня, ни у моих заказчиков не было - в случае, когда использовалась дефолтная системная конфигурация сервисов, без "мегатуненха" шаловливыми ручками. Вот после этого - бывало, да.
RO-реплики, к слову сказать, не рекомендуются к применению совсем - они чуть более, чем совсем бесполезны. Единственное вменяемое для них применение: удаленный сервер, подключенный медленным и ненадежным диалапом, зачем их делать в обычной сети, мне неведомо.
Maintenance есть у Вашей организации? Откройте SR, будем решать. Ну или описывайте полностью конфиг Вашего сервера. Кроме того, попробуйте поискать группы с помощью ldapsearch и сравните с тем, что там видит/не видит FortiGate.

[Андрей Добров]

Для того, чтобы найти, что именно не так в Вашей конфигурации, информации, к сожалению, очень сильно не хватает. Могу сказать, что никогда никаких проблем с LDAP ни в OES, ни в NW ни у меня, ни у моих заказчиков не было - в случае, когда использовалась дефолтная системная конфигурация сервисов, без "мегатуненха" шаловливыми ручками. Вот после этого - бывало, да.
RO-реплики, к слову сказать, не рекомендуются к применению совсем - они чуть более, чем совсем бесполезны. Единственное вменяемое для них применение: удаленный сервер, подключенный медленным и ненадежным диалапом, зачем их делать в обычной сети, мне неведомо.
Maintenance есть у Вашей организации? Откройте SR, будем решать. Ну или описывайте полностью конфиг Вашего сервера. Кроме того, попробуйте поискать группы с помощью ldapsearch и сравните с тем, что там видит/не видит FortiGate.

С версии FortiOS 5.x появилась возможность применять SSO и используя ТОЛЬКО LDAP без дополнительных компьютеров и сервисов что у меня и работало. Имеется ещё одна возможность получить SSO для FortiGate- это применять агента от FortiNet для eDirecrory.
Компания Fortinet в лице её саппорта до окончательного вердикта по проблеме предложила использовать именно агента для eDirectory. Сейчас работает через агента не зависимо какой сервер подставляю для агента в качестве источника OES или NetWare.

Хотя для себя до сих пор не могу осознать что происходит. Я менял, только в одном месте IP и изменялось направление запросов.
Не понимаю ...... где может быть собака порыта.

[Иван Левшин aka Ivan L.]

При всем уважении, вот эти все слова про "FortiOS" и т.д. для меня ничего не значат. Это third party, я не уверен, что они тестировались на совместимость с нашей стороны.
Поймите меня правильно: я ни в коей мере не ругаю и не оцениваю их. Могу только сказать, что оба продукта (NW и OES) разработаны с учетом отраслевых требований и рекомендаций (RFC и т.д.), LDAP в них совершенно стандартный и я в первый раз вижу, чтобы при организации именно LDAP-соединения возникали вот такие чудеса. На моей памяти подобное было тогда, когда под "LDAP-запросом" использовалось неподобие имени MS (все эти CDATA[...] в запросе... некошерно как-то и 100% это не "стандартный LDAP", да и о соответствии Х.500 тут говорить не призодится) - вот тогда да.
На самом деле я полагаю, что драма - в том, как FortiOS формирует и посылает запрос. Начните с трассировки ndstrace с ключами +TAGS +TIME +LDAP. Если нужна помощь, перенаправьте вывод в файл (ndstrace file on в консоли ndstrace, только после этого обязательно set ndstrace=*R, чтобы обнулить файл лога). Смоделируйте проблему, получите проблему/ошибку, после чего погасите ndstrace, заархивируйте файл и покажите его.

[Доменика]

И всё таки они различаются!

Несколько лет назад.
Задача перейти с Zenworks 7 на Zeworks 11
Берем 3 продукта(программы) от компании Novell\MicroFocus. Всё родное...
- ZenWorks Suite 7. Работает.
- ZenWorks 11.4.3. Развернут.
- утилита ZenWorks Migration Utility v11.3.0.52757. Установлена.

Мастер реплика лежит на OES 2015.1

Запускам утилиту миграции - пробуем перенести объект типа аля аппликейшн в новый ZEN.
- Подключаемся к серверу с мастер репликой. Ok
- Подключаемся к серверу с ZEN 11. Ok
- Выбираем объект для миграции. Ok
- Запускам миграцию. Migration failed.

Получаем шиш на каком-то масле.

Если несколько изменить схему подключения, а именно подключиться к ЛЮБОМУ серверу в сети на NetWare - всё происходит на ура!

В описание сказано что для миграции не надо иметь клиентской части от Novell и все что необходимо это подключение по LDAP.

Подпишусь под сказанным одним из гуру этого форума - "Не мы такие - жизнь такая!" (с)

[Иван Левшин aka Ivan L.]

Доменика, Вы ищете черную кошку в черной комнате. Ни LDAP, ни реплики тут не при чем. ZENworks 7 хранит объекты в дереве, ZENworks 11 - в базе. По поводу "шиша" Костя уже все объяснил: проверяйте настройки серверов. LDAP в OES отличается только тем, что он свежее, т.е. поддерживает больше расширений. Отличия могут быть, действительно, на уровне mapping - или, действительно, нужных объектов просто нет в реплике (при работе через LDAP механизм referencing не работает).
В Вашем случае проблема может быть вообще где угодно - и в настройках LDAP, и в настройках ZEN11. Смотрите лог утилиты миграции. Я лично переносил ZEN7 в ZEN11 этой утилитой без проблем вообще. При этом дерево было уже на OES2015SP1.