Menu
▾
▴
python-ldap-dev
|
From: Geert J. <ge...@bo...> - 2007-12-08 16:17:44
|
All, with this email I am announcing the first public release of python-ad. Python-AD is a Python client for MS Active Directory built on top of python-ldap. Amongst others it has the following features: * Automatic domain controller discovery (taking into account locality and timing) * Transparent multi-domain functionality. * Credential management. Credentials can be acquired using a username/password, username/keytab or can be loaded from the OS. Python-AD is ideal for situations where you need to manage data in AD from UNIX or Linux, such as adding users or querying printers. The software, including full documentation, can be found at: http://www.boskant.nl/trac/python-ad/ Regards, Geert Jansen |
|
From: Mike M. <mm...@wy...> - 2007-12-10 12:24:34
|
Will this initial release work on Mac OS X? If not, are there any plans in the future for Mac OS X? Thanks, Mike On Dec 8, 2007, at 11:17 AM, Geert Jansen wrote: > All, > > with this email I am announcing the first public release of python-ad. > Python-AD is a Python client for MS Active Directory built on top of > python-ldap. Amongst others it has the following features: > > * Automatic domain controller discovery (taking into account locality > and timing) > * Transparent multi-domain functionality. > * Credential management. Credentials can be acquired using a > username/password, username/keytab or can be loaded from the OS. > > Python-AD is ideal for situations where you need to manage data in AD > from UNIX or Linux, such as adding users or querying printers. > > The software, including full documentation, can be found at: > http://www.boskant.nl/trac/python-ad/ > > Regards, > Geert Jansen > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Python-LDAP-dev mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev |
|
From: Geert J. <ge...@bo...> - 2007-12-10 17:52:47
|
Mike Matz wrote: > Will this initial release work on Mac OS X? If not, are there any > plans in the future for Mac OS X? At the moment I have not tested Python-AD on OSX, but I would be happy to support it in a future version. This requires though that someone sends me patches, or that I find a way of getting access to OSX myself (I do not own a Mac). Regards Geert |
|
From: <mi...@st...> - 2007-12-10 19:50:50
|
Geert Jansen wrote: > Mike Matz wrote: >> Will this initial release work on Mac OS X? If not, are there any >> plans in the future for Mac OS X? > > At the moment I have not tested Python-AD on OSX, but I would be happy > to support it in a future version. This requires though that someone > sends me patches, or that I find a way of getting access to OSX myself > (I do not own a Mac). I saw that kinit is started as a shell sub-process. Another approach might be to use a Python wrapper module for heimdal by Univention (GPL-ed). Discussion starts here: http://www.stacken.kth.se/lists/heimdal-discuss/2007-06/msg00073.html I have a working installation (import works) but did no futher tests. Ciao, Michael. |
|
From: Geert J. <ge...@bo...> - 2007-12-10 21:29:38
|
Michael Ströder wrote: > I saw that kinit is started as a shell sub-process. Actually Python-AD comes with a C module that wraps the required Kerberos functions (see lib/ad/protocol/krb5.c). What you probably saw is the use of kinit in the test suite, where I use it to verify the credentials acquired by the C module. Regards, Geert |
|
From: <mi...@st...> - 2007-12-11 13:45:30
|
Geert Jansen wrote: > Michael Ströder wrote: > >> I saw that kinit is started as a shell sub-process. > > Actually Python-AD comes with a C module that wraps the required > Kerberos functions (see lib/ad/protocol/krb5.c). What you probably saw > is the use of kinit in the test suite, where I use it to verify the > credentials acquired by the C module. Ah, ok. Interesting. Why don't you separate the krb5 module into another project. I guess some people might be interested in that. Especially my dream would be to support HTTP-Authentication based on SPNEGO/GSSAPI in web2ldap. But not only authenticating the user at the web server. I would rather like forward the service ticket requested for a particular LDAP service to the LDAP server in a SASL/GSSAPI BindRequest. Do you think that's feasible? Ciao, Michael. |
|
From: David L. <d...@ad...> - 2007-12-11 14:08:37
|
Michael Ströder wrote: > Geert Jansen wrote: > >> Michael Ströder wrote: >> >> >>> I saw that kinit is started as a shell sub-process. >>> >> Actually Python-AD comes with a C module that wraps the required >> Kerberos functions (see lib/ad/protocol/krb5.c). What you probably saw >> is the use of kinit in the test suite, where I use it to verify the >> credentials acquired by the C module. >> > > Ah, ok. Interesting. Why don't you separate the krb5 module into another > project. I guess some people might be interested in that. > > Especially my dream would be to support HTTP-Authentication based on > SPNEGO/GSSAPI in web2ldap. But not only authenticating the user at the > web server. I would rather like forward the service ticket requested for > a particular LDAP service to the LDAP server in a SASL/GSSAPI > BindRequest. Do you think that's feasible? > there is pykerberos from http://trac.calendarserver.org/projects/calendarserver/browser/PyKerberos/ I am interested in a better GSSAPI binding for Python.. and have some incomplete code locally if anyone else is interested. To do credential forwarding, the gss is currently kind of crappy about how to extract creds portably, but if you know it's kerberos and you can set KRB5CCNAME to a temporary file you can stash a delegated TGT into a temp ccache so that SASL/GSS can find it when you talk ldap. -- David Leonard d...@ad... Ph:+61 404 844 850 |
|
From: <mi...@st...> - 2007-12-11 15:56:56
|
David Leonard wrote: > > I am interested in a better GSSAPI binding for Python.. and have some > incomplete code locally if anyone else is interested. Well, how about contributing your code to another project? Or how about creating a new project? > To do credential forwarding, the gss is currently kind of crappy about > how to extract creds portably, but if you know it's kerberos and you can > set KRB5CCNAME to a temporary file you can stash a delegated TGT into a > temp ccache so that SASL/GSS can find it when you talk ldap. Well, setting an env var is not really a good choice when running within a multi-threaded web application... :-/ Ciao, Michael. |
|
From: Geert J. <ge...@bo...> - 2007-12-11 21:28:08
|
Michael Ströder wrote: > > Well, setting an env var is not really a good choice when running within > a multi-threaded web application... :-/ > I was thinking how one could solve the problem of per-thread credentials in python-ldap (or python-ad).. I think it can be done with the keyring credential cache code that is in recent MIT Kerberos distributions. Per-thread keyrings exist so if you set $KRB5CCNAME to "KEYRING:thread:default" then you should be able to use per-thread credentials. Regards, Geert |
|
From: David L. <d...@ad...> - 2007-12-12 13:26:30
|
Geert Jansen wrote:
> Michael Ströder wrote:
>
>
>> Well, setting an env var is not really a good choice when running within
>> a multi-threaded web application... :-/
>>
>>
yet another reason to avoid threads? :)
>
> I was thinking how one could solve the problem of per-thread credentials
> in python-ldap (or python-ad).. I think it can be done with the keyring
> credential cache code that is in recent MIT Kerberos distributions.
> Per-thread keyrings exist so if you set $KRB5CCNAME to
> "KEYRING:thread:default" then you should be able to use per-thread
> credentials.
>
[A per-thread getenv() would be similarly interesting. I'm thinking like
how errno was bodged as a macro.]
Recapping the (interesting) problem: Michael wanted to pick out the
delegated creds from an SPNEGO auth'd request, convey them down to the
SASL GSSAPI auth underneath an LDAP bind. And have it all work inside a
threaded web server.
If the request handler is a python script, then you would get a separate
python process for each request, and setenving KRB5CCNAME to a temporary
cred cache file for the delegated ticket is straightforward. I know,
because I've done this. But let's say you want to be interesting and use
mod_python and have python-ldap code and sasl-gssapi running inside the
web server's thread. In this case, you might arrange for the spnego auth
to export the krb5 in-memory cred cache via an apache request note.
However, when it comes time to prepare the SASL GSSAPI environment, you
get stuck because there seems to be no way to communicate to the krb5
mechanism under sasl which cred cache to use for auth.. This is because
GSSAPI functions don't take context handles: it assumes global state for
mechanisms. Even doing the "KEYRING" trick above seems dubious to me
because the gss mechanisms might be squirreling away credential context
in global storage. If I recall correctly, some krb5 implementations of
gss are thread-clever, and might see different defaults per thread, so
they might work.
I think it would just be easier to avoid threads when using GSSAPI.
(Perhaps gss-v3 may be thread friendly?)
--
David Leonard d...@ad...
Ph:+61 404 844 850
|
|
From: <mi...@st...> - 2007-12-12 14:12:48
|
David Leonard wrote: > Geert Jansen wrote: >> Michael Ströder wrote: >>> Well, setting an env var is not really a good choice when running within >>> a multi-threaded web application... :-/ > > yet another reason to avoid threads? :) The multi-threaded approach gives me the possibility to use persistent LDAP connections. This is much faster. > Recapping the (interesting) problem: Michael wanted to pick out the > delegated creds from an SPNEGO auth'd request, convey them down to the > SASL GSSAPI auth underneath an LDAP bind. And have it all work inside a > threaded web server. Exactly. ;-) > If the request handler is a python script, then you would get a separate > python process for each request, and setenving KRB5CCNAME to a temporary > cred cache file for the delegated ticket is straightforward. This would be easy, but that's not how web2ldap works. > I know, > because I've done this. But let's say you want to be interesting and use > mod_python and have python-ldap code and sasl-gssapi running inside the > web server's thread. In this case, you might arrange for the spnego auth > to export the krb5 in-memory cred cache via an apache request note. I'd rather prefer to even extract the SPNEGO from the HTTP header within my web app since I don't need a Kerberos module for Apache then. And web2ldap runs also as a stand-alone server which is pretty handy in many situations. > However, when it comes time to prepare the SASL GSSAPI environment, you > get stuck because there seems to be no way to communicate to the krb5 > mechanism under sasl which cred cache to use for auth. Yupp. I already talked to Howard Chu about whether it's possible to change the OpenLDAP API (sasl_interactive_bind()) in this regard. > I think it would just be easier to avoid threads when using GSSAPI. :-( Ciao, Michael. |
|
From: Geert J. <ge...@bo...> - 2007-12-11 21:10:54
|
Michael Ströder wrote: > Ah, ok. Interesting. Why don't you separate the krb5 module into another > project. I guess some people might be interested in that. > > Especially my dream would be to support HTTP-Authentication based on > SPNEGO/GSSAPI in web2ldap. But not only authenticating the user at the > web server. I would rather like forward the service ticket requested for > a particular LDAP service to the LDAP server in a SASL/GSSAPI > BindRequest. Do you think that's feasible? > Well... at the moment the module is really bare bones and only exposes the few functions of the vast Kerberos API that Python-AD needs. Also I don't want to digress too much at this point. I created Python-AD as part of something bigger which does not exist yet: FreeADI. FreeADI would provide Active Directory integration for Linux systems, meaning you can use AD as the directory and authentication service on Linux. (Given the fact that Likewise Open was released last week, I am not sure though it would still be useful). >From what I understand from you though, you'd like the GSSAPI to be wrapped and not the Kerberos API. This is easier as the GSSAPI seems significantly smaller than the Kerberos API. By the way I had a look at web2ldap. You mention that you use an ASN.1 parser from Pisces and that you feel that people may have issues with its license. Python-AD comes with its own (very simple) ASN.1 parser/generator as well. It can parse arbitrary BER, emits DER and comes with a full test suite. The code is licensed under the MIT license so it may be less concerning. Also if you really want I could re-license it under the GPL. Regards, Geert |
|
From: Torsten K. <pyt...@tk...> - 2007-12-11 14:19:35
|
At Tue, 11 Dec 2007 14:45:01 +0100 Michael Str=F6der <mi...@st...> wrote: > Ah, ok. Interesting. Why don't you separate the krb5 module into > another project. I guess some people might be interested in that. ME, ME, ME!!! :o) I tried several krb5 modules lying around in the net so far - and none really worked! In fact, most of the implementations require an external kinit call, which is NOT what I intend to let my users do... So, I'd very much appreciate, if you think about Michael's idea, Geert! Regards, Torsten --=20 "Triumph without Victory, The Unreported History of the Persian Gulf War", -Headline published in the U.S. News & World Report, 1992. |
|
From: Rich M. <ric...@gm...> - 2007-12-11 15:02:54
|
Torsten Kurbad wrote: > At Tue, 11 Dec 2007 14:45:01 +0100 > Michael Ströder <mi...@st...> wrote: > > >> Ah, ok. Interesting. Why don't you separate the krb5 module into >> another project. I guess some people might be interested in that. >> > > ME, ME, ME!!! :o) > > I tried several krb5 modules lying around in the net so far - and none > really worked! In fact, most of the implementations require an external > kinit call, which is NOT what I intend to let my users do... > > So, I'd very much appreciate, if you think about Michael's idea, > Geert! > > Regards, > Torsten > You might be interested in the freeipa.org project which uses python, python-ldap, turbogears, PyKerberos, and supports http authentication with forwardable tickets. I don't think they support SPNEGO yet but patches are welcome :-) |
|
From: Noah G. <noa...@gm...> - 2007-12-11 15:25:01
|
On Dec 11, 2007, at 10:02 AM, Rich Megginson wrote: > Torsten Kurbad wrote: >> At Tue, 11 Dec 2007 14:45:01 +0100 >> Michael Str=F6der <mi...@st...> wrote: >> >> >>> Ah, ok. Interesting. Why don't you separate the krb5 module into >>> another project. I guess some people might be interested in that. >>> >> >> ME, ME, ME!!! :o) >> >> I tried several krb5 modules lying around in the net so far - and =20 >> none >> really worked! In fact, most of the implementations require an =20 >> external >> kinit call, which is NOT what I intend to let my users do... >> >> So, I'd very much appreciate, if you think about Michael's idea, >> Geert! >> >> Regards, >> Torsten >> > You might be interested in the freeipa.org project which uses python, > python-ldap, turbogears, PyKerberos, and supports http authentication > with forwardable tickets. I don't think they support SPNEGO yet but > patches are welcome :-) Rich, Have you used freeipa? I would be interested in covering this in the =20= book I am writing about Python for Systems Administration. Noah Gift > > > = ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Python-LDAP-dev mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev |
|
From: Rich M. <ric...@gm...> - 2007-12-11 15:32:25
|
Noah Gift wrote: > On Dec 11, 2007, at 10:02 AM, Rich Megginson wrote: > > >> Torsten Kurbad wrote: >> >>> At Tue, 11 Dec 2007 14:45:01 +0100 >>> Michael Ströder <mi...@st...> wrote: >>> >>> >>> >>>> Ah, ok. Interesting. Why don't you separate the krb5 module into >>>> another project. I guess some people might be interested in that. >>>> >>>> >>> ME, ME, ME!!! :o) >>> >>> I tried several krb5 modules lying around in the net so far - and >>> none >>> really worked! In fact, most of the implementations require an >>> external >>> kinit call, which is NOT what I intend to let my users do... >>> >>> So, I'd very much appreciate, if you think about Michael's idea, >>> Geert! >>> >>> Regards, >>> Torsten >>> >>> >> You might be interested in the freeipa.org project which uses python, >> python-ldap, turbogears, PyKerberos, and supports http authentication >> with forwardable tickets. I don't think they support SPNEGO yet but >> patches are welcome :-) >> > > Rich, > > Have you used freeipa? I would be interested in covering this in the > book I am writing about Python for Systems Administration. > No, I haven't used it, but I have worked on some of the directory server features it uses. > > Noah Gift > > >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> _______________________________________________ >> Python-LDAP-dev mailing list >> Pyt...@li... >> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev >> > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Python-LDAP-dev mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev > > |
|
From: Noah G. <noa...@gm...> - 2007-12-11 15:36:22
|
On Dec 11, 2007, at 10:31 AM, Rich Megginson wrote: > Noah Gift wrote: >> On Dec 11, 2007, at 10:02 AM, Rich Megginson wrote: >> >> >>> Torsten Kurbad wrote: >>> >>>> At Tue, 11 Dec 2007 14:45:01 +0100 >>>> Michael Str=F6der <mi...@st...> wrote: >>>> >>>> >>>> >>>>> Ah, ok. Interesting. Why don't you separate the krb5 module into >>>>> another project. I guess some people might be interested in that. >>>>> >>>>> >>>> ME, ME, ME!!! :o) >>>> >>>> I tried several krb5 modules lying around in the net so far - =20 >>>> and none >>>> really worked! In fact, most of the implementations require an =20 >>>> external >>>> kinit call, which is NOT what I intend to let my users do... >>>> >>>> So, I'd very much appreciate, if you think about Michael's idea, >>>> Geert! >>>> >>>> Regards, >>>> Torsten >>>> >>>> >>> You might be interested in the freeipa.org project which uses =20 >>> python, >>> python-ldap, turbogears, PyKerberos, and supports http =20 >>> authentication >>> with forwardable tickets. I don't think they support SPNEGO yet but >>> patches are welcome :-) >>> >> >> Rich, >> >> Have you used freeipa? I would be interested in covering this in =20 >> the book I am writing about Python for Systems Administration. >> > No, I haven't used it, but I have worked on some of the directory =20 > server features it uses. Red Hat is really picking up steam on creating Python Sys Admin =20 Tools. I will have to check out freeipa when I get a chance. Thanks =20= for the info. > >> >> Noah Gift >> >> >>> = ------------------------------------------------------------------------- >>> SF.Net email is sponsored by: >>> Check out the new SourceForge.net Marketplace. >>> It's the best place to buy or sell services for >>> just about anything Open Source. >>> http://sourceforge.net/services/buy/index.php >>> _______________________________________________ >>> Python-LDAP-dev mailing list >>> Pyt...@li... >>> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev >>> >> >> >> = ------------------------------------------------------------------------- >> SF.Net email is sponsored by: >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> _______________________________________________ >> Python-LDAP-dev mailing list >> Pyt...@li... >> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev >> >> > |
|
From: <mi...@st...> - 2007-12-11 18:51:32
|
Rich Megginson wrote: > You might be interested in the freeipa.org project which uses python, > python-ldap, turbogears, PyKerberos, and supports http authentication > with forwardable tickets. I don't think they support SPNEGO yet but > patches are welcome :-) Well, glancing over the code I wonder why you didn't try to contribute back some of the utility functions into python-ldap. E.g. some things like constructing a Proxy Authz Control or normalizing DNs. Note that python-ldap has a Python style license (not GPL) though. Ciao, Michael. |
|
From: Rich M. <ric...@gm...> - 2007-12-11 19:07:47
|
Michael Ströder wrote: > Rich Megginson wrote: > >> You might be interested in the freeipa.org project which uses python, >> python-ldap, turbogears, PyKerberos, and supports http authentication >> with forwardable tickets. I don't think they support SPNEGO yet but >> patches are welcome :-) >> > > Well, glancing over the code I wonder why you didn't try to contribute > back some of the utility functions into python-ldap. E.g. some things > like constructing a Proxy Authz Control or normalizing DNs. > I don't know. I haven't been working on that part. I'll let those guys know. > Note that python-ldap has a Python style license (not GPL) though. > Ok, good to know. > Ciao, Michael. > > |
|
From: <mi...@st...> - 2007-12-11 19:16:02
|
Rich Megginson wrote: > You might be interested in the freeipa.org project which uses python, > python-ldap, turbogears, PyKerberos, and supports http authentication > with forwardable tickets. > I don't think they support SPNEGO yet but patches are welcome :-) How does the browser send the ticket to the web application then? Ciao, Michael. |
|
From: Rich M. <ric...@gm...> - 2007-12-11 19:34:38
|
Michael Ströder wrote: > Rich Megginson wrote: > >> You might be interested in the freeipa.org project which uses python, >> python-ldap, turbogears, PyKerberos, and supports http authentication >> with forwardable tickets. >> I don't think they support SPNEGO yet but patches are welcome :-) >> > > How does the browser send the ticket to the web application then? > In Firefox, go to about:config In the Filter: text box, type "nego" You just have to set network.negotiate-auth.delegation-uris and network.negotiate-auth.trusted-uris to match your [domain_realm] setting in your /etc/krb5.conf. For example: network.negotiate-auth.delegation-uris: .example.com network.negotiate-auth.trusted-uris: .example.com I'm not sure but this should be documented on the freeipa.org web site, if it is not already. You also have to use Apache mod_auth_kerb, which should also be covered by freeipa.org > Ciao, Michael. > > |
|
From: <mi...@st...> - 2007-12-11 19:51:48
|
Rich Megginson wrote: > Michael Ströder wrote: >> Rich Megginson wrote: >> >>> You might be interested in the freeipa.org project which uses python, >>> python-ldap, turbogears, PyKerberos, and supports http authentication >>> with forwardable tickets. >>> I don't think they support SPNEGO yet but patches are welcome :-) >> >> How does the browser send the ticket to the web application then? >> > In Firefox, go to about:config Yes, that's what's written on the freeipa.org web site. I was more interested what's transmitted over the wire if it's not SPNEGO. Ciao, Michael. |
|
From: Rich M. <ric...@gm...> - 2007-12-11 20:21:40
|
Michael Ströder wrote: > Rich Megginson wrote: > >> Michael Ströder wrote: >> >>> Rich Megginson wrote: >>> >>> >>>> You might be interested in the freeipa.org project which uses python, >>>> python-ldap, turbogears, PyKerberos, and supports http authentication >>>> with forwardable tickets. >>>> I don't think they support SPNEGO yet but patches are welcome :-) >>>> >>> How does the browser send the ticket to the web application then? >>> >>> >> In Firefox, go to about:config >> > > Yes, that's what's written on the freeipa.org web site. I was more > interested what's transmitted over the wire if it's not SPNEGO. > I'm not really sure. One of the guys on fre...@re... would know for sure. > Ciao, Michael. > > |
|
From: Geert J. <ge...@bo...> - 2007-12-11 21:16:17
|
Torsten Kurbad wrote: > ME, ME, ME!!! :o) > > I tried several krb5 modules lying around in the net so far - and none > really worked! In fact, most of the implementations require an external > kinit call, which is NOT what I intend to let my users do... > > So, I'd very much appreciate, if you think about Michael's idea, > Geert! > What is the use case you are thinking about? As mentioned in my other email the Kerberos API is vast and while wrapping it in Python can be done (it is actually not difficult) but it is a lot of work. And after that people will want support for Heimdal, and then Windows, Mac... :-) Regards, Geert |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X