[Freeipa-users] Not able to get kerberos ticket from keytab

Fri Feb 26 09:29:44 UTC 2016

Thanks. It's working now using ipa-getkeytab.

Correct me if I am wrong (as I am new to freeipa), using ktutil I could add
multiple user in a keytab file (correct???) but in this case using
ipa-getkeytab can I do the same?

On Fri, Feb 26, 2016 at 9:15 PM, David Kupka <dkupka at redhat.com> wrote:

> On 26/02/16 08:56, David Kupka wrote:
>
>> On 26/02/16 02:22, Teik Hooi Beh wrote:
>>
>>> Hi,
>>>
>>> I have manged to deployed 1 ipa master and 1 ipa client with success on
>>> centos 7.2 with freeipa v4.2. I also managed to create user and set
>>> sshd-rules to for ttester user and also successfully get krb ticket
>>> using *kinit
>>> ttester at EXAMPLE.MY*. I am trying to deploy password-less SSH login with
>>> kerberos using the following guide  (
>>>
>>> https://uz.sns.it/~enrico/wordpress/2014/03/password-less-ssh-login-with-kerberos/
>>> )
>>>
>>> -
>>>
>>> snippet -
>>>
>>>
>>>
>>> *$ ktutil ktutil: add_entry -password -p ttester at EXAMPLE.MY -k 1 -e
>>> aes256-cts-hmac-sha1-96 ktutil: write_kt keytab*
>>>
>>> When I tried *kinit -kt keytab ttester at EXAMPLE.MY*, I get *"**kinit:
>>> Password incorrect while getting initial credentials"*
>>> Doing a trace using KRB5_TRACE on both calls
>>>
>>> *1. KRB5_TRACE=/dev/stderr kinit ttester at EXAMPLE.MY*
>>> 27242] 1456447025.219676: Getting initial credentials for
>>> ttester at EXAMPLE.MY
>>> [27242] 1456447025.222070: Sending request (164 bytes) to EXAMPLE.MY
>>> [27242] 1456447025.222223: Resolving hostname node1.example.my
>>> [27242] 1456447035.238004: Initiating TCP connection to stream
>>> 192.168.38.2:88
>>> [27242] 1456447035.238675: Sending TCP request to stream 192.168.38.2:88
>>> [27242] 1456447035.241248: Received answer (337 bytes) from stream
>>> 192.168.38.2:88
>>> [27242] 1456447035.241257: Terminating TCP connection to stream
>>> 192.168.38.2:88
>>> [27242] 1456447035.241377: Response was from master KDC
>>> [27242] 1456447035.241437: Received error from KDC:
>>> -1765328359/Additional
>>> pre-authentication required
>>> [27242] 1456447035.241484: Processing preauth types: 136, 19, 2, 133
>>> [27242] 1456447035.241499: Selected etype info: etype aes256-cts, salt
>>> "s`GD^,#=cA:Vr9hD", params ""
>>> [27242] 1456447035.241504: Received cookie: MIT
>>> Password for ttester at EXAMPLE.MY:
>>> [27242] 1456447062.215750: AS key obtained for encrypted timestamp:
>>> aes256-cts/73C6
>>> [27242] 1456447062.215815: Encrypted timestamp (for 1456447062.215315):
>>> plain 301AA011180F32303136303232363030333734325AA1050203034913, encrypted
>>>
>>> F9A2E97E916FC14D141690E151A25DCC00168361179C7F0ACDA94C7F58F3D50429780A5608A6B8623E355F2A5BD676F6FA5272D38FD05C8B
>>>
>>> [27242] 1456447062.215942: Preauth module encrypted_timestamp (2) (real)
>>> returned: 0/Success
>>> [27242] 1456447062.215948: Produced preauth for next request: 133, 2
>>> [27242] 1456447062.215965: Sending request (257 bytes) to EXAMPLE.MY
>>> [27242] 1456447062.216010: Resolving hostname node1.example.my
>>> [27242] 1456447072.229254: Initiating TCP connection to stream
>>> 192.168.38.2:88
>>> [27242] 1456447072.229655: Sending TCP request to stream 192.168.38.2:88
>>> [27242] 1456447072.236955: Received answer (722 bytes) from stream
>>> 192.168.38.2:88
>>> [27242] 1456447072.236974: Terminating TCP connection to stream
>>> 192.168.38.2:88
>>> [27242] 1456447072.237080: Response was from master KDC
>>> [27242] 1456447072.237117: Processing preauth types: 19
>>> [27242] 1456447072.237125: Selected etype info: etype aes256-cts, salt
>>> "s`GD^,#=cA:Vr9hD", params ""
>>> [27242] 1456447072.237131: Produced preauth for next request: (empty)
>>> [27242] 1456447072.237140: AS key determined by preauth: aes256-cts/73C6
>>> [27242] 1456447072.237199: Decrypted AS reply; session key is:
>>> aes256-cts/2A71
>>> [27242] 1456447072.237216: FAST negotiation: available
>>> [27242] 1456447072.237236: Initializing KEYRING:persistent:1000:1000 with
>>> default princ ttester at EXAMPLE.MY
>>> [27242] 1456447072.237275: Storing ttester at EXAMPLE.MY ->
>>> krbtgt/EXAMPLE.MY at EXAMPLE.MY in KEYRING:persistent:1000:1000
>>> [27242] 1456447072.237330: Storing config in KEYRING:persistent:1000:1000
>>> for krbtgt/EXAMPLE.MY at EXAMPLE.MY: fast_avail: yes
>>> [27242] 1456447072.237345: Storing ttester at EXAMPLE.MY ->
>>>
>>> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY at X-CACHECONF
>>> :
>>>
>>> in KEYRING:persistent:1000:1000
>>> [27242] 1456447072.237371: Storing config in KEYRING:persistent:1000:1000
>>> for krbtgt/EXAMPLE.MY at EXAMPLE.MY: pa_type: 2
>>> [27242] 1456447072.237380: Storing ttester at EXAMPLE.MY ->
>>> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY at X-CACHECONF
>>> :
>>> in KEYRING:persistent:1000:1000
>>>
>>> *2. KRB5_TRACE=/dev/stderr kinit -kt keytab ttester at EXAMPLE.MY*
>>> [27248] 1456447236.144685: Getting initial credentials for
>>> ttester at EXAMPLE.MY
>>> [27248] 1456447236.147107: Looked up etypes in keytab: aes256-cts
>>> [27248] 1456447236.147255: Sending request (164 bytes) to EXAMPLE.MY
>>> [27248] 1456447236.147381: Resolving hostname node1.example.my
>>> [27248] 1456447246.161528: Initiating TCP connection to stream
>>> 192.168.38.2:88
>>> [27248] 1456447246.161970: Sending TCP request to stream 192.168.38.2:88
>>> [27248] 1456447246.164772: Received answer (337 bytes) from stream
>>> 192.168.38.2:88
>>> [27248] 1456447246.164791: Terminating TCP connection to stream
>>> 192.168.38.2:88
>>> [27248] 1456447246.164904: Response was from master KDC
>>> [27248] 1456447246.164943: Received error from KDC:
>>> -1765328359/Additional
>>> pre-authentication required
>>> [27248] 1456447246.164987: Processing preauth types: 136, 19, 2, 133
>>> [27248] 1456447246.164997: Selected etype info: etype aes256-cts, salt
>>> "s`GD^,#=cA:Vr9hD", params ""
>>> [27248] 1456447246.165001: Received cookie: MIT
>>> [27248] 1456447246.165142: Retrieving ttester at EXAMPLE.MY from
>>> FILE:keytab
>>> (vno 0, enctype aes256-cts) with result: 0/Success
>>> [27248] 1456447246.165166: AS key obtained for encrypted timestamp:
>>> aes256-cts/0A17
>>> [27248] 1456447246.165210: Encrypted timestamp (for 1456447246.164647):
>>> plain 301AA011180F32303136303232363030343034365AA1050203028327, encrypted
>>>
>>> C092E6C29FC1CD794625CF12162D18767A68D1728E6C2ADC1F50492D6605E039B664213C29767715E04B3CA8D97EBD691BBF40B76370C9FA
>>>
>>> [27248] 1456447246.165224: Preauth module encrypted_timestamp (2) (real)
>>> returned: 0/Success
>>> [27248] 1456447246.165228: Produced preauth for next request: 133, 2
>>> [27248] 1456447246.165239: Sending request (257 bytes) to EXAMPLE.MY
>>> [27248] 1456447246.165253: Resolving hostname node1.example.my
>>> [27248] 1456447256.178637: Initiating TCP connection to stream
>>> 192.168.38.2:88
>>> [27248] 1456447256.179456: Sending TCP request to stream 192.168.38.2:88
>>> [27248] 1456447256.184929: Received answer (167 bytes) from stream
>>> 192.168.38.2:88
>>> [27248] 1456447256.184941: Terminating TCP connection to stream
>>> 192.168.38.2:88
>>> [27248] 1456447256.185043: Response was from master KDC
>>> [27248] 1456447256.185065: Received error from KDC: -1765328353/Decrypt
>>> integrity check failed
>>> kinit: Password incorrect while getting initial credentials
>>>
>>> From the 2 trace I notice the return bytes on return from calling using
>>>>
>>> keytab is only 167 bytes compare to 722 bytes. Does anybody know the
>>> reasons or could point me to where I could debug further?
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>> Hello!
>>
>> I don't know why it does not work with ktutil but I've find other way
>> how to get keytab for a user:
>>
>> $ kinit ttester
>> $ ipa-getkeytab -p ttester at EXAMPLE.TEST -k ttester.keytab -e
>> aes256-cts-hmac-sha1-96
>> $ kdestroy ttester
>> $ kinit ttester at EXAMPLE.TEST -kt ttester.keytab
>>
>> HTH,
>>
>>
> Oh, I forget to mention that this also sets random krbPrincipalKey for the
> user so you can kinit only with the keytab. ipa-getkeytab has also option
> -r (--retrive) that should not change krbPrincipalKey but for some reason
> user is not allowed to retrieve it.
> You can of course add ACI to allow that but I would not do it because
> there's probably good reason why it's forbidden by default.
>
> --
> David Kupka
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160226/a4ce4248/attachment.htm>