ejabberd LDAP и mod_shared_roster [почти SOLVED]

Не знаю как во 2-й версии, а в 1-й+мод(у мя до сих пор стоит на работе) работает нормально.
Вот почитай про моё допиливание.
http://www.gentoo.ru/node/9399

"Курнул" сейчас исходники ёжика, в общем это ущербность самого mod_shared_roster, вот как там написано:

%% Export items in roster format:
    SRItems = [#roster{usj = {U, S, {U1, S1, ""}},
                     us = US,
                     jid = {U1, S1, ""},
                     name = "",
                     subscription = both,
                     ask = none,
                     groups = GroupNames} ||
                     {{U1, S1}, GroupNames} <- dict:to_list(SRUsersRest)],
    SRItems ++ NewItems1. 

Т.е. name в котором передаётся ник всегда пустой, для примера, тот же кусок кода в mod_shared_roster_ldap:

 %% Export items in roster format:
    SRItems = [#roster{usj = {U, S, {U1, S1, ""}},
                     us = US,
                     jid = {U1, S1, ""},
                     name = get_user_name(U1,S1),
                     subscription = both,
                     ask = none,
                     groups = GroupNames} ||
                     {{U1, S1}, GroupNames} <- dict:to_list(SRUsersRest)],
    SRItems ++ NewItems1.

Вот и весь хрен хрен копейки...

В общем хожу по старым граблям. Всё те же проблемы с не соответствием AD схемы и той что используется для авторизации в *nix'ах.

Как я понял, в AD в ветке пользователя прописаны все группы членом которых он является. У меня членство в группах хранится в ветках групп. Если сделать как думал автор оригинального mod_shared_roster_ldap, то заставить работать всё это можно, с вот такими настройками:

{mod_shared_roster_ldap,[
                    {ldap_base, "dc=xxx,dc=ru"},
                    {ldap_rfilter, "(cn=Domain Users)"},
                    {ldap_filter,"(ObjectClass=*)"},
                    {ldap_groupattr,"cn"},
                    {ldap_groupdesc,"description"},
                    {ldap_memberattr,"memberUid"},
                    {ldap_memberattr_format,"%u"},
                    {ldap_userdesc,"displayName"}
                 ]},

Т.к. будет производиться поиск только в ou=Groups (у меня группы отдельно от пользователей), а у самих групп есть и cn и memberUid, но displayName мы не увидим, т.к. выборка имени для пользователя делается так:

handle_call({get_user_name, User}, _From, State) ->
UserDescAttr = State#state.user_desc,
Reply = case eldap_filter:parse(State#state.ufilter, [{"%u", User}]) of
		{ok, EldapFilter} ->
			case eldap:search(State#state.eldap_id, [
					{base, State#state.base},
					{filter, EldapFilter},
					{attributes, [UserDescAttr]}]) of
				#eldap_search_result{entries = [
						#eldap_entry{attributes =
							[{UserDescAttr, UserName} | _]}
						]} ->
					UserName;
				_ ->
					User
			end;
		_ ->
			User
	end,
	{reply, Reply, State};

ufilter при указанных настройках будет таким: '&(&(memberUid=%u)(cn=%g))(ObjectClass=*)', т.е. displayName в результате этого запроса не вернётся, совсем, нет у группы такого атрибута и пользователя с cn равным имени группы тоже нет. :-( Но и не правильным это поведение не назовёшь, всё-таки для AD этот запрос отработает верно.

Вернулись туда откуда пришли, снова вместо имен пользователей их логины получились.

к не лдап-версия есть вот такой патч, нужно ещё поискать.
https://support.process-one.net/browse/EJAB-114

Если не сложно покажите пожалуйста свой конфиг. Неполучаеться настроить