로컬 도메인의 이름입니다. Active Directory 도메인의 이름을 올바르게 지정하세요.

어제 우리 스튜디오는 단골 독자인 Andrey로부터 다음과 같은 질문이 담긴 편지를 받았습니다.

귀하의 블로그를 읽는 것이 즐겁고 나 자신에게 유용한 정보를 많이 배웠으며 Active Directory 도메인 이름에 대한 귀하의 의견을 알고 싶었습니다. 많은 사람들이 *organization*.local이라고 불러야 한다고 썼고 누군가는 도메인 이름을 불러야 한다고 썼습니다. 도메인과 동일합니다.

조직 내에서 도메인 이름을 지정할 때 사용하기에 가장 좋은 이름이 무엇인지 간단히 살펴보겠습니다.

실습에서 알 수 있듯이 도메인 이름을 선택하면 경험이 풍부한 사람이라도 혼란스러울 수 있습니다. 시스템 관리자. 유틸리티를 처음 시작하는 경우 dc프로모도메인 이름은 자동으로 무작위로 생성됩니다. 이 단계에서 도메인 이름이 이미 필요한 규칙에 부합하지 않으면 향후 도메인 이름을 변경하기가 더 어려워집니다. 인기순으로 옵션을 살펴 보겠습니다.

1. example.local이라는 도메인

우리 히트 퍼레이드의 리더는 다음으로 끝나는 도메인 이름입니다. 현지의.이 주제에는 다른 변형이 있습니다. 예를 들어 시험, 회사, 공장, nn, 위치, 등등. 이제 당신은 당신의 모든 책에서 그러한 사랑이 어디서 왔는지조차 기억하지 못합니다 마이크로소프트 회사항상 자신만의 종류 이름을 사용합니다. contoso.com우리가 확실히 볼 수 있는 곳 도메인 명명 형식. 그러나 거의 10년 동안 도메인은 .현지의선두 자리를 차지했습니다. 업무에 사용되는 서비스의 출현으로 상황은 안정되기 시작했습니다. SSL 인증서. "상관하지 않으므로 그렇게 될 것"인 도메인의 사용이 불가능해지는 경우. 회사가 내부적으로 사용한다고 가정해 보세요. Exchange 서버, 클라이언트 연결을 암호화하려면 SSL 인증서가 필요합니다. 시나리오에 따르면 이 작업을 수행하려면 인증서가 필요합니다. 외부 CA, 여기에 사용되는 서버의 모든 이름을 지정해야 합니다. 외부 연결. 그런 것 같은데, 서버 이름을 다 적어서 인증서 발급을 신청하는 것 같은데, 한 가지가 있습니다. 해당 도메인 이름으로 당신은 확인할 수 없습니다, "상관하지 않으므로 그렇게 될 것"이라는 도메인이 존재하지 않고 존재하지 않는 도메인의 FQDN 이름을 SAN에 입력해야 한다고 외부 인증 기관에 설명하려고 하면 소프트 거부를 받게 됩니다. :

불가능합니다. 실제 도메인 이름에 대한 인증서만 발급합니다.

그런데 문제가 하나 더 있습니다. 도메인 이름 사용 당신의 소유가 아닙니다도메인 이름을 사용하면 재앙적인 결과를 초래할 수 있습니다. 영역이 다음과 같은 경우 상황을 상상해보십시오. 현지의공개됩니다. 영역처럼 com또는 ko. 계속할 가치가 없다고 생각합니다.

2. 도메인 이름이 외부 도메인 이름과 동일합니다.

우리 히트 퍼레이드의 두 번째 장소입니다. 그러한 시나리오는 덜 인기가 있다는 사실에도 불구하고 여전히 생명권을 가지고 있습니다. 가까운 시일 내에 네트워크를 유지할 때 여전히 불편을 겪게 될 것이라는 사실 외에도 다른 어떤 것도 귀하를 위협하지 않습니다. 이 시나리오의 주요 문제는 두 개의 DNS 서버를 유지해야 한다는 것입니다. 내부와 외부. 이 조건에서 네트워크 내부의 컴퓨터는 이름 확인을 위해 내부 DNS 서버를 사용하고 회사 경계 외부의 컴퓨터는 외부 DNS 서버를 사용합니다. 귀하의 도메인에 자랑스러운 이름이 있다고 가정해 보세요. example.com. 안에 DMZ당신이 가지고 있는 영역 웹사이트이름이 붙은 회사 example.com. 위에서 설명한 시나리오에서 다음 위치에 있는 컴퓨터는 내부에조직 캔트 example.com이 있기 때문에 액세스하세요. 도메인 이름브라우저에 이 주소를 입력하면 다음으로 이동합니다. 도메인 컨트롤러. 위에서 언급했듯이 불편을 제외하고는 아무 것도 발생하지 않습니다. 언제든지 외부 사이트로 리디렉션되는 목발을 사용할 수 있지만 이것이 반드시 필요한 이중 작업은 아니라는 데 동의하거나 다음으로 시작하는 사이트 이름을 사용합니다. www아니면 밖에서.

3. 한 단어로 된 도메인 이름

아마도 위에서 가장 잘못된 옵션 일 것입니다. 단일 수준 도메인: 단일 라벨 도메인다음을 포함하는 도메인입니다. 하나의 구성 요소. 분명히 그들은 Microsoft가 Novell의 성공적인 경험을 채택한 NT 시대에 사용되기 시작했습니다. 처음에 나는 FreeBSD와 버전 4.11부터 시작하는 대규모 NetWare 서버의 관리자였으며 고대에는 NetWare가 작업에 Bindery를 사용했습니다. 단일 수준 도메인 스키마, 나중에 Microsoft가 인수했습니다.

모범 사례

이제 요약할 차례입니다. 어떤 도메인 이름을 사용할 것인가? 소유한 도메인의 세 번째 수준 도메인만. 다른 사람의 더 아름다운 도메인 이름을 사용하지 마세요 :-). 아래에서 이러한 도메인의 예를 볼 수 있습니다.

드문 경우지만 도메인 서비스 관리자가 현재 도메인의 이름을 바꾸는 작업에 직면할 수 있습니다. 이유는 다를 수 있지만 이러한 상황은 매우 가능합니다. 이 작업을 사소하다고 할 수는 없지만 때때로 처리해야 하는 경우가 있음에도 불구하고 모든 것을 올바르게 수행하는 것이 매우 중요합니다. 그렇지 않으면 이벤트의 결과가 완전히 작동하지 않는 기업 인프라까지 매우 위험할 수 있기 때문입니다. 따라서 이 문서의 뒷부분에서는 이 작업을 수행하기 위한 전제 조건, 일부 제한 사항, 도메인 이름을 바꾸는 방법에 대해 알아봅니다. 시작하기 전에 랩 환경에서 테스트 도메인 이름을 성공적으로 변경할 때까지 프로덕션 환경에서 이러한 단계를 수행하지 마시기 바랍니다. 시작하자.

전제조건

도메인 이름 변경을 시작하기 전에 다음 정보를 고려해야 합니다.

• Active Directory 포리스트 기능 수준. 포리스트의 모든 도메인에 최소한 하나의 운영 체제가 설치된 경우에만 도메인 이름 변경 작업을 수행할 수 있습니다. 윈도우 서버 2003(이 경우 에디션에는 제한이 없습니다). 또한 기능 수준을 최소한 Windows Server 2003 수준 이상으로 올려야 하는데, 즉 포리스트에서 Windows Server 2000 기능 수준을 선택했다면 다음 작업이 아예 불가능해집니다.
• 도메인 위치. Active Directory 포리스트에는 다양한 수준의 도메인이 있을 수 있습니다. 즉, 단일 도메인이 있을 수도 있고 포리스트에 하위 도메인이 포함될 수도 있습니다. 포리스트 내에서 도메인 컨트롤러의 위치를 ​​변경하는 경우 신뢰 관계를 만들어야 합니다.
• DNS 영역. 도메인 이름 변경 작업을 수행하기 전에도 새 DNS 영역을 생성해야 합니다.
• 관리 자격 증명. 도메인 이름 변경 작업을 수행하려면 Enterprise Admins 그룹의 구성원인 관리 계정으로 로그온해야 합니다.
• 분산 파일 시스템(DFS) 서버. 기업 환경에 DFS가 배포되었거나 로밍 프로필이 구성되어 있는 경우 DFS 루트 서버는 최소한 Windows Server 2000 서비스 팩 3 이상의 운영 체제를 실행해야 합니다.
• Microsoft Exchange Server와의 비호환성. 가장 짜증나는 점은 Microsoft Exchange Server 2003 서비스 팩 1 메일 서버가 Active Directory 포리스트에 배포된 경우 도메인 이름 변경은 문제 없이 완료되지만 도메인 이름 변경 프로세스를 수행할 사용자 계정은 다음과 같습니다. 전체 Exchange 관리자 그룹의 구성원이어야 합니다. 점점 더 현대적인 메일 서버(Exchange Server 2016 포함)은 도메인 이름 변경 작업과 호환되지 않습니다.

또한 도메인 이름을 바꾸는 동안 보류 중인 모든 Active Directory 포리스트 구성 작업을 중지해야 합니다. 즉, 도메인 이름 변경 작업이 완전히 완료될 때까지 포리스트 구성이 변경되지 않도록 해야 합니다( 자세한 정보자세한 방법은 아래를 참조하세요.) 이러한 작업에는 Active Directory 포리스트 내에서 도메인 생성 또는 제거, 응용 프로그램 디렉터리 파티션 생성 또는 제거, 포리스트에서 도메인 컨트롤러 추가 또는 제거, 직접 설정된 신뢰 생성 또는 제거, 전역 데이터베이스에 복제될 특성 추가 또는 제거가 포함됩니다. 목록.

만약을 대비해 Active Directory 포리스트의 각 도메인 컨트롤러에 전체 시스템 상태 백업을 만드는 것이 좋습니다. 이 작업이 완료되면 이 예방 조치는 결코 불필요한 것이 아닙니다.

귀하의 인프라가 위의 요구 사항과 필요한 모든 사항을 충족하는 경우 백업, 도메인 이름 변경 프로세스를 진행할 수 있습니다.

Active Directory 도메인 이름 변경 프로세스

우선 도메인의 원래 이름을 확인하려면 시스템 속성 창을 열 수 있습니다. 해당 그림에서 볼 수 있듯이 내 도메인 이름은 "Biopharmaceutic.local"입니다.

쌀. 1. 원래 Active Directory 도메인 이름 확인

이제 도메인 이름 변경이 성공적으로 완료된 후 구성원 서버와 클라이언트가 새 도메인 이름에 쉽게 가입할 수 있도록 새 DNS 영역 "biopharm.local"을 만들어야 합니다. 이렇게 하려면 다음을 엽니다. DNS 관리자» ( DNS 관리자) 그리고 " 정방향 조회 영역» ( 정방향 조회 영역) 새 영역을 생성하는 옵션을 선택합니다. 기본적으로 영역은 평소와 같이 생성됩니다. 새 영역 마법사의 첫 번째 페이지에서 소개 정보를 읽고 두 번째 페이지로 진행합니다. 영역 유형 페이지에서 기본 영역( 기본 영역) 영역을 Active Directory에 저장하는 옵션이 활성화되어 있는지 확인하세요. 영역 복제 범위 페이지에서 기본적으로 선택된 옵션인 "을 그대로 둡니다. 이 도메인의 도메인 컨트롤러에서 실행되는 모든 DNS 서버의 경우: Biopharmaceutic.local» ( 이 도메인의 도메인 컨트롤러에서 실행되는 모든 DNS 서버: Biopharmaceutic.local). 영역 이름 페이지에서 새 도메인 이름(biopharm.local)을 지정해야 하며 동적 업데이트 페이지에서도 " 보안된 동적 업데이트만 허용(Active Directory에 권장)» ( 보안된 동적 업데이트만 허용(Active Directory에 권장))가 기본적으로 선택되어 있습니다. 아래에서 새 영역을 생성하는 여러 단계를 볼 수 있습니다.

쌀. 2. 새로운 DNS 영역 생성

도메인 이름 변경의 다음 단계는 포리스트의 현재 상태에 대한 설명을 생성하는 것입니다. 실제로 이는 유틸리티가 사용되는 첫 번째 도메인 이름 변경 작업입니다. 명령줄 렌덤. 이 유틸리티는 현재 포리스트 구조에 대한 텍스트 설명을 Domainlist.xml이라는 XML 파일로 생성합니다. 이 파일에는 Active Directory 포리스트에 있는 응용 프로그램 디렉터리 파티션뿐만 아니라 모든 도메인 디렉터리 파티션의 목록이 포함되어 있습니다. 각 도메인 및 응용 프로그램 디렉터리 파티션의 각 항목은 XML 태그로 구분됩니다. 그리고. 또한 각 항목에는 파티션 루트 개체의 GUID(Globally Unique Object Identifier), 도메인 또는 응용 프로그램 디렉터리의 DNS 이름, 도메인의 NetBIOS 이름이 포함된 데이터가 포함되어 있습니다.

이러한 파일을 생성하려면 해당 계정에서 명령 프롬프트를 열고 " 무작위/목록". 생성된 파일은 루트 디렉터리에 저장됩니다. 계정당신의 사용자. 다음으로 텍스트 편집기를 사용하여 이 파일을 열어야 합니다.

이 파일 내에서 태그로 구분된 섹션 내의 도메인 이름을 변경해야 합니다. 그리고태그 안의 NetBIOS 이름 그리고). 해당 태그 내부의 GUID를 변경하면 안 된다는 점에 유의하세요.

다음 그림에서는 위 명령을 실행하는 프로세스, Domainlist.xml 파일의 위치, 이 파일의 첫 번째 섹션에 대한 변경 사항을 보여줍니다. 제 경우에는 이 구성의 도메인 이름이 4번 변경됩니다.

쌀. 3. Domainlist.xml 파일 생성 및 수정

해당 파일에 필요한 변경 사항을 적용했는지 확인하려면 " 무작위 /showforest". 다음 그림에서 볼 수 있듯이 내 모든 항목이 "Bopharm"으로 변경되었습니다.

쌀. 4. 잠재적인 변화 보기

다음 명령을 실행할 때 ( 무작위 /업로드), Rendom 유틸리티는 편집된 파일에 지정된 새 포리스트 구조를 포리스트의 모든 도메인 컨트롤러에서 로컬 및 원격으로 실행되는 일련의 카탈로그 업데이트 지침으로 변환합니다. 일반적으로 이 단계에서는 도메인 명명 마법사의 구성 디렉터리 섹션을 변경하여 Active Directory 도메인 이름을 바꿉니다. 또한 도메인 이름 변경 작업을 위해 포리스트에 있는 각 도메인 컨트롤러의 진행 상황과 상태를 추적하는 데 사용되는 Dclist.xml 파일이 생성됩니다. 또한 이 시점에서 Rendom 유틸리티는 Active Directory 포리스트가 해당 구성을 변경하지 못하도록 고정합니다. 이 명령을 실행하는 과정은 다음과 같습니다.

쌀. 5. rendom /upload 명령 실행

도메인 이름 변경 작업 전에 도메인 컨트롤러의 준비 상태를 확인하기 위해 다음 명령이 실행됩니다. 이 단계에서는 준비 검사 명령을 실행해야 합니다. 포리스트의 모든 도메인 컨트롤러. 이는 포리스트의 각 도메인 컨트롤러에 있는 Active Directory 데이터베이스가 올바른 상태에 있고 도메인 이름을 바꿀 수 있도록 변경할 준비가 되어 있는지 확인하기 위한 것입니다. 따라서 " 무작위 / 준비"는 다음 그림에서와 같이 수행됩니다.

쌀. 6. 이름 변경을 위한 도메인 준비

가장 중요한 순간. "명령 실행 중 무작위/실행". 도메인에서 이 명령을 실행하면 도메인 이름을 바꾸는 지침이 실행됩니다. 기본적으로 바로 이 순간 포리스트의 각 도메인 컨트롤러가 개별적으로 연결되므로 각 도메인 컨트롤러가 도메인 이름을 바꾸라는 명령을 실행하게 됩니다. 이 작업이 완료되면 각 도메인 컨트롤러가 재부팅됩니다. 도메인 이름을 바꾸는 프로세스는 다음 그림을 참조하세요.

쌀. 7. 도메인 이름 변경 프로세스

그러나 그것이 전부는 아닙니다. 실제로 도메인 이름이 이미 변경되었더라도 도메인 이름 변경 작업이 완료된 후에도 GPO와 해당 참조를 수정해야 합니다. 명령줄 유틸리티는 이름이 변경된 각 도메인에서 GPO 및 GPO 링크를 복원하는 데 사용됩니다. gpfixup.exe. 이 절차가 없으면 새 포리스트에서 도메인 이름 변경 작업이 완료된 후 그룹 정책난 그냥 제대로 작동하지 않을 것입니다. 이 명령은 이름이 변경된 각 도메인에서 한 번씩 실행되어야 합니다. 따라서 명령을 한 번 실행하십시오. gpfixup매개변수 포함 /olddns:바이오의약품.local(이름을 바꾼 도메인의 이전 이름) 및 /newdns:Biopharm.local(이름이 변경된 도메인의 새 이름) 다음 명령 gpfixup매개변수 포함 /oldnb:바이오의약품그리고 /newnb:바이오팜(각각 도메인의 이전 및 새 NETBIOS 이름) 이 절차는 아래와 같습니다.

쌀. 8. GPO 수정

실행할 명령은 두 개만 남았습니다. " 랜덤 / 클린"를 사용하면 Active Directory 내의 이전 도메인 이름에 대한 모든 참조와 " 무작위 /끝” 실제로 Active Directory 포리스트의 구성 변경을 방지하는 것입니다. 다음 그림에서 이러한 명령을 실행하는 프로세스를 볼 수 있습니다.

쌀. 9. Active Directory 도메인 이름 변경 완료

구성원 서버와 최종 클라이언트에 변경 사항을 적용하려면 해당 컴퓨터를 두 번 다시 시작해야 합니다. 그러나 도메인 컨트롤러의 이름을 수동으로 바꿔야 합니다. 다음 그림에서 볼 수 있듯이 내 도메인 컨트롤러 이름은 여전히 ​​동일합니다.

2015년은 인터넷이 널리 보급되고 모든 자존심이 강한 회사는 오랫동안 자체 웹 사이트를 가지고 있습니다. 멀리 갈 필요가 없습니다. 모든 시립 병원에도 자체 웹 리소스가 있습니다. 그럼에도 불구하고 시스템 관리자는 도메인에 대한 일반적인 이름을 만드는 방법을 배우지 못했습니다.

2단계 도메인(예: bissquit.com)의 비용은 연간 500루블이 조금 넘습니다. 이는 여러분이나 나 같은 일반 시민에게도 아주 작은 금액이고, 기업에게는 더욱이 한 푼에 불과합니다. 나는 이 블로그를 시작하겠다는 아이디어가 나타나기 오래 전에 도메인을 구입했습니다. 그냥 편리해요. rdp를 통해 원격 연결도 해보겠습니다. 지루한 IP 주소 대신 내 도메인 이름을 입력합니다.

인터넷에서는 "Active Directory 도메인 모범 사례" 요청에 따라 거의 모든 사이트에서 AD 도메인 이름 지정에 대한 포괄적인 권장 사항을 작성하고 이것이 수행되어야 하는 이유를 설명했습니다. 우리가 말하는 권장 사항을 자세히 살펴 보겠습니다.

• AD 도메인 이름을 지정하려면 조직에 공식적으로 등록된 도메인의 하위 도메인을 사용하세요.

조언이 딱 하나 있습니다. 이게 다야! 세부 사항과 작은 뉘앙스에 대해 많이 이야기할 수 있지만 추론의 80~90%는 위에 언급된 하나의 조언으로 귀결됩니다. 모든 문제는 사람이 이 작업을 수행해야 한다는 것을 알고 있지만 이것이 불가능한 이유를 이해하지 못하거나 다르게 수행하지 않는 것이 좋습니다. 자세한 내용은 지금부터.

1. .local, .corp, .lan과 같이 내부 및 외부에서 확인할 수 없는 이름을 사용할 수 없는 이유는 무엇입니까?

할 수 있다. 가능한 한 더 많이. 대부분은 그것을 사용합니다. 조직에 2000명 이상의 사람이 있고 .local 도메인을 사용하는 친구의 예가 있습니다. 갑자기 실제 AD 도메인이 필요하면 모든 어려움이 시작됩니다. 이는 하이브리드 클라우드 배포를 사용할 때 발생할 수 있습니다(Exchange + Office365가 대표적인 예입니다). "특정 AD 버전에서는 가능하기 때문에 도메인 이름을 바꾸는 것이 어떨까요?" - 물어. 예, 원칙적으로는 가능하지만 도메인 종속 서비스를 마이그레이션하는 데 어려움을 겪어야 합니다. 그중에는 동일한 Exchange와 다른 Exchange가 있지만 여기서는 하나의 Exchange로 충분합니다.

2. "좋아, 우리는 실제 외부 이름인 my-company.com을 구입합니다. AD 도메인도 호출하겠습니다." 역시 옵션이 아닙니다. 회사 웹사이트 등 my-company.com에 있는 다른 리소스에 권한 문제가 있을 수 있습니다. 게다가 귀하의 DNS 서버는 자신을 그렇게 간주하더라도 이 도메인에 대해 권한을 부여하지 않습니다. 이로 인해 문제가 발생할 수도 있습니다.

도메인 이름 지정에 대한 다른 고려 사항이 있습니다. 그중에는 유사한 실제 도메인을 다른 TLD에 생성하는 것이 포함됩니다. 그러나 일부 문제가 여전히 남아 있고 corp.my-company.com 도메인을 사용하는 것에 비해 뚜렷한 이점이 없기 때문에 이 작업을 수행하는 데 큰 의미가 없는 것 같습니다(이름은 예로 사용됨). ).

모든 것을 자신의 방식으로 처리하려는 사람들을 위해 최근에는 인증서 문제도 추가되므로 이제 내부 이름을 사용할 필요가 없습니다.

도메인 이름 선택 문제는 기술적으로 AD 도메인을 생성할 때 이름을 쓰는 줄에 달려 있으며 그 이상은 아닙니다. 그러나 잘못된 이름 선택으로 인해 발생하는 결과는 향후 많은 문제를 일으킬 수 있으므로 계획 단계에서 모든 것을 고품질로 수행하는 것이 매우 중요합니다. 다시한번 숙련된 관리자의 글을 읽어보는 것이 좋습니다

도메인 컨트롤러란 무엇입니까?

도메인 컨트롤러는 중앙 집중식 관리를 제공합니다. 네트워크 장치, 즉 도메인입니다. 컨트롤러는 네트워크 사용자의 계정 및 설정의 모든 정보를 저장합니다. 여기에는 보안 설정, 로컬 정책 등이 있습니다. 이는 특정 네트워크나 네트워크 그룹에 대한 모든 권한을 갖는 일종의 서버입니다. 도메인 컨트롤러는 다양한 Active Directory 서비스를 실행하는 일종의 특수 소프트웨어 집합입니다. 컨트롤러는 Windows Server 2003과 같은 특정 운영 체제를 실행합니다. 액티브 드라이브 설정 마법사를 사용하면 도메인 컨트롤러를 생성할 수 있습니다.

안에 운영 체제윈도우 NT 같은 메인 서버, 기본 도메인 컨트롤러가 사용됩니다. 사용 중인 다른 서버는 백업 컨트롤러로 사용됩니다. 기본 PDC 컨트롤러는 사용자 그룹 구성원 자격, 암호 생성 및 변경, 사용자 추가 등과 관련된 다양한 작업을 수행할 수 있습니다. 그 후 데이터는 추가 BDC 컨트롤러로 전송됩니다.

도메인 컨트롤러로 사용 가능 소프트웨어 Unix 운영 체제가 설치된 경우 Samba 4. 이 소프트웨어는 Windows 2003, 2008, 2003 R2 및 2008 R2와 같은 다른 운영 체제도 지원합니다. 필요한 경우 각 운영 체제는 특정 요구 사항 및 매개변수에 따라 확장될 수 있습니다.

도메인 컨트롤러 적용

도메인 컨트롤러는 서로 연결되거나 네트워크에 연결된 컴퓨터를 호스팅하는 많은 조직에서 사용됩니다. 컨트롤러는 디렉터리 데이터를 저장하고 사용자가 로그인, 로그아웃하고 서로 상호 작용하는 방법을 제어합니다.

도메인 컨트롤러를 사용하는 조직은 사용할 개수를 결정하고 데이터 보관 계획을 세워야 합니다. 물리적 보안, 서버 업데이트 및 기타 필요한 작업.

회사나 조직의 규모가 작고 하나의 도메인 네트워크만 사용하는 경우 높은 안정성, 내결함성 및 성능을 제공할 수 있는 컨트롤러 두 개만 사용하면 충분합니다. 높은 레벨네트워크 가용성. 특정 수의 사이트로 나누어진 네트워크에는 각 사이트마다 하나의 컨트롤러가 설치되어 필요한 성능과 안정성을 얻을 수 있습니다. 각 사이트의 컨트롤러를 사용하면 사용자 로그인이 훨씬 쉽고 빨라질 수 있습니다.

네트워크 트래픽을 최적화할 수 있습니다. 이를 위해서는 네트워크 부하가 최소화될 때 복제 업데이트 시간을 설정해야 합니다. 복제를 설정하면 작업이 크게 단순화되고 생산성이 높아집니다.

성취하다 최대 성능컨트롤러 작업에서 도메인이 글로벌 카탈로그인 경우 특정 가중치로 모든 개체를 요청할 수 있습니다. 그러나 글로벌 카탈로그를 활성화하면 복제 트래픽이 크게 증가한다는 점을 기억하는 것이 중요합니다.

둘 이상의 도메인 컨트롤러가 사용되는 경우 호스트 도메인 컨트롤러를 활성화하지 않은 상태로 두는 것이 가장 좋습니다. 도메인 컨트롤러를 사용할 때는 속임수에 필요한 데이터를 점유하려는 공격자가 쉽게 접근할 수 있기 때문에 보안에 주의하는 것이 매우 중요합니다.

추가 도메인 컨트롤러 설치 시 고려 사항

필요한 네트워크 서비스 운영의 안정성을 높이려면 추가 도메인 컨트롤러를 설치해야 합니다. 결과적으로 훨씬 더 높은 안정성, 신뢰성 및 작동 안전성을 달성할 수 있습니다. 이 경우 네트워크 성능은 훨씬 더 높아질 것이며 이는 도메인 컨트롤러를 사용하는 조직에 매우 중요한 매개 변수입니다.

도메인 컨트롤러가 올바르게 작동하려면 몇 가지 준비 작업을 수행해야 합니다. 가장 먼저 해야 할 일은 TCP/IP 설정을 확인하는 것입니다. TCP/IP 설정이 서버에 맞게 올바르게 설정되어 있어야 합니다. 가장 중요한 것은 매핑을 위해 DNS 이름을 확인하는 것입니다.

도메인 컨트롤러가 안전하게 작동하려면 FAT 32 파일 시스템보다 더 높은 보안을 제공하는 NTFS 파일 시스템을 사용해야 합니다. 서버에 설치하려면 파티션 하나를 생성해야 합니다. 파일 시스템시스템 볼륨이 위치할 NTFS입니다. 서버에서 DNS 서버에 액세스하는 것도 필요합니다. DNS 서비스는 리소스 레코드를 지원해야 하는 이 서버 또는 추가 서버에 설치됩니다.

도메인 컨트롤러를 적절하게 구성하려면 특정 역할의 실행을 추가할 수 있는 구성 마법사를 사용할 수 있습니다. 이렇게 하려면 제어판을 통해 관리 섹션으로 이동해야 합니다. 도메인 컨트롤러를 서버 역할로 지정해야 합니다.

오늘날 도메인 컨트롤러는 인간 활동의 모든 영역에서 다양한 조직, 기관 및 회사가 사용하는 네트워크 및 사이트에 없어서는 안 될 요소입니다. 그 덕분에 높은 작업 생산성과 안전이 보장됩니다. 컴퓨터 네트워크특히 중요합니다. 도메인 컨트롤러의 역할은 컴퓨터 네트워크에 구축된 도메인 영역을 관리할 수 있기 때문에 매우 중요합니다. 각 운영 체제에는 도메인 컨트롤러 작동과 관련된 특정 뉘앙스가 있지만 원칙과 목적은 모든 곳에서 동일하므로 설정을 다루는 것이 처음에 보이는 것처럼 어렵지 않습니다. 그러나 궁극적으로 운영 중 높은 성능과 보안을 달성하려면 전문가가 도메인 컨트롤러를 구성하는 것이 매우 중요합니다.

봄이 왔고, 이와 함께 당연해 보이지만 동시에 디자인에 있어 중요한 질문에 답하는 기본 자료를 탄생시키려는 욕구가 높아졌습니다. Active Directory 도메인에 어떤 이름을 붙여야 손상되지 않는지 나중에 엄청나게?

이 기사에서는 최악의 Active Directory 도메인 이름 옵션부터 제가 생각하기에 가장 좋다고 생각되는 도메인 이름 옵션까지 안내해 드리겠습니다. 최선의 선택, 극복해야 할 갈퀴를 지적하는 길을 따라.

단일 라벨 이름을 가진 도메인은 다음에서 사용할 수 없습니다. 생산적인 환경, 유일한 올바른 방법은 가능한 한 빨리 제거하는 것입니다.

도메인 이름에 잘못된 문자가 있습니다.

예를 들어 밑줄이 있습니다. 비록 이전 버전 Windows Server에서는 DNS 도메인 이름을 선택할 때 이 문자가 허용되었지만 DNS에 대한 RFC 1123 표준을 준수하지 않습니다. 새로운 윈도우 버전서버는 더 이상 표준에 반하여 도메인 이름을 지정할 수 없습니다. 이름에 밑줄이 포함된 도메인을 상속받은 경우 큰 문제가 예상됩니다. 예를 들어 Exchange 2007 이상은 설치할 수 없습니다. 해결책은 하나뿐입니다. 다른 도메인으로 마이그레이션하거나(권장) 도메인 이름을 변경하여(안전하지 않음) 도메인 이름에서 유효하지 않은 문자를 제거하는 것입니다.

분리된 네임스페이스

Disjoint 네임스페이스의 특별한 경우 중 하나는 도메인의 Netbios 이름이 도메인 DNS 이름의 가장 왼쪽 부분과 다른 경우입니다.

넷바이오스 이름 = TEST
DNS 이름 = lab.site

기능면에서 이 구성은 완벽하게 지원됩니다. 그러나 혼란과 모호함을 초래하지 않도록 피하는 것이 좋습니다.

.local 또는 ICANN

많은 튜토리얼에서 company.local과 같은 도메인 이름을 볼 수 있습니다. 실제로 교육 및 테스트 목적으로 이러한 이름을 사용하는 것은 범죄가 아닙니다. 동일한 체계에 따라 실제 도메인을 호출하면 상황이 더 나빠집니다.

• 이름은 글로벌 DNS의 이념에 어긋납니다. 다른 유사한 도메인과의 충돌이 없음을 보장하지 않습니다(신뢰 관계를 구축해야 할 때).
• 글로벌 네트워크에서 액세스하기 위해 이 이름을 사용할 수 없습니다(게시 시점)
• 소유권을 확인할 수 없는 도메인은 공개 SSL 인증서로 획득할 수 없습니다. 이 제한은 특히 개발과 관련이 있습니다. 클라우드 서비스온프레미스 서비스와 클라우드 서비스 간의 경계가 모호해지는 경우 예: Office 365 서비스의 Single Sign On에는 공용 인증서가 있는 AD 페더레이션 서비스가 필요합니다.

따라서 도메인 이름을 지정할 때 항상 ICANN(Internet Corporation for Assigned Names and Numbers) 계층 구조에 공식적으로 등록된 글로벌 이름을 사용하는 것이 좋습니다. 이렇게 하면 위에서 설명한 단점이 제거됩니다.

웹사이트
argon.com.ru
irom.info

선택 또는 결합

site 에 웹사이트가 있고 동일한 도메인의 이메일 주소도 사용하는 Argon의 도메인 구조를 설계한다고 가정해 보겠습니다. 그러나 다음과 같은 이유로 이 작업을 수행하지 않는 것이 좋습니다.

• 브라우저에 이러한 조직의 네트워크 내부에 http: // site / 주소를 입력하면 회사 웹 사이트로 이동하지 않고 처음으로 발견되는 도메인 컨트롤러로 이동합니다.
• 공용 및 내부 DNS 레코드 관리는 어렵습니다. 내부 네트워크에서 사용되는 사이트 영역의 모든 공용 DNS 레코드는 내부 DNS 영역에 복제되어야 합니다. 또한 이러한 기록의 동기화를 어떻게든 보장해야 합니다.

예를 들어, 인터넷에는 www.site라는 사이트가 있습니다. 내부 네트워크의 사용자가 접근하려면 내부 DNS 영역에 유사한 레코드를 생성해야 합니다.

• 내부 리소스 이름과 외부 리소스 이름이 충돌할 가능성이 있습니다.

예를 들어 ftp.site 서버는 내부 네트워크에서 널리 사용됩니다. 갑자기 인터넷 사용자에게 동일한 주소 ftp.site에서 파일 서비스를 제공해야 할 필요성이 생겼습니다. 무슨 일이에요? 내부 사용자는 지정된 이름으로 외부 서비스에 연결할 수 없습니다.

따라서 Active Directory 도메인은 인터넷(회사 홈페이지 등)의 네임스페이스와는 다른 전용 네임스페이스(네임스페이스)를 갖는 것이 좋습니다. 그리고 여기에도 선택이 있습니다:

• AD에는 완전히 다른 이름을 사용합니다(사이트에는 사이트, AD에는 argon.com.ru).
• AD에 하위 이름 사용(사이트에는 사이트, AD에는 lab.site)

두 옵션 모두 DNS 이념을 충족하며 위에 나열된 단점이 없지만, 하위 도메인을 사용하는 두 번째 옵션은 다음과 같은 측면에서 더 편리할 수 있습니다.

• 등록된 도메인 이름 지원(단 하나의 도메인에 대한 등록 및 DNS 호스팅 비용 지불)
• 등록을 위한 아름다운 이름 사용 가능(등록할 필요 없음)
• 공개 SSL 인증서 획득(회사 웹사이트 및 내부 네트워크 리소스 게시 시 하나의 와일드카드 인증서만 사용할 수 있음)

그래서 저는 AD 전용 도메인을 선택하되 조직 웹사이트의 하위 도메인을 선택하도록 제안합니다.

연구실 사이트
corp.microsoft.com

분할 두뇌

분할 브레인 DNS는 하나의 도메인 이름을 사용하여 내부 네트워크와 인터넷 모두에 리소스를 게시하는 것을 의미합니다. 동시에 내부 네트워크의 DNS 서버는 Portal.lab.site와 같은 주소를 내부 IP 주소로 확인하고, 인터넷의 공용 DNS 서버를 각각 외부 IP로 확인합니다. 예:

분할 브레인으로 인해 내부 네트워크와 인터넷 모두에서 리소스에 액세스하기 위한 균일한 주소와 같은 유용한 기능이 달성됩니다. 사용자가 자신의 문서에 액세스할 수 있는 하나의 주소 Portal.lab.site 만 아는 것으로 충분하며 회사 사무실이나 호텔 등 어디에 있는지는 중요하지 않습니다.

인프라 관점에서 볼 때 내부 CA에서 발급한 SSL 인증서의 CRL 또는 OCSP에 대해 동일한 주소를 갖는 것이 편리합니다.

분할 브레인이 없으면 내부에 소위 핀포인트 영역을 만들어야 할 수도 있습니다. DNS 서버, 이러한 "점선" 영역에는 "공개" 값을 내부 네트워크와 관련된 "개인" 값으로 대체해야 하는 레코드만 포함됩니다(상황은 " 제목 아래에 설명된 것과 유사합니다. 선택 또는 결합')을 참조하세요.

핀포인트 영역의 예:

명확화 또는 요약

문헌에서는 Bank , Company 또는 Corp 와 같은 일반화된 단어를 사용하여 도메인(특히 루트 도메인) 이름을 지정하는 방법에 대한 조언을 찾을 수 있습니다. 여기에는 이유가 있습니다. 우리 시대에는 기업들이 인수합병, 브랜드 변화를 정기적으로 경험할 수 있기 때문입니다. 아시다시피 도메인 이름은 변경하기가 매우 어렵습니다.

반면에 동일한 회사 인수 및 합병으로 인해 사용자가 한 도메인에서 다른 도메인으로 마이그레이션될 가능성이 매우 높습니다. 실제로 Bank라는 이름을 가진 12개의 도메인에서 사용자를 마이그레이션해야 하는 상황에 직면했습니다. 아시다시피, 동일한 이름을 가진 도메인(DNS 또는 Netbios) 간에 신뢰 관계를 설정하는 것은 불가능합니다. 이러한 도메인의 이름을 바꾸거나 세 번째 도메인을 통해 두 단계에 걸쳐 데이터를 마이그레이션해야 합니다.

저는 도메인 이름을 구체적으로 지정하고 회사 이름을 바꾼 후 이전 이름을 유지하는 것이 마이그레이션하거나 신뢰 관계를 구축해야 하는 경우 일반적으로 이름을 지정하고 심각한 기술 문제가 발생하는 것보다 낫다는 생각에 기울고 있습니다.

우수성을 향한 여정의 마무리

• 전 세계적으로 등록됨
• 전용(회사 웹사이트 도메인의 하위)
• 특정한
• 분할 브레인을 사용하다

연구실 사이트
corp.microsoft.com

그러나 Lync의 전자 메일 및 SIP 주소의 경우 더 짧은 user@site 주소를 사용하는 것이 더 좋습니다. 우리가 이 일을 하는 것을 막을 수 있는 것은 없지만 불편을 겪을 것입니다.

사용자의 이메일 주소 = user@website , 로그인 로그인 = lab\user , 사용자 계정 이름 = [email protected] . 사용자뿐만 아니라 Outlook 및 Lync와 같은 프로그램에서도 혼동되기 쉽습니다.

사소한 계정 수정 후에 사용자는 이메일 주소와 동일한 사용자 계정 이름을 갖게 됩니다. 혼란이 줄어들고 Lync 및 Outlook과 같은 프로그램에서 사용자 로그인 요구가 중단되므로 전자 메일이나 SIP 주소만 알면 충분합니다.

내 기본 작품:

기타 자료에 관한 기사:

• Active Directory 도메인 명명 고려 사항 - 여기에 Microsoft의 건전한 가이드가 제공됩니다.
• 컴퓨터, 도메인, 사이트 및 OU에 대한 Active Directory의 명명 규칙 - 하위 섹션 참조 인터넷으로 연결된 숲
• Active Directory 도메인 이름에 .local을 사용하면 안되는 이유 - 외국 동료의 유사한 기사