Will any of this work with the secure 636 connection with TLS? Thats what I have to
connect using. Its not a port 389 connection. I saw this documentation before but
couldn't find anything that said it work over 636.
For further consideration, I also don't have kerberos nor do I have the availability
to install anything on a windows system that is bound to the domain, as that is forbidden.
They would have to control the system and would then not allow anything to be installed
Operating Systems Analyst/Development, Lead
Rollins School of Public Health at Emory University
From: Clément OUDOT <clem.oudot(a)gmail.com>
Sent: Friday, April 24, 2015 2:59 PM
To: Dan White
Cc: Ross, Daniel B.; openldap-technical(a)openldap.org
Subject: Re: Ldap challenge
2015-04-24 19:02 GMT+02:00 Dan White <dwhite(a)cafedemocracy.org>:
On 04/22/15 20:08 +0000, Ross, Daniel B. wrote:
> Ok I have looked a couple options but I really dont know how to accomplish
> what I need to do.
> Here is what I am trying to do.
> I have a greater organization that is stuck on using Microsoft products
> namely Microsoft LDS. To make matters worse they present the data to my
> linux servers in a completely non-standard way. Its driving my solaris
> and linux box nuts and they simply dont want to work with it.
> What i need to do is continue to use the campus usernames and passwords
> but present the Data in a format that my linux/unix hosts can use. Is
> this possible?
> i.e. userid would still be samwise but instead of a bizzarre
> OU=monkeypeople,dc=example,dc=com I want it to present as
> I looked at referral and aliasing but it does not seem to be doing what I
> am trying to do. Passthrough authentication looks close but I cant find
> sufficient documentation to actually configure a system to use it.
Pass-through is documented in section 14.5 of the Administrator's Guide:
Supporting Cyrus SASL documentation:
And /saslauthd/LDAP_SASLAUTHD within the Cyrus SASL source.
You'll find workable pass-through examples for authenticating to Exchange
in this list's archives as well as the Cyrus SASL list archives. The 'ldap'
and 'kerberos5' saslauthd backends should both be workable solutions.
you can also find a documentation on SASL delegation here: