Sorry to barge in straight away with a question like this, but my time is running out and I have not been able to get a straight answer out of google.
I'm going through the hypotheticals for using ldap as the backend for kerberos, and I've hit a chicken and egg problem with SASL- can someone untangle my mind?
IF kerberos is using ldap as a backend store for keys, users, etc, and one can set the rootdn and leave the rootpw for later entry in the database itself, and the password can use SASL auth- what happens if you use kerberos as the auth mechanism?
According to the book, slapd needs to set up the access to the key from startup, and kerberos in this scenario will need ldap up to provide the key. Is ldap up enough that kerberos can provide this? Or does ldap retry or something so that this problem is overcome?
Thoughts?
Cheers
Da Rock wrote:
Sorry to barge in straight away with a question like this, but my time is running out and I have not been able to get a straight answer out of google.
I'm going through the hypotheticals for using ldap as the backend for kerberos, and I've hit a chicken and egg problem with SASL- can someone untangle my mind?
IF kerberos is using ldap as a backend store for keys, users, etc, and one can set the rootdn and leave the rootpw for later entry in the database itself, and the password can use SASL auth- what happens if you use kerberos as the auth mechanism?
According to the book, slapd needs to set up the access to the key from startup, and kerberos in this scenario will need ldap up to provide the key. Is ldap up enough that kerberos can provide this? Or does ldap retry or something so that this problem is overcome?
Which KDC are you going to use? Why do you want to use Kerberos as authc mech for the connection between the KDC and the LDAP backend server?
Usually one stashes the password at the KDC which does a simple bind. There's nothing wrong with that. Also I wouldn't use the rootdn as bind-DN for the KDC. I'd rather recommend to create service accounts and define appropriate ACLs.
Another possibility is to use SASL/EXTERNAL for a ldapi:/// connection (Unix domain socket) and map the Unix user to a service account for the KDC. In this case the service account does not need a password at all. But KDC and LDAP server have to run on the same machine for this to work.
Ciao, Michael.
On Wed, 2009-03-04 at 20:13 +0100, Michael Ströder wrote:
Da Rock wrote:
Sorry to barge in straight away with a question like this, but my time is running out and I have not been able to get a straight answer out of google.
I'm going through the hypotheticals for using ldap as the backend for kerberos, and I've hit a chicken and egg problem with SASL- can someone untangle my mind?
IF kerberos is using ldap as a backend store for keys, users, etc, and one can set the rootdn and leave the rootpw for later entry in the database itself, and the password can use SASL auth- what happens if you use kerberos as the auth mechanism?
According to the book, slapd needs to set up the access to the key from startup, and kerberos in this scenario will need ldap up to provide the key. Is ldap up enough that kerberos can provide this? Or does ldap retry or something so that this problem is overcome?
Which KDC are you going to use? Why do you want to use Kerberos as authc mech for the connection between the KDC and the LDAP backend server?
Usually one stashes the password at the KDC which does a simple bind. There's nothing wrong with that. Also I wouldn't use the rootdn as bind-DN for the KDC. I'd rather recommend to create service accounts and define appropriate ACLs.
Another possibility is to use SASL/EXTERNAL for a ldapi:/// connection (Unix domain socket) and map the Unix user to a service account for the KDC. In this case the service account does not need a password at all. But KDC and LDAP server have to run on the same machine for this to work.
I'm not sure you quite understand what I mean here- at least I'm not sure I get your point (if you care to clarify). Although maybe my mention of rootdn has confused the matter...?
To be precise Heimdal offers an option to use the ldap as a backend store for all of its data (keytabs, user profiles, etc). Obviously ACLs need to reflect this so although ladpi:/// socket is used, one should use ACLs that allow only the Heimdal to access the database (at least the keys anyway).
Openldap, in turn, offers the use of Kerberos (Heimdal in this case) to provide authentication through SASL. In the docs it says slapd needs to setup the key with kerberos at the start, so services need to be registered with kerberos through kadmin.
Now, IF Heimdal Kerberos is using ldap as its backend store and the user info for itself is in the database, and IF ldap is using SASL for auth, then ldap needs to register with Heimdal as a service to authenticate Heimdal which is using ldap as its backend service (Typing it out like this is kinda helping to clear the picture in my own mind... :) ). A chicken and egg scenario if I ever saw one.
A couple of points of interest come to mind:
1. Security of the ldapi socket needs to be paramount. Permission should be as tight as can be allowed so that only access is as necessary for use. On top of this, ACLs should only allow heimdal itself to access at least the keys (users and passwords could be changed by other means (?) such as secure web or script as the keys are what allows a user to do what they want and are what could be stolen or targeted at any rate).
2. rootdn should not be allocated a password in the config (no matter what form is used (slapd.conf or slapd.d/cn=config). Since rootdn can change anything in the database on a whim, access to the details of this should be left out of anything that an intruder could gain access to (even though IF root on the host is compromised all hope could well be lost anyway- keep as secure as possible)
3. Obviously SASL should be used as authentication (thats why its being setup isn't it?).
Possible solutions could be to not use SASL for the Heimdal principal so that Heimdal can access its database, rootdn can then use SASL for auth once called for, and ldap can authenticate as a service.
But then, I'm not the expert and I'm only just very new to this as I'm just looking into it now.... :)
Therefore, any thoughts on this? Limitations, workarounds, security flaws in my methods...
Da Rock wrote:
On Wed, 2009-03-04 at 20:13 +0100, Michael Ströder wrote:
Da Rock wrote:
Sorry to barge in straight away with a question like this, but my time is running out and I have not been able to get a straight answer out of google.
I'm going through the hypotheticals for using ldap as the backend for kerberos, and I've hit a chicken and egg problem with SASL- can someone untangle my mind?
IF kerberos is using ldap as a backend store for keys, users, etc, and one can set the rootdn and leave the rootpw for later entry in the database itself, and the password can use SASL auth- what happens if you use kerberos as the auth mechanism?
According to the book, slapd needs to set up the access to the key from startup, and kerberos in this scenario will need ldap up to provide the key. Is ldap up enough that kerberos can provide this? Or does ldap retry or something so that this problem is overcome?
Which KDC are you going to use? Why do you want to use Kerberos as authc mech for the connection between the KDC and the LDAP backend server?
Usually one stashes the password at the KDC which does a simple bind. There's nothing wrong with that. Also I wouldn't use the rootdn as bind-DN for the KDC. I'd rather recommend to create service accounts and define appropriate ACLs.
Another possibility is to use SASL/EXTERNAL for a ldapi:/// connection (Unix domain socket) and map the Unix user to a service account for the KDC. In this case the service account does not need a password at all. But KDC and LDAP server have to run on the same machine for this to work.
I'm not sure you quite understand what I mean here- at least I'm not sure I get your point (if you care to clarify). Although maybe my mention of rootdn has confused the matter...?
To be precise Heimdal offers an option to use the ldap as a backend store for all of its data (keytabs, user profiles, etc). Obviously ACLs need to reflect this so although ladpi:/// socket is used, one should use ACLs that allow only the Heimdal to access the database (at least the keys anyway).
Openldap, in turn, offers the use of Kerberos (Heimdal in this case) to provide authentication through SASL. In the docs it says slapd needs to setup the key with kerberos at the start, so services need to be registered with kerberos through kadmin.
Now, IF Heimdal Kerberos is using ldap as its backend store and the user info for itself is in the database, and IF ldap is using SASL for auth, then ldap needs to register with Heimdal as a service to authenticate Heimdal which is using ldap as its backend service (Typing it out like this is kinda helping to clear the picture in my own mind... :) ). A chicken and egg scenario if I ever saw one.
You're missing the obvious fact that GSSAPI/Kerberos is not the only secure SASL mechanism available in this picture, and it is obviously not the one the KDC uses to talk to LDAP.
A couple of points of interest come to mind:
- Security of the ldapi socket needs to be paramount. Permission should
be as tight as can be allowed so that only access is as necessary for use. On top of this, ACLs should only allow heimdal itself to access at least the keys (users and passwords could be changed by other means (?) such as secure web or script as the keys are what allows a user to do what they want and are what could be stolen or targeted at any rate).
No, security of the ldapi socket is irrelevant since the identity of the client connecting to the socket is what's actually used for the LDAP server's authentication/authorization purposes.
- rootdn should not be allocated a password in the config (no matter
what form is used (slapd.conf or slapd.d/cn=config). Since rootdn can change anything in the database on a whim, access to the details of this should be left out of anything that an intruder could gain access to (even though IF root on the host is compromised all hope could well be lost anyway- keep as secure as possible)
That's generally true.
- Obviously SASL should be used as authentication (thats why its being
setup isn't it?).
Yes. But SASL != Kerberos.
On Wed, 2009-03-04 at 17:27 -0800, Howard Chu wrote:
Da Rock wrote:
On Wed, 2009-03-04 at 20:13 +0100, Michael Ströder wrote:
Da Rock wrote:
Sorry to barge in straight away with a question like this, but my time is running out and I have not been able to get a straight answer out of google.
I'm going through the hypotheticals for using ldap as the backend for kerberos, and I've hit a chicken and egg problem with SASL- can someone untangle my mind?
IF kerberos is using ldap as a backend store for keys, users, etc, and one can set the rootdn and leave the rootpw for later entry in the database itself, and the password can use SASL auth- what happens if you use kerberos as the auth mechanism?
According to the book, slapd needs to set up the access to the key from startup, and kerberos in this scenario will need ldap up to provide the key. Is ldap up enough that kerberos can provide this? Or does ldap retry or something so that this problem is overcome?
Which KDC are you going to use? Why do you want to use Kerberos as authc mech for the connection between the KDC and the LDAP backend server?
Usually one stashes the password at the KDC which does a simple bind. There's nothing wrong with that. Also I wouldn't use the rootdn as bind-DN for the KDC. I'd rather recommend to create service accounts and define appropriate ACLs.
Another possibility is to use SASL/EXTERNAL for a ldapi:/// connection (Unix domain socket) and map the Unix user to a service account for the KDC. In this case the service account does not need a password at all. But KDC and LDAP server have to run on the same machine for this to work.
I'm not sure you quite understand what I mean here- at least I'm not sure I get your point (if you care to clarify). Although maybe my mention of rootdn has confused the matter...?
To be precise Heimdal offers an option to use the ldap as a backend store for all of its data (keytabs, user profiles, etc). Obviously ACLs need to reflect this so although ladpi:/// socket is used, one should use ACLs that allow only the Heimdal to access the database (at least the keys anyway).
Openldap, in turn, offers the use of Kerberos (Heimdal in this case) to provide authentication through SASL. In the docs it says slapd needs to setup the key with kerberos at the start, so services need to be registered with kerberos through kadmin.
Now, IF Heimdal Kerberos is using ldap as its backend store and the user info for itself is in the database, and IF ldap is using SASL for auth, then ldap needs to register with Heimdal as a service to authenticate Heimdal which is using ldap as its backend service (Typing it out like this is kinda helping to clear the picture in my own mind... :) ). A chicken and egg scenario if I ever saw one.
You're missing the obvious fact that GSSAPI/Kerberos is not the only secure SASL mechanism available in this picture, and it is obviously not the one the KDC uses to talk to LDAP.
I'm aware that SASL GSSAPI is not the only SASL auth on offer, but I'm not sure of the latter part of your statement: do you mean that the ldap used as a backend cannot use the kdc using the ldap as the backend for authentication?
You have awoken an alternative in my mind, though. I'll just go and stick my head back in my Openldap doc under SASL for a bit- I'll probably come back with another stupid question shortly... :)
A couple of points of interest come to mind:
- Security of the ldapi socket needs to be paramount. Permission should
be as tight as can be allowed so that only access is as necessary for use. On top of this, ACLs should only allow heimdal itself to access at least the keys (users and passwords could be changed by other means (?) such as secure web or script as the keys are what allows a user to do what they want and are what could be stolen or targeted at any rate).
No, security of the ldapi socket is irrelevant since the identity of the client connecting to the socket is what's actually used for the LDAP server's authentication/authorization purposes.
Surely at least some form of protection from say bruteforce or other form of attack should be implemented here? Stands to reason that only users or services that need something should be allowed access to it. Why leave a hole in the wall when a door could be used to keep out the nasties?
- rootdn should not be allocated a password in the config (no matter
what form is used (slapd.conf or slapd.d/cn=config). Since rootdn can change anything in the database on a whim, access to the details of this should be left out of anything that an intruder could gain access to (even though IF root on the host is compromised all hope could well be lost anyway- keep as secure as possible)
That's generally true.
- Obviously SASL should be used as authentication (thats why its being
setup isn't it?).
Yes. But SASL != Kerberos.
Sorry, I should have said SASL GSSAPI there. But given my above statement I'm starting rethink my stratagem... :)
At this point would like to thank for this experienced input as you have all been a very good sounding board in comparison to rambling to myself and twisting my mind around this many variables and scenarios ;)
Da Rock wrote:
On Wed, 2009-03-04 at 17:27 -0800, Howard Chu wrote:
You're missing the obvious fact that GSSAPI/Kerberos is not the only secure SASL mechanism available in this picture, and it is obviously not the one the KDC uses to talk to LDAP.
I'm aware that SASL GSSAPI is not the only SASL auth on offer, but I'm not sure of the latter part of your statement: do you mean that the ldap used as a backend cannot use the kdc using the ldap as the backend for authentication?
The slapd can use SASL/Kerberos to authenticate everyone *except* requests from the KDC itself, because that would cause the chicken'n'egg loop that you already alluded to. The Heimdal code always uses SASL/EXTERNAL to talk to ldap, for this very reason.
You have awoken an alternative in my mind, though. I'll just go and stick my head back in my Openldap doc under SASL for a bit- I'll probably come back with another stupid question shortly... :)
A couple of points of interest come to mind:
- Security of the ldapi socket needs to be paramount. Permission should
be as tight as can be allowed so that only access is as necessary for use. On top of this, ACLs should only allow heimdal itself to access at least the keys (users and passwords could be changed by other means (?) such as secure web or script as the keys are what allows a user to do what they want and are what could be stolen or targeted at any rate).
No, security of the ldapi socket is irrelevant since the identity of the client connecting to the socket is what's actually used for the LDAP server's authentication/authorization purposes.
Surely at least some form of protection from say bruteforce or other form of attack should be implemented here? Stands to reason that only users or services that need something should be allowed access to it. Why leave a hole in the wall when a door could be used to keep out the nasties?
There is no hole in this wall. An LDAP server is designed to securely process requests from multiple disparate clients. If your KDC and its host machine are secure, and the ACLs in your slapd are correct, then the issue is closed. You cannot bruteforce SASL/EXTERNAL over ldapi://. You can only fool it if you already have superuser access on the host system, and in that case, you were lost already anyway.
You can of course choose to dedicate one LDAP server to back your KDC, but if you're going to isolate it from any other usage in this manner, then you're no longer getting any special benefit from using LDAP.
On Wed, 2009-03-04 at 18:20 -0800, Howard Chu wrote:
Da Rock wrote:
On Wed, 2009-03-04 at 17:27 -0800, Howard Chu wrote:
You're missing the obvious fact that GSSAPI/Kerberos is not the only secure SASL mechanism available in this picture, and it is obviously not the one the KDC uses to talk to LDAP.
I'm aware that SASL GSSAPI is not the only SASL auth on offer, but I'm not sure of the latter part of your statement: do you mean that the ldap used as a backend cannot use the kdc using the ldap as the backend for authentication?
The slapd can use SASL/Kerberos to authenticate everyone *except* requests from the KDC itself, because that would cause the chicken'n'egg loop that you already alluded to. The Heimdal code always uses SASL/EXTERNAL to talk to ldap, for this very reason.
Thats the answer I'm looking for, then.
You have awoken an alternative in my mind, though. I'll just go and stick my head back in my Openldap doc under SASL for a bit- I'll probably come back with another stupid question shortly... :)
A couple of points of interest come to mind:
- Security of the ldapi socket needs to be paramount. Permission should
be as tight as can be allowed so that only access is as necessary for use. On top of this, ACLs should only allow heimdal itself to access at least the keys (users and passwords could be changed by other means (?) such as secure web or script as the keys are what allows a user to do what they want and are what could be stolen or targeted at any rate).
No, security of the ldapi socket is irrelevant since the identity of the client connecting to the socket is what's actually used for the LDAP server's authentication/authorization purposes.
Surely at least some form of protection from say bruteforce or other form of attack should be implemented here? Stands to reason that only users or services that need something should be allowed access to it. Why leave a hole in the wall when a door could be used to keep out the nasties?
There is no hole in this wall. An LDAP server is designed to securely process requests from multiple disparate clients. If your KDC and its host machine are secure, and the ACLs in your slapd are correct, then the issue is closed. You cannot bruteforce SASL/EXTERNAL over ldapi://. You can only fool it if you already have superuser access on the host system, and in that case, you were lost already anyway.
What about pretending to be a user with access to the socket (like ldap or the kdc users)? First rule of sysadmin: don't leave open a door that doesn't need to be open- even an internal one. But if you're talking about only superuser access on the socket then you're doing this anyway... :)
You can of course choose to dedicate one LDAP server to back your KDC, but if you're going to isolate it from any other usage in this manner, then you're no longer getting any special benefit from using LDAP.
I'm not sure exactly what I'm doing yet, but I am researching the possibilities. One possibility is user management, another is replication for other kdc's, not sure about any of these yet.
Thank you all for your input and experience here- this is exactly the info I needed to resolve the dilemma I was binding myself into... :)
Cheers
Da Rock wrote:
On Wed, 2009-03-04 at 18:20 -0800, Howard Chu wrote:
There is no hole in this wall. An LDAP server is designed to securely process requests from multiple disparate clients. If your KDC and its host machine are secure, and the ACLs in your slapd are correct, then the issue is closed. You cannot bruteforce SASL/EXTERNAL over ldapi://. You can only fool it if you already have superuser access on the host system, and in that case, you were lost already anyway.
What about pretending to be a user with access to the socket (like ldap or the kdc users)? First rule of sysadmin: don't leave open a door that doesn't need to be open- even an internal one. But if you're talking about only superuser access on the socket then you're doing this anyway... :)
What about any client on The Internet with access to port 389 (or whatever TCP port the server is listening on)?? Access control on the socket is irrelevant. Set your ACLs so that only properly authenticated users can access their relevant information and then it doesn't matter what socket they came in on.
ldapi:// is not a superuser-only access mechanism, nor does it need to be.
Da Rock wrote:
On Wed, 2009-03-04 at 18:20 -0800, Howard Chu wrote:
There is no hole in this wall. An LDAP server is designed to securely process requests from multiple disparate clients. If your KDC and its host machine are secure, and the ACLs in your slapd are correct, then the issue is closed. You cannot bruteforce SASL/EXTERNAL over ldapi://. You can only fool it if you already have superuser access on the host system, and in that case, you were lost already anyway.
What about pretending to be a user with access to the socket (like ldap or the kdc users)?
I'm a rather practical guy. So let us leave theory aside here: I'd suggest that you set up slapd -h ldapi:/// and connect to it via ldapsearch -H ldapi:///. Observe what's written in the syslog by slapd to get the idea what's happening there.
After that you want to learn about this:
authz-regexp "gidnumber=([0-9]+)\+uidnumber=([0-9]+),cn=peercred,cn=external,cn=auth" "ldap:///ou=schulung,dc=stroeder,dc=local??sub?(&(objectClass=posixAccount)(uidNumber=$2)(gidNumber=$1))"
This maps the Unix account data to an existing directory entry. This could be e.g. the Unix service account of the KDC mapped to the accompanying directory entry which gets the appropriate authorization by ACLs.
First rule of sysadmin: don't leave open a door that doesn't need to be open- even an internal one.
Be assured. People here like Howard are quite aware of that rule.
You can of course choose to dedicate one LDAP server to back your KDC, but if you're going to isolate it from any other usage in this manner, then you're no longer getting any special benefit from using LDAP.
I'm not sure exactly what I'm doing yet, but I am researching the possibilities. One possibility is user management, another is replication for other kdc's, not sure about any of these yet.
Another benefit of having a LDAP backend for the KDC is that it's more easy to sync user accounts.
Ciao, Michael.
Howard Chu wrote:
You can of course choose to dedicate one LDAP server to back your KDC, but if you're going to isolate it from any other usage in this manner, then you're no longer getting any special benefit from using LDAP.
Even if you isolate your LDAP server solely to back your KDC you gain at least a better replication mechanism.
Ciao, Michael.
Da Rock wrote:
I'm not sure you quite understand what I mean here-
I think I do. ;-)
There's no reason why you shouldn't be able to do the following:
LDAP Client --ldap:// with SASL/GSSAPI--> slapd --KRB5--> heimdal KDC --ldapi:// with SASL/EXTERNAL--> slapd
In fact the picture is a bit more complicated but I'm too tired to draw the real one. Hope you get the idea.
Ciao, Michael.
On Thu, 2009-03-05 at 02:43 +0100, Michael Ströder wrote:
Da Rock wrote:
I'm not sure you quite understand what I mean here-
I think I do. ;-)
There's no reason why you shouldn't be able to do the following:
LDAP Client --ldap:// with SASL/GSSAPI--> slapd --KRB5--> heimdal KDC --ldapi:// with SASL/EXTERNAL--> slapd
In fact the picture is a bit more complicated but I'm too tired to draw the real one. Hope you get the idea.
Actually thats very well presented- at least I get what your saying.
A hiccup here is that I mean that there is no ldap client- yet. I'm talking about at startup, slapd looks to authenticate with kerberos as a service, and kerberos is using ldap as the backend store and needs to authenticate to do so, which kerberos can't do as ldap hasn't authenticated yet as a service.
I can see several options/problems:
1. this would/should only be a problem on the initial startup and again IF the system goes down longer than the ticket lifetime.
2. The initial startup shouldn't be a problem as the password could be changed to SASL/GSSAPI once the system is up and running.
IF rootdn particularly is not allocated a password until changed within the database itself then this can be set to SASL/GSSAPI after startup, and the Heimdal user would have to be set in an initial ldif file anyway- right?
Da Rock wrote:
On Thu, 2009-03-05 at 02:43 +0100, Michael Ströder wrote:
Da Rock wrote:
I'm not sure you quite understand what I mean here-
I think I do. ;-)
There's no reason why you shouldn't be able to do the following:
LDAP Client --ldap:// with SASL/GSSAPI--> slapd --KRB5--> heimdal KDC --ldapi:// with SASL/EXTERNAL--> slapd
In fact the picture is a bit more complicated but I'm too tired to draw the real one. Hope you get the idea.
Actually thats very well presented- at least I get what your saying.
A hiccup here is that I mean that there is no ldap client- yet. I'm talking about at startup, slapd looks to authenticate with kerberos as a service
??? No, slapd does no such thing, that's not how Kerberos works.
Only Kerberos clients talk to the KDC. A Kerberized server only needs a keytab containing its principal name and current key. Those items can be generated by the KDC talking to slapd over SASL/EXTERNAL. Certainly slapd will be unable to perform GSSAPI authentication for any other LDAP clients until this step is completed, but it only happens once.
And this is true regardless of what your KDC uses as a backing store. Which again brings us back to the point of why the OpenLDAP docs expect you to already understand Kerberos before touching the subject here. If you don't already understand Kerberos, it's pointless to discuss it here (because this is an *LDAP* forum not a Kerberos forum) and when you *do* understand Kerberos, there's nothing more that needs to be explained.
We are starting to work towards implimenting this very solution. Is there any documentation you have found to be particularly helpful?
Thanks -Troy
On Mar 4, 2009, at 2:30 AM, Da Rock wrote:
Sorry to barge in straight away with a question like this, but my time is running out and I have not been able to get a straight answer out of google.
I'm going through the hypotheticals for using ldap as the backend for kerberos, and I've hit a chicken and egg problem with SASL- can someone untangle my mind?
IF kerberos is using ldap as a backend store for keys, users, etc, and one can set the rootdn and leave the rootpw for later entry in the database itself, and the password can use SASL auth- what happens if you use kerberos as the auth mechanism?
According to the book, slapd needs to set up the access to the key from startup, and kerberos in this scenario will need ldap up to provide the key. Is ldap up enough that kerberos can provide this? Or does ldap retry or something so that this problem is overcome?
Thoughts?
Cheers
On Wed, 2009-03-04 at 11:15 -0800, Troy Knabe wrote:
We are starting to work towards implimenting this very solution. Is there any documentation you have found to be particularly helpful?
Thanks -Troy
Well for starters most of the howtos on the net are shoddy and appear thrown together- even PADL. What concerns me is these sites show others how to do things (by experts in some cases) and the security doesn't appear as high a priority as it should be. PADL for instance recommend opening the ldapi socket to any writes and changes in their ACL. In some cases its simply a matter of "too hard to think further" on the issues.
The Heimdal docs are security conscious (naturally), but there is no direct "howto" in there, and the references are very piecemeal and appear incomplete (for instance they use hdb.schema, and say its in the source code- which source? Openldap or Heimdal? At any rate I couldn't find it in either. PADL have a similar problem with krb5-kdc.schema).
Openldap has a good documentation project, but they have no idea of the Heimdal implementation (not to blame with Heimdal not even sure either). References on SASL and ACLs are very good, but one needs to really understand what is really happening first (I didn't know too much about directory services and have only studied and learnt on my own)- perhaps some more examples (in a separate document maybe?) of what a newbie could understand (use figures- makes more sense that way. Screenshots, diagrams...) of what ldap is and does/is capable of?
Unless you really sat down (as a complete and utter greenhorn) and read between the lines like I did you'd never understand that ldap can handle several directories/database simultaneously with different access controls etc.
I like the documentation project you have running and if I can get the time (once I master this beast!) I'd like to help here.
I have digressed here, but in short outside of your own docs and Heimdal I don't think any material on the net is really useful at all. Everybody claims to be an expert, but haven't offered that level of advice. Everyone who is an expert has kept very tight lipped on something which is obviously a security risk and a money spinner for their own interests. Perhaps instead we should compare notes and implement it ourselves?
On Mar 4, 2009, at 2:30 AM, Da Rock wrote:
Sorry to barge in straight away with a question like this, but my time is running out and I have not been able to get a straight answer out of google.
I'm going through the hypotheticals for using ldap as the backend for kerberos, and I've hit a chicken and egg problem with SASL- can someone untangle my mind?
IF kerberos is using ldap as a backend store for keys, users, etc, and one can set the rootdn and leave the rootpw for later entry in the database itself, and the password can use SASL auth- what happens if you use kerberos as the auth mechanism?
According to the book, slapd needs to set up the access to the key from startup, and kerberos in this scenario will need ldap up to provide the key. Is ldap up enough that kerberos can provide this? Or does ldap retry or something so that this problem is overcome?
Thoughts?
Cheers
Da Rock wrote:
Openldap has a good documentation project, but they have no idea of the Heimdal implementation
Note that
1. you can build OpenLDAP as kerberized demon with both KRB5 implementations (heimdal and MIT) and
2. you can also use recent versions of the MIT KDC with a LDAP backend (not only OpenLDAP's slapd). To make matters worse both schemas differ.
Given that I think it's outside the scope of the OpenLDAP admin guide to speak about how to use OpenLDAP as a heimdal LDAP backend.
Ciao, Michael.
openldap-technical@openldap.org
-
Da Rock -
Howard Chu -
Michael Ströder -
Troy Knabe