PAM 모듈을 알 수 없음: 실제로 어느 프로세스가 실패했는가

그 문구를 비밀번호가 아니라 공유 객체와 함수 포인터에 대한 진술로 읽으십시오. 같은 단어는 OpenVPN 플러그인에서, 한 서비스용으로 로드된 PAM 스택에서, 또는 RADIUS 데몬 내부에서 나올 수 있으며 이는 서로 다른 세 가지 조사입니다. 먼저 프로세스를 특정하십시오.

아래 확인은 메시지가 VPN 로그인에서 Linux-PAM 통합을 통해 나타났다고 가정합니다. RADIUS 서버 자체의 구성에서 나왔다면 그 데몬의 증거부터 시작하십시오.

패키지를 지목하기 전에 프로세스를 지목하십시오

세 구성 요소가 모듈로 불리며 어느 것도 서로 바꿀 수 없습니다. OpenVPN 인증 플러그인은 VPN 데몬이 로드하며 그 데몬의 콜백 인터페이스를 구현합니다. PAM 모듈은 공유 객체로, libpam이 이름이 지정된 서비스를 위해 로드하는 것이며 다음과 같은 진입점을 구현합니다: pam_sm_authenticate. FreeRADIUS 모듈은 그 데몬 자체 구성의 일부입니다. 같은 단어를 가진 메시지는 세 가지 어디에서나 나올 수 있으므로 첫 질문은 어느 로그 줄이 그것을 만들었는가입니다.

실패한 시도 하나의 타임스탬프를 VPN 로그와 시스템 인증 로그에서 대조한 뒤 요약 앞의 줄을 읽으십시오. 구체적인 로더 메시지는 대개 이미 거기에 있습니다.

로딩 오류를 읽고, 다음으로 진입점을 읽으십시오

PAM은 선택한 공유 객체를 로드할 수 없거나 로드된 객체가 해당 스택 항목이 요구하는 함수를 제공하지 않을 때 알 수 없는 모듈을 보고합니다. 이것은 서로 다른 수리로, 첫째는 경로, 패키징 또는 ABI 문제이고 둘째는 일치하지 않는 진입점입니다. 인증 줄에는 pam_sm_authenticate 이 필요하고 계정 줄에는 pam_sm_acct_mgmt 이 필요하며, 둘 중 하나만 구현한 라이브러리는 다른 쪽에서 실패하는데, 이는 디스패처 코드가 보여주는 바와 같습니다. 디스크에서 파일을 찾는 것은 둘 중 어느 것도 증명하지 않습니다.

다른 배포판이나 CPU 아키텍처에서 비슷한 이름의 라이브러리를 가져오는 것은 수리가 아니며, 프로세스가 자신의 libpam에 대해 한 번도 시험되지 않은 모듈을 로드하도록 남길 수 있습니다. 무엇이든 바꾸기 전에 의도한 경로를 소유한 패키지와 파일의 실제 아키텍처를 확인하십시오.

스택이 제공하던 보장을 유지하십시오

이 오류를 잠재우는 가장 빠른 방법은 가장 나쁐 방법이기도 하며, 필수 모듈을 선택 사항으로 표시하거나, 계정 단계를 삭제하거나, 또는 무조건 허용을 삽입하는 것입니다. 이들 각각은 실패한 확인을 없는 확인으로 바꾸며, 그러면 로그인은 아무도 의도하지 않은 이유로 성공합니다. 비밀번호 재설정과 공유 비밀 변경도, 실패가 어느 자격 증명도 백엔드에 도달하기 전에 일어나므로 빠진 함수를 제공하지 않습니다.

다중 모듈 스택은 실패한 항목 전에 다른 백엔드를 실행했을 수 있으므로, 이 오류는 RADIUS 요청이 전송되지 않았다는 것을 증명하지 않습니다.

모듈이 아니라 로그인을 검증하십시오

불일치가 수정되면 실제 허용 경로를 시험하고, 유효한 계정은 통과해야 하며, 잘못된 자격 증명은 여전히 실패해야 하고, 금지된 계정은 여전히 거부되어야 합니다. 인증서나 추가 요소 요구가 여전히 적용되는지도 확인하십시오. 단계를 건너뛰는 수리된 스택은 클라이언트 쪽에서 성공처럼 보이기 때문입니다.

모듈이 깨끗하게 로드되는 것은 진전이며, 끝난 시험이 아닙니다.

어떤 서비스 이름, 어떤 정책 파일, 어떤 진입점이 관련되었는지, 증거로 사용한 단 한 번의 시도와 함께 기록하십시오. 그 기록이 다음 발생을 고고학 연습이 아니라 조회로 만듭니다.