Домен/Решение проблем
Если что-то не работает, алгоритм следующий:
Проверка сервера
1.Проверяем правильность работы домена на сервере
Проверяем на сервере домен и то, что он использует Kerberos:
# alterator-cmdline /net-domain action read domain:test.altlinux.ru resolver:OK access:OK ldap:OK kdc:OK smb:OK dhcpd:OK master:#t
Все параметры (кроме domain и master) должны быть OK, domain содержит правильное имя домена, master — значение #t.
Если проблемы с KDC, то следует выполнить следующий алгоритм действий:
- В модуле «DHCP-сервер» настроить сервер для подсети.
- Создать новый домен с другим именем (и с выставленным флажком «Обслуживать домен Kerberos»). При попытке использовать старое имя домена не создадутся нужные ветки в базе LDAP.
Проверка клиента
2. Проверяем схему аутентификации на клиенте
# system-auth status krb5 dc=test,dc=altlinux,dc=ru ldaps://ldap.test.altlinux.ru
Схема — krb5, выбран правильный домен. Примечание: на сервере используется схема ldap.
Если в модуле «Аунтификация» не показывается домен, то на клиенте нужно запустить службу avahi-daemon:
service avahi-daemon start
или добавить аутентификацию в домене вручную:
system-auth write krb5 dc=test,dc=altlinux,dc=ru ldaps://ldap.test.altlinux.ru
3. Смотрим доступность сервера по имени
# ping ldap.test.altlinux.ru
а) Если пишет 'unknown host', проверьте, прописан ли сервер как сервер DNS для этой машины. Рекомендуется сервер домена использовать как сервер DHCP и DNS для обслуживаемой подсети.
б) Если ping не идёт, проверьте сетевые подключения клиента и сервера и маршрутизацию сети.
4. Проверьте время на клиенте и сервере командой
# date
Оно не должно сильно отличаться. Kerberos очень чувствителен к разнице во времени.
5. Проверьте, виден ли клиент в LDAP
# ldapsearch -LLL -b "dc=test,dc=altlinux,dc=ru" -x -H "ldaps://ldap.test.altlinux.ru" "(&(objectClass=posixAccount)(uid=fill))" dn: uid=fill,ou=People,dc=test,dc=altlinux,dc=ru uid: fill cn:: 0KTQuNC70LjQv9C/0L7QsiDQmNCy0LDQvSDQlNC80LjRgtGA0LjQtdCy0LjRhw== sn:: 0KTQuNC70LjQv9C/0L7Qsg== objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: sambaSamAccount loginShell: /bin/sh uidNumber: 5006 gidNumber: 5009 homeDirectory: /home/fil sambaAcctFlags: [U ] sambaSID: S-1-5-21-2552966934-293145977-2108249345-11012 sambaPwdLastSet: 2147483647 sambaLogonTime: 0 sambaLogoffTime: 2147483647 sambaKickoffTime: 2147483647 sambaPwdCanChange: 0 sambaPwdMustChange: 0 givenName:: 0JjQstCw0L0=
6. Проверьте, видим ли пользователь через NSS на клиентской машине
# getent passwd fill fill:*:5006:5009:Филиппов Иван Дмитриевич:/home/fil:/bin/sh
Если ничего не выдано, проверяйте имя домена и работу службы LDAP (slapd) на сервере.
7. Проверяем получение тикета Kerberos:
# kinit l1 Password for l1@SCHOOL-5: # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: l1@SCHOOL-5 Valid starting Expires Service principal 09/30/12 18:17:00 10/01/12 18:17:00 krbtgt/SCHOOL-5@SCHOOL-5
В первой команде нужно указать имя пользователя и его пароль. Команда klist должна показать полученный тикет.
8. Пробуем зайти под доменным пользователем
В DM или консоли пробуем зайти доменным пользователем. В случае успеха аутентификация в домене работает.