Re: Thread-safe libraries

2004-03-01 Thread Donn Cave
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

2004-02-28 Thread Sam Hartman
> "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

2004-02-27 Thread Lukas Kubin
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

2004-02-25 Thread Ken Hornstein
>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

2004-02-25 Thread Cesar Garcia
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

2004-02-25 Thread Ken Hornstein
>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

2004-02-25 Thread Sam Hartman
> "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

2004-02-25 Thread Cesar Garcia
> "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 Kerberos
Ken> result from the lack of any file locking in the replay cache code.

Ken> Heimdal solves this part of thread-safeness by not having a replay
Ken> cache, at a cost to security.  How much this affects security in
Ken> practice is debatable; I'm not aware of any current attacks against
Ken> Kerberos application servers via ticket replay, but it's certainly
Ken> possible.

wrt to gssapi and 1.3.1 ...

Since we're pointing out lack of replay cache detection, note that if
acquiring creds for GSS_C_NO_NAME, then no replay cache is used.
(specifically looking at 1.3.1 - lib/gssapi/krb5/acquire_cred.c)

Acquiring creds for GSS_C_NO_NAME is also a result of invoking
gss_accept_sec_context with a verifier cred of GSS_C_NO_CREDENTIAL.
(This is very convenient for certain apps).

Of course, in the case of MIT - the choice is yours (at least
implicitly).

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos


Re: Thread-safe libraries

2004-02-25 Thread Sam Hartman
> "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

2004-02-25 Thread Sam Hartman
> "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

2004-02-25 Thread Ken Hornstein
>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

2004-02-25 Thread Lukas Kubin
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

2004-02-24 Thread Luke Howard

>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


Re: Thread-safe libraries

2004-02-24 Thread Nikola Milutinovic
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

2004-02-24 Thread Sam Hartman
> "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

2004-02-24 Thread Tim Alsop
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


Thread-safe libraries

2004-02-24 Thread Lukas Kubin
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


smime.p7s
Description: S/MIME Cryptographic Signature

Kerberos mailing list   [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos