OBIEE 12c(12.2.1.1)를 Active Directory(AD)와 연동한 고객 환경에서, AD 계정 중 일부는 로그인되고 일부는 “Invalid User Name or Password”로 실패하는 문제를 다룬 기록입니다. 비밀번호는 맞는데 일부 사용자만 실패한다면 대개 AD 인증 공급자(ActiveDirectoryAuthenticator)의 검색 범위나 필터 설정 문제입니다.
2024년 9월 Notion에 영어로 정리했던 글을 옮기면서 2026년 10월에 Oracle Analytics Server(OAS) 보안 문서와 WebLogic 12.2.1.4 MBean 메타데이터로 다시 확인했습니다. 원본에 있던 고객사 도메인, AD 서버 IP, 서비스 계정, 암호화된 비밀번호 문자열은 모두 예시 값으로 바꿨습니다. 절차는 OBIEE 12c와, 같은 WebLogic 12.2.1.4 위에서 동작하는 OAS에 공통입니다.
증상
- 같은 AD 도메인 사용자인데 일부만 로그인되고, 나머지는 “Invalid User Name or Password”로 실패합니다.
- BI 쪽 로그에는
[nQSError: 43126] Authentication failed: invalid user/password가 남습니다. WebLogic 쪽에서는 인증 실패([Security:090938],[Security:090302])로 기록됩니다. - WebLogic 관리 콘솔의 Security Realms > myrealm > Users and Groups에서 AD 사용자 목록이나 그룹 목록 일부가 보이지 않습니다.
원인은 대개 세 곳
| 설정 | 잘못됐을 때 |
|---|---|
| User Base DN | 지정한 OU 밖에 있는 사용자는 찾지 못해 인증에 실패합니다. 일부 부서만 로그인되는 경우 가장 먼저 볼 곳입니다. |
| Group Base DN | 그룹이 지정한 OU 밖에 있으면 그룹 목록이 비고, AD 그룹 기반 롤 매핑이 동작하지 않습니다. |
| 사용자·그룹 이름 속성과 필터 | 로그인 ID 속성(예: sAMAccountName)과 필터가 서로 맞지 않으면 사용자를 찾지 못합니다. |
검색 범위(User Search Scope, Group Search Scope)의 기본값은 subtree입니다. 그래서 Base DN은 대상 사용자와 그룹을 모두 포함하는 공통 상위 OU로 잡으면 됩니다.
점검 순서
1. 관리 콘솔에서 사용자와 그룹이 보이는지 확인
Security Realms > myrealm > Users and Groups에서 로그인에 실패하는 사용자와 그 사람이 속한 그룹이 보이는지 봅니다. 사용자가 안 보이면 User Base DN이나 사용자 필터 문제이고, 그룹이 안 보이면 Group Base DN이나 그룹 필터 문제입니다.
2. AD 관리자와 DN 확인
실패하는 사용자와 성공하는 사용자의 실제 DN, 소속 그룹의 DN을 AD 관리자에게 받아 비교합니다. 서버에서 직접 확인하려면 ldapsearch로 WebLogic이 쓰는 것과 같은 Base DN과 필터를 넣어 봅니다.
# 사용자: WebLogic의 User Base DN과 User From Name Filter로 검색
ldapsearch -H ldap://ad01.corp.example.com:389 \
-D "CN=svc-obiee,OU=Service,OU=HQ,DC=corp,DC=example,DC=com" -W \
-b "OU=HQ,DC=corp,DC=example,DC=com" \
"(&(sAMAccountName=user01)(objectclass=user))" dn memberOf
# 그룹: Group Base DN과 Group From Name Filter로 검색
ldapsearch -H ldap://ad01.corp.example.com:389 \
-D "CN=svc-obiee,OU=Service,OU=HQ,DC=corp,DC=example,DC=com" -W \
-b "OU=HQ,DC=corp,DC=example,DC=com" \
"(&(sAMAccountName=BI_Users)(objectclass=group))" dn결과가 나오지 않으면 그 Base DN 아래에 대상이 없다는 뜻입니다. -W는 비밀번호를 프롬프트로 받으므로 명령 기록에 비밀번호가 남지 않습니다.
3. Base DN을 공통 상위 OU로 조정
제 경우에는 Group Base DN을 부서 OU(OU=IT,OU=HQ,...)로 잡았을 때 그룹을 찾지 못했습니다. 그룹들이 부서 OU가 아닌 다른 OU에 있었기 때문에, 공통 상위인 OU=HQ,...로 넓혀 해결했습니다. 시행착오 중에 OU=IT,DC=corp,...처럼 중간 OU를 빼고 쓴 값도 시도했는데, 이런 DN은 AD에 실제로 없는 경로라서 동작하지 않습니다. DN은 AD 관리자에게 받은 값을 그대로 쓰세요.
설정 방법
OAS 보안 문서의 Active Directory 구성 절차를 기준으로 정리했습니다.
- 관리 콘솔에서 Lock & Edit
- Security Realms > myrealm > Providers > Authentication > New에서 Type
ActiveDirectoryAuthenticator로 추가(예:ADAuthenticator) - DefaultAuthenticator와 ADAuthenticator의 Control Flag를 모두
SUFFICIENT로 변경(기본값은REQUIRED) - ADAuthenticator > Provider Specific에서 접속 정보와 아래 값을 입력하고 Save
- Providers > Authentication > Reorder로 ADAuthenticator를 맨 위로 이동
- Activate Changes 후 WebLogic(AdminServer와 BI Managed Server) 재시작
| 항목 | 기본값 | 예시(로그인 ID가 sAMAccountName일 때) |
|---|---|---|
| User Base DN | ou=WLSMEMBERS,dc=example,dc=com | OU=HQ,DC=corp,DC=example,DC=com |
| User Name Attribute | cn | sAMAccountName |
| User From Name Filter | (&(cn=%u)(objectclass=user)) | (&(sAMAccountName=%u)(objectclass=user)) |
| Group Base DN | ou=WLSGROUPS,dc=example,dc=com | OU=HQ,DC=corp,DC=example,DC=com |
| Static Group Name Attribute | cn | sAMAccountName |
| Group From Name Filter | (&(cn=%g)(objectclass=group)) | (&(sAMAccountName=%g)(objectclass=group)) |
- AD의
cn은 보통 표시 이름(이름+성)이고sAMAccountName이 로그인 ID입니다. 기본값이cn이라서 사용자가 로그인 ID로 들어오게 하려면 이름 속성과 필터를 함께 바꿔야 합니다. - OAS 문서는 이름 속성을
cn이외 값으로 바꿀 때 짝이 되는 필터를 함께 바꾸라고 안내합니다. 사용자는 User Name Attribute와 함께 All Users Filter, User From Name Filter를, 그룹은 Static Group Name Attribute와 함께 All Groups Filter, Group From Name Filter를 같은 속성으로 맞춥니다. - 위 항목들은 WebLogic 메타데이터상 재시작이 필요한 속성입니다. Activate만 하고 재시작하지 않으면 반영되지 않습니다.
설정이 반영되면 도메인의 config/config.xml에 아래와 같이 기록됩니다(값은 예시). 원본 글에는 “BI 서비스를 내리고 config.xml을 확인하고 필요하면 직접 수정”하는 단계가 있었습니다. 하지만 config.xml은 관리 콘솔이 관리하는 파일이므로 확인만 하고, 수정은 콘솔에서 하는 것이 안전합니다.
<sec:authentication-provider xsi:type="wls:active-directory-authenticator-type">
<sec:name>ADAuthenticator</sec:name>
<sec:control-flag>SUFFICIENT</sec:control-flag>
<wls:host>ad01.corp.example.com</wls:host>
<wls:user-name-attribute>sAMAccountName</wls:user-name-attribute>
<wls:principal>CN=svc-obiee,OU=Service,OU=HQ,DC=corp,DC=example,DC=com</wls:principal>
<wls:user-base-dn>OU=HQ,DC=corp,DC=example,DC=com</wls:user-base-dn>
<wls:credential-encrypted>{AES}...</wls:credential-encrypted>
<wls:user-from-name-filter>(&(sAMAccountName=%u)(objectclass=user))</wls:user-from-name-filter>
<wls:group-base-dn>OU=HQ,DC=corp,DC=example,DC=com</wls:group-base-dn>
<wls:group-from-name-filter>(&(sAMAccountName=%g)(objectclass=group))</wls:group-from-name-filter>
<wls:static-group-name-attribute>sAMAccountName</wls:static-group-name-attribute>
<wls:use-retrieved-user-name-as-principal>false</wls:use-retrieved-user-name-as-principal>
</sec:authentication-provider>XML 파일 안에서는 필터의 &가 &로 저장됩니다.
함께 볼 설정
- 캐시: LDAP 조회 캐시(Cache Enabled)의 기본값은 켜짐, 크기 32KB, TTL 60초입니다. 원본 환경은 캐시를 꺼 둔 상태였는데, 캐시를 끄면 로그인마다 AD 조회가 늘어납니다. 특별한 이유가 없다면 켜 두고, 사용자가 많으면 크기를 늘리는 것을 검토하세요. 원본에 있던 “3200 이상 권장” 수치는 근거를 찾지 못해 뺐습니다.
- 롤 매핑: 로그인에 성공해도 AD 그룹을 애플리케이션 롤(
BIServiceAdministrator,BIContentAuthor,BIConsumer등)에 매핑해야 권한이 생깁니다. 원본의 “BIAuthor”는 11g 시절 이름이고, 12c와 OAS의 롤 이름은BIContentAuthor입니다. - 서비스 계정: Principal 계정은 조회 권한만 있으면 됩니다. 비밀번호가 만료되면 모든 AD 로그인이 실패하므로 만료 정책을 AD 관리자와 확인해 두세요.
정리
AD 사용자 일부만 로그인에 실패하면 먼저 관리 콘솔의 Users and Groups에 그 사용자와 그룹이 보이는지 확인합니다. 보이지 않으면 Base DN이 대상을 포함하는지, 이름 속성과 필터가 같은 속성(sAMAccountName 등)으로 맞춰져 있는지 봅니다. 값은 ldapsearch로 검증하고, 변경은 콘솔에서 한 뒤 재시작합니다.
로그인 실패 시 접속 IP와 사용자 ID를 남기는 방법은 OBIEE 로그인 실패 추적, AD 사용자는 빠른데 weblogic 계정만 느린 문제는 AD 로그인은 빠른데 weblogic만 느릴 때, AD 쪽 동기화 진단은 Active Directory USN 추적에서 다뤘습니다.
