Authenitcating Windows users with MIT Kerberos

[Jason T Hardy]

On Wed, 2004-03-24 at 15:31, Walt Howard wrote:
> In article <1080158210.5579.34.camel at dionysus.uta.edu> 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/