new error message/return code for kdb5_util unsupported commands

[greg@enjellic.com]

On May 31, 12:07pm, Sam Hartman wrote:
} Subject: Re: new error message/return code for kdb5_util unsupported comma

> >>>>> "greg" == greg  <greg at enjellic.com> writes:
> 
>     greg> On May 24, 8:39pm, Will Fiveash wrote: } Subject: new error
>     greg> message/return code for kdb5_util unsupported commands
> 
>     greg> Good morning, hope everyone's day is starting well.
>     greg> I understand the motivations in sacrificing 15+ years of
>     greg> well documented security practices at the altar of
>     greg> manageability.  I don't agree with them but do understand
>     greg> them.  Watching 4 months of dialogue on this issue causes me
>     greg> to believe the horse is being approached from the wrong end,
>     greg> which tends to result in getting kicked in the privates.
> 
>     greg> LDAP is a protocol not a database.  Has anyone considered
>     greg> bolting an LDAP interface onto the KDC?

> Yes.  For many years, this was the approach I favored.  I'd still like
> to do that.  However it doesn't actually meet everyone's needs.
> 
> People want to use LDAP implementations because of their ability to
> handle replication and because they want the data to live in one place
> for backups.
> 
> That requires having an LDAP backend to the databse.

Its strange we don't simply stuff everything into an Oracle database.

Then we could have transaction coherency too.

.. :-)

> You might want an LDAP admin protocol for managability.  What we
> provide does not actually give you that (although people will
> doubtless hurt themselves assuming they have it).  As an example,
> the way keys are stored in this protocol is not what you would want
> for an admin protocol although it is reasonably OK for our
> implementation's KDC.

Interesting.

I'm assuming from your comments that the design is to abstract KDB
transactions into object read/update/modification requests which are
propagated into a backing directory.  If that is a correct assumption
a kadmind implementation still needs to be run to implement management
of the authentication identities.

All this seems to have interesting implications with respect to
directory ACL management and monitoring.

> I do still believe an admin schema is needed and I do hope that we
> do that work.  I also hope that we have frontends that speak that
> admin schema.  However no one seems interested in writing that code.

Fascinating that a standardized management interface isn't a priority.
I must have an aberrant world view of issues.

It will be interesting to see how much code actually needs to get
written at the lake this summer.

> --Sam

Thanks for the comments.

Have a good day.

Greg

}-- End of excerpt from Sam Hartman

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
------------------------------------------------------------------------------
"MS can classify NT however they like.  Calling a pig a bird still
doesn't get you flying ham, however."
                                -- Steven N. Hirsch