LDAP Schema의 개념과 기본 요소
5000 단어 schema
BAP 제품에는 다음과 같은 범주가 있습니다.
# GalaxyTitle
objectclass ( 2.16.840.1.153730.3.4.2
NAME 'GalaxyTitle'
DESC 'GalaxyTitle use to manage title'
SUP top
STRUCTURAL
MUST ( uid )
MAY (
sortid )
)
# GalaxyPost
objectclass ( 2.16.840.1.153730.3.4.32
NAME 'GalaxyPost'
DESC 'GalaxyPost use to manage post'
SUP top
STRUCTURAL
MUST ( uid )
MAY (
sortid $ type )
)
# GalaxyDuty
objectclass ( 2.16.840.1.153730.3.4.22
NAME 'GalaxyDuty'
DESC 'GalaxyDuty use to manage duty'
SUP top
STRUCTURAL
MUST ( dutyuid )
MAY (
sortid )
)
# GalaxyGroup
objectclass ( 2.16.840.1.153730.3.2.12
NAME 'GalaxyGroup'
DESC 'GalaxyGroup use to manage group'
SUP top
STRUCTURAL
MUST ( uid )
MAY (
sysid $ employeeids $ sortid $ groupType $ searchCondition $ groupManager $ telephone $
email $ gfax $ others1 $ others2 $
others3 $ uniqueMember $ searchConditionXml)
)
# GalaxyPeople
objectclass ( 2.16.840.1.153730.3.2.22
NAME 'GalaxyPeople'
DESC 'GalaxyPeople use to manage people'
SUP InetOrgPerson
STRUCTURAL
MAY (
otherDepartmentNumber $ sortid $ ifactivated $ peopleLevel $ leadermember $ leaderFilter $ title $ post $ globalsortid $ virtualaccount
)
)
# GalaxyOrganization
objectclass ( 2.16.840.1.153730.3.2.2
NAME 'GalaxyOrganization'
DESC 'GalaxyOrganization use to manage dep'
SUP top
STRUCTURAL
MUST ( uid )
MAY (
sysid $ employeeids $ sortid $ depmanager $ telephone $
email $ gfax $ others1 $ others2 $
others3 $ depmanagerFilter $ title $ post)
)
# GalaxyContainer
objectclass ( 2.16.840.1.153730.3.2.16
NAME 'GalaxyContainer'
DESC 'a container,can fill with people,org,group...'
SUP top
STRUCTURAL
MUST ( cn )
)
# GalaxyLevel
objectclass ( 2.16.840.1.153730.3.3.18
NAME 'GalaxyLevel'
DESC 'level inof'
SUP top
STRUCTURAL
MUST ( cn $ number )
)
# GalaxyAttOfPeople
objectclass ( 2.16.840.1.153730.3.3.19
NAME 'GalaxyAttOfPeople'
DESC 'att name and sn'
SUP top
STRUCTURAL
MUST ( sn $ cn )
)
2. Attribute attribute는 위objectclass에 포함될 수 있는 속성입니다. 그 정의는 이름, 데이터 형식, 단일 값, 다중 값, 일치 규칙 등을 포함합니다.뒤에 구체적인 예로 설명하다. 3. Syntax syntax는 LDAP의'문법'입니다. 사실은 LDAP에서 사용할 데이터 형식과 데이터 제약입니다. 이 문법은 X.500의 데이터 제약에 따라 정의된 것입니다.정의에는 ID(X.500 준수)와 설명(DESP)이 필요합니다. 4.Matching Rules는 특정한 속성을 지정하는 데 사용되는 일치 규칙으로, 실제로는 LDAP 서버가 식별하고 정의된 속성을 일치시킬 수 있도록 특수한 Syntax의 별명을 정의하는 것이다.LDAP의 schema의 주요 요소는 바로 이것입니다. 다음은 LDAP가 규정하거나 현재 비교적 통용되는 schema를 열거했습니다. 일반적인 LDAP 서버는 이러한 정의를 식별할 수 있어야 합니다.이것이 바로 subschema라는 objectclass의 정의입니다. (2.5.20.1 NAME'subschema'AUXILIARY MAY(dITStructure Rules $nameForms $ditContentRules $objectClasses $attributeTypes $matchingRules $matchingRuleUse) 먼저 ID입니다. 여기는 2.5.20.1입니다. 이어서 NAME, AUXILIARY 설명은 보조형이고 그 다음은 선택 가능한 속성의 정의입니다.subschema에는 필수 속성이 정의되어 있지 않습니다. 정의가 필요하면 MAY와 같이 MUST () 에 속성을 놓고 $로 구분해서 속성 정의를 보십시오. (2.5.4.3 NAME'cn'SUP name EQUALITY caseIgnore Match) cn 속성의 부모 속성은name입니다.이것은 caseIgnoreMatch(정합 원칙은 EQUALITY, 그리고 SUBSTR은 문자열 정합, ORDERING는 순서 정합)와 같은 syntax 정의와 비교적 간단하다. 예를 들어 (1.3.6.1.4.1.1466.115.12.1.1.6 DESC'String') 이 정의는 1.3.6.1.4.1.1466.115.12.1.1.15.1.5는 LDAP의 문자열을 대표한다. 이 숫자열의 정의는 X.500과 관련이 있다.그것의 저장 방식, 차지하는 공간 크기 등을 포함한다.
마지막으로 Matching Rule의 예를 보면 앞에서 case Ignore Match를 언급했으니 그를 보십시오(2.5.13.2 NAME'case Ignore Match'SYNTAX 1.3.6.1.4.1.1466.115.12.15) 사실 1.3.6.1.4.1.1466.115.12.15.1.15는 LDAP 데이터 형식인 Directory String의 ID입니다. 앞의cn은 이 데이터 형식과 같아야 유효하다는 것을 설명합니다.그리고 많은 상용 schema의 정의가 RFC2252에 있습니다. LDAP 서버는 이러한 기본적인 schema를 지원해야 합니다.자, 이제 기본적으로 LDAP의 schema에 대해 대체적인 설명이 있습니다. 미흡하거나 타당하지 않은 점이 있을 수 있으니 여러분의 지적을 바랍니다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
[Node JS] 로그인 회원가입 로그아웃 구현 #2 / 회원가입 / hash / schema / bcryptbcrypt와 mongoose를 사용해 비밀번호를 암호화 하고 MongoDB에 유저 정보 저장. ▼회원가입을 위한 server.js 전체 코드▼ login.html파일을 만든 후 위의 폼을 만들기 위해 아래의 코드를...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.