Active Directory에 대해 인증 할 때 어떤 필드를 사용해야합니까?


12

Active Directory 사용자 개체에는 식별자로 간주 될 수있는 많은 필드가 있습니다. 다음은 ADUC의 레이블 및 속성 이름과 함께 이들 중 일부를 나열합니다.

  • 이름-cn
  • ? -이름
  • 사용자 sAMAccountName 로그온-sAMAccountName
  • 사용자 UPN 로그온 : userPrincipalName
  • ? -distinguishedName

AD에 대해 인증하는 사용자 지정 코드를 작성할 때 개발자가 이들 중 하나만 사용하도록 표준화하려고합니다. 문제는 "올바른"것인지 확실하지 않거나 다른 것이 맞는지 확실하지 않은 것입니다. 상황. 위의 필드 중 하나를 사용해야할지 확실하지 않습니다!

다른 사람이 합리적으로 사용할 것을 골랐습니까? 그리고 그 결정에 어떤 영향을 미쳤습니까? 문제를 설명하는 문서가 있습니까?


cn 필드를 사용하여 LDAP를 통해 인증하는 몇 가지 응용 프로그램 (내부 개발 및 다른 사람들이 수행 한 작업)이 발생했습니다. 이름 또는 성 필드를 변경하면이 필드가 AD Admin Center (성명으로 표시됨)에서 자동으로 업데이트되므로 cn 필드를 사용자 이름 필드로 간주 할 수 없습니다. 이 개발자들이 잘못된 필드를 사용 했습니까, 아니면 Microsoft가 cn을 깨뜨 렸습니까?
dunxd

답변:


18

CN만으로는 사용자를 고유하게 식별하지 않으므로 CN (일반 이름)은 로그인에 적합하지 않습니다. 나는 가질 수 있었다

CN=Ryan Ries,OU=Dallas,DC=Domain,DC=com

나는 또한

CN=Ryan Ries,OU=New York,DC=Domain,DC=com

사용자의 CN은 RDN (상대 식별 이름)이기도합니다. CN은 같지만 DN은 다릅니다. 조직에 Ryan Ries라는 두 사람이 있으면 문제가 발생하여 두 번째 사람에 대해 SamAccountName을 만들어야합니다 rries2.

CN=ryan,OU=Texas,DC=brazzers,DC=com? 와 같은 사용자 이름으로 시스템에 로그인하려는 사람이 있기 때문에 DN (고유 이름)은 로그인하기에 좋지 않습니다 . DN을 사용하면 사용자를 고유하고 확실하게 식별하지만 입력 해야하는 것은 성가신 일입니다. 파일 시스템의 상대 경로와 절대 경로 간에는 동일한 개념입니다. 또한 디렉터리 구조에서 개체를 검색하지 않고도 개체의 위치를 ​​정확하게 알 수 있습니다. 당신은 종종하지 않습니다.

이를 ANR (모호한 이름 확인)이라고합니다. 고유 이름이없는 경우 사용자를 위해 디렉토리를 검색합니다.

UPN (User principal name)은 이메일 주소처럼 보이고, 사용자의 회사 이메일 주소와 같을 수 있으며, 기억하기 쉽고, 이름을 검색하기 때문에 로그인하는 것이 좋습니다. 포리스트에서 검색하기 전에 먼저 로컬 도메인에서

Microsoft의 말 : UPN의 요점은 사용자가 단일 이름 만 기억하면되도록 전자 메일 및 로그온 네임 스페이스를 통합하는 것입니다. UPN은 Windows 사용자가 선호하는 로그온 이름입니다. 사용자는 UPN을 사용하여 도메인에 로그온해야합니다. 로그온시 먼저 로컬 도메인을 검색 한 다음 글로벌 카탈로그를 검색하여 UPN의 유효성을 검사합니다. 로컬 도메인 또는 GC에서 UPN을 찾지 못하면 UPN이 거부됩니다. 사용자 계정을 만들 때 UPN을 할당 할 수 있지만 필수는 아닙니다 .

응용 프로그램을 설계 할 때 마지막에 "필요하지 않음"비트를 명심하십시오.

SamAccountName은 도메인의 모든 사용자에 대해 고유해야하지만 포리스트가 아닌 SamAccountName도 좋습니다. 또한 SamAccountName은 짧습니다. 대부분의 사람들은 AD 포리스트에서 사용자를 고유하게 식별하지 않더라도 SamAccountNames로 로그인하므로 SamAccountName과 함께 갈 도메인 이름을 지정해야 시스템에서 로그인하려는 도메인을 시스템이 알 수 있습니다. .

다음은 추가로 읽을 수있는 문제에 대한 훌륭한 문서입니다.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms677605(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx


4

다른 사람이 로그인 할 때 사용자 이름으로 사용자 이름을 참조하는 경우 sAMAccountName도메인 이름과 함께 고유 한, 또는 userPrincipalName포리스트 내에서 고유 한을 권장합니다 .

고유 식별자와 같은 사용자 이름 인 경우 Windows는 모든 액세스 제어 항목에 SID를 사용하며 사용자 이름에서 SID로 변환하기위한 전체 방법을 제공합니다. 도메인 내에서 이름을 바꾸거나 이동해도 아무런 효과가 없지만 SID를 삭제하고 다시 만들면 SID는 계정 수명 동안 사용자의 은유와 일치합니다.

이를 위해, 내가 전화 할 LookupAccountName사용자 이름을 나타내는 문자열을 사용하고를 반환, sAMAccountNameSID사용자가 발견 된 도메인과 도메인 이름을.

그런 다음 사용자는 Windows에서 지원하는 구문을 사용하여 로그인 할 수 있으며 추가 교육이 필요하지 않습니다.


LookupAccountName은 UPN 또는 sAMAccountName 또는 정규화 된 DOMAIN \ sAMAccountName 또는 위의 모든 항목을 허용합니까? 링크 한 설명서에서 명확하지 않습니다.
dunxd

문서 목록이 지원하는 형식 : DOMAIN\Account, DOMAIN.COM\Account, Account, Account@DOMAIN.COM. 정규화 된 이름은 더 빠르지 만 다른 이름은 여전히 ​​사용 가능합니다.
Mitch

0

사용자가 사용하려는 이름의 형식을 선택하고 응용 프로그램 측에서 사용자의 입력을 결정하도록 허용하는 것이 좋습니다. 예 : 사용자 이름 : username@domain.com-UPN으로 간주하고 AD에서 UPN을 검색하십시오. 사용자가 다음을 입력하는 경우 : username-사전 정의 된 기본 도메인의 경우 samAccountName으로, 물론 domain \ username을 입력하는 경우 지정된 도메인의 samAccountName으로 간주하십시오. 사람들이 결혼하고 사용자 이름이 변경 될 수 있으므로 항상 사용자의 SID를 검색하고 SID에 모든 권한을 할당하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.