Moduł PAM jest nieznany: który proces naprawdę zawiódł

Czytaj to zdanie jako stwierdzenie o obiekcie współdzielonym i wskaźniku funkcji, a nie o haśle. Te same słowa mogą pochodzić z OpenVPN wtyczki, ze stosu PAM załadowanego dla jednej usługi albo z wnętrza demona RADIUS, i to trzy różne dochodzenia. Najpierw ustal proces.

Poniższe kontrole zakładają, że komunikat pojawił się przez integrację Linux-PAM przy logowaniu VPN. Jeśli pochodzi z własnej konfiguracji serwera RADIUS, zacznij od dowodów tego demona.

Nazwij proces, zanim nazwiesz pakiet

Trzy komponenty nazywa się modułem i żaden nie jest wymienny. Wtyczkę uwierzytelniania OpenVPN ładuje demon VPN i implementuje ona interfejs wywołania zwrotnego tego demona. Moduł PAM to obiekt współdzielony, który libpam ładuje dla nazwanej usługi, i który implementuje punkty wejścia takie jak pam_sm_authenticate. Moduł FreeRADIUS jest częścią własnej konfiguracji tego demona. Komunikat z tymi samymi słowami może pochodzić z każdego z trzech, więc pierwsze pytanie brzmi, która linia dziennika go wytworzyła.

Powiąż znacznik czasu jednej nieudanej próby między dziennikiem VPN a dziennikiem uwierzytelniania systemu, a następnie przeczytaj wiersze przed podsumowaniem. Konkretny komunikat loadera zwykle już tam jest.

Przeczytaj błąd ładowania, potem punkt wejścia

PAM zgłasza nieznany moduł, gdy nie może załadować wybranego obiektu współdzielonego albo gdy załadowany obiekt nie dostarcza funkcji wymaganej przez ten wpis stosu. To różne naprawy: pierwsza to problem ścieżki, pakowania lub ABI, a druga to niedopasowany punkt wejścia. Wiersz uwierzytelniania potrzebuje pam_sm_authenticate natomiast wiersz konta potrzebuje pam_sm_acct_mgmt, a biblioteka implementująca tylko jedną z nich zawiedzie na drugiej, jak kod dyspozytora pokazuje. Znalezienie pliku na dysku nie dowodzi ani jednego, ani drugiego.

Wzięcie biblioteki o podobnej nazwie z innej dystrybucji lub architektury procesora nie jest naprawą i może pozostawić proces ładujący moduł, który nigdy nie był testowany z jego libpam. Przed zmianą czegokolwiek sprawdź pakiet właściciela zamierzonej ścieżki oraz rzeczywistą architekturę pliku.

Zachowaj gwarancje, których dostarczał stos

Najszybszy sposób uciszenia tego błędu jest też najgorszy: oznaczenie wymaganego modułu jako opcjonalnego, usunięcie etapu konta, albo wstawienie bezwarunkowego zezwolenia. Każde z nich zamienia nieudaną kontrolę w brakującą kontrolę, a logowanie udaje się wtedy z powodów, których nikt nie zamierzał. Resetowanie haseł i zmiany wspólnego sekretu również nie dostarczają brakującej funkcji, bo awaria następuje, zanim jakiekolwiek dane uwierzytelniające dotrą do backendu.

Stos z wieloma modułami mógł uruchomić inny backend przed nieudanym wpisem, więc błąd nie dowodzi, że nie wysłano żądania RADIUS.

Weryfikuj logowanie, a nie moduł

Po poprawieniu niezgodności przetestuj rzeczywistą ścieżkę dopuszczenia. Ważne konto powinno przejść, nieprawidłowe dane uwierzytelniające powinny nadal zawodzić, a konto zabronione powinno nadal być odrzucane. Potwierdź też, że wszelkie wymagania dotyczące certyfikatu lub dodatkowego czynnika nadal są egzekwowane, bo naprawiony stos, który pomija etap, wygląda z perspektywy klienta jak sukces.

Czyste załadowanie modułu to postęp, a nie zakończony test.

Zapisz, jaka nazwa usługi, jakie pliki polityki i jakie punkty wejścia były zaangażowane, wraz z jedyną próbą, której użyłeś jako dowodu. To właśnie ten zapis czyni następne wystąpienie wyszukiwaniem, a nie ćwiczeniem archeologicznym.