Kerberos : 도메인 간/영역 문제

고객이 소프트웨어에 대해 SSO (Kerberos 포함)를 구성하도록 돕는 동안 문제가 발생했습니다.Kerberos : 도메인 간/영역 문제

그러나 먼저, 당신에게 몇 가지 상황에 맞는주게 :

을 당신은 우리가 크로스 도메인/영역 Kerberos를 수행 할 우리는 네 가지 (Active Directory를 가지고있는 위해, 첨부 krb5.ini에서 볼 수 있듯이, 모든 2008 R2 숲이/도메인 기능 수준) 도메인. 분명히 test.local의 자식 도메인이다

1) test.local 2) subdomain.test.local() 3) example.local는 4) dummy.local

양방향 전이 트러스트이었다 (test.local과 example.local 사이뿐만 아니라 test.local과 example.local 사이에서도 수동으로 설정하십시오.

그리고 test.local과 subdomain.test.local 사이에 기본 트러스트가 있습니다.

[libdefaults] 
default_realm = TEST.LOCAL 
default_tkt_enctypes = rc4-hmac aes128-cts aes256-cts des-cbc-crc des-cbc-md5 
default_tgs_enctypes = rc4-hmac aes128-cts aes256-cts des-cbc-crc des-cbc-md5 
permitted_enctypes = rc4-hmac aes128-cts aes256-cts des-cbc-crc des-cbc-md5 
[realms] 
TEST.LOCAL = { 
    kdc = dc001.TEST.local 
    kdc = dc002.TEST.local 
} 
EXAMPLE.LOCAL = { 
    kdc = dc001.example.local 
    kdc = dc002.example.local 
} 
SUBDOMAIN.TEST.LOCAL = { 
    kdc = dc001.SUBDOMAIN.TEST.local 
    kdc = dc002.SUBDOMAIN.TEST.local 
} 
DUMMY.LOCAL = { 
    kdc = dc001.dummy.local 
    kdc = dc002.dummy.local 
} 
[domain_realm] 
test.local=TEST.LOCAL 
.test.local=TEST.LOCAL 
example.local=EXAMPLE.LOCAL 
.example.local=EXAMPLE.LOCAL 
dummy.local=DUMMY.LOCAL 
.dummy.local=DUMMY.LOCAL 
subdomain.test.local=SUBDOMAIN.TEST.LOCAL 
.subdomain.test.local=SUBDOMAIN.TEST.LOCAL

상호 도메인 이름 확인이 올바르게 작동합니다.

웹 서버는 Linux 박스입니다 (올바르게 기억한다면 RedHat 또는 CentOS 설치). fqdn은 web001.test.local입니다.

클라이언트는 로컬 인트라넷 영역의 구성원으로 fqdn web001.test.local을 처리합니다 (이들이 속해있는 도메인과 별도로).

웹 서버에 대한 서비스 사용자 및 해당 키탭 파일을 만들었습니다.

우리가 test.local 조회하고 우리가 올바른 응답을 얻을 SPN을 검색 할 경우 사용자가 test.local 또는 하위 도메인의 구성원 인 경우 (우리가 테스트를 시작 및 Kerberos 그냥 괜찮 았는데 그 후

<service user)> 
HTTP/[email protected] 
HTTP/web001.test.local 
HTTP/web001

을 .test.local) dummy.local 및 example.local에서 테스트 사용자와 로그인 할 때까지.

사용자가 우리가 다음 스택 트레이스를 얻을이 특정 도메인에서 로그인을 시도 할 때마다 :

09:44:25.447 WARN REQUEST[10.50.50.45] 
o.s.s.k.w.a.SpnegoAuthenticationProcessingFilter - Negotiate Header was 
invalid: Negotiate YIIJ... 
org.springframework.security.authentication.BadCredentialsException: 
Kerberos validation not successful 

Caused by: java.security.PrivilegedActionException: null 

Caused by: sun.security.krb5.KrbCryptoException: Checksum failed 

Caused by: java.security.GeneralSecurityException: Checksum failed

내가 전에 말했듯이 : 커버 로스는 test.local과 subdomain.test 내 고객/사용자와 함께 작동합니다. 로컬 영역/도메인.

하지만 다른 도메인/영역에서는 작동하지 않는 이유가 없습니다.

누군가가 나를 깨우 치거나 적어도 나에게 힌트를 줄 수 있습니까?

미리 감사드립니다.

P. 디버깅/응답 관련 : 저는 고객 도메인 (활성 디렉토리)과 웹 서버에 직접 액세스 할 수 없습니다. 디버깅을하고 답변에 응답하는 데 며칠이 걸릴 수 있습니다.

출처

2017-02-24 hlpinform

example.local 도메인의 클라이언트가 HTTP/web001.test.local에 대한 서비스 티켓을 가지고 있는지 실제로 확인 했습니까? example.local의 KDC는 이러한 서비스 티켓을 발급 할 수 없습니다. 대신 example.local의 KDC는 KDC test.local을 사용하여 이러한 서비스 티켓을 얻도록 클라이언트에 지시해야합니다. https://technet.microsoft.com/en-us/library/bb742516.aspx –

본인이 직접 확인하지 않았습니다. 하지만 고객에게 확인을 요청할 것입니다. 그러나 내가 아는 한 example.local의 KDC는 서비스 티켓을 발급합니다. 그러나 클라이언트에게 직접 전달하는 것이 아니라 여기에 표시된대로 test.local에서 서비스 티켓 (트러스트를 통해)을 "교차 서명"하십시오 (https://adsecurity.org/?p=1588, 두 번째 이미지). 하지만 내 주요 관심사는 왜이 작동 test.local뿐만 아니라 subdomain.test.local 이해하지만 다른 두 도메인에 대해 이해할 수 없다는 것입니다. 그래서 차이가 있어야합니다. – hlpinform

귀하가 참조한 링크가 보안 위반 사항이며 올바른 방식으로 작동하지 않습니다. –

좋아요, 문제는 신뢰 구성입니다! 앞에서 언급했듯이, 그것은 양방향 전 이적 신뢰였습니다. 슬프게도 그것은 (어린이 도메인을 제외하고) 아이도 포레스트 트러스트도 아니었다. 그것은 외부의 신뢰였습니다. 이런 식으로 kerberos가 활성화 된 경우 라우팅 규칙이 없습니다.

이 문서 (https://jorgequestforknowledge.wordpress.com/2011/09/14/kerberos-authentication-over-an-external-trust-is-it-possible-part-6/)를 발견했으며 GPO를 통해 수동으로 라우팅 이름을 구성했습니다.이것은 트릭을했다.

Bernhard에게 질문하여 올바른 방향으로 안내해 주셨습니다.

출처

2017-03-06 10:30:42 hlpinform

답변

관련 문제