Jak naprawić błędy uwierzytelniania PAM w systemie SUSE Linux Enterprise Server

Komunikat „Błąd uwierzytelniania PAM” nie zawsze oznacza nieprawidłowe hasło. W systemie SUSE Linux Enterprise Server (SLES) moduły uwierzytelniania wtykowego (PAM) tworzą stos, który sprawdza tożsamość, dostęp do konta, zmiany hasła i konfigurację sesji. Przyczyną błędu może być literówka lub wyłączone konto, uszkodzony element PAM, niedostępna usługa LDAP lub Active Directory, problem z zegarem Kerberos lub DNS, a także problem z sesją pulpitu występujący po uwierzytelnieniu.

Najbezpieczniejszym rozwiązaniem jest zidentyfikowanie, która usługa i który etap PAM uległy awarii, przed zmianą konfiguracji. W tym przewodniku wykorzystano dokumentację systemu SUSE Linux Enterprise Server 15 SP7 jako punkt odniesienia. Jeśli uruchamiasz inny pakiet serwisowy SLES lub obraz specjalistycznego urządzenia, sprawdź odpowiednią dokumentację systemu SUSE i zainstalowane wersje pakietów przed zastosowaniem poleceń.

Po pierwsze, co jest nie tak: jedna usługa czy wszystkie logowania?

Zapisz użytkownika, dokładny czas, hosta i punkt wejścia awarii: SSH, lokalną konsolę tekstową, logowanie graficzne sulub aplikację. Przetestuj, jeśli to możliwe, z drugim znanym kontem. Jeśli awaria występuje tylko w SSH, a logowanie konsolowe działa, skup się na /etc/pam.d/sshdusłudze SSH. Jeśli użytkownicy lokalni działają, ale użytkownicy katalogowi nie, sprawdź SSSD, LDAP, Active Directory, Kerberos, DNS lub politykę autoryzacji hosta. Jeśli logowanie konsolowe powiedzie się, ale pulpit odrzuci użytkownika lub powróci do ekranu logowania, awaria może dotyczyć sesji graficznej lub katalogu domowego, a nie uwierzytelniania hasłem.

Podczas rozwiązywania problemów zachowaj otwartą istniejącą powłokę roota. Jeśli jesteś połączony zdalnie, otwórz drugą sesję SSH i upewnij się, że masz dostęp do konsoli lub pliku ratunkowego, zanim zaczniesz korzystać z PAM. Błąd składni lub flagi kontrolnej we współdzielonym pliku PAM może zablokować nowe logowania do wielu usług.

1. Przeczytaj dziennik dotyczący nieudanej próby

Przewodnik rozwiązywania problemów SUSE zaleca przeglądanie dziennika systemowego pod kątem komunikatów z procesu logowania i PAM. Zapytaj o krótki przedział czasowy blisko awarii, aby niezwiązane z nią komunikaty nie przysłaniały przyczyny:

sudo journalctl -b --since "15 minutes ago"

W przypadku problemu dotyczącego wyłącznie protokołu SSH należy zawęzić widok do demona SSH:

sudo journalctl -b -u sshd --since "15 minutes ago"

Sprawdź nazwę usługi, nazwę usługi PAM, nazwę modułu oraz czy komunikat odnosi się do auth, account, passwordlub session. Stos PAM authsprawdza dane uwierzytelniające, accountsprawdza, czy użytkownik ma uprawnienia dostępu do danej usługi i sessionprzygotowuje środowisko użytkownika. Pomyślne sprawdzenie hasła, po którym następuje odmowa dostępu do konta, wskazuje na inny problem niż nieznany użytkownik lub nieprawidłowe hasło. Unikaj włączania szczegółowego debugowania w systemie produkcyjnym, chyba że jest to konieczne; logi diagnostyczne mogą zawierać nazwy kont i inne wrażliwe informacje.

Zapoznaj się z podręcznikiem rozwiązywania problemów SLES firmy SUSE, aby poznać przepływ pracy związany z uwierzytelnianiem lokalnym i sieciowym.

2. Sprawdź, czy SLES może znaleźć użytkownika

Przed zmianą ustawień PAM sprawdź, czy przełącznik usługi nazw systemu może rozpoznać konto:

getent passwd user_name
id user_name

Zastąp user_nameodpowiednim loginem. Jeśli te polecenia nie zwrócą konta dla użytkownika katalogu, PAM może działać poprawnie, mimo że wyszukiwanie tożsamości nie działa. Sprawdź, czy skonfigurowana usługa tożsamości jest uruchomiona, host ma dostęp do katalogu i użytkownik ma uprawnienia do logowania się na tym hoście. W przypadku konfiguracji opartej na SSSD sprawdź demona i ostatnie logi:

sudo systemctl status sssd
sudo journalctl -b -u sssd --since "15 minutes ago"

SUSE dokumentuje SSSD jako serwer udostępniający zarówno interfejsy NSS, jak i PAM, i zaznacza, że ​​może on buforować dane tożsamości. Jeśli użytkownicy zgłaszają sporadyczne awarie, należy porównać czas i rozdzielczość DNS w systemie lokalnym z usługą katalogową lub środowiskiem Kerberos. Kerberos wymaga prawidłowej synchronizacji czasu; samo działające połączenie sieciowe nie gwarantuje powodzenia uwierzytelniania.

Sprawdź również, czy nie występują kolizje nazw. SUSE wskazuje nazwę użytkownika, która istnieje lokalnie i w sieciowym źródle tożsamości, jako możliwą przyczynę problemów z uwierzytelnianiem sieciowym. Przed edycją reguł PAM sprawdź, które źródło tożsamości jest prawdopodobnie właścicielem konta.

3. Sprawdź plik usługi PAM i współdzielony stos

SLES przechowuje pliki PAM dla poszczególnych usług w formacie /etc/pam.d. Plik usługi, taki jak , /etc/pam.d/sshdzazwyczaj obejmuje pliki współdzielone, takie jak common-auth, common-account, common-passwordi common-session. Błędny wiersz w pliku współdzielonym może mieć wpływ na kilka usług; błędny wiersz w pliku jednej aplikacji może mieć wpływ tylko na tę aplikację.

Przed edycją przeczytaj odpowiednie pliki i sprawdź ich linki:

sudo ls -l /etc/pam.d/common-*
sudo sed -n '1,160p' /etc/pam.d/sshd
sudo sed -n '1,160p' /etc/pam.d/common-auth
sudo sed -n '1,160p' /etc/pam.d/common-account

Sprawdź błędnie napisane nazwy modułów, brakujące pliki modułów, nieprawidłowe opcje, nieoczekiwaną kolejność oraz zmiany wprowadzone podczas niedawnego wdrożenia pakietu lub uwierzytelniania. Flagi kontrolne mają znaczenie: requiredrejestrują błąd, ale kontynuują działanie na stosie; requisitemogą zostać natychmiast zatrzymane; sufficientumożliwiają szybki powrót do poprawnego działania, gdy żaden wcześniej wymagany moduł nie uległ awarii. Nie kopiuj stosu PAM z innej dystrybucji lub wydania SLES bez zrozumienia jego modułów i przepływu sterowania.

Przed dokonaniem jakichkolwiek zmian należy wykonać kopię zapasową bieżącego katalogu wyłącznie z uprawnieniami roota, zachowując dowiązania symboliczne:

backup_dir=/root/pam.d.backup.$(date +%Y%m%d-%H%M%S)
sudo cp -a /etc/pam.d "$backup_dir"

Sprawdź, czy kopia zapasowa istnieje i zapisz dokładnie, które pliki zostały zmienione. Jeśli wszyscy użytkownicy są zablokowani, skorzystaj z obsługiwanej procedury ratunkowej SLES i przywróć system ze znanej, dobrej konfiguracji, zamiast improwizować na ekranie logowania.

4. W systemie SLES sprawdź, czy pam-config zarządza plikami współdzielonymi

SUSE zapewnia pam-configobsługę globalnych plików PAM i obsługiwanych konfiguracji aplikacji. Jest to zazwyczaj bezpieczniejsze niż ręczna edycja generowanych współdzielonych stosów podczas dodawania lub usuwania obsługiwanej metody. Najpierw sprawdź dostępne moduły i aktualną integrację SSSD:

sudo pam-config --list-modules
sudo pam-config --query --sss

Jeśli serwer celowo korzysta z SSSD, a integracja nie jest dostępna, dokumenty SUSE sudo pam-config --add --ssswskazują sposób jej dodania. Należy to zrobić dopiero po potwierdzeniu projektu uwierzytelniania katalogów, sprawdzeniu bieżącego stosu, zachowaniu kopii zapasowej i upewnieniu się, że istnieje ścieżka odzyskiwania. Nie należy uruchamiać tego jako ogólnego rozwiązania dla każdego „błędu uwierzytelniania”. Ponownie sprawdź konfigurację i przetestuj w drugiej sesji.

Szczególnie ryzykownym poleceniem jest pam-config --create. SUSE twierdzi, że generuje ono prostą konfigurację uwierzytelniania Unix i nadpisuje istniejące pliki konfiguracyjne, które nie są obsługiwane przez system pam-config(zachowując jednocześnie kopie zapasowe z .pam-config-backupsufiksem). Nie jest to rutynowa naprawa po pojedynczym nieudanym logowaniu. Należy jej używać tylko wtedy, gdy celowo zamierzasz odbudować konfigurację i planujesz odzyskiwanie.

Jeśli Twoja organizacja celowo ręcznie zarządza plikami PAM, należy konsekwentnie stosować się do tego schematu. SUSE zaznacza, że ​​ręczna konfiguracja wymaga wyłączenia pam-configtych plików. Niestandardowe stosy powinny zachowywać niezbędne moduły sesji, w tym pam_systemd.soopcjonalne moduły sesji, tam gdzie to możliwe.

5. Oddzielne problemy z SSH, katalogiem i pulpitem

Jeśli tylko SSH odrzuca konto

Porównaj /etc/pam.d/sshdz konfiguracją SLES, która jest znana i prawidłowa, i sprawdź dziennik demona SSH w momencie nieudanego logowania. Upewnij się, że konto jest dozwolone przez ustawienia i mechanizmy kontroli dostępu SSH, a także przez PAM. Nie osłabiaj uwierzytelniania SSH ani nie usuwaj sprawdzania konta tylko po to, aby błąd zniknął.

Jeśli tylko użytkownicy katalogu zawiodą

Potwierdź wyszukiwanie konta za pomocą getent, sprawdź status i logi SSSD oraz zweryfikuj dostępność katalogu, DNS, synchronizację czasu, rejestrację hosta i zasady dostępu użytkownika. Jeśli inny użytkownik katalogu odniesie sukces, porównaj grupy, powłokę, katalog domowy i reguły dostępu specyficzne dla hosta dla danego konta. Podręcznik klienta uwierzytelniania SUSE opisuje zarządzane przez YaST SSSD i sprawdzanie jego statusu.

Jeśli logowanie do konsoli działa, ale sesja graficzna się nie powiedzie

Sprawdź graficzne logi logowania i sesji, dostępność katalogu domowego, właściciela, wolne miejsce na dysku oraz wszelkie kroki odblokowania szyfrowanego dostępu do komputera domowego. Pomyślne logowanie do konsoli tekstowej jest cennym dowodem na to, że hasło i ścieżka uwierzytelniania podstawowego działają; pozwala to skupić się na sesji pulpitu lub środowisku użytkownika. Unikaj usuwania plików użytkownika na początku. Poradnik rozwiązywania problemów firmy SUSE zaleca metodyczne izolowanie problemów z konfiguracją pulpitu.

6. Sprawdź naprawę bez ryzyka zablokowania

Po wprowadzeniu zmiany otwórz nową sesję testową, dopóki powłoka odzyskiwania pozostaje dostępna. Przetestuj usługę, której dotyczy problem, przy użyciu konta, którego dotyczy problem, a następnie przetestuj drugie konto i konto administratora lokalnego. W przypadku uwierzytelniania katalogu sprawdź wyszukiwanie konta i stan usługi, a także pomyślne logowanie. Sprawdź ponownie dziennik pod kątem nowych błędów PAM i usuń wszelkie tymczasowe ustawienia debugowania za pomocą odpowiedniej pam-config --deleteopcji po zakończeniu testowania.

Na koniec sprawdź, czy wynik rozwiązuje problem z etapem, który się nie powiódł, a nie go ukrywa. Stałe logowanie powinno uwierzytelnić właściwego użytkownika, wymusić odpowiednią politykę konta i utworzyć normalną sesję. Zachowaj kopię zapasową do czasu weryfikacji tych wyników i udokumentowania ostatecznej konfiguracji.

Kiedy należy zatrzymać się i użyć trybu ratunkowego?

Zaprzestań wprowadzania zmian zdalnych, jeśli utracisz dostęp do roota, wiele usług zawiedzie jednocześnie, współdzielony stos został nadpisany lub nie możesz określić, który menedżer konfiguracji jest właścicielem plików. Dokumentacja SLES opisuje użycie dostępu do roota do naprawy konfiguracji i przejścia do trybu ratunkowego, gdy normalne logowanie jest niedostępne. W przypadku zarządzanych systemów produkcyjnych, przed odbudowaniem współdzielonego stosu uwierzytelniania należy skontaktować się z zespołem ds. tożsamości lub platformy.

Aby poznać dokładną strukturę pliku PAM, flagi modułów, pam-configzachowanie i kroki odzyskiwania, skorzystaj z podręcznika PAM dla systemu SUSE SLES 15 SP7 oraz podręcznika SUSE Common-Problems Guide ( odpowiedniego dla danej wersji ). Stosy PAM to polityka bezpieczeństwa; wprowadź najmniejszą uzasadnioną zmianę, a następnie zweryfikuj zarówno dostęp, jak i ograniczenia.