Root Authentication

[James Walthall]

How does root authentication work with kerberos?

To my understanding, it appears as if the root user can authenticate both 
locally and on the kerberos KDC.

I have successfully been able to login onto a kerberized redhat linux 8 
machine using both the root password
established locally as well as the kerberos principle password without 
making any configuration changes between
logins.

I assume this is working as designed. Any idea how to disable the local 
logon for root while still allowing the
kerberized logon (or is this just a bad idea altogether?)

Thanks in advance!

---------------
James Walthall Jr
IBM Host Integration Server Test / HATS
Outside: (919) 254-8869
Tieline: 444-8869
Research Triangle Park
Raleigh, North CarolinaaFrom news at ra.nrl.navy.mil Thu Mar  4 20:56:18 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id i251uIqb029890
	for <kerberos at PCH.mit.edu>; Thu, 4 Mar 2004 20:56:18 -0500 (EST)
Received: from ra.nrl.navy.mil (ra.nrl.navy.mil [132.250.1.121])
	i251uGta000295
	for <kerberos at MIT.EDU>; Thu, 4 Mar 2004 20:56:16 -0500 (EST)
Received: (from news at localhost)
	by ra.nrl.navy.mil (8.11.7p1+Sun/8.11.7) id i251o5L05148
	for kerberos at MIT.EDU; Thu, 4 Mar 2004 20:50:05 -0500 (EST)
From: Russ Allbery <rra at stanford.edu>
X-Newsgroups: comp.protocols.kerberos
Date: Thu, 04 Mar 2004 17:43:08 -0800
Organization: The Eyrie
Message-ID: <87brnc9ihf.fsf at windlord.stanford.edu>
References: <3f5ba094.0403041516.1915ec69 at posting.google.com>
To: kerberos at MIT.EDU
Subject: Re: WebISO: the killer kerberos app?
X-BeenThere: kerberos at mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: The Kerberos Authentication System Mailing List <kerberos.mit.edu>
List-Help: <mailto:kerberos-request at mit.edu?subject=help>
List-Post: <mailto:kerberos at mit.edu>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
	<mailto:kerberos-request at mit.edu?subject=subscribe>
List-Archive: <http://mailman.mit.edu/pipermail/kerberos>
List-Unsubscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
	<mailto:kerberos-request at mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 05 Mar 2004 01:56:18 -0000

Christopher Kranz <clk at princeton.edu> writes:

> I've been looking into a number of WebISO solutions over the last
> several months.  The one thing that struck me is how Kerberos like a
> number of the solutions appear to be.  That is, they use a trusted 3rd
> party with a shared secret and then have a persistent token that allows
> logins without having to re-authenticate for some amount of time.

> It occurred to me that if you think of the web client as the credentials
> cache Kerberos could easily be used as a WebISO solution.  The web
> client connects to the web app.  If you don't already have a service
> ticket you get redirected to a login server that will prompt you for
> your Kerberos password and get a TGT for you if you do not already have
> one.  So in a sense the web client plus the login server combined looks
> like the traditional Kerberos client.  The login server contacts the KDC
> and gets a TGT and creates a service ticket for the web app.  It ships
> these back to the web client as cookies.  The web client now has
> credentials to give to the web app.  If the client connects to another
> Kerberized web app it is again redirected to the login server but this
> time it can use the stored TGT to obtain a service ticket for the new
> web application.

This is exactly the design of Stanford's WebAuth v3.  :)  See:

    <http://webauthv3.stanford.edu/>

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>