Search results for "starttls" - openldap-technical

Re: Syncrepl question

by Ivan Ordonez

Quanah Gibson-Mount wrote: > --On Friday, December 05, 2008 1:18 PM -0800 Ivan Ordonez > <iordonez(a)nature.berkeley.edu> wrote: > >> Hi Quanah, >> >> I was able to get it to work earlier when I add the startls=critical >> line. It work when I did it on the slave1, at the time, I made the >> slave1 as the master. Thanks so much for that. Now moving on the the >> real master, things did not go well. Now the issue is that, any changes >> I make on the master, doesn't go to the slaves. I have two slaves and I >> want those two to get the changes. >> >> example: >> >> Master >> | >> _ _ _ _ _| |_ _ _ _ _ >> | | >> | | >> | | >> Slave1 Slave2 >> >> Now, when I make any change on the master, the changes will take effect >> only on master and not on the slaves. I will get this error on both >> slaves. >> Is this because of the acl.bdc.readonly.conf line I have on both slave's >> slapd.conf file? pdbedit -Lv username still work only on account >> were no >> changes are made. > > Do you see any errors on the master from the slaves binding? Are you > sure they have the right permissions to the master? Did you look at > what sync logging shows? What is the contextCSN on your master versus > your slaves? > > At this point, I suggest we take this discussion back to the list, > since we got back your earlier config issue (starttls not being set in > the syncrepl config). > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration There is no binding issue from the master. I can connect to the master without issue using the command below: ldapsearch -LLL -x -H ldap://pdc.ldap.com:389 -D "cn=Replicator,ou=DSA,dc=my,dc=domain,dc=com" -s base -b "dc=my,dc=domain,dc=com" -w mypassword This is what I got from the log: init_sam_from_ldap: Entry found for user: i_test5 init_sam_from_ldap: no sambaSID or sambaSID attribute found for this user i_test5 ldapsam_getsampwnam: init_sam_from_ldap failed for user 'i_test5'! Username not found! Everytime I make any changes on an account using "pdbedit" using the master, the account is not found on the slave even if it was there before I made the change. Has anyone seen this before. I am migrating from slurpd to syncrepl. Openldap 2.3.43 Samba 3.0.33 Gentoo Linux Thanks in advance. -Ivan

15 years, 11 months

Re: 2.4.22 mirrormode syncrepl credential password encryption

by Gémes Géza

Hi, Although I use cn=config instead of slapd.conf, my setup is similar. I've created one user (e.g. cn=replicator) with global read access. Created a certificate (and private key) for that user and mapped it to the user via: olcAuthzRegexp: {0}"cn=certificate data comes here" "cn=replicator" then my replica line looks like this: olcSyncrepl: {0}rid=001 provider=ldap://firstserver bindmethod=sasl saslmech=external authcid="cn=certificate data comes here" starttls=critical tls_cert=/path/to/the/cert tls_key=/path/to/the/privatekey tls_cacert=/path/to/the/cacert tls_reqcert=demand searchbase= "dc=example,dc=com" type=refreshAndPersist retry="5 5 300 5" timeout=1 > Hi, > > I have version 2.4.22 running with mirrormode enabled and it is > working well. > > I have a question regarding the credentials field in the syncrepl part > in slapd.conf. > > Must this be cleartext or can it be encrypted and what is considered > good practise > regarding which binddn to use. (e.g. should I create a user with > cleartext password > specifically for replication?) > > Up to now I have used the same binddn as my rootdn but I can only get > this to work > with a cleartext password and I don't want to have my rootpw as > cleartext in slapd.conf. > > Here is my current slapd.conf snippet > > database bdb > suffix "dc=example,dc=com" > rootdn "cn=Manager,dc=example,dc=com" > moduleload syncprov > > overlay syncprov > syncprov-checkpoint 1 1 > syncprov-sessionlog 100 > > # Cleartext passwords, especially for the rootdn, should > # be avoid. See slappasswd(8) and slapd.conf(5) for details. > # Use of strong authentication encouraged. > rootpw secret > # The database directory MUST exist prior to running slapd AND > # should only be accessible by the slapd and slap tools. > # Mode 700 recommended. > directory /var/lib/ldap > # Indices to maintain > index objectClass eq > > syncrepl rid=123 > provider=ldap://server:389 > type=refreshAndPersist > retry="5 5 300 +" > searchbase="dc=example,dc=com" > attrs="*,+" > bindmethod=simple > binddn="cn=Manager,dc=uniscope,dc=jp" > credentials=secret > > mirrormode on > > > Any help would be appreciated. Thanks. > > ------------------------------------------------------------------------ > Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign > up now. <https://signup.live.com/signup.aspx?id=60969>

14 years, 4 months

Re: issues configuring SASL EXTERNAL and proxyauth with chain used for ppolicy_forward_updates

by Shawn McKinney

> On Apr 14, 2022, at 4:56 PM, Kartik Subbarao <subbarao(a)computer.org> wrote: > > I have a consumer server (2.4.57) that successfully forwards pwdFailureTime modifications to the master server using GSSAPI authentication. I want to replace GSSAPI with certificate-based (SASL EXTERNAL) authentication along with proxy authorization. Basically, I want to configure the equivalent of the following command line: > > LDAPTLS_KEY=server.key LDAPTLS_CERT=server.crt \ > ldapmodify -Z -Y EXTERNAL \ > -e '!authzid=dn:cn=proxydn,dc=example,dc=com' -e relax \ > -h ldap-master.example.com -f update_pwdfailuretime.ldif > > The command line works as expected -- it authenticates successfully using the server certificate, and then does PROXYAUTHZ to cn=proxydn,dc=example,dc=com to perform the modify operation. The issue is when I try to configure this behavior with chain on the consumer server. I've tried various incantations along these lines: > > chain-idassert-bind bindmethod=SASL saslmech=EXTERNAL tls_cert=server.crt tls_key=tls.key authzId=dn:cn=proxydn,dc=example,dc=com > > The SASL EXTERNAL authentication works fine -- It binds to the master with the DN mapped from the certificate's subject. But it doesn't do the proxyauthz to cn=proxydn,dc=example,dc=com. I've read through the docs in detail and tried various modes, flags and other settings, but I can't get it to do the proxy authz. > What's error in the logs? > Does anyone have a known working config for this kind of setup that they can share? Otherwise, any suggestions on the best way to troubleshoot this further would be great. Here’s a snippet from an ansible template we use for one of our tests: ```conf overlay chain chain-uri "{{ hostvars[providers | first].ldap_url }}" chain-tls start tls_cacert="{{ cacert_path }}" tls_cert="{{ config_path }}/{{ inventory_hostname }}.crt" tls_key="{{ config_path }}/{{ inventory_hostname }}.pem" tls_reqcert=demand chain-idassert-bind mode=legacy bindmethod=sasl saslmech=external binddn=cn=notused starttls=yes tls_cacert="{{ cacert_path }}" tls_cert="{{ config_path }}/{{ inventory_hostname }}.crt" tls_key="{{ config_path }}/{{ inventory_hostname }}.pem" tls_reqcert=demand ``` Other important items is the service account used as proxy must have: ```ldif … sn: service account authzTo: ldap:///ou=People,dc=example,dc=com??subtree?(objectclass=someperson) ``` Also, on the consumer: ```conf authz-regexp "cn=([^,]*),ou=Symas,o=Symas corp,l=Grand Junction,st=Colorado,c=us" "cn=$1,ou=clients,dc=example,dc=com" ``` And on the target: ```conf authz-policy to authz-regexp "cn=([^,]*),ou=Symas,o=Symas corp,l=Grand Junction,st=Colorado,c=us" "cn=$1,ou=servers,dc=example,dc=com" ``` HTH — Shawn

2 years, 7 months

RE: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)

by Paul B. Henson

> From: Quanah Gibson-Mount > Subject: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20) > > For this testing call, we particularly need folks to test OpenLDAP with > startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and with > the 1.1 series). Compiled successfully with Gentoo linux and openSSL 1.02j/cyrus-sasl 2.1.26, configured as: --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --libdir=/usr/lib64 --libexecdir=/usr/lib64/openldap --disable-static --enable-ldap --enable-slapd --enable-bdb --enable-hdb --enable-dnssrv=mod --enable-ldap=mod --enable-mdb=mod --enable-meta=mod --enable-monitor=mod --enable-null=mod --enable-passwd=mod --enable-relay=mod --enable-shell=mod --enable-sock=mod --disable-perl --disable-sql --disable-crypt --disable-slp --disable-lmpasswd --enable-syslog --enable-aci --enable-cleartext --enable-modules --enable-rewrite --enable-rlookups --enable-slapi --enable-syncprov=yes --enable-overlays=mod --enable-ipv6 --with-cyrus-sasl --enable-spasswd --disable-wrappers --with-tls=openssl --enable-dynamic --enable-local --enable-proctitle --enable-shared make test completed successfully, is there any particular way to verify all the tests were okay? Does the make itself fail if any of the tests do, I did not see a summary at the end. make its was not as happy: >>>>> Starting its4326 ... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Starting proxy slapd on TCP/IP port 9012... Using ldapsearch to check that proxy slapd is running... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ldapsearch failed (255)! ./data/regressions/its4326/its4326: line 93: kill: (28780) - No such process >>>>> ./data/regressions/its4326/its4326 failed (exit 255) I see the fix for ITS8432 is included in this release (yay); I was wondering if you've had any luck tracking down the underlying issue behind ITS8444? So far I still haven't seen any corruption or operational issues from it, but the rampant noise in the logs and errors being generated are quite disconcerting :). Plus they will potentially mask any errors that are actually indicative of a real problem. Thanks.

7 years, 9 months

Replication OpenLDAP...

by Nguyen, Quoc Khanh

Hi all, I'm setting up a Master and Slave OpenLDAP (ver. 2.4.25) use Replication method following https://help.ubuntu.com/community/OpenLDAPServer. When i used slapdcat (slapdcat -l master_dump.ldif), I got a messeage: root@ldap:/usr/local/openldap/sbin# ./slapcat -l master_dump.ldif /usr/local/openldap/etc/openldap/slapd.conf: line 89: keyword is obsolete (ignored) /usr/local/openldap/etc/openldap/slapd.conf: line 91: keyword is obsolete (ignored) bdb_db_open: warning - no DB_CONFIG file found in directory /usr/local/openldap/var/openldap-data: (2). Expect poor performance for suffix "dc=abc,dc=com". bdb_monitor_db_open: monitoring disabled; configure monitor database to enable What i'm doing wrong? Please help... My Master slapd.conf is: # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # CA signed certificate and server cert entries: TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCACertificateFile /var/myCA/cacert.crt TLSCertificateFile /var/myCA/master_ldap_crt.pem TLSCertificateKeyFile /var/myCA/master_ldap_key.pem # Use the following if client authentication is required #TLSVerifyClient demand # ... or not desired at all TLSVerifyClient never ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=abc,dc=com" rootdn "cn=rootldap,dc=abc,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw 123456789 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/openldap/var/openldap-data # Indices to maintain index objectClass eq index uid eq index cn,gn,mail eq,sub index sn eq,sub index ou eq replogfile /usr/local/openldap/var/openldap-data/replogfile replica uri="ldaps://mail1.abc.com" starttls=yes bindmethod=simple binddn="cn=rootldap,dc=abc,dc=com" credentials="123456789" My Slave slapd.conf is similar configuraion to the Master Server... *********************************** EVERYTHING HAS JUST BEGUN...

13 years, 6 months

Re: fedora and openldap

by Judith Flo Gaya

Hello Quanah, On 4/12/11 7:28 PM, Quanah Gibson-Mount wrote: > --On Tuesday, April 12, 2011 7:10 PM +0200 Judith Flo Gaya<jflo(a)imppc.org> > wrote: >> ( I installed a newer version of openldap in my server as the RH6 uses an >> old one, I compiled it with tls and openssl) >> >> From the client I do : >> ldapsearch -x -ZZ -d1 -h curri0.imppc.local:636 > This is a startTLS request. You are using LDAPS. This will never work. > > Try > > ldapsearch -x -H ldaps://curri0.imppc.local:636/ It doesn't work either, still complains about not being able to contact the server. But now I see a different error: ldapsearch -x -H ldaps://curri0.imppc.local:636 -d1 ldap_url_parse_ext(ldaps://curri0.imppc.local:636) ldap_create ldap_url_parse_ext(ldaps://curri0.imppc.local:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP curri0.imppc.local:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: could not initialize moznss using security dir /etc/openldap/cacerts - error -8174:Unknown code ___f 18. TLS: could not add the certificate (null) - error -8192:Unknown code ___f 0. TLS: error: connect - force handshake failure -1 - error -8054:Unknown code ___f 138 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) and this is what the server says: slap_listener_activate(8): >>> slap_listener(ldaps://curri0.imppc.local:636) connection_get(12): got connid=1008 connection_read(12): checking for input on id=1008 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(12): got connid=1008 connection_read(12): checking for input on id=1008 TLS trace: SSL3 alert read:fatal:bad certificate TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate. connection_read(12): TLS accept failure error=-1 id=1008, closing connection_close: conn=1008 sd=12 any clue? the error on the client side seems to indicate that the client is trying to use the nss from the mozilla but I never meant to this, openssl is installed. Thanks a lot for your help. j > instead. > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

13 years, 7 months

Re: slapd-meta and tls_reqcert=allow

by Jim Vanes

I've patched (locally) Redhat's 2.4.23-26 rpm with http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=1760501ce… and it now works as expected. Thanks again. ________________________________ From: Jim Vanes <jimvanes(a)yahoo.ca> To: Manuel Gaupp <mgaupp(a)googlemail.com> Cc: OpenLDAP <openldap-technical(a)openldap.org> Sent: Friday, February 1, 2013 10:47:58 AM Subject: Re: slapd-meta and tls_reqcert=allow Thanks! I've looked for any ITS regarding this but failed to find anything. I'll try with a newer version. ________________________________ From: Manuel Gaupp <mgaupp(a)googlemail.com> To: Jim Vanes <jimvanes(a)yahoo.ca> Cc: OpenLDAP <openldap-technical(a)openldap.org> Sent: Friday, February 1, 2013 5:59:42 AM Subject: Re: slapd-meta and tls_reqcert=allow Jim Vanes <jimvanes(a)yahoo.ca> wrote: > I'm using OpenLDAP 2.4.23-26 from Centos 6. I seem to be hitting a configuration issue regarding slapd-meta and SSL/TLS. > > Here is my meta config: > > database meta > suffix "dc=virtual,dc=local" > rootdn "cn=root,dc=virtual,dc=local" > rootpw password > > # Local > uri ldap://localhost/dc=ds1,dc=virtual,dc=local > suffixmassage "dc=ds1,dc=virtual,dc=local" "dc=lab,dc=local" > idassert-bind bindmethod=simple binddn="cn=root,dc=lab,dc=local" credentials=password > > #Remote AD server > uri ldap://10.33.63.125:389/dc=ad1,dc=virtual,dc=local > tls start > suffixmassage "dc=ad1,dc=virtual,dc=local" "dc=mslab,dc=local" > idassert-bind bindmethod=simple binddn="CN=Sync,CN=Users,DC=lab,DC=local" credentials="Password1" starttls="yes" tls_reqcert="allow" > > It seems as though tls_reqcert="allow" is ignored for the remote AD server. If set that variable in the ldap.conf everything works fine. But shouldn't the above function as an override to the default of 'demand'? The behaviour is the same when I change the above to use SSL instead. I think you're running into an issue that I reported in September 2010. See http://www.openldap.org/lists/openldap-technical/201009/msg00073.html and http://www.openldap.org/its/index.cgi?findid=6642 According to the Release Change Log, this issue should have been fixed in release 2.4.24. So you should definitely update to a more recent release. Best regards, Manuel

11 years, 9 months

Antw: Syncrepl N-Way multimaster replication - Configuration issue on Rhel6

by Ulrich Windl

>>> coma <coma.inf(a)gmail.com> schrieb am 27.11.2014 um 17:18 in Nachricht <CABnSCoknUmvmY_eJPac9mDqsWcja57b8W_1gT09VFZv0=ncFpA(a)mail.gmail.com>: > Hello everybody, > i'm currently tring to configure N-Way multimaster replication, and > i'm facing two issues with olcServerId and slapd -h options. > > For information: > I'm running on Rhel6.6 with openldap 2.4.39-8. > I'm running slapd on non-standard ports (11389 for ldap and ldap with > TLS, and 11390 for ldaps) > I've tried on standard ports but same issues. > I've configured the replication following these two procedures: > https://access.redhat.com/solutions/273533 > http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master > > - First Issue details: > > When i'm adding olcServerID's on both servers, using following ldif: > > cat <<EOF | ldapmodify -Y EXTERNAL -H ldapi:/// > dn: cn=config > changetype: modify > replace: olcServerID > olcServerID: 1 ldap://server1-test1.test.com > olcServerID: 2 ldap://server2-test1.test.com > EOF Why didn't you add the port to your URI? You should have known that with a non-default port at least your URI won't match your server's configuration. Same for ldap: vs ldaps: I guess. > > i'm no longer able to restart slapd. Error is: read_config: no > serverID / URL match found. Check slapd -h arguments. > > To resolve it, i've tried to add the URL of my servers in > correspondant /etc/sysconfig/ldapExample: > > SLAPD_LDAP=no > SLAPD_LDAPI=yes > SLAPD_LDAPS=no > SLAPD_URLS="ldap://server1-test1.test.com:11389 > ldaps://server1-test1.test.com:11390" > > But issue "Error is: read_config: no serverID / URL match found." is > always present event after a server reboot and a full openldap > reinstallationn. > > - Second issue détails (replication disabled, serverID's removed): > > With /etc/sysconfig/ldap configured as: > SLAPD_LDAP=no > SLAPD_LDAPI=yes > SLAPD_LDAPS=no > SLAPD_URLS="ldap://:11389 ldaps://:11390" > > i'm able to connect on port 11389/11390 with clear, starttls and SSL > using a ldap browser or ldapsearch, > > But with /etc/sysconfig/ldap configured as: > SLAPD_LDAP=no > SLAPD_LDAPI=yes > SLAPD_LDAPS=no > SLAPD_URLS="ldap://server1-test1.test.com:11389 > ldaps://server1-test1.test.com:11390" > > i'm not able to connect anymore. How do your certificates look like? Regards, Ulrich > > Can you please help me on this? > > Thanks in advance,

9 years, 11 months

master/slave sync stops working

by Kai Wiechers

Hi List, I have trouble with my fresh setup openLDAP Master/Slave sync. The slave stops syncing every few hours with the message shown below. If I restart the slave things start working again. I monitored the network connectivity between th hosts and there is no issue with that. Debug output running slapd -d 256 -d 128 5b23c9dc do_syncrep2: rid=001 (-1) Can't contact LDAP server 5b23c9dc do_syncrepl: rid=001 rc -1 retrying (4 retries left) /var/log/syslog Jun 15 16:14:52 ldap-server slapd[5178]: do_syncrep2: rid=001 (-1) Can't contact LDAP server Jun 15 16:14:52 ldap-server slapd[5178]: do_syncrepl: rid=001 rc -1 retrying (4 retries left) I'm running Ubuntu 16.04.4 openLDAP 2.4.42 (from Ubuntu repository) on both servers. I setup the sync using these LDIFs on the master. |dn: olcDatabase={||1||}mdb,cn=config| |changetype: modify| |delete: olcAccess| |olcAccess: {||0||}| |-| |add: olcAccess| |olcAccess: {||0||}to attrs=userPassword,shadowLastChange| | ||by dn=||"cn=admin,dc=domain,dc=com"| |write| | ||by dn=||"cn=replicator,dc=domain,dc=com"| |write| | ||by self write| | ||by anonymous auth| | ||by * none| |-| |delete: olcAccess| |olcAccess: {||2||}| |-| |add: olcAccess| |olcAccess: {||2||}to *| | ||by dn=||"cn=admin,dc=domain,dc=com"| |manage| | ||by dn=||"cn=replicator,dc=domain,dc=com"| |manage| | ||by self write| | ||by anonymous auth| | ||by users read| |dn: cn=module{||0||},cn=config| |changetype: modify| |add: olcModuleLoad| |olcModuleLoad: syncprov.la <https://confluence.2rioffice.com/display/SA/syncprov.la>| |dn: olcDatabase={||1||}mdb,cn=config| |changetype: modify| |add: olcDbIndex| |olcDbIndex: entryUUID,entryCSN eq| |dn: olcOverlay=syncprov,olcDatabase={||1||}mdb,cn=config| |changetype: add| |objectClass: olcOverlayConfig| |objectClass: olcSyncProvConfig| |olcOverlay: syncprov| On the Slave I imported these LDIFs |dn: cn=module{||0||},cn=config| |changetype: modify| |add: olcModuleLoad| |olcModuleLoad: syncprov.la <https://confluence.2rioffice.com/display/SA/syncprov.la>| |dn: olcDatabase={||1||}mdb,cn=config| |changetype: modify| |add: olcDbIndex| |olcDbIndex: entryUUID,entryCSN eq| |dn: olcDatabase={||1||}mdb,cn=config| |changetype: modify| |add: olcSyncRepl| |olcSyncRepl: rid=||001| | ||provider=ldap:||//ldap-master.domain.com/ <https://confluence.2rioffice.com/display/SA/ldap-grev-ham-de.2rioffice.com/>| | ||bindmethod=simple| | ||binddn=||"cn=replicator,dc=domain,dc=com"| | ||credentials=PASSWORD| | ||searchbase=||"dc=domain,dc=com"| | ||scope=sub| | ||schemachecking=on| | ||type=refreshAndPersist| | ||retry=||"30 5 300 3"| | ||interval=||00||:||00||:||00||:||30| | ||starttls=yes| | ||tls_reqcert=allow| I'm really new to openLDAP so please let me know how to provide additional Info if you need them. Thanks and best regards, Kai

6 years, 5 months

Problems using OpenLPAP for authentification of users: Client library issues STARTTLS but TLS is not configured

by Jörg Spilker

Hi, well, i don´t know what i´m doing wrong. I just want to authenticate unix and windows users against OpenLDAP Database. I followed some howtos to setup openldap, winbind etc. and nearly everything seems just fine. But authenticating unix users finally doesn´t work. I´ve attached the syslog output. START TLS extension not supportet. This is true, as i haven´t configured OpenLPAP for TLS. But my LDAP client configuration doesn´t specify an LDAPS URL. So what´s going wrong? Greeting, Jörg # # This is the configuration file for the LDAP nameservice # switch library, the LDAP PAM module and the shadow package. # # Your LDAP server. Must be resolvable without using LDAP. URI ldap://localhost # The distinguished name of the search base. base dc=jetsys,dc=de # The LDAP version to use (defaults to 3 # if supported by client library) ldap_version 3 # Don't try forever if the LDAP server is not reacheable bind_policy soft # The distinguished name to bind to the server with. # Optional: default is to bind anonymously. binddn cn=Manager,dc=jetsys,dc=de # The credentials to bind with. # Optional: default is no credential. bindpw XXXXXXXXX # The distinguished name to bind to the server with # if the effective user ID is root. Password is # stored in /etc/ldap.secret (mode 600) rootbinddn cn=Manager,dc=jetsys,dc=de Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 fd=23 ACCEPT from IP=127.0.0.1:15332 (IP=0.0.0.0:389) Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 op=0 do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 op=0 RESULT tag=120 err=2 text=unsupported extended operation Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 op=1 UNBIND Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 fd=23 closed Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 fd=23 ACCEPT from IP=127.0.0.1:15333 (IP=0.0.0.0:389) Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 op=0 do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 op=0 RESULT tag=120 err=2 text=unsupported extended operation Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 op=1 UNBIND Jul 9 07:32:27 xdaolin slapd[2241]: conn=703 fd=23 closed Jul 9 07:32:27 xdaolin getent: nss_ldap: could not search LDAP server - Server is unavailable

16 years, 4 months

openldap-technical search results for query "starttls"