Re: A problem with authentication
Server not found in database: afs/[EMAIL PROTECTED]: No such entry in the database Just ignore this error, its kinit/pam modules trying to do afslog and tries diffrent names for the service. You might have a [EMAIL PROTECTED] if cellname and realmname only differ in case-ing. and at the same time in heimdal-kdc log I find: AS-REQ [EMAIL PROTECTED] from IPv4:ipaddress for krbtgt/ [EMAIL PROTECTED] Using des-cbc-crc/des-cbc-crc Requested flags: renewable_ok, proxiable, forwardable sending 493 bytes to IPv4:ipaddress AS-REQ [EMAIL PROTECTED] from IPv4:ipaddress for krbtgt/ [EMAIL PROTECTED] Using des-cbc-crc/des-cbc-crc Requested flags: renewable_ok, proxiable, forwardable sending 493 bytes to IPv4:ipaddress To me this looks as though the login ought to have succeeded. Any clarification welcome. You should check for a TGS req just below it for host/[EMAIL PROTECTED] that the hosts uses to verify the login. Love
Re: renewing a forwardable ticket
19 mar 2007 kl. 01.20 skrev Jukka Salmi: Is this a bug or a feature? I would have expected a forwardable ticket to be still forwardable after being renewed, by default... Can you try heimdal 0.8 snapshot and see if that have the same behavior, I think I fixed a bug like this some time ago. Love
Re: database corruption
We have had the ipropd-master process die with the following error: Assertion failed: tmp == *len, file log.c, line 748 The only work around I could come up with was to move the slave databases out of the way and copy the database/log file from the master. This allowed replication to continue from this point on. This is running 0.7.1. Is there anything I can do to provide more information about this and prevent it from happening again? Sorry about the delay, on vacation. So the log file seem to be corrupted in the end, did your disk fill up at some point ? Love
Re: memory leak in krb5_rd_cred
21 feb 2007 kl. 14.31 skrev Henry B. Hotz: Been using the above mentioned fix, so not sure how much I care, but it might come back to haunt me. So if I parse this correctly, there is no longer any memory leaks ? Love
Re: database corruption
22 feb 2007 kl. 12.52 skrev Eric Sturdivant: Sorry about the delay, on vacation. So the log file seem to be corrupted in the end, did your disk fill up at some point ? Nope, we still have ~18gb free on that partition. Since the iprop log contains key information I don't want to ask for it, can you dump the database with dump_log and see where it break and then try do figure out how the last entry is broken. The each entry in iprop log ahve this format, the first entry operation is a NOP (no operation). /* * A log record consists of: * * version number4 bytes * time in seconds 4 bytes * operation (enum kadm_ops) 4 bytes * length of record 4 bytes * data... n bytes * length of record 4 bytes * version number4 bytes * */ Love
Re: AFS and keytab
13 feb 2007 kl. 06.58 skrev Andrew Bacchi: I'm not certain if this question belongs here or in the AFS list. Probably more of an AFS issue. I think you is missing a pts entry for this principal. I don't remember the kerberos 4 mapping to AFS mapping in AFS off my head, you need to check that with the afs folks. If you run kinit like this: kinit [argument] principal command -- command-arguments kinit will renew you tickets before they are about to expire (and renew afs tokens too) Love
Re: Keytab MEMORY in error message
Perhaps lib/krb5/keytab.c:krb5_kt_get_entry around line 372 should have: 371 krb5_kt_get_name (context, id, kt_name, sizeof(kt_name)); 372 krb5_enctype_to_string(context, enctype, enctype_str); if (kt_name[0] == '\0') strcpy(kt_name, MEMORY); 373 374 if (kvno) 375 snprintf(kvn... Otherwise you get: Failed to find [EMAIL PROTECTED](kvno 1) in keytab (des-cbc-crc) as opposed to the superior: Failed to find [EMAIL PROTECTED](kvno 1) in keytab MEMORY (des-cbc-crc) I'm splitting these issues. For the first one, will using krb5_kt_get_full_name() instead be acceptable to you ? Love
Re: Does this happen in the new mechglue too?
The issue was that trying to acquire a credential could result in a redundant AS-REQ. It turned out to be lib/mechglue/g_acquire_cred.c:gss_acquire_cred was looping over all mechanisms. The problem was that with SPNEGO it did KRB5 twice, once for KRB5 mech and once through SPNEGO mech calling KRB5. I added a clause that checked for mech-mech_type == GSS_SPNEGO_MECHANISM to skip that mech (unless it was explicitly specified). Please consider this condition wrt the new mechglue code if necessary. After a fast read though of the code it looks like this could still happen in the new mech-glue code. This is the second issue with gssapi mech-glue layer hides too much from SPNEGO. I need figure out the implications of this (split or merged mech-glue/SPNEGO). Love
Re: Detect when KRB5CCNAME changes for certain server scenarios
8 feb 2007 kl. 16.14 skrev Michael B Allen: Please consider the below patch. This will cause krb5_cc_set_default_name to be called if KRB5CCNAME changes at all. It assumes getenv returns the same address but if it does not the code is at least correct. Shouldn't all inputs that changes the default name affect the probe function Right now that is KRB5CCNAME and uid of the process. Also, if you use a static variable, you need to use a pthread mutex. In this case I don't think it would matter much, but better be safe. Love
Re: Keytab MEMORY in error message
8 feb 2007 kl. 15.49 skrev Michael B Allen:
Also, I would like to mention a very very minor issue related to the
message above.
If lib/krb5/get_in_tkt.c:init_as_req is called with krb5_kt_get_entry
as key_proc and it does not find the desired key, the enctype listed
in the error message will likely (always?) be 'des-cbc-crc'. This is
because it may search through archfour-hmac-md5, des-cbc-md5 and
finally
des-cbc-crc. So because des-cbc-crc is always last, it is what always
appears in the error text.
Anyway, my thought is that this very common error is a little
confusing. It's perfectly correct behavior but to an operator
debugging a
program, it will be a little confusing. If I was using archfour-
hmac-md5
and I saw 'des-cbc-crc' I would think that perhaps some keys were old
or messed up somewhere.
The ideal message IMHO would be something like:
Failed to find [EMAIL PROTECTED] in keytab MEMORY with kvno 1 and enctype
archfour-hmac-md5, des-cbc-md5 or des-cbc-crc.
I realize the state of the error is lost with each call to key_proc
but
if you're remotely interested in a patch I think I could add something
at the end of the if(preauth != NULL) { clause in init_as_req.
I don't suspect you'll want to bother but I didn't think it could hurt
to try :-)
I think you are right in that the error message should be better,
however
doesn't this happen when you do optimistic pre-auth type selection.
Ie, if you use NULL or KRB5_PADATA_NONE this doesn't happen.
Love
Re: gsskrb5_accept_delegated_token leaks a ccache
Doesn't the ccache = NULL in gsskrb5_accept_delegated_token prevent
id
from being closed?
180 (*delegated_cred_handle)-cred_flags |=
GSS_CF_DESTROY_CRED_ON_RELEASE;
181 ccache = NULL;
^^
182 }
183
184 out:
185 if (ccache) {
186 if (delegated_cred_handle == NULL)
187 krb5_cc_close(gssapi_krb5_context, ccache);
188 else
189 krb5_cc_destroy(gssapi_krb5_context, ccache);
Ah, you are running a diffrent version of what I'm using. Try apply
1.64 delta of that file, it will probably make you more happy.
Love
revision 1.64
date: 2006/10/25 04:19:45; author: lha; state: Exp; lines: +2 -1
(gsskrb5_accept_delegated_token): need to free ccache
--- heimdal/lib/gssapi/krb5/accept_sec_context.c 7 Oct 2006 22:13:53
- 1.63
+++ heimdal/lib/gssapi/krb5/accept_sec_context.c 25 Oct 2006 04:19:45
- 1.64
@@ -181,6 +181,7 @@ gsskrb5_accept_delegated_token
handle = (gsskrb5_cred) *delegated_cred_handle;
handle-cred_flags |= GSS_CF_DESTROY_CRED_ON_RELEASE;
+ krb5_cc_close(_gsskrb5_context, ccache);
ccache = NULL;
}
Re: password changes
Hello, I am using heimdal 0.7.2 with Openldap 2.3.32 backend. When I change passwords using MIT kpasswd from a RedHat 40 U4 server, the password changes however I don't see through kadmin? The password changed doesn't exist in in released heimdal, 0.8 will have support for it. The kadmin protocol supports its, just not the database back-ends. Love
heimdal 0.8-rc7
Hello I just cooked the heimdal 0.8-rc8 tar ball and Mac Universal Binary package, they are available here: ftp://ftp.pdc.kth.se/pub/heimdal/src/snapshots/heimdal-0.8-rc7.tar.gz ftp://ftp.pdc.kth.se/pub/heimdal/src/snapshots/heimdal-0.8-rc7.dmg Again, if you want binary packages generated for your operating system you need to step forward and contribute spec files and tell us if how to build the binaries and if you can build them. Some portability problems fixed, but most work have been on the digest kdc service. You are read more about the new digest service here: http://blogs.su.se/lha/Heimdal/ Expect a release before tueday morning unless something critical shows up, I've been running the new code in production on the KDCs since this week, this is not very strange for us since we have been running 0.8-ish code over the last year to take advantage of new features in the KDC. Love
Re: heimdal snapshot on debian (etch) segfaults when using LDAP backend.
1 feb 2007 kl. 06.37 skrev Mustafa A. Hashmi:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1214949696 (LWP 26400)]
LDAP__connect (context=0x8057030, db=0x80580c8) at hdb-ldap.c:1418
1418if (HDB2LDAP(db)) {
(gdb) bt
How about this patch ?
http://people.su.se/~lha/patches/heimdal/ldap-hdp.txt
Love
Re: PKinit
31 jan 2007 kl. 16.34 skrev Mustafa A. Hashmi: Hi all, A very simple pkinit setup just to test things up and running on debian etch. When I get a kerberos ticket via kinit -C FILE:user.crt,user.key, the following is logged in kdc.log: I assume your pem file is password protected ? What version of heimdal is this ? If you run code before heimdal-0.8- rc4 or 2007/01/09 I can understand why you get the log entry. Love
Re: rc4 make check hang
stepi hangs. Does not return to the debugger prompt. ^C bt Shows the same stack (as expected). Can you get trace from the kernel for that process ? Love
Re: Microsoft Cross Reference for PKINIT PKI Certs
26 jan 2007 kl. 20.18 skrev Henry B. Hotz: The Microsoft KB article referenced on the Heimdal PKINIT web page, 313274, seems to no longer be available. Is this one the correct replacement? http://support.microsoft.com/default.aspx?scid=kb;en-us;Q281245 No, its not, 313274 was a wrapper document that pointed to the following documents. 313557 HOW TO:Install a Smart Card Reader 228831 Cannot Overwrite Smart Card Key in Certificate Services Setup 231881 How to Install/Uninstall a Public Key Certificate Authority for Windows 2000 281245 Guidelines for Enabling Smart Card Logon with Third-Party Certification Authorities I don't see any references to any PKINIT OIDs in it, but it's what I found by googling for the title of the old one. For vista the requirements are the same as the PK-INIT RFC. Love
Re: rc4 make check hang
== All 1 tests passed == Making check in ftpd make check-local hang This is strange since check-local only checks that the command supports --version. Are you sure that the right process that is hanging ? Love
Re: heimdal 0.8-rc3
Love Hörnquist Åstrand wrote: 15 jan 2007 kl. 23.24 skrev Douglas E. Engert: The code was not checking if this was the case and always using the skey and thus would fail to decrypt PAC_SERVER_CHECKSUM. This is fixed by post 0.8-rc3, I got the same bug report from Andrew Bartlett. Are you sure this is correct you patch is correct, I would think it should use the o-ticket in the enc_tkt_in_skey case. I though that was what I did. If the KDC_OPT_ENC_TKT_IN_SKEY is on, then use the session key: o-ticket-ticket.key otherwise use the key used to decrypt the ticket whoich looked liek the o-keyblock. But looking closer at 791, if (ap_req.ap_options.use_sesion_key... Is this where the auth_context-keyblock is copied to the o-keyblock the key to be used? in which case the mod should always use the o- keytab. Then what is the o-ticket-ticket.key ? its the session key between the client and the server that is inside the ticket. But the text from the MS page say it should be use the key that was used to encrypt the ticket itself, and that is not the key inside that ticket. Do you have any setup where you can try out the u2u case easily in a windows domain ? No. I just tried it on my w2k3server setup by talking to myself and it wont even see the enc-tkt-in-skey flag since its on the server (not so helpfully named uu_client in appl/test in heimdal). Love
Re: heimdal 0.8-rc3
15 jan 2007 kl. 23.24 skrev Douglas E. Engert: The code was not checking if this was the case and always using the skey and thus would fail to decrypt PAC_SERVER_CHECKSUM. This is fixed by post 0.8-rc3, I got the same bug report from Andrew Bartlett. Are you sure this is correct you patch is correct, I would think it should use the o-ticket in the enc_tkt_in_skey case. Do you have any setup where you can try out the u2u case easily in a windows domain ? Love
Re: pkcs12
11 jan 2007 kl. 17.45 skrev Alberto Fondi: Yes the output for my certificate is Do you have any explaining error message in the kdc log, or it it just a client side failure (ie it looks like its ok in the KDC log) ? Love
Re: heimdal 0.8-rc3
Hello Chandrasekar Thanks Andrew found the problem yesterday too so I found the bug a day ago. Here is a patch that should fix the problem. http://people.su.se/~lha/patches/heimdal/plugin-dlopen-lazy.txt Love 9 jan 2007 kl. 16.21 skrev Chandrasekar Kannan: I see the following failure on i386 during gmake all check install gmake[3]: Leaving directory `/export/heimdal/heimdal-0.8-rc3/tests/ gss' gmake[2]: Leaving directory `/export/heimdal/heimdal-0.8-rc3/tests/ gss' Making check in plugin gmake[2]: Entering directory `/export/heimdal/heimdal-0.8-rc3/tests/ plugin' gmake check-TESTS check-local gmake[3]: Entering directory `/export/heimdal/heimdal-0.8-rc3/tests/ plugin' sed -e 's,[EMAIL PROTECTED]@],.,g' -e 's,[EMAIL PROTECTED]@],../../tests/ plugin,g' -e 's,[EMAIL PROTECTED]@],/bin/grep -E,g' ./check-pac.in check-pac.tmp chmod +x check-pac.tmp mv check-pac.tmp check-pac Creating database Doing database check Starting kdc Waiting for KDC to start, looking logfile messages.log Have waited 2 seconds Getting client initial tickets Getting tickets Verify PAC on server ap-req: get pac test failed signal killing kdc FAIL: check-pac 1 of 1 tests failed Please report to [EMAIL PROTECTED] gmake[3]: *** [check-TESTS] Error 1 gmake[3]: Leaving directory `/export/heimdal/heimdal-0.8-rc3/tests/ plugin' gmake[2]: *** [check-am] Error 2 gmake[2]: Leaving directory `/export/heimdal/heimdal-0.8-rc3/tests/ plugin' gmake[1]: *** [check-recursive] Error 1 gmake[1]: Leaving directory `/export/heimdal/heimdal-0.8-rc3/tests' gmake: *** [check-recursive] Error 1 [EMAIL PROTECTED] heimdal-0.8-rc3]# Love Hörnquist Åstrand wrote: Hello I've just created a heimdal 0.8-rc3 snapshot. ftp://ftp.pdc.kth.se/pub/heimdal/src/snapshots/heimdal-0.8-rc3.tar.ga ftp://ftp.pdc.kth.se/pub/heimdal/src/snapshots/heimdal-0.8-rc3.dmg Basicly what needs to happen before release is fixing (text) error message for GSS-API mech-glue layer and testing on more platforms. Testing is mostly automated and very simple to set up, please read here if you want to contribute. http://www.pdc.kth.se/heimdal/help/#buildfarm Love
Re: heimdal 0.8-rc3
9 jan 2007 kl. 20.27 skrev Douglas E. Engert: Removing the if and abort lines, so the modules and exponent can both be missing, allows it to work as the auth cert is present. Updated the comment and remove the abort(). Thanks! Love
Re: PAC failures in current heimdal
I'm having trouble with the PAC test in Heimdal. It looks to me like we hit an host-dependent bug, as some hosts fail the test: Yes, (at least some) Linux-is and solaris needs RTLD_LAZY. Fixed the tree, thanks. Love
Re: The errors during the execution of make command
15 dec 2006 kl. 18.25 skrev Alberto Fondi: These are the errors the make command gives me when i execute it. The snapshot is the last published vis.c:346:52: macro strsvisx passed 5 arguments, but takes just 4 vis.c: In function `rk_strvisx': try ftp://ftp.pdc.kth.se/pub/heimdal/src/snapshots/heimdal- alberto.tar.gz or tomorrows snapshot. vis.c no longer have that many lines, so I think you are running snapshot generated today. Love
Re: Should kadmin ask for password
6 dec 2006 kl. 23.39 skrev Hai Zaar: since I do not have kadmin/admin credential in cache. it will ask you for you password since the principal in the credental cache doesn't match what it think its the default (your principal with / admin added). If you specify the principal with -p it should work just fine. $ kinit [EMAIL PROTECTED]'s Password: $ klist Credentials cache: FILE:krb5cc_501 Principal: [EMAIL PROTECTED] Issued Expires Principal Dec 7 00:04:57 Dec 7 10:06:00 krbtgt/[EMAIL PROTECTED] Dec 7 00:04:58 Dec 7 10:06:00 [EMAIL PROTECTED] $ kadmin -p lha kadmin get lha Principal: [EMAIL PROTECTED] [...] kadmin ext -k /tmp/kaka host/nutcracker.it.su.se kadmin exit $ klist Credentials cache: FILE:krb5cc_501 Principal: [EMAIL PROTECTED] Issued Expires Principal Dec 7 00:04:57 Dec 7 10:06:00 krbtgt/[EMAIL PROTECTED] Dec 7 00:04:58 Dec 7 10:06:00 [EMAIL PROTECTED] Dec 7 00:05:07 Dec 7 01:05:07 kadmin/[EMAIL PROTECTED] $ kinit -t FILE:/tmp/kaka host/[EMAIL PROTECTED] $ klist Credentials cache: FILE:krb5cc_501 Principal: host/[EMAIL PROTECTED] Issued Expires Principal Dec 7 00:11:33 Dec 7 10:12:36 krbtgt/[EMAIL PROTECTED] Dec 7 00:11:34 Dec 7 10:12:36 [EMAIL PROTECTED] with this in the acl file: $ grep ^lha@ /var/heimdal/kadmind.acl [EMAIL PROTECTED] get [EMAIL PROTECTED] [EMAIL PROTECTED] add,get,modify,cpw,del host/nutcracker.it.su.se Love
Re: krb5-config --libs gssapi prints out -pthread - why makes this my build fail?
to the linker, but during linking (Linux x86)) ld fails with /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../../ i686-pc-linux-gnu/bin/ld: unrecognized option '-pthreads' I think, you should replace -pthread by -lpthread. Don't ask me how this came into your krb5-config. Its heimdal pthread test that failes to detect the right thing. I guess the test needs be split since for some platforms the pthread option for application is not the same as for libs. Any help to improve the situation would be appreciated. Love
Re: testing pkinit with gssmaestro/gssmask
4 dec 2006 kl. 23.36 skrev Olga Kornievskaia: Hi, I have a couple of questions: have you ever tested pkinit code with gssmonger/gssmaestro/gssmask? The reason i ask is that I don't see any way to actually pass in pkinit options to the code. kinit would usually call krb5_get_init_creds_opt_set_pkinit() before calling krb5_get_init_creds_password(). gssmask.c calls gss_import_name() followed by gss_init_sec_context() which will eventually call krb5_get_init_creds_password() but set_pkinit will not be called. I had no gssmonger that I knew supported pkinit (maybe I did), so I never implemented the code in the client. If you know how to test it, I'll complete the code. Love
Re: 4.23.2 Using Kerberos database
28 nov 2006 kl. 01.23 skrev Henry B. Hotz: That's a section of http://www.pdc.kth.se/heimdal/heimdal.html that isn't filled out. I would assume that it's intended to describe how to put the PKI cert name -- Kerberos Principal mapping into the database itself instead of in the cert's. That's allowed by the RFC, but perhaps not often done by people who *can* put them in the cert's. Should I conclude that the code to support that mode is likely to have bugs, or more politely, to be incomplete? The code is incomplete, there is backend support but no user interface to change the values. Love
Re: Is there no gss_nt_service_name in Heimdal Kerberos
17 nov 2006 kl. 15.47 skrev Harald Barth: Is gss_nt_service_name declared in Heimdal Kerberos? Heimdal uses GSS_C_NT_HOSTBASED_SERVICE as its defined in rfc2744. If not, what can I use to replace it? Yes, that would be nice to know. I may be stuck at the same spot trying to compile library cyrus-sasl 2.1.22 against heimdal 0.7.2. Any pointers? GSS_C_NT_HOSTBASED_SERVICE. Love
Re: config option inconsistencies
16 nov 2006 kl. 16.31 skrev Kevin Coffman: There are currently inconsistencies in the use of underscores and hyphens in the Heimdal (pkinit/pki) config parameters. I think there are also inconsistencies with pki- vs. pkinit- in some cases? Is it too late, too painful, to make these consistent at this point? No, its not. Prefix with pkinit and use _ ? Love
Re: About one unknown padata type 129
16 nov 2006 kl. 06.10 skrev Ralph: What's the meaning of 'not compatible'? Do you mean Heimdal has already know the structure of this piece of data (padata 129)? Or, does Heimdal use another approach to prived Constrained Delegation and Protocol Transition? There is a diffrent wireformat today since I don't know what the format was. Also note that since there is no PAC in Heimdal, there needs to be a diffrent solution for checking the validity of the request. See the end of tests/kdc/check-kdc.in how to use it. Love
Re: MacOSX: /Library/Preferences/edu.mit.Kerberos /etc/krb5.conf
I can't find any documentation about how /Library/Preferences/edu.mit.Kerberos, /etc/krb5.conf are read by libkrb and in what preference order conflicting entries are resolved. My ktrace output indicates that they are read both. Version is a snapshot from last month. /Library/Preferences/edu.mit.Kerberos is read before SYSCONFDIR /krb5.conf and /etc/krb5.conf Entires are appended (not overwritten). Love
Re: Problem installing pkinit
25 okt 2006 kl. 14.26 skrev Athanasios Moralis: and I found that if I put pkinit_require_eku=false I have a successful logging. :-) Setting win2k_pkinit_require_binding = yes did not affect the result. This is something that I should really look into it. Perhaps my certificate does not support eku or something else is happening. Yes, the RFC specifices a that the KDC to have PK-INIT KDC EKU set on it, I guess I should add a warning kdc startup code hinting that not having the EKU will cause interrop problems. Love
