On Wed, 2004-03-24 at 15:31, Walt Howard wrote: > In article <[EMAIL PROTECTED]> you write: > >We've been testing MIT Kerberos as a centralized authentication > >mechanism for Linux/UNIX and Windows boxes for the past several months. > >My test setup consists of one master and two slave (read only) KDC's > >runing RHEL AS 3.0 and a myriad of clients. So far, all is well on the > >Linux/UNIX client side, but I keep running into a problem with the > >Windows client setup, ksetup on WinXP specifically. > > > >The ksetup utility doesn't allow me to specify an admin server separate > >from my KDCs. I would like all of the "normal" ticket requests to go to > >the slave KDCs and the "admin" traffic to go to the admin server. > > On WindowsServer2003 (all I have to play with), ksetup can take either > a /AddKDC or a /AddKpasswd option. I told it about all the MIT KDCs > with /AddKDC and only the admin server with /AddKpasswd. Seems to work. >
Thanks, I must have missed that option! <Insert Foot In Mouth> > >As it stands, I cannot change passwords on the Windows box unless I've > >only specified the admin server. Not only is this a drain on my admin > >server's resources, it's a single point of failure for my Windows > >clients. > > > >I can see a few solutions, but haven't found anyone that's put together > >a good tutorial for doing this yet: > > > >(1) Allow for multi-master admin servers -- Microsoft seems to have this > >in AD, but from my research, the master KDC is a single point of failure > >in the MIT implementation. If this worked, delta-level replication would > >happen from KDC to KDC (no more master -> slave propagation). > > Doing multi-master anything is a lot more difficult than it looks, and > MSAD can be fooled with relative ease because they underestimated the > problem and did not really solve it. > > The MIT master is not really a single point of failure, since all the > slaves have a copy of the data and kprop can be manually run in reverse > to reload a failed-and-replaced master. You just can't make any changes > to the underlying DB while the master is down. I know, that's a big > nuisance, but it doesn't really qualify as a failure. > > One of the options you have for KDC master failures is to use DNS TXT > and SRV records to distribute the information about which server does > what, to clients. Then, in event of a master failure, you can promote > a slave to master (start up the kadmind) and tweak the DNS records to > tell all the clients. > I agree with all of your points, but from my point of view it was a single point of failure for the Windows clients if I couldn't specify the slave KDCs. I'll try your suggestion for /addkpasswd and see how well it works. > >(2) Alter the Kerberos setup under Windows to specify separate admin and > >KDC servers. This would solve my immediate problem, but it still appears > >to me that a single admin server is a single point of failure for > >password changes. > > Failure of authentication service for more than about a minute for an > organization your size is a major problem. Failure of the password- > changing service more likely can be tolerated for half-a-day or so, > so the cost of the single-point-of-failure is acceptable. Or you could > get a Tandem Nonstop for your admin server :-) We're looking at using > OpenBSD with CARP and a shared disk to construct servers that don't > ever go offline. > We're there an unlimited budget we could solve all of the worlds problems. :) > >(3) Redirect admin server requests at the slave KDCs. I'm not even sure > >if this would work, but if I were to set up a NAT tunnel from the > >kpasswd service on my slave KDC to my admin server (and back again), the > >client would think that the slave is handling the password change > >request. > > That doesn't fix the single-point-of-failure problem. I understand that it doesn't fix the SPOF, but it would have allowed me to avoid only specifying the kadmin server in my Windows client configs. Thanks for your suggestions! Jason -- Jason T Hardy Unix Systems Administrator Office of Information Technology University of Texas at Arlington http://www.uta.edu/linux/ ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
