Я борюсь с приложением Windows, которое использует MIT Kerberos для аутентификации.
Если пользователь входит в Windows с учетной записью пользователя домена, klist показывает, что он получает ожидаемые билеты от AD, включая эту:
#1> Client: jalf @ TESTREALM.COM
Server: krbtgt/TESTREALM.COM @ TESTREALM.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
Start Time: 1/12/2012 9:46:27 (local)
End Time: 1/12/2012 19:46:27 (local)
Renew Time: 1/19/2012 9:46:27 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Однако, когда мы пытаемся использовать этот билет в нашем приложении, библиотека Kerberos, похоже, не находит его.
Вот упрощенная версия соответствующего кода:
// Open the MSLSA cache
krb5_cc_resolve(kcontext, "MSLSA:", &mslsa_ccache);
// Create a cursor for traversing the cache
krb5_cc_start_seq_get(kcontext, mslsa_ccache, &cursor);
// Check all the credentials in the cache
while (!(code = krb5_cc_next_cred(kcontext, mslsa_ccache, &cursor, &creds))) {
// Find the one with the INITIAL flag set
if ( creds.ticket_flags & TKT_FLG_INITIAL ) {
// ticket found
krb5_free_cred_contents(kcontext, &creds);
break;
}
krb5_free_cred_contents(kcontext, &creds);
}
krb5_cc_end_seq_get(kcontext, mslsa_ccache, &cursor);
Но по какой-то причине мы никогда не войдем в часть // ticket found.
Запустив код в отладчике, я вижу, что он находит несколько других билетов, показанных klist, но по какой-то причине он никогда не находит тот, который нам интересен.
Может кто-нибудь объяснить это поведение, или как обойти это? Наивно, я ожидал бы, что выходные данные klist будут совпадать с результатами итерации по кешу с krb5_cc_next_cred.
Я относительно новичок в Kerberos и унаследовал этот код от ушедшего сотрудника, так что, возможно, мне не хватает какой-то важной фундаментальной информации.