Re: Thread-safe libraries
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Sam Hartman) wrote: Lukas == Lukas Kubin [EMAIL PROTECTED] writes: Lukas Is there any progress in the ability of Kerberos libraries Lukas on Linux to be used by threads-enabled applications? I'm Lukas still having troubles using sasl kerberos authentication to Lukas ldap server on Linux (Debian). It always fails when Lukas parallel connection appears. Is there any solution for Lukas this now? Thank you. I believe someone has written a patch to the SASL library to use mutexes around GSSAPI calls. That sounds like Simon Wilkinson. I have done this too, but I'm sure his code is at least better tested. Unless I missed something, it can be done with fairly simple changes to one source file (plugins/gssapi.c) and does away with a few little headaches if you're not otherwise using Heimdal already. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
Lukas == Lukas Kubin [EMAIL PROTECTED] writes: Lukas Sam Hartman wrote: Lukas == Lukas Kubin [EMAIL PROTECTED] writes: Lukas How complicated is it to move to Heimdal from MIT? I need Lukas a solution to enable users' authentication to LDAP in our Lukas network which uses MIT Kerberos 5. What do you use? On a Debian system using the native LDAP, install libsasl2-modules-gssapi-heimdal not libsasl2-gssapi-mit. That should be all you need. You can continue using MIT for everything else. Lukas Thank you, that's what I was looking for! I wouldn't expect Lukas it is suitable to use heimdal libraries wit MIT K5. No, but I've spent a fair bit of time working with the Debian Heimdal maintainer (I maintain MIT Kerberos for Debian) to make sure you can install both libraries on the same system. Each application chooses which version of Kerberos it wants. We should soon be at a point where different parts of the same application can use different Kerberos implementations. If I'm misremembering that you are using Debian, then you just need to build libsasl against LDAP. If you are also using PAM, you might want libpam-heimdal not libpam-krb5. Lukas Why. Is it related to the threading support too? Re phrasing: If you use PAM inside your LDAP server you may want Heimdal PAM modules for two reasons. First, it currently doesn't work so well if part of an application uses Heimdal and another part uses MIT. So if the SASL plugin for the LDAP server is going to use Heimdal then anything else within LDAP that uses Kerberos should also use Heimdal. Secondly, you'll run into the threading issue possibly if you use PAM to resolve simple binds. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
Sam Hartman wrote: Lukas == Lukas Kubin [EMAIL PROTECTED] writes: Lukas How complicated is it to move to Heimdal from MIT? I need Lukas a solution to enable users' authentication to LDAP in our Lukas network which uses MIT Kerberos 5. What do you use? On a Debian system using the native LDAP, install libsasl2-modules-gssapi-heimdal not libsasl2-gssapi-mit. That should be all you need. You can continue using MIT for everything else. Thank you, that's what I was looking for! I wouldn't expect it is suitable to use heimdal libraries wit MIT K5. If I'm misremembering that you are using Debian, then you just need to build libsasl against LDAP. If you are also using PAM, you might want libpam-heimdal not libpam-krb5. Why. Is it related to the threading support too? Lukas Originally I (after I've found I can't use MIT's kerberos Lukas with OpenLDAP) wished to try to use the krb5kdc LDAP schema Lukas and let LDAP server to verify the password itself. However, Lukas I found the latest versions of OpenLDAP don't support this Lukas feature. Is there any other way? I need to resolve this Lukas soon. But I don't know about Heimdal K5 support on I strongly recommend against the KDC LDAP schema. Again, thank you really much for the help. It was too painful for me to solve the problem of falling LDAP server. And the solution is so simple ... lukas -- Lukas Kubin phone: +420596398275 email: [EMAIL PROTECTED] Information centre The School of Business Administration in Karvina Silesian University in Opava Czech Republic http://www.opf.slu.cz smime.p7s Description: S/MIME Cryptographic Signature Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
How complicated is it to move to Heimdal from MIT? I need a solution to enable users' authentication to LDAP in our network which uses MIT Kerberos 5. What do you use? Originally I (after I've found I can't use MIT's kerberos with OpenLDAP) wished to try to use the krb5kdc LDAP schema and let LDAP server to verify the password itself. However, I found the latest versions of OpenLDAP don't support this feature. Is there any other way? I need to resolve this soon. But I don't know about Heimdal K5 support on Windows. I need to use both Linux and Windows clients. Thank you. lukas Nikola Milutinovic wrote: Sam Hartman wrote: Lukas == Lukas Kubin [EMAIL PROTECTED] writes: Lukas Is there any progress in the ability of Kerberos libraries Lukas on Linux to be used by threads-enabled applications? I'm Lukas still having troubles using sasl kerberos authentication to Lukas ldap server on Linux (Debian). It always fails when Lukas parallel connection appears. Is there any solution for Lukas this now? Thank you. I believe someone has written a patch to the SASL library to use mutexes around GSSAPI calls. MIT is working on thread safety for our libraries but has not released any code yet. Some time ago, I had the same worry. Apparently, the only thread-safe Kerberos libraries around are from Tim Aslop's company (he replied on this list), Cybersafe, I think. It is also worth noting, that, while Heimdal is not thread safe (at least there are no guarantees), it has proven to be much more thread-robust than MIT. OpenLDAP page and a couple of users have expirienced problems with MIT and threaded OpenLDAP server, while Heimdal performed flawlessly. It could be that Heimdal IS thread-safe, just nobody knows for sure. :-) Nix. P.S. Cyrus SASL 2.1.17 recognizes MIT, Heimdal, Cybersafe and SEAM (Sun) Kerberos implementations. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos -- Lukas Kubin phone: +420596398275 email: [EMAIL PROTECTED] Information centre The School of Business Administration in Karvina Silesian University in Opava Czech Republic http://www.opf.slu.cz smime.p7s Description: S/MIME Cryptographic Signature Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
It is also worth noting, that, while Heimdal is not thread safe (at least there are no guarantees), it has proven to be much more thread-robust than MIT. OpenLDAP page and a couple of users have expirienced problems with MIT and threaded OpenLDAP server, while Heimdal performed flawlessly. It could be that Heimdal IS thread-safe, just nobody knows for sure. :-) I believe that many of the problems of thread-safeness in MIT Kerberos result from the lack of any file locking in the replay cache code. Heimdal solves this part of thread-safeness by not having a replay cache, at a cost to security. How much this affects security in practice is debatable; I'm not aware of any current attacks against Kerberos application servers via ticket replay, but it's certainly possible. --Ken Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
Ken == Ken Hornstein [EMAIL PROTECTED] writes: It is also worth noting, that, while Heimdal is not thread safe (at least there are no guarantees), it has proven to be much more thread-robust than MIT. OpenLDAP page and a couple of users have expirienced problems with MIT and threaded OpenLDAP server, while Heimdal performed flawlessly. It could be that Heimdal IS thread-safe, just nobody knows for sure. :-) Ken I believe that many of the problems of thread-safeness in MIT Ken Kerberos result from the lack of any file locking in the Ken replay cache code. It would be nice if someone having crashes with OpenLDAP would get a backtrace showing this. Certainly if the problem were well-defined we'd be happy to spend a bit of time making Open LDAP users' lives easier possibly on a relatively short time scale. --Sam Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
Lukas == Lukas Kubin [EMAIL PROTECTED] writes: Lukas How complicated is it to move to Heimdal from MIT? I need Lukas a solution to enable users' authentication to LDAP in our Lukas network which uses MIT Kerberos 5. What do you use? On a Debian system using the native LDAP, install libsasl2-modules-gssapi-heimdal not libsasl2-gssapi-mit. That should be all you need. You can continue using MIT for everything else. If I'm misremembering that you are using Debian, then you just need to build libsasl against LDAP. If you are also using PAM, you might want libpam-heimdal not libpam-krb5. Lukas Originally I (after I've found I can't use MIT's kerberos Lukas with OpenLDAP) wished to try to use the krb5kdc LDAP schema Lukas and let LDAP server to verify the password itself. However, Lukas I found the latest versions of OpenLDAP don't support this Lukas feature. Is there any other way? I need to resolve this Lukas soon. But I don't know about Heimdal K5 support on I strongly recommend against the KDC LDAP schema. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
Cesar == Cesar Garcia [EMAIL PROTECTED] writes: Cesar wrt to gssapi and 1.3.1 ... Cesar Since we're pointing out lack of replay cache detection, Cesar note that if acquiring creds for GSS_C_NO_NAME, then no Cesar replay cache is used. (specifically looking at 1.3.1 - Cesar lib/gssapi/krb5/acquire_cred.c) I think that's false. I believe that krb5_rd_req will end up setting up a rcache later. I don't have time to go look through the code now though, but I wrote it and at least intended that a replay cache would get used even though it does not get stored in the GSSAPI credentials structure. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
I think that's false. I believe that krb5_rd_req will end up setting up a rcache later. I think Cesar is right, actually. krb5_rd_req will only set up a replay cache if you pass in the server argument, which is set from creds-princ, which is NULL if you call the gss function with GSS_C_NO_CREDENTIAL. I believe this is why raw Kerberos apps (like telnetd) explicitly set up a replay cache; those apps generally will accept any principal on a host. --Ken Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
According to strace ... 1.2.8 app server with named credential - opens an rcache. 1.3.1 app server with no credential - no evidence of rcache being opened. wrt to krb5_rd_req - it looks like rcache is obtained only if auth_context_flags includes KRB5_AUTH_CONTEXT_DO_TIME. accept_sec_context clearly sets auth_context with KRB5_AUTH_CONTEXT_DO_SEQUENCE. What am I missing? Sam == Sam Hartman [EMAIL PROTECTED] writes: Cesar == Cesar Garcia [EMAIL PROTECTED] writes: Cesar wrt to gssapi and 1.3.1 ... Cesar Since we're pointing out lack of replay cache detection, Cesar note that if acquiring creds for GSS_C_NO_NAME, then no Cesar replay cache is used. (specifically looking at 1.3.1 - Cesar lib/gssapi/krb5/acquire_cred.c) Sam I think that's false. I believe that krb5_rd_req will end up setting Sam up a rcache later. Sam I don't have time to go look through the code now though, but I wrote Sam it and at least intended that a replay cache would get used even Sam though it does not get stored in the GSSAPI credentials structure. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
According to strace ... 1.2.8 app server with named credential - opens an rcache. 1.3.1 app server with no credential - no evidence of rcache being opened. Hm, regarding my previous note It looks like I was wrong, krb5_rd_req() will get a replay cache even if the passed-in server is NULL, because it gets the server name from the ticket. wrt to krb5_rd_req - it looks like rcache is obtained only if auth_context_flags includes KRB5_AUTH_CONTEXT_DO_TIME. accept_sec_context clearly sets auth_context with KRB5_AUTH_CONTEXT_DO_SEQUENCE. Looks like the right thing to do here is change accept_sec_context() to set KRB5_AUTH_CONTEXT_DO_SEQUENCE. --Ken Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Thread-safe libraries
Lukas, Our TrustBroker products are threadsafe and we are currently working on a solution which uses SASL/GSS to administer Active Directory from Linux, Solaris, HPUX, AIX and Windows systems. Please let me know if you would like to discuss this further by contacting me offlist. Thanks, Tim. -Original Message- From: Lukas Kubin [mailto:[EMAIL PROTECTED] Sent: 24 February 2004 12:11 To: [EMAIL PROTECTED] Subject: Thread-safe libraries Is there any progress in the ability of Kerberos libraries on Linux to be used by threads-enabled applications? I'm still having troubles using sasl kerberos authentication to ldap server on Linux (Debian). It always fails when parallel connection appears. Is there any solution for this now? Thank you. lukas -- Lukas Kubin phone: +420596398275 email: [EMAIL PROTECTED] Information centre The School of Business Administration in Karvina Silesian University in Opava Czech Republic http://www.opf.slu.cz Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
Lukas == Lukas Kubin [EMAIL PROTECTED] writes: Lukas Is there any progress in the ability of Kerberos libraries Lukas on Linux to be used by threads-enabled applications? I'm Lukas still having troubles using sasl kerberos authentication to Lukas ldap server on Linux (Debian). It always fails when Lukas parallel connection appears. Is there any solution for Lukas this now? Thank you. I believe someone has written a patch to the SASL library to use mutexes around GSSAPI calls. MIT is working on thread safety for our libraries but has not released any code yet. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
Sam Hartman wrote: Lukas == Lukas Kubin [EMAIL PROTECTED] writes: Lukas Is there any progress in the ability of Kerberos libraries Lukas on Linux to be used by threads-enabled applications? I'm Lukas still having troubles using sasl kerberos authentication to Lukas ldap server on Linux (Debian). It always fails when Lukas parallel connection appears. Is there any solution for Lukas this now? Thank you. I believe someone has written a patch to the SASL library to use mutexes around GSSAPI calls. MIT is working on thread safety for our libraries but has not released any code yet. Some time ago, I had the same worry. Apparently, the only thread-safe Kerberos libraries around are from Tim Aslop's company (he replied on this list), Cybersafe, I think. It is also worth noting, that, while Heimdal is not thread safe (at least there are no guarantees), it has proven to be much more thread-robust than MIT. OpenLDAP page and a couple of users have expirienced problems with MIT and threaded OpenLDAP server, while Heimdal performed flawlessly. It could be that Heimdal IS thread-safe, just nobody knows for sure. :-) Nix. P.S. Cyrus SASL 2.1.17 recognizes MIT, Heimdal, Cybersafe and SEAM (Sun) Kerberos implementations. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Thread-safe libraries
It is also worth noting, that, while Heimdal is not thread safe (at least there are no guarantees), it has proven to be much more thread-robust than MIT. OpenLDAP page and a couple of users have expirienced problems with MIT and threaded OpenLDAP server, while Heimdal performed flawlessly. It could be that Heimdal IS thread-safe, just nobody knows for sure. :-) The recent Heimdal snapshots have considerable improvements in the thread safety department, and I expect these will be in 0.7 when it is released. -- Luke Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
