kerberos ticket length and IP addresses
[this is largely a kerberos question, but I am cross posting in case anyone on the openafs mailing list may have had a similar experience] We are having two problems with larger krb5 afs/service tickets. Specifically when krb5_creds.ticket.length exceeds order of about 350 bytes we run into these two problems (the length tolerence differs slightly between the two issues): 1 - we are still running openafs 1.2.13 fileservers which don't seem to like the larger tickets, they treat requests as if the request came from: #define ANONYMOUSID 32766 so in effect, the tokens are useless 2 - on machines running older versions of the openafs client, ktc_SetToken fails as follows: nptest05:/u/cesarg$ aklog aklog: unable to obtain tokens for cell b.ny.ms.com (status: 11862789). nptest05:/u/cesarg# translate_et 11862789 11862789 (ktc).5 = AFS kernel pioctl doesn't exist Upgrading openafs servers is well under way, but realistically another 6 months before completion. Upgrading openafs clients is unfortunately much more difficult for us to do - largely due to [let's call it] political factors, that upgrade schedule is much much longer. We see these problems on client machines that have many (7 or 8) interfaces, as the TGTs we obtain are addressful - removing IP addresses (e.g., kinit -A) works, but unfortunately is not a short term option for us as this causes problems for legacy/interal apps built with *very* old krb5 libs - and unfortunately my team doesn't own those apps. As a workaround, we attempted to obtain afs service tickets via krb5_get_cred_via_tkt(), specifying an empty set of addresses (arg 4), but this doesn't seem to have any impact on the length of the resulting afs service ticket (cred.ticket.length). In fact if we request 0, 50, or 100 IPs via arg 4, it still doesn't seem to influence the length of the afs service ticket. The afs ticket length seems to be tied to the length of the tgt in all cases. Is this expected? I've yet to go deep enough into the relevent tgs req code to understand why this happens. Is there something else we could do that will result in smaller tickets. I realize our real problem is political, a short term answer for us unfortunately cannot require that we strip IPs from our TGTs, or require openafs client and server upgrades - these contraints are horrible - believe me, none of us are happy about it ... not looking for sympathy :-) Are there any additional details we can provide that would help. I suppose it is possible our code/workaround is simply coded incorrectly. I'd be willing to send out code if someone thinks that is the case. Any help in understanding this is greatly appreciated. Thanks. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
According to strace ... 1.2.8 app server with named credential - opens an rcache. 1.3.1 app server with no credential - no evidence of rcache being opened. wrt to krb5_rd_req - it looks like rcache is obtained only if auth_context_flags includes KRB5_AUTH_CONTEXT_DO_TIME. accept_sec_context clearly sets auth_context with KRB5_AUTH_CONTEXT_DO_SEQUENCE. What am I missing? Sam == Sam Hartman [EMAIL PROTECTED] writes: Cesar == Cesar Garcia [EMAIL PROTECTED] writes: Cesar wrt to gssapi and 1.3.1 ... Cesar Since we're pointing out lack of replay cache detection, Cesar note that if acquiring creds for GSS_C_NO_NAME, then no Cesar replay cache is used. (specifically looking at 1.3.1 - Cesar lib/gssapi/krb5/acquire_cred.c) Sam I think that's false. I believe that krb5_rd_req will end up setting Sam up a rcache later. Sam I don't have time to go look through the code now though, but I wrote Sam it and at least intended that a replay cache would get used even Sam though it does not get stored in the GSSAPI credentials structure. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: I am stuck at krb5_cc_initialize, how to check?
Are you building your own app or is this from one of the stock applications? Can you provide a stack trace and other relevent details that you can obtain from your debugger? Which version of the kerberos libraries does this application use, did you build your own are you using libraries provided by your OS vendor. If you built the kerberos libraries yourself, can you tell us something about how you built the kerberos libraries (what version, what platform, configure/compiler options, etc) and something about the circumstance under which you see this error. Do you have similar apps that work. Is this a multi-threaded app, etc. A trace (from truss/strace or truss -u, ltrace, depending on what platform and what you have available) might be useful. Grace == Grace Tsai [EMAIL PROTECTED] writes: Grace Hi, Grace I am sorry to keep bothering you about this problem. But I am stuck at Grace the Grace function krb5_cc_initialize, I have got core file when this function is Grace called. Grace By using dbx to analyze the core file, I got Grace Segmentation fault in krb5_cc_initialize at line 49 in file Grace could not read ccfns.c Grace The line 49 of ccfns.c is Grace return cache-ops-init(context,cache,principal); Grace I really dont know how to debug this. Grace I guess I like to ask now is how do I Grace check item by item (variable by variable) that the contents of the Grace inputs Grace to this function is correct. Grace code = krb5_cc_initialize(k5context, Graceccache, Graceprincipal); Grace Thanks a million in advance. Grace Grace Grace Grace Kerberos mailing list [EMAIL PROTECTED] Grace https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kerberos ftpd bug? can't get it to work (New, sort of)
You can also inspect for which principal a service ticket was acquired, on the client side via klist. Make sure there is a corresponding keytab entry for this principal on the target host (klist -k). Ken == Ken Hornstein [EMAIL PROTECTED] writes: GSSAPI accepted as authentication type GSSAPI error major: Miscellaneous failure GSSAPI error minor: No principal in keytab matches desired name Ken If you turn on ftpd debugging (-d), ftpd will log a whole bunch of crap Ken to syslog. One of the things it logs is the name it's trying to use Ken locally. I suspect that the problem is something akin to listing the Ken short name of the host first in /etc/hosts. Ken --Ken Ken Ken Kerberos mailing list [EMAIL PROTECTED] Ken https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
no file locking used when reading/writing replay cache?
short: There does not appear to be use of file locks when reading/writing to replay cache files. long: We are implementing gss authentication via client and server side security exits invoked by a vendor application. The application is both multi-processed and multi-threaded. We have applied various patches in order to get this code to run cleanly under Purify and use a mutex in both the client and server side to serialize the entire sequence of gss calls (within a single process only, of course). Under extremely high load (note this involves multiple app-server processes), we are getting SEGVs in our security exit. Unfortunately the vendor product catches SEGV, so getting a core, stack trace, etc, will involve some work. In the mean time, I noticed that there is no use of file locking when reading/writing to the replay cache. Unfortunately, I also don't have copy of the replay cache file for us to examine. I wish I had more to work with - I'm working with the application team to get better data. However, even if this is not the cause of the problem we saw, I thought it might be worth raising this issue. Any insight would be appreciated. Thanks, Cesar Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
gss_accept_sec_context server principal
Hi, I'm am trying to change the behavior of a functioning GSS-enabled application server such that the server principal and corresponding keytab entry used by gss_accept_sec_context is determined dynamically based on the server principal named in the client's ticket (implicitly specified by the input token to gss_accept_sec_context). There are various reasons for wanting to do this. Migrating to DNS is one - we would like to isolate applications from naming changes on the client hosts (or the server hosts for that matter) so that application servers can accept tickets for either: service/short_name@MS.COM service/short_name[EMAIL PROTECTED] thereby, allowing various client/hosts to migrate to DNS independently. service is generally the name of the application. short_name is the short name (our current hostname resolution renders short names). This short name could either be an actual host name or a one of several VCS service name. In other words, there could be many permutations, and I would like avoid any brute force approaches where I try every possible server principal name. [of course, I would populate the application server's keytab file with all of the necessary keytab entries so that it can assume any of the above identities - in fact this works already for kshd/klogind, which of course are not written with GSSAPI] My first attempt was to specify GSS_C_NO_CREDENTIAL for the verifier credential handle. This appeared to reveal a bug in gss_accept_sec_context(): (I'll send a separate email to [EMAIL PROTECTED] about this). == start bug description == krb5_gss_accept_sec_context acquires a default cred via krb5_gss_acquire_cred, if the supplied verifier_cred handle is GSS_C_NO_CREDENTIAL - which is places in the variable cred_handle It then proceeds to try to validate verifier_cred_handle, which in my case is GSS_C_NO_CREDENTIAL, rather than the new obtained credential (cred_handle). So this fails unnecessarily. So I fix this so that it validates cred_handle (which it obtains) rather than verifier_cred_handle (GSS_C_NO_CREDENTIAL). == end bug description == Nonetheless, in obtaining a credential handle, krb5_gss_acquire_cred will determine the server principal name. As invoked by krb5_gss_accept_sec_context, it will obtain a handle to the credential based on logic for GSS_C_NO_NAME and GSS_C_ACCEPT (cred_usage supplied by krb5_gss_accept_sec_context). In doing so, it invokes krb5_sname_to_principal, which determine the default principal name based on hostname and sname arguments (both NULL). This results in a server principal name constructed from an sname of host and a hostname based on gethostname which is then resolved via gethostbyname/gethostbyaddr. krb5_gss_acquire_cred then attempts to extract the keytab entry for this principal. Of course, this is not what I want. Calling gss_acquire_cred from my application using GSS_C_NO_NAME has the same affect. Has anyone attempted to write a GSS-enabled application server that can assume more than one different identities, based on the server principal name specified in the client's ticket. Is there another approach that will allow me to do this? The only other thought I have is to try to extract the server principal name for the token supplied by the client. This, however, seems like I am breaking rules by not treating tokens as opaque objects. I haven't investigated this approach yet, I was hoping there was a more natural approach than this. Any suggestions are highly appreciated. Thanks, Cesar Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: krb524d, aklog and AFS tokens
Understood, I've just been delaying for no good reason. I'll find time one of these weekends to submit various patches. Thanks. Sam == Sam Hartman [EMAIL PROTECTED] writes: Cesar == Cesar Garcia [EMAIL PROTECTED] writes: Cesar I've been meaning to submit a patch for this to Cesar [EMAIL PROTECTED]: *** krb524d.c Wed Mar 5 19:24:17 2003 Cesar --- krb524d.c.new Wed Mar 5 19:33:44 2003 *** Sam If you expect a patch like this to get reviewed and applied: Sam 1) You do actually need to submit it to krb5-bugs Sam 2) Describe what problem it exists Sam 3) Describe why you see the problem and others might not. This is Samparticularly important in this instance as krb524d is very clearly Samnot broken for most users. Sam --Sam Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: afs-krb5 integration
We haven't had problems with it. We've only recently started rolling out OpenAFS. Klaas == Klaas Hagemann [EMAIL PROTECTED] writes: Klaas Hi Cesar, thanks for your quick help. I supposed, i woould Klaas have searched a long time for this bug. But with your Klaas patch, the krb524d works good together with openafs? Klaas Thanks Klaas - Original Message - From: Cesar Garcia Klaas [EMAIL PROTECTED] To: Ken Hornstein Klaas [EMAIL PROTECTED] Cc: Cesar Garcia Klaas [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Klaas Friday, October 18, 2002 6:22 AM Subject: Re: afs-krb5 Klaas integration Not sure - I'm not exactly an AFS subject matter expert and I haven't seen the AFS code that implements the key retrieval (from KeyFile) and token validation. When I first started looking at MIT's krb524, this was the first problem we saw. [the 524 client setting the lifetimes incorrectly was the other, as apparently the resulting V4 ticket lifetimes are not communicated back to the client over the 524 wire protocol and the client is setting it based on 5 minute increments in the V4 ticket, not the CMU/AFS lifetime interpretation]. I noticed the kvno returned was 0, while the actual kvno for our afs principal was 1 (as seen via kadmin). Given the error and the observed behavior wrt kvno, the fix was rather straight forward. Perhaps your afs server uses different criteria for key retrieval. We're only now starting to roll out OpenAFS. Our observations were made with Transarc AFS, versios 3.x. Sorry I don't have a good answer for this. Ken == Ken Hornstein [EMAIL PROTECTED] writes: There is also a bug in krb524d that does not set the kvno on the returned V4 ticket. Here's a patch: Ken Interesting ... so what triggers this? I mean, it seems to work Ken in normal circumstances ... Ken --Ken Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos Klaas Kerberos Klaas mailing list [EMAIL PROTECTED] Klaas http://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: afs-krb5 integration
There is also a bug in krb524d that does not set the kvno on the
returned V4 ticket. Here's a patch:
$ diff -c krb524d.c.orig krb524d.c
*** krb524d.c.orig Thu Oct 17 13:37:30 2002
--- krb524d.c Thu Oct 17 13:39:55 2002
***
*** 412,418
memset (key, 0, sizeof (*key));
return ret;
}
!
krb5_kt_free_entry(context, entry);
return 0;
} else if (use_master) {
--- 412,419
memset (key, 0, sizeof (*key));
return ret;
}
! if(kvnop)
! *kvnop = entry.vno;
krb5_kt_free_entry(context, entry);
return 0;
} else if (use_master) {
Ken == Ken Hornstein [EMAIL PROTECTED] writes:
i have strange problems in integrating openafs into krb5.
I use openafs 1.2.7 and kerberos 1.2.6 for the slave-server and 1.2.4 for
the kerberos master/admin server.
I checked everything with these key-versions (thanks to Derek on the openafs
mailing lis), but it did not help.
I always get ticket contained unknown key version number
Ken At the end of the day, there is a ticket in a Keyfile that does not agree
Ken with the service ticket stored in your KDC. This is the ONLY possible
Ken cause of this error (at least, the only one I've ever seen).
Ken Possible causes of this:
Ken - You're not updating the KeyFile on ALL of your AFS servers (yes, you
Ken have to do them ALL, and the best way to do that is with upclient,
Ken because it needs to be the same one everywhere).
Ken - You entered in the wrong kvno for asetkey.
Ken - You have an old cached service ticket on your client.
Ken There may be more problems, but these are the only ones that I've seen.
Ken I know that some people were unable to make it work, but I am convinced
Ken that they still had one of these problems and they just didn't realize it.
Ken --Ken
Ken
Ken Kerberos mailing list [EMAIL PROTECTED]
Ken http://mailman.mit.edu/mailman/listinfo/kerberos
Kerberos mailing list [EMAIL PROTECTED]
http://mailman.mit.edu/mailman/listinfo/kerberos
Re: afs-krb5 integration
Not sure - I'm not exactly an AFS subject matter expert and I haven't seen the AFS code that implements the key retrieval (from KeyFile) and token validation. When I first started looking at MIT's krb524, this was the first problem we saw. [the 524 client setting the lifetimes incorrectly was the other, as apparently the resulting V4 ticket lifetimes are not communicated back to the client over the 524 wire protocol and the client is setting it based on 5 minute increments in the V4 ticket, not the CMU/AFS lifetime interpretation]. I noticed the kvno returned was 0, while the actual kvno for our afs principal was 1 (as seen via kadmin). Given the error and the observed behavior wrt kvno, the fix was rather straight forward. Perhaps your afs server uses different criteria for key retrieval. We're only now starting to roll out OpenAFS. Our observations were made with Transarc AFS, versios 3.x. Sorry I don't have a good answer for this. Ken == Ken Hornstein [EMAIL PROTECTED] writes: There is also a bug in krb524d that does not set the kvno on the returned V4 ticket. Here's a patch: Ken Interesting ... so what triggers this? I mean, it seems to work Ken in normal circumstances ... Ken --Ken Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
thread safety of gssapi and dependencies
Hi, I was wondering what the thread safety situation is with ligss and underlying libraries. We intend to use these apps in heavily threaded applications (including middle tier servers that act as both security context initiators and acceptors). We seem to be running in to KRB5_FCC_INTERNAL Internal credentials cache error with the 1.2.2 distribution. We're currently porting to 1.2.6. However, I don't see anything in the release notes that would indicate 1.2.6 would change this situation much. I haven't looked at the specifics of these errors at this point. I will shortly, but I thought I'd throw the question out there for now. Any insight would be appreciated. Thanks. Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
MIT client and AD KDC interoperability
Part of our migration from NT to active directory involves cloning NT user accounts to initialize the AD account (including the password). This allows a user to log in to XP (a member of an AD domain) using the cloned password, at least initially. It's not clear whether the cloning mechanism allows us to participate in K5 based authentication or if it's still NTLM. Nonetheless, from UNIX (MIT kerberos clients), when trying to obtain a TGT using the cloned account - the following error is produced: $ kinit [EMAIL PROTECTED] Password for [EMAIL PROTECTED]: kinit(v5): KDC has no support for encryption type while getting initial credentials However, once I change my AD password, the MIT kinit can obtain tickets from the AD KDC. This is presumably because the NTLM hash of the user's password (now held in AD, cloned from the NT account) does not produce a DES key can be used with the MIT supported enctypes. Cloning accounts/passwords in bulk is potentially a challenge. My recommendation right now (to our PC engineering/deployment folks) would be to expire passwords as part of the cloning process, such that a password change is required on initial login to XP/AD. The password changes then enables users to obtain tickets from an AD KDC using UNIX/MIT clients. However, not everyone has a Windows based desktop, so the initial password change is becomes inpractical for some class of users. I'm wondering if anyone has or plans to implement an enc-type, on the [MIT] client side, that supports the NTLM hashed password/key, or whether there are any technical reasons that simply would not work. Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: Ticket forwarding and IP addresses
FYI,
For those interested, here's a very simple patch to
krb524d.c (release 1.2.2):
Basically, the when looking up the key that krb524d
will use to build the response, the key version number
is not being assigned when using the keytab option.
The code looks OK when using the KDB.
I'll have to hammer away at this server.
What's the story with the alpa status of k524?
Are folks using this in production environments, despite the
recommendation in the README against doing so?
Thanks again for the pointers.
*** krb524d.c.orig Wed Feb 13 22:34:06 2002
--- krb524d.c Wed Feb 13 23:41:34 2002
***
*** 393,398
--- 393,400
if ((ret = krb5_kt_get_entry(context, kt, p, kvno, ktype, entry)))
return ret;
memcpy(key, (char *) entry.key, sizeof(krb5_keyblock));
+ if(kvnop)
+ *kvnop = entry.vno;
return 0;
} else if (use_master) {
return kdc_get_server_key(context, p, key, kvnop, ktype, kvno);
Cesar == Cesar Garcia [EMAIL PROTECTED] writes:
Cesar OK. I may have figured the error.
Cesar Although the the key version number for my afs principal is 1,
Cesar the 1.2.2 krb524d (using -k) returns a V4 cred with a kvno of 0.
Cesar I determined this on the client side, I'll have to walk through the
Cesar server code to see why the cred is returned with a kvno of 0.
Cesar == Cesar Garcia [EMAIL PROTECTED] writes:
Cesar This is not exactly a Kerberos specific issue, but perhaps
Cesar the folks on this mailing list might have some insight.
Cesar I decided for now to go with Ken's suggestion that I simply
Cesar remove the IP addresses from my V5 tickets, and do ticket
Cesar forwarding sans IP addresses.
Cesar It appears that the one dependency we have on IP addresses
Cesar is k524. Our client code is modern and works fine. It's an
Cesar old krb524d which we currently run on a CyberSafe KDC that
Cesar requires IP addresses in the requesting ticket.
Cesar So thanks to Doug Engert, we have a -k option that allows
Cesar one to run the MIT krb524d with a keytab, which handles
Cesar null IP addresses just fine - and I don't immediately, or
Cesar perhaps ever, have to solve the problem of writing the glue
Cesar to get it to work the CyberSafe KDB. Simply extracting all
Cesar the necessary keys to a keytab file suffices.
Cesar I then add the following keys to a keytab file:
Cesar 1 - krbtgt/k5realm@k5realm
Cesar 2 - afs@k5realm (*)
Cesar (*) An aside - this predates me, so I'm not sure what all
Cesar the reasons were) Since all of our AFS cells use the same
Cesar server principal, we don't have afs/afscellname@k5realm
Cesar for each of our cells, just one principal afs@k5realm
Cesar (one k5realm) for all cells. Not sure how/if this is
Cesar relevant, but it is different.
Cesar The basic algorithm for obtaining tokens for all cells follows:
Cesar 1 - using V5 TGS, obtain a ticket V5 ticket for afs@k5realm
Cesar (this ticket get's cached)
Cesar 2 - using k524 and V5 ticket for afs@k5realm, obtain a V4 ticket
Cesar for afs@k5realm
Cesar 3 - foreach cell, invoke ktc_SetToken, passing in the V4 cred
Cesar obtained in step 2.
Cesar This code is implemented in a lib/app we call ak5log and works
Cesar with the cybersafe based krb524d, with either the cybersafe
Cesar based k524 client or the MIT based k524 client.
Cesar When we try to run either the cybersafe or MIT based client
Cesar against the MIT krb524d (using -k), the ak5log code completes,
Cesar but I get the following messages in syslog:
Cesar
Cesar Feb 12 21:05:09 imus afs: [ID 255639 kern.notice] afs: Tokens for user of AFS
id 4843 for cell w.ny.ms.com are discarded (rxkad error=19270408)
Cesar
Cesar with a similar error going to my console.
Cesar krb524init itself seems to work fine against the same MIT
Cesar krb524d with the keytab. That is the I can V4 tgt and run
Cesar my v4 apps with no problem.
Cesar The error apparently corresponds to Unknown key. I've verified
Cesar the key and kvno for afs@k5realm that was extracted to the
Cesar keytab file, and it appears to be correct. I assume I would
Cesar have failed earlier had that not been the case.
Cesar When I list my tokens, the listing looks normal.t The
Cesar tokens themselves, however, are worthless.
Cesar We're running various versions of transarc afs (3.5, 3.6)
Cesar on our solaris machines, openafs 1.2.2 on our linux boxes.
Cesar AFS servers are solaris.
Cesar Before I go digging into this problem some more, I was wondering
Cesar if anyone might have some insight on this one.
Cesar Thanks in advance.
Cesar == Cesar Garcia [EMAIL PROTECTED] writes:
Cesar I've been working with 1.2.2 for a some months now, and only
Cesar recently have attempted to get the rcmds working, mainly in
Cesar an effort to better understand how ticket forwarding works,
Cesar since we have a need to do this in a homegrown application.
Cesar The behavior that I see is that when I invoke ticket
Cesar forwarding
Re: Ticket forwarding and IP addresses
This is not exactly a Kerberos specific issue, but perhaps the folks on this mailing list might have some insight. I decided for now to go with Ken's suggestion that I simply remove the IP addresses from my V5 tickets, and do ticket forwarding sans IP addresses. It appears that the one dependency we have on IP addresses is k524. Our client code is modern and works fine. It's an old krb524d which we currently run on a CyberSafe KDC that requires IP addresses in the requesting ticket. So thanks to Doug Engert, we have a -k option that allows one to run the MIT krb524d with a keytab, which handles null IP addresses just fine - and I don't immediately, or perhaps ever, have to solve the problem of writing the glue to get it to work the CyberSafe KDB. Simply extracting all the necessary keys to a keytab file suffices. I then add the following keys to a keytab file: 1 - krbtgt/k5realm@k5realm 2 - afs@k5realm (*) (*) An aside - this predates me, so I'm not sure what all the reasons were) Since all of our AFS cells use the same server principal, we don't have afs/afscellname@k5realm for each of our cells, just one principal afs@k5realm (one k5realm) for all cells. Not sure how/if this is relevant, but it is different. The basic algorithm for obtaining tokens for all cells follows: 1 - using V5 TGS, obtain a ticket V5 ticket for afs@k5realm (this ticket get's cached) 2 - using k524 and V5 ticket for afs@k5realm, obtain a V4 ticket for afs@k5realm 3 - foreach cell, invoke ktc_SetToken, passing in the V4 cred obtained in step 2. This code is implemented in a lib/app we call ak5log and works with the cybersafe based krb524d, with either the cybersafe based k524 client or the MIT based k524 client. When we try to run either the cybersafe or MIT based client against the MIT krb524d (using -k), the ak5log code completes, but I get the following messages in syslog: Feb 12 21:05:09 imus afs: [ID 255639 kern.notice] afs: Tokens for user of AFS id 4843 for cell w.ny.ms.com are discarded (rxkad error=19270408) with a similar error going to my console. krb524init itself seems to work fine against the same MIT krb524d with the keytab. That is the I can V4 tgt and run my v4 apps with no problem. The error apparently corresponds to Unknown key. I've verified the key and kvno for afs@k5realm that was extracted to the keytab file, and it appears to be correct. I assume I would have failed earlier had that not been the case. When I list my tokens, the listing looks normal.t The tokens themselves, however, are worthless. We're running various versions of transarc afs (3.5, 3.6) on our solaris machines, openafs 1.2.2 on our linux boxes. AFS servers are solaris. Before I go digging into this problem some more, I was wondering if anyone might have some insight on this one. Thanks in advance. Cesar == Cesar Garcia [EMAIL PROTECTED] writes: Cesar I've been working with 1.2.2 for a some months now, and only Cesar recently have attempted to get the rcmds working, mainly in Cesar an effort to better understand how ticket forwarding works, Cesar since we have a need to do this in a homegrown application. Cesar The behavior that I see is that when I invoke ticket Cesar forwarding, the forwarded tickets contain only a single Cesar IP address. Cesar After walking through some of the code, it appears that Cesar the client, via krb5_fwd_tgt_creds, determines the target's Cesar IP address via a host lookup using gethostbyname(), as Cesar implemented in krb5_os_hostaddr(). Cesar Since we use NIS as the primary source for hostname Cesar resolution, all host lookups render a single IP address, Cesar even for multihomed machines. Moving to DNS is not an Cesar option at the moment. Additionally, we use Veritas VCS Cesar and other similar clustering facilities. These hosts Cesar will have additional IP addresses that are not associated Cesar with the real hostname, but with service names for a Cesar particular cluster/application. So even if were to switch Cesar to DNS, the client would not be able to determine all the Cesar IP addresses for a given target host via the hostname Cesar lookup that it uses today. Cesar That said (barring hacks to application protocols that Cesar would allow target hosts to send IP addresses back to Cesar the source host, then having the client embed the full set Cesar of tickets), the way to address this would be to have Cesar the target host obtain new tickets will a full set of Cesar IP addresses. Cesar 1 - is this possible? Cesar 2 - is it within the limits of the specification? Cesar If so, has anyone has implemented this for 1.2.2 or any Cesar releases of MIT krb5. ___ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Ticket forwarding and IP addresses
I've been working with 1.2.2 for a some months now, and only recently have attempted to get the rcmds working, mainly in an effort to better understand how ticket forwarding works, since we have a need to do this in a homegrown application. The behavior that I see is that when I invoke ticket forwarding, the forwarded tickets contain only a single IP address. After walking through some of the code, it appears that the client, via krb5_fwd_tgt_creds, determines the target's IP address via a host lookup using gethostbyname(), as implemented in krb5_os_hostaddr(). Since we use NIS as the primary source for hostname resolution, all host lookups render a single IP address, even for multihomed machines. Moving to DNS is not an option at the moment. Additionally, we use Veritas VCS and other similar clustering facilities. These hosts will have additional IP addresses that are not associated with the real hostname, but with service names for a particular cluster/application. So even if were to switch to DNS, the client would not be able to determine all the IP addresses for a given target host via the hostname lookup that it uses today. That said (barring hacks to application protocols that would allow target hosts to send IP addresses back to the source host, then having the client embed the full set of tickets), the way to address this would be to have the target host obtain new tickets will a full set of IP addresses. 1 - is this possible? 2 - is it within the limits of the specification? If so, has anyone has implemented this for 1.2.2 or any releases of MIT krb5. ___ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: Ticket forwarding and IP addresses
Ken == Ken Hornstein [EMAIL PROTECTED] writes: Since we use NIS as the primary source for hostname resolution, all host lookups render a single IP address, even for multihomed machines. Moving to DNS is not an option at the moment. Ken I have to ask ... you're STILL using NIS for hostname resolution? Ouch. Thanks for the sympathy. Unfortunately, in our case, migrating to DNS is not a trivial effort, but let's not go there. That said (barring hacks to application protocols that would allow target hosts to send IP addresses back to the source host, then having the client embed the full set of tickets), the way to address this would be to have the target host obtain new tickets will a full set of IP addresses. 1 - is this possible? Ken The trick here is that one of the IP addresses in the target ticket Ken _must_ be the IP address used to talk to the KDC; otherwise, you're Ken outta luck. 2 - is it within the limits of the specification? Ken Yes. Ken It occurs to me that you could save yourself some pain and simply get Ken a completely addressless ticket. There is a school of thought in the Ken Kerberos world that suggests IP addresses in tickets are not that useful. OK. let's reset a bit. What I neglected to mention was that we are a former CyberSafe customer, with remnants of CyberSafe code still in production. (Now I'll be getting pity, not sympathy.) Since the move to MIT has also been driven by the deployment of platforms not supported by CyberSafe (e.g., linux), we have focused primarily on application infrastructure. That said, the core CyberSafe KDCs are still in place, in addition to a variety of other KDC based services, either homegrown or adopted to work with a CyberSafe KDB. Admittedly, I'll have to assess the current dependencies that we have on IP addresses. The implementation of krb524d that we currently use requires IP addresses, or it barfs. This may well be the only dependency that we really have. Client krb524 code has already been migrated to MIT. That said, I'll investigate if we have any more dependencies on IP addresses in tickets and start working on porting krb524d to the CyberSafe KDB. Unfortunately, I can't use it as is for now, until we migrate the all the KDC services to MIT krb5 (or perhaps Heimdal, since incremental propagation is a must have). Nonetheless, we have all sorts of applications that obtain initial credentials (various homegrown apps, PAM modules, sitecheck binaries for irix) which would need to corrected. Ticket forwarding was my immediate objective. But I'll submit I was looking for the lazy way out. Ken --Ken ___ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: KERB V5 + SEGV_MAPERR
The mutex keeps multiple threads from simultaneously entering a mutexed code segment. This problem has more to do with how errno is defined. Keep in mind that most system calls (e.g., stat, fork, open, etc) set errno on failure (this is done implicitly, since errno is not passed in as an argument to the system call). In non-multithreaded apps, it's reasonable for errno to be defined as a global variable, since it's not possible for multiple systems calls to be invoked concurrently. In multithreaded apps, this is a problem. Since your libs are not build with -D_REENTRANT, the kerberos libs are referencing the global errno, instead of the thread specific errno which stat is actually using. Hence your problem. Christopher == Christopher Burke [EMAIL PROTECTED] writes: Christopher [EMAIL PROTECTED] (Cesar Garcia) wrote in Christopher [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: I gather your application is multithreaded, or at least built with threads in mind ... You should build your kerberos libs with -D_REENTRANT. Christopher Yes my application is multi-threaded however I do have a mutex around the Christopher entire call to the kerberos stuff ... shouldn't that help ? Christopher -- Christopher --- Christopher /* Christopher Burke - Spam Mail to [EMAIL PROTECTED] Christopher |* www.craznar.com - Christopher \* Real mail to cburke(at)craznar(dot)com Christopher ___ Christopher Kerberos mailing list Christopher [EMAIL PROTECTED] Christopher http://mailman.mit.edu/mailman/listinfo/kerberos ___ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: KERB V5 + SEGV_MAPERR
I gather your application is multithreaded, or at least built with threads in mind ... You should build your kerberos libs with -D_REENTRANT. At least in 1.2.2, the problem begins in src/util/profile/prof_file.c in the profile_update_file method, where a stat is done to look for the krb5.conf file. Since there are multiple places that the krb5.conf file can reside (see DEFAULT_PROFILE_PATH in osconf.h) the lib code loops through the possible locations, doing a stat on each location to see if the file exists. The following is the relevant code segment: if (stat(prf-filespec, st)) return errno; The problem is that when the stat is done on a location where the config file does not exist, the stat sets the per-thread 'errno' variable and returns -1. The krb lib code catches the -1 and returns the errno as it should, but the errno that it looks at is the global errno (extern int errno), which has not been set by stat, so the value of errno is undefined and may be 0, so the caller of this method gets a 0 return value and assumes that the file is there and that data structures that are subsequently used have been setup. However, the data structures have not been setup correctly, causing a core dump in util/profile/prof_tree.c, in the method profile_node_iterator. When the libs are compiled with the -D_REENTRANT flag, the libs use the macro for errno rather than the extern int errno (see /usr/include/errno.h), and so it is able to use the errno that stat sets and everything works as it should. Christopher == Christopher Burke [EMAIL PROTECTED] writes: Christopher This problem seems to be an old one (http://groups.google.com/groups?selm= Christopher 6ogf07%247pg%241%40news.appliedtheory.comoutput=gplain), but I cannot find Christopher out an answer. Christopher We are running on Solaris 8 (E10K ultra SPARC 8processor domain)... it only Christopher occurs when running within a shared object called by another process. When Christopher compiled directly into a user app - works fine. From a truss output on our process ... Christopher 14.5968 stat(/etc/krb5.conf, 0xFE3C0D48) = 0 Christopher 14.5975 stat(/usr/local/kerb5/etc/krb5.conf, 0xFE3C0D48) Err#2 ENOENT Christopher 14.5982 Incurred fault #6, FLTBOUNDS %pc = 0xFDDF0480 Christopher siginfo: SIGSEGV SEGV_MAPERR addr=0x0014 Christopher 14.5989 Received signal #11, SIGSEGV [caught] Christopher siginfo: SIGSEGV SEGV_MAPERR addr=0x0014 Christopher 14.5995 sigprocmask(SIG_SETMASK, 0xFED8EFE8, 0x) = 0 Christopher 14.6001 sigaction(SIGSEGV, 0xFE3C08E0, 0x) = 0 Christopher 14.6007 sigprocmask(SIG_SETMASK, 0xFED9ADB8, 0x) = 0 Christopher 14.6013 setcontext(0xFE3C0A98) Christopher 14.6020 Incurred fault #6, FLTBOUNDS %pc = 0xFDDF0480 Christopher siginfo: SIGSEGV SEGV_MAPERR addr=0x0014 Christopher 14.6026 Received signal #11, SIGSEGV [default] Christopher siginfo: SIGSEGV SEGV_MAPERR addr=0x0014 Christopher *** process killed *** Christopher -- Christopher --- Christopher /* Christopher Burke - Spam Mail to [EMAIL PROTECTED] Christopher |* www.craznar.com - Christopher \* Real mail to cburke(at)craznar(dot)com
Re: Kerberos on the web
Actually they are sharing the details, but only for review/ analysis. The Microsoft PAC specification is available at Microsoft's web site, but subject to a rather prohibitive license. http://www.microsoft.com/Downloads/Release.asp?ReleaseID=20597 Unfortunately, at least from my interpretation of the license, I/we would be prohibited from discussing the details of the specification using a forum such as this one. Specifically, the terms of the license permit licensees to use the specification solely for your informational purposes, and prohibit use of the specification for any other purposes. Nicolas Williams wrote: MS did not really distort an agreed upon standard, by which I take it you mean RFC1510. RFC1510 has provisions that allow implementors to come up with, require and use their own authorization data extensions. MS did; and they're just not sharing the details. It's their right, really, though arguably it's not nice, particularly since they're using a protocol that they did not invent in the first place and which fits their security model much better than the old NT domain protocols ever did and so they are benefitting from the fact that others have shared ideas but they are not sharing back. But this isn't kindergarten you know. Cheers, Nico On Fri, Jan 18, 2002 at 04:29:52AM -0800, hot ice wrote: Hi David No offense and nothing personal, and I would be sorry to see this thread degenerate into an MS vs. non-MS slanging match. I like MS-products and I have been a Microsoft programmer through and through. But one thing I don't like about MS, is the way they distort an agreed upon standard, and throw their weight around to shove it down others' throats - that is unpleasant. I don't need give you examples do I? BTW Thanks to all who responded. H/I -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. smime.p7s Description: S/MIME Cryptographic Signature
alternate keytab for gssapi
Hi, I was just wondering if it was possible for an application to specify an alternate keytab when obtaining credentials (gss_acquire_cred) that will be used to accept a security context (gss_accept_sec_context). If not, should I bother to make changes to gssapi_krb5, or is expected to be in the next release? The application server will not be running as root and I clearly don't want to change ownership/permissions on the default keytab file. While I can implement the application using libkrb5, I'm looking to save time, as the application is being ported from a vendor implementation of gss. I am using version 1.2.2. Thanks.
