Active Directory 이름 전략

[  출처 : http://blog.naver.com/reddangun/120019414499  ]

Active Directory 이름 전략

DNS 이름영역(namespace)의 이해

DNS 이름영역이란?

이름영역(namespace)이라고 하는 것은 이름을 IP 주소로 풀이(resolve)하는 데 이용되는 레코드를 가지고 있는 데이터의 저장 영역을 말한다. DNS는 분산 이름영역으로서 Internet에서 컴퓨터자원의 이름을 이에 상응하는 TCP/IP주소로 풀이하는 데 사용된다.

예를 들면 www.icmarket.co.kr을 210.124. 9.2로 풀이하는 것을 말한다.

DNS domains

DNS 는 domain이라는 블록으로 이루어져 있다. 마치 NTFS의 디렉토리가 다른 디렉토리를 서브 디렉토리로 포함하는 방식으로 되어 있다.

다른 domain을 포함하는 domain을 parent domain이라고 한다. DNS tree의 맨 상위 층을 root domain이라고 하며 이에 대한 parent domain은 존재 하지 않는다.

다른 domain에 포함되는 domain을 child domain 혹은subdomain이라고 부른다. DNS를 구축한다는 것은 이 parent domain 을 몇 개 만들고 이에 따른 child domain을 몇 개 둘 것인가를 결정하는 일이다.

Child domain에서 parent domain이름으로는 각기 점(.)으로 분리되는 계층 구조로 구분되는 데, sales.icmarket.co.kr은 하나의 sales domain으로서 icmarket.co.kr domain의 subdomain으로서 FQDN(Fully Qualified Domain Name)이다.

여기서 server1.sales.icmarket.co.kr은 sales.icmarket.co.kr내의 한 object 이다.

DNS 가이드라인

domain 이름영역(namespace)을 만들 때는 다음과 같은 사항을 염두에 둔다.

관리상의 편의를 위해 domain 레벨에 한정을 둔다. 최대 3 개에서 5 개 사이의 레벨이면 대부분의 조직에서 충분하다.

Parent domain내의 각 child domain의 이름은 고유하게 만들어야 한다.

Domain 이름은 점(.)을 포함하여 최대 63자 임으로 되도록 이면 짧게 해야 한다.

DNS에 사용할 수 있는 글자는 RFC 1034, 1035에 규정되어 있듯이 A~Z, a~z, 0~9그리고 하이푼(-)을 사용할 수 있으며 영어 이외의 언어를 사용하는 환경에서는Unicode도 사용할 수 있다.

 

 

Root Domain 명명하기

이름영역(namespace)에서 제일 처음 오는 domain을 root domain이라고 한다. 이 root domain은 그 밑에 오는 모든 child domain의 이름영역의 후미에 붙는다.

이 root domain의 이름을 결정하기 전에 다음 사항들을 확인한다.

쉽게 인식할 수 있는 이름을 결정한다. 조직을 대표하거나 암시할 수 있는 이름이라야 한다.

선택한 이름이 법적으로 문제가 없는지를 확인해야 한다.

domain레벨이 여러 층에 같은 이름이 사용되지 않도록 해야 한다.

Internet 내, 외부로 서로 다른 이름영역을 사용할 경우에는 외부 이름에서 파생되어 나온 이름을 내부용으로 사용하는 것이 좋다.

DNS Root 이름의 등록

일단 Internet에 등록되어진 이름에 대해서는 등록 회사만 사용할 수 있기 때문에 Internet에 접속할 네트워크 인 경우에는 반드시 필요한 경우이다. 이는 InterNIC을 통해서 하는 데, com, edu, org나 net의 경우에 일정한 관리 비용을 지불하고 www.internic.net을 통해서 등록한다.

　

내, 외부용으로 서로 다른 root domain이름을 사용할 경우

Internet에 공개하는 자원과 공개하지 않은 내부 자원을 분리하는 방법 중에 하나가 DNS namespace를 내, 외부용으로 각기 다르게 가져가는 방법이 있다. 내부 이름 영역(namespace)은 Internet으로 부터 방화벽으로 보호가 되며 서고 각기 다른 DNS database file 과 FQDN(Fully Qualified Domain Name)을 가지기 때문에 서로 쉽게 구별된다.

내, 외부용으로 각기 다른 root domain namespace를 가져가게 되면 다음과 같은 장점이 있다.

관리와 보안문제에 관하여 내, 외부자원에 관하여 확연한 구분을 둘 수 있다.
내, 외부의 자원이 중첩되지 않기 때문에 관리가 쉽다.
내부 클라이언트의 브라우저 설정이 용이하다.
프락시 클라이언트의 설정이 용이하다.
단점은 내, 외부용의 두 개의 이름을 등록해야 한다는 것이다.

 

내, 외부용으로 동일한 Root Name을 가져갈 경우

내, 외부용으로 root domain name이 동일할 경우에는 방화벽 내부의 클라이언트에게는 방화벽 내, 외부로 액세스할 수 있도록 하고 방화벽 외부의 클라이언트는 방화벽 내부의 자원에는 액세스 할 수 없도록 설정해야 한다.

그림에서 보다시피 이 경우에도 icmarket.com라는 DNS database file을 내, 외부용으로 2 개 이용하는 데, 외부의 DNS database file은 방화벽 바깥에 있는 Web 서버나 FTP 서버와 email 서버 등과 같은 자원에 대한 이름 풀이를 제공하며, 방화벽 내부에 있는DNSS database file은 내부 사용자 만이 이용하는 자원들에 대한 이름 풀이를 담당하는 것이다.

내부 사용자들은 방화벽 내부에 외부 Internet 서버의 미러(mirrored)서버를 내부에 둠으로써 이를 통하여 외부 자원을 액세스 할 수 있으며, 각 클라이언트에는 icmarket.com로 끝나는 이름에 대해서는 내부 자원으로 인식할 수 있도록 프락시 클라이언트 소프트웨어를 설정하여야 한다.

동일한 root name 을 사용하게 되면 다음과 같은 번잡한 일이 수반된다.

까다로운 프락시 설정 문제가 따른다.

컨텐트 담당자와 네트워크 관리자는 내, 외부 자료에 대한 확실한 구분을 할 수 있어야 한다.

내, 외부 이름이 동일하기 때문에 관리상의 혼란이 야기 될 수 있다.

사용자들은 자원의 브라우저 할 때, 내, 외부에 따라 완전해 틀리게 보일 수 있다는 것을 이해 해야 한다.

DNS zone의 이해

domain 과 host 에 대한 정보를 담고 있는 것이 DNS zone이다. Zone을 잘 설계하여야만 이를 관리하거나 복제하는 것을 간단하게 처리할 수 있다.

DNS Zone은 이를 유지관리 하고 위임하는 데 사용하는 몇 개의 파일로 구성되어 있다. 하나의 Zone은 단일 domain이나 몇 개의 subdomain 으로 가진 하나의 domain으로 구성되며, 하나의 DNS 서버는 하나 이상의 zone파일을 관리 할 수 있도록 설정할 수 있다.

각 zone은 그 zone의 root domain 으로 명시되는 특정 domain을 나타내며, domain과 host 에 관련된 정보는 resource records로 명시하는 몇 개의 파일로 구성되어 있다. 그리고 이 resource records는 이름 풀이에 사용된다.

DNS에서 domain과 zone의 커다란 차이점은, 하나의 domain 과 여기에 포함되는 각 노드들은 하나의 단일 노드로 간주되며, 하나의 zone은 특정 name server를 대표되는 resource records의 모음으로 간주된다. 특히 domain은 이름영역을 논리적이고 계층적으로 구성하는 것에 비해 zone은 그 이름과 resource data들이 어떻게 name server로 분산되고 name server로 지정되는 하는 가에 대한 것이다.

다음은 대부분의 DNS 구축에 이용되는 zone file에 대한 설명이다.

Zone.dns: host name을 IP 주소로 매핑한다. domain 이름이 icmarket.com 일 경우에 이 파일의 이름은 db.icmarket.com으로 된다.
z.y.w.x.inaddr.arpa: IP 주소를 host name으로 매핑한다. 네트워크 주소가 C 클래스 이면서 210.124.9.0일 경우에는 이 파일은 db.210.124.9.0가 된다.
Cache.dns: 이는 root domain을 관리하는 name server의 이름과 주소를 나타낸다.
　

 

Zone type과 Direction의 이해

DNS zone에는 그 타입별로, standard primary와 standard secondary 그리고 Active Directory integrated로 나눌 수 있으며 이는 각기 master zone, replica zone 을 만들며, Master zone은 Active Directory와 통합된다.

다음은 각 zone type에 관한 설명이다.

Standard primary: 새로운 zone의 마스터 카피이다. 이는 표준 text파일에 저장되며, 이에 대한 업데이트는 직접 이루어 진다.
Standard secondary: 기존의 zone에 대한 복제본이다. 이는 read-only이기 때문에 이를 직접 업데이트 할 수는 없다. Primary zone의 설정을 통하여 secondary zone을 만든다. 이 secondary zone을 만들 때에 관리자는 zone정보를 transfer할 DNS서버를 명시해야 하며, 이를 만들어 둠으로써 Primary zone name server의 부하를 덜어 줄 뿐 아니라 이중화를 이룰 수 있다.
Active Directory integrated: Active Directory를 이용해 저장되고 복제하는데 사용하는 새로운 zone의 마스터 카피이다. 직접 업데이트 된다.
Zone Direction은 forward lookup zone과 reverse lookup zone이 있다. 다음은 이들에 대한 요약이다.

Forward lookup zone 파일은 DNS이름을 IP 주조나 LDAP이름으로 풀이한다. 관리자는 반드시 하나 이상의 forward lookup zone을 설정해야 한다. 이는 www.icmarket.co.kr을 210.124.9.2로 풀이한다.
Reverse lookup zone 파일은 IP주소를 host name으로 풀이한다. 210.124.9.2를 www.icmarekt.co.kr로 풀이한다.
Resource Records에 대한 이해

Resource records란 domain이나 host에 관련된 정보를 가지고 있는 data entry이다. 이 resource record에는 여러 가지 종류가 있는 데, 이 중에 가장 빈번하게 사용하는 것이 바로 domain controller와 DNS서버를 찾아내기 위한 것이다.

다음은 각 Resource record의 타입에 관한 설명이다.

A : 이는 host를 나타낸다. Forward lookup zone을 위한 호스트 이름과 IP주소의 매핑이 나열되어 있다.
SRV : Service 를 나타낸다. 서비스를 제공하는 서버를 나타낸다. 이를 테면, 클라이언트가 로그온을 할 때 이를 인증할 서버를 찾아야 하는 데, 이 경우에는 DNS서버로 질의를 날려서 domain controller와 이의 IP 주소를 알아내는 것이다.
SOA : Start of authority를 나타낸다. 이는 domain내에서 어떤 서버가 domain에 관한 권한을 가지고 있는 name server인지를 나타낸다. 이는 새로운 zone이 만들어 지게 되면 자동으로 생성된다.
NS : Name Server를 나타낸다. 각 domain에 할당된 name server를 나타낸다. 이 NS 레코드도 새로운 zone이 만들어 질 때에 자동 생성된다.
PTR : Pointer이다. domain의 이름영역(namespace)에 다른 일 부분을 가르킨다.
CNAME : Canonical name을 나타낸다. 특정 host name에 대한 별칭을 만든다. 이를 테면 하나의 host name에 여러 개의 별칭을 줄 때에 사용한다. 동일 컴퓨터를 다른 이름으로 부를 때, 즉, www.icmarket.co.kr이나 ftp.icmarket.co.kr로 부를 때 사용하는 것이다.

Resource Records Fields

Resource Records에는 여러 field 가 있는 데, 이를 이용하여 이름을 풀이한다 던 지 아니면 resource records의 타입을 나타내고 낸다.

host (A) resource record를 예를 들어 보면,

<host name> IN A <IP address of host> 라고 명시되는 데, 여기서 host name은 호스트의 이름을 나타내고, <IP address of host>는 해당 호스트의 IP 주소를 나타낸다.

그러므로 Server1이라는 서버의 host record는 다음과 같다.

Server1 IN A 210.124.9.2

Service 에 관련된 SRV resource records는 이름 풀이와는 상관이 없으며 다음과 같은 포맷으로 기록된다.

<service>.<protocol>.<domain> IN SRV <priority><weight><prot><host>

각 필드의 설명은 다음과 같다.

<service>: 제공하는 서비스의 종류
<protocol>: 사용하는 프로토콜
<domain>: 서비스가 운용되는 domain
<priority>: 서비스가 해당 호스트에서 동작할 때에 주어지는 우선순위 이다. 낮을수록 우선 순위가 높다. 클라이언트는 맨 처음 제일 낮은 번호의 호스트에게 액세스한다. 범위는 0 부터 65,535이다.
<weight>: 우선순위 내에서 무게 서열을 말한다. 같은 우선순위를 가진 2 개의 서버가 있을 때에 이 weight에 따라 그 액세스를 결정한다. 이는 2 개 의 서버사이의 부하 분산을 위해 사용되는데, 이 값이 0 일 경우에는 load balancing이 필요 없음을 말한다. 이 값의 범위도 0 부터 65,535이다.
<port >: 서비스에 사용되는 IP 주소의 port를 말한다. 이것의 범위도 0 부터 65,535까지 이다.
<host>: 해당 서비스를 제공하는 서버의 호스트 이름을 나타낸다.
다음은 예를 참조 한다.

ldap.tcp.icmarket.co.kr IN SRV 0 0 389 Server1.icmarket.co.kr

Resource Records에 대한 규정은 RFC 1034, 2052,2065에 따른다.

 

 

DNS Zone과 Active Directory Domains의 관계

Microsoft DNS 서비스를 구축할 때에 관리자는 텍스트 파일 포맷으로 된 표준 DNS저장 방법을 사용하던지 아니면 해당 Zone 에 관한 정보를 Active Directory에 결합하는 방법을 사용할 수도 있다. Active Directory에 결합하는 방식을 사용하게 되면 이는 전체 네트워크의 domain controller에 복제되어 동기화 되어 사용된다.

Active Directory domain database에는 하나 이상의 DNS zone 이 저장 될 수 있으며, 모든 domain controller는 다른 Windows 2000서버가 보내는 DNS업데이트 요청을 전부 수용한다. 각 domain controller는 해당 Active Directory내의 DNS zone에 관련된 데이터를 업데이트 할 수 있게 된다. 각 domain의 database에 저장된 DNS zone object는 다른 domain controller로 replication을 통하여 복제된다.

다음은 DNS zone과 finance.icmarket.co.kr이라는 Windows NT domain 이 어떻게 상호 동작하는 것인지를 설명하고 있다.

domain에 해당하는 finance.icmarket.co.kr이라는 DNS zone을 만든다. domain controller가 있는 각 Site마다 최소 하나이상의 DNS 서버가 있어야 한다.
각 클라이언트를 zone내에 두어야 한다. 예를 들면 pc1.finance.icmarekt.co.kr 과 같은 것이다.
관리자가 DNS 서비스를 구축하는 이름영역 에 사용될 IP 주소의 범위를 결정한다. 이는 reverse lookup zone을 설정할 때에 사용된다.

Microsoft DNS Service

Microsoft사에서는 Windows 2000의DNS서비스를 강력히 추천하는데, 이 Windows 2000의 DNS서비스에는 다음과 같은 기능적 특징을 요약하면 다음과 같다.

Integration with Active Directory: DNS zone 파일이 Active Directory내에 저장된다.

SRV resource records: NT 4.0 service pack을 이용해서는 SRV record를 수동으로 입력할 수 있지만 Windows 2000에서는 Active Directory와 결합되어 있기 때문에 이를 자동으로 입력한다. 이는 RFC 2052 규정에 따른다.

Dynamic update: DDNS(Dynamic DNS)를 표준 프로토콜로 사용하기 때문에 각 호스트는 DNS database에 그 호스트 이름을 동적으로 등록하기 때문에 관리비용을 줄일 수 있다. 이 규정의 RFC 2136에 따른다.

Secure Dynamic update: RFC 2137에 규정되어 있는 데, 등록된 호스트 이름의 인증에 관한 것이다.

Incremental zone transfer: 서버간의 복제가 일어 날 때, 특히 보조(secondary) 서버가 주(primary)서버로부터 변경된 data를 다운로드할 때에 전체 database를 다운로드하는 것이 아니라 변경된 부분만 읽어 오는 zone transfer를 수행한다. 이는 RFC 1995에 규정되어 있다.

Support for the Unicode extended character set: ANSI 문자를 사용하지 않는 영어 이외의 언어를 사용하는 환경에서 유용하게 사용할 수 있다.

Interoperation with DHCP: DHCP서비스를 제공하는 서버가 zone에 각 IP를 부여하는 클라이언트의 이름을 DNS서버에 직접 등록을 대신하는 기능이다.

　

 

DNS 서버의 역할

DNS 서버는 DNS zone 타입에 따라 그 기능이나 역할이 몇 가지로 나누어 진다.

Primary Server: 각 zone에 대하여 DNS service에 대한 권한을 가지며 zone file의 마스터 복사본을 가지고 있다. zone에 대해 그 기능의 일 부분을 다른 서버에 위임한다거나 해당 zone에 호스트를 추가하는 작업들은 바로 이 Primary server에서 이루어 져야 한다.

Secondary Server: 이는 zone에 대한 권한을 가지고 있는 마스터 서버로부터 zone에 대한 데이터를 가져 온다. Secondary zone은 Active Directory에 저장되지 않기 때문에 zone database file을 업데이트 할 수 없다. 클라이언트가 이 secondary server로 dynamic update을 요구하게 되면, 이 secondary server는 이 요구를 primary server로 전송한다.

Master Server: Primary server나 Secondary server로서 해당 zone에 대한 정보를 제공한다. 이 secondary server는 zone 정보를 master server로 부터 가져오기 때문에 master server의 SOA records가 제대로 설정되어 있어야 secondary server가 zone정보에 대한 master server로 지정된다.

Caching-only server: 이는 primary server도 secondary server도 아니다. 그러므로 zone transfer traffic도 일어 나지 않으며, zone file도 저장하고 있지 않다. 주로 WAN 으로 원격지에 몇 대의 컴퓨터만 있을 경우에 Master server가 제공하는 정보를 캐쉬에 보관하고 있으면서 이에 대한 로컬 클라이언트에 요구에 응답하는 기능을 제공함 으로서 WAN구간 트래픽을 줄이는 기능을 주로 한다.

　

Zone Transfer의 이해

마스터 DNS서버가 부하 분산을 위하여 DNS record를 secondary server로 복제하는 것을 zone transfer라고 한다. 마스터 DNS서버는 이 기능을 수행하기 위해 별도로 설정하는 것이 없으나 secondary server는 어느 마스터 서버로부터 zone database file을 읽어 올 것인가를 명시해야 한다. DNS zone file을 여러 대의 서버로 복제함으로써 다음과 같은 장점을 가질 수 있다.

primary server에 기능장애가 생기더라도 다른 서버가 이를 대신하기 때문에 fault tolerant가 된다.
분 산되어 있는 서버간에 일어나는 DNS이름풀이에 관련한 네트워크 트래픽을 줄일 수 있다. 이는 특히 WAN구간에서 반드시 고려해야 하는 사항이다.
Primary master server에서 그 외의 서버로 DNS이름 풀이의 부하를 분산할 수가 있다.
이 복제 프로세스는 새 컴퓨터가 연결되거나, 노트북이 서브넷을 바꾸어 연결되거나, DHCP임대 기간이 만료되는 경우에는 항시 자동으로 일어나게 되어 있다. 그리고 primary master server가 이 업데이트를 수행할 수 있으며 표준 DNS 서비스는 single master replication이다. 모든 server가 Active Directory에 통합될 경우에는 각 zone에 대한 권한을 가진 서버가 이 업데이트를 전 네트워크에 Active Directory를 통하여 시작하는 데, 이 경우에는 multi-master replication방식이라고 부른다.

 

Zone Transfer에 대한 고려 사항

DNS 구축을 고려할 때에, zone transfer나 caching으로 일어 날 수 있는 네트워크 트래픽을 반드시 염두에 두어야 한다. 비록 WINS 서비스가 발생하는 트래픽 만큼은 심각하지 않지만 이를 구성할 때는 다음과 같은 사항을 고려해야 한다.

DNS lookup 과정은 서버와 클라이언트간에 많은 트래픽을 발생시킨다. 특히 느린 WAN구간이나 라우팅 된 네트워크에서는 이는 심각한 문제이다.
WINS와 DHCP 서비스가 통합 될 때는 DNS클라이언트를 dynamically 업데이트 하기 때문에 서버와 서버간의 트래픽이 많이 발생한다. 이 경우에는 이름영역(namespace)을 파티션으로 나누어 특정 name server에 특정 zone만이 복제되도록 해야 한다. 그리고 이중화로 발생되는 트래픽을 고려해야 한다.
조직이 상대적을 작은 경우거나 중앙에 집중되어 있는 경우에는 되도록 이면 zone을 적게 만들어야 한다. 경우에 따라서는 전 이름영역에 하나를 두는 경우도 있다. zone의 개수가 적으면 적을수록 zone transfer traffic은 적게 일어난다는 것은 기억해야 한다.
　

 

Non-MS DNS서버와의 통합

Non-MS DNS서버와 Active Directory에서 통합할 경우에는 다음 사항을 확인해야 한다.

DNS root domain 이름을 소유하고 있는 서버가 어느 것인지를 우선 확인한다. SRV record를 지원할 것 인지와 , incremental zone transfer, dynamic update, secure dynamic update을 이용할 것인지를 결정해야 한다.
기존의 DNS 서버가 SRV resource record가 지원하지 않을 경우에는 다음 중의 하나를 해야 한다.
DNS서버를 업그레이드 한다.
SRV resource record를 지원하는 DNS server를 새로 설치한다.
기존의 DNS서비스가 MS DNS 서비스가 아닐 경우에는 이것이 Active Directory와 DHCP 기능과 통합되는 지를 확인해야 한다.
　

 

WINS 및 DHCP와의 통합

DHCP 및 WINS서비스와 DNS서비스를 통합할 수 있도록 해 놓으면 non MS DNS 서버와의 통합운영도 용이하게 할 수 있다.

Windows 2000 이전 버전의 Win95/98 클라이언트는 DHCP서버로 부터 IP를 임대 받을 때에, DHCP 서버가 DNS forward zone와 reverse zone 파일에 이들 클라이언트의 호스트 이름과 IP주소를 동적으로 업데이트 한다.

Windows 2000를 탑재한 클라이언트나, Active Directory 업그레이드 클라이언트 모듈을 탑재한 Win95/98 클라이언트는 NetBIOS 이름이나 WINS를 이용하지 않는다. 그러나 그 이전 버전의 클라이언트가 있는 네트워크에서는 DHCP가 WINS서버를 명시하게 되면 클라이언트들은 WINS서버를 이용하게 되고, 또한 DNS 서비스가 이름이나 주소를 풀이해 내지 못할 경우에는 WINS의 forward 나 reverse lookup 기능을 이용에 의존하게 된다.

각 DNS zone에 따라 WINS lookup 서비스가 활성 혹은 비 활성으로 설정할 수 있으며, 이렇게 함으로써 WINS의 요청을 처리할 수 없는 non-MS DNS server로 트래픽이 발생하는 것을 방지할 수 있다.

　

 

DNS server와 Active Directory와의 통합

Active Directory는 네트워크 로그온 과정에서 domain이나 서버 및 호스트를 찾기 위한 서비스에 DNS서버를 이용한다.

DNS서버에 질의함 으로서 directory server가 어떤 호스트인지를 확인한다. 이는 SRV resource records를 참조하여 로그온 서비스를 하는 호스트를 찾는 과정을 말한다. 이 서버는 클라이언트가 속해 있는 서브넷과 가장 가까운 곳에 있는 로그온 서버를 찾아서 보내 준다.

클라이언트가 domain controller를 찾을 수 있도록, 각 domain controller의 NetLogon 서비스는 하나 이상의 SRV resource records를 DNS서버에 등록한다. 이는 텍스트 파일로는 systemroot\System32\Config\Netlogon.dns에서 볼 수 있다.

　

 

LDAP 이름 명명법(Naming convention)

Active Directory의 각 object는 LDAP DN(distinguished name)과 LDAP RDN(relative distinguished name)을 가지고 있으며, 디폴트로 Active Directory는 LDAP 프로토콜을 표준 프로토콜로 사용한다.

Distinguished Names

Terminal object나 leaf object는 다른 object를 포함하지 않는다. 사용자 계정 이름은 이 terminal object의 예로 들 수 있는 데, 이는 James Smith와 같이 CN(common name)으로 구별된다.

컨테이너 object(container object)는 다른 object를 포함하는 것을 말한다. Division은 컨테이너 object로서 employees나, computers, printers등을 포함한다.

Domain component는 하나의 LDAP domain으로서 다른 domain이나 컨테이너 object를 포함한다.

DN으로 terminal object를 가지고 있는 domain을 구별하거나 마지막 object인 terminal object를 포함하고 있는 컨테이너 object로 가는 경로를 알 수 있다. 다음을 예로 들어 보자.

Terminal object이 James Smith는 Users라는 컨테이너 object에 있고, 이 Users 컨테이너 object는 icmarket라는 domain 속에, 그리고 이 보다 더 큰 Internet domain인 com에 속해 있다. 이 경우에 James Smith 의 DN은 ;

DC=com, DC=icmarket, OU=Users, CN=James Smith 이 된다.

Relative Distinguished Names

RDN은 DN의 한 부분으로서 object을 찾는데 사용된다.

Users 컨테이너 object내에서 CN= James Smith하나만으로도 James Smith object를 찾아내는 데 충분하다. 그러므로 CN= James Smith은 James Smith object의 RDN으로서 Users 컨테이너 object내에서는 찾을 수 있는 것이다.

Active Directory에서는 동일한 parent object내에서 동일한 RDN을 가진 2 개의 object는 존재할 수가 없다.

각 Active Directory object에는 128bit로 구성되는 고유한 GUID(Globally Unique Identifier)가 부여된다. 이 GUID는 이동하거나 다른 이름으로 바뀌더라도 그 번호는 결코 바뀌지 않는다.

 

 

다른 이름 명명법(Naming Convention) 이용하기

이 기종과의 호환성을 유지하기 위하여 Active Directory 에서는 다음과 같은 몇 가지 다른 이름 명명법을 지원한다.

RFC 822 Name

RFC 822 명명법이라고 하는 것은 user_name@domain_name 포맷이다. 주로 Internet email 주소로 사용되는 포맷인데, 바로 이 포맷으로 Active Directory내의 모든 object를 나타내게 할 수 있다. 예: dwbaek@sns.co.kr

Security Account Manager Account Name

이는 MS NT 4.0에서 SAM(Security Account Manager)에서 계정이름으로 사용하는데 이용되었던 양식이다. 예: dwbaek

User Principal Name

UPN(User Principal Name)은 사용자와 그룹을 나타내는 간편한 방법으로서 Windows 2000의 로그온이름으로 사용된다. UPN은 SAM 계정이름에 object의 UPN의 접미어 부분을 가져 다 붙여서 만든다. 이 UPN접미어란 tree나 domain의 이름이다. UPN은 여기에 붙는 접미어가 틀리더라도 고유해야 한다. 예: dwbaek@sns.co.kr 혹은 dwbaek@icmarket.sns.co.kr

이 UPN은 전화 번호나 설명처럼 하나의 등록정보(property)이다. 여기에 어떠한 값도 주어질 수가 있다. 사용자의 UPN에 값(value)가 주어지지 않을 경우에는 그 사용자 UPN의 디폴트인 user_name@domain_name이 주어진다.

Active Directory Canonical Name

Active Directory Canonical Name이라는 것은 각 object의 tree내의 위치를 왼쪽부터 오른 쪽으로 백슬래쉬로 구분하여 표시하는 방법이다.

예: dwbaek/users/icmarket/sns.co.kr

Downlevel Domain Name

NT 4.0이전 버전에서 domain의 사용자 계정을 나타낼 때 사용하던 방법이다.

예: sns\dwbaek

LDAP URL

LDAP URL(Lightweight Directory Access Protocol Uniform Resource Locator)은 name server의 이름과 object의 DN을 연속적으로 붙여서 사용하는 방법이다. 이는 LDAP 클라이언트가 Active Directory에 액세스할 때에 스크립트로 이 LDAP URL을 사용한다.

예: LDAP://Server1.icmarket.sns/CN= DaeWon Baek /OU=users/DC=co/DC=kr

Universal Naming Convention

UNC(Universal Naming Convention)은 Windows 2000 서버의 공유 볼륨이나 프린터, 파일들을 지칭할 때 사용한다.

예: \\server1.icmarekt.sns\xl\sales.xls