Домен/Решение проблем: различия между версиями

Материал из ALT Linux Wiki
Нет описания правки
 
Строка 34: Строка 34:


= Проверка клиента =
= Проверка клиента =
==1. Проверяем доступные домены с сервера==
Служба {{cmd|avahi-daemon}} должна быть запущена на сервере и клиенте и там и там выдавать примерно следующее:
# avahi-browse -prtk _server._tcp
+;enp0s8;IPv4;ALT\032Linux\032Server\032\040c228\041;_server._tcp;local
=;enp0s8;IPv4;ALT\032Linux\032Server\032\040c228\041;_server._tcp;local;c228.local;192.168.1.1;0;"domain=school.alt" "role=master"


==2. Проверяем схему аутентификации на клиенте ==
==2. Проверяем схему аутентификации на клиенте ==

Текущая версия от 18:45, 25 сентября 2015

Внимание! Домен на Пятой и Шестой платформе нужно устанавливать только после настройки сервера DHCP. В противном случае придётся выбирать другое имя домена.


Внимание! Сервер домена гарантированно работает только на SysVInit, но не на Systemd.


Если что-то не работает, алгоритм следующий:

Проверка сервера

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, то следует выполнить следующий алгоритм действий:

  1. В модуле «DHCP-сервер» настроить сервер для подсети.
  2. Создать новый домен с другим именем (и с выставленным флажком «Обслуживать домен Kerberos»). При попытке использовать старое имя домена не создадутся нужные ветки в базе LDAP.

Проверка создания пользователя

Для успешного создания пользователя домена необходимо запустить службу slapd. А если домен с Kerberos, то и krb5kdc. Полный пошаговый вывод программы создания пользователя:

sh -x /usr/sbin/ldap-useradd test

Проверка клиента

1. Проверяем доступные домены с сервера

Служба avahi-daemon должна быть запущена на сервере и клиенте и там и там выдавать примерно следующее:

# avahi-browse -prtk _server._tcp
+;enp0s8;IPv4;ALT\032Linux\032Server\032\040c228\041;_server._tcp;local
=;enp0s8;IPv4;ALT\032Linux\032Server\032\040c228\041;_server._tcp;local;c228.local;192.168.1.1;0;"domain=school.alt" "role=master"


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=*))"                        
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 должна показать полученный тикет.

Если по каким-то причинам запись в LDAP есть, а в Kerberos отсутствует (например, создавали домен без поддержки Kerberos), нужно явно завести в Kerberos:

. /usr/bin/alterator-kdc-princ-functions 
addprinc l1
changepw l1 Passw0rd

Для работы служб должны быть получены и тикеты вида <имя_службы@...>. Более подробно про диагностику и работу Kerberos можно почитать в разделе Домен/Kerberos. Обратите внимание на пункт «Нюансы работы».

8. Пробуем зайти под доменным пользователем

В DM или консоли пробуем зайти доменным пользователем. В случае успеха аутентификация в домене работает. Если что-то не работает, то смотрите 12-ую консоль (Ctrl+Alt+F12).

Разное

Требования к именам пользователей

При создании пользователя, содержащего в имени буквы в верхнем регистре, POP3 и IMAP-доступ к его почтовому ящику не будет работать. Рекомендуется создавать имена пользователей, состоящие из латинских букв в нижнем регистре, цифр, символов «_» и «-». Исправлено в ldap-user-tools  с версии 0.8.2-alt2 

Сообщения об ошибках входа: вероятные причины

"Сбой при проверке подлинности"

Чаще всего, недоступность контроллера домена по сети. Отсутствие физического соединения (отошёл кабель, нет питания, ...) или ошибка при получении параметров сети. Слишком позднее получение параметров сети (проблема DHCP). Характерный признак - отсутствие ответа на ping контроллера домена. В качестве временной меры в ряде случаев помогает перезагрузка рабочей станции. Общее устранение проблемы связано с обеспечением устойчивой работы сети.

"Службе проверки подлинности не удаётся загрузить сведения аутентификации"

Предположительно, остановка или недоступность службы KDC. Проверить состояние службы krb5kdc на контроллере домена.

# service krb5kdc status

В случае состояния stopped причина обнаружена. Попробовать перезапустить KDC

# service krb5kdc start

Если krb5kdc не запускается, пытаться устранить причину или (если возможно) восстановить работоспособное состояние сервера домена из резервной копии.