SPNEGO 문제점 해결 팁

SPNEGO(Simple and Protected GSS-API Negotiation Mechanism)를 사용하여 WebSphere® Application Server에서 보안 자원에 대한 HTTP 요청을 안전하게 협상하고 인증할 수 있습니다. WebSphere Application Server에 대한 웹 인증 서비스로 SPNEGO(Simple and Protected GSS-API Negotiation Mechanism)를 사용하는 중에 문제점이 발생할 수 있습니다.

SPNEGO 문제 및 가능한 솔루션

참고: 이 주제는 하나 이상의 애플리케이션 서버 로그 파일을 참조합니다. 권장되는 대안은 분배 및 IBM® i 시스템에서 SystemOut.log, SystemErr.log, trace.logactivity.log 파일을 사용하는 대신 HPEL(High Performance Extensible Logging) 로그를 사용하고 인프라를 추적하도록 서버를 구성하는 것입니다. 원시 z/OS® 로깅 기능과 연계하여 HPEL을 사용할 수도 있습니다. HPEL을 사용하는 경우 서버 프로파일 바이너리 디렉토리의 LogViewer 명령행 도구를 사용하여 모든 로그에 액세스하고 정보를 추적할 수 있습니다. HPEL 사용에 대한 자세한 정보는 HPEL을 사용한 애플리케이션 문제점 해결 정보를 참조하십시오.
WebSphere Application Server에 대한 웹 인증 서비스로 SPNEGO를 사용하는 경우 다음 문제가 발생할 수 있습니다. 가능한 솔루션이 제공됩니다.

Kerberos 프린시펄 이름을 분석할 수 없음

다음 추적 예제에 표시된 대로 Kerberos 프린시펄 이름을 사용할 수 없는 경우:

[11/11/03 1:42:29:795 EST] 1d01b21e GetKrbToken   > Negotiation (GSS): Begin handshake
[11/11/03 1:42:29:795 EST] 1d01b21e Context       > GSS Context init, servername:HTTP@johnwang5.jwcmd.com
[11/11/03 1:42:29:866 EST] 1d01b21e TraceNLS      u No message text associated with key Error.getting.the.Token,
.GSS.Exception:org.ietf.jgss.GSSException,.major.code:.13,.minor.code:.0
	major.string:.Invalid.credentials
	minor.string:.Cannot.get.credential.from.JAAS.Subject.for.principal:.HTTP/192.168.0.4@168.0.4 in bundle 
com.ibm.ejs.resources.security
[11/11/03 1:42:29:866 EST] 1d01b21e GetKrbToken   E Error getting the Token, GSS Exception:org.ietf.jgss.GSSException, 
major code: 13, minor code: 0
	major string: Invalid credentials
	minor string: Cannot get credential from JAAS Subject for principal: HTTP/192.168.0.4@168.0.4
[11/11/03 1:42:29:876 EST] 1d01b21e TraceNLS      u No message text associated with key SpnegoTAI.exits.due.to.an.exception. 
in bundle com.ibm.ejs.resources.security
[11/11/03 1:42:29:876 EST] 1d01b21e SpnegoTAI     E SpnegoTAI exits due to an exception. 

해당 호스트 파일에 서버의 IP 주소를 추가하십시오. 또한 애플리케이션 서버를 재사용하여 새 호스트 파일을 로드해야 합니다.

WebSphere Application Server 및 AD(Active Directory) 도메인 제어기의 시간이 5분 내에 동기화되지 않습니다.

이 문제에 대한 trace.log 파일은 다음과 유사합니다.
[11/11/03 1:44:09:499 EST] 1d01b21e GetKrbToken   > Negotiation (GSS): Begin handshake
[11/11/03 1:44:09:499 EST] 1d01b21e Context       > GSS Context init, servername:HTTP@backendrc4.ibm.net
[11/11/03 1:44:09:499 EST] 1d01b21e Context       > GSS Context init, done.
[11/11/03 1:44:09:679 EST] 1d01b21e SpnegoTAI     > Server response token as follows...
0000:  6082014f 06062b06 01050502 a1820143     `?.O..+.....¡?.C
0010:  3082013f a0030a01 01a10b06 092a8648     0?.? ....¡...*?H
0020:  82f71201 0202a282 01290482 01256082     ?÷....¢?.).?.%`?
0030:  01210609 2a864886 f7120102 0203007e     .!..*?H?÷......~
0040:  82011030 82010ca0 03020105 a1030201     ?..0?.. ....¡...
0050:  1ea41118 0f323030 33313131 31303634     .¤...20031111064
0060:  3430395a a5050203 0a3548a6 03020125     409Z¥....5H¦...%
0070:  a90b1b09 4a57434d 442e434f 4daa2630     ©.....IBM.NETª&0
0080:  24a00302 0100a11d 301b1b04 48545450     $ ....¡.0...HTTP
0090:  1b136a6f 686e7761 6e67352e 6a77636d     ..backendrc4.ibm
00a0:  642e636f 6dab81ab 1b81a86f 72672e69     .net.«?«.?¨org.i
00b0:  6574662e 6a677373 2e475353 45786365     etf.jgss.GSSExce
00c0:  7074696f 6e2c206d 616a6f72 20636f64     ption, major cod
00d0:  653a2031 302c206d 696e6f72 20636f64     e: 10, minor cod
00e0:  653a2033 370a096d 616a6f72 20737472     e: 37..major str
00f0:  696e673a 20446566 65637469 76652074     ing: Defective t
0100:  6f6b656e 0a096d69 6e6f7220 73747269     oken..minor stri
0110:  6e673a20 436c6965 6e742074 696d6520     ng: Client time 
0120:  54756573 6461792c 204e6f76 656d6265     Tuesday, Novembe
0130:  72203131 2c203230 30332061 7420313a     r 11, 2003 at 1:
0140:  33353a30 3120414d 20746f6f 20736b65     35:01 AM too ske
0150:  776564                                  wed

이 문제를 두 가지 방식 중 하나로 수정할 수 있습니다. 우선되는 방법은 WebSphere 시스템 시간을 AD 서버 시간의 5분 내로 동기화하는 것입니다. 우수 사례는 시간 서버를 사용하여 모든 시스템의 동기화 상태를 유지하는 것입니다. 또는 Kerberos 구성 파일에서 클럭 오차 매개변수를 추가하거나 조정할 수도 있습니다. 기본값은 300초(5분)임을 참고하십시오.

메커니즘 1.3.6.1.5.5.2에 대한 이름 작성에 사용 가능한 팩토리가 없음

systemout.log 파일에 다음과 같은 예외 오류가 포함된 경우:
[4/8/05 22:51:24:542 EDT] 5003e481 SystemOut     O [JGSS_DBG_PROV] Provider IBMJGSSProvider version 1.01 
does not support mech 1.3.6.1.5.5.2
[4/8/05 22:51:24:582 EDT] 5003e481 ServerCredent E com.ibm.issw.spnegoTAI.ServerCredential initialize() SPNEGO014: 
Kerberos initialization Failure: org.ietf.jgss.GSSException, major code: 2, minor code: 0
	major string: Unsupported mechanism
	minor string: No factory available to create name for mechanism 1.3.6.1.5.5.2
	at com.ibm.security.jgss.i18n.I18NException.throwGSSException(I18NException.java:30)
	at com.ibm.security.jgss.GSSManagerImpl.a(GSSManagerImpl.java:36)
	at com.ibm.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:217)
	at com.ibm.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:264) 
.
. 
java.security 파일이 IBMSPNEGO 보안 제공자를 포함하는지 및 올바르게 정의되어 있는지 확인하십시오. 이 파일은 다음과 유사한 행을 포함해야 합니다.
security.provider.6=com.ibm.security.jgss.mech.spnego.IBMSPNEGO

SPNEGO 토큰을 복호화하고 확인하는 동안 Kerberos 오류가 수신됨

JGSS(Java™ Generic Security Service) 라이브러리가 SPNEGO 토큰을 처리하려고 시도하면 다음과 같은 예외 오류를 수신할 수 있습니다.
Error authenticating request. Reporting to client
Major code = 11, Minor code = 31
org.ietf.jgss.GSSException, major code: 11, minor code: 31
	major string: General failure, unspecified at GSSAPI level
	minor string: Kerberos error while decoding and verifying token: com.ibm.security.krb5.internal.KrbException, status code: 31
	message: Integrity check on decrypted field failed
이 오류는 한 개의 키를 사용하여 티켓이 인코딩된 다음 다른 키를 사용하여 티켓을 디코딩하려는 시도가 이루어질 때 발생합니다. 이에 대한 여러 가능한 설명이 있습니다.
  • keytab 파일이 재생성된 후 서버 머신에 복사되지 않았습니다.
  • Kerberos 구성이 잘못된 keytab 파일을 지정합니다.
  • SPN이 Active Directory에 의해 두 번 이상 정의되었습니다. 이는 유사하게 정의된 SPN(같은 이름이거나 SPN의 일부로 정의된 포트가 있어서 다를 수 있음)을 포함하는 다른 사용자 ID로 인한 것입니다.
  • 암호화 유형이 DES인 경우 서비스 사용자 ID와 연관된 비밀번호는 RC4-HMAC 암호화를 위해서만 존재하는 것일 수 있습니다. 이는 +DesOnly 옵션을 사용하여 새 사용자 ID를 작성하고 SPN을 정의하며 keytab을 생성한 경우에 발생합니다. 이 SPN에 대해 생성된 서비스 티켓은 keytab에서 찾은 본인확인정보와 일치하지 않는 한 개의 본인확인정보로 암호화됩니다.
  • Microsoft ktpass 도구의 이전 버전이 사용되고 있습니다. 이전 버전의 도구는 올바르지 않은 keytab 파일을 작성하고 이 오류가 발생하는 원인이 될 수 있습니다. 도메인 제어기로 Windows Server 2003을 사용하는 경우 Windows Server 2003 SP 2(특히, 버전 5.2.3790.2825)의 일부인 ktpass.exe의 버전을 사용하십시오.

keytab 파일에 문제점이 있으면 수정하십시오. 다중 SPN 정의에 문제점이 있는 경우 여분의 SPN 또는 충돌하는 SPN을 제거하고 AD에서 해당 SPN이 등록 해제되었는지 확인한 다음 SPN을 다시 추가하십시오. 자세한 정보는 Kerberos 서비스 프린시펄 이름 및 keytab 파일 작성의 내용을 참조하십시오. LDAP 브라우저를 사용하는 SPN과 충돌하는 SPN이 정의된 다른 항목이 있는지 Active Directory를 검색해야 될 수도 있습니다.

SPN이 등록되지 않았는지 확인하려면 다음 명령
setspn –l userid
가 다음을 리턴해야 합니다.
Cannot find account userid

사용자 ID 및 keytab이 DES-CBC-MD5용인 경우 사용자 ID를 작성한 후 해당 사용자 ID의 비밀번호를 변경한 다음 keytab 파일을 작성하십시오. Windows Server 2003을 사용하고 있는 경우 ktpass 최신 버전으로 업그레이드하십시오.

싱글 사인온이 발생하지 않음

추적이 켜지면 다음 오류가 표시될 수 있습니다.
Client sent back a non-SPNEGO authentication header, SpnegoTAI exits
이 오류의 가능한 원인은 클라이언트가 SPNEGO 토큰이 아닌 NTLM(NT LAN manager) 응답을 리턴하는 것입니다. 이는 다음 중 하나 이상의 문제로 인해 발생할 수 있습니다.
  • 클라이언트가 올바르게 구성되지 않았습니다.
  • 클라이언트가 지원되는 브라우저를 사용하고 있지 않습니다. 예를 들어, Internet Explorer 5.5 SP1의 사용자가 비SPNEGO 인증 헤더로 응답합니다.
  • 사용자가 AD 도메인 또는 신뢰 도메인에 로그인하지 않았거나 사용되는 클라이언트가 Windows에서 통합 인증을 지원하지 않습니다. 이 경우 TAI가 올바르게 작동합니다.
  • 사용자가 클라이언트가 실행되는 머신(로컬 호스트)과 같은 머신에서 정의되는 서비스에 액세스합니다. Internet Explorer가 URL을 제공되는 완전한 이름 대신 http://localhost<someURL>로 분석합니다.
  • SPN을 Active Directory에서 찾을 수 없습니다. SPN의 형식은 HTTP/server.realm.com이어야 합니다. SPN에 추가할 명령은 다음과 같습니다.
    setspn –a HTTP/server.realm.com userid

    SPN이 @REALM.COM이 추가된 HTTP/server.realm.com@REALM.COM과 같이 잘못 정의된 경우 사용자를 삭제하고 재정의한 후 SPN을 재정의하십시오.

  • 호스트 이름이 HOST 레코드가 아닌 DNS 별명으로 분석됩니다. HOST 레코드에 대한 호스트 이름으로 변경하십시오.
  • ServicePrincipalName을 보유하는 AD의 계정이 사용자가 로그인한 AD 도메인에서 원격인 AD 도메인에 있고 이러한 도메인이 Windows 2003 도메인이 아닙니다. 도메인을 Windows 2003으로 마이그레이션하거나 SSO를 ServicePrincipalName 사용자 ID와 같은 도메인에 있는 사용자로 제한하십시오.

RC4-HMAC 암호화에서 싱글 사인온(SSO)을 사용할 수 없음

추적이 켜지면 다음과 같은 오류 메시지를 수신할 수 있습니다.
com.ibm.security.krb5.internal.crypto.KrbCryptoException, status code: 0
message: Checksum error; received checksum does not match computed checksum
이 오류에 대해 일부 가능한 이유에는 다음이 포함됩니다.
  • RC4-HMAC 암호화가 2003 KDC 이전 Windows 버전에서 지원되지 않습니다. 이것이 문제점인지 확인하려면 예외가 처리된 이전 추적을 검사하십시오. 수신 티켓의 컨텐츠가 추적에 표시되어야 합니다. 암호화되는 동안 서비스의 SPN 이름을 읽을 수 있습니다. 2003 KDC 이전 Windows 버전이 사용되고 시스템이 RC4-HMAC를 사용하도록 구성된 경우 예상한 HTTP/hostname.realm@REALM 대신 userid@REALM에 대한 티켓을 표시하는 문자열이 표시됩니다. 예를 들어, 다음은 2003 KDC 이전 Windows 버전에서 수신된 티켓의 시작부입니다.
    0000: 01 00 6e 82 04 7f 30 82  04 7b a0 03 02 01 05 a1  ..n...0.........
    0010: 03 02 01 0e a2 07 03 05  00 20 00 00 00 a3 82 03  ................
    0020: a5 61 82 03 a1 30 82 03  9d a0 03 02 01 05 a1 0a  .a...0..........
    0030: 1b 08 45 50 46 44 2e 4e  45 54 a2 18 30 16 a0 03  ...REALM.COM.0..
    0040: 02 01 01 a1 0f 30 0d 1b  0b 65 70 66 64 77 61 73  .....0...userid
    0050: 75 6e 69 74 a3 82 03 6e  30 82 03 6a a0 03 02 01  .a.f...n0..j....
    영역은 REALM.COM입니다. 서비스 이름은 userid입니다. 같은 SPN에 대해 올바르게 구성된 티켓은 다음과 같습니다.
    0000: 01 00 6e 82 04 56 30 82  04 52 a0 03 02 01 05 a1  ..n..V0..R......
    0010: 03 02 01 0e a2 07 03 05  00 20 00 00 00 a3 82 03  ................
    0020: 82 61 82 03 7e 30 82 03  7a a0 03 02 01 05 a1 0a  .a...0..z.......
    0030: 1b 08 45 50 46 44 2e 4e  45 54 a2 2a 30 28 a0 03  ..REALM.COM.0...
    0040: 02 01 02 a1 21 30 1f 1b  04 48 54 54 50 1b 17 75  .....0...HTTP..u
    0050: 73 31 30 6b 65 70 66 77  61 73 73 30 31 2e 65 70  serid.realm.com.
    0060: 66 64 2e 6e 65 74 a3 82  03 39 30 82 03 35 a0 03  ...n.....90..5..

    문제점을 정정하려면 단일 DES 암호화를 사용하거나 KDC에 Windows Server 2003을 사용하십시오. SPN 및 keytab 파일을 재생성하는 것을 잊지 마십시오.

  • RC-HMAC 암호화는 신임 정보 위임 기능이 사용되는 경우에 작동하지 않습니다. 이 문제점이 있는지 판별하려면 JGSS 및 Krb5 추적을 사용으로 설정하십시오. SPN 이름이 올바른 경우 다음과 같은 메시지가 표시될 수 있습니다.
    [JGSS_DBG_CTX] Successfully decrypted ticket
    [JGSS_DBG_CTX] Put authz info in cache
    [JGSS_DBG_CTX] Session key type = rc4-hmac
    …
    [JGSS_DBG_CTX] Successfully decrypted authenticator
    [JGSS_DBG_CTX] Error authenticating request. Reporting to client
    …
    Major code = 11, Minor code = 0
    org.ietf.jgss.GSSException, major code: 11, minor code: 0
    	major string: General failure, unspecified at GSSAPI level
    	minor string: Kerberos error converting KRBCred: com.ibm.security.krb5.internal.crypto.KrbCryptoException, status code: 0
    	message: Checksum error; received checksum does not match computed checksum

    이는 SPNEGO 토큰에 포함된 위임 신임 정보가 적절한 키로 암호화되지 않았음을 표시합니다.

    APAR IY76826을 얻으십시오. 이는 ibmjgssprovider.jar을 Microsoft에서 정의된 RC4 암호화된 위임 신임 정보를 승인할 수 있는 버전으로 대체합니다.

  • ktpass로 keytab 파일을 생성할 때 사용되는 비밀번호는 서비스 계정에 지정된 비밀번호와 일치하지 않습니다. 비밀번호가 변경되면 같은 비밀번호로 재설정되더라도 키를 재생성하고 재분배해야 합니다.
    또한 ktpass 도구는 다음의 경우에서와 같이 비일치 비밀번호로 keytab 파일을 생성할 수 있습니다.
    • ktpass에 입력된 비밀번호가 서비스 계정의 비밀번호와 일치하는 경우 생성된 keytab 파일이 작동하지 않습니다.
    • ktpass에 입력된 비밀번호가 서비스 계정의 비밀번호와 일치하지 않고 길이가 7자 미만인 경우 ktpass가 중지되고 keytab 파일을 생성하지 않습니다.
    • ktpass에 입력된 비밀번호가 서비스 계정의 비밀번호와 일치하지 않고 길이자 6자를 초과하면 ktpass가 중지되지 않습니다. 대신 올바르지 않은 키를 포함하는 keytab 파일을 생성합니다. SPNEGO 토큰을 복호화하기 위해 이 키를 사용하면 이전에 나열된 체크섬 오류가 발생합니다.

    서비스 계정에 널이 아닌 비밀번호를 사용한 다음 ktpass를 호출할 때 해당 비밀번호를 사용하십시오.

  • ktpass 버전 1830(지원 도구 SP1에 있음)은 일부 Windows 2003 Server 환경에서 오류를 생성할 수 있습니다. 도구의 SP2 버전을 사용하여 오류를 피하십시오.

    keytab 파일을 생성하려면 ktpass의 지원 도구 SP2 버전을 사용하십시오.

신임 정보 위임이 티켓 요청의 올바르지 않은 옵션으로 인해 작동하지 않을 수 있음

추적이 켜지면 다음 오류 메시지가 표시되는 경우
com.ibm.security.krb5.KrbException, status code: 101 message: Invalid option in ticket request

Kerberos 구성 파일이 올바르게 구성되지 않습니다. 갱신 가능 또는 프록시 가능이 둘 다 true로 설정되지 않도록 하십시오.

SPNEGO 싱글 사인온(SSO)을 통해 보호 URL에 액세스할 때 문제점

SPNEGO SSO를 통해 보호 URL에 액세스할 때 다음과 유사한 오류를 수신할 수 있습니다.
Bad Request

Your browser sent a request that this server could not understand.
Size of request header field exceeds server limit.

Authorization: Negotiate YII……

이 메시지는 Apache/IBM HTTP Server에서 생성되고 브라우저가 리턴한 권한 헤더가 너무 김을 표시합니다. 단어 Negotiate 뒤에 오는 긴 문자열은 SPNEGO 토큰입니다. 이 SPNEGO 토큰은 Windows Kerberos 토큰의 랩퍼입니다. Windows는 Kerberos 토큰에 사용자의 PAC 정보를 포함합니다. 사용자가 속한 보안 그룹이 많을수록 더 많은 PAC 정보가 Kerberos 토큰에 삽입되어 SPNEGO가 더 커지게 됩니다. IBM HTTP Server 2.0(Apache 2.0 및 IBM HTTP Server 6.0과 마찬가지로)은 허용 가능한 HTTP 헤더의 크기를 8K로 제한합니다. 다수의 그룹 및 다수의 그룹의 사용자 멤버십을 포함하는 Windows 도메인에서 사용자 SPNEGO 토큰의 크기는 8K 한계를 초과할 수 있습니다.

가능한 경우 사용자가 구성원인 보안 그룹의 수를 줄이십시오. IBM HTTP Server 2.0.47 누적 수정사항 PK01070에서는 HTTP 헤더 크기가 최대 Microsoft 한계인 12K이거나 이 한계를 넘을 수 있습니다.

수정사항을 적용한 후 httpd.conf 파일에서 LimitRequestFieldSize 매개변수를 지정하여 허용 가능한 헤더의 크기를 기본값 8192에서 늘릴 수 있습니다.

JGSS 추적이 사용 안함으로 설정되었음에도 일부 KRB_DBG_KDC 메시지가 SystemOut.log에 표시됨

대부분의 JGSS 추적이 com.ibm.security.jgss.debug 특성으로 제어되는 반면 작은 메시지 세트는 com.ibm.security.krb5.Krb5Debug 특성으로 제어됩니다. krb5 특성의 기본값은 일부 메시지를 SystemOut.log로 생성하는 것입니다.

SystemOut.log에서 모든 KRB_DBG_KDC 메시지를 제거하려면 JVM 특성을 -Dcom.ibm.security.krb5.Krb5Debug=none으로 설정하십시오.

ktpass가 사용자 ID를 찾을 수 없음

ktpass를 사용할 때 다음과 유사한 오류 메시지를 수신할 수 있습니다.
DsCrackNames returned 0x2 in the name entry for server3
Failed getting target domain for specified user.

Active Directory 포리스트에서 ktpass.exe가 사용하는 사용자 ID 검색에 사용할 기본 도메인 이름이 없습니다. 도메인 제어기가 포리스트에 없는 경우에는 이 오류가 발생하지 않습니다.

이 문제점을 수정하려면 -mapUser userid 옵션을 지정하는 대신 -mapUser userid@domain을 사용하십시오. 예를 들어, –mapUser server3@WIBM.NET를 지정하십시오.

신임 정보 위임이 모든 사용자 ID에 대해 작동하지 않음

trace.log에서 다음과 유사한 오류 예외가 표시되는 경우
> com.ibm.issw.spnegoTAI.Context getDelegateCred() Entry
d com.ibm.issw.spnegoTAI.Context getDelegateCred() unable to get Delegate Credential
< com.ibm.issw.spnegoTAI.Context getDelegateCred() Exit
W com.ibm.issw.spnegoTAI.SpnegoHandler handleRequest() SPNEGO021: No delegated credentials were found for user: nauser@NA.IBM.NET

SPN이 접속한 도메인 계정에서 "계정이 위임에 대해 신뢰됨" 특성이 정의되어 있지 않은 것입니다.

이 문제를 처리하려면 도메인 계정이 "계정이 위임에 대해 신뢰됨" 특성을 정의하는지 확인하십시오.

브라우저가 올바르게 구성되었지만 사용자에게 신임 정보가 요구됨

브라우저가 올바르게 구성되었지만 사용자에게 신임 정보를 요구합니다. TAI가 SPNEGO 토큰에서 사용자 신임 정보를 얻었을 수도 있고 사용자가 로그인에 실패했을 수도 있습니다. trace.log에서 다음과 유사한 예외 오류가 표시됩니다.
< com.ibm.issw.spnegoTAI.SpnegoTAI getAuthenticatedUsername(): lansche Exit
d com.ibm.issw.spnegoTAI.SpnegoTAI negotiateValidateandEstablishTrust(): Handshake finished, sending 200 :SC_OK
< com.ibm.issw.spnegoTAI.SpnegoTAI negotiateAndValidateEstablishedTrust Exit
A SECJ0222E: An unexpected exception occurred when trying to create a LoginContext. The LoginModule alias is system.WEB_INBOUND 
and the exception is...
사용자 ID(이전 예제에서 lansche임)가 WebSphere에서 사용 중인 레지스트리에 존재하지 않습니다. 이 문제점은 다음과 같은 경우에 발생할 수 있습니다.
  • WebSphere가 사용하는 레지스트리가 Active Directory 도메인 LDAP 또는 글로벌 카탈로그가 아니지만 일부 다른 가상 레지스트리(예: 파일 기반 사용자 정의 사용자 레지스트리)입니다.
  • 사용자 정의 IClientToServerUseridMapper 구현은 맵핑되는 이름이 레지스트리에 존재하지 않도록 사용자 이름을 수정합니다.
  • WebSphere LDAP 사용자 필터 특성에 의해 맵핑된 속성은 올바르지 않습니다.

이 문제점을 수정하려면 TAI에 의해 WebSphere Application Server에 어설션되는 사용자가 구성된 WebSphere 레지스트리인지 확인하십시오.

Novell 클라이언트를 사용하는 사용자가 SPNEGO를 사용하여 인증할 수 없음

Novell 클라이언트를 사용하는 사용자가 SPNEGO를 사용하여 인증할 수 없는 경우 "NTLM 토큰이 수신됨" 메시지를 수신할 수 있습니다.

사용자가 Novell 클라이언트에 로그인했을 수도 있지만 Windows Kerberos 로그인(이 로그인은 Kerbtray 유틸리티를 사용하여 확인할 수 있음)을 수행하지 않았습니다. 사용자가 Windows 도메인에 로그온했고 Kerberos 티켓을 가진 경우 이 사용자는 SPNEGO 인증을 이용할 수 없습니다.

이 문제점을 수정하려면 Novell 클라이언트를 제거하고 기본 Windows 도메인 로그인을 사용하십시오.

일부 캐싱 프록시 서버를 통해 SPNEGO 사이트에 액세스할 때 SPNEGO 인증 문제가 발생함

일부 캐싱 프록시 서버를 통해 SPNEGO 사이트에 액세스하는 경우 SPNEGO를 사용하여 인증하지 못할 수 있습니다. 메시지 "SPNEGO 인증은 이 클라이언트에서 지원되지 않음"이 표시될 수 있습니다.

캐싱 프록시가 HTTP 401 인증 협상 응답에서 리턴하는 호스트 이름을 변경할 가능성이 있습니다.

이 문제가 있는 경우 솔루션을 찾으려면 프록시 공급업체에 문의하십시오.

VPN(Virtual Private Networks) 소프트웨어 및 방화벽이 SPNEGO 조작을 방해할 수 있음

SPNEGO 조작을 방해할 수 있는 VPN 소프트웨어 및 방화벽에 관련된 문제점이 발생할 수 있습니다.

이러한 문제를 해결하려면 필요한 구성 변경에 대해 VPN 및 또는 방화벽 공급업체에 문의하십시오.

SPNEGO 보호 애플리케이션에 액세스할 때 발생 가능한 브라우저 문제

한 개의 비밀번호(예: passwordA)를 사용하여 도메인 머신에 로그인하고 원래 비밀번호를 변경하여(예를 들어, 두 번째 도메인 머신에서 비밀번호를 passwordB로 변경할 수 있음) 두 번째 도메인 머신에 로그온하는 경우 브라우저 문제가 있을 수 있습니다.

일단 원래 도메인 머신으로 돌아오면 협상 요구에 대해 SPNEGO/Kerberos 또는 NTLM 응답을 얻을 수 없습니다. 두 번의 시도 후 브라우저가 HTTP 404 오류 메시지를 표시합니다.

이 문제를 해결하려면 원래 도메인 머신에서 로그오프하고 새 비밀번호(passwordB)로 다시 로그온하십시오.

Internet Explorer 6.0에서 발생 가능한 브라우저 문제

WebSphere Application Server가 SPNEGO로 구성되고 요청에 대해 폴백이 사용으로 설정되는 경우 Internet Explorer 6.0은 양식 로그인 페이지에 로그인하는 데 실패할 수 있습니다.

이러한 상황을 피하려면 다음 조치 중 하나를 완료하십시오.
  • 글로벌 보안 > SPNEGO 웹 인증 패널에서 애플리케이션 인증 메커니즘에 대한 폴백 허용 옵션이 선택되어 있는 경우 이 옵션을 선택 취소하십시오.
  • Internet Explorer 버전 7.0으로 업그레이드
  • 다른 인증 페이지를 사용하도록 Internet Explorer 버전 6.0을 구성하십시오. 이 문제는 기본 인증 대 양식 로그인 인증 우선권에 대한 문제입니다.

NTLMTokenReceivedPage 또는 SpnegoNotSupportedPage 특성에 대해 정의된 오류 페이지가 http:// URL에서 로드를 수행함

NTLMTokenReceivedPage 또는 SpnegoNotSupportedPage 특성에 대해 정의된 오류 페이지가 http:// URL에서 로드를 수행합니다. 다음 추적 메시지가 표시될 수 있습니다.
Could not load the SPNEGO not supported content, going with the default content. 
Exception received: java.net.ProtocolException: Server redirected too many  times (20)

이 문제는 로드된 파일이 자동 경로 재지정을 수행하는 경우에 발생합니다. 웹 서버에서 파일 로드 및 자동 경로 재지정 사용을 둘 다 수행하는 것이 불가능함

이 문제를 해결하려면 http:// URL이 아닌 file:/// URL에서 컨텐츠를 로드하십시오.

클라이언트 브라우저 싱글 사인온(SSO) 시도가 인증에 실패함

Microsoft Internet Security Acceleration Server에서 SPNEGO 토큰을 사용하는 경우 클라이언트 브라우저 싱글 사인온(SSO) 시도가 WebSphere Application Server에서 인증에 실패하면 오류가 발생할 수 있습니다.

추적이 사용으로 설정되면 다음 메시지가 표시됩니다.
com.ibm.ws.security.spnego.SpnegoHandler isAuthHeaderNotSPNEGO 
ENTRY Negotiate                                                  
com.ibm.ws.security.spnego.SpnegoHandler isAuthHeaderNotSPNEGO 
Client sent back a non-SPNEGO authentication header

Microsoft ISA(Internet Security Acceleration Server)가 클라이언트 브라우저와 WebSphere Application Server 사이에 존재하면 ISA가 클라이언트 브라우저 요청으로부터 SPNEGO 인증 헤더를 인터셉트할 수 있습니다. ISA는 SPNEGO 오브젝트 ID(OID)를 Kerberos OID로 변환합니다. SPNEGO OID가 변환되었고 현재 누락되었기 때문에 WebSphere Application Server가 실패합니다.

이 문제를 수정하는 방법에 대한 정보는 Microsoft Corporation Support 사이트에서 "웹 사이트가 SPNEGO 인증 패키지만 허용하는 경우 사용자가 ISA Server 2006에 공개되는 웹 사이트에 액세스할 수 없음" 주제의 내용을 참조하십시오.

Microsoft Windows 버전 7 및 Internet Explorer 버전 8은 기본적으로 DES 암호화 유형을 사용 안함으로 설정합니다.

Microsoft Windows 버전 7에서 Internet Explorer 버전 8을 사용하고 작동시킬 SPNEGO 싱글 사인온(SSO)을 얻을 수 없는 경우 Windows 버전 7에서 Kerberos에 대한 DES 암호화 유형이 기본적으로 사용 안함으로 설정되었기 때문일 수 있습니다. 추적이 켜지면 다음 메시지가 표시됩니다.
Client sent back a non-SPNEGO authentication header....

암호화 유형을 RC4-HMAC 또는 AES로 변경하는 것이 권장됩니다. 그러나 여전히 DES 암호화 유형을 사용하기로 선택하는 경우 DES 암호화 유형을 사용으로 설정하는 방법에 대한 도움말을 보려면 Windows 7 문서를 참조해야 합니다.

다음은 암호화 유형을 DES에서 RC4로 변경하는 방법의 예제입니다.

  1. SPN에 맵핑하는 데 사용하는 Microsoft Active Directory 계정에서 이 계정에 DES 암호화 유형 사용 선택란이 선택되어 있지 않은지 확인하십시오. Microsoft Active Directory 머신에서 다음을 수행하십시오.
    1. 시작- > 프로그램->관리 도구 > Active Directory 사용자 및 컴퓨터 > 사용자를 클릭하십시오.
    2. SPN에 맵핑하는 데 사용하는 Microsoft Active Directory 계정을 클릭하십시오.
    3. 계정을 선택한 다음 Use DES encryption type for this account 상자가 선택되어 있지 않은지 확인하십시오.
  2. SPN에 맵핑하는 데 사용하는 Microsoft Active Directory 계정을 재설정하십시오. 이 계정을 같은 비밀번호로 재설정할 수 있습니다.
  3. RC4 암호화 유형으로 keytab을 재생성하십시오.
  4. 새 keytab 파일을 WebSphere Application Server 서버에 복사하십시오.
  5. default_tkt_enctypes 및 default_tgs_enctypes 속성에 대해 RC4를 처음으로 나열하도록 Kerberos 구성(krb5.ini/krb5.conf) 파일을 업데이트하십시오.
    예를 들어 다음과 같습니다.
    default_tkt_enctypes = rc4-hmac des-cbc-md5
    default_tgs_enctypes = rc4-hmac des-cbc-md5
    .
  6. 모든 WebSphere Application Server 서버를 중지하고 다시 시작하십시오.
참고: 여러 SPN에 맵핑하는 데 사용하는 둘 이상의 Microsoft Active Directory 계정이 있는 경우 각 SPN 및 모든 keytab 파일의 병합을 위해 1 - 3단계를 반복해야 합니다.

비제한 정책을 설정한 다음 AES256 암호화 사용

먼저 비제한 정책을 설정한 후 AES256 암호화를 사용할 수 있습니다. 다음 단계를 수행하십시오.
  1. Application Server를 중지하십시오.
  2. 새 정책 파일을 다운로드하고 설치하십시오.
    중요사항: 사용자의 국가마다 암호화 소프트웨어의 가져오기, 소유, 사용 또는 다른 국가로의 다시 내보내기에 대한 제한사항이 있을 수 있습니다. 비제한 정책 파일을 다운로드하거나 사용하기 전에 암호화 소프트웨어의 가져오기, 소유, 사용 및 다시 내보내기에 관한 해당 국가의 법률, 규정 및 정책을 확인하여 준수 여부를 확인해야 합니다.
    1. 적절한 SDK 레벨을 클릭하십시오.
    2. 페이지 아래로 이동하여 IBM SDK 정책 파일을 클릭하십시오. SDK 웹 사이트에 대한 비제한 JCE 정책 파일이 표시됩니다.
    3. 로그인을 클릭하고 IBM.com ID 및 비밀번호를 제공하십시오.
    4. SDK에 대한 비제한 JCE 정책 파일을 선택하고 계속을 클릭하십시오.
    5. 라이센스를 보고 계속하려면 동의함를 클릭하십시오.
    6. ZIP 파일로 패키징된 비제한 관할 정책 파일을 추출하십시오. ZIP 파일은 US_export_policy.jar 파일과 local_policy.jar 파일을 포함합니다.
    7. WebSphere Application Server 설치에서 $JAVA_HOME/lib/security 디렉토리로 이동하여 기존 US_export_policy.jarlocal_policy.jar 파일을 백업하십시오.
    8. US_export_policy.jarlocal_policy.jar 파일을 IBM.com 웹 사이트에서 다운로드한 두 개의 파일로 대체하십시오.
    참고: 이러한 파일을 대체하기 전에 백업을 수행하십시오. WAS_Install/java/jre/lib/security 에서 사용되는 경로의 예제입니다.
  3. 애플리케이션 서버를 시작하십시오.

주제 유형을 표시하는 아이콘 참조 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsec_SPNEGO_troubles
파일 이름:rsec_SPNEGO_troubles.html