Douglas E. Engert wrote: > Not sure what you mean here as you have responded to Ken that its > not the KDC access to its data stored in LDAP that you are interested in.
I think maybe some wires have been crossed, and I have not described what the issues are as well as I may have liked. We do want to use the KDC, but for it to access our pre-existing data in LDAP, but not write anything there. Currently our route for authenticating users for various things (online mostly) is to authenticate against LDAP. Our user data is actually in Novell eDirectory, but the LDAP interface is the preferred method for access. However we have a long term plan of rolling out an SSO service, and thought Kerberos would be best suited as there seems to be many Kerberos aware systems, and we may in the long term be moving to Active Directory (and ADFS) which I believe is (sort of) Kerberos which would give us an even greater scope of using Kerberos including for system logins. So what we would have liked is for a web-based user to go to one of our web applications that requires authentication and for them to authenticate in a way that ends up with them having a valid Kerberos ticket somehow for other Kerberos aware applications, so they don't get asked for user/pass again in a session. And we had hoped this could be achieved without having to create a duplication of all our user data into a Kerberos specific database, or for Kerberos to require to add any data to our LDAP server since it's basically read-only as it's populated from elsewhere. >From what I read of the Kerberos LDAP backend plugin, is that it can't just be configured to look at our existing LDAP server and it's associated structure when a user tries to login to something via Kerberos, and use its own non-LDAP database for tickets and whatever other information is needed. -- John Gilbertson The University of Liverpool ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
