DOMAIN \ username과 username@domain.local의 차이점은 무엇입니까?


46

모호한 인증 오류를 해결하려고하는데 배경 정보가 필요합니다.

  • Windows (및 Outlook과 같은 프로그램)의 처리 방법 DOMAIN\username과 차이점은 username@domain.local무엇입니까?

  • 이 두 사용자 이름 형식에 대한 적절한 용어는 무엇입니까?

  • 편집 : 특히 Windows가 두 사용자 이름 형식을 인증하는 방법에 차이가 있습니까?


이전 질문 중 하나에 관심이있을 수 있습니다 .
벨민 페르난데스

답변:


38

Active Directory 환경이 있다고 가정합니다.

백 슬래시 형식 DOMAIN \ USERNAME은 (는) SAM 계정 이름이 USERNAME 인 사용자 개체에 대해 도메인 DOMAIN을 검색 할 것이라고 생각합니다.

UPN 형식 username @ domain은 사용자 원칙 이름이 username @ domain 인 사용자 개체를 포리스트에서 검색합니다.

이제, 일반적으로 두 형식이 완벽하게 작동 광고를 제공 적어도 동일한 계정을 찾을해야하므로 USERNAME의 SAM 계정 이름을 가진 사용자 계정은 DOMAIN @ USERNAME의 UPN이있다. 복제 문제가 있거나 글로벌 카탈로그에 도달 할 수없는 경우 UPN 형식이 실패하는 경우 백 슬래시 형식이 작동 할 수 있습니다. 예를 들어 대상 도메인에 대해 도메인 컨트롤러에 도달 할 수없는 경우 반대가 적용되는 (비정상적인) 조건이있을 수도 있습니다.

그러나 사용자 이름 구성 요소가 SAM 계정 이름과 다르고 도메인 구성 요소가 도메인 이름과 다른 UPN을 갖도록 사용자 계정을 명시 적으로 구성 할 수도 있습니다.

Active Directory 사용자 및 컴퓨터의 계정 탭에는 "사용자 로그온 이름"이라는 제목 아래에 UPN이 표시되고 "사용자 로그온 이름 (Windows 2000 이전)"제목에는 SAM 계정 이름이 표시됩니다. 따라서 특정 사용자와 문제가있는 경우이 두 값 사이에 불일치가 없는지 확인합니다.

참고 : 위에서 설명한 검색에서 사용자 계정을 찾지 못하면 추가 검색이 수행 될 수 있습니다. 예를 들어, 지정된 사용자 이름이 다른 형식 (명확한 방법으로)으로 변환되어 일치하는지 여부를 확인할 수 있습니다. 포리스트에없는 신뢰할 수있는 도메인에서 계정을 찾는 절차도 있어야합니다. 정확한 행동이 어디에 / 언급되어 있는지 잘 모르겠습니다.

문제 해결을 더욱 복잡하게하기 위해 Windows 클라이언트는 기본적으로 성공적인 대화 형 로그온에 대한 정보를 캐시하므로 Active Directory의 사용자 계정 정보에 액세스 할 수없는 경우에도 동일한 클라이언트에 로그인 할 수 있습니다.


1
나는이 대답이 내 것보다 낫다. 잘 했어요
Ryan Ries

ldapsearch를 사용하여 AD를 쿼리하는 경우 msDS-PrincipalName 특성에서 하위 수준의 로그인 이름을 찾을 수 있습니다.이 이름은 "작동 특성"이므로 명시 적으로 요청해야합니다.
Eric

22

나는 이것을 고칠 수 있지만 실제로 큰 차이는 없습니다.

Domain \ User는 "오래된"로그온 형식으로, 하위 수준 로그온 이름 이라고 합니다 . SAMAccountNameWindows 2000 이전의 로그온 이름 이라고도합니다 .

User@Domain.com은 UPN- 사용자 이름 입니다. "바람직한"최신 로그온 형식입니다. 인터넷 스타일의 로그인 이름으로 사용자 이메일 이름에 매핑되어야합니다. ( MSDN 참조 )

UPN으로 로그인하는 이유는 대부분 외관상으로 회사의 사용자에게 회사 전자 메일 주소로도 사용할 수있는 워크 스테이션에 로그온 할 수있는 단일 이름을 부여하는 것입니다.

편집 : 더 정교함-UPN의 또 다른 장점은 사용자가 로그온 할 수있는 하나 이상의 유효한 UPN을 설정할 수 있다는 것입니다. 다시, 대부분 화장품. 그러나 중요한 것은 모든 응용 프로그램이 UPN과 호환되는 것은 아니라는 점입니다.

편집 # 2 : 두 가지 약간 다른 검색 형식에 대한 Harry Johnston의 답변이 마음에 듭니다. 이해하는 것이 가장 중요하며 실제로 문제를 설명 할 수도 있습니다. :)


3
RFC 822에는 "ARPA 인터넷 문자 메시지 형식의 표준"인 UPN에 대한 언급이 없습니다. UPN은 연결된 컴퓨터 시스템의 도메인 (또는 "영역")에서 싱글 사인온 서비스 (SSO)를 제공하기 위해 Kerberos와 LDAP 정보를 함께 묶는 Active Directory "발명"입니다.
adaptor

아 죄송합니다. msdn.microsoft.com/en-us/library/windows/desktop/ 에서 정보를 얻었습니다. ... ... 올바른 정보를 찾으면 답변을 편집하겠습니다.
Ryan Ries

1
@adaptr RFC 822는 10 년 전에 폐기되었습니다. – rfc 2822 참조.
Jim B

@Ryan, Active Directory는 서로 다른 두 가지 형식으로 검색됩니다. 내 답변을 참조하십시오.
Harry Johnston

@JimB RFC822는 더 이상 사용되지 않습니다. RFC2822 및 현재 RFC 5322는 다수의 다른 메일 및 컨텐트 관련 RFC (시작 용 5353)와 함께이를 참조합니다.
적응자

1

슬래시 형식 ( DOMAIN\username)은 실제로 NetBIOS도메인의 DNS 이름 ( domain.mycompany.local)과 같습니다. 이름은 15 자로 제한되며, 점, 밑줄 등을 포함 할 수 없습니다
NetBIOS

이 페이지에 대한 자세한 내용은 다음과 같습니다.
* Jeff Schertz, 2012-08-20, Active Directory 명명 형식 이해 ( 여기에서 보관 )

위의 @ harry-johnston이 언급했듯이 실제로 이전 NT4 및 Windows 2000 호환 형식이지만 좋아하는 형식으로 붙어있는 것 같습니다 (입력하기가 쉽지 않습니다!). 결국 레거시 형식에 대한 지원은 Windows에서 시작될 수 있습니다.

UPN 형식을 사용하는 습관을들이는 것이 좋습니다. 사용자 이름으로 PC에 로그인하는 데 문제가 있고 Windows 로그인 상자가 로컬로 기본 설정되어 있음을 알지 못하기 때문입니다. PC 도메인 (예 :) pc01\fred또는 다른 원격 데스크톱 호스트에 연결할 때 원격 데스크톱 클라이언트가 이전에 사용한 다른 도메인 이름을 캐시 할 수 있으므로 도메인 및 사용자 이름을 포함해야합니다. 매번 UPN 형식을 고수하면 결국 지원 요청이 줄어 듭니다.


"이전 형식"은 AD 환경이 아닌 환경에서 여전히 사용되고 있기 때문에 사라질 것 같지 않습니다. ( Host\username물론 AD가없는 도메인은 없습니다)
MSalters

-1

이 두 사람 사이에는 99 %의 사용자 만이 아무런 문제가 없을 것입니다. 차이점과 그러한 문제가 발생할 수있는시기를 설명하려고합니다.

파일 공유에 액세스하려고 할 때 domain \ username을 사용하면 DNS는 먼저 도메인을 확인한 다음 사용자 이름을 확인합니다. username @ domain을 사용하면 사용자가 ACL (액세스 제어 목록)에 있고 액세스 권한이 있는지 직접 확인합니다. 그래서 당신이 생각할 수있는 것은 무엇입니까?

이름이 DC01 인 도메인 컨트롤러 1 개와 모든 클라이언트가 DNS를 받고이 도메인에 있습니다. 마이그레이션하려고하고 누군가 같은 이름의 다른 서버를 추가했습니다. 후자의 서버도 DC가되므로 로컬 SAM은 더 이상 사용되지 않으며 파일 공유도 갖습니다.

사용자가 서버에 연결하면 자격 증명을 입력하라는 메시지가 표시됩니다. domain \ username을 사용하는 경우 먼저 새 도메인을 사용하는 대신 현재 도메인을 확인하고 파일 공유에서 새 도메인의 계정을 사용했습니다. 따라서 현재 dc를 발견하고 사용자 이름을 확인하면 찾을 수 없습니다. (사용자 이름과 비밀번호가 발견되어 정확히 동일하더라도 사용자 이름을 사용하여 ACL에서 허용되는지 확인하지는 않지만 SID를 사용하므로 SID가 사용되므로 작동하지 않습니다. AD의 사용자 생성 시간과 1 조의 1 조로 동일하고 훌륭합니다 .-P).


-1. 나는 당신이 여기서 말하는 것을 정말로 따라갈 수 없습니다. "사용자가 서버에 연결하는시기"라고 말한 곳은 어느 서버, 이전 DC01 또는 새 DC01입니까? 어쨌든 이전 DC01은 어떻게 되었습니까? 도메인에서 제거, 이름 변경, 제거 되었습니까? 먼저 제대로 강등 되었습니까? 새 도메인 생성을 설명하지 않았기 때문에 "새 도메인"이란 무엇을 의미합니까? "도메인 \ 사용자 이름"을 사용하는 경우 항상 명시 적으로 지정한 도메인을 검색 해야 합니다. 그렇지 않은 경우를 설명하고 있습니까?
Harry Johnston

또한 "사용자 이름을 사용하여 ACL에서 허용되는지 확인하지만 SID를 사용할 것"은 예상되는 동작입니다. domain \ username 또는 username @ domain을 사용하는지 여부에 관계없이 항상 그렇게해야합니다. 같은 이름을 가진 두 개의 도메인이 있거나 비슷한 병리가있는 경우에 대해 이야기하고 있습니까?
Harry Johnston

DNS는 먼저 도메인을 확인한 다음 사용자 이름을 확인합니다 . DNS가 사용자 이름을 확인합니까? 뭐?
bahrep 2016 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.