Пользователи и группы системы в LDAP, все хорошо, но .....
Рассмотрим на примере групп:

Выдает название групп на кириллице в системе  в виде \D0\9E\D1\85\D1\80\D0\B0\D0\BD\D0\B0 \D1\82\D1\80\D1\83\D0\B4\D0\B0,  если атрибут LDAP групп (cn) совпадает с dn (т.е. DN начинается с этого атрибута), если нет - всё отлично.
Пример:

dn: cn=Тест,ou=Group,dc=......
cn: Тест
gidNumber: 500
objectClass: posixGroup
objectClass: top

getent group выдает кракозябры

В случае же:

dn: gidNumber=500,ou=Group,dc=....
gidNumber: 500
objectClass: posixGroup
objectClass: top
cn:: Тест

getent group выдаёт название группы по русски.

Создается впечатление, что pam берёт название группы в 1-м случае с DN, чтобы лишний раз не читать атрибут cn
Как побороть - не знаю.

Варианты использовать дополнительный атрибут для представления имён либо второй вариант не интересен по многим причинам.

• LDAP, pam и атрибуты,начинающиий, 20:20 , 26-Апр-10
  • LDAP, pam и атрибуты,azazelloav, 21:53 , 26-Апр-10
    • LDAP, pam и атрибуты,начинающиий, 23:03 , 26-Апр-10
      • LDAP, pam и атрибуты,azazelloAV, 11:49 , 30-Апр-10
        • LDAP, pam и атрибуты,начинающий, 13:30 , 30-Апр-10

>getent group выдаёт название группы по русски.
>
>Создается впечатление, что pam берёт название группы в 1-м случае с DN,
>чтобы лишний раз не читать атрибут cn
>Как побороть - не знаю.

1. вызов getent использует nss, а не pam.
2. ldapseach правильно выдает в любом случае?
3. Если нет, то может, тип аттрибута в длап схеме - строка аscii.
Когда-то я вручную менял тип на utf-8 для поля gecos.

>>getent group выдаёт название группы по русски.
>>
>>Создается впечатление, что pam берёт название группы в 1-м случае с DN,
>>чтобы лишний раз не читать атрибут cn
>>Как побороть - не знаю.
>
>1. вызов getent использует nss, а не pam.

Это не имеет значение, различия между pam и nss в данном случае не принципиально, в конечном итоге последняя инстанция pam
>2. ldapseach правильно выдает в любом случае?

Правильно, ну конечно теже кракозябры, но мы то знаем что это base64 (проверял декодированием правильность)
>3. Если нет, то может, тип аттрибута в длап схеме - строка
>аscii.
>Когда-то я вручную менял тип на utf-8 для поля gecos.

3 пункт поподробнее....

>3 пункт поподробнее....

attributetype ( 1.3.6.1.1.1.1.2 NAME 'gecos'
        DESC 'The GECOS field; the common name'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreIA5SubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
#       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

>>3 пункт поподробнее....
>
>attributetype ( 1.3.6.1.1.1.1.2 NAME 'gecos'
>        DESC 'The GECOS field;
>the common name'
>        EQUALITY caseIgnoreMatch
>        SUBSTR caseIgnoreIA5SubstringsMatch
>        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
>
>#       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

Ну вообще то там и так 1.15.
Во первых, трудно поменять, ибо cn уж слишком common и участвует во многих объектах.
Но суть не в этом. cn то в любом случае выдается верный. Неверный выдаётся когда он участвует в DN, да и то, токи в PAM

К примеру, вот что у нас выдаёт ldapsearch

1: # \D0\98\D0\97\D0\9F, Group, mes.zt
2: dn:: Y2490JjQl9CfLG91PUdyb3VwLGRjPW1lcyxkYz16dA==
3: cn:: 0JjQl9Cf

И DN верный, и cn верный в кодировке base64.
1-я строка - коммент самого ldapsearch.
Вот именно в таком виде (как 1-я строка) у нас выдаётся в getent. И не важно, cn это или к примеру uid. Суть в том, что если нам нужен атрибут для предоставления наших данных и он входит в dn, глюки обеспечены.

>Неверный выдаётся когда он участвует в DN, да и то, токи
>в PAM
>
>К примеру, вот что у нас выдаёт ldapsearch
>
>1: # \D0\98\D0\97\D0\9F, Group, mes.zt
>2: dn:: Y2490JjQl9CfLG91PUdyb3VwLGRjPW1lcyxkYz16dA==
>
>в том, что если нам нужен атрибут для предоставления наших данных
>и он входит в dn, глюки обеспечены.

Тогда разве что исходники libnss_ldap.so смотри на предмет его логики )))