다음을 달성하는 가장 확실한 방법은 무엇입니까? 사이트에는 작동 중인 AD 인프라가 있고 인프라의 특정 부분은 AD OU의 사람들이 ou=linux-users,dc=example,dc=com자신의 컴퓨터를 사용하여 인프라의 Linux 부분에 로그온할 수 있어야 하는 GNU/Linux 시스템과 긴밀하게 결합되어 있습니다. AD 자격 증명이지만 Linux 시스템의 PAM 스택에서 DC를 사용하지 않습니다. 즉, AD에서 slapd까지 POSIX 속성(uid,gid,homedir,password)을 사용하여 일종의 동기화와 확장이 있어야 합니다. Linux 시스템의 slapd는 OpenLDAP이고, AD의 스키마는 POSIX 속성이 없는 Windows 2003의 것입니다.
답변1
Ldap 동기화 커넥터(LSC)AD에서 OpenLDAP 서버로 지속적인 동기화를 설정하는 동시에 원하는 대로 생성된 추가 속성을 추가하는 데 사용할 수 있습니다.
그러나 BIND 요청을 AD 서버에 전달하도록 OpenLDAP를 설정하지 않는 한 AD 자격 증명을 직접 사용할 수는 없지만 사용 가능한 AD 인프라에 따라 달라집니다.
AD에서 자격 증명을 사용하는 것은 어렵습니다. 왜냐하면 일반 텍스트로 된 자격 증명을 다른 곳에서 보유해야 하거나 바인딩을 위해 AD를 사용하거나 암호 동기화를 설정해야 하기 때문입니다. 확인해 보세요Active Directory 비밀번호 동기화 옵션.
해당 페이지에 설명되지 않은 한 가지 옵션은 AD 서버에서 해시된 비밀번호 목록을 내보내는 것이지만 이는 지속적인 동기화가 아닌 일회성 작업입니다.
답변2
PAM 스택에 AD 서버를 원하지 않는 특별한 이유가 있습니까? 여기서 가장 좋은 해결책은 AD 사용자에게 POSIX/RFC2307 속성을 추가하고 AD 서버에서 pam_ldap/nss_ldap(또는 nss_ldapd)을 지정하는 것입니다.
AD를 직접 쿼리할 수 없는 네트워크 보안/부하 문제가 있는 경우 OpenLDAP의 프록시/캐시 기능을 사용하거나 제한된 AD 슬레이브를 배포하여 Linux 호스트에 서비스를 제공할 수 있습니다.
나는 "증강된" 계정을 갖는 것에 대해 조언하고 싶습니다. 꽤 더러운 해킹을 통해 수행할 수 있지만 제 경험상 프로덕션 환경을 신뢰하기에는 너무 취약합니다. 이는 또한 "신뢰할 수 있는 하나의 소스" 패러다임을 깨뜨립니다. 즉, AD가 신뢰할 수 있는 계정 저장소인 경우 POSIX 속성을 거기에 추가하고 관리해야 합니다.