openldap-technical

openldap-technical@openldap.org

21 participants
9787 discussions

problem with syncrepl and STARTTLS
by r0m5 02 Jun '17

02 Jun '17

Hello, I am facing an issue with syncrepl and STARTTLS on 389 port. The kind of problem happening only sometimes, and disappearing "by itself". I use Debian Jessie, OpenLDAP 2.4.40+dfsg-1+deb8u2. Description : I have a production environment, and a preproduction environment. Both of them consist of one provider and multiple consumers. Right now all is working fine. Then 2 times a days a script injects the production data in the preproduction environment : ldapsearch on prod / ldapdelete on preprod / stop slapd on preprod / slapadd on preprod / start slapd on preprod. Then sometimes during this injection I get a problem : one or more of the consumers in preprod fail to sync. But sometimes all are OK. Then the consumers facing the issue succeed syncrepl again "by themselves" after a few dozens of minutes / hours. If I restart slapd on the failing consumers, then the syncrepl succeeds immediately. When the syncrepl is failing, I can still perform an ldapsearch using STARTTLS and the syncrepl binding credentials from the consumer to the provider. There is no issue with non-TLS LDAP replications. Also, using ldapsearch with option "-d 3" I get TLS debug, but even with "olcLogLevel -1" in cn=config I can't get precise debug for TLS during syncrepl. I captured the trafic and when there is the error, wireshark at some point can't understand TLS sent by the consumer (SSL "ignored unknown record"). Corresponding data is "30 05 02 01 02 42 00". Not sure it's related to the problem though, but it looks like since (if I am right) the first information in TLS is the content-type, and 30 is not a valid value for content type (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-pa…). Any idea ? I would like to avoid making the injection script connect to all my preprod consumers and restart slapd on them. Please feel free to ask for more logs / configurations. Log on the provider : May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: slap_listener_activate(9): May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 busy May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: >>> slap_listener(ldap:///) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: listen=9, new connection on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: added 18r (active) listener=(nil) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 fd=18 ACCEPT from IP=192.168.115.61:33816 (IP=0.0.0.0:389) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18): got connid=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): checking for input on id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: op tag 0x77, time 1496231248 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0 do_extended May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0 EXT oid=1.3.6.1.4.1.1466.20037 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: do_extended: oid=1.3.6.1.4.1.1466.20037 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0 STARTTLS May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: send_ldap_extended: err=0 oid= len=0 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: send_ldap_response: msgid=1 tag=120 err=0 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0 RESULT oid= err=0 text= May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18): got connid=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): checking for input on id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18): got connid=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): checking for input on id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): unable to get TLS client DN, error=49 id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 fd=18 TLS established tls_ssf=128 ssf=128 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 2 descriptors May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18): got connid=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): checking for input on id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: ber_get_next on fd 18 failed errno=0 (Success) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): input error=-2 id=1010, closing. May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_closing: readying conn=1010 sd=18 for close May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_close: conn=1010 sd=18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: removing 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 fd=18 closed (connection lost) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero Log on the consumer : May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: =>do_syncrepl rid=006 May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: slap_client_connect: URI=ldap://ldap-master-pp.acme Error, ldap_start_tls failed (-11) May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: do_syncrepl: rid=006 rc -11 retrying May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=11 active_threads=0 tvp=zero syncrepl config on consumer : olcSyncrepl: {0}rid=6 provider=ldap://ldap-master-pp.acme starttls=critical t ls_reqcert=never bindmethod=simple binddn="cn=replication,ou=Applications,d c=acme,dc=fr" credentials=**** searchbase="dc=acme,dc=fr" schemacheck ing=off type=refreshAndPersist filter="(objectClass=*)" attrs="*" scope=sub retry="60 +" TLS config on provider : dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 9efabaca-b31f-1036-9746-2d4f8feb88f1 creatorsName: cn=config createTimestamp: 20170411162820Z olcTLSCertificateFile: /etc/ssl/certs/ssl-cert-snakeoil.pem olcTLSCertificateKeyFile: /etc/ssl/private/ssl-cert-snakeoil.key olcLogLevel: 256 entryCSN: 20170531131949.877388Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170531131949Z

1 0

How wold you go about writing a new OpenLDAP backend?
by John Lewis 31 May '17

31 May '17

What if I wanted to write a OpenLDAP backend for a systemd journal file or Elasticsearch so I can present my logs as an LDAP subtree so I can use my LDAP tools to filter my logs? Should I use back-shell for prototyping? If so, what is the usual work flow?

2 1

OpenLDAP / Active directory cohabitation
by Alexandre Rosenberg 31 May '17

31 May '17

Hello, I am in a environment where we use both OpenLDAP and Active Directory. All Linux servers authenticate against OpenLDAP where we have user group, unix group (...) I would like to keep everything the same except that when the user bind to OpenLDAP the credential should be checked against Active Directory. There is no need to retrieve/return any information from Active Directory except for the authentication. This means that if perform a BIND and a search, the BIND should be performed against the AD but the search result should from OpenLDAP. (anonymous search is fine) One complication is that we have 2 times of usernames: short username: john01 long username: john.smith(a)example.com The short username are used in in OpenLDAP like this: uid=john01,ou=People,dc=example,dc=com While the AD uses the long username. From my test when binding to AD, only the "DN" is simply set to the username. john.smith(a)example.com I am starting to seriously look at the various OpenLDAP overlay and proxy functionality but I am a bit confused on how to archive this. Best regards, Alexandre

5 4

Re: SIGPIPE on OS X fix still pending (ITS#8590)
by Quanah Gibson-Mount 31 May '17

31 May '17

--On Wednesday, May 31, 2017 12:11 PM +0100 Lorenz Bauer <lmb(a)cloudflare.com> wrote: > Hello Quanah, > > On 26 May 2017 at 20:36, Quanah Gibson-Mount <quanah(a)symas.com> wrote: >> Generally, we need secondary confirmation on the patch. > > That makes sense. I've written a test program which exercises the > different ways of generating SIGPIPE, available at [1]. This should > make verifying the patch easier. I'll also update the ITS. > > Best, > Lorenz > > 1: https://gist.github.com/lmb/a35e7b9566fa79e7bf971ac21bbb9efb Thanks, I will discuss with the rest of the team about getting this integrated into the LMDB test suite. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Migration from ApacheDS to OpenLDAP
by Hongfu Huang 31 May '17

31 May '17

Hi all, Is there an easy way to migrate an ApacheDS to an OpenLDAP? Can just export everything in an ldif file from ApacheDS and then import it into an OpenLDAP? Or what should I definitely take care of here? For example, the schema mapping? Should I create a separate DIT(DBs) in OpenLDAP for each partition in ApacheDS? Thanks for any suggestions! Regards Hongfu -- Hongfu Huang, Senior System Integrator M.Sc. Computer Science AdNovum Informatik AG Roentgenstrasse 22, 8005 Zurich, Switzerland phone +41 44 272 6111, direct +41 44 270 5266 hongfu.huang(a)adnovum.ch, www.adnovum.ch Locations: Zurich (HQ), Bern, Lausanne, Budapest, Ho Chi Minh City, Singapore

3 2

Re: How wold you go about writing a new OpenLDAP backend?
by Howard Chu 31 May '17

31 May '17

Michael Ströder wrote: > Howard Chu wrote: >> John Lewis wrote: >>> What if I wanted to write a OpenLDAP backend for a systemd journal file >>> or Elasticsearch so I can present my logs as an LDAP subtree so I can >>> use my LDAP tools to filter my logs? Should I use back-shell for >>> prototyping? If so, what is the usual work flow? >> >> back-shell might work for rough prototyping. back-sock would be more reasonable these >> days. > > For prototyping a back-sock listener in Python you could give module slapdsock a try: > > https://pypi.python.org/pypi/slapdsock > > Personally I use it for OATH-LDAP's bind listeners which seem to work fairly robust on > moderate load. But the release 0.5.2 should also work with all other request types. > > If you have a non-trivial deployment the sheer amount of log data can cause some > interesting performance issues. Indeed. Still it's an interesting idea; I've often thought about writing an ElasticSearch replacement on top of OpenLDAP. In a native backend it would be orders of magnitude faster than their stuff. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 2

Re: How wold you go about writing a new OpenLDAP backend?
by Howard Chu 31 May '17

31 May '17

John Lewis wrote: > What if I wanted to write a OpenLDAP backend for a systemd journal file > or Elasticsearch so I can present my logs as an LDAP subtree so I can > use my LDAP tools to filter my logs? Should I use back-shell for > prototyping? If so, what is the usual work flow? back-shell might work for rough prototyping. back-sock would be more reasonable these days. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: SIGPIPE on OS X fix still pending (ITS#8590)
by Lorenz Bauer 31 May '17

31 May '17

Hello Quanah, On 26 May 2017 at 20:36, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > Generally, we need secondary confirmation on the patch. That makes sense. I've written a test program which exercises the different ways of generating SIGPIPE, available at [1]. This should make verifying the patch easier. I'll also update the ITS. Best, Lorenz 1: https://gist.github.com/lmb/a35e7b9566fa79e7bf971ac21bbb9efb -- Lorenz Bauer | Systems Engineer 25 Lavington St., London SE1 0NZ www.cloudflare.com

1 0

Re: Re: OpenLDAP / Active directory cohabitation
by Clément OUDOT 30 May '17

30 May '17

2017-05-30 8:10 GMT+02:00 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de>: > I have one question: Why is hte AD admin accound needed to authenticate? I see > a problem with the AD admin password being stored in cleartext in the saslauthd > configuration... You don't need AD admin password, you just need a standard AD account that can read user entries (no write access required). Clément.

1 0

Re: Antw: Re: OpenLDAP / Active directory cohabitation
by Dan White 30 May '17

30 May '17

On 05/30/17 08:10 +0200, Ulrich Windl wrote: >>>> Clément OUDOT <clem.oudot(a)gmail.com> schrieb am 29.05.2017 um 20:43 in >Nachricht ><CAK_oV4-DYo6d=LgWnu7foGkYQ4n9mjHiDbmo1t9uGyJT5e8EFQ(a)mail.gmail.com>: >> 2017-05-29 19:00 GMT+02:00 Dan White <dwhite(a)cafedemocracy.org>: >>> On 05/29/17 23:36 +0900, Alexandre Rosenberg wrote: >>>> >>>> I am in a environment where we use both OpenLDAP and Active Directory. >>>> All Linux servers authenticate against OpenLDAP where we have user group, >>>> unix group (...) >>> >>> Pass-through authentication should work if you're performing simple binds. >>> Chapter 14 of the admin guide has a good example. >> >> You can also find a tutorial here: >> https://ltb-project.org/documentation/general/sasl_delegation > >I have one question: Why is hte AD admin accound needed to authenticate? I see >a problem with the AD admin password being stored in cleartext in the saslauthd >configuration... Here's a simpler approach that does not require storing a password: https://www.openldap.org/lists/openldap-technical/201106/msg00198.html This was tested against AD 2003. You may need to use ldaps with newer versions. -- Dan White

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical