python-ldap-dev

Connection to AD on windows

[Jeroen M. <jmi...@ya...>]

Hi,

I'm trying to get python-ldap working on a windows machine to authenticate users against an Active Directory server.
However, I'm getting the weirdest things...


This is what I'm trying:

import ldap, ldap.sasl

conn = ldap.initialize('ldap://blabla')
conn.set_option(ldap.OPT_PROTOCOL_VERSION, ldap.VERSION3)
conn.set_option(ldap.OPT_REFERRALS,0)
sasl = ldap.sasl.gssapi()
conn.sasl_interactive_bind_s('', sasl)

upon the sasl_interactive_bind_s, I get the following traceback:

Traceback (most recent call last):
  File "D:\Projects\Python\ldap\src\ldaptest.py", line 12, in <module>
    conn.sasl_interactive_bind_s('', sasl)
  File "c:\python25\lib\site-packages\python_ldap-2.3.9-py2.5-win32.egg\ldap\ldapobject.py", line 219, in sasl_interactive_bind_s
    return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls),sasl_flags)
  File "c:\python25\lib\site-packages\python_ldap-2.3.9-py2.5-win32.egg\ldap\ldapobject.py", line 96, in _ldap_call
    result = func(*args,**kwargs)
ldap.SUCCESS: {'desc': 'Success'}

so apparently an exception of type ldap.SUCCESS seems to be thrown, which doesn't make much sense...

What's going on?
I'm totally clueless...

Im using the 2.3.9 release I got here:
http://svn.kmrc.de/download/distribution/contrib/

Thanks in advance for any ideas!



      

SASL GSSAPI under Win32 (was: Connection to AD on windows)

[Michael S. <mi...@st...>]

Jeroen Michiel wrote:
> 
> I'm trying to get python-ldap working on a windows machine to authenticate
> users against an Active Directory server. However, I'm getting the weirdest
> things...
> 
> This is what I'm trying:
> 
> import ldap, ldap.sasl
> 
> conn = ldap.initialize('ldap://blabla')
> conn.set_option(ldap.OPT_PROTOCOL_VERSION, ldap.VERSION3)
> conn.set_option(ldap.OPT_REFERRALS,0)
> sasl = ldap.sasl.gssapi()
> conn.sasl_interactive_bind_s('', sasl)

I'm pretty sure SASL bind with GSSAPI mech is not supported with the Win32
builds. Therefore I changed the subject line to trigger attention of the
relevant readers.

The OpenLDAP libs are usually compiled against heimdal or MIT Kerberos which
both have nothing to do with the Kerberos ticket store of your Windows session.

David tried another approach which would help for this situation. His
experimental attempts to build with wldap32.dll can be found here:

http://sourceforge.net/tracker/?func=detail&aid=1698443&group_id=2072&atid=352072

Any takers? Personally I have some doubts though because especially regarding
SASL the APIs are incompatible.

> upon the sasl_interactive_bind_s, I get the following traceback:
> 
> Traceback (most recent call last):
>   File "D:\Projects\Python\ldap\src\ldaptest.py", line 12, in <module>
>     conn.sasl_interactive_bind_s('', sasl)
>   File "c:\python25\lib\site-packages\python_ldap-2.3.9-py2.5-win32.egg\ldap\ldapobject.py", line 219, in sasl_interactive_bind_s
>     return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls),sasl_flags)
>   File "c:\python25\lib\site-packages\python_ldap-2.3.9-py2.5-win32.egg\ldap\ldapobject.py", line 96, in _ldap_call
>     result = func(*args,**kwargs)
> ldap.SUCCESS: {'desc': 'Success'}

Raising ldap.SUCCESS in this case is clearly a bug.

> Im using the 2.3.9 release I got here:
> http://svn.kmrc.de/download/distribution/contrib/

These are .egg files built by Torsten. Not sure what he did regarding Kerberos.

Maybe Torsten or Waldemar can comment on the Win32 builds.

Ciao, Michael.

Re: SASL GSSAPI under Win32 (was: Connection to AD on windows)

[Waldemar O. <wal...@gm...>]

2009/8/5 Michael Ströder <mi...@st...>:
> Jeroen Michiel wrote:
>>

>
> I'm pretty sure SASL bind with GSSAPI mech is not supported with the Win32
> builds. Therefore I changed the subject line to trigger attention of the
> relevant readers.
>
> The OpenLDAP libs are usually compiled against heimdal or MIT Kerberos which
> both have nothing to do with the Kerberos ticket store of your Windows session.
>
> David tried another approach which would help for this situation. His
> experimental attempts to build with wldap32.dll can be found here:
>
> http://sourceforge.net/tracker/?func=detail&aid=1698443&group_id=2072&atid=352072
>
> Any takers? Personally I have some doubts though because especially regarding
> SASL the APIs are incompatible.
>

>
>> Im using the 2.3.9 release I got here:
>> http://svn.kmrc.de/download/distribution/contrib/
>
> These are .egg files built by Torsten. Not sure what he did regarding Kerberos.
>
> Maybe Torsten or Waldemar can comment on the Win32 builds.
>

I have made a couple attempts to support SASL in the Win32 builds.
One user even reported a success using it but it never worked for me.
I will give it one more go but I can not make any promises.

Waldemar

Re: SASL GSSAPI under Win32

[Michael S. <mi...@st...>]

Waldemar Osuch wrote:
> I have made a couple attempts to support SASL in the Win32 builds.
> One user even reported a success using it but it never worked for me.
> I will give it one more go but I can not make any promises.

I tried to bind with SASL DIGEST-MD5 to MS AD W2K3SP2 and to OpenLDAP 2.4.x
but that did not work:

AUTH_UNKNOWN: {'info': 'SASL(-4): no mechanism available: Unable to find a
callback: 2', 'desc': 'Unknown authentication method'}

Hmm, are the SASL mechs modules available at all?

Ciao, Michael.

Re: SASL GSSAPI under Win32

[Waldemar O. <wal...@gm...>]

2009/8/5 Michael Ströder <mi...@st...>:
> Waldemar Osuch wrote:
>> I have made a couple attempts to support SASL in the Win32 builds.
>> One user even reported a success using it but it never worked for me.
>> I will give it one more go but I can not make any promises.
>
> I tried to bind with SASL DIGEST-MD5 to MS AD W2K3SP2 and to OpenLDAP 2.4.x
> but that did not work:
>
> AUTH_UNKNOWN: {'info': 'SASL(-4): no mechanism available: Unable to find a
> callback: 2', 'desc': 'Unknown authentication method'}
>
> Hmm, are the SASL mechs modules available at all?
>
That is the error I am getting too.
My understanding of how it is supposed to work is that _ldap.pyd calls into
libsasl.dll first (this part works) but then libsasl.dll has to find and load
the requested auth mechanism.
Unfortunately I did not find a way of telling libsasl where the
auth plugin dlls are located.
Dropping them into the same directory and hoping it will find them
does not seem to work.

Re: SASL GSSAPI under Win32

[Jeroen M. <jmi...@ya...>]

I also had that same error trying digest-md5. 
I still find it strange that with gssapi a SUCCESS exception is raised: it smells like a bug, or like a mismatch of libraries somehow.
The strange thing is that the version I use is supposed to be statically linked to the necessary libs, so that you won't have the DLL lookup issues. For dynamically linked versions one can always copy the dlls to system32, but that's fishy at best...

But I found a way to get it working without sasl at last with simple_bind_s and the ldap.OPT_REFERRALS option.
I had already read about this option, but it didn't help, until it turned out I had to supply valid account data to simple_bind_s (the so-called 'Bind DN and password', I guess). I had already tried all sorts of combinations, but not that one... (I'm new to LDAP as you might guess)


Thanks for your time!


----- Original Message ----
From: Waldemar Osuch <wal...@gm...>
To: Michael Ströder <mi...@st...>
Cc: pyt...@li...
Sent: Thursday, 6 August, 2009 5:07:08
Subject: Re: SASL GSSAPI under Win32

2009/8/5 Michael Ströder <mi...@st...>:
> Waldemar Osuch wrote:
>> I have made a couple attempts to support SASL in the Win32 builds.
>> One user even reported a success using it but it never worked for me.
>> I will give it one more go but I can not make any promises.
>
> I tried to bind with SASL DIGEST-MD5 to MS AD W2K3SP2 and to OpenLDAP 2.4.x
> but that did not work:
>
> AUTH_UNKNOWN: {'info': 'SASL(-4): no mechanism available: Unable to find a
> callback: 2', 'desc': 'Unknown authentication method'}
>
> Hmm, are the SASL mechs modules available at all?
>
That is the error I am getting too.
My understanding of how it is supposed to work is that _ldap.pyd calls into
libsasl.dll first (this part works) but then libsasl.dll has to find and load
the requested auth mechanism.
Unfortunately I did not find a way of telling libsasl where the
auth plugin dlls are located.
Dropping them into the same directory and hoping it will find them
does not seem to work.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Python-LDAP-dev mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev



      

Re: SASL GSSAPI under Win32

[Torsten K. <pyt...@tk...>]

Hi list,

sorry for getting back to this so late, but I've been away from my
Windows development machine for a while...

> My understanding of how it is supposed to work is that _ldap.pyd
> calls into libsasl.dll first (this part works) but then libsasl.dll
> has to find and load the requested auth mechanism.
> Unfortunately I did not find a way of telling libsasl where the
> auth plugin dlls are located.
> Dropping them into the same directory and hoping it will find them
> does not seem to work.

Waldemar, I now tried a differente approach: I used our "patented"
pexports method to statically link in the following sasl auth plugins:

- ANONYMOUS
- CRAMMD5
- DIGESTMD5
- LOGIN
- PLAIN

But telling from the size of the .egg file, gcc most probably dropped
all the additional symbols. :-(
Could someone with an appropriate setup please check out

http://svn.kmrc.de/download/distribution/contrib/python_ldap-2.3.9-py2.6-win32.egg

try one or more of the above auth mechanisms and report back here?

Thanks in advance
Torsten
-- 
  I am a deeply superficial person. -Andy Warhol

Re: SASL GSSAPI under Win32

[Michael S. <mi...@st...>]

Torsten,

first thanks for trying to get that working.

Torsten Kurbad wrote:
>> My understanding of how it is supposed to work is that _ldap.pyd
>> calls into libsasl.dll first (this part works) but then libsasl.dll
>> has to find and load the requested auth mechanism.

Yes, that's my superficial understanding too.

> Waldemar, I now tried a differente approach: I used our "patented"
> pexports method to statically link in the following sasl auth plugins:
> 
> - ANONYMOUS
> - CRAMMD5
> - DIGESTMD5
> - LOGIN
> - PLAIN
> 
> But telling from the size of the .egg file, gcc most probably dropped
> all the additional symbols. :-(

Yes, I guess so.

> Could someone with an appropriate setup please check out
> 
> http://svn.kmrc.de/download/distribution/contrib/python_ldap-2.3.9-py2.6-win32.egg
> 
> try one or more of the above auth mechanisms and report back here?

Unfortunately it does not seem to work:

--------------------------- snip ---------------------------
>>> sasl_cb_value_dict = {
      ldap.sasl.CB_AUTHNAME    :'fred',
      ldap.sasl.CB_PASS        :'secret',
    }
>>> sasl_auth=ldap.sasl.sasl(sasl_cb_value_dict,'DIGEST-MD5')
>>> l.sasl_interactive_bind_s("", sasl_auth)

Traceback (most recent call last):
  File "<pyshell#13>", line 1, in <module>
    l.sasl_interactive_bind_s("", sasl_auth)
  File "C:\Python26\lib\site-packages\ldap\ldapobject.py", line 219, in
sasl_interactive_bind_s
    return
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls),sasl_flags)
  File "C:\Python26\lib\site-packages\ldap\ldapobject.py", line 96, in _ldap_call
    result = func(*args,**kwargs)
SUCCESS: {'desc': 'Success'}
>>> l.whoami_s()
''
>>>
--------------------------- snip ---------------------------

Ciao, Michael.

Re: SASL GSSAPI under Win32

[Torsten K. <pyt...@tk...>]

Hi Michael,

thanks for testing the new .egg so quickly.

> Unfortunately it does not seem to work:

That's really unfortunate. I'll try now to dig into the configure
scripts of Cyrus-SASL to get rid of most of the dependencies (as the
Mozilla guys did with the NTMakefile). Then it should be possible to
do a "real" static build of library and plugins using MinGW.

Regards,
Torsten
-- 
  His honour rooted in dishonour stood,
  And faith unfaithful kept him falsely true.
  -Alfred Lord Tennyson

Re: SASL GSSAPI under Win32

[Torsten K. <pyt...@tk...>]

> I'll try now to dig into the configure
> scripts of Cyrus-SASL to get rid of most of the dependencies (as the
> Mozilla guys did with the NTMakefile). Then it should be possible to
> do a "real" static build of library and plugins using MinGW.

I think, I'm almost there. I have a static libsasl and several static
plugin libs, but when I try to link one of the plugins with
_ldap.pyd, I get:

e:\projects\prereq\built\cyrus-sasl\lib\sasl2\libcrammd5.a(plugin_common.o):
	In function `plug_ipfromstring':
	e:/projects/prereq/src/cyrus-sasl-2.1.23/plugins/plugin_common.c:150:
		undefined reference to `sasl_getaddrinfo'
	e:/projects/prereq/src/cyrus-sasl-2.1.23/plugins/plugin_common.c:157:
		undefined reference to `sasl_freeaddrinfo'
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

Should be a matter of proper includes. I'll track that down tomorrow...

Regards,
Torsten
-- 
  It's more than magnificent-it's mediocre. -Samuel Goldwyn

Re: SASL GSSAPI under Win32

[Torsten K. <pyt...@tk...>]

Hi list,

> I think, I'm almost there. I have a static libsasl and several static
> plugin libs, but when I try to link one of the plugins with
> _ldap.pyd, I get:
> 
> e:\projects\prereq\built\cyrus-sasl\lib\sasl2\libcrammd5.a(plugin_common.o):
> 	In function `plug_ipfromstring':
> 	e:/projects/prereq/src/cyrus-sasl-2.1.23/plugins/plugin_common.c:150:
> 		undefined reference to `sasl_getaddrinfo'
> 	e:/projects/prereq/src/cyrus-sasl-2.1.23/plugins/plugin_common.c:157:
> 		undefined reference to `sasl_freeaddrinfo'
> collect2: ld returned 1 exit status
> error: command 'gcc' failed with exit status 1
> 
> Should be a matter of proper includes. I'll track that down
> tomorrow...

in fact, it was a bit more than just proper includes, that's why it took
me so long. ;-)

But anyway, here's a new .egg for testing:

http://svn.kmrc.de/download/distribution/contrib/python_ldap-2.3.9-py2.6-win32.egg

Good luck and best regards,
Torsten

PS: Waldemar, in case it still doesn't work: Do you have IRC, ICQ, Skype
or the like?
-- 
Happiness is a positive cash flow.

Re: SASL GSSAPI under Win32

[Michael S. <mi...@st...>]

Torsten Kurbad wrote:
>> I think, I'm almost there. I have a static libsasl and several static
>> plugin libs, but when I try to link one of the plugins with
>> _ldap.pyd, I get:
>>
>> e:\projects\prereq\built\cyrus-sasl\lib\sasl2\libcrammd5.a(plugin_common.o):
>> 	In function `plug_ipfromstring':
>> 	e:/projects/prereq/src/cyrus-sasl-2.1.23/plugins/plugin_common.c:150:
>> 		undefined reference to `sasl_getaddrinfo'
>> 	e:/projects/prereq/src/cyrus-sasl-2.1.23/plugins/plugin_common.c:157:
>> 		undefined reference to `sasl_freeaddrinfo'
>> collect2: ld returned 1 exit status
>> error: command 'gcc' failed with exit status 1
>>
>> Should be a matter of proper includes. I'll track that down
>> tomorrow...
> 
> in fact, it was a bit more than just proper includes, that's why it took
> me so long. ;-)
> 
> But anyway, here's a new .egg for testing:
> 
> http://svn.kmrc.de/download/distribution/contrib/python_ldap-2.3.9-py2.6-win32.egg

Sorry, still does not work. This is the console output:

U:\Proj\python-ldap\python-ldap\Demo>c:\Python26\python.exe sasl_bind.py
******************** CRAM-MD5 ********************
Error using SASL mechanism CRAM-MD5 {'desc': 'Success'}
******************** PLAIN ********************
Error using SASL mechanism PLAIN {'desc': 'Success'}
******************** LOGIN ********************
Error using SASL mechanism LOGIN {'desc': 'Success'}
******************** EXTERNAL ********************
Error using SASL mechanism EXTERNAL {'desc': 'Success'}
******************** GSSAPI ********************
Error using SASL mechanism GSSAPI {'desc': 'Success'}
******************** NTLM ********************
Error using SASL mechanism NTLM {'desc': 'Success'}
******************** DIGEST-MD5 ********************
Error using SASL mechanism DIGEST-MD5 {'desc': 'Success'}

BTW: You could test yourself e.g. against MS AD but take the FQDN in the LDAP
URI then.

Are there any options in cyrus-sasl to turn on debug logs? (Aargh! Tried to
use mod_auth_kerb today and the debugging also pretty much sucks with MIT
Kerberos.)

Ciao, Michael.

Re: SASL GSSAPI under Win32

[Waldemar O. <wal...@gm...>]

On Wed, Aug 19, 2009 at 11:25 AM, Torsten
Kurbad<pyt...@tk...> wrote:
> Hi list,
>

>
> But anyway, here's a new .egg for testing:
>
> http://svn.kmrc.de/download/distribution/contrib/python_ldap-2.3.9-py2.6-win32.egg
>

Unfortunately it did not work for me either but your dedication to the
cause prompted
me to test my version of the build some more :)

My build is not static anymore.  Now I put all the required *.dll(s)
into site-packages\ldap directory.
I also put the _ldap.pyd in there too so the extension can find them.
This approach work for all the dlls except the SASL plugins.

If I put the SASL plugin dlls into into "C:\CMU\bin\sasl2" then they
will be found.
In my environment only DIGEST-MD5 and NTLM got loaded but NTLM did not work.
I have got 'Authentication method not supported' error.

Now the question is, should I continue to pretend that SASL mechanisms
are supported?
Are the 2 or rather 1.5 available mechanisms worth the effort?

I hope Torsten will be successful but I feel ready to give up on SASL
support in my builds.
They never really worked out of the box anyway.

If you are depending on existing SASL support in my builds it is time
to speak up.
Unless Torsten is successful, the 2.3.9 build will not have it.

Waldemar

Re: SASL GSSAPI under Win32

[Torsten K. <pyt...@tk...>]

Hi Waldemar,

> My build is not static anymore.  Now I put all the required *.dll(s)
> into site-packages\ldap directory.
> I also put the _ldap.pyd in there too so the extension can find them.
> This approach work for all the dlls except the SASL plugins.

unfortunately, .dlls are relatively useless in conjunction with .eggs,
since there seems to be no proper way to bundle the two. That was the
reason for my static approach.

But here's my idea: I'll put up a documentation today on what I did to
get cyrus-sasl compiling successfully using MinGW.
Some minor modifications to that method should get us .dlls again
instead of static libs. When configuring the build, you can provide a
prospective location of the plugin .dlls, e.g. C:\sasl2. Perhaps that
would help to find all of the mechanisms.

If you have the time and nerves, we could do some 'conferencing' in
Google talk on the way...

Best regards,
Torsten
-- 
Never make anything simple and efficient when a way can be found to
make it complex and wonderful.              - Murphy's Law No. 13 -

Re: SASL GSSAPI under Win32

[Michael S. <mi...@st...>]

Torsten Kurbad wrote:
> But here's my idea: I'll put up a documentation today on what I did to
> get cyrus-sasl compiling successfully using MinGW.

I'd appreciate to have this in the official docs in a separate section under

http://www.python-ldap.org/doc/html/installing.html#building-and-installing

Ciao, Michael.

Re: SASL GSSAPI under Win32

[Torsten K. <pyt...@tk...>]

Hi Michael,

> I'd appreciate to have this in the official docs in a separate
> section under
> 
> http://www.python-ldap.org/doc/html/installing.html#building-and-installing

that would be great indeed.

I had very little time this morning (the internet link of our institute
was broken and I had to track down the failure). But I managed to put
some basic documentation online under

http://svn.kmrc.de/download/distribution/contrib/doc/Minimal-Cyrus-SASL-Win32-HowTo.txt

Feedback is more than welcome! :-)

Best regards,
Torsten
-- 
McDonald's -- Because you're worth it.

Re: SASL GSSAPI under Win32

[Michael S. <mi...@st...>]

Torsten Kurbad wrote:
> Hi Waldemar,
> 
>> My build is not static anymore.  Now I put all the required *.dll(s)
>> into site-packages\ldap directory.
>> I also put the _ldap.pyd in there too so the extension can find them.
>> This approach work for all the dlls except the SASL plugins.
> 
> unfortunately, .dlls are relatively useless in conjunction with .eggs,
> since there seems to be no proper way to bundle the two. That was the
> reason for my static approach.

I'm not familiar with the .egg stuff. But .egg files seem to be ZIP files.
Isn't there any chance to add the DLLs to this ZIP file?

How to make SASL libs locate the plugin DLLs would be another issue.

Ciao, Michael.

Re: SASL GSSAPI under Win32

[Michael S. <mi...@st...>]

Waldemar Osuch wrote:
> My build is not static anymore.  Now I put all the required *.dll(s)
> into site-packages\ldap directory.
> I also put the _ldap.pyd in there too so the extension can find them.
> This approach work for all the dlls except the SASL plugins.
> 
> If I put the SASL plugin dlls into into "C:\CMU\bin\sasl2" then they
> will be found.

It's the same on Linux. If you install into a non-standard localtion "make
install" outputs the following text:

********************************************************
* WARNING:
* Plugins are being installed into /opt/cyrus-sasl/lib/sasl2,
* but the library will look for them in /usr/lib/sasl2.
* You need to make sure that the plugins will eventually
* be in /usr/lib/sasl2 -- the easiest way is to make a
* symbolic link from /usr/lib/sasl2 to /opt/cyrus-sasl/lib/sasl2,
* but this may not be appropriate for your site, so this
* installation procedure won't do it for you.
*
* If you don't want to do this for some reason, you can
* set the location where the library will look for plugins
* by setting the environment variable SASL_PATH to the path
* the library should use.
********************************************************

Well, symbolic links are not an option. But how about setting the SASL_PATH
env var? We could even try to add a os.env['SASL_PATH']=... to Lib/ldap/sasl.py.

Could you please provide a ZIP file or something which contains the
python-ldap build and the SASL plugin DLLs and I will play around a little bit.


> In my environment only DIGEST-MD5 and NTLM got loaded but NTLM did not work.
> I have got 'Authentication method not supported' error.
> 
> Now the question is, should I continue to pretend that SASL mechanisms
> are supported?

If there's no way to load at least one SASL plugin it ldap.SASL_AVAIL should be 0.

> Are the 2 or rather 1.5 available mechanisms worth the effort?

DIGEST-MD5 would be worth the effort.

> Unless Torsten is successful, the 2.3.9 build will not have it.

Waldemar, I can fully understand your frustration. And I really appreciate
your and Torsten's efforts. Please let's try another round.

If setting SASL_HOME is not successful it would be a good idea to raise this
issue on the OpenLDAP and Cyrus-SASL mailing lists and request a new feature.
Cyrus SASL 2.1.24 RC1 was released to public a couple of days ago. Maybe it
would be possible to have another SASL option passed through libldap to
cyrus-sasl lib which sets the path where to locate the SASL plugins.

Ciao, Michael.

Re: SASL GSSAPI under Win32 (was: Connection to AD on windows)

[Torsten K. <pyt...@tk...>]

Hi list,

>> Im using the 2.3.9 release I got here:
>> http://svn.kmrc.de/download/distribution/contrib/

> These are .egg files built by Torsten. Not sure what he did regarding Kerberos.

Sorry for my late reply.

To be honest, I did nothing regarding Kerberos. I just compiled a very
stripped down version of cyrus-sasl (following the guide on
https://wiki.mozilla.org/LDAP_C_SDK_SASL_Windows) and then linked it
statically to the python-ldap build, leaving out all plugin DLLs.

Theoretically it should be possible to statically link in the plugin
libs, too - I'll try that tomorrow, if I find the time. Anyway, that
would just give very basic functionality like MD5, but no Kerberos,
since cyrus only builds against Heimdal or MIT, which are not (yet)
available for Windows (and most probably never will be).

Michael, can you think of any LDAP-SASL-Kerberos combination that we
still might try to build on Windows? I once tried building cyrus against
KfW from the MIT site, hoping it would share enough common code with the
"real" MIT-Kerberos, but it seems to be a completely different
codebase...

Best regards,
Torsten

Re: SASL GSSAPI under Win32

[Michael S. <mi...@st...>]

Torsten Kurbad wrote:
>>> Im using the 2.3.9 release I got here:
>>> http://svn.kmrc.de/download/distribution/contrib/
> 
>> These are .egg files built by Torsten. Not sure what he did regarding Kerberos.
> 
> Sorry for my late reply.
> 
> To be honest, I did nothing regarding Kerberos. I just compiled a very
> stripped down version of cyrus-sasl (following the guide on
> https://wiki.mozilla.org/LDAP_C_SDK_SASL_Windows) and then linked it
> statically to the python-ldap build, leaving out all plugin DLLs.

I'd strongly prefer if SASL would be either functional at least of the
password based mechs or not compiled into the Win32 builds at all.

Note that some implementations (like web2ldap) might look at the
ldap.SASL_AVAIL variable and change the behaviour accordingly.

> Theoretically it should be possible to statically link in the plugin
> libs, too - I'll try that tomorrow, if I find the time. Anyway, that
> would just give very basic functionality like MD5,

It'll be great if at least the password-based mechs would be supported. IÄd
appreciate if Waldemar and you could bring your builds in line.

> but no Kerberos, since cyrus only builds against Heimdal or MIT, which are
> not (yet) available for Windows (and most probably never will be).

There is MIT Kerberos for Windows but it uses its own ticket cache which does
not make sense at all.

> Michael, can you think of any LDAP-SASL-Kerberos combination that we
> still might try to build on Windows?

Well, this was the reason why David started his experiments with linking
against winldap.dll which makes use of the native Windows Kerberos implementation.

Ciao, Michael.

Re: SASL GSSAPI under Win32

[Michael S. <mi...@st...>]

Torsten Kurbad wrote:
> 
>> I'd appreciate to have this in the official docs in a separate
>> section under
>>
>> http://www.python-ldap.org/doc/html/installing.html#building-and-installing
> 
> that would be great indeed.
> 
> I had very little time this morning (the internet link of our institute
> was broken and I had to track down the failure). But I managed to put
> some basic documentation online under
> 
> http://svn.kmrc.de/download/distribution/contrib/doc/Minimal-Cyrus-SASL-Win32-HowTo.txt

Many thanks for this! I don't know how persistent this link will be. So do you
mind if I add this as-is to python-ldap's source distribution? In the long run
we can add this in file Doc/installing.rst.

Ciao, Michael.

Re: SASL GSSAPI under Win32

[Torsten K. <pyt...@tk...>]

Hi Michael,

> > http://svn.kmrc.de/download/distribution/contrib/doc/Minimal-Cyrus-SASL-Win32-HowTo.txt
> 
> Many thanks for this! I don't know how persistent this link will be.
> So do you mind if I add this as-is to python-ldap's source
> distribution? In the long run we can add this in file
> Doc/installing.rst.

yes, please do so.

As for the .dll inclusion in .eggs: You are right, .eggs are indeed
simply .zip files. But they are "enriched" by an internal directory and
file structure that has to be recorded during build.
There is an option (IMHO extra_data) to include .dlls and other
"extras" in a subdirectory called DATA. I didn't use that option so
far, since I'd still prefer a completely static solution.

Anyway, I'll try to build a combined solution (static libsasl2,
plugin .dlls) now. If I succeed building a static libsasl2 that loads
its plugins from the standard location, and also to include the plugin
.dlls into the .egg somehow, we could take it from there. What do you
think?

Best regards,
Torsten
-- 
Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de

Keep your boss's boss off your boss's back.