#1297 Use keytab to select etypes for krb5_get_init_creds_keytab()
Closed: Fixed None Opened 8 years ago by dpal.

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

Fixed by 4c157ec

component: SSSD => Kerberos Provider
milestone: SSSD 1.9.0 => SSSD 1.9.0 beta 1
owner: somebody => stefw
version: => master

Fields changed

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

3 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata