AD 도메인 이름을 수정하는 대신 UPN을 추가하는 데 단점이 있습니까?


9

불행히도 회사 이름이 아닌 DNS 이름 인 Active Directory 도메인을 상속했습니다. 우리는 ABC.com이라고합니다. 대신 company.com 아래에있는 것이기를 원합니다 ( AD 이름 지정에 대한 MDMarra의 답변에 따르면 다른 용도로 사용하는 DNS 이름을 사용하고 싶지 않기 때문에 ad.company.com을 사용했을 것입니다). 이제 올해는 디렉토리 동기화를 사용하여 전자 메일을 Office 365로 이동할 수 있습니다. 이를 위해서는 최소한 이메일 도메인 (company.com)과 일치하는 UPN이 필요합니다. 좋아, 두 번째 UPN을 추가하는 과정은 충분히 간단 해 보인다 . 원하는 UPN에 올 때까지 테스트하고 계정을 옮기는 것이 합리적입니다.

이 작업을 수행하는 데 단점이 있습니까? ABC.com이라는 '비 소유'도메인 이름을 무기한으로 유지하면 기술 부채 잔인 사신이 결국 도착합니까?

참고로 2012R2 수준의 모든 도메인 (포리스트, 기능 수준, 모든 DC)과이 도메인의 Exchange 2010이 포함 된 단일 포리스트, 단일 도메인이 있습니다. AD에는 약 150 명의 사용자와 450 대의 컴퓨터가 있습니다 (많은 개발 / 테스트 자동화). 2003 년부터 2012R2까지 우리를 안전하게 안내했지만 AD의 전문가라고 결코 말하지는 않습니다.

도메인 이름 변경이 일반적으로 권장되는 것처럼 보이지 않으며 도메인에 Exchange 2010이 있기 때문에 옵션이라고 생각하지 않습니다.

내가 알기로, 나는 다음 중 하나를 할 수 있었다.

  • 두 번째 UPN을 추가하고 완료하십시오. UPN을 생성 / 추가 할 때 수동으로 UPN을 설정해야하는 문제를 해결할 수 있습니다.
  • 두 번째 도메인을 포리스트에 추가하고 모든 것을 옮기고 항상 제거 할 수없는이 레거시 루트 도메인을 갖습니다.
  • 두 번째 포리스트 인 포리스트 <-> 포리스트 트러스트를 만들고 새 포리스트에서 처음부터 원하는대로 모든 것을 수행합니다. 모든 것을 이동하고 결국 원래 포리스트를 제거합니다. 실제로 느리게, 신중하게, 앞뒤로 테스트했으며, 아마도 최소한의 시간 동안 큰 비용을 썼을 것입니다. 꿈의 세계에서 이것이 가장 좋은 것처럼 보이지만, 나는 누군가가 저승 사자 도착이 언급되지 않는 한 이것에 대한 비즈니스 사례를 정당화 할 수 있는지 확실하지 않습니다.
  • ??? 내가 생각하지 못한 다른 것

1
일반적으로 이러한 유형의 질문은 이것이 "모범 사례"질문
일뿐

1
손가락이 엇갈리게-우리는 라우팅 할 수없는 도메인을 가진 유일한 사람이거나 통제 할 수없는 사람이 될 수는 없습니다 ... 또한이 상황의 부정적인 측면에 대한 몇 가지 사실 (단지 의견이 아닌)이 있어야합니다 ...
Joshua McKinnon

1
Will the technical debt grim reaper eventually arrive if we stay on this 'non-owned' domain name of ABC.com indefinitely?-결국은 추가 UPN을 생성한다고해서 AD FQDN이 잘못되었다는 사실을 해결할 수는 없습니다. UPN은 사용자가 로그인하는 데 사용할 수있는 "대체"사용자 이름 일뿐입니다. 실제 AD FQDN과는 아무런 관련이 없습니다. Office 365 로의 이전이 문제가 될 것입니다. 특히 내부적으로 사용중인 이름을 "소유"하지 않고 다른 조직과 "속한다"는 것을 알 수 있습니다.
joeqwerty

O365, 페더레이션 또는 외부 SSO의 모래에 오랫동안 선을 그어 우리가 잘못된 AD FQDN에 대해 우리가하는 일을 전제로 정렬했습니다. 물론 다른 두통이 있습니다 ... 계획을 골라야 할 것 같습니다. 나는 그것이 재미있을 것이라고 기대하지 않습니다. 메모 @joeqwerty 주셔서 감사합니다. 내가 시간을 거슬러 여행을하고 그 사람이 회사가 통제하지 않은 이름을 선택하는 것을 막을 수 있다면 ...
Joshua McKinnon

네. 도전적인 일입니다. 경험에는 좋지만, 의심 할 여지없이 생성 될 스트레스에는 그리 좋지 않습니다. 행운을 빕니다.
joeqwerty

답변:


8

따라서 내부적으로 사용하지 않는 도메인을 소유하지 않는 것에 대한 실재적 위기 – Office 365 관점에서 이것은 괜찮습니다. Office 365는 AD 도메인이 아니라 사용중인 전자 메일 도메인을 확인합니다. 따라서 UPN을 사용자의 전자 메일 주소와 일치하도록 변경하여 취한 접근 방식은 적절하고 정확합니다.

이제는 순수한 AD 관점에서 볼 때 내부 DNS 도메인을 소유하지 않기 때문에 해당 내부 DNS 도메인에 대한 타사 인증서를 얻을 수 없습니다. 이것은 당신에게 문제가 될 수도 있고 아닐 수도 있습니다. 또한 동일한 이름을 공유하는 다른 도메인과 신뢰를 가질 수 없으므로 해당 도메인을 소유 한 회사와 합병하고 해당 이름을 사용하는 회사와 합병하는 경우 마이그레이션 악몽이 발생할 수 있습니다. 나는 이것이 확률이 0에 가깝다고 상상할 것이다.

그것은의 많은 이름을 바꾸거나 도메인 밖으로 이전 할 최종 사용자에게 잠재적으로 매우 파괴적인 작업을합니다. 이 시점에서, 나는 일반적으로 그 중 하나의 사례가 당신을 아프게하지 않으면 단지 이름이 잘못된 도메인을 떠나야한다고 생각합니다.


동일한 도메인을 가진 타사의 타사 인증서 및 취득이 주요 문제인 경우, 나는 이미 # 1에 익숙하고 # 2 가능성은 0에 가깝습니다. 관련된 작업량을 정당화하는 데 가까이 가지 마십시오. Azure의 도메인 가입 WSUS와 같은 것은 구성하기가 다소 번거롭지 만 외부 액세스가 필요한 대부분의 항목은 어쨌든 사용하려는 실제 DNS 이름으로 인증서를 활용합니다. 나는 이미 그 두통에 익숙하다. 내가 이름을 딴 도메인은이 길로 내려 가지 않을 것입니다.
Joshua McKinnon

@JoshuaMcKinnon 그래-(알다시피) 나는 AD의 이름을 올바르게 지정하는 십자군이지만 현실적으로 그것을 해결하기 위해 포리스트 간 마이그레이션을 수행하는 것은 가장 작은 환경을 제외한 모든 사람에게 부당한 부담입니다. 그것은 우리가 대부분의 경우에 살아야 할 것들 중 하나 일뿐입니다.
MDMarra

그래-당신에게서 이것을 듣는 것이 안심입니다. 이 경우 현명한 일은 그것과 함께 사는 것입니다. :) 나는 하루나 이틀을주고 마크를 받아 들일 것이다.
Joshua McKinnon
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.