Re: Master - Slave replication
In article [EMAIL PROTECTED], Derek Harkness [EMAIL PROTECTED] wrote: Is kprop and kpropd really the only way to replicate a master and slave? It just seems lame that in 2008 I still have to write a cron job to replicate a database every X seconds. As noted in another followup, some Kerberos sites have implemented something on their own. We did. It was really more like a trivial integration with already existing local accounting software, so maybe not much help to anyone looking to go this way. At the time we did that, the latency was not every X seconds, but every X minutes, where X is two digits - since we would have to at least wait long enough that the replica could complete its load before getting a new one. But if I had to start over without a convenient way to implement incremental replication, I wouldn't worry as much about it as I did at the time. At any ordinary site, a single master KDC will take the whole load without breaking a sweat, so the replica is only really needed for service exception backup, and if in that event it's a few minutes out of date it isn't the end of the world. This is why the I sure would not turn to an LDAP back end for this reason. Nothing against LDAP, if you have data to publish it's the way to go and we do plenty of it here, but for replicating the KDC? talk about a cure that's worse than the disease ... Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kerberos vs ldap
In article [EMAIL PROTECTED], Danny Mayer [EMAIL PROTECTED] wrote: Turbo Fredriksson wrote: it == it is ramu [EMAIL PROTECTED] writes: it Can anyone explain to me whats the relation between LDAP vs it Kerberos Two _completely_ different protocols/systems. In short and generalized: LDAP is for AUTHORIZATION (access rules) and Kerberos is for AUTHENTICATION (verify password). LDAP has nothing whatsoever to do with authorization. It's a data storage and retrieval mechanism. If you choose to use it for authorization that's up to you. Taken out of context, that's true, but conversations like this can be awfully tedious if we have to drag around explicit context. Give us a break, OK? How would you explain the relation between LDAP vs. Kerberos? Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Issue with KDC
In article [EMAIL PROTECTED], sunilcnair [EMAIL PROTECTED] wrote: This is Sunil here, i am working on the cross domain authentication using kerberos, i have two domains(xx.com) and(co.yy), and i am in a dilemma as to install 2KDC in both the domains or is it sufficient for the kdc to be installed in only one single domain, and register the other domain as just the user of the domain in which the kdc is installed.Also Iâd like to avoid cross realms scenario,because we should set up another KDC.(thats bit difficult)is there any other possibilities of using two domain for kerberos without having KDC on both the domains please do clear my doubt. Looking for an answer Kerberos is basically indifferent to DNS domains, and one Kerberos realm can certainly serve many DNS domains. Application software may rely on DNS for realm information, though - configuration files may specify realm/domain maps, and Kerberos realm information can be published in special DNS SRV and TXT records. If you have tried this and were not able to make it work, check that the [domain_realm] section of your configuration file includes the new domain. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Incremental Propagation
In article [EMAIL PROTECTED], Kevin Coffman [EMAIL PROTECTED] wrote: On 9/21/07, Jeffrey Altman [EMAIL PROTECTED] wrote: John Harris wrote: Greetings, Does MIT's current implementation of the Kerberos KDC include incremental propagation? I know it didn't a long time ago, then there were CITI patches for it, then those didn't work for awhile. I don't seem to be able to pinpoint an answer to it. Thanks, John There is no incremental propagation distributed with MIT Kerberos. Jeffrey Altman Our patch hasn't been ported forward to release 1.5 and beyond yet. With the new plugable database interface, changes are necessary. We haven't had the time to get to it yet. We haven't taken ours to a recent release level yet either, but for other reasons. It would be interesting, if academic, to see if our approach would work with 1.6 without changes. I think it would - it's quite trivial, we just siphon off data (who, what) from every change kadmind makes, and some other local software takes it and applies to peer KDCs. One or more of which are Microsoft domain controllers (but only the MIT KDCs can propagate changes.) We've been doing this for ca 8 years. As for an LDAP solution, we've talked about this here before (cf. LDAP KDB.) If you need an LDAP backend for some other reason, that's one thing, but just for replication, I don't think so. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT krb5 has no site support.
In article [EMAIL PROTECTED],
Jeremy Allison [EMAIL PROTECTED] wrote:
On Thu, 31 Aug 2006 12:22:47 -0700, Donn Cave wrote:
Custom krb5.conf isn't very elegant, but apart from that, would you agree
that this fits in the general area of configuration data from alternate
sources?
I mean, it seems like it would be better to use the existing configurable
library parameters if possible, rather than add to what's already a fairly
complex configuration diagram. Would something like the following be an
improvement?
include k5-int.h
const char *kdc[4] = {realms, 0, kdc, 0};
kdc[1] = this_realm;
err = profile_clear_relation(kcontext-profile, kdc);
err = profile_add_relation(kcontext-profile, kdc, localkdc);
Interesting - are you saying there's already a way in 1.5.x
to do this ? I can create a context then manipulate the
KDC - IP address association in it ? I notice you're
using k5-int.h - I take it this is an internal only API.
Yes, I suppose it's internal. Ideally, Ithink MIT
probably recognizes that this functionality is needed
in some form, though, even if they're not committed to
this particular way to achieve it.
I don't actually know whether the above works in 1.5.x -
due static build requirements, I have elected to stay with
1.4 while I can, and that's where I tested the above.
It's effectively the same as a custom krb5.conf, with
respect to that one parameter.
Donn Cave, [EMAIL PROTECTED]
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Presence/absence of the keytab
In article [EMAIL PROTECTED], Russ Allbery [EMAIL PROTECTED] wrote: ... The pam_krb5 modules that I've used either don't do this or only do this when the keytab is available, presumably doing a security vs. ease of deployment tradeoff. One difficulty is that if the authentication is not being done as root, the PAM module needs something other than the host keytab to use for verification, and I don't know of any PAM module that is configurable enough to be pointed at any keytab and use that keytab for verification. It would be a good thing to add, though. Wonder if this situation is common enough to warrant library support for some default file convention, like /etc/krb5.keytab if root, otherwise ~/krb5.keytab. Not to say a configurable parameter isn't a good thing, too. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Presence/absence of the keytab
In article [EMAIL PROTECTED], Richard E. Silverman [EMAIL PROTECTED] wrote: SL == Scott Lowe [EMAIL PROTECTED] writes: SL Yesterday, however, I was able to successfully authenticate via SL Kerberos from VMware ESX Server 2.5.3 (the console operating SL system is Linux-based) *without* generating a keytab. This seems SL to fly in the face of all the information and instructions I've SL seen. SL So, I'm curious...any thoughts as to why this worked? A keytab is needed for a host on which a kerberized service runs; it holds the service princpal's secret key, which the service software needs. You don't need anything special on a host to allow someone to kinit on it. The only secret needed is your password. True, though there is a sort of grey area inhabited by services that use Kerberos to perform password authentication. This is functionally like kinit, but semantically quite different, and without a service principal to validate the authentication results, they're vulnerable. So depending on what `successfully authenticate' actually means here, the information and instructions that say to get a service principal and a keytab may be worth listening to, even if the service appears to work without it. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Presence/absence of the keytab
In article [EMAIL PROTECTED], Scott Lowe [EMAIL PROTECTED] wrote: On 2006-05-04 12:29:53 -0400, Donn Cave [EMAIL PROTECTED] said: True, though there is a sort of grey area inhabited by services that use Kerberos to perform password authentication. This is functionally like kinit, but semantically quite different, and without a service principal to validate the authentication results, they're vulnerable. So depending on what `successfully authenticate' actually means here, the information and instructions that say to get a service principal and a keytab may be worth listening to, even if the service appears to work without it. I suppose if I were seeking to use a fully Kerberized server application that accept Kerberos tickets from Kerberos clients, then a keytab would be necessary. In this instance, the service does not accept Kerberos authentication from connecting systems, but acts a Kerberos client on the back-end to perform authentication (using PAM). It seems to make sense, then, that a keytab would not be necessary. At least, not in this situation. I guess it depends on what you mean by necessary, but if there's any reasonable possibility that you could create a host service principal and install that keytab, I would do it. If you have reason to believe that the PAM authentication isn't actually using the keytab, I would find out why and try to get it fixed. Without it, you're vulnerable. Of course everything's relative, and the authorization you're providing with this authentication may not warrant the concern, but that's different than thinking it isn't necessary in the sense that there is no use for it, which would be an error. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SRV records and canonicalization
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Simon Wilkinson) wrote: I'm interested in what people feel the 'correct' approach is to the following situation. XMPP (the 'Jabber' protocol) uses DNS SRV records to determine the location of a Jabber service for a given DNS domain. In some implementations there may be multiple servers, running on multiple different machines, all of which can accept an incoming connection. In current Jabber (and MIT Kerberos) implementations, the service principal used for the SASL/GSSAPI/Kerberos connection is the canonical version of the hostname returned from the results of the SRV query. This is obviously bad, as the use of an insecure directory service (DNS) to perform both of these lookups presents an opportunity for a MITM attack. Worse is a current proposal that the server should be able to tell the client the principal name to use. So, for a Jabber connection to 'example.org', should we connecting to the service principal 'xmpp/example.org'? But, how does this work where 'example.org' is providing multiple XMPP servers - should they all have a copy of the same key material, and does this present further concerns? Domain based names may be interesting, but the drafts are not clear to me. I imagine someone in my organization knows addresses for the kitten working group mailing lists, so they may be hearing more on that. Some years ago, I believe a certain large software company's LDAP clients would include the service port number in their service principal name. So if you wanted to support Kerberos access to an LDAP server running on port 777 on oc.bo.co, you would want to provide it with a key for LDAP:777/oc.bo.co (or LDAP/oc.bo.co:777 or something, I don't remember.) We didn't particularly appreciate it at the time, and I would be a little surprised if anyone is doing anything like that today. Technically I believe it may address your second point, and at least it's easy for both parties to determine the service-specific name, but the service distinction probably shouldn't really be tied to a service port number. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: KRB5CCNAME and sshd
In article [EMAIL PROTECTED], Victor Sudakov [EMAIL PROTECTED] wrote: I will tell you what I am trying to achieve, perhaps you can give me advice. I kinit -f on the client box at home and then ssh to the server box at work. On the server box, I have screen(1) running, which I reattach after login and detach before logout. It runs for weeks and even months on end. You know that all screen sessions or windows inherit the environment variables from the shell where screen was started initially. So, $KRB5CCNAME in the screen sessions points to stale credential caches, even though the fresh credentials have been correctly forwarded from the client machine and are available in some new place (but there is no way to inform the applications within screen about this new place). I would like to achieve that if my credentials have been forwarded to the server box, they should be refreshed in all the screen windows. That certainly must be a manual operation. I don't use screen, but I suppose you have a number of concurrent shell processes, and they are not really aware of this connect/disconnect cycle, so they have no way to know when it's time to update KRB5CCNAME. You must therefore enter some command, in each window, to get them to do that. The command can be a simple one, if you use an alias or shell procedure. Your shell startup can save the value of KRB5CCNAME somewhere so the old screen shell can find it. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Clarifications sought on Kerberos SA: TGS_REQ and Server Auth??
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Surendra Babu A) wrote: - Now we initiated the email operation from Multi Funtion Printer. It contacted the ESMTP server from ESMTP client. - Sent the EHLO command. ESMTP Server Gave me the AUTH GSSAPI response. So Kerberos is supported at server sid. Right?? - After seeing this GSSAPI string, sending the Service ticket to ESMTP server. Is it correct? We are assuming that, GSSPAI is supported means, Kerberos is supported. Is it right? Yes, all sounds right to me. Could you please explain about the Application Server transactions??? How to communicate with GSSAPI? If you have downloaded the MIT Kerberos distribution, you could look at src/appl/gss-sample/. Therein you will find example code for a simple GSS application. gss-sample uses functions like send_token() to transmit the authentication data. Your application won't use those, and instead will send and receive authentication data according to the ESMTP AUTH protocol. That's probably explained in an ESMTP RFC. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: AIX 5.3: kinit(v5): Cannot resolve network address for KDC in requested realm while getting initial credentials
In article [EMAIL PROTECTED],
Christoph Weizen [EMAIL PROTECTED] wrote:
kinit (krb5 1.4.2) on an AIX 5.3 gives me
# /usr/local/bin/kinit -k -t foobar.keytab
foobar/[EMAIL PROTECTED]
kinit(v5): Cannot resolve network address for KDC in requested realm
while getting initial credentials
From a working Linux krb5 1.4.2 installation I copied /etc/krb5.conf
and foobar.keytab to AIX 5.3. The following steps don't defer to the
steps I did under Linux.
# ./configure --without-krb4 --enable-shared
# make make install
Using gcc 3.3.2.
I found a patch for krb5 1.4.1 for AIX 5.2 from Ken Raeburn, but as far
as I see it is fixed in 1.4.2.
I don't know what's in that patch. Does it look like you
already have applied something like this?
Donn Cave, [EMAIL PROTECTED]
---
*** include/fake-addrinfo.h.distWed Jun 1 12:24:32 2005
--- include/fake-addrinfo.h Fri Aug 12 09:10:48 2005
***
*** 1193,1199
a known service name for tcp or udp (as appropriate), an error
code (for host not found) is returned. If the port maps to a
known service for both udp and tcp, all is well. */
! if (serv serv[0] isdigit(serv[0])) {
unsigned long lport;
char *end;
lport = strtoul(serv, end, 10);
--- 1193,1208
a known service name for tcp or udp (as appropriate), an error
code (for host not found) is returned. If the port maps to a
known service for both udp and tcp, all is well. */
! /*
! **
! ** However, where AI_NUNERICSERV is defined (AIX 5) and was
specified,
! ** this is unneeded and and broken - discard is not numeric.
! */
! if (serv serv[0]
! #ifdef AI_NUMERICSERV
! !(hint-ai_flags AI_NUMERICSERV)
! #endif
! isdigit(serv[0])) {
unsigned long lport;
char *end;
lport = strtoul(serv, end, 10);
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kinit coredump
In article [EMAIL PROTECTED] om, [EMAIL PROTECTED] (Jason Brown) wrote: I am having a problem with kinit on AIX 4.3.3. I have compiled the Kerberos 1.4.2 distro with IBM C compiler (Version 5) ... gcc 3.4.3 fails because it cannot find threading support. Used both gnu make, and IBM make. When I run kinit to test the install I get Illegal Instruction, (coredump). Any ideas ? You have to find each configure file and, where it has *-*-aix5*) , change that to *-*-aix*) Re-run configure, and make. If it's still happening, something went wrong - maybe old configuration, maybe missed a configure file. IBM's implementation of some DNS functions uses a different size state struct than the include files define, which guarantees memory corruption when you try to use these functions. The configure script forestalls this on AIX 5, should also do so on AIX 4. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Memory Leak problems with krb5_get_init_creds_password?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Chet Burgess) wrote: [ ... re memory leak caused by DNS KDC lookup ... ] The res_ninit() call and the subsequent calls for the DNS records are made in the krb5int_dns_init function found at src/lib/krb5/os. The res_ninit() call is made for every lookup. As for the DNS vs. config file variable, I had a proper krb5.conf file that listed the REALM and the KDCs, untill I added dns_fallback = false to the config file it would always try DNS then look at the config file. That's weird, but there are some potential surprises. For an example I ran into myself, if your initial request fails, it will be retried to the configured master_kdc. Of course if that isn't in krb5.conf it will go to DNS (_kerberos-master._udp.) master_kdc is fairly recent and likely not configured at a lot of sites where the krb5.conf goes back a ways (or maybe where there is no master KDC, though such sites may as well configure a value anyway.) Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: krb5 1.4 on AIX 5.1 Illegal Instruction
In article [EMAIL PROTECTED], Donald Thompson [EMAIL PROTECTED] wrote: I'm getting an 'Illegal Instruction' when I try to kinit using krb5 1.4 on AIX 5.1. I've tried compiling using both the IBM XL C Compiler, as well as gcc 3.3 with the same result. I've had no problems compiling and using krb5 1.3 versions. Anyone know if theres a fix for this? -Don In case anyone is still set back by this one, I tracked it to res_nsearch. On our AIX platforms (I was looking at 5.2, but 4.3 looks the same) this function overwrites a much larger area than the declared size of its input struct __res_state. I don't know if this would be true for everyone, or if it's a patch my hosts happen to have. SRV lookups work better if the configure scripts don't find res_nsearch. Also, AIX 5 defines AI_NUMERICSERV, which has implications for MIT's getaddrinfo wrapper. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Newbie: Server not found in Kerberos database
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Michael Urban) wrote: ... The problem comes when I attempt to do the same thing with the same version of OpenSSH built with the same options on a Solaris machine. In that case, the server logs a Server not found in Kerberos database message and gives up. I have looked at all the obvious candidates (wrong DNS entry, disagreement as to host name in /etc/hosts and DNS, etc) and come up empty. Unfortunately, the log messages do not tell me _what_ principal it was trying to find in krb5.keytab (I assume that this is where the mismatch or missing entry is). I would expect ssh to acquire a ticket for the remote host service. You can see your tickets with klist, so that will give you one side of the story. Speaking of /etc/hosts, the host's own name as it comes out of its own /etc/hosts has to match the hosts name as it comes out of DNS. So the fully qualified name must be listed first, not second after the short name. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Cannot resolve network address for KDC in requested realm while getting initial credentials
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: kinit test Password for [EMAIL PROTECTED]: ... However, I can't kinit using this keytab file: [EMAIL PROTECTED]/var/kerberos/krb5kdc]$ kinit -k kadm5test kinit(v5): Cannot resolve network address for KDC in requested realm while getting initial credentials In the course of this message you don't show the same realm twice, for a total of four different realms (host.COM is not the same realm as HOST.COM.) If that's really the case, I believe it could account for the error shown above. You may find some details on this in the KDC syslog. The kadmin function that populates a keytab does create a new key version, so the old one is no longer valid for new ticket requests. That's normally a feature. If you want to store the key for a typeable password in a keytab, I believe you can use ktutil for this. Donn Cave, [EMAIL PROTECTED] klist shows: [EMAIL PROTECTED] /var/kerberos/krb5kdc]$ klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 01/20/05 14:53:59 01/21/05 00:53:59 krbtgt/[EMAIL PROTECTED] Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached A secondary problem is now the password seems to have been changed after creating the keytab, and I can no longer kinit (without the keytab): [EMAIL PROTECTED] /var/kerberos/krb5kdc]$ kinit test Password for [EMAIL PROTECTED]: kinit(v5): Password incorrect while getting initial credentials For testing purposes I'm using my hostname as my realm name. I've tried logging in as root and as test, but get the same result. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos and Apache Virtual Hosted Websites
In article [EMAIL PROTECTED], Scott Moseman [EMAIL PROTECTED] wrote: ... When I attempt to access the website, vhost.domain.com, I get this error message in the Apache error logs: gss_acquire_cred() failed: Miscellaneous failure (No principal in keytab matches desired name) How can I further trouble shoot this Kerberos problem? When I use kerbtray on my PC, it shows the correct name for the Kerberos ticket (vhost.domain.com). Any help? The way it looks to me, you have a fairly good case from your troubleshooting so far. Someone now needs to look at the code. This gss_acquire_cred() gets the service principal name from its caller, so you can start there, where the module calls gss_acquire_cred with the wrong principal name, and see how that happened. I don't know anything about it, but I would guess there may be two ways to get it right. Either propagate this information from whatever configuration option initially determines the virtual host, or dig it up via getsockname() on the service port socket. Instead they probably did the easiest thing and used gethostname(). Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos authentication without reverse lookup
In article [EMAIL PROTECTED], Fredrik Tolf [EMAIL PROTECTED] wrote: On Tue, 2005-01-18 at 18:45 -0500, Roland Dowdeswell wrote: On 1106079270 seconds since the Beginning of the UNIX epoch Fredrik Tolf wrote: I came up with a fairly simple solution that would be to add, to inetd on each host, a simple program that just echoes to the connecting host what that host's perception of its own FQDN is. Then I'd write a simple nsswitch module for gethostbyaddr (possibly with some kind of config file so that it never tries for hosts that aren't supposed to be part of this) that connects to this service on the address that it is supposed to canonicalize. You could always do what Heimdal does which is use ai-ai_canonname rather than performing a reverse lookup. Unfortunately, this strategy is not followed by 3rd party vendors such as OpenSSH. I'm sorry if I'm wrong, but doesn't getaddrinfo get ai_canonname by doing a reverse lookup? When I tried it out, at least that is what happened. It depends on the platform. The GNU getaddrinfo implementation does. I'm assuming AI_CANONNAME in ai_flags. NetBSD 2.0, AIX 5.2 don't, they stop at what you'd get from gethostbyname() -- they look up CNAME aliases but don't look up the IP PTR. Also might be worth mentioning that the MIT implementation also uses this in several places, though in the critical sname_to_principal() function it uses getnameinfo for the lookup. Secure DNS would be nice for all this. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Preauth and ticket forwarding
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Rachel Elizabeth Dillon) wrote: I am one of many administrators for a network of 50 machines running MIT Kerberos on Solaris. Recently, another administrator installed a Cisco VPN Magic Box that supposedly uses Kerberos authentication, but won't work unless preauthentication is turned off. With preauthentication turned off for any given principal, ticket forwarding no longer works for that principal. I guess my question is threefold: 1. What does preauth actually do? From some reading, I believed it to be based on clock skew, and fixed the clock skew between the VPN box and the Kerberos server, but preauth still fails. All the KDC logs say is that preauth is required just as they would for a successful kinit, but with no successful kinit afterward. Of course, all the Cisco box gives me is Authentication Failure. Unfortunately, I do not have a choice as to whether or not to use this product. In case it may help, you can find more detail about the preauthentication failure in the syslog output from the KDC. The error message can be a little misleading - I believe No such file or directory really means that the key was wrong. Other errors are no valid preauth type, which I think may commonly be a Microsoft issue, and Clock skew too great. These messages appear on a separate line, so you have to locate the failure event in the log and then look for diagnostic messages on the line before. 2. Assuming I have no choice but to turn off preauth for the Cisco box, is there any way to make SSH ticket forwarding work with preauth turned off? It works just fine as my system stands with preauth turned on, but when preauth goes off, ticket forwarding stops working. This makes sense as a security feature and I realize I am shooting myself in the foot, but I am being ordered to shoot myself in the foot, and I am trying to minimize immediate bleeding. :) I would be surprised if preauthentication has any effect on the subsequent properties of the credentials, anyway, so I can't answer this one. 3. Does anyone have experience making MIT Kerberos work with a Cisco VPN 3000? I've looked through the Cisco documentation and it doesn't mention preauth or really much of anything except how to format your @ signs. Sorry! Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: LDAP gateway for Kerberos
Quoth [EMAIL PROTECTED] (talisman): | is there such a thing as a ldap gateway for kerberos i.e. | | the ldap gateway piece of software accepts ldap searches and returns | basic user info from kerberos, and accepts a bind and passes that | through to kerberos and returns success/failure back to the ldap | client? You can find an LDAP implementation that supports Kerberos authentication at http://www.openldap.org/ (plus Cyrus SASL), and I imagine there are others. Such an implementation would allow a client to use Kerberos credentials to authenticate during bind. The part about basic user info from Kerberos is not so obvious, inasmuch as, in general, there isn't any useful user info there. Some, maybe most, environments that use Kerberos also have a user database with all kinds of information, but if that's what you want, you'll have to ask about that (hypothetical) database. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberized telnetd: -a valid option eight char limit on account names
In article [EMAIL PROTECTED], Jeffrey Altman [EMAIL PROTECTED] wrote: hwntw wrote: ... The Kerberos bit comes in because Vintela vas authentication is essentially Kerberos auth. If I log in and do klist I get Ticket cache: FILE:/tmp/krb5cc_1001_SQ2421 Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 10/22/04 10:00:13 10/22/04 20:00:14 krbtgt/[EMAIL PROTECTED] renew until 10/23/04 10:00:13 That is the result of the VIntela product authenticating to Active Directory. Point is I telnet using a kerberised telnetd from the MIT distribution. Praps I am being unrealistic in expecting the -a valid argument to telnetd to work in this case. Nevertheless, the issue of the eight char limit on accounts names is still germane, as this is a Kerberos telnetd we are talking about, not the in.telnetd that comes with Solaris 9 (and which does not work at all with Vintela VAS). I should have mentioned that ssh connections do not exhibit this eight char account name limit The Vintela product is performing a Kerberos initial ticket request upon login. The telnet session is not being authenticated using Kerberos. You are typing in a user name and password. Hoping that it will help to make this semantic distinction, actually the Vintela product apparently isn't authenticating at all but rather leaving that to the MIT telnetd ... which, as you say, gets an initial ticket, which naturally appears on the remote end. Vintela appears to me to be the client. I am not aware of any restrictions on the length of the user name in MIT's telnetd. In particular, because telnetd does not know anything about usernames. The username is determined by the text entered into the 'login' program on the machine. 'login' more then likely is being replaced by Vintela. Could have been replaced by something, anyway. The system administrator on this host may know more about what's going on. To start with though, it might be worth looking at /etc/passwd on the remote host to see if these long names are in fact in there, in the first field as user IDs. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: OpenLDAP - GSSAPI (SASL) - KERBEROS V Questions
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Gerald (Jerry) Carter) wrote: Matt Joyce wrote: ... | How can I get more verbose error logs without recompiling? Verbose error logs for the krb libs or for Openldap ? The normal level syslog logs from the Kerberos KDC host can be pretty useful when there are authentication problems involving a service principal. The application error messages from the Cyrus SASL GSSAPI module will help a little, but unfortunately tend to omit specifics of the error. | And, once i've generated my ldap principal, and his key... | can I copy the key out of the keytab and chown/chmod it for | ldap in another directory and expect it to work? Since (as Sam already said), the service principal name is ldap/[EMAIL PROTECTED], each ldap server will need its own keytab. It sounds like you are asking if you can use the same keytab for multiple OpenLDAP installations. Sorry if i misunderstood. Or could be intending to run slapd under a less privileged UID than 0, for whom /etc/krb5.keytab is inaccessible. There's no reason that can't work, as long as you can specify the location of the keytab. The krb5 library mechanism for that, an enviroment variable KRB5_KTNAME, is the only way that comes to mind. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Heimdal or MIT kerberos
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Ken Raeburn) wrote: On Oct 4, 2004, at 01:40, Frank Cusack wrote: Heimdal does not have a functioning replay cache, so if your app needs that you must go with MIT. If heimdal is thread-safe, that's news to me. You shouldn't care if the apps you plan to use are off the shelf (sounds that way). MIT's use of a replay cache also leads to poorer performance of application servers under very heavy load (but if you're not under heavy load, do you care about that extra tiny fraction of a second delay?). I believe the replay cache may also be a contributor to MIT's reported worse behavior in multithreaded servers; none of that code is thread-safe, and we can spend quite a few cycles there. That fits with my observations with Cyrus SASL GSSAPI authentication in an LDAP service. Heimdal is commonly recommended there. I tried both, and MIT was indeed slower and crashed in the GSSAPI code under heavy load. But it's really pretty simple to add an interlock to the SASL GSSAPI module, which disposes of the issue entirely, and I felt that authentication was acceptably fast and we didn't need to abandon replay checking. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos and UW-IMAP
Quoth [EMAIL PROTECTED] (Luis Daniel Lucio Quiroz): ... | Well, I seems I forgot to export keytab for imap/server.name | | but where do you read that I should be on /etc/krb5.keytab? I'd like to reed | UW-IMAP doc but it's so poor :( Well, of course nothing in the code for imapd actually specifies /etc/krb5.keytab. That just happens to be the default location, in the predominate Kerberos implementations on UNIX. It's like inetd.conf, which you must modify if you install imapd -- unless your platform uses something else. Your UNIX system administrator is presumed to be a more reliable source for this than the author of imapd. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos and UW-IMAP
Quoth [EMAIL PROTECTED] (Luis Daniel Lucio Quiroz): | Well, I was wondering if someone has a successful history on setting up | WU-IMAP 2002+ (I use 2004) with Krb auth? I have just this realms | configured | | imap/host.domain ... | but then what I shall do? WU IMAP does no have enoght doc. Shouldn't need one for this (though I guess one benefit of more documentation might be that people would know its name better - WU?) The source distributions does have directions for building with Kerberos 5. If that happened, and the key for that imap service principal is there in /etc/krb5.keytab, the server should support GSSAPI authentication. Apple Mail, Pine are a couple of clients that come to mind that support GSSAPI authentication. imapd logs to the mail syslog log. There is a comp.mail.imap newsgroup, where people know more about this software. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: storing tickets in memory
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Ken Raeburn) wrote: On Jun 10, 2004, at 09:11, Adam Denenberg wrote: ok thanks for the info. I did some reading and was basically thinking of implementing kerberos here on our unix systems but read about some security concerns about ticket credentials being stored in /tmp. Meaning anyone with root can become another user and steal his/her credentials. How do people deal with this security issue? By realizing that unless your OS significantly curtails the access granted to root, the root user can look at users' shared memory segments and local process memory, or run processes as the target user, or modify system software to do things the users don't intend; so basically, the game is over once the bad guy gets root access. I think there may be two questions here. One of them is your bad guy scenario, which I suppose applies just as well to my personal NetBSD desktop computer as to a host in the basement with thousands of accounts. The other is about per host level of assurance, where we assume that every host's administrator is to some level a bad guy. Take for example a university campus -- many departments will maintain their own sites, with a vast range of security policies, and then there will be a lot of one-of-a-kind hosts run by some professor's graduate student, dormitory residents, who knows what all. People on campus are using these hosts, usually several of them if any, and we would like to think that their access to a residence hall computer wouldn't compromise their account on the central site financial database. I think this is actually a strong point of Kerberos authentication, relative to the alternatives, because you _don't have_ credentials on the remote host, so it sort of doesn't matter what happens to you there. Only the data you actually send to that host, or get back from it, can be compromised, and your credentials are not part of that data stream. (I wish that were easier for people to understand.) In contrast, if you use ssh or SSL to encrypt your password, for example, it's going to be unencrypted on the remote end, and your primary authentication key is utterly exposed to the remote host's administrator. So it seems to me, to answer `How do people deal with this security issue?', I would start by asking, why is it an issue? Why does your user have credentials on this host? Maybe there's a good reason, like it's the user's workstation which is obviously where the credentials are going to be, but just to be aware that not every host that plays the Kerberos game keeps user credentials. And of course then there's the Kerberos authenticated filesystem, but I don't know that can of worms/garden of delights by experience. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: FTP - GSSAPI Error acquiring credentials
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Pierre Goyette) wrote: I have a Solaris box with MIT Kerberos 1.3.3 installed as an application server which is part of a Windows 2000 KDC. I can perform a kerberized telnet to the box perfectly. However, I cannot ftp to the box. ... A Ethereal trace shows the client receiving a 501-GSSAPI error minor: no principal in keytab matches desired name. ... On my client, I properly acquire all the right tickets, klist -e shows: Ticket cache: API:krb5cc Default principal: [EMAIL PROTECTED] Valid starting Expires Service principal 06/08/04 08:01:18 06/08/04 18:01:18 krbtgt/[EMAIL PROTECTED] renew until 06/15/04 08:01:18, Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5 06/08/04 12:04:48 06/08/04 18:01:18 host/[EMAIL PROTECTED] renew until 06/15/04 08:01:18, Etype (skey, tkt): DES cbc mode with RSA-MD5, DES cbc mode with RSA-MD5 06/08/04 12:05:47 06/08/04 18:01:18 ftp/[EMAIL PROTECTED] renew until 06/15/04 08:01:18, Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32 Kerberos 4 ticket cache: API:krb4cc I see your ftp service ticket's encryption is different from the host service ticket. If you could, as root, try $ klist -k -e does the ftp key's encryption type match your service ticket? Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: gss_accept_sec_contextand channel binding in ftp
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Markus Moeller) wrote: I noticed that from MIT version 1.2.4 to 1.3.1 the gss_accept_sec_context call has changed in ftpd.c. It is now set to use always GSS_C_NO_CHANNEL_BINDINGS. I also noticed that changing the channel bindings in gss_init_sec_context on the client doesn't create an error I would expect. I also see a different behaviour in my proftpd mod_gss module. If the client uses gss_init_sec_context with GSS_C_NO_CHANNEL_BINDINGS, the channel bindings settings in gss_accept_sec_context on the server are ignored (e.g if the server uses channel bindings with application data set and the client used GSS_C_NO_CHANNEL_BINDINGS the client can login) Is this intention ?? I can't speak for the MIT Kerberos developers, but I feel fairly confident that it was not an accident. Moreover, it is quite useful for GSS Fetch users behind NATs, for example. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: deletion of old keys
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Sam Hartman) wrote: Lara == Lara Adianto [EMAIL PROTECTED] writes: Lara Hi, In section 4.1 of RFC 1510, it is mentioned that When Lara an application server's key changes, if the change is Lara routine, the old key should be retained by the server until Lara all tickets that had been issued using that key have Lara expired It means in the keytab, not the KDC database. There's not currently a way to delete key data from the kdc if you use the option to retain old keys. Which is probably not an issue, right? I mean, unless this option is widely used. If I may elaborate a little (I hope someone will correct me if this isn't right), a service ticket for your service is based on the key for that service at the time the ticket was issued, of course. Then, for the rest of its lifetime, it needs to match the key in the keytab file. That key is identified by kvno, so it's possible to retain the old key alongside the new key. (Assuming MIT or Heimdal Kerberos, not MS.) The time span during which this is an issue depends on ticket expiration. Once that time has elapsed, the old key may be removed by the system administrator. Or left in there, doesn't make any difference. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberizing a non-kerberized telnet client
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Burkhardt, Andrew) wrote: ... We have setup a test Windows Server 2003 Domain/KDC. We have a Windows 2000 Professional computer using the kerberized Ktelnet client, connecting to a Red Hat 9 Linux box running kerberized telnetd, and successfully authenticating using Kerberos. Basically, everything is running correctly in the environment. The problem is we use a non-kerberized telnet client in the field. We are heavily dependant on this client, meaning we can not change clients and fyi, there are no kerberized upgrade for this client. Is there a way to wrap a non-kerberized telnet client so it will use kerberos authentication? Has anyone had any experience with this problem? I am looking for any suggestions. Many thanks! I don't recall ever hearing of a Kerberos telnet wrapper, but it could be worth a look. We did something like that here with FTP, for the sake of web development tools that use it, and it seems to have worked out fairly well. You'd have to know something about the telnet protocol and how Kerberos fits in, which I guess you could get from the MIT source. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: loadbalancing of keberized services
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Jeffrey Hutzelman) wrote: On Monday, April 12, 2004 16:52:23 -0700 Donn Cave [EMAIL PROTECTED] wrote: I believe we're more or less always asking for this trouble. If you don't get a canonical, reverse looked-up name back out of MIT Kerberos krb5_sname_to_principal(), then you're doing something different than me. Well, for starters, I don't call MIT kerberos krb5_sname_to_principal() very often, since I don't currently use that implementation. So, do you currently use an implementation where that function or its equivalent doesn't return a canonical name? My experiment with Heimdal 0.6 tells me it works just like MIT, but I am not as familiar with that implementation and could be missing something. Performing DNS alias resolution in krb5_sname_to_principal() is insecure unless you have a well-managed DNSSEC infrastructure, which virtually no one does. I have always considered this behaviour to be an implementation bug. While this is not addressed well enough in RFC1510, the next version of the Kerberos V spec (due out later this year) will include the following text: Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names (i.e. MUST NOT use insecure DNS queries to map one name to another to determine the host part of the principal name with which one is to communicate). The language I read (I think it was at least 6 months ago) didn't even leave room for CNAME alias translation, let alone reverse lookup canonicalization. I don't think it's really fair to call current behavior a bug, because it has too large of a constituency. Whatever MIT chooses to do about it after this spec comes out, I wouldn't care to be in their shoes. It would be especially ironic if adequately secure DNS were to become widespread in a year or two from now. So after a decade of supporting a naming model with this security problem, Kerberos switches to a different model just about the time the old one becomes safe for anyone who cares. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: loadbalancing of keberized services
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Jeffrey Hutzelman) wrote: On Saturday, April 10, 2004 16:47:21 + Donn Cave [EMAIL PROTECTED] wrote: It depends on your client software. All you need to do is resolve the addresses to canonical host name first, and use the resolved name for both the client connect and the service ticket. Careful here... Using insecure DNS to compute a service principal name is asking for trouble. You're OK if, as suggested, you compare the resulting name to a list of known valid servers, but that's a fair bit of work and most software that does reverse resolution to determine service names either can't or doesn't do it. I believe we're more or less always asking for this trouble. If you don't get a canonical, reverse looked-up name back out of MIT Kerberos krb5_sname_to_principal(), then you're doing something different than me. Given that implementation, you're going to do the reverse lookup anyway, so the only question is whether it would be convenient to actually connect to the same host. I assume so, that's why I'd propose to look up the canonical name in the application. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: loadbalancing of keberized services
Quoth vadim [EMAIL PROTECTED]: | I am evaluating now a possibility of load balancing between several ldap | servers. I imagine each ldap server will bind to its own ip address. | LDAP client will try to connect to ip address of the loadbalancer and | the loadbalancer will distribute requests between ip address of ldap | servers. I am not following you. I expect the domain name service (DNS) to distribute load by rotating a list of one or more IP addresses, for a single well known LDAP server domain name. Maybe that's what you mean. The details of what you're proposing to do are important. | If I use GSSAPI to authenticate my clients against ldap servers, I am | afraid I will get in troubles, as my clients will ask for ticket for | | ldap/[EMAIL PROTECTED] | | although they will be connected to ldapservers with principals like | | ldap/[EMAIL PROTECTED] or ldap/[EMAIL PROTECTED] ... It depends on your client software. All you need to do is resolve the addresses to canonical host name first, and use the resolved name for both the client connect and the service ticket. (It would be nice to check the resolved name against some list of valid hosts, in case you're vulnerable to DNS spoofing.) You might do this in the actual LDAP client program if you have the source, or in a wrapper script otherwise. This reverse lookup procedure uses gethostbyname() and then gethostbyaddr() with the result. If you can't do that, then I guess you will need the keys for each server host, on all server hosts - ldap/server1 + ldap/server2 + ... Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kerberos password change in master-slave environ
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Ken Hornstein) wrote: Our realm has 43,000+ principals so for us, its a big deal. :) We have slaves not only for redundancy, but also for load balancing. We don't want all the users on our campus authenticating or changing passwords against just one machine. With ticket caching, the load against one KDC hasn't been really that bad, from my experience. I'll second that. We have roughly twice as many, and I have never noticed any significant amount of traffic to the secondary, even without much caching (Kerberos per se has never really caught on here, mainly due to lack of applications, so authentication mostly means acquiring initial credentials and then throwing them away.) However, dump propagation and performance were part of the issue when we set up our own multimaster system some years back. - Propagation takes up resources on the master, especially during the dump. Not a desperate problem if you have a fast computer and you're doing it once an hour, but I didn't think we could afford to do it, say, every 5 minutes (and that's the minimum, because we couldn't finish it in less than 5 minutes.) - Fallback to slave servers will be infrequent, but significant. We couldn't totally disregard the phenomenon for user support purposes, it will happen often enough that it has to work right. - Lag between master and slave - 30 minutes, 60 minutes, something like that - would be a user support issue. See previous point: hard to say `has to work right' and then allow this. People's new passwords would not work, perhaps intermittently, during a fallback episode. Our system revolves around some software locally developed out of a legacy system, with only minimal changes to the KDC. This approach has been very successful, in my opinion, and if anyone is thinking about developing a more general solution in this area, it's a model to consider. Useful in a heterogeneous authentication environment. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kerberos password change in master-slave environ
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (John Hascall) wrote: ... We are running MIT's with our own incremental replication code (we replicate to the slave, our W2K-AD, and our Novell NDS). Basically, we put 5 little hooks in the kadmin libs that write 'transaction log records' into a directory. Everything else is done with external programs and scripts. I've posted more details which should be in the list archives someplace. That sounds similar to our setup. Same hooks, but of course different external software. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Sam Hartman) wrote: Lukas == Lukas Kubin [EMAIL PROTECTED] writes: Lukas Is there any progress in the ability of Kerberos libraries Lukas on Linux to be used by threads-enabled applications? I'm Lukas still having troubles using sasl kerberos authentication to Lukas ldap server on Linux (Debian). It always fails when Lukas parallel connection appears. Is there any solution for Lukas this now? Thank you. I believe someone has written a patch to the SASL library to use mutexes around GSSAPI calls. That sounds like Simon Wilkinson. I have done this too, but I'm sure his code is at least better tested. Unless I missed something, it can be done with fairly simple changes to one source file (plugins/gssapi.c) and does away with a few little headaches if you're not otherwise using Heimdal already. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: OpenSSH 3.7, kerberos thru pam
Quoth [EMAIL PROTECTED] (Patrice Seyed): | I'm running openssh-3.7.1p1, /etc/pam.d/authconfig is syntactically | correct regarding pam_kerb5.so, and /etc/krb5.conf and /etc/krb.conf are a | pristine working config from another linux system. (oh running | 2.4.21-4.0.1.ELsmp also here). | | so kerberos will only work/authenticate properly with this setup when i | uncomment in | /etc/ssh/sshd_config: | KerberosAuthentication yes Yes. | i think is the mechanism for going around PAM though. Yes. As I understand it, PAM is not Kerberos authentication in the sense that your ssh client uses your local credentials to get a service ticket for the remote sshd. Rather, it is password authentication - your password goes across the wire to the remote sshd - where the Kerberos module acts as a proxy client+server to validate the password. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: new kerberos5 1.3.1 possible config problems
Quoth Jacob Williams [EMAIL PROTECTED]: ... | When I try to use the service in any way (even just using kinit) i get the res | kinit(v5): Client not found in Kerberos database while getting initial credent | and I cannot work out what this means or what I need to do to fix it. Hard to say. I would look in the KDC syslog, or if you don't have access to it yourself, ask someone who does (mention time, date and your IP address.) This log will show the full principal name in your request. (Assuming you're actually configured for the correct realm - if not, then of course nothing will appear in that log. You might try the full [EMAIL PROTECTED] principal name with kinit.) The KDC syslog is really essential for troubleshooting configuration problems and things like that. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: documentation for ssh/gssapi auth anywhere?
In article [EMAIL PROTECTED], paul [EMAIL PROTECTED] wrote: ... debug1: Miscellaneous failure No principal in keytab matches desired name I'm stuck here, what is the desired name? host/[EMAIL PROTECTED] where host is the literal string host address is the full canonical DNS address of the host computer realm is the Kerberos realm, exact case (rarely needed.) Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Last successful authentication always set to never
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (John Hascall) wrote: When I do getprinc on any principal in our REALM, it prints the attributes Last successful authentication and Last failed authentication set to value [never]. Similarly, the value of Failed password attempts is 0. Why the system doesn't update that values? Thanks. When you 'configure' kerberos during the build process, you need to include the '--with-kdc-kdb-update' flag to enable this. And then you need to put the 'requires_preauth' attribute on your principals. MIT will tell you these features are 'not well tested', but they seem to work fine for me. Requires an update to the database for each authentication, right? For us, that would be a fairly radical increase in the number of updates per day. Seems like there would also be a propagation issue, since these updates would automatically apply to the master only if the master is also taking all the authentication requests. I would get that information from logs, instead. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: preauth error
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Kristian Rink) wrote:
...
kerberos:~# tail /var/log/krb-kdc.log
Oct 07 11:44:18 kerberos krb5kdc[192](info): preauth (timestamp)
verify failure: Decrypt integrity check failed Oct 07 11:44:18
kerberos krb5kdc[192](info): AS_REQ (6 etypes {18 16 23 1 3 2})
192.168.10.170: PREAUTH_FAILED: krink/[EMAIL PROTECTED] for
krbtgt/[EMAIL PROTECTED], Decrypt integrity check
failed
When I've seen that `preauth (timestamp)' error, it has
indeed meant that there is a substantial time discrepancy
between the KDC and client.
Donn Cave, [EMAIL PROTECTED]
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)
I don't think this qualifies as new at all. Since you are not able to provide accurate information about your problem, you are going to have to rely on your own resources for the most part. The key point that you have to accept, is that when you get this error `No principal in keytab matches desired name', it's due to either the most trivially obvious cause: A. the remote host hasn't been set up with its own ftp key, or if that isn't the problem, it has to be B. the ftp client uses a different name for the host than the host uses for itself. There are various ways to diagnose the latter problem, but of course they are not very useful where the actual host names have to be cloaked in mystery. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Q: Ordering master/slave KDC's in CLIENT machines' krb5.conf
In article [EMAIL PROTECTED],
MattW [EMAIL PROTECTED] wrote:
Please help me understand how I should order the
client's list of KDC's it can contact in the krb5.conf file.
I have:
[realms]
YADDA.WASHINGTON.EDU = {
kdc = kdc.yadda.washington.edu
kdc = kdc1.yadda.washington.edu
kdc = kdc2.yadda.washington.edu
admin_server = kdc1.yadda.washington.edu
default_domain = yadda.washington.edu
krb524_server = kdc1.yadda.washington.edu
}
NOTE: kdc.yadda.washington.edu points to the master, which is
kdc1.yadda.washington.edu
but I have MANY clients which will need to set up to use
kerberos, and kdc1 and kdc2 are on different subnets.
Should I put the kdc that is the closest (fewest hops, or local)
first in the list? or should I always put the master server first,
regardless of network proximity.
Am i nit-picking here? Does order matter in the kdc list?
Yes.
The addresses are contacted in order until one responds,
but some requests may then also find their way to the master
server. Master is however spelled admin_server, so in your
example the master is really kdc1. As far as I know, the first
KDC on the list will be contacted first, but otherwise gets
no special status from this.
You may also be interested in the use of DNS records to do this.
Cf. for example, SRV record for _kerberos._udp.u.washington.edu,
and TXT record for _kerberos.u.washington.edu. That allows
applications in u.washington.edu to find the realm's KDC without
any local configuration file. If you have a serious issue with
network connectivity, that might be another way to address it
(though I would think it's highly unlikely to be worth it - I mean,
the DNS records are a fine idea, especially if you don't have a
name collision with a Windows domain, but having them resolve
to different hosts depending on the DNS server would be only
for the desperate.)
Im curious how failover is done if my router to the first
kerb server in the list goes down.
It's done with select() on the socket file descriptor in conjunction
with the connect() function.
Donn Cave, [EMAIL PROTECTED]
Kerberos mailing list [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Ssh trouble with forwarding
Quoth [EMAIL PROTECTED] (Matthijs Mohlmann): | I have trouble with ssh en forwarding. ... | Now when i try to login to my ssh service with the following command: | [EMAIL PROTECTED]:~$ ssh -A -K active2.active2.homelinux.org | Password: | | I don't want that password prompt. My ticket is enough to authenticate | me. | | When i now do some debugging: | Active2:~# ssh -d -f /etc/ssh/sshd_config ... | 17612: debug1: Miscellaneous failure | 17612: debug1: No principal in keytab matches desired name | | What does this mean ? I have a | host/[EMAIL PROTECTED] in my | /etc/krb5.keytab on the ssh-server. I have also a ssh service key in my | keytab (ssh/[EMAIL PROTECTED]) However, the IP address associated with that name seems to be actually hosted at x4sall.nl, under another domain name. Your key unfortunately has to match that canonical domain name, rather than active2.active2. Or at any rate, you have to use whatever name the host uses for itself. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Ssh trouble with forwarding
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Matthijs Mohlmann) wrote: On Tue, 2003-09-02 at 05:12, Donn Cave wrote: Quoth [EMAIL PROTECTED] (Matthijs Mohlmann): ... | Now when i try to login to my ssh service with the following command: | [EMAIL PROTECTED]:~$ ssh -A -K active2.active2.homelinux.org ... | 17612: debug1: Miscellaneous failure | 17612: debug1: No principal in keytab matches desired name | | What does this mean ? I have a | host/[EMAIL PROTECTED] in my | /etc/krb5.keytab on the ssh-server. I have also a ssh service key in my | keytab (ssh/[EMAIL PROTECTED]) I have my own dns-server for internal network. And my domain is active2.homelinux.org. My computers are name.active2.homelinux.org and all this names are in the dns. I have checked what ip every computer is using and it sounds to me as oke active2.active2.homelinux.org - 192.168.0.2 server.active2.homelinux.org - 192.168.0.7 router.active2.homelinux.org - 192.168.0.1 $ host active2.active2.homelinux.org active2.active2.homelinux.org is a nickname for active2.homelinux.org active2.homelinux.org has address 80.126.240.96 active2.homelinux.org mail is handled (pri=5) by active2.homelinux.org active2.homelinux.org mail is handled (pri=10) by bulletgate.org $ host 80.126.240.96 96.240.126.80.IN-ADDR.ARPA domain name pointer a80-126-240-96.adsl.xs4all.nl There's a limit to what we can tell from here, but believe me, it will not work until the name the host knows itself by, and the name in the Kerberos host principal, are the same. This is the problem you have to solve. If you have access to logs from the KDC, you can see exactly what the principal name needs to be. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kerberos ftpd bug? can't get it to work
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (root) wrote: HAS ANYONE GOTTEN FTP/FTPD TO WORK ON KERBEROS V5? I need help. Talk to us. Douglas Engert posted a followup in response to your initial question. He asks what host name you're connecting to, what host name is in the keytab. I might add, what host name shows up in klist afterwards, if any. GSS ftp does have some host name issues. On the bright side, at least you're not running krb5-1.3 yet, so telnet probably works. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Decrypt integrity check failed
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Muhammed Reahan) wrote: Decrypt integrity check failed First of all I created a principal name test. It is successfully created i entered the password for it two times. ... Then i added the entry for the principal in the keytab file as kadmin.local: ktadd test Entry for principal test with kvno 2, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab. ... Now i want to get the ticket of principal test with kinit command. kinit test Password for [EMAIL PROTECTED]: kinit: Password incorrect i entered the password correctly which i entered the first time.But automatically password is changed. i have tried this with two or three principals. Yes, ktadmin invents a pseudo-random key when it adds a keytab entry, so there is no way to subsequently authenticate with a password. If you want a keytab entry and a known password, you have to use ktutil to create it. I think ideally this would very rarely be necessary. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Password-less authentication with OpenSSH 3.6.1 and krb5/GSSAPI
Quoth [EMAIL PROTECTED] (Kerry Thompson): ... | I've since run into the same problem, it seems that OpenSSH with Simon's | patch doesn't enable GSSAPI properly when built out of the box. Maybe a | problem with the patched ./configure or configure.ac or autoconf or | something. You can quickly check the status by running 'grep -i gssapi | Makefile' and seeing if you've got the GSSAPI stuff being linked into | the OpenSSH build or not. You have to run autoreconfig after applying the patch. That's the part that's easiest to forget to do, at least it was for me. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: telneting into solaris 8 kerberized telnetd prompts for passwd
In article [EMAIL PROTECTED] oft.com, [EMAIL PROTECTED] (Peter Himmelfarb \(Excell Data Corporation\)) wrote: ... ./telnet -a -x msaum01 Trying 10.10.0.10... Connected to abc.abc.com (10.10.0.10). Escape character is '^]'. Waiting for encryption to be negotiated... [ Kerberos V5 accepts you as ''[EMAIL PROTECTED]'' ] done. Last login: Fri Jun 27 11:47:13 from 10.10.0.10 Password: That would suggest to me that the client's Kerberos principal, [EMAIL PROTECTED], isn't authorized to log in on any particular account on that host. In the simple case that means there isn't a bullet in the password file, but at any rate there must be some mapping from [EMAIL PROTECTED] to user. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Forwarding Kerberos Credentials - SSH
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Parag Godkar) wrote: ... 9. Now from this telnet/ssh session, I would like the users to telnet/ssh to another linux server (or to the same server) in the same kerberos domain WITHOUT BEING PROMPTED FOR A PASSWORD. NOW THIS IS WHAT I WANT TO KNOW IF IT IS PRACTICABLE OR I AM TRYING TO DO SOMETHING IMPOSSIBLE? Yes! It is possible, and everything up to here leads me to expect it will work. But as another followup has already pointed out, the server apparently has no service key - from the server diagnostics, Miscellaneous failure No principal in keytab matches desired name Someone needs to create a principal host/x.y.z and add its key to /etc/krb5.keytab on x.y.z (the remote host.) Remember when testing the client, you must do that as the user who logged in and has the credentials -- don't do it as root. 3. I have the following relevant lines in my sshd_config - #RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys #PasswordAuthentication yes #PermitEmptyPasswords no #ChallengeResponseAuthentication yes KerberosAuthentication yes #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes GssapiAuthentication yes GssapiKeyExchange yes GssapiUseSessionCredCache yes #AFSTokenPassing no #KerberosTgtPassing no #PAMAuthenticationViaKbdInt no and the following relevant lines in my ssh_config - # Host * # ForwardAgent no # ForwardX11 no # PasswordAuthentication yes GssapiAuthentication yes GSSAPIDelegateCredentials yes KerberosAuthentication yes alone, in both, should be enough, something you can easily try if you have further difficulties. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Forwarding Kerberos Credentials - SSH
In article [EMAIL PROTECTED], Frank Cusack [EMAIL PROTECTED] wrote: Wow. Lots of info. :-) I'll quote it all, since it's so involved that it will be useful to have a complete reference in a single message. Good - so, folks who want that complete reference: you know where to go! No. Only if you want to use ssh protocol 2. ahhh... this is the problem. By default, ssh will select protocol 2. Which doesn't support krb5. So you must tell it to use protocol 1, and probably must tell the server to do krb5 (probably sshd_config on the server doesn't accept krb5 by default). I found this all a little confusing, and I'm sure there are people here who know more about the GSSAPI OpenSSH patch, but in case it helps ... The way I read it, he applied this patch with the expectation that it provides Kerberos support for protocol 2, and that is true - it should. Only between patched OpenSSH servers and clients, because unfortunately it doesn't interoperate with the ssh.com approach to Kerberos 5 for protocol 2. I agree that ssh -v ought to help narrow down the problem. It might be worth trying some other Kerberos 5 application - I believe we're talking about Redhat Linux here, where the telnet and ftp applications should support Kerberos 5. Secondly I think the term forwarding doesn't apply to the scenarios I'm reading about here. If you log in to sshd with your Kerberos password, the remote credentials acquired in the process are actually local in this sense - they reside on the host that acquired them, as sshd did that. When used to authenticate to some service from there, that's just simple basic Kerberos authentication, no forwarding needed. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Host Alias
| I have come across a usability issue where users of a network I plan | to implement Kerberos on are currently accustomed to host aliases. | i.e: typing 'ftp foo' instead of 'ftp foo.my.long.host.name.com.' | | Anyone have advice on how to get around using fully qualified hostnames | for Kerberos host principals? On the contrary, you certainly should use fully qualified hostnames for Kerberos host principals. That also should work, that is, you should be able to type 'ftp foo' and it should be automatically expanded to the full domain name. If it isn't, the reason is likely the short comes before the full name in /etc/hosts. The same is true of alias names in the DNS CNAME sense, that they should just work in current implementations (though perhaps not forever, if I read the draft right.) Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: krb5 ticket cache
Quoth [EMAIL PROTECTED] (Klaas Hagemann): ... | after doing kinit the kerberos client creates a krb5 ticket cache file | like /tmp/krb5cc_506. | | Another user having root privileges on this client can optain these | ticket cache file and have the network wide rights of the owner of this | ticket. | | Is there any chance that the ticket is stored in memory rather than on | the local disk? can i configure it in any way? Yes! Try this: $ KRB5CCNAME=MEMORY:0 kinit Password for [EMAIL PROTECTED]: Now look for your credentials in /tmp, and they won't be there. They won't be anywhere else either, they're just gone, along with the kinit process that owned that storage, but that would be what you wanted. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos5 NAT and kftp
Quoth [EMAIL PROTECTED] (Jeffrey Altman): | You need to use an FTP client that allows you to disable the use | of channel bindings. See C-Kermit | | http://www.kermit-project.org/ckermit.html | | It will do what you need when the command | | SET AUTH K5 NO-ADDR ON You also need a patched ftpd, right? Or does the GSS ftpd from the current MIT release now support clients from behind a NAT? Donn Cave, [EMAIL PROTECTED] | In article [EMAIL PROTECTED], | Protima Chhabra [EMAIL PROTECTED] wrote: | : Hi, | : | : I have a Kerberos client sitting behind a firewall doing NAT. I have | : patched my client and added the proxy gateway to my configuration file, as | : explained in the document below | : |http://www.ncsa.uiuc.edu/UserInfo/Resources/Software/kerberos/firewall.html#proxy | : | : I can get a ticket, get ktelnet to work with an error message, but kftp | : does not work, as shown below. Can someone tell me what is it that I am | : doing wrong. | : | : Thanks | : Protima | : | : |-- | : kclient101% klist | : Ticket cache: /tmp/krb5cc_11617 | : Default principal: [EMAIL PROTECTED] | : | : Valid starting ExpiresService principal | : 11/14/02 19:06:17 11/15/02 05:06:15 [EMAIL PROTECTED] | : | : | : kclient102% ktelnet opal0-gx.main.KRB.COM | : Trying 255.255.255.255... Connected to opal0-gx.main.KRB.COM | : (255.255.255.255). Escape character is '^]'. [ Kerberos V5 accepts you as | : ``[EMAIL PROTECTED]'' ] [ Kerberos V5 refuses forwarded credentials because | : Read forwarded creds failed: Incorrect net address ] Last login: Thu Nov 14 | : 17:58:26 from 68.156.252.64.snet.net | : opal0 exit | : opal0 logout | : Connection closed by foreign host. | : | : kclient103% kftp opal0-gx.main.KRB.COM | : Connected to opal0-gx.main.KRB.COM. | : 220 opal0 FTP server (Version 5.60) ready. | : 334 Using authentication type GSSAPI; ADAT must follow | : GSSAPI accepted as authentication type | : GSSAPI error major: Incorrect channel bindings were supplied | : GSSAPI error minor: No error | : GSSAPI error: accepting context | : GSSAPI ADAT failed | : GSSAPI authentication failed | : Name (opal0.main.KRB.COM:user): | : 530 User user access denied: authentication required. | : Login failed. | : Remote system type is UNKNOWN. | : ftp bye | : 221 Goodbye. Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: afs-krb5 integration
Quoth [EMAIL PROTECTED] (Sam Hartman): | Josh == Josh Huber [EMAIL PROTECTED] writes: ... | Josh I like the thought of more integration of AFS and krb5. | | Not surprisingly those of us who worked on this proposal had similar | motivations. Excellent. I'm encouraged enough by all this to overcome my embarrassment and ask a very basic question about AFS and krb5. Unlike (I gather) most or all AFS sites, we never used Kerberos 4 here, we started with V5 (after a brief flirtation with DCE.) Hence, no --with-krb4, no Kerberos 4 salted keys, just pure krb5. Will pure V5 work with AFS, once implementation of all this new stuff is nailed down? Am I right that the classic krb524d AFS support depends on V4 keys in the V5 KDC? Thanks, Donn Cave, [EMAIL PROTECTED] An alternate conversion is provided for AFS servers that support the encrypted part of a krb5 ticket as an AFS token. If the krb524d is converting a principal whose first component is afs and if the encrypted part of the ticket fits in 344 bytes, then it will default to simply returning the encrypted part of the ticket as a token. If it turns out that the AFS server does not support the ticket, then users will get an unknown key version error and the krb524d must be configured to use v4 tickets for this AFS service. Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: Eudora-Mac-Cannot communicate with Kerberos
Quoth [EMAIL PROTECTED] (Ken Hornstein): | So this is really a good news to me. May you let me know | what specific configuration I need to modify to make it work. | | You need a V5-capable KCLNT32.DLL (that's the Kerberos piece that | Qualcomm doesn't provide). That's sorta specific to your Kerberos | implementation, though ... I could give you mine, but if you're using | a newer Kerberos release, it probably won't work. I think we got ours | from Donn Cave, originally. I don't think so! It doesn't come with the MIT Kerberos5 distribution for Windows, you're saying? As for Eudora, I have seen 4.3 authenticate with GSSAPI-Kerberos5 to an IMAP service, but at the time that was apparently for IMAP only, and Windows only. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: krb5_rd_req: Wrong principal in request while reading request
Quoth [EMAIL PROTECTED] (Thomas Huang): | I am trying to setup a kerberorized service (using kerberos 5 v1.2.2) | on a Solaris 7 machine. When trying to connect to this service using | a kerberorized client, the server returned the following error | message: | | krb5_rd_req: Wrong principal in request while reading request | | I have verified my /etc/krb5.keytab has the correct entries. I was | able to use 'kinit -k -t /etc/krb5.keytab -S myserivce principal' | to obtain a service ticket on that server host. I have also updated | the /etc/hosts file to make sure the fully qualified host name is on | the first position. My guess is some how the host lookup is | returning a different host name, but I am sure I am on a single home | machine. My /etc/nsswitch.conf has the following entry on for hosts | | hosts: nisplus dns [NOTFOUND=return] files | | I am not very good in system administration. Any ideas? Not really, but I agree that's a likely cause. If you can look (or get someone to look) in the syslog records for the KDC, you should see the exact ticket the client gets, and that ought to be helpful. Or for that matter, you should have the ticket in your credentials cache after you run the client, so try klist. In either case, it may be helpful to clear the cache first. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: Compiling 1.2.5 on True64 v5.x
Quoth Peter Losher [EMAIL PROTECTED]:
| Has anyone encountered an issue compiling Kerberos 1.2.5 on a Tru64 {5.0 or
| 5.1) box using Compaq's C compiler? Any pointers would be welcome.
Well, I just had a go at it with Digital UNIX 4.0, using DEC's
C compiler. What a mess! Your compiler sure seems to be more
tolerant than mine. I'm having to fix several include files,
where preprocessor macros were indented. (Folks, if you must
indent a preprocessor macro, that's fine, but the # has to stay
in the first column.) With those fixes, it did build.
But I don't have your problem - maybe because DU 4.0 doesn't
even have an in6.h. The authors of in6.h apparently expect
typedefs like uint8_t to exist, but don't manage to make
that happen. You'll have to find where they're supposed to
come from - not sys/types.h, evidently, but no doubt something
like it. Your compiler may actually be misconfigured, like
someone installed a IPv6 option but some include files were
not updated. It's going to bite you every time you try to
compile just about anything.
Donn Cave, [EMAIL PROTECTED]
| (Error message below)
...
| cc: Error: /usr/include/netinet/in6.h, line 55: Missing type specifier or
| type qualifier. (missingtype)
| uint8_t sa6_addr[16];
| ^
Kerberos mailing list [EMAIL PROTECTED]
http://mailman.mit.edu/mailman/listinfo/kerberos
Re: Compiling 1.2.5 on True64 v5.x
Quoth [EMAIL PROTECTED] (Tom Yu): [... re indented # in preprocessor statements] | Did you use the -std flag to cc? It's documented in the build notes | as being necessary. Tru64 4.x I think had a cc that defaulted to KR | mode. No, I didn't use -std, and it does help with the indented parentheses. Minus that problem, it doesn't appear to be necessary at this point - in terms of compiler errors, anyway, from there on it was all about signed vs. unsigned. Digital UNIX cc doesn't so much default to KR, as accommodates it. It would work fine everywhere you have #ifdef __STDC__, as would any fairly recent compiler. But it doesn't define __STDC__, and that's really what -std is usually about -- it's just there to get that macro. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: Building from source question (krb5 1.2.5) ...
Quoth [EMAIL PROTECTED] (Sam Hartman): | No. Kerberos has no TLI support at all. | | Obviously you could write this support since you have the source, but | that would be significant work. Our PTX machine went out via the loading dock many years ago, and I have only vague memories of it. One is replacing Berkeley socket API calls with TLI functions to get things to work. The other is finding out that the socket version of the application could as easily have been fixed, and that we didn't seem to really need TLI for anything. The socket library is a third party effort that wasn't as excellent as it would be on a real Berkeley type UNIX, but I don't remember any problems with applications that do ordinary things and are written correctly. I don't remember how much MIT krb5 I got running there. Some, I'm pretty sure, but that would have been ca. beta7, and things have changed a little here and there since then. The SIOCGIFCONF etc. stuff in krb5/os/ might be an obvious suspect if nothing works, for example. Exotic stuff like this may just need to be avoided, as you'll notice it already is avoided for non-UNIX platforms. Will need PTX specific stuff for util/pty (man getpseudotty), if building an application that uses ptys. It's some work, but not like rewriting to TLI - and that might not work anyway, if the actual problem is no better understood than sockets are bad! Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: Odd Kermit Kerberos problem
Quoth [EMAIL PROTECTED] (Ed Ravin): | I encountered a very odd problem with Kermit and Kerberized | telnet today. I tried to use kermit to connect to a host: | | $ kermit -J serverhost |DNS Lookup... Trying 192.168.1.23... Reverse DNS Lookup... (OK) | No credentials found with supported encryption types while authorizing (3). | Authentication failed: No authentication method available | | This was odd because I had just Kerberized using /usr/bin/telnet to a | different host. I tried serverhost with telnet, it Kerberized without | a problem, then tried Kermit again, and it now could Kerberize without | a problem. | | Environment is NetBSD 1.5.2, with MIT libraries and KDC. | | Any idea what might be going on here? No, and I don't want to. I just want the encryption types pain to end. But if you can repeat this, you might use klist -e to check up on your credentials before and after these steps. On NetBSD, /usr/bin/telnet would normally be Heimdal, not MIT. These two implementations can use the same krb5.conf, but there are differences that happen to be related to encryption types. My MIT krb5.conf has these two lines in [libdefs]: default_tkt_enctypes = des-cbc-crc default_tgs_enctypes = des-cbc-crc and I added these for the Heimdal applications - default_etypes = des-cbc-crc default_etypes_des = des-cbc-crc Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: imap server and GSSAPI ?
Quoth Martin Schulz [EMAIL PROTECTED]: | I'am currently setting up an imap server. Basic mail delivery works, | but authentication still needs password passing (via ssl, but | nevertheless). But I definitely want to make use of the available Krb5 | TGT, to avoid that password passing; as I understood it, GSSAPI is the | way to go. | | | Are there any comprehensive descriptions about this setup? | | I found a brief description for cyrus-imapd, but I am using the UW imapd. Do you mean you want to know to implement GSSAPI-Kerberos5 authentication in your own IMAP client? I guess you could look at RFC 2060 (IMAP4rev1), AUTHENTICATE command, for starters. Use GSSAPI for mechanism name. You can also see one implementation in the imapd source, c-client/auth_gss.c. I might be able to provide another examples if you happen to be working in Python instead of C. On the other hand, if you want to use existing software, you might want to specify the platform. I know pine and recent Windows versions of Eudora will do that, undoubtedly a few others. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: default principal confusion
Quoth [EMAIL PROTECTED] (Ken Grady): |What is the correct way to do this? Or is it correct to allow both? | And should an option be added to SomeNewSSH to allow either | functionality (-k1 kerberos original -k2 extra principal...)? | Openssh-3.1p1 uses the default principal is the same as the client and | things seem to be compatable as far as using forwarded tickets are | concerned. Compatability between differing versions of ssh is | practically non-existant AFAICT. | | When I kinit I get klg @lanl.gov as the default principal. An od -c | of the cache shows that klg is also the client. When I use ssh.com's | ssh-3.1.0 and ssh -l acct machine.lanl.gov, I end up with a ticket for | default principal [EMAIL PROTECTED] and client [EMAIL PROTECTED] which isn't | necessarily bad, because I can use that ticket and ksu (ticket default | principal becomes [EMAIL PROTECTED]) and I become root (I'm in acct's and | roots's .k5login files). The logs on the KDC show that root was | authenticated as [EMAIL PROTECTED] for acct (see below). Where it gets | confusing is if I ssh -l root machine.lanl.gov my default principal is | [EMAIL PROTECTED] client [EMAIL PROTECTED], but [EMAIL PROTECTED] isn't a valid | kerberos principal. So should ssh-3.1.0 revert back to [EMAIL PROTECTED] or | should ksu change the principal to [EMAIL PROTECTED] and just leave the | client [EMAIL PROTECTED]? The ssh from ssh-3.1.0 doesn't seem to use the | client info from the ticket cache, so I am unable to ssh with a default | principal of [EMAIL PROTECTED] and client of [EMAIL PROTECTED] to another machine | (unless I ksu klg first. What if I don't have an account on the | machine?) nor am I able to ssh with a default principal of | [EMAIL PROTECTED] So the question is Which is correct?. I don't have much to do with these things, but since no one else's followup has appeared yet, here's my opinion. Where it gets confusing above shows why -l username should refer to a remote account and not a Kerberos principal. Authorization to that account can be based on whatever suits sshd. If Kerberos then the Kerberos principal should be determined according to general Kerberos rules, i.e., the default principal from the credentials. If that's inconvenient, the solution should apply to Kerberos applications in general, where I would imagine the use of more than one principal could be better supported. Whether ssh should forward credentials I don't know for sure, but since there isn't any real mapping between principal and account, only a set of loose conventions, I guess it should be as happy to forward to a .k5login-authorized account as to a name==name-authorized account. Donn Cave, [EMAIL PROTECTED] | The logs show: | Apr 10 08:11:00 kerb1 krb5kdc[715]: TGS_REQ 123.123.123.2(88): | ISSUE:authtime 1018447267, [EMAIL PROTECTED] for [EMAIL PROTECTED] | pr 10 08:11:48 kerb1 krb5kdc[715]: TGS_REQ 123.123.123.2(88): | ISSUE:authtime 1018447267, [EMAIL PROTECTED] for | [EMAIL PROTECTED] | Apr 10 08:11:48 kerb1 ksu[8599]: 'ksu root' authenticated [EMAIL PROTECTED] | for acct on /dev/pts/2 | Apr 10 08:11:48 kerb1 ksu[8599]: Account root: authorization for | [EMAIL PROTECTED] successful Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: Problems using Kerberos telnet
Quoth [EMAIL PROTECTED] (Wyllys Ingersoll): ... | This is the problem. Is the hostname you entered at the client prompt | the same as the name | of the server that is stored in the KDC? It may be a DNS issue, try | specifying the | fully-qualified hostname when you make your connection from the client. | | A look at the KDC logs might help clear this up. While we're on the subject, I find that the Heimdal telnet on my NetBSD 1.5.2 host fails to do a reverse lookup to determine the service host's canonical name. That's probably a bug. MIT clients do this more or less universally, in krb5_sname_to_principal(). This is probably not the problem our nameless correspondent Someone is having, but I believe he is using Heimdal too. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
RE: Tickets accepted upon login but still prompted for password
Quoth [EMAIL PROTECTED] (Rechenberg, Andrew): | [arechenberg@rh71test ~]$ telnet -a rh71test.shermfin.com | Trying 10.1.1.55... | Connected to rh71test.shermfin.com (10.1.1.55). | Escape character is '^]'. | [ Kerberos V5 accepts you as ``[EMAIL PROTECTED]'' ] | telnetd: Authorization failed. rm $HOME/.k5login Just a guess. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
RE: Tickets accepted upon login but still prompted for password
Quoth [EMAIL PROTECTED] (Rechenberg, Andrew): | Looking at the code, it looks like if I don't have a .k5login | I should be allowed access, but the authorization is failing. | Is this a correct assumption? Not completely correct, or you wouldn't have a problem, but yes, that's how it works for everyone else. There are basically two ways to decide authorization: 1. You don't have a .k5login. Rules are used to decide whether your prinicipal ought to be authorized for the present account. Those rules can be anything in theory, but in practice they're like [EMAIL PROTECTED] is authorized for account 'myname'. 2. You do have a .k5login - use it instead. That's why Mark Eichin speculated that your host doesn't know its local realm. Something's going wrong in (1), if you can make it work by using your own principal in (2). If I were in your shoes, I would get the source and build it, and find out what it's doing in lib/krb5/os/kuserok.c. (Or find out that the source you build works, where the stuff you're now using doesn't.) Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberized rsh/rlogin on FreeBSD and NetBSD?
Quoth Chris Schadl [EMAIL PROTECTED]: | Hi, | | When I try to rlogin or rsh to my NetBSD or FreeBSD machines with | kerberos support, I get the error Couldn't authenticate to server: Bad | sendauth version was sent. Looking in the syslogs of these hosts, I see | the following: | | Mar 6 22:12:07 ryoko rlogind[37294]: usage: rlogind [-Dalnx] | Mar 6 22:12:07 ryoko rlogind[37294]: usage: rlogind [-Dalnx] | Mar 6 22:12:07 ryoko rlogind[37294]: Connection from 192.168.0.2 on illegal port | | (that's on the FreeBSD host; I get something simmilar on the NetBSD | server) | | rlogind and rshd are set in inetd.conf to use the -k flag to enable | Kerberos authentication, however the errors in my syslog would seem to | indicate that the -k flag is not supported. Does anyone what I have to | do to get kerberos rsh/rlogin working on these platforms? On NetBSD 1.5, it doesn't look to me like /usr/libexec/rlogind supports Kerberos. Only /usr/libexec/telnetd. Same story in the clients - only telnet supports Kerberos. (Host/service principal lookup in this telnet has the same bug as in MIT's ftp, multiple lookups lose in a dynamic DNS environment.) Well, ssh looks like it might support Kerberos 4, but I wouldn't expect that to do you much good. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos Security Question
Quoth [EMAIL PROTECTED] (Tomas Maly): [... re credentials in /tmp ] | Any way, I was wondering if it was thought of how to | secure this hole. Would it be possible to make a | ticket cache file valid only for a particular process | group, perhaps? Is there any current ways to tighten | security? I would like to not force removing root | access from these untrusted users (such as for their | Linux PCs). If you're giving root access to someone, they're trusted! I guess you mean that they're not worthy of the trust you place in them? Something's unclear here. Here are a couple more questions for you: - Do these credentials have any value at all? I mean, do you use them, does anyone use them? It sounds like they're the by-product of password validation. It might take some work in login.krb5, but in theory those credentials are optional. - Following the password validation assumption, are those passwords in the clear on the network? - Can your users actually use Kerberos? Can they have Kerberos telnet or ssh on their desktop? If you do the Kerberos single login thing, and then use your credentials to log in to a remote host, you don't go through that password validation step and wouldn't have credentials there (unless you deliberately forward them.) This is really a _more_ secure way to deal with trust issues - compared to say ssh or SSL with passwords, where you expose your password to the remote host. | Also, I've noticed that the login.krb5 program creates | a pseudo-random filename for the cache (such as | /tmp/krb5cc_XYZPDQ). Why is this? You could have several sessions concurrently on the same host. This way you don't lose your credentials from one session when another one starts or exits (they're deleted on exit.) Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: kerberos 1.2.3 compile problems on aix 4.3.3
Quoth [EMAIL PROTECTED] (jesse raynor): | I had trouble compiling kerberos 1.2.3 on AIX 4.3.3. I got it to build with | cc, which doesn't define __STDC__, but not with xlc, which does. I am using | version 5 of the AIX C compiler. | | To build with cc, I cd'ed to the src directory and did: | | ./configure --prefix=/opt/kerberos --without-krb4 | make | | By default, cc gets picked as the compiler to use. Eventually the build | dies | under the telnet directory. Here's the last command make tried: ... | To make the prototypes match, I changed lines 192-194 of ext.h from | | extern void netprintf P((const char *, ...)); | extern void netprintf_urg P((const char *fmt, ...)); | extern void netprintf_noflush P((const char *fmt, ...)); | | to | | extern void netprintf (const char *, ...); | extern void netprintf_urg (const char *fmt, ...); | extern void netprintf_noflush (const char *fmt, ...); | | and then reran make. It finished compiling. That's the right fix. Unless you want to add varargs support, you're already limited to compilers that support stdarg. They will all support function prototypes, so __STDC__ as a test for function prototype support is useless (as well as wrong.) Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
Re: host and services principals/tickets
Quoth [EMAIL PROTECTED] (Andreas Hasenack): | LDAP | services aren't really a distinct category. You might run | several LDAP services on the same host whose data and access | controls are completely different, and that's what you would | | I though ACLs were not kerberos' concern. Kerberos only says | that you are you, right? What you can or cannot do outside of | kerberos is not its business, right? Right. I really am talking about the identity of the service, the point is that an LDAP service's useful concept of identity is not about being the LDAP service on host x.y.z. Neither the host nor the use of LDAP protocol are particularly interesting to me, it's the data. And I suppose that's how telnet, rsh and ssh all came to use the same host principal - your connection's network protocol may be telnet or ssh, but what matters is that you have a shell prompt. Access controls are just an example of the possible differences, and they're interesting because they hint at potentially different security considerations that might lead back to Kerberos when we consider for example which keytab to store the keys in, privileges to access the keytab vs. what privileges the server runs with. Donn Cave, [EMAIL PROTECTED]
Re: host and services principals/tickets
Quoth [EMAIL PROTECTED] (Booker C. Bense): ... | - There's nothing stopping these various ldap servers from | sharing the same keytab. I can see some reasons for not wanting | to do that, but the only compelling one to me is that if | you don't trust the security of one of the servers. | Other than that I can't see any real reason why the keytab | can be shared. Anything else hints of using the naming | of kerberos principals for authorization, and we all know | how evil that is. I seem to be too dense this morning to see how service principal names could be authorization. I mean, with client principals it's obvious enough, but I reckon that the service would be the one who grants authorization, not the one who receives it, in at least the typical use of service principals. By extension, do you see any reason why all services should not just use the host principal? That's not a sarcastic question - I think the point could be argued, at least for services that all run as root or have enough common privilege. Donn Cave, [EMAIL PROTECTED]
Re: host and services principals/tickets
Quoth [EMAIL PROTECTED] (Sam Hartman): | Donn == Donn Cave [EMAIL PROTECTED] writes: | |Donn An LDAP service certainly should have its own key, but in my |Donn opinion this should actually be a run time option. LDAP |Donn services aren't really a distinct category. You might run |Donn several LDAP services on the same host whose data and access |Donn controls are completely different, and that's what you would |Donn like to base the service principals on, not the technicality |Donn of the protocol. But you might also run two that are |Donn essentially identical, but on separate service ports for |Donn testing, so it isn't ideal to just incorporate the service |Donn port in the service principal to accomplish this (don't |Donn laugh! I believe there are implementations that do exactly |Donn that.) | | The problem is that you need a secure mechanism to tell the client | what principal to authenticate against. Specifying that in the | protocol document is a great way to make sure it is securely known. If I run separate LDAP services with separate principals like ldapwhitepages/x.y.edu and ldapaccounts/x.y.edu, the clients (and the servers) would presumably get that information from configuration files, just as they currently need to know what host and service port to connect to. Could you elaborate on the problem with this as a secure mechanism? Given that host and port are going to be determined this way. Donn Cave, [EMAIL PROTECTED]
Re: host and services principals/tickets
Quoth [EMAIL PROTECTED] (Andreas Hasenack): | I'm suddenly a little bit confused about host and services | principals. | | For example, for OpenLDAP I have a principal called | [EMAIL PROTECTED] But, for openssh, I found out | that I had to have a [EMAIL PROTECTED] principal | instead of something like [EMAIL PROTECTED] | | This is defined by the service/application, right? Yes, the application decides. Some are even ambivalent, like ftp which can be either ftp or host. Telnet uses host, and it seems to have made sense to everyone that the same key would serve for sshd. An LDAP service certainly should have its own key, but in my opinion this should actually be a run time option. LDAP services aren't really a distinct category. You might run several LDAP services on the same host whose data and access controls are completely different, and that's what you would like to base the service principals on, not the technicality of the protocol. But you might also run two that are essentially identical, but on separate service ports for testing, so it isn't ideal to just incorporate the service port in the service principal to accomplish this (don't laugh! I believe there are implementations that do exactly that.) Donn Cave, [EMAIL PROTECTED]
Re: Unresolved symbol _et_list for OSF4.0f (dynamic lib)
Quoth [EMAIL PROTECTED] (Jonathan Wackley): | Configured and built MIT Kerberos V5 release 1.2.2 distribution with no | obvious issues. Execute code to perform dlopen of libkrb5.so and the | following error message (from my program) is shown at exit: | | /sbin/loader: Error: Unresolved symbol in | /kerberos/tru64_new/lib/libkrb5.so.3: _et_list | /sbin/loader: Warning: update_reference_counts: negative reference_count for | libkrb5.so.3 | | Verified that LD_LIBRARY_PATH is set properly. Assuming that it was a | problem with my actions I downloaded the binary version of release 1.2.3 and | the exact same error occurs. Verified that the symbol is resolved in | libcom_err.so. Does anyone have any suggestions why this error occurs? Not really, but you might try linking the application - the one that calls dlopen() - with -rpath /kerberos/tru64_new/lib. I've done that on Digital UNIX 4.0 to solve a run time loading problem with Kerberos libraries in a non-standard directory. I don't recall the error. My problem was that the dlopen() was called from another shared library (a Python module), and the normal library load path rules didn't work by extension in this case, perhaps for security reasons. (Since then I have seen the light, Kerberos libraries are static.) Donn Cave, [EMAIL PROTECTED]
Re: telnet - encryption
Quoth Tns Bker [EMAIL PROTECTED]: | as I read from the Kerberos documentation the kerberized version of telnet can | use an encrypted mode. | | Does that mean, that all the traffic, that travels over that connection is | encypted? Or does it mean, that only passwords are encrypted? | | Is such a telnet connection as 'secure' as an ssh or ssl encrypted connection? More secure. Kerberos telnet doesn't send any password at all, encrypted or not. SSL can encrypt your password across the network, but at the other end you just have to trust the remote host. | Is there a list of applications, which can be kerberized and then use | encryption in the same manner as it can be done with telnet? Would it be | possible for openafs, as well? I would think so, but not necessarily with the current version of Kerberos, Kerberos 5. Haven't tried it myself. Donn Cave, [EMAIL PROTECTED]
Re: Kerberos single sign on
Quoth David Stern [EMAIL PROTECTED]: | We have a DCE/DFS environment with kerberos 5.1.2. The kerberos | source builds with ftp ea daemons. I'm interested in setting up | single signon st once users logon and are authenticated, they can | ssh, ftp or whatever to any machine without being prompted for a | password. Does anyone have any pointers to How-To docs on this? Have you tried it? As you know, your login procedure is a key part of it. Telnet, is it? Do you already have MIT's telnetd and login.krb5 in place? At many academic sites, the means by which people log in are as varied as could be. Some of them are by nature not going to result in remote credentials, like rlogin or ssh with RSA keys. Others can make credentials, like ssh with password. And then some are configurable, Kerberos5 ssh or telnet can forward credentials. If all that is going on, remote credentials could be kind of a headache to document for typical users. What you describe is kind of a perversion of single signon. The real thing happens on the local computer, not some remote computer. If you can get Kerberos 5 telnet ssh working, on both the hosts and for some significant fraction of users, then ticket forwarding will give you that extended single signon as an extra benefit for those users. Donn Cave, [EMAIL PROTECTED]
Re: Kerberos single sign on
Quoth [EMAIL PROTECTED] (Sam Hartman): | Donn == Donn Cave [EMAIL PROTECTED] writes: | | Donn What you describe is kind of a perversion of single signon. | Donn The real thing happens on the local computer, not some | Donn remote computer. | | UH, no, this is single signon. Single signon means that I get all the | credentials to access services at the site from one signon. This | includes things like getting to IMAP mail, filesystems and local | applications. It also includes getting to services like shells | exported by some machines. IT happens that these shell services | often need proxy authentication to be useful. I might have misunderstood him. What I was getting was, you log in to a remote host, and acquire a TGT in the process that gives you access to remote services from there. For example, connect via ssh, sshd takes your password and acquires an initial ticket granting ticket while validating it against the KDC, and then it and any subsequent service tickets are available to that session. The way I count it, that would be single login only if all day long, that one ssh session accounted for everything you did at the site. If you ssh to another host in another window, you're going to have to do another login, because your own computer has no credentials. Donn Cave, [EMAIL PROTECTED]
