본질적으로 Active Directory 내의 OctetString 특성에 개인 키 (해시)를 저장하고 있습니다.
제 질문은 기본적으로 어떤 속성이 안전하며 개인 데이터를 유지하는 것이 합리적입니까? 이 값은 현재 AD 비밀번호와 마찬가지로 관리자도 액세스 할 수없는 경우 비밀번호와 유사한 것으로 간주해야합니다.
다음은 Windows 2008R2 + Exchange 2010 도메인에서 기본적으로 사용되는 속성 목록의 시작입니다.
최신 정보:
기본적으로 도메인의 모든 사용자에게 "읽기"권한을 표시하지 않는 Octet String 속성을 알고 있습니까? 해시를 공개적으로 저장하고 싶지 않으며 누군가 해시를 기반으로 무지개 테이블을 만들 수 있습니다.
답변:
AD에 데이터를 저장할 때 대부분의 사람들이 직면하는 문제는
스키마 확장 (종종 회사 정치적 의미가 있음)
기존 속성 사용 및 권한 편집 (DIT 및 후속 복제 크기를 증가시키는 AD / ACL 팽창으로 이어짐)
대안이 있습니다 ... 내 마음에 가장 좋은 선택은 AD의 덜 알려진 기능을 사용하여 기존 속성을 가져 와서 기밀로 플래그 지정하는 것입니다.
프로세스에 대한 자세한 내용은 다음과 같습니다.
Active Directory의 기본 권한은 인증 된 사용자가 모든 속성에 대해 포괄적 인 읽기 권한을 갖도록하는 것입니다. 따라서 모든 사람이 읽을 수 없도록 보호해야하는 새로운 속성을 도입하기가 어렵습니다.
이를 완화하기 위해 Windows 2003 SP1에는 특성을 CONFIDENTIAL로 표시하는 방법이 도입되었습니다. 이 기능은 스키마의 속성에서 searchFlags 값을 수정하여 수행됩니다. SearchFlags는 속성의 다양한 속성을 나타내는 여러 비트를 포함합니다. 예를 들어 비트 1은 속성이 인덱싱되었음을 의미합니다. 새로운 비트 128 (7 번째 비트)은 속성을 기밀로 지정합니다.
주 : 기본 스키마 속성 (common-name과 같은 "top"에서 파생 된 속성)에는이 플래그를 설정할 수 없습니다. LDP를 사용하여 객체를보고 객체의 systemFlags 속성을 확인하여 객체가 기본 스키마 객체인지 확인할 수 있습니다. 10 번째 비트가 설정되면 기본 스키마 개체입니다.
디렉토리 서비스는 읽기 액세스 확인을 수행 할 때 기밀 속성을 확인합니다. READ_PROPERTY 액세스 외에 디렉토리 서비스에는 속성 또는 해당 속성 세트에 대한 CONTROL_ACCESS 액세스가 필요합니다.
기본적으로 관리자 만 모든 개체에 CONTROL_ACCESS 액세스 할 수 있습니다. 따라서 관리자 만 기밀 속성을 읽을 수 있습니다. 사용자는이 권한을 원하는 특정 그룹에 자유롭게 위임 할 수 있습니다. 이는 DSACL 도구, 스크립팅 또는 RDP ADAM 버전의 LDP를 사용하여 수행 할 수 있습니다. 이 글을 쓰는 시점에서 ACL UI Editor를 사용하여 이러한 권한을 할당 할 수는 없습니다.
속성을 기밀로 표시하고 속성을보아야하는 사용자를 추가하는 프로세스에는 3 단계가 있습니다.
기밀을 표시 할 속성 결정 또는 기밀을 표시 할 속성 추가
기밀로 표시
올바른 사용자에게 Control_Access 권한을 부여하면 속성을 볼 수 있습니다.
자세한 내용과 단계별 지침은 다음 문서를 참조하십시오.
922836 Windows Server 2003 서비스 팩 1에서 특성을 기밀로 표시하는 방법
http://support.microsoft.com/default.aspx?scid=kb;EN-US;922836
이를 위해 항상 새 필드를 사용하여 Active Directory를 확장 할 수 있습니다.
다음은 새 속성 추가 및 속성에 대한 권한 제한에 대한 지침이 포함 된 문서 입니다.
이 값은 현재 AD 비밀번호와 마찬가지로 관리자도 액세스 할 수없는 경우 비밀번호와 유사한 것으로 간주해야합니다.
이것은 정확하지 않으며 심지어 잘못되었습니다. 비밀번호가 저장되지 않았습니다. 해시가 저장되고 도메인 관리자가 액세스 할 수 있습니다. 실제로 원하는 경우 암호를 가역 암호화로 저장하도록 AD를 구성 할 수도 있습니다.
AD에서 도메인 관리자를 막을 수있는 것은 없습니다. 권한을 제거하거나 거부하면 도메인 관리자가 소유권을 가져와 다시 추가 할 수 있습니다. 이는 OU의 관리자가 높은 수준의 관리자를 취소 할 수없는 Novell의 NDS와는 대조적입니다.
최선의 방법은 기존 속성이나 새 속성을 사용하고 액세스를 제한하는 것입니다. 관리자가 관리 권한을 유지하지 못하게하고 액세스 또는 권한 변경이 기록되도록 속성에 대한 감사를 활성화 할 수 있습니다.