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

Домен/Решение проблем

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

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

• 1 Проверка сервера
  • 1.1 1.Проверяем правильность работы домена на сервере
    • 1.1.1 Проверка создания пользователя
    • 2.1 1. Проверяем доступные домены с сервера
    • 2.2 2. Проверяем схему аутентификации на клиенте
    • 2.3 3. Смотрим доступность сервера по имени
    • 2.4 4. Проверьте время на клиенте и сервере командой
    • 2.5 5. Проверьте, виден ли клиент в LDAP
    • 2.6 6. Проверьте, видим ли пользователь через NSS на клиентской машине
    • 2.7 7. Проверяем получение тикета Kerberos
    • 2.8 8. Пробуем зайти под доменным пользователем
    • 3.1 Требования к именам пользователей
    • 3.2 Сообщения об ошибках входа: вероятные причины
      • 3.2.1 «Сбой при проверке подлинности»
      • 3.2.2 «Службе проверки подлинности не удаётся загрузить сведения аутентификации»

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

      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. Смотрим доступность сервера по имени

      а) Если пишет ‘unknown host’, проверьте, прописан ли сервер как сервер DNS для этой машины. Рекомендуется сервер домена использовать как сервер DHCP и DNS для обслуживаемой подсети.

      б) Если ping не идёт, проверьте сетевые подключения клиента и сервера и маршрутизацию сети.

      4. Проверьте время на клиенте и сервере командой

      Оно не должно сильно отличаться. 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 на контроллере домена.

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

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

      Источник

      su: сбой при проверке подлинности

      «username» is not in the sudoers file. This incident will be reported.

      Ошибок с паролем быть не может. Как решить?

      

      

      Решил, всем спасибо. Расходитесь.

      

      Галочка решено и напиши в чем был затык — думаю не один ты столкнулся с такой проблемой, следующий погуглит, попадет на твою тему (лор на первых страницах гугла) и не создаст очередную.

      

      Да пользователя добавить в группу sudo, это же в официальном мануале есть: https://wiki.debian.org/sudo

      Так что гугл уже имеет, что выдать. А если человек не привык гуглить — он в любом случае создаст тему.

      Vsevolod-linuxoid ★★★★★ ( 16.05.17 05:35:25 MSK )
      Последнее исправление: Vsevolod-linuxoid 16.05.17 05:36:24 MSK (всего исправлений: 1)

      

      не создавал для рута пароль?

      

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

      И single user mode никто не отменял.

      

      И single user mode никто не отменял.

      Я удалял себя из группы судо нечаяно, а пароль рута залочен. Было прикольно. Т.е. single в этом случае тоже не работает.

      mandala ★★★★★ ( 17.05.17 00:59:01 MSK )
      Последнее исправление: mandala 17.05.17 00:59:49 MSK (всего исправлений: 2)

      

      sudoers

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

      

      С live-cd загрузись и добавь себя в группу sudo, можно редактированием конфигов, можно через chroot.

      mandala ★★★★★ ( 18.05.17 00:59:53 MSK )
      Последнее исправление: mandala 18.05.17 01:00:09 MSK (всего исправлений: 1)

      В том-то все и дело что при установке дестр. Fedora пользователю (2) присаваеваться группа whell и права группы adm. И все работает нормально до поры до времени но в один прекрасный момент ты решаеш открыть файловый менеджер Krusader (с правами root который до этого открывал без проблем ну или что-то другое) и.. спрашивают в окне kde-su пороль root (ввожу Правильный пороль проверяю, жму кнопку продолжить и вот-те здрасте окошко с ошибкой глосящей что у меня (состоящего в групп whell и role adm нет прав запускать приложения с правами root 🙁 🙁 ps Лечиться сей баг лишь только переустановкой пакетов kde-su kf5-su 🙁

      Источник

      Команда su root [Решено]

      Что происходит, когда я ввожу su root? Меня просят пароль, но у меня есть только свой пароль (я включён в группу администраторов). Какой пароль я должен ввести в этом случае? Если я ввожу свой пароль (а я единственный пользователь системы), то в результате мне выдаётся сообщение: su: Сбой при проверке подлинности.

      И не является ли такое использование команды su ситуацией, непредусмотренной создателями этой команды? Потому что у рута на моей кубунте пароль отсутствует. Пароль есть только у меня как у единственного пользователя системы.

      Этот вопрос мне интересен, потому что хотел бы просто для интереса зарегиться под рутом и не использовать sudo. Возможно ли такое?

      

      Рута на kubuntu вообще нету по умолчанию, поэтому у него нету и пароля, поэтому через него и нельзя зайти, поэтому обычно используют sudo -s -H

      А вообще про это дело есть в подшивке ТУТ

      

      Команда su открывает сеанс root. Она не требует аргументов, т.е. не надо писать su root. По умолчанию в бунте у root нет пароля, поэтому su не работает.

      Чтобы «зарегиться под рутом», выполните sudo passwd root
      Открывать сеанс рута без это можно по sudo su или sudo -i

      

      sudo su
      Даст тебе желаемое а root в ubuntu по умолчанию отключен — можно конечно включить но сидеть всё время под root-ом плохой тон.

      Создать пользователя root это не значит запускать под ним систему. Хотя за многие годы так и не возникла необходимость его создать. Хватало всегда sudo -i

      

      Всегда пользовался sudo bash.
      Это не одно и то же?

      Как бы не одно и тоже, но результат тот же ))) Тут у каждого свои прибамбасы.

      Источник

      Проблема с паролём для root

      А зачем sudo su , если есть sudo -i или sudo -s или на худой конец sudo bash ?

      Если что, пароль рута можно задать, загрузив ядро с параметром init=/bin/bash или подобным

      не знаю, man sudo не читал, вообще не люблю эту штуку

      Если что, пароль рута можно задать, загрузив ядро с параметром init=/bin/bash или подобным

      На какие только извращения ни идут люди, лишь бы не делать sudo passwd .

      Может случиться так, что /etc/sudoers не настроен тогда sudo работать не будет. А если и пароль рута не задан, то и su может тоже не работать — тогда иначе никак, похоже. Или с livecd или init=/bin/sh

      У меня есть подозрение, что fedora даже не спрашивает пароль рута, как и убунту, по дефолту настраивая sudo.

      

      И спрашивает, и настраивает sudo (если поставить чекбокс «сделать пользователя администратором»).

      

      Юзай sudo -i . Если надо другого юзера – sudo -u username -i , а поскольку у некоторых юзеров бывает false или nologin вместо шелла – sudo -u username /bin/bash . Чтобы задать юзеру пароль – sudo passwd username . У sudo не так и много опций.

      Зачем? 20 – стабильнее, 22/23 – свежее.

      

      Поменял имя пользователя этим способом:

      А если напрямую в файле /etc/passwd и /etc/shadow поменять имя разве это не будет работать?

      Перезагрузил i3wm, и теперь доступ к su запрещен.

      spasticarm0x15dec@calculate ~ $ su Пароль: su: Доступ запрещен spasticarm0x15dec@calculate ~ $ sudo -i Пароль: Попробуйте ещё раз. Пароль: spasticarm0x15dec is not in the sudoers file. This incident will be reported. 

      

      А если напрямую в файле /etc/passwd и /etc/shadow поменять имя разве это не будет работать?

      Нет, не будет. Меняй обратно

      

      Я уже. Итог su: Доступ запрещен . Теперь только init=/bin/sh ?

      Источник

      Читайте также:  Linux установка графической оболочки debian