Oracle Internet Directory - LDAP 67(ModifyDN 오류) · OU 이동 실패 · ACI 권한 오류까지 -
변경 조건과 결과를 확인하는 진단 가이드
LDAP 67(ModifyDN) / OU 이동 실패 / ACI 오류 — 왜 터지고, 어떻게 바로잡나
Oracle Internet Directory(OID) 및 Oracle Directory Integration Platform(ODIP) 운영에서 확인할 증상 → 원인 가설 → 검증 조건을 정리했습니다.
권한(ACI), DIT·매핑, 체크포인트를 각각 검토해야 합니다. 예제는 설치 버전과 실제 환경에 맞춰 검증할 자료이며, 그대로 실행할 복구 절차나 재발 방지 보장은 아닙니다.
이 글은 이런 분들이 읽으면 좋아요
- DIP AD→OID 동기화에서 67/권한/OU 이동 이슈가 반복되는 운영자
- 운영 중 복구 조건과 영향 범위를 정리할 기준이 필요한 팀
- 프로파일·매핑·DIT·ACI를 변경 범위를 구분해 검토하려는 분
이 글에서 바로 얻을 수 있어요
- 별도 검증이 필요한 LDIF·명령·체크리스트
- ACI 유효 권한과 적용 범위의 확인 조건
- LACN↔USN을 같은 원본 기준으로 해석하는 방법
이렇게 읽으면 더 빠릅니다
- #스키마 → #SSL → #ACI → #DIT 순으로 사전 체크
- 실행은 Disable → 변경 → 검증 → Enable
- 스모크 3건은 예시이며, 데이터 결과·로그·합의된 기준으로 승인/중단 결정
Disable → 변경 → 검증 → Enable기존 구성의 재기동 예시:
Admin → Node Manager → OPMN(OID) → wls_ods1/2(DIP). 설치 버전·의존성에 맞는 절차를 확인해야 하며, 보편적인 기동/정지 순서로 적용하지 않습니다.
1) 증상 & 원인 패턴 (왜 터질까?)
용도
오류 코드·진단 메시지·요청 DN과 작업 유형을 기록하고, RDN 제약·권한·스키마·연결 문제를 구분합니다.
목적
로그와 요청을 대조해 원인 가설을 검토하고, 근거 없는 반복 변경을 피합니다.
해석 방법
로그의 에러코드/키워드(67, proxy, SSL, USN)를 증상→처방 표에 매핑합니다.
- LDAP 67 → 현재 RDN 값을 일반
modify로 제거하려 했는지 확인합니다. 이름 변경은modrdn요청과 서버의 스키마 제약을 검토해야 합니다. - OU 이동 실패 → 새 부모
add/ 기존 부모delete등 유효 권한, 대상 부모 존재 여부와 스키마를 확인합니다. 권한 부족으로만 단정하지 않습니다. - ACI 부족 →
add/delete/write/read/search/compare/browse/proxy를 일괄 부여하는 것이 아니라, 작업별 유효 권한·그룹·상속·적용 범위를 확인합니다. proxy는 일반 이동의 필수 권한이 아닙니다. - SSL/TLS 미스 → 설정된 리스너·모드·인증서 신뢰를 확인합니다. SSL_ENCRYPT와 4141은 기존 구성 예시이며, 포트 번호 자체가 TLS를 보장하지 않습니다.
- LACN/USN 갭 → 체크포인트의 원본과 AD DC·invocationID를 먼저 맞춥니다. 번호 차이는 누락 건수나 rewind 필요성을 증명하지 않습니다.
- EM Agent TZ → 주로 가시성 문제. 동작엔 제한적이나 운영에선 정합 권장.
2) 사전 점검 (스키마 · SSL · 프로파일 사전체크)
실패한 항목의 현재 위치, 옮길 위치와 실행 계정을 기록해 두면 구조 문제와 권한 문제를 나누어 조사할 수 있습니다. 오류 번호만 보고 권한을 넓히기 전에 이 조건부터 확인해야 합니다.
용도
변경 전 스키마·연결·프로파일의 확인 결과와 미확인 조건을 기록합니다.
목적
운영 창구 열리기 전에 구조/연결/설정 3요소 통과로 “실패 원인 불명” 방지.
해석 방법
각 테스트의 성공/에러 메시지를 기록, 에러는 해당 처방 섹션으로 해당 절로 돌아가 재확인.
스키마 존재
orclADUser/Group/Object는 필요한 스키마 정의와 구분해 확인합니다. 예제처럼 같은 이름의 속성을 요청해 결과가 없다는 이유만으로 스키마가 없다고 판단하지 않습니다.
ldapsearch -h <OID_HOST> -p 389 -D "cn=orcladmin" -w '<PW>' \ -b "cn=subschema" -s base "(objectClass=*)" \ "orclADUser" "orclADGroup" "orclADObject"
해석: 설치 버전의 objectClasses·attributeTypes 및 실제 매핑을 확인한 뒤 필요한 정의를 판단합니다. 예제 결과만으로 스키마 등록을 실행하지 않습니다. -w 인자는 비밀번호 노출 가능성이 있으며 389 자체는 암호화를 보장하지 않습니다.
SSL/TLS 신뢰체인
- DIP→OID의 실제 리스너·모드를 확인:
4141&SSL_ENCRYPT는 환경별 예시 - OID 인증서를 DIP keystore/cacerts에 신뢰로 등록
프로파일 사전체크
# Map Rule 문법 manageSyncProfiles validateMapRules -p <ProfileName> # 연결 테스트 manageSyncProfiles testProfile -p <ProfileName>
해석: validate는 문법/매핑 구조, testProfile은 단순 연결 점검이 아닙니다. Oracle 11g 문서에서는 실제 동기화를 수행하므로 설치 버전·인자와 대상 영향을 확인해야 합니다. 기존 -p 예제도 그대로 실행하지 않습니다.
3) ACI 확인 — Rename/이동의 유효 권한
용도
RDN 변경과 부모 이동을 구분하고, 실제 바인드 주체의 유효 권한을 확인합니다.
목적
LDAP 50(권한), 65(오브젝트 클래스), 67(RDN 제약)을 구분합니다. ACI 변경만으로 모두 해결되지는 않습니다.
해석 방법
orclACI 검색 시 group DN·권한 키워드가 기대값(아래 표)과 일치하는지 확인.
| 상황 | 필요 권한 | 적용 위치 |
|---|---|---|
| RDN 변경(동일 부모) | 엔트리 RDN write + 부모 browse 등 조회 조건 확인; proxy는 실제 프록시 사용 시 별도 검토 | 대상 엔트리 & 해당 부모 |
| 부모 컨테이너 이동 | 새 부모 add, 기존 부모 delete, 엔트리 RDN write, 부모들 browse 등 조회 조건 확인; proxy는 일반 필수 조건 아님 | 기존/새 부모 컨테이너 + 엔트리 |
LDIF — Entry/Attr 권한 부여
dn: <대상_컨테이너_DN> changetype: modify add: orclACI orclACI: access to entry by group="cn=odisgroup,cn=DIPAdmins,cn=Directory\20Integration\20Platform,cn=Products,cn=OracleContext" (browse,proxy) - add: orclACI orclACI: access to attr=(*) by group="cn=odisgroup,cn=DIPAdmins,cn=Directory\20Integration\20Platform,cn=Products,cn=OracleContext" (read,search,compare,write)
해석: INVALID ACI는 문법·대상·주체 등을 확인해야 합니다. \20은 공백 표현 예시이며 내부 공백을 모두 이렇게 바꿔야 한다는 뜻은 아닙니다. 예제의 전체 속성 write/proxy를 최소 권한으로 인증하지 않습니다.
적용 확인
ldapsearch -h <OID_HOST> -p 389 -D "cn=orcladmin" -w '<PW>' \ -b "<대상_컨테이너_DN>" -s base "(objectClass=*)" orclACI
해석: 출력에 group DN과 (browse,proxy), (read,search,compare,write)가 보이는 것만으로 유효 권한이나 성공을 판정할 수 없습니다. 작업별 권한과 상속·그룹 관계를 확인합니다.
4) DIT 구조 정비 + 역LDIF(롤백)
용도
누락된 ou=yourdomain.com 같은 레벨을 보강하고, 레거시 서브트리를 표준 경로로 정렬.
목적
DIP DomainRules와 물리 경로 일치 → 신규/변경 정확히 반영.
해석 방법
이동 전/후 DN 매핑표(건수·샘플DN)로 검증. 역LDIF는 검토 자료이며, 의존 참조·현재 상태·동시 변경 때문에 즉시 복구를 보장하지 않습니다.
누락 OU 생성
dn: ou=yourdomain.com,cn=Users,dc=serv,dc=nossys,dc=net objectClass: top objectClass: organizationalUnit ou: yourdomain.com
서브트리 이동 (modrdn)
dn: ou=CLGX,cn=Users,dc=serv,dc=nossys,dc=net changetype: modrdn newrdn: ou=CLGX deleteoldrdn: 0 newsuperior: ou=yourdomain.com,cn=Users,dc=serv,dc=nossys,dc=net
역LDIF 예시 (적용 조건 검증 필요)
dn: ou=CLGX,ou=yourdomain.com,cn=Users,dc=serv,dc=nossys,dc=net changetype: modrdn newrdn: ou=CLGX deleteoldrdn: 0 newsuperior: cn=Users,dc=serv,dc=nossys,dc=net
5) DIP DomainRules & 매핑 반영 (사전체크 포함)
용도
AD 도메인 베이스를 OID의 정확한 컨테이너로 매핑.
목적
예시 경로 ou=yourdomain.com → ou=CLGX와 실제 필터·DomainRules·속성 매핑·대상 부모를 함께 대조합니다.
해석 방법
validateMapRules는 문법, testProfile은 실제 동기화 영향을 확인한 뒤 사용하는 테스트입니다. 두 결과만으로 전체 경로·데이터 정합성을 판정하지 않습니다.
도메인 매핑(예시)
# dc=infosolco,dc=net → ou=yourdomain.com,cn=Users,... DomainRules: dc=infosolco,dc=net : ou=yourdomain.com,cn=Users,dc=serv,dc=nossys,dc=net
업로드 전 사전체크
manageSyncProfiles validateMapRules -p <ProfileName> manageSyncProfiles testProfile -p <ProfileName>
해석: 오류 메시지·인자·프로파일을 확인합니다. 공백·탭뿐 아니라 버전·매핑·접속·권한을 구분합니다.
6) LACN ↔ AD USN 정합 (Go/No-Go 게이트)
용도
체크포인트가 어느 변경 원본을 가리키는지 확인합니다. 번호 차이를 지연 시간이나 누락 건수로 환산하지 않습니다.
목적
중복/누락 없이 안전 회수를 위해 증분 범위 명확화.
해석 방법
같은 AD DC·invocationID 기준인지 확인합니다. 청크 단위라도 안전한 rewind를 보장하지 않으며, 임의로 체크포인트를 낮추지 않습니다.
양쪽 수치 확인
# AD high watermark repadmin /showrepl <DC-NAME> # OID Profile 메트릭 ldapsearch -D "cn=orcladmin" -w '<PW>' \ -b "orclodipagentname=<Profile>,cn=ODIP Agents,cn=Directory Integration Platform,cn=Products,cn=OracleContext" \ -s base "(objectClass=*)" \ orclOdipConDirLastAppliedChgNum orclOdipProfileMetric
해석: failure_count의 정의·시간 범위와 실제 오류를 확인합니다. 증가만으로 구조/권한 문제를 단정하지 않습니다. 기존 repadmin 예제를 rootDSE highestCommittedUSN 조회로 간주하지 않습니다.
체크포인트 변경 예시의 위험 검토
# 큰 폭 조정 금지 → 안전 청크(예: 5,000,000)씩 낮추고 증분 실행/검증 반복 # 변경 전 Profile 백업 필수
7) 실행 순서 & 스모크 (성공/중단 기준 수치화)
용도
운영 반영을 체크리스트로 실행, 결과를 수치로 확인.
목적
감이 아니라 정량 근거로 승인/중단 결정.
해석 방법
failure_count=0, LDAP 50/65/67 없음, LACN 상승, 3건 스모크 T+30분은 예시 조건입니다. Go 판정에는 실제 대상 값·삭제/이동·필터 범위와 합의된 관찰 기간이 필요합니다.
실행 순서(클러스터 동일)
- Disable 대상 프로파일(양 노드 동일)
- DIT 보강/이동 + ACI 반영
- DomainRules/맵 반영 →
validate/testProfile - LACN/USN 원본 기준과 로그·대상 값 확인; rewind는 별도 승인·검증 조건
- 재기동 예시
Admin → Node Manager → OPMN(OID) → wls_ods1/2(DIP)는 설치 구성의 의존성과 운영 절차를 먼저 검증 - Enable + 수동 1회 증분 실행
스모크(즉시 3건)
- 신규 사용자 → 표준 OU에 생성
- UPN/mail 변경 → 속성 반영
- Rename(ModifyDN) 또는 부모 이동 → 성공
성공/중단 기준 (해석)
failure_count = 0유지는 보조 지표; 카운터 범위와 실제 대상 값·로그 대조 필요- LDAP
50/65/67부재만으로 성공 판정 불가; 실제 요청 실행과 대상 DN·속성 결과 확인 - LACN이 AD high watermark 방향으로 지속 상승만으로 누락 회수나 데이터 정합성을 증명하지 못함
- 3건 스모크 T+30분 내는 예시이며, 모든 대상 범위·삭제 처리·관찰 기간을 별도로 검증
중단 및 복구 예시 (별도 검증 필요)
# 롤백 단위 요약 1) 프로파일/맵: 이전 버전 복구 2) ACI: 이전 값 복구 3) DIT: 역LDIF(modrdn reverse) 적용 4) 서비스: 필요 시 WLS/OID 재기동 5) DB/시스템(최후): RMAN/Datapump 또는 스냅샷 복원
8) 모니터링 & EM Agent (TZ 정합)
용도
EM 콘솔 상태 그린 확보, 알람/스케줄 가시성 정상화.
목적
초동대응 시간을 줄이기 위한 관측성 확보.
해석 방법
시각 불일치가 시간대·표시·시계 중 어디에서 발생하는지 확인합니다. resetTZ/secure/restart는 버전·등록·신뢰 영향을 검증할 운영 작업이며 보편적인 해결책이 아닙니다.
# 시간대 정합 emctl resetTZ agent # 상태/보안 재확립(환경별 상이) emctl stop agent emctl secure agent emctl start agent
해석: DIP 동작엔 직접 영향이 없을 수도 있으나, 운영 의사결정(알람/타임라인)에 중요 — 정합화 권장.
9) 바로 쓰는 검사표 (체크리스트)
| 항목 | 내용 | 상태 |
|---|---|---|
| 스키마 | orclADUser/Group/Object 존재 | ☐ |
| SSL/TLS | 실제 DIP→OID 리스너·모드·신뢰 확인; 4141/SSL_ENCRYPT는 예시 | ☐ |
| 프로파일 | validateMapRules 인자·결과 확인; testProfile 실제 동기화 영향 검증 | ☐ |
| ACI | 작업별 RDN/부모 유효 권한 확인; proxy는 별도 조건, 최소 권한 검토 | ☐ |
| DIT | 누락 OU 생성, 이동 전/후 매핑표·역LDIF 준비 | ☐ |
| LACN/USN | 동일 원본/DC 기준 및 실제 대상 비교; 임의 rewind 금지 | ☐ |
| EM Agent | TZ 정합 및 상태 그린 | ☐ |
| 스모크 | 신규/속성/이동·삭제 결과 확인; T+30분은 환경별 예시 | ☐ |
* 표를 복사해 팀 공용 체크리스트로 쓰세요.