Linux 서버의 Active Directory 인증에 대한 일반적인 지식은 무엇입니까?

Linux 서버 및 최신 Windows Server 운영 체제 (CentOS / RHEL 중심)의 Active Directory 인증 / 통합에 대한 2014 년의 공통된 지식은 무엇입니까 ?

2004 년 처음 통합을 시도한 이후 몇 년 동안이 문제에 대한 모범 사례가 바뀌는 것처럼 보입니다. 현재 어떤 방법이 가장 큰 모멘텀인지 확실하지 않습니다.

현장에서 나는 보았다 :

winbind를 / 삼바
스트레이트 업 LDAP
때로는 LDAP + Kerberos를
Microsoft Windows 서비스 유닉스 (SFU)에 대한
유닉스 용 Microsoft ID 관리
NSLCD
SSSD
FreeIPA
Centrify
Powerbroker ( 노나 마찬가지로 )

Winbind는 항상 끔찍하고 신뢰할 수없는 것처럼 보였습니다. Centrify 및 Likewise와 같은 상용 솔루션은 항상 작동했지만이 기능이 OS에 포함되어 있기 때문에 불필요 해 보였습니다.

내가 마지막으로 설치 한 것은 Linux 쪽 (RHEL5의 경우)에 Windows 2008 R2 서버 및 NSLCD에 Microsoft Identity Management for Unix 역할 기능이 추가 된 것입니다. 이는 NSLCD 및 메모리 리소스 관리 문제에 대한 유지 관리 부족으로 SSSD가 변경되는 RHEL6까지 작동했습니다. Red Hat은 SSSD 접근 방식을 지원하는 것처럼 보였으므로 사용하기에 좋습니다.

도메인 컨트롤러가 Windows 2008 R2 Core 시스템이고 Identity Management for Unix 역할 기능을 추가 할 수없는 새로운 설치 작업을하고 있습니다. 이 기능은 더 이상 사용되지 않으며 Windows Server 2012 R2 에는 더 이상 존재 하지 않는다고 들었습니다 .

이 역할을 설치하면이 GUI가 있다는 장점이 있지만 사용자 속성을 한 단계 쉽게 관리 할 수 ​​있습니다.

그러나...

RSAT (원격 서버 관리 도구)의 NIS (Network Information Service) 도구 용 서버 옵션은 더 이상 사용되지 않습니다. 기본 LDAP, Samba 클라이언트, Kerberos 또는 Microsoft 이외의 옵션을 사용하십시오.

따라서 호환성을 깨뜨릴 수 있다면 의지하기가 정말로 어렵습니다. 고객은 Winbind를 사용하려고하지만 Red Hat 측면에서 볼 수있는 모든 것은 SSSD 사용을 가리 킵니다.

올바른 접근 방식은 무엇입니까?
당신은 어떻게이 처리하나요 사용자 환경?

2014 년 3 월 Red Hat 은 Red Hat Enterprise Server를 Active Directory와 통합 하기위한 참조 아키텍처를 발표했습니다 . (이 자료는 확실히 최신의 내용이어야합니다.) 나는 이것을 답변으로 게시하는 것을 싫어하지만 실제로 답변 필드로 옮기기에는 너무 많은 자료입니다.

이 문서 (수정 됨)는 언론에서 널리 알려졌습니다. RHEL (Red Hat Enterprise Linux) 7의 새로운 기능에 초점을 맞추는 것 같습니다. 이 문서 는 지난 주 Summit에 게시되었습니다.

이 링크가 오래되면 알려주세요. 그에 따라 답변을 업데이트하겠습니다.

개인적으로 WinBind를 인증에 상당히 안정적으로 사용했습니다. 루트 또는 다른 로컬 계정을 가진 사람이 들어 와서 winbindd를 반송해야하는 매우 드문 서비스 실패가 있습니다. 노력을 기울이면 적절한 모니터링을 통해 문제를 해결할 수 있습니다.

Centrify에는 추가 기능이 있지만 별도의 구성 관리를 통해 제공 할 수 있습니다. (인형 등)

6/16/14 수정 :

Red Hat Enterprise Linux 7 Windows 통합 안내서

re : "Centrify 및 Likewise와 같은 상용 솔루션은 항상 작동했지만이 기능이 OS에 구워 졌기 때문에 불필요한 것처럼 보였습니다."

글쎄요, 우리 대부분은 XYZ 운영 체제가 마침내 AD 통합 퍼즐을 깨뜨린다는 소식을 듣고 있다고 생각합니다. 문제는 OS 공급 업체에게 AD 통합은 확인란 기능입니다.

1. 그들의 OS 플랫폼과
2. 해당 플랫폼의 현재 버전
3. 최신 버전의 Active Directory에 대해

실제로 대부분의 환경은 OS 공급 업체 및 OS 버전 측면에서 모 놀리식이 아니며 이전 버전의 AD가있을 것입니다. 따라서 Centrify와 같은 공급 업체는 450 가지 이상의 UNIX / Linux / Mac 등을 지원해야합니다. RHEL 7뿐만 아니라 Windows 2000 R2에서 Windows 2012 R2까지.

또한 AD 배포 방식도 고려해야합니다. OS 공급 업체의 AD 통합은 RODC (읽기 전용 도메인 컨트롤러), 단방향 트러스트, 다중 포리스트 지원 등을 지원합니다. 기존 UID 공간 (있는 경우)에는 UID를 AD로 마이그레이션하는 마이그레이션 도구가 있습니까? 또한 OS 공급 업체의 AD 지원은 UID 공간이 평평하지 않은 상황에서 여러 UID를 단일 AD에 매핑하는 기능을 해결합니다. 그리고 어떻습니까 ... 당신은 아이디어를 얻습니다.

그런 다음 지원 문제가 있습니다 ...

요점은 AD 통합이 개념적으로 쉬운 것처럼 보이고 공급 업체의 최신 OS와 "무료"일 수 있으며 한 공급 업체의 OS 버전이 하나만 있고 최신 버전 인 바닐라 AD가있는 경우 작동 할 수 있습니다. 발생할 수있는 문제를 해결하기 위해 최선을 다할 OS 공급 업체와의 프리미엄 지원 계약. 그렇지 않으면 특수한 타사 솔루션을 고려할 수 있습니다.

RSAT (원격 서버 관리 도구)의 NIS (Network Information Service) 도구 용 서버 옵션은 더 이상 사용되지 않습니다.

NIS는 Sun이 우리를 미워했고 우리가 비참 해지기를 바랐다는 증거입니다.

기본 LDAP, Samba 클라이언트, Kerberos 또는 Microsoft 이외의 옵션을 사용하십시오.

이것은 좋은 조언입니다. "기본 LDAP 사용 (SSL을 통해 사용하십시오.)"이라는 옵션을 선택할 수 있습니다. 여기에는 pam_ldap + nss_ldap (PADL에서) 또는 nss-pam- 조합으로 가장 익숙한 옵션이 많이 있습니다. ldapd (포크로 시작되었으며 지속적인 개발 및 향상을 보았습니다).

RedHat에 대해 구체적으로 묻는 것이기 때문에 RedHat은 SSSD를 사용하는 다른 대안 을 제공 한다는 점에 주목할 가치가 있습니다 .
귀하의 환경이 모든 RedHat이거나 많은 RedHat 시스템을 보유하고 있다면 공식적으로 지원되는 "RedHat Way of Doing Things"를 조사하는 것이 확실히 가치가 있습니다.

RedHat / SSSD에 대한 경험이 없으므로 문서를 사용하고 있지만 상당히 강력하고 잘 디자인 된 것 같습니다.

제안 된 방법 중 찬반론 목록을 제공하겠습니다.

Kerberos / LDAP 정리

장점 : 올바르게 구성하면 효과적입니다. 회복력이 거의없는 끊임없는 네트워크 고장에서도 살아남을 수 있습니다. AD에서 변경이 필요하지 않고 스키마 변경이 없으며 AD에 대한 관리자 액세스가 필요하지 않습니다. 비어 있는.

단점 : 상대적으로 구성하기가 어렵습니다. 여러 파일을 변경해야합니다. 인증 서버 (Kerberos / LDAP)를 사용할 수 없으면 작동하지 않습니다.

윈 바인드

장점 : 구성하기 쉽습니다. 기본 sudo 기능. 비어 있는.

단점 : 집중적 인 지원. 네트워크 탄력성이 아닙니다. 네트워크 문제가있는 경우 지원 작업 인 서버를 다시 등록해야하는 AD에서 Linux 시스템이 제거 될 수 있습니다. AD의 관리자 계정에 액세스해야합니다. AD에서 스키마를 변경할 수 있습니다.

원심 / 마찬가지로 등

장점 : 비교적 쉽게 구성 할 수 있습니다.

단점 : sudo 기능을 독점적이고 지원하기 어려운 것으로 변경합니다. 서버 당 라이센스 비용. 관리 할 추가 기술이 필요합니다.

SSSD

장점 : 하나의 구성 파일로 구성이 쉽습니다. 현재 및 향후의 모든 인증 방법과 함께 작동합니다. 확장 성, 시스템과 함께 성장합니다. 연결이 끊긴 모드에서 작동합니다. 네트워크 탄력성. AD 스키마를 변경할 필요가 없습니다. AD 관리자 자격 증명이 필요하지 않습니다. 무료 지원.

단점 : DNS 자동 업데이트와 같은 승리 서비스가 없습니다. CIFS 공유를 구성해야합니다.

개요

장점과 단점을 살펴보면 SSSD가 확실한 승자입니다. 새로운 시스템 인 경우 SSSD 이외의 다른 것을 사용할 이유가 없습니다. 현재의 모든 인증 방법과 함께 작동하고 시스템과 함께 확장 할 수있는 통합 기입니다. 사용 가능한 경우 새로운 방법을 추가 할 수 있기 때문입니다. 기본 Linux 방법을 사용하며 훨씬 더 안정적이고 빠릅니다. 캐싱이 켜져 있으면 시스템은 전체 네트워크 장애가있는 완전히 분리 된 시스템에서도 작동합니다.

변경해야 할 작업이 너무 많으면 기존 시스템에 Winbind를 사용할 수 있습니다.

Centrify에는 비용이 많이들 수있는 통합 문제가 있습니다. 대부분의 버그는 새 릴리스에서 수정되었지만 여전히 두통을 유발하는 버그가 있습니다.

나는 이러한 모든 방법으로 작업했으며 SSSD가 확실한 승자입니다. 구형 시스템의 경우에도 Winbind에서 SSSD로 변환하기위한 ROI는 매우 높습니다. SSSD를 사용하지 않는 특별한 이유가 없다면 항상 SSSD를 사용하십시오.

이것에 대해 언급해야합니다 :

Centrify에는 추가 기능이 있지만 별도의 구성 관리를 통해 제공 할 수 있습니다. (인형 등)

Centrify와 함께 일하는 사람은 그 의견이 어디에서 왔는지 확실하지 않습니다. 이것을 보면 Puppet과 같은 구성 관리 도구로 얻을 수없는 기능 이 많이 있음 을 알 수 있습니다. 예를 들어, 여러 UID를 단일 AD 계정 (영역)에 매핑 지원, 전체 Active Directory 도메인 트러스트 지원 (3 페이지의 Red Hat 솔루션에서 지원하지 않는 문서) 지원 등

그러나이 Red Hat 가이드로 돌아갑니다. Red Hat이 이것을 게시하고 있으며 옵션이 좋습니다. 고객에게 기본 AD 통합을 수행 할 수있는 10 가지 옵션이 제공됩니다. 대부분의 옵션은 Winbind의 변형이며 15 페이지에는 각각의 장단점이 나열되어 있으며 각 단계마다 수동 단계가 필요합니다 (위에 해당하는 단점 / 기능 부족). Centrify Express의 장점은 위의 다른 주석 작성자는 다음과 같습니다.

1. 모든 수동 단계없이 설치하는 것이 간단합니다 ...
2. 무료이며 ...
3. Red Hat V7에만 국한된 것은 아닙니다. Centrify는 300 가지가 넘는 * nix 및 ...
4. Windows 2008뿐만 아니라 Windows AD의 모든 변형을 지원합니다. Centrify와 Winbind의 비교를 여기에 게시 했지만 오픈 소스는 아닙니다.

결국 그것은 당신이 그것을 굴 리거나 상업용 솔루션으로 가고 싶을 정도로 끓습니다. 당신이 어디에서 어떻게 시간을 보내는 지 정말 중요합니다.