new error message/return code for kdb5_util unsupported commands

[greg@enjellic.com]

On May 26,  2:46pm, Ken Raeburn wrote:
} Subject: Re: new error message/return code for kdb5_util unsupported comma

Hi Ken, thanks for the note.

> On May 26, 2006, at 10:24, greg at enjellic.com wrote:
> > I understand the motivations in sacrificing 15+ years of well
> > documented security practices at the altar of manageability.

> The assumption seems to be that the LDAP back end data (and service
> implementation) is going to be as well protected as your KDC because
> that's where you store all your account data etc; or, conversely,
> authentication data is not seen as any more important than the rest.
> Not true in some environments, but it probably is in others.

Any systems jockey in their right mind would/should cringe at
re-keying an organization.

Recovering from a corruption or compromise of account/authorization
information involves a database reload.  Recovering from a compromise
of authentication secrets requires participation by every individual
in the organization.  The first you can cover up the second you
can't.... :-)

I actually just gone done writing the section for my Ann Arbor talk on
these issues.

> I haven't experimented with LDAP tools much, but purely for
> administration of a Kerberos database, the protocol is probably no
> worse than the special-purpose admin protocol MIT has (or the
> different one Heimdal has).  There's probably a lot there that a
> kadmin type program doesn't need, but then again, the code probably
> gets exercised more to get bugs shaken out.

The primary advantage is a common interface.  SUN and MIT are on the
same page because they try to be.  Heimdal is doing something
different, so is Apache.  With an LDAP interface everyone is on the
same page by default.

Using LDAP as the management protocol means people just need to agree
on a schema definition.  I'm assuming this agreement is already a
given considering the work with DAL.

> > LDAP is a protocol not a database.  Has anyone considered bolting an
> > LDAP interface onto the KDC?
> 
> The idea has crossed my mind, but that's about as far as I've gone. :-)

> > OpenLDAP already has a collection of back-ends.  I've considered
> > engineering an MIT/KDC implementation to add to the list.  If someone
> > can explain why this is wrong-headed I won't add it to my personal
> > amusement list for the summer.

> No reasons come to my mind.  But like I said, I haven't worked with  
> LDAP much, and 95% of it's been with this new kdb back end...

I think I'll take a run at building something after I get Ann Arbor
behind me and the summer settles down.  I'll keep anyone who is
interested up to date.

> Ken

Thanks again for the comments.

Have a good week.

}-- End of excerpt from Ken Raeburn

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg at enjellic.com
------------------------------------------------------------------------------
"The real question is not whether machines think but whether men do."
                                -- B. F. Skinner
                                   _Contingencies of Reinforcement_