www.rathontech.com

LDAP, PKI 전문 컨설팅 그룹

객체 클래스(object class)

엔트리에서 다음에 나오는 것은 두 개의 objectclass 속성이다. 이와 같은 속성은 그 엔트리가 어느 유형의 객체인지를 정의한다. 그러나 LDAP에서 객체의 개념은 극도로 단순하다. 그것은 한 엔트리가 어떤 속성을 가져야 하는 지와 어떠한 속성을 가지도록 허가되었는지를 단순히 정의할 뿐이다. 모든 객체 클래스는 그들의 부모 객체 클래스로부터 요구사항을 상속 받고 자신의 것을 추가한다. 그렇지만, objectclass 속성은 특별한 속성이 아니다. 그것은 모든 LDAP 작업에서 다른 LDAP 속성과 정확하게 똑같이 취급된다. 하지만 객체 클래스를 수정하는 것은 그 작업 이후에 객체가 서버에 받아들여질지 아닐지를 결정한다.

위에서의 LDAP 객체 정의는 중요하다. 왜냐하면 이 정의가 실제로 얼마나 단순한가를 자신도 납득하기 어렵기 때문이다. 다시 말해 한 객체는 단순히 어떤 속성이 엔트리에 저장되어야 하거나 저장될 수 있음을 정의할 뿐이다. 필자는 posixAccount 객체 클래스와 printer 객체 클래스를 모두 가지는 객체를 생성할 수 있다. 이 조합은 독자와 필자 모두에게 너무나 모순되게 보일 수 있는데, LDAP의 측면에서 보면, 자료는 단지 자료일 뿐이고 그 자체로는 아무 의미가 없다. LDAP를 대단하도록 만드는 것 중의 하나가 사람에게는 속성들이 무엇인가를 의미한다는 것이다. 그렇지만 객체 클래스와 속성에 지능적으로 이름을 붙여서 실제로 뜻이 통하는 객체를 생성해냄으로써 그 의미를 유지하는 것은 자료를 가지고 작업하는 사람에게 달려있다. 이것은 듣는 것보다는 실제로 훨씬 어렵고, 이 모두를 어떻게 할 것인가를 결정하는 것은 LDAP를 이용하는 첫 번째 과정이다. 다행스럽게도 여러분에게 필요한 객체 클래스의 대부분은 LDAP 명세(posixAccount가 최근 RFC 의 일부분이기는 하지만)의 일부분이고, 그래서 적어도 처음에는 이에 대해 너무 많이 걱정할 필요는 없다.

단지 강제로 객체 클래스를 설정하고 이것을 객체에 추가할 수는 없다는 점에 유의해라. schema라 불리는 안에서, 서버는 이를 위해 정의된 각각의 객체 클래스를 가지고 있어야 한다. 만약 정의되지 않은 객체 클래스를 가지고 엔트리에 추가하려고 한다면, 스키마 위반이 되어 작업은 실패할 것이다. 서버에 대해 객체 클래스를 정의하는 것은 서버마다 다르지만, 서버들은 대부분 이것들을 아주 잘 문서화하고 있다.

이와 같은 경우, 엔트리는 top과 posixAccount 유형이 될 것이라고 선언해왔다. top 객체 클래스는 단지 objectclass 속성이 존재하기만을 요구하고, 이는 정의에 의하면 다른 모든 LDAP 객체 클래스에 대한 부모 객체 클래스이다. 이와 같은 사실에 근거를 두고 생각해 보면, 객체들은 항상 객체 클래스 목록을 출력하며, 부모 객체 클래스를 따라서 그것들은 모두 하나의 인스턴스이며, LDAP 데이터베이스 안에 있는 모든 객체는 객체 클래스로서 top을 리스트할 것이다. posixAccount 객체 클래스는 루크 하워드(Luke Howard)가 RFC 에서 정의했다. 참고로 루크 하워드는 LDAP 가 유닉스 계정을 저장하고 LDAP안에 있는 passwd 파일로부터 모든 정보를 저장할 수 있는 방법과 관련하여 주목할만한 일을 해왔다.

속성

짐작한 바와 같이 속성은 여러 개의 값을 가질 수 있다. 이와 같은 특성은 속성의 정의에 진술되어 있으며 대부분을 지원한다.

예전에 언급한대로 top 객체 클래스는 obejctclass가 존재하기를 요구하고, objectclass가 존재하기도 한다. 따래서 top의 존재는 이 엔트리에 다른 영향을 미치지 못한다. posixAccount 객체 클래스는 cn, uid, uidNumber, gidNumber, homeDirectory를 요구하며, userPassword, loginShell, gecos, description을 허용한다. 유효한 로그인 계정은 description을 제외한 모든 정보를 가져야 하므로 이것들 모두를 우리의 엔트리에 포함했다.

속성값 전부는 userPassword 값을 제외하고는 자체 설명적이다. 대부분의(모든?) 유닉스 머신들이 crypt 형태로 암호를 저장하고, LDAP 엔트리를 passwd 파일로 덤프할 것이기 때문에, LDAP 암호 역시 crypt 형식으로 저장해야 한다. 많은 LDAP 서버들은 다중 암호 형식을 지원하고, 우리는 형식을 지정 법을 설명한 예제를 포함했다. 다중 형식을 지원하는 서버들은 기본 형식의 명세를 허가해야 한다. 또한 LDAP 서버를 유닉스 계정을 저장하는데 사용할 계획이라면 기본 형식을 crypt로 지정할 것을 추천한다. 이에 대한 유일한 예외는 유닉스 머신 전부가 LDAP 서버로부터 직접 떨어져 인증할 수 있고 crypt 이외의 형식을 이해할 수 있을 경우이다.