Perfect Oracle OAM 사용자별 패스워드 정책 관리 [Ultimate Guide 2024]

Table of Contents

엔터프라이즈 환경에서의 패스워드 정책 관리는 겉으로 보기에 단순해 보이지만, 실제로는 여러 층의 복잡성으로 상당히 도전적인 과제에 해당 합니다. 특히 Oracle Access Manager(OAM)와 Oracle Internet Directory(OID)가 함께 사용되는 환경에서는 패스워드 정책의 동작 방식을 정확히 이해하는 것이 매우 중요합니다. 이 글에서는 특정 사용자에 대한 패스워드 정책 예외 처리를 다루면서, 시스템의 내부 동작 원리와 실제 구현 방법을 상세히 살펴보겠습니다.

시스템 아키텍처의 역사적 맥락과 현재

현재 OAM 환경의 패스워드 정책 관리 시스템을 이해하기 위해서는 먼저 그 역사적 맥락을 이해해야 합니다. Oracle이 Oblix를 인수하면서 두 회사의 기술이 통합되었고, 이로 인해 현재 시스템에는 세 가지 서로 다른 패스워드 정책 관리 메커니즘이 공존하게 되었습니다. 이는 마치 한 자동차에 세 가지 다른 제동 시스템이 설치된 것과 같은 상황입니다.

이러한 복잡한 구조는 때로는 혼란을 가져올 수 있지만, 각 메커니즘의 역할과 상호작용을 이해한다면 오히려 더 유연하고 강력한 정책 관리가 가능해집니다. 특히 최근의 분석 결과, 대부분의 시스템에서는 이 세 가지 메커니즘 중 실제로는 하나만이 주도적으로 사용되고 있다는 점이 밝혀졌습니다.

시스템 아키텍처의 이해: 다층 보안 시스템

현재 OAM 환경의 패스워드 정책 관리 시스템을 이해하기 위해, 대규모 기업 건물의 보안 시스템에 비유해보면 좋을 것 같습니다. 오랜 시간에 걸쳐 여러 보안 시스템이 도입되면서, 현재는 세 가지 서로 다른 보안 메커니즘이 공존하게 되었습니다.

1. OID의 기본 패스워드 정책: 기본 키카드 시스템

이는 마치 건물의 기본적인 키카드 출입 통제 시스템과 같습니다. orclPwdPolicyEnable 속성은 이 시스템의 마스터 스위치와 같은 역할을 합니다. 현재 환경에서 이 값이 0으로 설정되어 있다는 것은, 마치 키카드 리더기가 설치되어 있지만 전원이 꺼져 있는 것과 같은 상태입니다. 결과적으로:

LDAP 기본 패스워드 정책이 작동하지 않음
pwdaccountlockedtime과 같은 기본 잠금 메커니즘이 비활성화됨
OID 레벨의 패스워드 복잡성 검사가 수행되지 않음

2. OAM의 최신 패스워드 관리: 생체인식 보안 시스템

이는 최신 생체인식 보안 시스템에 비유할 수 있습니다. 지문, 홍채, 얼굴 인식 등 다양한 첨단 기술을 활용할 수 있지만, 현재는 두 가지 핵심 설정이 모두 비활성화되어 있습니다:

Enable Password Management: 생체인식 시스템의 전원 스위치와 같은 역할
Adaptive Authentication Service: 상황에 따라 보안 수준을 자동으로 조절하는 지능형 기능

이는 마치 최첨단 보안 시스템을 설치해놓고도 사용하지 않는 상황과 같습니다. 기술적으로는 가장 발전된 시스템이지만, 실제로는 그 기능을 활용하지 못하고 있는 것입니다.

3. Oblix 레거시 시스템: 전통적인 보안 데스크 시스템

여기가 현재 시스템의 가장 흥미로운 부분입니다. 앞의 두 시스템이 비활성화되어 있음에도 불구하고, 보안은 완벽하게 유지되고 있습니다. 이는 마치 오랜 기간 신뢰성이 검증된 전통적인 보안 데스크 시스템과 같습니다:

oblixPersonPwdPolicy: 보안 담당자의 방문자 확인 절차와 같은 역할
oblogintrycount: 방문 시도 기록을 세심하게 관리하는 역할
oblockouttime: 특정 방문자의 출입 제한 시간을 관리하는 역할

이 시스템이 여전히 주력으로 사용되는 이유는 그 신뢰성과 세밀한 통제 능력 때문입니다. 마치 경험 많은 보안 요원이 직접 방문자를 확인하고 기록하는 것처럼, 각 사용자의 접근을 세밀하게 관리할 수 있습니다.

📍 Oblix 정책 관리 아키텍처 이해하기

🔍 정책 관리의 핵심 구조

oblixPersonPwdPolicy는 Oracle Access Manager(OAM)에서 관리되는 정책입니다. 이를 이해하기 위해서는 Oracle의 ID 관리 시스템의 계층 구조를 살펴볼 필요가 있습니다.

주요 컴포넌트

OID (Oracle Internet Directory): 디렉토리 서비스, 데이터베이스 역할
OAM (Oracle Access Manager): 정책 관리 및 정의

📚 쉬운 비유로 이해하기

이는 마치 도서관(OID)에 책(정책)이 보관되어 있지만, 그 책의 내용을 결정하고 수정하는 것은 출판사(OAM)와 같은 원리입니다.

⚡ 실제 작동 방식

OAM에서 패스워드 정책을 생성하고 관리
정책은 OID에 저장되며, oblixPersonPwdPolicy 속성으로 참조
로그인 시도 시 사용자의 oblixPersonPwdPolicy 속성 확인
해당 정책에 따라 패스워드 규칙 적용

⚠️ 중요 사항

패스워드 정책 수정은 반드시 OAM 관리 콘솔이나 OAM의 REST API를 통해 작업해야 합니다. OID에서 직접 수정하는 것은 권장되지 않습니다.

시스템 현재 상태 진단

현재 시스템에서 실제로 패스워드 정책을 관리하는 것이 Oblix 레거시 시스템이라고 판단한 근거는 다음과 같습니다:

1. OID 기본 정책이 비활성화된 근거:

orclPwdPolicyEnable=0 설정을 통해 명시적으로 비활성화되어 있음
pwdaccountlockedtime과 같은 기본 LDAP 잠금 속성이 실제 잠금 상태에 영향을 미치지 않음을 확인
실제 테스트 결과 OID의 기본 패스워드 정책 규칙이 적용되지 않음

2. OAM 현대적 패스워드 관리가 비활성화된 근거:

Enable Password Management가 체크 해제되어 있음
Adaptive Authentication Service가 Disabled 상태임
OAM 콘솔에서 패스워드 정책 관련 설정이 회색으로 표시되어 있어 접근 불가

3. Oblix 시스템이 실제 작동 중임을 보여주는 증거:

사용자 계정 조회 시 oblixPersonPwdPolicy 속성이 존재하고 유효한 값을 가짐
로그인 실패 시 oblogintrycount가 실시간으로 증가
계정 잠금 시 oblockouttime 값이 정확하게 설정됨
실제 로그인 테스트에서 Oblix 정책의 규칙이 정확히 적용됨

이상과 같은 진단을 통해, 현재 시스템에서는 Oblix 레거시 시스템만이 실제로 패스워드 정책을 관리하고 있으며, 다른 두 메커니즘은 의도적으로 비활성화된 상태임을 확인할 수 있었습니다.

실제 시스템 동작의 이해

이제 Oblix 시스템이 실제로 어떻게 작동하는지 더 자세히 살펴보겠습니다. 앞서 보안 데스크 시스템에 비유했듯이, 이 시스템은 매우 체계적이고 세밀한 방식으로 접근을 관리합니다.

사용자 접근 관리의 세부 메커니즘

보안 데스크에서 방문자의 출입을 관리하는 것처럼, Oblix 시스템은 여러 단계에 걸쳐 사용자의 접근을 확인하고 기록합니다. 이 과정은 다음과 같이 이루어집니다:

1. 접근 시도 기록 (oblogintrycount)

이는 마치 보안 데스크에서 방문자의 출입 시도를 기록하는 로그북과 같습니다. 단순히 횟수만 기록하는 것이 아니라, 각 시도에 대한 중요한 정보를 모두 저장합니다:

시도 시간: 언제 접근을 시도했는지
접근 패턴: 얼마나 자주, 어떤 간격으로 시도했는지
출처 정보: 어디서 접근을 시도했는지

예를 들어, 정상적인 사용자는 보통 근무 시간에 회사 네트워크에서 접근을 시도하고, 실수로 비밀번호를 잘못 입력했을 때는 어느 정도 시간 간격을 두고 다시 시도합니다. 반면, 자동화된 공격은 매우 짧은 간격으로 연속적인 시도를 하거나, 비정상적인 시간대에 접근을 시도하는 경향이 있습니다.

2. 접근 제한 관리 (oblockouttime)

이는 보안 데스크에서 특정 방문자의 출입을 일시적으로 제한하는 것과 같습니다. 단순한 시간 기록 이상의 정보를 포함합니다:

제한 시작 시점: 언제부터 접근이 제한되었는지
제한 이유: 어떤 행동이 제한의 원인이 되었는지
제한 조건: 어떤 조건이 충족되면 제한이 해제되는지

이러한 정보는 보안 관리에 매우 중요합니다. 예를 들어, 단순한 실수로 인한 잠금인지, 의심스러운 활동으로 인한 잠금인지를 구분할 수 있게 해줍니다.

3. 정책 적용 (oblixPersonPwdPolicy)

이는 보안 데스크의 출입 규정과 같은 역할을 합니다. 각 사용자나 그룹에 대해 다음과 같은 세부 규칙을 정의할 수 있습니다:

허용되는 실패 횟수: 몇 번의 실패까지 허용할 것인지
제한 시간: 접근이 제한되었을 때 얼마나 오래 제한할 것인지
예외 조건: 어떤 상황에서 이러한 규칙을 완화할 것인지

이러한 세부적인 통제가 가능하기 때문에, 현재도 많은 기업들이 이 시스템을 선호하고 있습니다. 최신 시스템이 제공하는 화려한 기능들보다, 검증된 안정성과 세밀한 통제 능력이 더 중요하기 때문입니다.

패스워드 정책의 구현과 적용

특별한 패스워드 정책을 실제로 구현하고 적용하는 과정은 여러 단계를 거쳐야 합니다. 마치 건물에 새로운 보안 규정을 도입할 때, 규정을 만들고, 문서화하고, 해당 규정이 적용될 그룹을 지정하고, 실제로 잘 작동하는지 확인하는 것과 같습니다. 각 단계를 자세히 살펴보겠습니다.

첫 번째 단계: 새로운 정책 생성

먼저 OAM의 REST API를 사용하여 새로운 패스워드 정책을 생성합니다. 이 단계에서 설정하는 각 값은 정책의 동작에 중요한 영향을 미치므로, 그 의미와 영향을 자세히 이해하는 것이 중요합니다:

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 값의 의미와 영향:

값이 1인 경우: 시스템의 모든 다른 정책보다 우선 적용됩니다. 이는 특별히 중요한 예외 정책을 만들 때 사용하지만, 신중하게 사용해야 합니다. 너무 많은 정책에 priority 1을 부여하면 정책 간 우선순위가 모호해질 수 있습니다.
값이 10 이상인 경우: 기본 정책(일반적으로 priority가 100)보다는 우선하지만, 다른 특별 정책들과의 관계를 고려해야 합니다.
잘못 설정했을 때의 위험: 예를 들어, 관리자 그룹의 정책보다 일반 사용자 그룹의 정책이 더 높은 우선순위를 가지게 되어 보안 정책이 의도치 않게 약화될 수 있습니다.

lockoutDuration 설정의 중요성:

1800초(30분)로 설정: 일반적인 업무 환경에 적합한 값으로, 보안과 사용자 편의성의 균형을 고려한 설정입니다.
더 짧게 설정(예: 600초): 빈번한 접근이 필요한 운영 계정에 적합하지만, 보안성이 다소 약화될 수 있습니다.
더 길게 설정(예: 7200초): 높은 보안이 필요한 관리자 계정에 적합하지만, 업무 지연이 발생할 수 있습니다.

maxIncorrectAttempts의 설정:

값이 5인 경우: 업계 표준에 부합하는 일반적인 설정입니다.
값이 3 이하인 경우: 보안은 강화되지만, 정상적인 사용자도 자주 잠길 수 있습니다.
값이 10 이상인 경우: 사용자 편의성은 높아지지만, 무차별 대입 공격에 취약해질 수 있습니다.

ruleType과 ruleValue의 관계:

ruleType이 2일 때: 그룹 기반 정책을 의미하며, ruleValue에는 반드시 유효한 LDAP 그룹 이름이 지정되어야 합니다.
잘못된 설정의 예: ruleType은 2로 설정했지만 ruleValue에 존재하지 않는 그룹을 지정하면, 정책이 아무에게도 적용되지 않는 문제가 발생합니다.

설정들이 실제 시스템에서 어떻게 상호작용하는지 이해하면, 더 효과적인 패스워드 정책을 설계할 수 있습니다. 예를 들어, 중요한 시스템 관리자 계정의 경우:

priority를 1로 설정하여 절대적 우선순위 부여
maxIncorrectAttempts를 3으로 설정하여 보안 강화
lockoutDuration을 7200초로 설정하여 무차별 대입 공격 방지

두 번째 단계: 생성된 정책 확인

정책이 제대로 생성되었는지 확인합니다. 이는 새로 만든 보안 규정이 시스템에 제대로 등록되었는지 검증하는 과정입니다:

curl -u weblogic:password \
"http://oidhost:14100/oam/services/rest/access/api/v1/policy/PasswordPolicies/special_policy"

이 명령어를 통해 다음 사항들을 확인할 수 있습니다:

정책 ID가 올바르게 생성되었는지
설정한 값들(잠금 시간, 실패 허용 횟수 등)이 정확히 저장되었는지
정책의 우선순위가 의도한 대로 설정되었는지

세 번째 단계: LDAP 그룹 생성

정책을 적용할 대상 그룹을 LDAP에 생성합니다. 이는 마치 새로운 보안 규정이 적용될 특별 출입 그룹을 만드는 것과 같습니다:

# 새로운 그룹 생성을 위한 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

네 번째 단계: 사용자를 그룹에 추가

특별 정책을 적용할 사용자를 새로 만든 그룹에 추가합니다:

# 사용자 추가를 위한 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

다섯 번째 단계: 정책 적용 확인

모든 설정이 완료된 후, 정책이 실제로 의도한 대로 적용되었는지 확인합니다:

# 사용자의 정책 확인
ldapsearch -h hostname -p port -D "cn=orcladmin" -w password \
-b "cn=targetuser,cn=Users,dc=example,dc=com" \
"(objectClass=*)" oblixPersonPwdPolicy

# 잠금 상태 확인
ldapsearch -h hostname -p port -D "cn=orcladmin" -w password \
-b "cn=targetuser,cn=Users,dc=example,dc=com" \
"(objectClass=*)" oblogintrycount oblockouttime

여섯 번째 단계: 정책 작동 테스트

설정이 완료된 후에는 실제로 정책이 의도한 대로 작동하는지 테스트해야 합니다:

로그인 실패 테스트
실패 카운터 확인
잠금 상태 확인
잠금 해제 시간 검증

이러한 모든 단계가 성공적으로 완료되면, 새로운 패스워드 정책이 시스템에 완전히 구현된 것입니다.

패스워드 정책의 적용 메커니즘과 시스템 영향

패스워드 정책이 실제로 어떻게 적용되고 시스템 전반에 어떤 영향을 미치는지 이해하는 것은 매우 중요합니다. 이는 마치 건물의 보안 규정이 실제 출입 통제에 어떻게 반영되는지 이해하는 것과 같습니다.

정책 적용의 계층 구조

OAM과 OID가 통합된 환경에서 패스워드 정책은 계층적으로 적용됩니다. 이 구조를 이해하면 여러 정책이 동시에 존재할 때 어떤 정책이 우선적으로 적용될지 예측할 수 있습니다.

최상위 레벨에서는 개별 사용자에게 직접 할당된 정책이 있습니다. 이는 마치 VIP 출입 카드와 같아서, 다른 모든 규정보다 우선합니다. 사용자 객체의 oblixPersonPwdPolicy 속성을 통해 직접 지정된 이 정책은 가장 높은 우선순위를 가집니다.

중간 레벨에서는 그룹 기반 정책이 작동합니다. 한 사용자가 여러 그룹에 속해 있을 수 있기 때문에, 이 레벨에서는 정책 간의 우선순위가 중요해집니다. 예를 들어, 한 사용자가 ‘관리자 그룹’과 ‘일반 사용자 그룹’ 모두에 속해 있다면, 더 높은 우선순위(더 낮은 priority 값)를 가진 정책이 적용됩니다.

마지막으로, 기본 정책이 있습니다. 이는 위의 어떤 정책도 적용되지 않는 사용자에게 적용되는 최후의 보안망입니다. 모든 시스템은 반드시 하나의 기본 정책을 가지고 있어야 합니다.

정책 충돌과 해결 메커니즘

여러 정책이 중첩될 때, 시스템은 정교한 규칙에 따라 충돌을 해결합니다. 이 과정은 마치 한 사람이 여러 개의 출입 카드를 가지고 있을 때, 어떤 출입 권한이 적용될지 결정하는 것과 같습니다.

우선순위 규칙의 작동 방식은 다음과 같습니다:

1. 개별 사용자 정책이 있다면 무조건 이 정책이 적용됩니다. 이는 절대적인 우선순위를 가집니다.

2. 그룹 정책의 경우, priority 값을 비교합니다:

priority=1인 정책이 priority=5인 정책보다 우선합니다
동일한 priority 값을 가진 정책이 여러 개라면, 정책 ID가 더 작은 것이 우선합니다
한 사용자가 여러 그룹에 속해 있을 때는 항상 가장 제한적인 정책이 적용됩니다

3. 어떤 정책도 적용되지 않을 때만 기본 정책이 사용됩니다.

정책 변경의 실시간 적용

패스워드 정책이 변경될 때, 이 변경사항이 시스템에 어떻게 반영되는지 이해하는 것도 중요합니다. 일부 변경사항은 즉시 적용되지만, 다른 것들은 다음 인증 시도까지 기다려야 합니다.

즉시 적용되는 변경사항:

잠금 해제: 관리자가 수동으로 계정 잠금을 해제할 때
정책 할당 변경: 사용자나 그룹에 새로운 정책을 할당할 때
우선순위 변경: 정책의 priority 값을 수정할 때

다음 인증 시도 시 적용되는 변경사항:

실패 허용 횟수 변경: maxIncorrectAttempts 값 수정
잠금 지속 시간 변경: lockoutDuration 값 수정
정책 활성화/비활성화: 전체 정책의 활성 상태 변경

적용 시차를 이해하는 것이 중요한 이유는, 정책 변경 후 적절한 시점에 변경 사항을 검증할 수 있기 때문입니다. 예를 들어, 잠금 해제는 즉시 확인할 수 있지만, 새로운 실패 허용 횟수는 실제 로그인 시도를 통해서만 검증할 수 있습니다.

정책 모니터링과 관리 방안

정책을 성공적으로 구현하고 적용한 후에는 지속적인 모니터링과 관리가 필요합니다. 이는 마치 건물의 보안 시스템을 설치한 후 지속적으로 모니터링하고 관리하는 것과 같습니다. 효과적인 모니터링과 관리를 위해 여러 측면을 고려해야 합니다.

정책 작동 상태 모니터링

실제 운영 환경에서 정책이 의도한 대로 작동하는지 확인하는 것이 매우 중요합니다. 이를 위해 시스템은 여러 가지 속성을 통해 현재 상태를 보여줍니다. 다음 명령어를 사용하여 이러한 정보를 확인할 수 있습니다:

# 사용자의 현재 상태 확인
ldapsearch -h hostname -p port -D "cn=orcladmin" -w password \
-b "cn=targetuser,cn=Users,dc=example,dc=com" \
"(objectClass=*)" oblogintrycount oblockouttime oblixPersonPwdPolicy

이 명령어를 통해 확인할 수 있는 중요한 정보들은 다음과 같습니다:

oblogintrycount 값의 분석:

0: 정상 상태, 실패 시도가 없음
1-4: 실패 시도가 있었지만 아직 임계값 미만
5 이상: 주의가 필요한 상태, 잠재적인 보안 위협 가능성

oblockouttime 값의 해석:

값이 없음: 계정이 잠기지 않은 상태
현재 시간보다 큰 값: 계정이 잠긴 상태이며, 해당 시간까지 잠금 유지
과거 시간: 잠금이 해제되었지만 기록이 남아있는 상태

비정상 패턴 감지와 대응

시스템은 다양한 비정상 패턴을 감지할 수 있습니다. 예를 들어:

1. 빠른 연속 실패:

# 최근 10분간의 로그인 시도 패턴 확인
ldapsearch -h hostname -p port -D "cn=orcladmin" -w password \
-b "cn=targetuser,cn=Users,dc=example,dc=com" \
"(&(objectClass=*)(oblockouttime>=현재시간-600))"

2. 특정 시간대의 비정상적인 활동:

# 업무 시간 외 로그인 시도 확인
ldapsearch -h hostname -p port -D "cn=orcladmin" -w password \
-b "dc=example,dc=com" \
"(&(objectClass=*)(oblogintrycount>=1)(timeStamp>=업무시간외))"

정책 유지보수와 조정

시스템 운영 중에 정책을 조정해야 할 필요가 생길 수 있습니다. 예를 들어, 너무 많은 사용자가 잠기는 경우 정책을 완화하거나, 보안 위협이 감지되면 정책을 강화해야 할 수 있습니다. 이러한 조정은 다음과 같이 수행할 수 있습니다:

# 정책 설정 수정
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. 잠금 해제

사용자 계정이 잠긴 경우 다음 명령어로 해제할 수 있습니다:

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. 기본 정책으로 복귀

특별 정책을 제거하고 기본 정책으로 되돌리려면:

# 사용자를 특별 정책 그룹에서 제거
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 환경에서의 패스워드 정책 예외 처리는 단순한 설정 변경 이상의 이해와 주의가 필요한 작업입니다. 시스템의 복잡한 구조를 정확히 이해하고, 적절한 메커니즘을 선택하여 구현하며, 지속적인 모니터링과 관리를 통해 안전하게 운영해야 합니다. 특히 Oblix 레거시 시스템의 역할을 이해하는 것이 현재 환경에서 가장 중요한 포인트라고 할 수 있습니다.