5장. 디렉터리 항목 스키마 참조


5.1. 디렉터리 서버 스키마 정보

이 장에서는 디렉터리 스키마의 몇 가지 기본 개념에 대한 개요를 제공하고 스키마가 설명하는 파일을 나열합니다. 개체 클래스, 속성 및 개체 식별자(OID)에 대해 설명하고 서버 스키마 및 스키마 검사 확장에 대해 간단히 설명합니다.

5.1.1. 스키마 정의

디렉터리 스키마는 데이터를 디렉터리에 저장할 수 있는 방법을 정의하는 규칙 집합입니다. 디렉터리 정보는 개별 항목이며 각 항목은 특성 세트와 해당 값으로 구성됩니다. 항목에 설명된 ID 유형은 항목의 개체 클래스에 정의되어 있습니다. 오브젝트 클래스는 항목이 오브젝트 클래스에 대해 정의된 속성 세트를 통해 설명하는 오브젝트의 종류를 지정합니다.

기본적으로 스키마 파일은 생성할 수 있는 항목( 오브젝트 클래스) 및 해당 항목을 설명할 수 있는 방법( 특성)의 목록입니다. 스키마는 오브젝트 클래스 및 특성을 정의합니다. 스키마는 특성 값에 포함된 형식( 특성의 구문)과 해당 특성의 단일 인스턴스만 있을 수 있는지 여부를 정의합니다.

추가 스키마 파일을 Directory Server 구성에 추가하고 서버에 로드할 수 있으므로 스키마를 사용자 지정할 수 있으며 필요에 따라 확장할 수 있습니다.

개체 클래스, 속성 및 디렉터리 서버가 스키마를 사용하는 방법에 대한 자세한 내용은 배포 가이드를 참조하십시오.

주의

스키마 정의에 너무 적은 또는 너무 많은 문자가 포함된 경우 Directory Server가 시작되지 않습니다. LDAP 표준에서 0개 이상의 공백을 사용할 수 있는 위치에 정확히 하나의 공간을 사용합니다(예: NAME 키워드와 특성 유형의 이름 사이의 위치).

5.1.1.1. 오브젝트 클래스

LDAP에서 오브젝트 클래스는 항목을 정의하는 데 사용할 수 있는 속성 세트를 정의합니다. LDAP 표준에서는 사람(개인 및 inetOrgPerson), 그룹(groupOfUniqueNames), 위치(locality), 조직 및 부서(조직 및 조직Unit) 및 장비(장치)와 같은 많은 일반적인 유형의 항목에 대한 오브젝트 클래스를 제공합니다.

스키마 파일에서 오브젝트 클래스는 objectclasses 줄로 식별된 다음 OID, 이름, 설명, 직접 우수한 오브젝트 클래스(오브젝트 클래스와 함께 사용하고 이 오브젝트 클래스와 해당 특성을 공유하는 개체 클래스) 및 필수(MAY) 속성 목록에 의해 식별됩니다.

이는 예 5.1. “개인 오브젝트 클래스 스키마 항목” 에 표시됩니다.

예 5.1. 개인 오브젝트 클래스 스키마 항목

objectClasses: ( 2.5.6.6 NAME 'person' DESC 'Standard LDAP objectclass' SUP top MUST ( sn $ cn ) MAY ( description $ seeAlso $ telephoneNumber $ userPassword ) X-ORIGIN 'RFC 2256' )
5.1.1.1.1. 필수 및 허용된 속성

모든 오브젝트 클래스는 여러 필수 특성과 허용된 속성을 정의합니다. 필수 속성은 지정된 오브젝트 클래스를 사용하여 항목에 있어야 하지만 허용된 속성은 허용되며 사용할 수 있지만 항목이 유효한 경우에는 필요하지 않습니다.

예 5.1. “개인 오브젝트 클래스 스키마 항목” 에서와 같이 사용자 오브젝트 클래스에는 cn,sn 및 objectClass 속성이 필요하며 설명도참조하십시오. ,telephoneNumber, userPassword 속성도 참조하십시오.

참고

모든 항목에는 항목에 할당된 오브젝트 클래스를 나열하는 objectClass 속성이 필요합니다.

5.1.1.1.2. 오브젝트 클래스 상속

항목에 둘 이상의 오브젝트 클래스가 있을 수 있습니다. 예를 들어, 사람의 항목은 person object 클래스에 의해 정의되지만, inetOrgPerson 및 organizationalPerson 객체 클래스의 특성에 의해 동일한 사람이 설명될 수도 있습니다.

또한 개체 클래스는 계층적 일 수 있습니다. 개체 클래스는 자체 필수 및 허용된 속성 외에도 다른 클래스에서 속성을 상속할 수 있습니다. 두 번째 오브젝트 클래스는 첫 번째의 최상 의 오브젝트 클래스입니다.

서버의 개체 클래스 구조는 특정 항목에 대한 필수 및 허용되는 속성 목록을 결정합니다. 예를 들어 사용자 항목에 inetOrgPerson 개체 클래스가 있어야 합니다. 이 경우 항목은 inetOrgPerson,organizationalPerson 에 대한 우수한 오브젝트 클래스와 organizationalPerson 의 우수한 오브젝트 클래스를 포함해야 합니다.

objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

inetOrgPerson 개체 클래스가 항목에 할당되면 항목은 우수한 오브젝트 클래스에서 필수 및 허용되는 속성을 자동으로 상속합니다.

5.1.1.2. 속성

디렉터리 항목은 속성 및 해당 값으로 구성됩니다. 이러한 쌍을 특성-값 어설션 또는 AVA라고 합니다. 디렉터리의 모든 정보는 설명적 특성과 연결되어 있습니다. 예를 들어, cn 속성은 cn: jdkn과 같은 사람의 전체 이름을 저장하는 데 사용됩니다.

또 다른 속성으로, 존(John)에 대한 추가 정보를 제공할 수 있습니다.

givenname: John
surname: Smith
mail: jsmith@example.com

스키마 파일에서 속성은 attributetypes 줄로 식별된 다음, OID, 이름, 설명, 구문(값에 대해 허용된 형식), 선택적으로 특성이 단일 또는 다중 값인지 여부, 특성이 정의된 위치로 표시됩니다.

이는 예 5.2. “설명 특성 스키마 항목” 에 표시됩니다.

예 5.2. 설명 특성 스키마 항목

attributetypes: ( 2.5.4.13 NAME 'description' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' )

일부 속성은 축약할 수 있습니다. 이러한 약어는 특성 정의의 일부로 나열됩니다.

attributetypes: ( 2.5.4.3 NAME ( 'cn' 'commonName' ) ...
5.1.1.2.1. 디렉터리 서버 속성 구문

특성의 구문은 속성이 허용하는 값의 형식을 정의합니다. 다른 스키마 요소와 마찬가지로 구문은 스키마 파일 항목에서 구문의 OID를 사용하여 속성에 대해 정의됩니다. Directory Server Console에서 구문은 친숙한 이름으로 참조합니다.

Directory Server는 특성의 구문을 사용하여 항목에서 정렬 및 패턴 일치를 수행합니다.

LDAP 특성 구문에 대한 자세한 내용은 RFC 4517 을 참조하십시오.

표 5.1. 지원되는 LDAP 속성 구문
이름OID정의

바이너리

1.3.6.1.4.1.1466.115.121.1.5

더 이상 사용되지 않습니다. 대신 Octet 문자열을 사용합니다.

비트 문자열

1.3.6.1.4.1.1466.115.121.1.6

비트팅인 값의 경우(예: '0101111101'B )

부울

1.3.6.1.4.1.1466.115.121.1.7

두 개의 허용된 값만 있는 속성의 경우 TRUE 또는 Cryostat입니다.

국가 문자열

1.3.6.1.4.1.1466.115.121.1.11

정확히 두 개의 출력 가능한 문자열 문자로 제한되는 값(예: 미국)입니다.

DN

1.3.6.1.4.1.1466.115.121.1.12

고유 이름(DN)의 경우

전달 방법

1.3.6.1.4.1.1466.115.121.1.14

정보를 전달하거나 엔티티에 연결하는 데 선호되는 방법이 포함된 값의 경우 다른 값은 달러 기호($)로 구분됩니다. 예를 들면 다음과 같습니다.

[literal,subs="+quotes,vernortheastim"] …​. 전화 $ physical …​.

디렉터리 문자열

1.3.6.1.4.1.1466.115.121.1.15

유효한 UTF-8 문자열인 값의 경우 이러한 값은 대소문자를 구분하지 않습니다. Directory String 및 관련 구문에 대해 대소문자를 구분하지 않고 대소문자를 구분하지 않는 일치 규칙을 모두 사용할 수 있습니다.

향상된 가이드

1.3.6.1.4.1.1466.115.121.1.21

속성 및 필터를 기반으로 복잡한 검색 매개변수가 포함된 값의 경우

facsimile

1.3.6.1.4.1.1466.115.121.1.22

숫자가 포함된 값의 경우

Fax

1.3.6.1.4.1.1466.115.121.1.23

전송된 팩스의 이미지를 포함하는 값의 경우

일반화된 시간

1.3.6.1.4.1.1466.115.121.1.24

인쇄 가능한 문자열로 인코딩되는 값의 경우 시간대를 지정해야 합니다. CryostatT 시간을 사용하는 것이 좋습니다.

가이드

1.3.6.1.4.1.1466.115.121.1.25

사용되지 않음. 속성 및 필터를 기반으로 복잡한 검색 매개변수가 포함된 값의 경우

IA5 String

1.3.6.1.4.1.1466.115.121.1.26

유효한 문자열인 값의 경우 이러한 값은 대소문자를 구분하지 않습니다. IA5 문자열 및 관련 구문에 대해 대소문자를 구분하지 않고 대소문자를 구분하지 않는 일치 규칙을 모두 사용할 수 있습니다.

정수

1.3.6.1.4.1.1466.115.121.1.27

정수 값이 있는 경우입니다.

JPEG

1.3.6.1.4.1.1466.115.121.1.28

이미지 데이터가 포함된 값의 경우

이름 및 선택적 UID

1.3.6.1.4.1.1466.115.121.1.34

DN 및 (선택 사항)의 조합 값이 포함된 값의 경우 고유 ID입니다.

숫자 문자열

1.3.6.1.4.1.1466.115.121.1.36

숫자와 공백의 문자열이 모두 포함된 값의 경우

OctetString

1.3.6.1.4.1.1466.115.121.1.40

값이 binary인 경우 바이너리 구문이 대체됩니다.

오브젝트 클래스 설명

1.3.6.1.4.1.1466.115.121.1.37

오브젝트 클래스 정의가 포함된 값의 경우

OID

1.3.6.1.4.1.1466.115.121.1.38

OID 정의가 포함된 값의 경우

우편 주소

1.3.6.1.4.1.1466.115.121.1.41

우편 주소 = dstring *("$" dstring) 형식으로 인코딩되는 값의 경우 예를 들면 다음과 같습니다.

[literal,subs="+quotes,vernortheastim"] …​. 1234 Main St.$Raleigh, NC 12345$USA …​.

각 dstring 구성 요소는 DirectoryString 값으로 인코딩됩니다. 줄 구분 기호가 잘못되지 않도록 백슬래시와 달러 문자가 발생하면 인용됩니다. 많은 서버는 우편 주소를 최대 30 자까지 6 줄로 제한합니다.

출력 가능한 문자열

1.3.6.1.4.1.1466.115.121.1.44

인쇄 가능한 문자열이 포함된 값의 경우

Space-Insensitive 문자열

2.16.840.1.113730.3.7.1

공백을 구분하지 않는 문자열이 포함된 값의 경우

전화 번호

1.3.6.1.4.1.1466.115.121.1.50

전화 번호 형식의 값입니다. 전화 번호를 국제 형식으로 사용하는 것이 좋습니다.

Teletex 터미널 식별자

1.3.6.1.4.1.1466.115.121.1.51

국제 전화 번호가 포함된 값의 경우

전화 번호

1.3.6.1.4.1.1466.115.121.1.52

Telex 번호, 국가 코드 및 Telex 터미널의 응답 코드가 포함된 값의 경우

URI

 

URL 형식의 값의 경우 http://, https://, ftp://, ldap://, ldaps:// 와 같은 문자열에 의해 도입되었습니다. URI는 IA5 문자열과 동일한 동작을 갖습니다. 이 구문에 대한 자세한 내용은 RFC 4517 에서 참조하십시오.

5.1.1.2.2. 단일 및 다중 값 속성

기본적으로 대부분의 속성은 다중 값입니다. 즉, 항목이 다른 값을 사용하여 동일한 속성을 여러 번 포함할 수 있습니다. 예를 들면 다음과 같습니다.

dn: uid=jsmith,ou=marketing,ou=people,dc=example,dc=com
ou: marketing
ou: people

예를 들어 cn,tel 및 objectclass 속성은 모두 둘 이상의 값을 가질 수 있습니다. 단일 값인 특성 - 즉, 단일 값만 허용하는 것처럼 스키마에 속성의 하나의 인스턴스만 지정할 수 있습니다. 예를 들어 uidNumber 는 하나의 가능한 값만 가질 수 있으므로 해당 스키마 항목에는 SINGLE-VALUE 라는 용어가 있습니다. 속성이 다중 값인 경우 value 표현식이 없습니다.

5.1.2. 기본 디렉터리 서버 스키마 파일

Directory Server에 대한 템플릿 스키마 정의는 /etc/dirsrv/schema 디렉터리에 저장됩니다. 이러한 기본 스키마 파일은 새 Directory Server 인스턴스의 스키마 파일을 생성하는 데 사용됩니다. 각 서버 인스턴스에는 /etc/dirsrv/slapd- 인스턴스 /schema에 자체인스턴스별 스키마 디렉터리가 있습니다. 인스턴스 디렉터리의 스키마 파일은 해당 인스턴스에서만 사용됩니다.

디렉터리 스키마를 수정하려면 인스턴스별 스키마 디렉터리에 새 속성 및 새 개체 클래스를 만듭니다. 기본 스키마는 새 인스턴스를 만드는 데 사용되며 각 인스턴스에는 고유한 스키마 파일이 있으므로 각 인스턴스를 사용하는 것과 일치하는 각 인스턴스에 대해 약간 다른 스키마를 사용할 수 있습니다.

Directory Server Console 또는 LDAP 명령을 사용하여 추가된 사용자 지정 속성은 99user.ldif 파일에 저장됩니다. 기타 사용자 지정 스키마 파일은 각 인스턴스의 /etc/dirsrv/slapd-인스턴스/schema 디렉터리에 추가할 수 있습니다. Red Hat Directory Server와 함께 제공되는 표준 파일을 수정하지 마십시오.

Directory Server가 계획 디렉터리 스키마에 대한 정보 및 제안을 저장하는 방법에 대한 자세한 내용은 배포 가이드를 참조하십시오.

표 5.2. 스키마 파일
스키마 파일목적

00core.ldif

X.500 및 LDAP 표준(RFC)에서 권장 코어 스키마입니다. 이 스키마는 인스턴스 구성에 디렉터리 서버 자체에서 사용하고 서버 인스턴스를 시작하는 데 사용됩니다.

01core389.ldif

X.500 및 LDAP 표준(RFC)에서 권장 코어 스키마입니다. 이 스키마는 인스턴스 구성에 디렉터리 서버 자체에서 사용하고 서버 인스턴스를 시작하는 데 사용됩니다.

02common.ldif

항목을 구성하는 데 사용되는 Directory Server에서 정의한 RFC 2256, LDAPv3 및 표준 스키마의 표준 관련 스키마입니다.

05rfc2927.ldif

RFC 2927의 스키마, "MIME Directory Profile for LDAP 스키마"입니다.

05rfc4523.ldif

X.509 인증서에 대한 스키마 정의입니다.

05rfc4524.ldif

cosine LDAP/X.500 스키마.

06inetorgperson.ldif

RFC 2798, RFC 2079 및 RFC 1274의 inetOrgPerson 스키마 요소.

10rfc2307.ldif

RFC 2307의 스키마, "LDAP를 네트워크 정보 서비스로 사용하기 위한 접근 방식".

20subscriber.ldif

Directory Server-Nortel 구독자 상호 운용성을 위한 공통 스키마 요소

25java-object.ldif

RFC 2713, "LDAP 디렉터리에서 Java 오브젝트를 나타내는 Schema"의 스키마입니다.

28pilot.ldif

새 배포에서 더 이상 사용하지 않는 Pilot RFC, 특히 RFC 1274의 스키마입니다.

30ns-common.ldif

공통 스키마.

50ns-admin.ldif

관리 서버에서 사용하는 스키마입니다.

50ns-certificate.ldif

Red Hat Certificate System에서 사용하는 스키마입니다.

50NS-directory.ldif

레거시 Directory Server 4.x 서버에서 사용하는 스키마입니다.

50ns-mail.ldif

메일 서버의 스키마입니다.

50NS-value.ldif

Directory Server의 값 항목에 대한 스키마입니다.

50NS-web.ldif

웹 서버의 스키마입니다.

60autofs.ldif

설정을 위한 오브젝트 클래스입니다. 이는 NIS 서버에 사용되는 여러 스키마 파일 중 하나입니다.

60eduperson.ldif

교육 관련 인력 및 조직 항목의 스키마 요소.

60mozilla.ldif

Mozilla 관련 사용자 프로파일의 스키마 요소.

60nss-ldap.ldif

GSS-API 서비스 이름의 스키마 요소.

60pam-plugin.ldif

디렉터리 서비스와 PAM 모듈을 통합하는 스키마 요소.

60pureftpd.ldif

FTP 사용자 계정을 정의하는 스키마 요소.

60rfc2739.ldif

calendars 및 vCard 속성에 대한 스키마 요소.

60rfc3712.ldif

프린터 구성을 위한 스키마 요소.

60sabayon.ldif

sabayon 사용자 항목을 정의하는 스키마 요소.

60sudo.ldif

sudo 사용자 및 역할을 정의하는 스키마 요소.

60trust.ldif

NSS 또는 PAM에 대한 신뢰 관계를 정의하는 스키마 요소입니다.

99user.ldif

Directory Server Console을 통해 추가된 사용자 지정 스키마 요소.

5.1.3. OID(오브젝트 식별자)

모든 스키마 요소에는 속성 및 개체 클래스를 포함하여 OID(오브젝트 식별자)가 할당됩니다. OID는 일반적으로 점으로 구분된 문자열로 작성된 정수의 시퀀스입니다. 모든 사용자 정의 속성 및 클래스는 X.500 및 LDAP 표준을 준수해야 합니다.

주의

스키마 요소에 대해 OID를 지정하지 않으면 디렉터리 서버는 자동으로 ObjectClass_name-oid 및 attribute_name-oid 를 사용합니다. 그러나 숫자 OID 대신 텍스트 OID를 사용하면 클라이언트, 서버 상호 운용성 및 서버 동작에 문제가 발생하여 숫자 OID를 할당하는 것이 좋습니다.

OID는 에 구축될 수 있습니다. 기본 OID는 조직의 모든 스키마 요소에 사용되는 루트 번호이며 스키마 요소를 늘릴 수 있습니다. 예를 들어 기본 OID는 1 이 될 수 있습니다. 그런 다음 회사는 속성에 1.1 을 사용하므로 모든 새 속성에 1.1.x 의 OID가 있습니다. 오브젝트 클래스에 1.2 를 사용하므로 모든 새 오브젝트 클래스에는 1.2.x 의 OID가 있습니다.

Directory Server 정의 스키마 요소의 경우 기본 OID는 다음과 같습니다.

  • Netscape 기본 OID는 2.16.840.1.113730 입니다.
  • Directory Server 기본 OID는 2.16.840.1.113730.3 입니다.
  • 모든 Netscape 정의 속성에는 기본 OID 2.16.840.1.113370.3.1 이 있습니다.
  • 모든 Netscape 정의 오브젝트 클래스에는 기본 OID 2.16.840.1.113730.3.2 가 있습니다.

OID에 대한 자세한 내용이나 접두사를 요청하려면 http://www.iana.org/ 에서IANA(Internet Assigned Number Authority) 웹 사이트로 이동하십시오.

5.1.4. 스키마 확장

Directory Server 스키마에는 대부분의 디렉터리 요구 사항을 충족하는 데 사용할 수 있는 수백 개의 오브젝트 클래스 및 특성이 포함되어 있습니다. 이 스키마는 사용자 지정 스키마 파일을 생성하여 엔터프라이즈의 디렉터리 서비스에 대한 요구 사항을 충족하는 새로운 개체 클래스 및 특성을 사용하여 확장할 수 있습니다.

스키마에 새 특성을 추가할 때 이를 포함하도록 새 개체 클래스를 만들어야 합니다. 기존 오브젝트 클래스에 새 속성을 추가하면 표준 LDAP 스키마를 사용하는 기존 LDAP 클라이언트와 Directory Server의 호환성이 손상될 수 있으며 서버를 업그레이드할 때 문제가 발생할 수 있습니다.

서버 스키마 확장에 대한 자세한 내용은 배포 가이드를 참조하십시오.

5.1.5. 스키마 검사

스키마 검사는 LDIF를 사용하여 가져온 데이터베이스에서 생성, 수정 또는 가져온 데이터베이스에서 모든 항목을 확인하여 스키마 파일의 스키마 정의를 준수함을 의미합니다. 스키마 확인에서는 다음 세 가지 사항을 확인합니다.

  • 항목에 사용되는 개체 클래스 및 특성은 디렉터리 스키마에 정의됩니다.
  • 오브젝트 클래스에 필요한 속성은 항목에 포함되어 있습니다.
  • 오브젝트 클래스에서 허용하는 속성만 항목에 포함됩니다.

스키마 확인이 설정되어 있는 Directory Server를 실행해야 합니다. 스키마 검사 활성화에 대한 자세한 내용은 관리 가이드를 참조하십시오.

5.1.6. 구문 검증

구문 검증 은 Directory Server에서 특성 값이 해당 속성에 필요한 구문과 일치하는지 확인하는 것을 의미합니다. 예를 들어 구문 검증은 새로운 telephoneNumber 속성에 실제로 해당 값에 유효한 전화 번호가 있는지 확인합니다.

기본 구성을 사용하면 구문 검증(예: 스키마 검사)에서 속성 값이 필요한 구문과 일치하는지 확인하고 구문을 위반하는 모든 수정 사항을 거부하도록 디렉터리 수정을 확인합니다. 선택적으로 구문 위반에 대한 경고 메시지를 기록하고 변경을 거부하거나 수정 프로세스가 성공할 수 있도록 구문 유효성 검사를 구성할 수 있습니다.

DN을 제외한 모든 구문은 RFC 4514 에 대해 검증됩니다. 기본적으로 DN은 RFC 1779 또는 RFC 2253 에 대해 검증되며 RFC 4514 보다 엄밀합니다. DN에 대한 엄격한 검증을 명시적으로 구성해야 합니다.

이 기능은 바이너리 구문(확인할 수 없음) 및 비표준 구문을 제외하고 표 5.1. “지원되는 LDAP 속성 구문” 에 나열된 모든 속성 구문과 필수 형식이 없는 비표준 구문을 확인합니다. 검증되지 않은 구문은 다음과 같습니다.

  • Fax(이진)
  • OctetString(이진)
  • jpeg (binary)
  • 바이너리 (Non-standard)
  • Space Insensitive String (non-standard)
  • URI (Non-standard)

구문 검증이 활성화되면 속성이 항목에 추가되거나 수정될 때마다 새 속성 값이 선택됩니다. (이에는 공급자 서버에서 구문이 검사되었으므로 복제 변경 사항은 포함되지 않습니다.) syntax-validation.pl 스크립트를 실행하여 기존 속성 값의 구문 위반을 확인할 수도 있습니다.

구문 검증 옵션에 대한 자세한 내용은 관리 가이드를 참조하십시오.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Legal Notice

Theme

© 2026 Red Hat
맨 위로 이동