IDM AD -> eDir правило создания user в edir

[skoltogyan]

Доброго дня.
До этого работало:
eDir->AD.
Появилась необходимость настроить и в обратную сторону.
При создании в AD , содается и в eDir( тьфу-тьфу ), но в eDir создается объект так:
Familiya Imya.
КТо знает - что именно откррректировать в драйвере IDM, что-бы в edir создавались в виде:
ifamilya

?

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

В первую очередь, смотреть правила маппинга, политики формирования Destination Name в Placement Policy (на соответствующем канале) и настроечные переменные драйвера (если пользуетесь стандартными политиками из пакетов, много настроек вынесено туда).

Стандартная практика для AD - это когда в качестве заключительного компонента Full Destination Name используется не login name (как в eDirectory), а Full Name. При этом логин и Full Distinguished Name из AD дублируются драйвером в атрибуты DirXML-ADAliasName и DirXML-ADContext. Последний используется на publisher-канале, чтобы отличить операции перемещения от операций переименования (поскольку в обоих случаях изменяется Full Distinguished Name, то драйвер не различает этих операций и генерирует два события сразу, одно из которых потом Veto-ится соответствующим правилом на основе анализа изменений атрибута DirXML-ADContext).

Чтобы ещё больше запутать ситуацию, в последних версиях политик из стандартных пакетов поменялся формат того, что кладётся в атрибут DirXML-ADAliasName. Если раньше он мапился на AD-шный атрибут sAMAccountName (вида "VPupkin"), то теперь по умолчанию мапится на другой атрибут - userPrincipalName (имеющий вид "VPupkin@Ваш.домен"). Так что не так всё просто.

[skoltogyan]

у меня idm3.61 ( старенький )
до последнего времени все работало eDir->AD.
Недавно возникла потребность сделать ДВУНАПРАВЛЕННО, что-бы если создал пользователя в AD , то он создался-б и в eDIR ( home не нужен ). И если потмо в eDir внес изменения, то в AD они отобразились + пароль.
В целом заработало.
было две проблемы:

проблема-1:
при создании в AD нового пользователя в одном из контейнеров - в eDir создавались в корне все ( o=ami ).
это победил, изменив в :
"Publisher Placement Policies" | "placement for all objects"
было: "ami" + "\" + Source Name ()
изменил на: "ami" + "\" + Operation Property ("unmatched-src-dn")
и оно стало создавать пользователей в eDir в том-же контейнере, что есть в AD

проблема-2:
При создании в AD новый создается в eDiir, но создается с CN вида "Фамилие Имя Отчество", а не вида vpupkin
вроде в этом месте ( возможно) надо что-то изменить:
"Publisher Placement Policies" | "optional logon name mapping"
в нем action:
"set operation destination DN (dn (Destination DN (length="-2") + "\" + Escape Destination DN (Attribute ("DirXML-ADAliasName") ) ) ) "

но я не панимаю, что.

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

Ну, в старых версиях (3.5-3.6) точно логин сохранялся в атрибуте DirXML-ADAliasName, который мапился на AD-шный атрибут sAMAccountName.

При создании в AD новый создается в eDir, но создается с CN вида "Фамилие Имя Отчество", а не вида vpupkin
вроде в этом месте ( возможно) надо что-то изменить:
"Publisher Placement Policies" | "optional logon name mapping"
в нем action:
"set operation destination DN (dn (Destination DN (length="-2") + "\" + Escape Destination DN (Attribute ("DirXML-ADAliasName") ) ) ) "

но я не панимаю, что.

Ну, вроде как это оно и есть: заменяет текущий Destination DN на новый, в котором от старого берётся полный путь от корня, но без последнего компонента (length="-2") , и дополняется вместо него содержимым указанного атрибута (который должен содержать AD Login).
В современных версиях эти политики окружены множеством IF-ов, проверяющих значения конфигурационных переменных (GCV) драйвера.

Надо по логам смотреть, что именно там происходит. Либо не отрабатывает это правило, либо после него отрабатывает какое-то ещё, которое сформированный Destination DN перезаписывает по-новой.
Включать (на закладке "Misc" в свойствах драйвера) trace level=4, указывать для драйвера отдельный трейс-файл и разбираться, сопоставляя записи в логах с правилами в драйвере.

[skoltogyan]

Разобрался.
Что-бы оно делало, как хочу, необходимо было изменять CN ( я вписываю в внего sAMAccountName . вернее так - пытался вписать, а оно вроде-как не применялось....).
После включения Trace увидел, что правило, которое вписывает новое имя ( на базе измененного CN ) не отрабатывает. А не отрабатывает потому, что "LogonNameMap" = False
Начал смотреть в Global Configuration Values, а там ВООБЩЕ НЕТ СЕКЦИИ "Name Mapping Policy" ( после какой аварии и почему она пропала - бмп. )
Как решил: - создал новый драйвер ( не для реального использования ) и скопировал из него эту недостающую секцию в свой драйвер.

После этого все заработало

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

После включения Trace увидел, что правило, которое вписывает новое имя ( на базе измененного CN ) не отрабатывает. А не отрабатывает потому, что "LogonNameMap" = False

Я именно эти и имел в виду, когда писал:

В современных версиях эти политики окружены множеством IF-ов, проверяющих значения конфигурационных переменных (GCV) драйвера.

Ну что ж, хорошо, что заработало

[skoltogyan]

пагано что не так и не понял - как потярялась целая секция... где это она ( секция ) хранится, что потерялась..

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

погано что не так и не понял - как потярялась целая секция... где это она ( секция ) хранится, что потерялась..

У меня в своё время эта секция терялась при миграции на другой сервер.

Когда делал обновление OES2 (SLES10) -> OES11 (OES11), то "неожиданно" выяснилось, что OES11 поддерживается только для 64-битных платформ, а у нас IDM Engine стоял на OES2 32-битной. Поэтому пришлось "с нуля" ставить новый сервер OES11, вводить в дерево eDirectory и мигрировать на него. Вроде бы, ничего сложного - все настройки-то "живут" в дереве, расположил реплику на новом сервере, перенастроил IDM запускаться на новом сервере, делов-то...

Но в какой-то момент я с удивлением обнаружил, что в eDirectory, среди прочих интересных вещей, существуют некоторые любопытные флаги для атрибутов. Ну, флагами "Single Valued" или "Synchronize Immediately" нас не удивишь; но вот флаг "Per replica" оказался для меня неожиданностью. А именно он выставлен, например, на атрибутах DirXML-ShimConfigInfo и DirXML-ConfigValues объекта "драйвер" (класс DirXML-Driver), где и хранятся, в частности, переменные GCV. И сделано это специально, чтобы иметь возможность на разных серверах иметь разные значения конфигурационных переменных.

Никогда до этого не обращал внимания, но и в iManager-е, и в Designer-е при просмотре/редактировании переменных GCV всегда есть упоминание: "for server <имя_сервера>", которое при наличии в Driver Set-е более одного сервера превращается в выпадающее меню (из которого можно выбрать конкретный сервер).

Но у себя я это обнаружил поздновато, когда "старый" сервер уже удалил. Хорошо, что все настройки были заэкспортированы, и худо-бедно удалось восстановить всё необходимое (пароли, правда, пришлось перебивать заново - они в экспорт-файлах не сохранялись).