emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] ldap.el: use auth-source if passwd is not defined in ldap-ho


From: Leonidas Tsampros
Subject: Re: [PATCH] ldap.el: use auth-source if passwd is not defined in ldap-host-parameters-list
Date: Thu, 10 Mar 2011 23:05:25 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Ted Zlatanov <address@hidden> writes:
> On Sat, 05 Mar 2011 11:16:39 +0200 Leonidas Tsampros
> <address@hidden> wrote:
>
> LT> Ted Zlatanov <address@hidden> writes:
>>> On Fri, 04 Mar 2011 22:47:20 +0200 Leonidas Tsampros
>>> <address@hidden> wrote:
>>>
> LT> Attached you can find a small patch to make ldap.el use auth-source if
> LT> passwd is not defined in the ldap-host-parameters-list.
>>>
>>> Cool!  I made some changes to it, please let me know what you think:
>>>
>>> - must pass `auth-source' set to t in the SEARCH-PLIST to activate this
>>> functionality (I don't know if you agree)
>
> LT> Agreed. It's nice not to catch users by surprise.
>
>>> - search for 'port "ldap"' entries in the netrc file (should we default
>>> to no port?)
>
> LT> This is the only part I disagree a bit. For example, my imap host is the
> LT> same with my ldap host, the credentials are the same for both services,
> LT> and both imap/ldap use the default ports. (This is a classic case of an
> LT> Exchange server I think)
>
> This makes sense, especially since ldap.el hosts can be in the format
> "server:port".  I removed the "port ldap" requirement.
>
>>> - take the password and use it
>>>
>>> - take "binddn" or "user" tokens for `binddn'
>>>
>>> - take "base" tokens for `base'
>
> LT> (Really there is no wrong direction in this. We just don't want to carry
> LT> passwords in our configuration files. :)
>
> Agreed, and that's why I've been working on auth-source.el.
>
> Try the attached patch.  If it works for you I'll push it into the
> trunk.  Let me know if I need to update any other documentation besides
> the docstring.  It looks like only Chong Yidong has made significant
> changes to ldap.el since 2005 so I'm not CC-ing the original author.
>
> Thanks
> Ted
>

Hi Ted,

sorry for the late reply but here are my findings after applying your
patch:

1) authinfo machine ip-address login username password secret-key imap

and (setq ldap-host-parameters-alist
      (quote (("ip-address" base "dc=domain,dc=com"
               binddn "domain\\username" "auth-source "yes"))))

Logging in to both the LDAP and the IMAP server works as expected (on
the assumption that they are the same hosts, and this is my personal
setup, so I'm pretty happy.

2) authinfo machine ip-address login username password secret-key imap
   authinfo machine ip-address binddn domain\username password secret-key port 
ldap

and (setq ldap-host-parameters-alist
      (quote (("ip-address" base "dc=domain,dc=com"
               auth-source "yes"))))

The above is the more general case of having a separate LDAP
server. This case doesn't work, since auth-source-search returns the
first entry and so (plist-get asfound :binddin) returns nothing.

In order to work around this case, I thought of the following:

3) authinfo machine ip-address login username password secret-key imap
   authinfo machine ip-address:389 binddn domain\username password secret-key

and (setq ldap-host-parameters-alist
      (quote (("ip-address:389" base "dc=domain,dc=com"
               auth-source "yes"))))

which should work as expected but I think it breaks eudc-ldap. The
module seems trying to match only the 'ip-address' part of the
ldap-host-parameters-alist entry and as such a check to see if a base dn
is defined fails. However I want to double check this again.

Anyway, since we have the auth-source switch to enable this explicitly,
I think you can commit this pretty safely and then figure out how to
move with case 2) and 3), as I don't think that it breaks any
functionality.

I will try to give it a shot too, in case I come up with a plan.

Thanks for the patch and the effort, and please correct me if I have
misunderstood the user scenarios that we would like to support wrt to
ldap configuration.

Best Regards,
Leonidas Tsampros



reply via email to

[Prev in Thread] Current Thread [Next in Thread]