홈랩의 웹 서비스 로그인을 authentik으로 모으다 보니 SMB도 같은 계정으로 사용할 수 있을지 궁금해졌습니다. 기존에는 Samba, OpenLDAP, SSSD를 함께 사용하고 있었습니다. ksmbd로 서버를 바꾸면서 authentik의 계정과 비밀번호 변경까지 연결할 수 있는지 복제 VM에서 실험했습니다.
2026년 10월 13일에 비밀번호 변경과 계정 비활성화까지 시험했습니다. 공식 authentik 이미지와 수정하지 않은 Samba·ksmbd 도구를 사용하는 경로도 작동했습니다. 다만 그 구성을 유지하려면 별도 정책과 동기화 프로그램을 관리해야 했습니다. 최종적으로는 운영의 Samba + OpenLDAP + SSSD 구성을 유지하기로 했습니다.
웹 로그인과 SMB 인증은 연결 방식이 다릅니다
웹 앱은 OIDC로 인증 서버에 사용자를 보내고, 돌아온 인증 정보를 앱의 계정과 연결할 수 있습니다. 이번 SMB 실험은 SMB3의 NTLM 인증을 대상으로 했습니다. 웹 앱에 쓰던 OIDC 설정을 추가하는 것으로 끝나는 문제가 아니었습니다.
사용자 이름과 UID/GID를 LDAP·SSSD에서 읽을 수 있어도, SMB 인증에 필요한 자격 증명이 자동으로 준비되는 것은 아닙니다. 이번에는 authentik에서 변경한 비밀번호에 대응하는 SMB용 정보를 서버에 반영하는 경로가 필요했습니다.
ksmbd의 사용자 모드 도구는 ksmbdpwd.db라는 로컬 사용자 DB를 사용합니다. Samba에서 사용하던 ldapsam과 같은 구성이 그대로 들어 있다고 가정할 수 없었습니다. 로컬 DB 형식과 갱신 방법은 ksmbd-tools의 사용자 DB 설명에서 확인했습니다.
처음에는 본체를 수정하는 경로를 시험했습니다
초기 실험에서는 authentik의 비밀번호 처리와 LDAP outpost, ksmbd-tools의 사용자 조회 코드를 수정했습니다. 비밀번호 변경 때 SMB용 NT 해시를 만들어 저장하고, ksmbd가 LDAP에서 현재 값을 조회하는 방식이었습니다.
동작을 구현하면서 업데이트 부담도 드러났습니다. 새 authentik 버전에서는 비밀번호 처리 코드와 DB 모델의 호환성을 다시 확인해야 했고, outpost와 ksmbd-tools도 새 소스를 기준으로 재빌드해야 했습니다. 공식 이미지에 예전 Python 파일을 덮어쓰는 방식은 업데이트하면서 이전 구현을 계속 끌고 가게 됩니다.
원래 목적은 계정 관리를 줄이는 것이었습니다. 인증 서버 본체의 변경과 여러 바이너리의 패치를 계속 관리해야 한다면, 장기적인 관리 부담도 함께 따져야 했습니다. 그래서 공식 확장 기능과 기존 관리 인터페이스를 사용하는 방식으로 실험을 다시 구성했습니다.
공식 Flow와 로컬 DB 동기화로 바꾸기
새 실험에서는 authentik 2026.8.3의 공식 server·worker·LDAP outpost 이미지를 사용했습니다. authentik Python 파일을 덮어쓰거나 outpost의 Go 바이너리를 교체하지 않았습니다. Samba는 배포판의 기존 바이너리를, ksmbd-tools는 소스 패치 없이 빌드한 바이너리를 사용했습니다.
사용자가 기본 비밀번호 변경 화면에 입력한 새 비밀번호를 공식 Flow의 정책에서 처리했습니다. SMB용 NT 해시를 계산하고 Fernet로 암호화한 다음, User Write stage에서 비밀번호와 암호화된 사용자 속성을 저장하도록 구성했습니다. Prompt에 입력한 값과 User Write의 관계는 Prompt stage 설명과 User Write stage 설명에 나와 있습니다.
authentik 기본 비밀번호 변경 화면
→ 공식 Flow의 정책에서 SMB용 정보 생성·암호화
→ User Write stage에서 저장
→ 공식 LDAP Provider로 암호화된 속성 조회
→ VM의 동기화 프로그램에서 복호화
→ ksmbdpwd.db 갱신과 reload
→ Samba tdbsam 갱신비밀번호 원문을 SMB VM으로 보내지 않았습니다. 암호화 키는 별도 Secret과 VM의 root 전용 설정으로 관리했습니다. VM의 동기화 프로그램은 2초 간격으로 LDAP를 조회해 변경을 반영했습니다.
ksmbd 쪽은 공식 사용자 DB와 reload 인터페이스를 사용했고, Samba 쪽은 pdbedit로 tdbsam에 반영했습니다. Samba의 import·export 기능은 pdbedit 문서를 기준으로 확인했습니다.
이 구성에서는 본체 소스를 수정하지 않아도 별도로 관리하는 코드가 남습니다. authentik의 비밀번호 정책과 VM의 동기화 프로그램이 그 부분입니다. 계정 상태 확인, DB 갱신, 오류 처리까지 이 코드의 책임이 됩니다.
비밀번호 변경과 계정 비활성화 시험하기
테스트는 운영 서버가 아닌 복제 VM의 단일 계정으로 수행했습니다. authentik의 기본 사용자 설정 화면에서 실제 HTTP 로그인과 비밀번호 변경을 진행한 뒤, 두 SMB 서버에서 새 인증을 시도했습니다.
| 검사 | ksmbd | Samba |
|---|---|---|
| 새 비밀번호로 신규 로그인 | 성공 | 성공 |
| 파일 읽기·쓰기 | 성공 | 성공 |
| 이전 비밀번호로 신규 로그인 | 거부 | 거부 |
| 계정 비활성화 후 신규 로그인 | 거부 | 거부 |
| 기존 SSSD UID/GID 유지 | 확인 | 확인 |
SSSD도 새 공식 LDAP outpost를 사용하도록 바꿨고, /etc/passwd에 테스트 사용자를 추가하지 않은 상태에서 기존 UID/GID를 유지하는 것을 확인했습니다. 계정 연결을 바꾸면서 파일 소유자가 달라지지 않는지도 같이 봤습니다.
이 실험에서 남은 관리 항목
2초 간격의 동기화라 비밀번호 변경과 SMB DB 갱신 사이에는 지연이 있습니다. 실제로 변경 직후 바로 접속했을 때는 새 비밀번호 인증에 실패했고, 동기화 후에는 성공했습니다. 그동안 이전 비밀번호가 잠시 유효할 수도 있습니다. 이미 연결된 SMB 세션을 강제로 종료하는 기능은 넣지 않았습니다.
기본 사용자 비밀번호 변경 Flow에 정책을 넣었다고 모든 변경 경로가 연결되는 것도 아닙니다. 관리자 UI의 직접 비밀번호 설정, API 변경, 가입과 복구 Flow에는 별도의 연결과 검증이 필요합니다. 이번 결과는 사용자 설정 화면의 비밀번호 변경 경로에 대한 것입니다.
LDAP의 속성 반환과 검색 필터 호환성도 확인해야 했습니다. 사용자 검색 결과에 sambaSamAccount 값이 보였지만, 해당 objectClass를 포함한 필터로 검색하면 결과가 없었습니다. 이 실험에서 Samba가 성공한 경로는 tdbsam 동기화이며, 공식 authentik LDAP를 기존 ldapsam에 그대로 연결한 결과는 아닙니다.
테스트 LDAP 연결은 내부망의 평문 연결이었고, SMB 자격 증명 속성 자체를 암호화했습니다. 다중 사용자 운영에 쓰려면 LDAP 전송 보호, 키 관리, 동시에 발생하는 변경과 장애 복구도 추가로 검증해야 합니다. 인증 서버의 저장과 두 SMB DB의 갱신 전체가 하나의 트랜잭션으로 처리되는 구조도 아닙니다.
운영에서는 기존 Samba 구성을 유지하기로 했습니다
실험으로 확인한 것은 공식 authentik Flow와 LDAP Provider, 수정하지 않은 SMB 도구를 연결해 비밀번호 변경을 반영할 수 있다는 점입니다. 그 대가로 정책과 동기화 서비스를 운영해야 하고, 인증 실패나 갱신 지연을 진단할 지점도 늘어났습니다.
제 목표에는 기존 Samba + OpenLDAP의 ldapsam + SSSD 구성을 유지하는 편이 맞았습니다. 이 실험으로 운영 Samba를 전환하지 않았고, ksmbd 전환 실험은 여기서 마쳤습니다.
이번에는 새 구성이 작동하는 것까지 확인한 뒤 기존 구성을 선택했습니다. 운영 방식을 바꿀 때는 기능 구현과 함께, 다음 업데이트와 장애 때 무엇을 관리해야 하는지도 판단 기준이 된다는 경험이었습니다.
답글 남기기