Re: KDC Configuration Questions
Ken Raeburn wrote: > On Feb 6, 2009, at 11:31, Anh Nguyen wrote: >> Hi, >> Sorry for the following newbies questions, but thanks in advance for >> your comments and suggestions: >> 1. Could we set up multiple KDC per single realm? > > Absolutely; at most sites I think it's the normal way of doing > things. You just set up additional DNS SRV records for the realm, or > (in the MIT client implementation) multiple "kdc = " lines in > the config file. I think MIT's administration manual (or possibly > installation manual, I haven't checked in a while) should describe both. > > With multiple SRV records, unless you set different priorities, the > clients should try the KDCs in random order, thus spreading the load. > With config file entries, for historical reasons, the client will try > them in order, so the second only gets tried if a response doesn't > come back from the first quickly enough, etc. > >> 2. Is it possible to set up multiple independent sets of KDC/realm's >> working against a single database managed by directory server? > > If you use the LDAP database back end, yes, just point all the KDCs in > a realm to the same LDAP server(s) and data. I'm pretty sure you > could also do multiple realms in one LDAP directory, but I don't know > what subtle issues might lie there; I'm more familiar with our more > traditional Berkeley DB back end. > > Technically, with the Berkeley DB back end, you could probably set up > multiple KDCs too, but all KDCs need access to the same DB files, and > for security reasons they probably shouldn't be exported over the net, > so you'd be talking about running multiple KDCs on one machine, which > is not as useful if you're looking to improve availability in cases of > machine failure. > >> 3. Is there a plan to multi-thread KDC? > > Well, that's an interesting question It's been discussed, since > waiting for LDAP query results could make your KDC slow down. We've > even had some code donated, but changing a sensitive security service > like the KDC in such a drastic way makes a lot of people nervous for > good reasons (ignoring the actual code we got -- going from a big > single-threaded program with a bunch of global storage to a > multi-threaded program with work queues between different parts is a > significant restructuring and likely to have subtle problems), so > we've held off on it for now, until we can take a better look at the > issue and possible approaches. > > In the meantime, actually, that might be a good use case for running > multiple KDC processes on one host. You could spread out the load > somewhat, among, say, three processes on host A on different port > numbers, and three processes on host B on different port numbers. > You'd be relying on this load-sharing to reduce the problems from LDAP > latency, so you'd really want to go with the SRV records rather than > config file entries. > > I've got a couple other ideas about less drastic code changes we might > be able to make to allow for some parallel processing, by forking the > KDC process, but there are some interactions with the way we're > handling network interfaces that need a little thought. If you're > interested in working on some code, let me know. :-) > > Ken Hi Ken, I'd like to apologize for this very late reply. Your mail was mistakenly filtered to a folder, which I just coincidently checked. Thank you very much for your explanation of the potentials. Regarding the last one for improving concurrency I will certainly relay the message to other teams, and will keep you posted. Thanks again. Anh- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Long-running jobs with renewal of krb5 tickets and AFS tokens
On Mon, Mar 02, 2009 at 09:02:59PM -0500, Jason Edgecombe wrote: > Nicolas Williams wrote: > >I have seen sites use on the order of months for the renewable ticket > >lifetime, but still hours for normal ticket lifetime. If you already > >use seven days for renew life you might as well double it -- whatever > >your threat model is, if you can accept seven days then chances are you > >can accept fourteen. > > > Doubling it wouldn't really help. It would probably need to be on the > order of a month. If I were to change the renewable lifetime, I need to > change all principals, the client krb5.conf and the server kdc.conf. Is > that correct? Hmmm, not sure. The client ought to ask for infinity, but I don't think that's the default, sadly. The kdc.conf parameters in question are best not used -- you can use kadmin policies instead. Also, IIRC the TGS principal's renew life puts a bound on all, IIRC, so generally you might want to set principals' renewable ticket life to be very long, and use the TGS principal as a big hammer. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Long-running jobs with renewal of krb5 tickets and AFS tokens
Nicolas Williams wrote: > On Sat, Feb 28, 2009 at 11:40:26PM -0500, Jason Edgecombe wrote: > >> I guess setting things for renewable tickets longer than 7 days or >> running the jobs in local disk will be easiest. >> >> We have a 7 day normal/renewable lifetime. What length do other sites have? >> > > I have seen sites use on the order of months for the renewable ticket > lifetime, but still hours for normal ticket lifetime. If you already > use seven days for renew life you might as well double it -- whatever > your threat model is, if you can accept seven days then chances are you > can accept fourteen. > Doubling it wouldn't really help. It would probably need to be on the order of a month. If I were to change the renewable lifetime, I need to change all principals, the client krb5.conf and the server kdc.conf. Is that correct? Thanks, Jason Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Long-running jobs with renewal of krb5 tickets and AFS tokens
On Sat, Feb 28, 2009 at 11:40:26PM -0500, Jason Edgecombe wrote: > I guess setting things for renewable tickets longer than 7 days or > running the jobs in local disk will be easiest. > > We have a 7 day normal/renewable lifetime. What length do other sites have? I have seen sites use on the order of months for the renewable ticket lifetime, but still hours for normal ticket lifetime. If you already use seven days for renew life you might as well double it -- whatever your threat model is, if you can accept seven days then chances are you can accept fourteen. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Long-running jobs with renewal of krb5 tickets and AFS tokens
Jason Edgecombe wrote: > We have users who need to run long-running jobs and store their files in > AFS during the run. > > I've read the k5start and k5renew man pages, but I don't see how I can > have users type in their password when they start a job and have the > tickets and tokens keep being renewed. > > Hi John, I'm forcing an 'at' job in the .cshrc script to 'k5renew' and 'afs5log' every 8 hours or so for the max lifetime of a week. This works only for interactively started jobs of course; jobs running through a scheduler such as pbs or condor need some other tricks... Hugo Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
