Distribution Lists на Groupwise 2012

[caxap]

Была попытка перенести GW8 с NetWare на GW2012 на Linux.

Была выявлена проблема при создании новых Distribution Lists.
В свойствах E-mail Address отсутствует возможность, как автоматического заполнения так и ручного ввода.
Это такое поведение именно с GW2012?
Всё что было создано на GW8 до перехода осталось в рабочем состоянии, но не нельзя редактировать.
В C1 под Linux данное поле вообще не активно.

Кто-то сталкивался? Или может посмотреть у себя?
Надо понять что происходит.

[Dimerson]

на 2012 нет проблем c distribution lists.

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

ПОддержу, никаких проблем быть не должно. Как выполнялась миграция, не было ли ошибок? Надеюсь, условие конвертирования заглавных символов в прописные в именах файлов при миграции - выполнено?

[Dimerson]

может какая база не обновилась на 2012 версию ?

У меня есть книжки Даниты по обновлению на 12 весрию (бандл) - я покупал тогда как раз с NW на Linux базы переносил. Там перенос баз исчерпывающе описан.
И есть ее последняя по переезду на 14. потом она на пенсию ушла.
Могу поделиться.

[caxap]

может какая база не обновилась на 2012 версию ?

У меня есть книжки Даниты по обновлению на 12 весрию (бандл) - я покупал тогда как раз с NW на Linux базы переносил. Там перенос баз исчерпывающе описан.
И есть ее последняя по переезду на 14. потом она на пенсию ушла.
Могу поделиться.

Буду обязан.......

[caxap]

ПОддержу, никаких проблем быть не должно. Как выполнялась миграция, не было ли ошибок? Надеюсь, условие конвертирования заглавных символов в прописные в именах файлов при миграции - выполнено?

Думаю не верно объяснил.
Если использовать Distribution Lists внутри ГВ - проблем нет.
Объект создаётся и при отправке сообщения на Distribution Lists - сообщения доставляются пользователям.
Есть софт - антиспам, который стоит перед GW и на первом этапе работы при приёме сообщений лезет по LDAP в eDirectory и ищет у объектов атрибут mail, где должна располагаться запись об электроном адресе.
В GW2012 при создании объекта Distribution Lists это поле не создаётся в принципе. В GW 8 у Distribution Lists этот атрибут имеется и к тому же был заполнен автоматически.

У меня в наличии 2 ConsoleOne от GW8 на винде и от GW2012 на Linux.
На винде поле для емайл адреса имеется и можно редактировать, но не запоминается изменения. Точнее - при повторном обращении к объекту - поле пустое.
На Linux в С1 аналогичное поле у объекта имеется но редактировать не даёт. Поле не активно.
Если я произведу переименование старого объекта Distribution Lists и сделаю синхронизацию, то адрес в нужном поле измениться. Это к вопросу что первично изменения в eDirectory или GW.
Вопрос - если я ручками добавлю атрибут в eDirectory конкретному объекту - не грохнется база ГВ после синхронизации. Может в GW2012 изменилась идеология использования Distribution Lists или есть косяк который я ещё не вижу.

[Dimerson]

Я тут планирую вместо GWAVA развернуть Антиспам/Антивир Appliance от Kaspersky.
По части интеграции он мОгет ldap. Я уже прикидываю что и как.
И прикидываю что надо поднять LDAP на стороне GroupWise (в 12- версии это делает вроде бы GWIA, в 14+ настраивается на стороне MTA (вкладка LDAP) но поднимает gwadmiservice - оно порт LDAP слушает) а не на стороне eDir. Ибо в новых GW eDir штука факультативная и чтобы все заколосилось надо поднять нормальную синхронизацию Groupwise <-> Edir.

У меня на стенде я попробовал запросить группы (суть Distribution Lists) через LDAP со стороны GroupWise:

ldapsearch -h 192.168.27.222 -p 1389 -D "cn=admin,ou=TEST-PO,ou=TEST-DOM,o=TEST-GW" -w <ТЕСТОВЫЙ СУПЕРПАРОЛЬ> -s sub -b "o=TEST-GW" "(&(objectclass=group))"

И вот что оно выдало :
...................................
# UsersCH, TEST-PO, TEST-DOM, TEST-GW
dn: cn=UsersCH,ou=TEST-PO,ou=TEST-DOM,o=TEST-GW
mail: UsersCH@test.lan
sn: UsersCH
cn: UsersCH
objectClass: top
objectClass: group
objectClass: groupOfNames
givenName: UsersCH
member: cn=AstemesovB,ou=TEST-PO,ou=TEST-DOM,o=TEST-GW
member: cn=ErmuhanovA,ou=TEST-PO,ou=TEST-DOM,o=TEST-GW
gwLdapId: 0C17AB6BFC45CF4B83570C17AB6BFC45
gwDirectoryId: TEST
gwLdapDn: cn=SomeList,ou=GwGroups,o=test
...................................

Запрашиваю пользователей.

ldapsearch -h 192.168.27.222 -p 1389 -D "cn=admin,ou=TEST-PO,ou=TEST-DOM,o=TEST-GW" -w <ТЕСТОВЫЙ СУПЕРПАРОЛЬ> -s sub -b "o=TEST-GW" "(&(objectclass=person))"
.....
# AstemesovB, TEST-PO, TEST-DOM, TEST-GW
dn: cn=AstemesovB,ou=TEST-PO,ou=TEST-DOM,o=TEST-GW
mail: AstemesovB@test.lan
sn: Astemesov
cn: AstemesovB
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: user
givenName: Baltabay
telephoneNumber: +7-(3822)-345345
gwLdapId: 03546FC87271664591B503546FC87271
gwDirectoryId: TEST
gwLdapDn: cn=User1-1,ou=DepartmentOne,o=test
displayName: Baltabay Astemesov

# ErmuhanovA, TEST-PO, TEST-DOM, TEST-GW
dn: cn=ErmuhanovA,ou=TEST-PO,ou=TEST-DOM,o=TEST-GW
mail: ErmuhanovA@test.lan
sn: Akylbek
cn: ErmuhanovA
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: user
givenName: Ermuhanov
telephoneNumber: +7-(3833)-854876
gwLdapId: AC3DBDD30DCB9F4CE8A3AC3DBDD30DCB
gwDirectoryId: TEST
gwLdapDn: cn=User1-2,ou=DepartmentOne,o=test
displayName: Ermuhanov Akylbek
.....

У меня на стенде синхронизация работает в обе стороны.
В общем поглядите в эту сторону.
Может получится.
Сразу скажу что 12 весрию в этом плане не трогал но почти уверен что будет так же.

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

В GW всегда собственная БД GW (и файлы конфигурации) были первичны. К1 - всего-навсего средство работы с файлами БД, т.е. при синхронизации первична таки БД, то, что в eDirectory с БД не совпадает - идет лесом. Если есть желание поспорить, предлагаю задуматься: зачем К1 просит путь к БД домена при подключении к GW? Правильно, чтобы ковыряться в БД домена напрямую.
Возможно, проблема в версиях плагина или К1. Групповые рассылки помню смутно (почти не применял, когда админил), как оно выглядело в 6/8/2012 - не помню, сейчас это группы, у которых есть соответствующий атрибут.

[Dimerson]

Оно всегда было группой в рамках GW. И можно сделать двунаправленную синхронизацию в/из Edir группы соответствующей Distribution List.

[Dimerson]

Дошли руки потестить на живом 2012.

LDAP поднят на GWIA. Порт отличный от дефолтного. В GWIA ACL разрешены аттрибуты на отдачу.

ldapsearch -P 2 -x -h <GWIA_Address> -p <GWIA_LDAP_PORT> выгребает домены, постофисы, юзверей и алиасы

а дистрибушн листы нет.

2014 отдает все (уверен на 99%). Если надо 100% уверенности могу проверить на стенде c 2018.

[skoltogyan]

Дошли руки потестить на живом 2012.

LDAP поднят на GWIA. Порт отличный от дефолтного. В GWIA ACL разрешены аттрибуты на отдачу.

ldapsearch -P 2 -x -h <GWIA_Address> -p <GWIA_LDAP_PORT> выгребает домены, постофисы, юзверей и алиасы

а дистрибушн листы нет.

2014 отдает все (уверен на 99%). Если надо 100% уверенности могу проверить на стенде c 2018.

а в ldapsearch пробовали в лоб указать примерно так

Код: Выделить всё

-b "dc=blabla,dc=com"

и
в запросе попробовать LDAP3, а не LDAP2
и сказать ему не прерыватьс, если ошибка будет походу

-c

?

[Dimerson]

1) -P2 это и есть LDAP2

2) base DN можно но не нужно
у меня несколько систем GROUPWISE соединены. Так что у них один iDomain и один GWIA.
соответственно этот GWIA отдает их LDAP-ом с разными корневыми OU=<GWSYSTEMNAME>

3) -c не горячо не холодно

Больше того. в Старых GW LDAP он такой не совсем честный LDAP а заготовка для адресной книги LDAP.
Он ищет по objectclass, sn, givenname, objectclass (хорошо если они не в BASE64/UTF8).
По аттрибуту mail не ищет

Я так думаю авторизовать тоже не могет . Но это про 2012 (это крайняя версия с LDAP в GWIA). У более новых LDAP хоть и настраивался в MTA но реально поднимал его gwadminservice
(это писаное на java приложение и порт открывает java - там надеюсь более честный LDAP. Если сильно надо могу провести тест. Но могу скаазать одно - там анонимный бинд не проходит - нужен реальный пользователь в groupwise с паролем и логинимся в НОВЫЙ ЛДАП на яве ldapsearch через -D -w - я заходил админом системы).

Про это была хорошая статейка https://ohmag.net/ask-the-experts-groupwise-33/

[skoltogyan]

Щас опишу, может каким-то боком в ldapsearch -> Edir подобное наталкиваетесь.
Итак - ниже текст не про eDir , а про Active Dirrectory и обращение к нем из ldapsearch.
Описываю на что наткнулся и в самом конце текста, на основании написаного, выскажу предположение.
Есть Windows Server 2012 R2. Он DC и все роли FSMO на нем.
дерево такое:
dc=HER,dc=FIRMA1,dc=cn
В дереве том есть куча OU и пользователей.
Часть пользователй имеет UPN вида:
userXXX@firma1.cn
Другая часть пользователей имеет UPN вида:
userXXX@firma2.com
Есть отдельно стоящий Linux ( напримр с Leap15.4 ).
Из этого линукса из bash подется такой запрос:
ldapsearch -c -D "CN=ldapprn pldaprn,OU=bla1,OU=bla0,DC=HER,DC=FIRMA1,DC=CN" -W -p 389 -h 192.168.1.1 -b "dc=HER,dc=FIRMA1,dc=cn" -s sub -x "(objectclass=*)" | grep -i userPrincipalName
Чисто было интересно глянуть шо вернет.
И удивило вот что: не всех пользователей вернуло в ответе.. я потом пробовал ограничивать запрос не к dc=HER,dc=FIRMA1,dc=cn , а указывая ближе к OU, в которых пользователи.. Там возвращало нормально..
ПОтом попробовал так:
ldapsearch -c -D "CN=ldapprn pldaprn,OU=bla1,OU=bla0,DC=HER,DC=FIRMA1,DC=CN" -W -p 389 -h 192.168.1.1 -b "dc=HER,dc=FIRMA1,dc=cn" -s sub -x "(objectclass=Persona)" | grep -i userPrincipalName | grep -i firma2 | wc -l
Ограничил запрос - только Person и посчитать количество с именем "firma2" в UPN, полчил ответ: 282
Потом так попробовал
ldapsearch -c -D "CN=ldapprn pldaprn,OU=bla1,OU=bla0,DC=HER,DC=FIRMA1,DC=CN" -W -p 389 -h 192.168.1.1 -b "dc=HER,dc=FIRMA1,dc=cn" -s sub -x "(objectclass=*)" | grep -i userPrincipalName | grep -i firma2 | wc -l
ТЕОРЕТИЧЕСКИ оно должно было вернуть НЕ МЕНЬШЕ объектов. Но реально получил цифру: 80
Как оказалось - в настройках LDAP сервера AD есть параметр:
"MaxValRange" - This value controls the number of values that are returned for an attribute of an object, independent of how many attributes that object has, or of how many objects were in the search result. In Windows 2000, this control is hard-coded at 1,000. If an attribute has more than the number of values that are specified by the MaxValRange value, you must use value range controls in LDAP to retrieve values that exceed the MaxValRange value. MaxValueRange controls the number of values that are returned on a single attribute on a single object.
Minimum Value: 30
Default value: 1500
Т.е. что-бы нормально пользоваться ldapsearch для получения ответов по ldap от AD надо это учитывать. а то оно просто не все будет возвращать...

Вот. Может в вашем случае ldapsearch не все получает от по ldap от eDir(или от gwia или gwia не все получает от eDir), смотря к чему вы стучитесь ?

[Dimerson]

я в ldap gwia сразу прописал в GWIA LDAP ACL Number of entries to return: 200 (больше чем надо иначе оно 100 отдавало (по дефолту 100)

[Сергей Дубров]

"MaxValRange" - This value controls the number of values that are returned for an attribute of an object, independent of how many attributes that object has, or of how many objects were in the search result. In Windows 2000, this control is hard-coded at 1,000. If an attribute has more than the number of values that are specified by the MaxValRange value, you must use value range controls in LDAP to retrieve values that exceed the MaxValRange value. MaxValueRange controls the number of values that are returned on a single attribute on a single object.
Minimum Value: 30
Default value: 1500
Т.е. что-бы нормально пользоваться ldapsearch для получения ответов по ldap от AD надо это учитывать. а то оно просто не все будет возвращать...

В современных версиях AD кол-во возвращаемых результатов поиска по LDAP-иерархии hard-coded=1000 и этот параметр модификации не подлежит, насмерть вшито в код. Натыкался на комментарий по этому поводу в одном из php-модулей (LDAP3) web-клиента roundcube. Написано, что планируют делать запросы итерациями, порциями по 1000 штук за раз, чтобы обойти это ограничение. Но написано в 2018, а в коде до сих пор не реализовано, при поиске в адресной книге строго 1000 записей выдаёт, ни штукой больше (у нас в каталоге более 3000 юзеров). Причина банальная - рекурсивный поиск по иерархической структуре плохо отображается на реляционную БД (а АД - это по сути допиленный MS Access), сильно грузит процессор и принципиально работает в один поток. Вот у Новела иерархическая e-dir была реализована на более адекватном бэкграунде - на иерархической же БД (flaim).

Кстати, почему не все атрибуты возвращаются при некоторых запросах к AD - причина та же. Для ухода от ресурсоёмкого поиска по LDAP-иерархии MS отобразила часть атрибутов в глобальный каталог (реляционная база). Подмножество атрибутов, копируемых в GC, настраивается. И если идёт поиск по атрибуту, который не отображён в GC и лежит глубоко ниже по иерархии - запрос молча ничего не вернёт.