Назад | Перейти на главную страницу

Ошибка клиента LDAP PAM «не удается найти имя для идентификатора пользователя»

Прошлой ночью у меня была проверка подлинности ldap, которая отлично работала, а сегодня, похоже, она не работает. Я могу пройти аутентификацию как пользователь, но клиент не может найти информацию около Пользователь:

Пример входа в систему как пользователь ldap «ts121207»:

$ su - ts121207
Password:
$ id -u
5003
$ whoami
whoami: cannot find name for user ID 5003

Я могу подключиться как пользователь и без проблем делать запросы от клиента:

$ ldapsearch -h ldap.example.org -D cn=ts121207,ou=students,ou=users,dc=example,dc=org -b ou=students,ou=users,dc=example,dc=org -w secret '(uid=ts121207)' uid givenName sn
# extended LDIF
#
# LDAPv3
# base <ou=students,ou=users,dc=example,dc=org> with scope subtree
# filter: (uid=ts121207)
# requesting: uid givenName sn 
#

# ts121207, students, users, example.org
dn: cn=ts121207,ou=students,ou=users,dc=example,dc=org
uid: ts121207
givenName: Test
sn: Student

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Я пробовал перезапустить sssd, а также очистить /var/lib/sss/db/*.

Интересно то, что когда я смотрю на журналы slapd на сервере ldap, кажется, что они не связываются как пользователь при поиске информации. Это то, что регистрируется, как только я запускаю whoami:

Nov 19 17:57:52 example.org slapd[14150]: conn=1332 op=0 BIND dn="" method=128                                                                                                                                                                                                             
Nov 19 17:57:52 example.org slapd[14150]: conn=1332 op=0 RESULT tag=97 err=0 text=                                                                                                                                                                                                         
Nov 19 17:57:52 example.org slapd[14150]: conn=1332 op=1 SRCH base="dc=example,dc=org" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uidNumber=5003))"                                                                                                                             
Nov 19 17:57:52 example.org slapd[14150]: conn=1332 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass                                                                                                                          
Nov 19 17:57:52 example.org slapd[14150]: conn=1332 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=

Разве клиенту не следует связываться как пользователь, чтобы выполнить этот запрос и прочитать атрибуты? Или я неверно истолковал эту строку журнала?

Я разобрался в проблеме. Я настроил клиент ldap с помощью Ubuntu ldap-auth-config пакет. Один из вопросов спрашивает «Требуется ли вход в базу данных?»:

Если вы ответите на это «Нет», то клиент ldap свяжется анонимно (после аутентификация), чтобы получить информацию о пользователе / ​​группе. Сначала мне показалось странным, что информацию о пользователе может видеть любой, но потом мне пришло в голову, что это аналогично тому, как /etc/passwd и /etc/group работы, которые доступны для чтения во всем мире.

Мои списки управления доступом предотвращали это, потому что я не хотел разрешать анонимным соединениям перечислять пользователей в моем каталоге. Чтобы исправить это, я добавил системного пользователя:

dn: cn=auth,ou=system,dc=example,dc=org
cn: auth
objectclass: organizationalRole
objectclass: top
objectclass: simpleSecurityObject
userpassword: {SHA}---redacted----=

Затем я добавил следующие ACL:

#
# System user "auth" can access user/group attrs needed by pam / nss             
olcAccess: {4}to dn.subtree="ou=users,dc=example,dc=org"                        
    attrs=entry,uid,userPassword,uidNumber,gidNumber,cn,homeDirectory,loginShell,gecos,description,objectClass
    by dn.exact="cn=auth,ou=system,dc=example,dc=org" read                      
    by self read                                                                 
    by * search                                                                  
olcAccess: {5}to dn.subtree="ou=groups,dc=example,dc=org"                       
    attrs=entry,cn,gidNumber,memberUid,objectClass                               
    by dn.exact="cn=auth,ou=system,dc=example,dc=org" read
#                                                                                
# Allow users to read any data on their own entries                              
olcAccess: {6}to *                                                               
    by self read                                                                 
    by * search

Наконец я побежал sudo dpkg-reconfigure ldap-auth-config, и на вопрос «Требуется ли вход в базу данных?» я ответил утвердительно. На вопрос, где запрашивается «непривилегированный пользователь», я указал нового системного пользователя, которого я создал:

Обратите внимание, что это по-прежнему делает учетные записи пользователей потенциально может быть перечислен любым пользователем, аутентифицированным в системе Linux, поскольку этот пароль хранится в виде открытого текста в /etc/ldap.conf, но это не менее безопасно, чем как /etc/passwd и /etc/group работай.