바라건대 , 우리 모두 는 Active Directory 포리스트의 이름을 지정하기위한 권장 사항 이 무엇인지 알고 있으며 매우 간단합니다. 즉, 한 문장으로 요약 될 수 있습니다.
등록 된 기존 도메인 이름의 하위 도메인을 사용하고 외부에서 사용하지 않을 도메인 이름을 선택하십시오. 나는 통합과 등록했다 예를 들어, hopelessn00b.com도메인 내 내부 AD 숲은 이름을 지정해야 internal.hopelessn00b.com하거나 ad.hopelessn00b.com또는 corp.hopelessn00b.com.
“가짜”tlds 또는 단일 레이블 도메인 이름을 사용하지 않아야 하는 압도적으로 매력적인 이유가 있지만 루트 도메인 ( hopelessn00b.com)을 도메인 이름으로 사용 corp.hopelessn00b.com하지 않고 대신 같은 하위 도메인을 사용하는 비슷한 이유를 찾는 데 어려움을 겪고 있습니다. . 실제로 내가 찾을 수있는 유일한 정당화는 내부에서 외부 웹 사이트에 액세스하려면 A nameDNS 레코드 가 필요 www.하고 브라우저에서 웹 사이트 이름 앞에 입력 해야한다는 것입니다. 문제가있는 한 꽤 “meh”입니다.
그래서, 내가 무엇을 놓치고 있습니까? ad.hopelessn00b.comActive Directory 포리스트 이름 으로 사용하는 것이 왜 훨씬 더 낫 hopelessn00b.com습니까?
단지 기록을 위해, 정말로 설득력이 필요한 것은 나의 고용주입니다. 사장님은 뒤돌아 가고 있습니다. 그리고 corp.hopelessn00b'semployer.com내부 네트워크 용으로 명명 된 새로운 AD 포리스트를 만들기 위해 계속 진행 한 후 , 그는 hopelessn00b'semployer.com( 외부 등록 도메인과 동일). 나는 최선의 방법이 더 나은 선택이라는 설득력있는 이유 또는 이유를 얻을 수 있기를 바라고 있습니다. 그래서 그를 설득 할 수 있습니다 … 적어도 직장을 구하거나 새 직장을 찾는 것이 더 쉬운 것처럼 보이기 때문입니다. 순간. 지금, “Microsoft의 모범 사례”내부적으로 우리 회사의 공개 웹 사이트에 접속을하지 않는 것은 절단 될, 그리고 난 정말 , 정말 , 정말 여기 누군가가 뭔가 더 설득력이있다 희망.
답변
너무 많은 담당자가 있습니다. 귀중하게 오십시오.
좋아, Microsoft에 의해 잘 문서화되어 있으므로 여러 번 연결했을 때 split-horizon 또는 구성된 TLD를 사용해서는 안됩니다 (내 블로그에 외침!). 여기에는 몇 가지 이유가 있습니다.
-
www위에서 지적한 것이 문제. 성가 시지만 거래 차단기는 아닙니다. -
뿐만 아니라 내부적으로 액세스 할 수있는 모든 공용 서버에 대해 중복 레코드를 유지 관리해야합니다
www.mail.hopelessnoob.com일반적인 예입니다. 이상적인 시나리오에서는mail.hopelessnoob.com또는 과 같은 것을위한 별도의 경계 네트워크가publicwebservice.hopelessnoob.com있습니다. 내부 및 외부 인터페이스가있는 ASA와 같은 일부 구성의 경우 어쨌든 내부 NAT 또는 분할 수평 DNS가 필요 하지만 웹 연결 리소스가 머리핀 NAT 경계 뒤에 있지 않은 합법적 인 주변 네트워크가있는 대규모 조직의 경우- 이로 인해 불필요한 작업이 발생합니다. -
이 시나리오를 상상해보십시오
hopelessnoob.com. 내부 및 외부에 있습니다. 당신은 당신과 파트너 관계를 맺고있는 회사를 가지고example.com있으며 그들은 AD와 공개적으로 접근 할 수있는 DNS 네임 스페이스와 내부적으로 수평을 나눕니다. 이제 사이트 간 VPN을 구성하고 인터넷을 통해 외부 공용 리소스에 액세스하면서 터널을 통과하는 트러스트에 대한 내부 인증을 원합니다. 믿을 수 없을 정도로 복잡한 정책 라우팅없이 또는 자체 내부 DNS 영역 사본을 보유하지 않으면 불가능한 일이되었습니다. 이제 유지 관리 할 추가 DNS 레코드 세트를 만들었습니다. 그래서 당신은 당신의 끝에 헤어핀을 처리 하고끝, 정책 라우팅 / NAT 및 기타 모든 종류의 속임수. (실제로 내가 상속 한 AD 로이 상황에 처해있었습니다). -
DirectAccess를 배포 한 경우 이름 확인 정책이 대폭 간소화됩니다. 이는 다른 스플릿 터널 VPN 기술에서도 마찬가지입니다.
이 중 일부는 엣지 케이스이고 일부는 그렇지 않지만 모두 쉽게 피할 수 있습니다 . 처음부터이 작업을 수행 할 수있는 능력이 있다면 올바른 방법으로 10 년 안에 이러한 문제 중 하나에 빠지지 않도록하십시오.
답변
이 문장 : “실제로, 내부에서 외부 웹 사이트에 액세스하려면 SRV DNS 레코드가 필요하고 브라우저에서 웹 사이트 이름 앞에 www.를 입력해야한다는 것이 정당화되지 않습니다.”
즉, 모든 공개 레코드의 사본을 AD DNS 서버에 보관해야합니다. 이는 특히 제대로 수행하지 않을 경우 문제가 발생할 수 있습니다. 일부는 놓치게됩니다. 누군가 ftp.company에 접속하려는 경우. com하지만 내부 DNS에서 별칭을 만드는 것을 잊었거나 제대로 자동화하지 않은 경우 사내 사람들이 공용 FTP 사이트를 전혀 방문 할 수 없습니다.
이것은 Windows Active Directory 명명 모범 사례?
DNS 영역의 여러 복사본을 유지 관리하는 것이 영원히 쉽게 해결하기 쉬운 문제라면 원하는 것을 할 수 있다고 생각합니다. MS가 그것을 깨뜨리는 것을 바꿀 때까지. 당신 은 그들의 권장 사항을 따를 수 있습니다.
답변
오늘 긴 답변을 만드는 담당자에 대해서는별로 신경 쓰지 않습니다. 그래서 짧게 유지하겠습니다.
나는 split-dns를 잘 사용했고 Evan과 Mark가 다르게 설득 할 때까지 여러 번 구현했습니다. 솔직히 말해서 할 수는 없으며, 할 수 있고, 일부는 괜찮을 수도 있습니다 (오버 헤드와 작업에도 불구하고).
몇 년 전에 나에게 그것을 사용하지 않는 것을 확고히 한 구체적인 것들이 나왔습니다.
- 질문에서 지적한 것처럼 내부 사용자가 도메인 이름을 통해서만 외부 웹 사이트를 방문하도록 허용 할 수 없습니다. 왜 그렇게 큰 문제인지 묻지 않지만
www도메인 레코드는 AD 도메인과 일치하기 때문에 실제 웹 사이트를 표시하지 않고 도메인 이름 만 브라우저에 입력하면 브라우저에 도메인 이름을 입력한다는 것을 알 수있는 내부 사용자가 있습니다. 에 취득하기위한 포괄하지www내부적 할 수 없습니다. - Exchange 문제-Exchange 자동 검색에서 인증서를 가져 오지 못할 수 있으며 오류가 표시됩니다. 내부 및 외부에서 발생할 수 있습니다. Exchange 조직에서 “외부 포리스트 사서함”을 시작했을 때 더욱 분명해졌으며 기존 DNS와 동일한 내부 DNS를 보지 못했습니다.
희망이 도움이됩니다.
