[1117] in Kerberos_V5_Development
Re: OV admin system integration plan
daemon@ATHENA.MIT.EDU (Richard Basch)
Mon May 6 11:42:28 1996
Date: Mon, 6 May 1996 11:38:13 -0400
To: Marc Horowitz <marc@MIT.EDU>
Cc: "Richard Basch" <basch@lehman.com>, "Barry Jaspan" <bjaspan@MIT.EDU>,
krbdev@MIT.EDU
In-Reply-To: <9605052247.AA04271@bart-savagewood.MIT.EDU>
From: "Richard Basch" <basch@lehman.com>
On Sun, 5-May-1996, "Marc Horowitz" wrote to "Richard Basch, Barry Jaspan, krbdev@MIT.EDU" saying:
> In message <199605052153.RAA01965@badger.lehman.com>, "Richard Basch" <basch@lehman.com> writes:
>
> >> A few reasons why I am using v4kadmind:
> >> 1. We still have a large V4 install base.
> >> 3. The V5 admin server/protocol is changing soon and I don't want
> >> to build up an install base that I will have to convert. When
> >> the final V5 admin protocol is done, I will consider deploying it.
>
> Except for changing passwords, how much of your installed base uses
> admin clients of any version? I'm trying to gauge the usefulness of
> extending ov's v4 protocl password changing server.
Our main use of the v4 protocol is password changing... ksrvutil & kpasswd.
> >> > "The kdb library currently uses the ndbm api. The OV admin system
> >> > code uses the berkeley db api for its own databases, and the kdb
> >> > library to access the KDC database." The rest of the paragraph
> >> > follows more clearly from this.
> >>
> >> Why doesn't the admin server use the kdb layer, instead of direct db/dbm
> >> access? This would reduce the number of places that need to be changed
> >> if a new db is chosen.
>
> It does use the kdb layer, when it can. This layer provides
> functionality for dealing with principals, and none for dealing with
> policies. So it uses db for dealing with policies.
>
> The entire kdb abstraction is a mess; gutting it and using a more
> reasonable abstraction for the underlying database would be admirable,
> but it's what we've got now.
Ok, so the policies are in another database, if I understand you correctly...
As long as that is the case, and the kdb routines are being used for all
principal changes, it sounds like it will suffice.
> >> The part that actually needs work under the kadmin tree is ktutil.
> >> There is no equivalent to the V4 ksrvutil (add/delete/change). However,
> >> I must say that it provides a useful V4-V5 conversion feature.
>
> The OV stuff provides such a program, so you'll have it when the OV
> integration is done.
Great!
--
Richard Basch
Sr. Developer/Analyst URL: http://web.mit.edu/basch/www/home.html
Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu
101 Hudson St., 33rd Floor Fax: +1-201-524-5828
Jersey City, NJ 07302-3988 Voice: +1-201-524-5049
