Windows 2012 DC를 KDC로 사용하여 Ubuntu 16.04에서 KRB5를 구성하는 동안 이상한 문제가 발생했습니다. kinit의 비밀번호 프롬프트에 비밀번호가 제공되면 서비스 AD 계정을 사용하여 kinit 호출이 성공하지만, 정확히 동일한 비밀번호로 keytab 파일을 사용하는 경우 실패합니다. 물론 가장 간단한 설명은 keytab 파일에 잘못된 비밀번호가 있다는 것입니다. 하지만 파일은 자동으로 생성되고 동일한 코드로 생성된 키탭은 다른 환경에서 작동합니다. 그럼에도 불구하고 저는 ktpass비밀번호 관련 문제를 배제하기 위해 수동으로 새 키탭 파일을 여러 번 생성하고 Windows에서 키탭 파일을 생성했습니다 (명령줄에서 ktpass에 비밀번호를 제공할 수 있음). 그러나 결과는 항상 동일합니다. 즉, keytab 파일을 사용한 인증이 작동하지 않습니다.
문제가 Windows DC의 일부 설정과 관련이 있는 것 같지만 어디를 봐야 할지 모르겠습니다.
비밀번호를 사용하여 성공적으로 인증되었습니다.
root@my-server / # KRB5_TRACE=/dev/stdout kinit -V service_user :(
Using default cache: /tmp/krb5cc_0
Using principal: [email protected]
[3880] 1550161945.213705: Getting initial credentials for [email protected]
[3880] 1550161945.213896: Sending request (194 bytes) to DOMAIN.INT
[3880] 1550161945.214051: Sending initial UDP request to dgram 192.168.0.1:88
[3880] 1550161945.215117: Received answer (190 bytes) from dgram 192.168.0.1:88
[3880] 1550161945.215158: Response was from master KDC
[3880] 1550161945.215184: Received error from KDC: -1765328359/Additional pre-authentication required
[3880] 1550161945.215225: Processing preauth types: 16, 15, 19, 2
[3880] 1550161945.215243: Selected etype info: etype aes256-cts, salt "DOMAIN.INTrmcloudmember", params ""
Password for [email protected]:
[3880] 1550161955.687314: AS key obtained for encrypted timestamp: aes256-cts/0FBD
[3880] 1550161955.687371: Encrypted timestamp (for 1550161956.151464): plain 301AA011180F32303139303231343136333233365AA1050203024FA8, encrypted 9B8C1FB7CC85C23D0D803DCF2C29655D329628F98C505CEBE8EA1F3353D8D513CFAE25C1E146D74C5C4FE71326FCF12F6ED911FBC2B14FE2
[3880] 1550161955.687398: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
[3880] 1550161955.687404: Produced preauth for next request: 2
[3880] 1550161955.687430: Sending request (274 bytes) to DOMAIN.INT
[3880] 1550161955.687522: Sending initial UDP request to dgram 192.168.0.1:88
[3880] 1550161955.695617: Received answer (94 bytes) from dgram 192.168.0.1:88
[3880] 1550161955.695671: Response was from master KDC
[3880] 1550161955.695690: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP
[3880] 1550161955.695696: Request or response is too big for UDP; retrying with TCP
[3880] 1550161955.695701: Sending request (274 bytes) to DOMAIN.INT (tcp only)
[3880] 1550161955.695731: Initiating TCP connection to stream 192.168.0.1:88
[3880] 1550161955.696053: Sending TCP request to stream 192.168.0.1:88
[3880] 1550161955.697043: Received answer (1831 bytes) from stream 192.168.0.1:88
[3880] 1550161955.697053: Terminating TCP connection to stream 192.168.0.1:88
[3880] 1550161955.697089: Response was from master KDC
[3880] 1550161955.697117: Processing preauth types: 19
[3880] 1550161955.697127: Selected etype info: etype aes256-cts, salt "DOMAIN.INTdomainmember", params ""
[3880] 1550161955.697143: Produced preauth for next request: (empty)
[3880] 1550161955.697152: AS key determined by preauth: aes256-cts/0FBD
[3880] 1550161955.697201: Decrypted AS reply; session key is: aes256-cts/DD7B
[3880] 1550161955.697220: FAST negotiation: unavailable
[3880] 1550161955.697239: Initializing FILE:/tmp/krb5cc_0 with default princ [email protected]
[3880] 1550161955.697329: Storing [email protected] -> krbtgt/[email protected] in FILE:/tmp/krb5cc_0
[3880] 1550161955.697364: Storing config in FILE:/tmp/krb5cc_0 for krbtgt/[email protected]: pa_type: 2
[3880] 1550161955.697394: Storing [email protected] -> krb5_ccache_conf_data/pa_type/krbtgt\/DOMAIN.INT\@DOMAIN.INT@X-CACHECONF: in FILE:/tmp/krb5cc_0
Authenticated to Kerberos v5
keytab 파일을 사용한 인증 실패:
root@my-server / # KRB5_TRACE=/dev/stdout kinit -V -k -t /etc/krb5/service_user.keytab service_user
Using default cache: /tmp/krb5cc_0
Using principal: [email protected]
Using keytab: /etc/krb5/service_user.keytab
[3844] 1550161914.505633: Getting initial credentials for [email protected]
[3844] 1550161914.505787: Looked up etypes in keytab: des-cbc-crc, des, des-cbc-crc, rc4-hmac, aes256-cts, aes128-cts
[3844] 1550161914.505838: Sending request (194 bytes) to DOMAIN.INT
[3844] 1550161914.505972: Sending initial UDP request to dgram 192.168.0.1:88
[3844] 1550161914.507116: Received answer (190 bytes) from dgram 192.168.0.1:88
[3844] 1550161914.507146: Response was from master KDC
[3844] 1550161914.507170: Received error from KDC: -1765328359/Additional pre-authentication required
[3844] 1550161914.507199: Processing preauth types: 16, 15, 19, 2
[3844] 1550161914.507216: Selected etype info: etype aes256-cts, salt "DOMAIN.INTdomainmember", params ""
[3844] 1550161914.507263: Retrieving [email protected] from FILE:/etc/krb5/service_user.keytab (vno 0, enctype aes256-cts) with result: 0/Succes-s
[384] 1550161914.507280: AS key obtained for encrypted timestamp: aes256-cts/3ABA
[3844] 1550161914.507329: Encrypted timestamp (for 1550161914.976630): plain 301AA011180F32303139303231343136333135345AA10502030EE6F6, encrypted BD37FD997AD3BB56EA1893F99CDCDC7AF49964AC65E686316BE58F545609C3EE15E5753D57B9812794EB480E7F3D2B61613B2F9518DB5841
[3844] 1550161914.507344: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
[3844] 1550161914.507353: Produced preauth for next request: 2
[3844] 1550161914.507371: Sending request (274 bytes) to DOMAIN.INT
[3844] 1550161914.507407: Sending initial UDP request to dgram 192.168.0.1:88
[3844] 1550161914.513601: Received answer (156 bytes) from dgram 192.168.0.1:88
[3844] 1550161914.513649: Response was from master KDC
[3844] 1550161914.513665: Received error from KDC: -1765328360/Preauthentication failed
[3844] 1550161914.513684: Preauth tryagain input types: 16, 15, 19, 2
kinit: Preauthentication failed while getting initial credentials
업데이트 2019-09-02: 해결책을 찾지 못했고 대신 파이프를 사용하여 비밀번호를 kinit에 전달했습니다.
답변1
나는 똑같은 문제에 직면하고 있습니다. 근본 원인은 Kerberos 서버가 rc4-hmac 암호화 유형만 지원하기 때문입니다.
해결책:ktutil에서 사용됨
ktutil: addent -password -p foo@bar -k 0 -e rc4-hmac
Password for foo@bar:
ktutil: wkt foo.keytab
ktutil: quit
ktinit -kt foo.keytab foo
이것은 나에게 효과적입니다. 그래도 문제가 해결되지 않으면 다양한 암호화 유형을 한 번에 모두 시도해 보십시오.
답변2
sAMAccountName우리도 동일한 문제가 있었고 도메인 계정이 다른 // CN( name모든 계정이 원래 생성되었을 때와 다른 것으로 업데이트됨)를 사용하도록 업데이트되었기 때문이라는 것을 알았습니다 .
우리가 문제를 인식하게 만드는 것은 다음과 같습니다.
Selected etype info: etype aes256-cts, salt "DOMAIN.INTdomainmember", params ""
우리의 경우 salt값은 업데이트된 이름이 아닌 원래 이름을 나타냅니다. 원래 질문의 출력 예에서 salt는 입니다 . 이는 (명령에 사용된 것과 같이 ) DOMAIN.INTdomainmember도메인 계정 이름을 의미 domainmember하지 않습니다 .service_userkinit
해결 방법은 서비스 계정을 삭제하고 다시 생성하여(처음부터 올바른/필요한 이름으로) 문제를 해결하는 것이었습니다.
Kerberos를 좋아해야 합니다!