OAM과 OID를 함께 사용하는 환경에서는 비밀번호 정책을 어느 구성 요소가 적용하는지부터 확인해야 합니다. 이 글의 기존 설정·명령 예시는 제품 세대와 스키마가 섞여 있어 그대로 실행할 수 있는 절차가 아닙니다. 설치된 OAM·OID 버전, 인증 모듈과 Identity Store 설정을 대조하고, 변경·잠금 해제·삭제 예제는 비운영 환경에서 별도로 검증하세요.
시스템 아키텍처의 역사적 맥락과 현재
OAM·OID의 비밀번호 정책을 검토할 때는 제품 버전과 사용하는 스키마를 구분합니다. Oracle의 레거시 스키마 문서와 OAM 12c Password Management 문서를 하나의 동작 방식으로 합쳐 해석하면 안 됩니다.
설정 화면이나 LDAP 속성 하나만으로 실제 정책 적용 경로를 단정하지 않습니다. Identity Store 설정, 인증 모듈과 로그인 결과를 함께 확인해야 합니다.
OID 정책·OAM Password Management·Oblix 스키마 구분
아래에서는 OID의 디렉터리 정책, OAM Password Management 설정과 Oblix 스키마 항목을 구분합니다. 세 항목이 각각 독립된 시스템으로 동시에 동작한다고 가정하지 마세요.
1. OID의 디렉터리 비밀번호 정책
OID의 orclPwdPolicyEnable=0은 해당 정책을 비활성화합니다. Fine-Grained Password Policies에서는 대상 엔트리와 상위 엔트리의 pwdPolicySubentry를 확인해 적용 정책을 찾아야 합니다. OID 그룹에 정책을 연결하는 것만으로 그 구성원에게 자동 적용되지는 않으며, OAM의 그룹 기반 정책 할당과도 다른 방식입니다. 이 설정만으로 다른 인증 경로의 보안 상태까지 판단하지 않습니다.
- 대상 엔트리에 적용되는 OID 정책과 활성 상태 확인
- pwdAccountLockedTime 등 상태값을 적용 정책·바인드 결과와 대조
- OID 비밀번호 변경·바인드 경로에서 해당 정책이 검사되는지 확인
2. OAM의 Password Management
OAM의 Password Management는 Identity Store에서 활성화 여부와 스키마 선택을 확인합니다. 이를 생체인식 기능으로 설명하거나 Adaptive Authentication 설정과 같은 기능으로 묶어 판단하지 않습니다.
- Enable Password Management: 해당 Identity Store의 Password Management 활성화 여부
- Adaptive Authentication Service: 비밀번호 정책 활성화 여부와 구분해서 확인할 항목
OAM 12c에서는 Password Management 설정과 인증 모듈을 함께 확인합니다. 화면의 비활성 표시만으로 다른 인증 경로의 보안 상태까지 판단할 수는 없습니다.
3. Oblix 스키마와 사용자 상태값
Oblix 스키마 항목이 남아 있다면 해당 제품 세대와 사용하는 인증 경로를 확인합니다. 속성 존재나 다른 기능의 비활성 표시가 전체 보안이 유지된다는 증거는 아닙니다.
- oblixPersonPwdPolicy: 사용자에 부가되는 런타임 비밀번호 정책용 보조 object class
- oblogintrycount: 로그인 시도 횟수 관련 값
- oblockouttime: 계정 잠금 시각·기간 처리와 관련된 값
스키마 항목의 존재와 현재 정책 적용 여부는 별개입니다. 실제 값을 갱신하는 구성 요소와 인증 결과를 확인해야 합니다.
📍 Oblix 정책 관리 아키텍처 이해하기
🔍 정책 관리의 핵심 구조
Oracle의 레거시 스키마 문서에서 oblixPersonPwdPolicy는 보조 object class입니다. 이를 정책 DN을 담는 일반 속성으로 읽지 말고, 실제 사용자 객체의 objectClass와 관련 속성을 구분해서 확인하세요.
주요 컴포넌트
- OID (Oracle Internet Directory): LDAP 디렉터리 서비스
- OAM (Oracle Access Manager): 인증 경로와 Password Management 구성 확인 대상
📚 쉬운 비유로 이해하기
디렉터리는 사용자 상태와 관련 스키마 값을 저장하고, 적용 경로의 구성 요소는 그 값을 사용합니다. 저장된 값만으로 정책의 관리 주체나 적용 순서를 확정하지 않습니다.
⚡ 실제 작동 방식
- OAM 버전과 Identity Store의 Password Management 설정 확인
- Oblix 스키마 사용 여부와 사용자 objectClass·관련 속성 확인
- 실제 인증 경로에서 참조·갱신하는 값 확인
- 대상 사용자에게 적용되는 정책과 로그인 결과 대조
⚠️ 중요 사항
정책을 변경하기 전에 해당 제품 버전의 지원 관리 경로와 API를 확인하세요. LDAP 값을 직접 바꾸는 예제는 정책·캐시·잠금 상태에 영향을 줄 수 있으므로 검증된 복구 절차 없이 실행하지 않습니다.
과거 환경 진단 기록과 재검증 항목
다음은 글 작성 당시 남긴 환경 진단 기록입니다. 이번 개정에서 해당 시스템을 재접속하거나 재현한 결과는 아니며, 다른 환경의 적용 경로를 판단하는 근거로 일반화하지 마세요.
1. 과거 기록: OID 정책 설정과 인증 결과
- orclPwdPolicyEnable=0 설정을 통해 명시적으로 비활성화되어 있음
- pwdaccountlockedtime과 같은 기본 LDAP 잠금 속성이 실제 잠금 상태에 영향을 미치지 않음을 확인
- 실제 테스트 결과 OID의 기본 패스워드 정책 규칙이 적용되지 않음
2. 과거 기록: OAM 설정 화면에서 확인한 항목
- Enable Password Management가 체크 해제되어 있음
- Adaptive Authentication Service가 Disabled 상태임
- OAM 콘솔에서 패스워드 정책 관련 설정이 회색으로 표시되어 있어 접근 불가
3. 과거 기록: Oblix 상태값과 로그인 시험
- 기존 기록은 사용자 객체의 Oblix 정책 관련 항목을 확인했다고 서술합니다. oblixPersonPwdPolicy 자체는 보조 object class이므로 속성 조회 예제와 구분해서 다시 검증해야 합니다.
- 로그인 실패 시 oblogintrycount가 실시간으로 증가
- 계정 잠금 시 oblockouttime 값이 정확하게 설정됨
- 실제 로그인 테스트에서 Oblix 정책의 규칙이 정확히 적용됨
위 기록은 당시 환경에 대한 서술입니다. 의도적인 비활성화 여부와 실제 정책 관리 경로를 확정하려면 당시 설정·인증 모듈·로그인 로그를 대조해야 합니다. 현재 시스템에서도 같은 경로가 동작한다고 이 글에서 검증한 것은 아닙니다.
실제 시스템 동작의 이해
다음은 사용자 상태를 읽고 정책 적용 결과를 확인할 때 구분할 항목입니다. 값의 형식과 갱신 주체는 설치 버전의 스키마 문서에서 확인합니다.
사용자 접근 관리의 세부 메커니즘
시도 횟수, 잠금 관련 값과 적용 정책을 서로 구분해서 확인합니다. LDAP 상태값을 로그인 이벤트 전체 기록으로 해석하지 마세요.
1. 접근 시도 기록 (oblogintrycount)
obLoginTryCount는 로그인 시도 횟수 관련 값입니다. 이 값 자체에 시각·원본 주소·전체 시도 내역이 함께 저장되는 것은 아닙니다. 조사할 때는 별도 인증·감사 로그에서 다음 항목을 확인합니다:
- 시도 시각: 인증·감사 로그에서 확인
- 시도 간격과 패턴: 여러 로그 이벤트를 대조
- 접속 원본: 로그가 기록하는 클라이언트 정보 확인
짧은 간격의 반복 실패는 조사 대상이지만 공격 여부를 확정하는 증거는 아닙니다. 자동 재시도, 저장된 이전 비밀번호와 정상 사용자 활동도 함께 확인하세요.
2. 접근 제한 관리 (oblockouttime)
obLockoutTime은 잠금 처리에 쓰이는 시각 관련 값입니다. 제한 이유나 해제 조건이 모두 이 값 안에 들어 있다고 가정하지 말고 정책·로그에서 다음 항목을 따로 확인합니다:
- 잠금 시점: 버전별 값 형식과 관련 로그 대조
- 잠금 원인: 실패 횟수와 인증·감사 로그 확인
- 해제 조건: 적용 정책과 관리 절차 확인
잠금 상태를 조사할 때는 사용자 상태값과 로그를 함께 봅니다. 잠금값 하나만으로 실수와 의심스러운 활동을 구분할 수는 없습니다.
3. 사용자 상태 스키마와 적용 정책의 구분
적용 정책에서 실패 허용 횟수와 잠금 기간을 확인합니다. 사용자·그룹별 할당 지원과 예외 방식은 설치 버전의 문서를 대조하세요.
- 허용되는 실패 횟수: 몇 번의 실패까지 허용할 것인지
- 제한 시간: 접근이 제한되었을 때 얼마나 오래 제한할 것인지
- 예외 조건: 어떤 상황에서 이러한 규칙을 완화할 것인지
운영에 필요한 정책은 지원되는 할당 방식, 실제 인증 결과와 복구 가능성을 기준으로 선택합니다. 특정 레거시 방식이 널리 선호되거나 더 안정적이라고 이 글에서 입증한 것은 아닙니다.
패스워드 정책의 구현과 적용
정책 변경은 지원 기능과 대상 Identity Store를 확인한 뒤 비운영 환경에서 시험합니다. 정책 생성·할당·적용 결과·복구를 각각 검증하고 운영 적용은 별도 변경으로 진행하세요.
첫 번째 단계: 새로운 정책 생성
아래 REST 코드는 수정·검증이 필요한 과거 예제입니다. OAM 12.2.1.4 공식 REST 문서는 /iam/admin/access/api/v1/policy/PasswordPolicies 경로와 AssignmentRule·PasswordPolicyInfo 필드명을 사용합니다. 기존 코드의 경로와 소문자 필드명을 검증된 요청으로 취급하지 마세요. 잠금 필드는 lockOutDuration이며 단위는 분이므로 기존 lockoutDuration·1800을 30분으로 해석할 수 없습니다. 설치 버전의 요청 구조·지원 인증 방식을 대조하고, HTTP나 명령줄 자격 증명 예시를 운영에 그대로 사용하지 마세요.
curl -u weblogic:password -H "Content-Type: application/json" -X POST \ "http://oidhost:14100/oam/services/rest/access/api/v1/policy/PasswordPolicies" \ -d '[ { "assignmentRule": { "idStoreRef": "OID_USER_STORE", "priority": 1, "passwordPolicyID": "special_policy", "ruleType": 2, "ruleValue": "SPECIAL_POLICY_GROUP" }, "passwordPolicyInfo": { "desc": "Special Lockout Policy", "id": "special_policy", "lockoutDuration": 1800, "maxIncorrectAttempts": 5 } } ]'
priority 값의 의미와 영향:
- priority는 적용 가능한 정책 할당을 정렬할 때 사용합니다. 값 1만으로 모든 다른 정책·인증 경로보다 우선한다고 보장하지 않습니다.
- 기본 정책의 우선순위 값이나 숫자의 의미를 임의로 가정하지 말고 설치 버전의 문서와 실제 할당 목록을 확인합니다.
- 잘못 설정했을 때의 위험: 예를 들어, 관리자 그룹의 정책보다 일반 사용자 그룹의 정책이 더 높은 우선순위를 가지게 되어 보안 정책이 의도치 않게 약화될 수 있습니다.
lockoutDuration 설정의 중요성:
- OAM 12.2.1.4의 lockOutDuration 단위는 분입니다. 30분을 표현하려면 해당 버전의 지원 필드·요청 구조를 먼저 확인해야 하며, 기존 1800초 설명과 예제는 검증된 값이 아닙니다.
- 잠금 기간을 줄일 때는 재시도 정책, 자동 로그인과 운영 지원 부담을 함께 검토합니다.
- 잠금 기간을 늘릴 때는 정상 사용자 잠금과 복구 절차에 미치는 영향을 확인합니다.
maxIncorrectAttempts의 설정:
- 실패 허용 횟수 5는 기존 예시입니다. 이를 모든 환경의 업계 표준으로 사용하지 마세요.
- 낮은 실패 임계값은 정상 사용자나 자동 재시도 계정의 잠금을 늘릴 수 있으므로 실제 인증 패턴을 확인합니다.
- 높은 실패 임계값의 영향은 재시도 제한과 다른 인증 통제도 함께 검토합니다.
ruleType과 ruleValue의 관계:
- OAM 12.2.1.4 REST 문서에서 ruleType=2는 그룹 기반 할당입니다. ruleValue는 사용자가 속해야 하는 그룹을 가리키며, 이름만 쓰면 되는지 또는 DN이 필요한지는 해당 Identity Store와 설치 버전에서 검증합니다.
- 그룹과 멤버십을 찾을 수 없으면 의도한 할당이 성립하지 않을 수 있습니다. 오류 응답과 적용 정책을 함께 확인하고, 요청이 조용히 무시된다고 단정하지 않습니다.
다음 숫자 조합은 기존 설정 예시이며 관리자 계정에 검증된 권장값이 아닙니다. 적용 전 할당 우선순위, 임계값과 잠금 시간 단위를 각각 확인하세요:
- priority=1: 해당 버전의 정책 선택 결과 확인 필요
- maxIncorrectAttempts=3: 정상 사용자·자동 재시도 영향 확인 필요
- 기존 lockoutDuration=7200: 필드명·시간 단위·버전 검증 전 사용 금지
두 번째 단계: 생성된 정책 확인
지원되는 조회 방법으로 저장된 정책과 할당을 확인합니다. 생성 응답만으로 실제 사용자에게 적용됐다고 판단하지 않습니다.
curl -u weblogic:password \ "http://oidhost:14100/oam/services/rest/access/api/v1/policy/PasswordPolicies/special_policy"
기존 코드의 ID를 붙인 경로를 검증된 조회 방식으로 사용하지 마세요. OAM 12.2.1.4의 Get Password Policies 문서는 컬렉션 경로와 policyid 쿼리 매개변수를 설명합니다. 버전에 맞는 조회 방법으로 다음 항목을 대조합니다:
- 정책 ID가 올바르게 생성되었는지
- 설정한 값들(잠금 시간, 실패 허용 횟수 등)이 정확히 저장되었는지
- 정책의 우선순위가 의도한 대로 설정되었는지
세 번째 단계: LDAP 그룹 생성
대상 그룹과 Identity Store를 확인합니다. 아래 LDAP 그룹 생성 예제는 DN·스키마·필수 멤버와 안전한 인증 경로를 검증한 뒤에만 별도로 검토하세요.
# 새로운 그룹 생성을 위한 LDIF 파일 생성 (create_group.ldif) cat > create_group.ldif << 'EOF' dn: cn=SPECIAL_POLICY_GROUP,cn=Groups,dc=example,dc=com objectclass: top objectclass: groupOfUniqueNames cn: SPECIAL_POLICY_GROUP description: Group for special password policy uniquemember: cn=dummy EOF # LDIF 파일을 사용하여 그룹 생성 ldapadd -h hostname -p port -D "cn=orcladmin" -w password -f create_group.ldif
네 번째 단계: 사용자를 그룹에 추가
사용자와 그룹 DN, 현재 멤버십과 복구 방법을 확인합니다. 아래 LDAP 변경 예제를 검증 없이 실행하지 마세요.
# 사용자 추가를 위한 LDIF 파일 생성 (add_user.ldif) cat > add_user.ldif << 'EOF' dn: cn=SPECIAL_POLICY_GROUP,cn=Groups,dc=example,dc=com changetype: modify add: uniquemember uniquemember: cn=targetuser,cn=Users,dc=example,dc=com - EOF # LDIF 파일을 사용하여 사용자 추가 ldapmodify -h hostname -p port -D "cn=orcladmin" -w password -f add_user.ldif
다섯 번째 단계: 정책 적용 확인
실제 할당과 인증 결과를 확인합니다. 아래 objectClass 조회는 사용자 엔트리의 클래스 목록을 확인하는 예제입니다. oblixPersonPwdPolicy가 포함되어 있어도 실제 적용 정책이나 인증 결과를 입증하지는 않습니다. 설치 버전의 스키마와 안전한 조회 경로를 먼저 확인하세요.
# 사용자 object class 확인 (실제 적용 정책의 증거는 아님) ldapsearch -h hostname -p port -D "cn=orcladmin" -w password \ -b "cn=targetuser,cn=Users,dc=example,dc=com" \ "(objectClass=*)" objectClass # 잠금 상태 확인 ldapsearch -h hostname -p port -D "cn=orcladmin" -w password \ -b "cn=targetuser,cn=Users,dc=example,dc=com" \ "(objectClass=*)" oblogintrycount oblockouttime
여섯 번째 단계: 정책 작동 테스트
설정이 완료된 후에는 실제로 정책이 의도한 대로 작동하는지 테스트해야 합니다:
- 로그인 실패 테스트
- 실패 카운터 확인
- 잠금 상태 확인
- 잠금 해제 시간 검증
생성·할당·인증 결과와 복구가 각각 검증돼야 합니다. 명령 응답이나 LDAP 값만으로 운영 환경에 안전하게 구현됐다고 결론 내리지 않습니다.
패스워드 정책의 적용 메커니즘과 시스템 영향
정책 선택은 설치 버전의 지원 기능, Identity Store와 인증 모듈에 따라 확인합니다. 다음 설명을 모든 OAM·OID 세대에 공통인 우선순위로 사용하지 마세요.
정책 적용의 계층 구조
OAM 12c의 Multiple Password Policies 문서는 Identity Store·그룹 수준의 할당과 우선순위 정렬을 설명합니다. 레거시 사용자 스키마와 다른 세대의 선택 규칙을 혼합하지 않습니다.
사용자에게 별도 정책이 적용되는지는 해당 버전의 지원 할당 방식과 실제 선택 결과로 확인합니다. oblixPersonPwdPolicy object class만으로 사용자 직접 할당의 절대 우선순위를 입증할 수는 없습니다.
여러 그룹에 속한 사용자는 Identity Store의 정책 할당 목록과 우선순위를 대조합니다. 적용 가능한 정책 중 어떤 것이 선택됐는지 비운영 로그인 시험에서 확인하세요.
특정 정책이 적용되지 않는 경우의 기본 정책은 해당 버전의 문서와 실제 설정을 확인합니다.
정책 충돌과 해결 메커니즘
여러 할당이 겹치면 적용 가능한 정책과 우선순위를 확인합니다. 아래의 절대 우선순위·동점 처리·항상 가장 제한적인 정책이라는 표현은 검증된 공통 규칙이 아닙니다.
우선순위 규칙의 작동 방식은 다음과 같습니다:
1. 사용자 직접 할당 여부와 우선순위는 버전별 지원 기능으로 확인합니다. 모든 다른 정책보다 무조건 우선한다고 가정하지 않습니다.
2. 그룹 정책의 경우, priority 값을 비교합니다:
- 공식 문서는 할당을 priority로 정렬해 첫 번째 적용 가능한 정책을 선택한다고 설명합니다. 여기서 대조한 문서만으로 숫자 1과 5의 우선 방향까지 확정하지 않으며, 설치 버전과 실제 선택 결과를 확인합니다.
- 같은 우선순위의 동점 처리 규칙은 공식 근거와 비운영 시험으로 확인해야 하며, 정책 ID 크기로 단정하지 않습니다.
- 복수 그룹에서 항상 가장 제한적인 정책이 선택된다고 가정하지 말고 실제 선택 결과를 확인합니다.
3. 어떤 정책도 적용되지 않을 때만 기본 정책이 사용됩니다.
정책 변경의 반영 시점 확인
OAM 12.2.1.4의 Multiple Password Policies 문서는 설정 변경 후 60초를 기다리도록 안내합니다. 이는 모든 잠금 해제나 인증 경로의 반영 시간을 보장하는 값은 아닙니다. 다음 변경 항목은 각각 관리 경로, 캐시 반영과 인증 결과를 확인하세요.
관리 경로와 반영 결과를 확인할 변경사항:
- 잠금 해제: 관리자가 수동으로 계정 잠금을 해제할 때
- 정책 할당 변경: 사용자나 그룹에 새로운 정책을 할당할 때
- 우선순위 변경: 정책의 priority 값을 수정할 때
반영을 기다린 뒤 적용 정책과 인증 결과를 대조할 항목:
- 실패 허용 횟수 변경: maxIncorrectAttempts 값 수정
- 잠금 지속 시간 변경: 설치 버전의 지원 필드와 단위 확인
- 정책 활성화/비활성화: 전체 정책의 활성 상태 변경
반영 시점과 실제 인증 결과를 함께 확인합니다. 잠금 해제·할당·임계값 변경은 설치 버전에서 지원되는 관리 방식과 비운영 시험을 기준으로 검증하세요.
정책 모니터링과 관리 방안
정책 적용 후에는 잠금 빈도, 정상 사용자 영향과 복구 결과를 지속적으로 확인합니다.
정책 작동 상태 모니터링
아래 LDAP 조회는 사용자 상태값을 읽는 기존 예제입니다. 스키마와 속성 종류를 확인하고 인증·감사 로그를 함께 대조하세요. 상태값만으로 정책 전체가 정상 동작한다고 판단하지 않습니다.
# 사용자의 현재 상태 확인 ldapsearch -h hostname -p port -D "cn=orcladmin" -w password \ -b "cn=targetuser,cn=Users,dc=example,dc=com" \ "(objectClass=*)" oblogintrycount oblockouttime objectClass
이 명령어를 통해 확인할 수 있는 중요한 정보들은 다음과 같습니다:
oblogintrycount 값의 분석:
- 0: 이 값에 기록된 시도 횟수가 0이며 전체 인증 경로의 정상 상태를 보장하지 않음
- 1–4: 기존 예시 범위이며 실제 임계값·초기화 조건과 대조 필요
- 5 이상: 적용 임계값과 로그를 확인할 조사 대상이며 공격 여부를 단정하지 않음
oblockouttime 값의 해석:
- 값 없음: 이 속성에 잠금 시각이 없으며 다른 잠금 경로도 확인 필요
- 시간값 존재: 버전별 형식과 잠금 기간의 해석을 확인
- 과거 시간값: 값만으로 잠금 해제 완료를 단정하지 말고 인증 결과와 대조
비정상 패턴 감지와 대응
비정상 패턴은 인증·감사 로그를 대조해 조사합니다. 아래 상자는 조사 항목을 정리한 주석이며 실행 명령이 아닙니다. 단순 LDAP 상태 조회로 최근 10분의 전체 로그인 이력이나 업무 시간 외 이벤트를 얻을 수 없습니다. 실제 로그 형식과 시간대, 대상 사용자를 확인한 뒤 별도 조회 절차를 준비하세요.
1. 빠른 연속 실패:
# 최근 10분의 로그인 패턴은 인증·감사 로그에서 확인합니다. # LDAP의 obLockoutTime 값은 전체 로그인 이벤트 이력이 아닙니다. # 기준 시각·시간대·사용자·성공/실패 이벤트를 대조하세요. # 현재시간-600은 LDAP 필터에서 계산되는 식이 아닙니다.
2. 특정 시간대의 비정상적인 활동:
# 업무 시간 외 로그인은 인증·감사 로그에서 확인합니다. # 업무 시간·사용자 시간대·휴일·로그 시간대를 먼저 정합니다. # 해당 범위 밖의 이벤트를 정상 활동과 대조하세요. # timeStamp>=업무시간외는 검증된 LDAP 감사 조회식이 아닙니다.
정책 유지보수와 조정
정책 조정은 변경 전 값과 복구 경로를 확보한 뒤 비운영 환경에서 시험합니다. 아래 REST 수정 예제도 필드명·시간 단위·요청 구조를 설치 버전에 맞게 검증하기 전에는 실행하지 않습니다.
# 정책 설정 수정 curl -u weblogic:password -H "Content-Type: application/json" -X PUT \ "http://oidhost:14100/oam/services/rest/access/api/v1/policy/PasswordPolicies/special_policy" \ -d '{ "passwordPolicyInfo": { "id": "special_policy", "lockoutDuration": 3600, "maxIncorrectAttempts": 3 }}'
변경을 수행할 때는 반드시 변경 사항을 문서화하고, 변경 후 영향을 모니터링해야 합니다. 특히 다음 사항들을 주의 깊게 관찰해야 합니다:
- 잠금 빈도의 변화
- 사용자 불만 사항 접수 빈도
- 보안 이벤트 발생 빈도
또한, 정기적으로 다음과 같은 검토를 수행하는 것이 좋습니다:
- 현재 적용된 모든 특별 정책 목록 확인
- 각 정책의 필요성 재검토
- 정책 적용 대상 그룹의 적절성 평가
- 보안 요구사항과 사용자 편의성의 균형 재평가
문제 해결과 롤백 방법
정책 적용 후 문제가 발생할 경우를 대비하여, 다음과 같은 복구 절차를 준비해야 합니다:
1. 잠금 해제
아래 잠금 해제 예제는 shell 입력·LDIF 전달 형식과 속성 의미를 다시 검증해야 합니다. 지원되는 관리 절차와 복구 경로 없이 그대로 실행하지 마세요.
ldapmodify -h hostname -p port -D "cn=orcladmin" -w password <dn: cn=targetuser,cn=Users,dc=example,dc=com changetype: modify replace: oblogintrycount oblogintrycount: 0 - replace: oblockouttime oblockouttime: 0 EOF
2. 기본 정책으로 복귀
그룹에서 사용자 제거와 정책 삭제는 서로 다른 변경입니다. 아래 예제는 LDIF 전달 형식·정책 참조·공유 영향·복구 방법을 먼저 검증해야 하며 운영에 그대로 실행하지 않습니다.
# 사용자를 특별 정책 그룹에서 제거 ldapmodify -h hostname -p port -D "cn=orcladmin" -w password <dn: cn=SPECIAL_POLICY_GROUP,cn=Groups,dc=example,dc=com changetype: modify delete: uniquemember uniquemember: cn=targetuser,cn=Users,dc=example,dc=com EOF # 특별 정책 삭제 curl -u weblogic:password -X DELETE \ "http://oidhost:14100/oam/services/rest/access/api/v1/policy/PasswordPolicies/special_policy"
결론
OAM·OID의 비밀번호 정책을 검토할 때는 설치 버전, 인증 모듈, Identity Store와 실제 적용 정책을 구분하세요. 이 글의 과거 환경 기록은 현재 환경의 증거가 아니며, 기존 변경·잠금 해제·삭제 예제는 별도 비운영 검증 전에는 사용하지 않습니다.