Bug#698534: krb5-user: usage of keytabs gives Generic preauthentication failure while getting initial credentials
On Mon, 2013-05-27 at 18:04 -0400, Benjamin Kaduk wrote: Thanks for these. It looks like the salt that the KDC is sending back with the AS_REP is CERN.CHchristoph.anton.mitterer, but the salt that ktutil would use is just CERN.CHmitterer. Since these are not the same, the key generated by ktutil is different than the key on the KDC, and the encrypted timestamp preauthentication fails. I see... ktutil is not smart enough to allow the user to specify a non-default salt Given that this seems to be quite widespread then (I mean AD is evil, but used in many places)... do you seen any chances upstream, to extend ktutil accordingly? The arcfour enctypes presumably worked because they do not use the salt parameter for key generation. I can confirm this, with arc-four it works now on Debian as well,... analogously it doesn't work with aes on the other distros I've tested. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#698534: krb5-user: usage of keytabs gives Generic preauthentication failure while getting initial credentials
Well, is there any reason you're not using the full name for the principal in the keytab? in AD, i'd expect that to work too. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698534: krb5-user: usage of keytabs gives Generic preauthentication failure while getting initial credentials
On Tue, 2013-05-28 at 09:02 -0400, Sam Hartman wrote: Well, is there any reason you're not using the full name for the principal in the keytab? in AD, i'd expect that to work too. Uhm... the full name isn't the actual username,... and it seems neither it is known as a kerberos principal: $ kinit christoph.anton.mitte...@cern.ch kinit: Client not found in Kerberos database while getting initial credentials Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#698534: krb5-user: usage of keytabs gives Generic preauthentication failure while getting initial credentials
i think you need to reclose the bug not simply mark it as fixed again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698534: krb5-user: usage of keytabs gives Generic preauthentication failure while getting initial credentials
On Tue, 28 May 2013, Christoph Anton Mitterer wrote: ktutil is not smart enough to allow the user to specify a non-default salt Given that this seems to be quite widespread then (I mean AD is evil, but used in many places)... do you seen any chances upstream, to extend ktutil accordingly? I created ticket 7647 in our bug tracker (http://krbdev.mit.edu/rt/Ticket/Display.html?id=7647user=guestpass=guest) but I do not expect any action on it in the near future. -Ben -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698534: krb5-user: usage of keytabs gives Generic preauthentication failure while getting initial credentials
fixed 698534 1.11.2+dfsg-1 thanks On Sun, 26 May 2013, Christoph Anton Mitterer wrote: See the attachments (kinit for what happened with plain kinit, kutil for what happened with the keytab). Thanks for these. It looks like the salt that the KDC is sending back with the AS_REP is CERN.CHchristoph.anton.mitterer, but the salt that ktutil would use is just CERN.CHmitterer. Since these are not the same, the key generated by ktutil is different than the key on the KDC, and the encrypted timestamp preauthentication fails. ktutil is not smart enough to allow the user to specify a non-default salt; if your KDC is in fact AD, you may need to use a ktpass.exe utility to generate an AES keytab for your principal. The arcfour enctypes presumably worked because they do not use the salt parameter for key generation. -Ben Kaduk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698534: krb5-user: usage of keytabs gives Generic preauthentication failure while getting initial credentials
reopen 698534 stop Hi. Are you really sure that this has been fixed? $ apt-cache policy krb5-user krb5-user: Installed: 1.11.2+dfsg-1 $ kinit mitte...@cern.ch Password for mitte...@cern.ch: $ klist -e Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: mitte...@cern.ch Valid starting Expires Service principal 2013-05-26 12:04:33 2013-05-27 12:04:19 krbtgt/cern...@cern.ch Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 but: $ ktutil ktutil: addent -password -p mitte...@cern.ch -k 1 -e aes256-cts-hmac-sha1-96 Password for mitte...@cern.ch: ktutil: wkt kt ktutil: quit $ kinit -k -t kt mitte...@cern.ch kinit: Preauthentication failed while getting initial credentials Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#698534: krb5-user: usage of keytabs gives Generic preauthentication failure while getting initial credentials
On Sun, 26 May 2013, Christoph Anton Mitterer wrote: $ kinit mitte...@cern.ch Password for mitte...@cern.ch: $ klist -e Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: mitte...@cern.ch Valid starting Expires Service principal 2013-05-26 12:04:33 2013-05-27 12:04:19 krbtgt/cern...@cern.ch Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 but: $ ktutil ktutil: addent -password -p mitte...@cern.ch -k 1 -e aes256-cts-hmac-sha1-96 Password for mitte...@cern.ch: ktutil: wkt kt ktutil: quit $ kinit -k -t kt mitte...@cern.ch kinit: Preauthentication failed while getting initial credentials The key needed to decrypt the KDC's response to kinit's request depends not only on the password, but also on the salt string stored in the KDB and potentially a couple other parameters. There are default values which are probably being used here, but it is not necessarily so. kinit-with-a-password can adapt to what the KDC tells it, but ktutil must make a guess when addent -password is called. Because this mechanism (and really, a few others) are also possible explanations for your observed behavior, as well as the linked upstream issue, it is hard to say with any certainty what is going on. More information about what the kerberos library is doing is necessary for an accurate diagnosis. Can you run the two kinit commands with KRB5_TRACE set in the environment to the path to a log file and capture a trace log? (Use a different KRB5_TRACE setting for each run to get separate logfiles, please.) That will include the salt sent by the KDC and more details about what the library is doing. -Ben Kaduk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698534: krb5-user: usage of keytabs gives Generic preauthentication failure while getting initial credentials
Hey Benjamin. On Sun, 2013-05-26 at 15:17 -0400, Benjamin Kaduk wrote: Can you run the two kinit commands with KRB5_TRACE set in the environment to the path to a log file and capture a trace log? (Use a different KRB5_TRACE setting for each run to get separate logfiles, please.) That will include the salt sent by the KDC and more details about what the library is doing. See the attachments (kinit for what happened with plain kinit, kutil for what happened with the keytab). I censored, what looked like secret data ;) Cheers, Chris. [24117] 1369603888.278262: Getting initial credentials for mitte...@cern.ch [24117] 1369603888.289018: Sending request (158 bytes) to CERN.CH [24117] 1369603893.514896: Resolving hostname cerndc.cern.ch. [24117] 1369603893.605518: Sending initial UDP request to dgram 137.138.20.249:88 [24117] 1369603893.735136: Received answer from dgram 137.138.20.249:88 [24117] 1369603893.845196: Response was not from master KDC [24117] 1369603893.845293: Received error from KDC: -1765328359/Additional pre-authentication required [24117] 1369603893.845384: Processing preauth types: 16, 15, 19, 2 [24117] 1369603893.845422: Selected etype info: etype aes256-cts, salt CERN.CHchristoph.anton.mitterer, params [24117] 1369603893.845480: PKINIT client has no configured identity; giving up [24117] 1369603893.845497: Preauth module pkinit (16) (flags=1) returned: -1765328174/No user identity options specified [24117] 1369603893.845526: PKINIT client has no configured identity; giving up [24117] 1369603893.845538: Preauth module pkinit (15) (flags=1) returned: -1765328174/No user identity options specified [24117] 1369603913.385217: AS key obtained for encrypted timestamp: aes256-cts/55C4 [24117] 1369603913.385356: Encrypted timestamp (for 1369603915.187189): plain , encrypted [24117] 1369603913.385400: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success [24117] 1369603913.385412: Produced preauth for next request: 2 [24117] 1369603913.385450: Sending request (236 bytes) to CERN.CH [24117] 1369603918.895461: Resolving hostname cerndc.cern.ch. [24117] 1369603918.965134: Sending initial UDP request to dgram 137.138.20.249:88 [24117] 1369603919.85423: Received answer from dgram 137.138.20.249:88 [24117] 1369603919.155423: Response was not from master KDC [24117] 1369603919.155503: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP [24117] 1369603919.155523: Request or response is too big for UDP; retrying with TCP [24117] 1369603919.155537: Sending request (236 bytes) to CERN.CH (tcp only) [24117] 1369603919.265426: Resolving hostname cerndc.cern.ch. [24117] 1369603919.335384: Initiating TCP connection to stream 137.138.20.249:88 [24117] 1369603919.445027: Sending TCP request to stream 137.138.20.249:88 [24117] 1369603919.565683: Received answer from stream 137.138.20.249:88 [24117] 1369603919.665298: Response was not from master KDC [24117] 1369603919.665394: Processing preauth types: 19 [24117] 1369603919.665418: Selected etype info: etype aes256-cts, salt CERN.CHchristoph.anton.mitterer, params [24117] 1369603919.665435: Produced preauth for next request: (empty) [24117] 1369603919.665456: AS key determined by preauth: aes256-cts/55C4 [24117] 1369603919.665573: Decrypted AS reply; session key is: aes256-cts/B971 [24117] 1369603919.665589: FAST negotiation: unavailable [24117] 1369603919.665650: Initializing FILE:/tmp/krb5cc_1000 with default princ mitte...@cern.ch [24117] 1369603919.665851: Removing mitte...@cern.ch - krbtgt/cern...@cern.ch from FILE:/tmp/krb5cc_1000 [24117] 1369603919.665871: Storing mitte...@cern.ch - krbtgt/cern...@cern.ch in FILE:/tmp/krb5cc_1000 [24117] 1369603919.666029: Storing config in FILE:/tmp/krb5cc_1000 for krbtgt/cern...@cern.ch: pa_type: 2 [24117] 1369603919.666080: Removing mitte...@cern.ch - krb5_ccache_conf_data/pa_type/krbtgt\/CERN.CH\@CERN.CH@X-CACHECONF: from FILE:/tmp/krb5cc_1000 [24117] 1369603919.666099: Storing mitte...@cern.ch - krb5_ccache_conf_data/pa_type/krbtgt\/CERN.CH\@CERN.CH@X-CACHECONF: in FILE:/tmp/krb5cc_1000 [24141] 1369603943.589328: Destroying ccache FILE:/tmp/krb5cc_1000 [24335] 1369604170.264488: Getting initial credentials for mitte...@cern.ch [24335] 1369604170.270865: Looked up etypes in keytab: aes256-cts [24335] 1369604170.270938: Sending request (158 bytes) to CERN.CH [24335] 1369604170.470493: Resolving hostname cerndc.cern.ch. [24335] 1369604170.580479: Sending initial UDP request to dgram 137.138.20.248:88 [24335] 1369604170.700262: Received answer from dgram 137.138.20.248:88 [24335] 1369604170.790293: Response was not from master KDC [24335] 1369604170.790388: Received error from KDC: -1765328359/Additional pre-authentication required [24335] 1369604170.790481: Processing preauth
Bug#698534: krb5-user: usage of keytabs gives Generic preauthentication failure while getting initial credentials
So, if you type kinit foo@REALM then run kvno foo@REALM My suspicion is that to what extent kvno matters for tgts has changed recently. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698534: krb5-user: usage of keytabs gives Generic preauthentication failure while getting initial credentials
Hi Sam. On Tue, 2013-01-22 at 15:19 -0500, Sam Hartman wrote: So, if you type kinit foo@REALM then run kvno foo@REALM That doesn't work: $ kinit mitte...@cern.ch Password for mitte...@cern.ch: $ kvno mitte...@cern.ch kvno: Server not found in Kerberos database while getting credentials for mitte...@cern.ch The server is configured in /etc/krb5.conf. A short search at Google reveals that this might be somehow connected to AD being used in the background... The following works, though: $ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: mitte...@cern.ch Valid starting Expires Service principal 2013-01-23 00:25:42 2013-01-24 00:25:42 krbtgt/cern...@cern.ch $ kvno krbtgt/cern...@cern.ch krbtgt/cern...@cern.ch: kvno = 3 But using -k 3 in ktutil's addent doesn't help. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#698534: krb5-user: usage of keytabs gives Generic preauthentication failure while getting initial credentials
My guess is that you have the wrong kvno. Can you try runnig the kvno command on the principal in question immediately after a successful kinit? It's possible that your KDC won't let you find out the kvno that way in which case things are more difficult to diagnose. --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698534: krb5-user: usage of keytabs gives Generic preauthentication failure while getting initial credentials
Hi Sam. On Sun, 2013-01-20 at 17:41 -0500, Sam Hartman wrote: My guess is that you have the wrong kvno. That would be strange, cause I use the very same kvno on Scientific Linux (where it works). Also some of the CERN guys told me, it would be ignored for TGTs, but I'm by no means an expert in kerberos (since I never understood why it is strongly secure, as in my mind everything always fully depends just on the shared secret (the passphrase))... but I guess you guys know that better :) Can you try runnig the kvno command on the principal in question immediately after a successful kinit? You mean the manual kinit? What parameters should I use on kvno? I mean which service, which for_user etc.? It's possible that your KDC won't let you find out the kvno that way in which case things are more difficult to diagnose. :/ Thanks, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#698534: krb5-user: usage of keytabs gives Generic preauthentication failure while getting initial credentials
Package: krb5-user Version: 1.10.1+dfsg-3 Severity: important Hi (@Russ: This is partially also, what I wrote you already in private). It seems that Debians Kerberos have some problems with using keytabs, at least with some remote KDCs. What I do is always about this. 1) Creating a keytab with: $ ktutil ktutil: add_entry -password -p mitte...@cern.ch -k 1 -e arcfour-hmac-md5 Password for mitte...@cern.ch: ktutil: wkt keytab ktutil: q $ 2) Trying it out with: $ kinit -k -t keytab mitte...@cern.ch The password is always from the clipboard and correct as it works when I manually use kinit. When doing this under Scientific Linux 6, which has KRB 1.9, it just works as expected and I get my tgt. Under sid I get: kinit: Generic preauthentication failure while getting initial credentials Tried it of course with different algos, too, including aes256-cts-hmac-sha1-96 and des3-cbc-sha1. Under squeeze I get: kinit: Key table entry not found while getting initial credentials Interestingly, when using the realm/KDC of our local university, it works in Debian, too. According too the CERN support guys, they may be using ActiveDirectory. Could this be an error in either Debian itself or rather some upstream issue? Thanks, Chris. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.7-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages krb5-user depends on: ii krb5-config2.3 ii libc6 2.13-38 ii libcomerr2 1.42.5-1 ii libgssapi-krb5-2 1.10.1+dfsg-3 ii libgssrpc4 1.10.1+dfsg-3 ii libk5crypto3 1.10.1+dfsg-3 ii libkadm5clnt-mit8 1.10.1+dfsg-3 ii libkadm5srv-mit8 1.10.1+dfsg-3 ii libkdb5-6 1.10.1+dfsg-3 ii libkeyutils1 1.5.5-4 ii libkrb5-3 1.10.1+dfsg-3 ii libkrb5support01.10.1+dfsg-3 ii libss2 1.42.5-1 krb5-user recommends no packages. krb5-user suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
