Пользователи, аутентифицирующиеся через AD, больше не получают запроса на ввод пароля.

Содержание

Вопрос или проблема
Ответ или решение
Причины изначальной проблемы
Логи до и после миграции
Решение проблемы
Дополнительные рекомендации
Заключение

Вопрос или проблема

Платформы: Oracle Linux 5, Oracle Linux 6
PowerbrokerOpen V7.01

Что мы хотим получить: Пользователи могут войти в командную строку Linux, используя свое имя пользователя и пароль Active Directory.

Что происходит сейчас: Пользователи входят с помощью своего логина AD и больше не запрашиваются для ввода пароля

Что изменилось: Машины Linux были перенесены с домена “MYCOMPANY.NET” на “MYCOMPANY.LOCAL”, так как домен “MYCOMPANY.NET” будет удален.

Это вывод в /var/log/secure с машины, которая еще не была перенесена:

Фев 11 14:51:07 prdsrv101 sshd[32690]: Приняты клавиатурно-интерактивные/pam для davthac с 10.53.25.44 порт 53561 ssh2
Фев 11 14:51:07 prdsrv01 sshd[32690]: pam_unix(sshd:session): сеанс открыт для пользователя davthac (uid=0)

Это вывод в /var/log/secure с машины, которая была перенесена:

Фев 11 14:57:00 tstivxapp01 sshd[10161]: Авторизован для davthac, krb5 principal [email protected] (krb5_kuserok)
Фев 11 14:57:00 tstivxapp01 sshd[10161]: Приняты gssapi-with-mic для davthac с 10.53.25.44 порт 53777 ssh2
Фев 11 14:57:00 tstivxapp01 sshd[10161]: pam_unix(sshd:session): сеанс открыт для пользователя davthac (uid=0)

Похоже, что метод аутентификации был изменен, но мы не вносили никаких изменений в конфигурацию Powerbroker, кроме как вышли из MYCOMPANY.NET и присоединились к MYCOMPANY.LOCAL.

Что мне нужно сделать, чтобы вернуть запрос пароля?

Спасибо заранее

Дэйв

Мне пришлось отключить GSSAPIAuthentication в файле /etc/sshd/sshd_config. Это сработало и для меня, как показано ниже.

grep GSSA /etc/ssh/sshd_config
# Шифры, MAC, KexAlgoritms и GSSAPIKexAlgorithsm не будут иметь никаких
# параметров GSSAPI
GSSAPIAuthentication no

Ответ или решение

Когда пользователи аутентифицируются через Active Directory (AD) на платформах Oracle Linux 5 и 6, и больше не получают запроса на ввод пароля, это может вызвать определенные беспокойства. Весь процесс аутентификации стал не таким, каким был прежде, что может снизить уровень безопасности. В данном ответе мы обсудим вероятные причины произошедших изменений и шаги, которые помогут восстановить обычный процесс аутентификации.

Причины изначальной проблемы

Очевидно, что основной причиной изменения процесса аутентификации явилось перемещение серверов из домена MYCOMPANY.NET в MYCOMPANY.LOCAL. Это переключение могло привести к неправильным настройкам аутентификации в системе. Как показано в логах /var/log/secure, аутентификация пользователей переместилась на использование gssapi-with-mic, что является частью механизма Kerberos для безопасной аутентификации. Это означает, что пользователи могли заходить в систему без ввода пароля, если у них уже есть действительный Kerberos-токен.

Логи до и после миграции

До миграции:
```
Accepted keyboard-interactive/pam for davthac from 10.53.25.44 port 53561 ssh2
```
В этом случае используется традиционный метод аутентификации, который включает запрос пароля.
После миграции:
```
Authorized to davthac, krb5 principal USER@MYCOMPANY.LOCAL (krb5_kuserok)
Accepted gssapi-with-mic for davthac from 10.53.25.44 port 53777 ssh2
```
Аутентификация происходит с помощью методa Kerberos, что исключает необходимость ввода пароля, если токен Kerberos уже действителен.

Решение проблемы

Как было указано в одном из ответов, отключение GSSAPIAuthentication решило проблему. Это позволяет возвращать пользователей к более традиционным методам аутентификации, которые требуют ввода пароля при каждом входе. Чтобы это сделать, следуйте следующим шагам:

Редактирование файла конфигурации SSH:
Откройте файл /etc/ssh/sshd_config с привилегиями суперпользователя:
```
sudo vi /etc/ssh/sshd_config
```
Отключение GSSAPI:
Найдите строку, касающуюся GSSAPIAuthentication, и измените ее на значение "no":
```
GSSAPIAuthentication no
```
Перезапуск службы SSH:
Чтобы изменения вступили в силу, перезапустите службу SSH:
```
sudo systemctl restart sshd
```

Дополнительные рекомендации

Убедитесь, что ваше Kerberos настроено правильно. Если пользователи всё ещё нуждаются в Kerberos для других сервисов, убедитесь, что перемещение в новый домен MYCOMPANY.LOCAL правильно связано с вашей конфигурацией Kerberos (krb5.conf).
Выполните регулярный аудит конфигурации аутентификации и разрешений пользователей после миграции. Это поможет удержать уровень безопасности на высоком уровне и предотвратит возможность несанкционированного доступа.

Заключение

Восстановление запроса на ввод пароля при аутентификации пользователей через Active Directory в новых условиях домена MYCOMPANY.LOCAL требует изменений в конфигурации SSH. Отключение GSSAPIAuthentication позволит вернуть традиционный процесс ввода пароля. Не забывайте также следить за настройками Kerberos и защищать доступ к системам.

Это позволит вам не только сохранить привычный уровень безопасности, но и гарантировать, что пользователи смогут безопасно и эффективно взаимодействовать с системами Linux в рамках нового домена.