Kerberos Backend for LDAP

[Matthew Smith]

Thank you for the reply! Luke has indeed responded to me as well, but I 
think I may have communicated the wrong idea.  I am looking to keep all 
the info stored in a KDC, but provide a bare LDAP interface to the 
"non-credential" data.  I would like the following:

LDAP-Client <--->  LDAP Interface  <--->  KDC

Where the LDAP client can now retrieve information of the form (for 
example):
dn: krbprinc=myprinc, ou=REALM, dc=my2LD, dc=myTLD
PrincExpiration:200407090000
KrbLastModifyTime:200304150830
LastLogin:200304150800
...etc...

even though ALL this data remains stored in the KDC.

Any thoughts on this type of architecure?  It seems to me that storing 
the credential information in LDAP (which was not built to be an 
authenticator, but rather a single-purpose DB) is a bad idea, so I would 
rather keep the credential store in Kerberos (built from ground up to be 
an authenticator), and simply provide a restricted LDAP "interface" to 
the informational fields in the KDC Database.

Thank you,
-Matt
Dr. Greg Wettstein wrote:
> On Apr 15,  8:50am, Matthew Smith wrote:
> } Subject: Kerberos Backend for LDAP
> 
> Hi Matt, hope that your day is going well.
> 
> 
>>Does anyone know of a Kerberos backend for LDAP (preferably 
>>SunOne/iPlanet or OpenLDAP)?  I AM NOT talking about authenication (I 
>>know about GSSAPI/SASL, and {KRB}:Princ), but rather, I would like to 
>>see princ information via an ldap interface.  I would like to open up my 
>>LDAP utility, bind to this LDAP interface, and see information such as 
>>enc-types, modified time, expiration time, etc (obviously, a schema 
>>definition would be necessary).
>>In the end, I would like to combine this interface with my "Enterprise 
>>Information" LDAP server, behind some sort of LDAP proxy, to provide a 
>>single cohesive LDAP view of all my "Identity" information.
>>
>>Any direction is greatly appreciated!  Thanks,
> 
> 
> I believe that such a facility has been implemented for Heimdal
> Kerberos.  I don't have a URL at hand but you may want to take a look
> at their WEB site or Google for a combination of Heimdal and LDAP.  I
> suspect that Luke from PADL may chime in, I believe that they have
> implemented something like this as well.
> 
> That being said, as a systems architect, I would not go the route of
> putting authentication credential information into a directory
> server.  Losing the directory server to either an internal or external
> security intrusion means that you have lost all authentication
> integrity for your organization.
> 
> Like most other issues in IT this is probably ultimately a religious
> debate.  Without speaking for the MIT guys I think that they strongly
> disfavor the notion of putting this information in directory servers
> as well.
> 
> My prediction for the future is that the next major wave of security
> issues are going to focus on directory services.  I'm pretty confident
> that this issue is flying under people's radar screens right now.
> The increasing use of directory enabled computing architectures will
> make the directory servers a high yield target for both internal and
> external based security penetration attempts.  This is especially
> problematic if the directory serves as the repository for both
> authentication and authorization information.
> 
> Its still vaporware until I get the GPL issues resolved with the
> source code but concern over the integrity of the directory server
> drove much of the architecture in the Hurderos system.  Specifically
> we were looking at how to provide an authorization system which was
> robust in the face of directory compromise.
> 
> Once again its personal prejudice but I'm not a big believer in having
> the directory itself be the total repository of all identity
> information.  The approach that we took in Hurderos was to use a
> strategy akin to a meta-directory system to manage identity
> information.  In this model the directory servers became the 'visible'
> repository for identity information.  From a practical perspective,
> representational or characterizing information about an identity takes
> many forms, some of which make sense to be exported while other
> information simply isn't relevant.
> 
> 
>>-Matt
> 
> 
> Best of luck with your work.
> 
> }-- End of excerpt from Matthew Smith
> 
> 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-4950            WWW: http://www.enjellic.com
> FAX: 701-281-3949           EMAIL: greg at enjellic.com
> ------------------------------------------------------------------------------
> "My spin on the meeting?  I lie somewhere between the individual who feels
> that we are all going to join hands and march forward carrying the organization
> into the information age and Dr. Wettstein.  Who feels that they are holding
> secret meetings at 6 o'clock in the morning plotting strategy on how to
> replace our system."
>                                 -- Paul S. Etzell, M.D.
>                                    Medical Director, Roger Maris Cancer Center
> 
>