Learn more about these different git repos.
Other Git URLs
https://bugzilla.redhat.com/show_bug.cgi?id=811375 (Fedora)
It seems that when using krb5_get_init_creds_keytab(), if we don't have a keytab entry with a key using the first valid etype offered by the server, then the authentication fails. For example the keytab created by samba using 'net ads keytab create' contains: 3 STEF-DESKTOP$@AD.THEWALTER.LAN (des-cbc-crc) 3 STEF-DESKTOP$@AD.THEWALTER.LAN (des-cbc-md5) 3 STEF-DESKTOP$@AD.THEWALTER.LAN (arcfour-hmac) However when I try to use this keytab with SSSD and my Windows 2008 Server, I get the following failure: (Tue Apr 10 22:21:54 2012) [[sssd[ldap_child[9108]]]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab (Tue Apr 10 22:21:54 2012) [[sssd[ldap_child[9108]]]] [find_principal_in_keytab] (0x0080): No principal matching stef-desktop.thewalter.lan$@AD.THEWALTER.LAN found in keytab. (Tue Apr 10 22:21:54 2012) [[sssd[ldap_child[9108]]]] [select_principal_from_keytab] (0x0200): Selected principal: STEF-DESKTOP$@AD.THEWALTER.LAN (Tue Apr 10 22:21:54 2012) [[sssd[ldap_child[9108]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [STEF-DESKTOP$@AD.THEWALTER.LAN] [9108] 1334089314.79075: Getting initial credentials for STEF-DESKTOP$@AD.THEWALTER.LAN [9108] 1334089314.79235: Sending request (196 bytes) to AD.THEWALTER.LAN [9108] 1334089314.80090: Resolving hostname dc.ad.thewalter.lan. [9108] 1334089314.80804: Sending initial UDP request to dgram 192.168.12.10:88 [9108] 1334089314.82538: Received answer from dgram 192.168.12.10:88 [9108] 1334089314.82777: Response was not from master KDC [9108] 1334089314.82798: Received error from KDC: -1765328359/Additional pre-authentication required [9108] 1334089314.82834: Processing preauth types: 16, 15, 19, 2 [9108] 1334089314.82847: Selected etype info: etype aes256-cts, salt "AD.THEWALTER.LANhoststef-desktop.ad.thewalter.lan", params "" [9108] 1334089314.100867: Retrieving STEF-DESKTOP$@AD.THEWALTER.LAN from FILE:/etc/krb5.keytab (vno 0, enctype aes256-cts) with result: -1765328203/No key table entry found for STEF-DESKTOP$@AD.THEWALTER.LAN [9108] 1334089314.100973: Preauth module encrypted_timestamp (2) (flags=1) returned: -1765328203/No key table entry found for STEF-DESKTOP$@AD.THEWALTER.LAN [9108] 1334089314.101033: Produced preauth for next request: (empty) [9108] 1334089314.101101: Getting initial credentials for STEF-DESKTOP$@AD.THEWALTER.LAN [9108] 1334089314.101199: Sending request (196 bytes) to AD.THEWALTER.LAN (master) (Tue Apr 10 22:21:54 2012) [[sssd[ldap_child[9108]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Generic preauthentication failure As you'll note kerberos selected the aes256-cts enctype as that was the first one offered by the server. However our keytab didn't contain that enctype. After applying the patch we see the following behavior: (Tue Apr 10 22:21:30 2012) [[sssd[ldap_child[8434]]]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab (Tue Apr 10 22:21:30 2012) [[sssd[ldap_child[8434]]]] [find_principal_in_keytab] (0x0080): No principal matching stef-desktop.thewalter.lan$@AD.THEWALTER.LAN found in keytab. (Tue Apr 10 22:21:30 2012) [[sssd[ldap_child[8434]]]] [select_principal_from_keytab] (0x0200): Selected principal: STEF-DESKTOP$@AD.THEWALTER.LAN (Tue Apr 10 22:21:30 2012) [[sssd[ldap_child[8434]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [STEF-DESKTOP$@AD.THEWALTER.LAN] (Tue Apr 10 22:21:30 2012) [[sssd[ldap_child[8434]]]] [ldap_child_get_tgt_sync] (0x0200): Loaded 3 enctypes from keytab for STEF-DESKTOP$@AD.THEWALTER.LAN [8434] 1334089290.741565: Getting initial credentials for STEF-DESKTOP$@AD.THEWALTER.LAN [8434] 1334089290.741696: Sending request (193 bytes) to AD.THEWALTER.LAN [8434] 1334089290.742423: Resolving hostname dc.ad.thewalter.lan. [8434] 1334089290.743722: Sending initial UDP request to dgram 192.168.12.10:88 [8434] 1334089290.745430: Received answer from dgram 192.168.12.10:88 [8434] 1334089290.745716: Response was not from master KDC [8434] 1334089290.745745: Received error from KDC: -1765328359/Additional pre-authentication required [8434] 1334089290.745783: Processing preauth types: 16, 15, 11, 19, 2 [8434] 1334089290.745805: Selected etype info: etype rc4-hmac, salt "", params "" [8434] 1334089290.745820: Selected etype info: etype rc4-hmac, salt "", params "" [8434] 1334089290.760170: Retrieving STEF-DESKTOP$@AD.THEWALTER.LAN from FILE:/etc/krb5.keytab (vno 0, enctype rc4-hmac) with result: 0/Success [8434] 1334089290.760229: AS key obtained for encrypted timestamp: rc4-hmac/470C [8434] 1334089290.760291: Encrypted timestamp (for 1334089290.760238): plain 301AA011180F32303132303431303230323133305AA10502030B99AE, encrypted 546748A09B9 7ED96144527146CA931F16256EB5C918CBA546E5983AEBDF09E274134A0D41423F5F2A409BEC3A4 D1172A2069407B [8434] 1334089290.760309: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success [8434] 1334089290.760319: Produced preauth for next request: 2 [8434] 1334089290.760340: Sending request (269 bytes) to AD.THEWALTER.LAN [8434] 1334089290.760964: Resolving hostname dc.ad.thewalter.lan. [8434] 1334089290.761391: Sending initial UDP request to dgram 192.168.12.10:88 [8434] 1334089290.762394: Received answer from dgram 192.168.12.10:88 [8434] 1334089290.762586: Response was not from master KDC [8434] 1334089290.762620: AS key determined by preauth: rc4-hmac/470C [8434] 1334089290.762658: Decrypted AS reply; session key is: rc4-hmac/2600 [8434] 1334089290.762666: FAST negotiation: unavailable [8434] 1334089290.762707: Initializing FILE:/data/build/sssd/var/lib/sss/db/ccache_AD.THEWALTER.LAN with default princ STEF-DESKTOP$@AD.THEWALTER.LAN Version-Release number of selected component (if applicable): git master as of today. 1.8.90 is in version.m4 I also posted a patch upstream, in case the mit krb5 guys think that they should be doing this automatically. But in any case this is a fix we want for RHEL7, whether upstream or here in sssd.
Fields changed
blockedby: => blocking: => coverity: => feature_milestone: => milestone: NEEDS_TRIAGE => SSSD 1.9.0 tests: => 0 testsupdated: => 0 upgrade: => 0
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=811982
rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=811375 811375] => [https://bugzilla.redhat.com/show_bug.cgi?id=811375 811375], [https://bugzilla.redhat.com/show_bug.cgi?id=811982 811982]
Fixed by 4c157ec
component: SSSD => Kerberos Provider milestone: SSSD 1.9.0 => SSSD 1.9.0 beta 1 owner: somebody => stefw version: => master
resolution: => fixed status: new => closed
Also backported to 1.8.x: - fbd3a26 - 6da9b3b (fix for #1330)
Metadata Update from @dpal: - Issue assigned to stefw - Issue set to the milestone: SSSD 1.9.0 beta 1
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/2339
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.