Search results for "starttls" - openldap-technical

Slapd process randomly hangs on consumers and comes back to life after a while with no intervention

by Pierre-Jean CROUZET

Hello, To start with, this is my very first post on a mailing list of this kind. I've read much about how to do things right, like here: https://www.openldap.org/doc/admin24/troubleshooting.html or here: https://www.openldap.org/faq/data/cache/59.html Nonetheless, please do tell me if I'm not following the standards. I'm facing an issue with my OpenLDAP servers that I struggle to fix or even find info about. To summarize: We have an architecture of 2 providers with mirror mode replication for their configuration. They are LXC's hosted in a datacenter. We have 2 consumers with mirror mode replication for their config also, and they get the DB (mdb backend) from the above providers. They are VMs hosted in a different hypervisor and datacenter than the providers. We have a loadbalancing architecture in front that sends requests evenly to the 4 servers. The writes requests directed to the consumers are forwarded to the providers using the chain overlay. The slapd process of those 2 consumers randomly hangs. When it happens, the slapd service is still running and listening, but not a single query can go through, even the logging stops. Like a complete freeze. The service comes back to life after some time (several minutes, different every time) without any manual intervention. Trying to manually restart the process during such even obviously fails, unless I kill -9, which is not something I want to do. My observations so far : - The hangs appear only during business hours (nothing during nights or week-end). - Only the consumers hang. The providers are always fine. - CPU / RAM / Disks are fine before / during the crashes. - The hangs seem random and I could not find a way to trigger them at will. - strace shows the following lines in an infinite loop during hangs. ``` [pid 1082] gettimeofday({tv_sec=1726669191, tv_usec=694473}, NULL) = 0 [pid 1082] poll([{fd=18, events=POLLIN|POLLPRI}], 1, 100) = 0 (Timeout) [pid 1082] sched_yield() ``` It seems that the process is waiting for some data that never comes. The fd=18 is referencing to a TCP socket connected to provider1. So it would suggests that the provider is not sending what the consumer wants. This has led me to several suppositions: 1. Network issues Unlikely, since only those 2 servers in the DC are experiencing misbehavior, and I can telnet / ldapsearch from the faulty consumer to the provider with no problem during hangs. 2. Syncrepl / slapo-chain misconfiguration I might have a configuration problem, but no matter how much I review it, I don't see what's wrong. I've provided the syncrepl / slapo-chain conf in the config.ldif attachment. I've also provided several other attachments that I thought would be helpful: - log.txt => The slapd logs in trace level that show the last bind before the service hangs. - ldaps_request.log => An ldapsearch performed against the faulty consumer during hang. - starttls_request.log => Same as above, but using StartTLS => the connection seems successful and stops at the server hello TLS exchange. Versions : - slapd: 2.5.18 LTS - Server: Ubuntu 22.04 LTS I am a bit out of ideas on things I could try to fix the issues. Hence this email. I thank you for your time and I am very grateful for any help you could give me. Regards, Pierre-Jean

8 months, 3 weeks

Re: top-level data entries not replicating, 2.4.15

by Jonathan Clarke

On 24/08/2009 14:16, Jonathan Clarke wrote: > On 20/08/2009 14:39, Brian Neu wrote: >> Forgive me if pasting here is bad etiquette. >> >> >> <consumer slapd.conf> >> >> include /etc/openldap/schema/corba.schema >> include /etc/openldap/schema/core.schema >> include /etc/openldap/schema/cosine.schema >> include /etc/openldap/schema/duaconf.schema >> include /etc/openldap/schema/dyngroup.schema >> include /etc/openldap/schema/inetorgperson.schema >> include /etc/openldap/schema/java.schema >> include /etc/openldap/schema/misc.schema >> include /etc/openldap/schema/nis.schema >> include /etc/openldap/schema/openldap.schema >> include /etc/openldap/schema/ppolicy.schema >> include /etc/openldap/schema/collective.schema >> include /etc/openldap/schema/samba.schema >> >> allow bind_v2 >> >> pidfile /var/run/openldap/slapd.pid >> argsfile /var/run/openldap/slapd.args >> >> TLSCACertificateFile /etc/openldap/cacerts/cavictory2.crt >> TLSCertificateFile /etc/openldap/keys/victory3cert.pem >> TLSCertificateKeyFile /etc/openldap/keys/victory3key.pem >> >> database hdb >> suffix "dc=srg,dc=com" >> checkpoint 1024 15 >> rootdn "cn=Manager,dc=srg,dc=com" >> >> rootpw {MD5}blah >> >> directory /var/lib/ldap >> >> index objectClass eq,pres >> index ou,cn,mail,surname,givenname eq,pres,sub >> index uidNumber,gidNumber,loginShell eq,pres >> index uid,memberUid eq,pres,sub >> index nisMapName,nisMapEntry eq,pres,sub >> >> syncrepl rid=0 >> provider=ldap://victory2.srg.com:389 >> bindmethod=simple >> starttls=critical >> binddn="cn=replicator,dc=srg,dc=com" >> credentials=blah >> searchbase="dc=srg,dc=com" >> logbase="cn=accesslog" >> schemachecking=on >> type=refreshAndPersist >> retry="60 +" >> syncdata=accesslog > > I don't see anything wrong with this - although I'm not very familiar > with accesslog configuration. > > Does the "cn=replicator,dc=srg,dc=com" have full access on the provider > to read necessary data? Please ignore this post - I hadn't seen that the discussion continued already. My mailer displayed it in a separate post, got me confused on a Monday morning :/

15 years, 9 months

back-ldap and ldaps not working

by Jon C Kidder

I have the following attributes set in my ldap backend for the chain overlay. olcDbURI: "ldaps://ds2-q.global.aep.com:636" olcDbStartTLS: ldaps starttls=no tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer" tls_reqcert=demand tls_crlcheck=none The referenced file is the exact same file I use in this global attribute olcTLSCACertificateFile: /appl/openldap/etc/openldap/tls/cacerts.cer This is a 2.4.44 replication consumer using the following replication attribute olcSyncrepl: {1}rid=112 provider=ldaps://ds2-q.global.aep.com:636 binddn="cn=syncuser,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com" bindmethod=simple credentials=<redacted> searchbase="dc=Global,dc=aep,dc=com" type=refreshAndPersist retry="5 5 300 +" timeout=1 Replication works perfectly and changes to the referenced master are replicated to this slave. I can see successful connections for rid=112 to this master in the log. The problem is when the chain overlay tries to follow referrals to this same master I get the following error: 595fbb1c conn=1000 op=1 ldap_chain_op: ref="ldaps://ds2-q.global.aep.com:636/uid=s012235,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com" -> "ldaps://ds2-q.global.aep.com:636" 595fbb1c conn=1000 op=1 ldap_chain_op: ref="ldaps://ds2-q.global.aep.com:636/uid=s012235,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com": URI="ldaps://ds2-q.global.aep.com:636" found in cache ldap_create ldap_url_parse_ext(ldaps://ds2-q.global.aep.com:636) 595fbb1c =>ldap_back_getconn: conn=1000 op=1: lc=0x10180430 inserted refcnt=1 rc=0 ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ds2-q.global.aep.com:636 ldap_new_socket: 16 ldap_prepare_socket: 16 ldap_connect_to_host: Trying 10.92.127.52:636 ldap_pvt_connect: fd: 16 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=US/ST=Ohio/L=Columbus/O=American Electric Power/OU=Complex - Middleware/CN=AEP Root CA (2014)/emailAddress=middleware(a)aep.com, issuer: /C=US/ST=Ohio/L=Columbus/O=American Electric Power/OU=Complex - Middleware/CN=AEP Root CA (2014)/emailAddress=middleware(a)aep.com TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in error TLS trace: SSL_connect:error in error TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain). 595fbb1c send_ldap_result: conn=1000 op=1 p=3 595fbb1c send_ldap_result: conn=1000 op=1 p=3 595fbb1c send_ldap_response: msgid=2 tag=103 err=52 ber_flush2: 14 bytes to sd 15 595fbb1c conn=1000 op=1 RESULT tag=103 err=52 text= So, is there something wrong with the value of the olcDBStartTLS attribute that I'm not seeing?? -Jon C. Kidder American Electric Power Complex - Middleware Engineering

7 years, 11 months

supportedSASLMechanisms not Work in Debian Lenny

by Jarbas Peixoto Júnior

I have two servers: * Server A: Debian Etch - Works Fine * Server B: Debian Lenny - Do not Works supportedSASLMechanisms EXTERNAL In Server A I have: # ldapsearch -v -H ldap://server-Etch -b "" -LLL -s base supportedSASLMechanisms -ZZ ldap_initialize( ldap://server-Etch ) SASL/EXTERNAL authentication started SASL username: emailAddress=jarbas.peixoto(a)previdencia.gov.br,CN=jarbas.peixoto,OU=DATAPREV,O=Previdencia Social,L=Campo Grande,ST=Mato Grosso do Sul,C=BR SASL SSF: 0 filter: (objectclass=*) requesting: supportedSASLMechanisms dn: supportedSASLMechanisms: PLAIN supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: NTLM supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: EXTERNAL In Server B I have: # ldapsearch -v -H ldap://server-Lenny -b "" -LLL -s base supportedSASLMechanisms -ZZ ldap_initialize( ldap://server-Lenny:389/??base ) ldap_start_tls: Connect error (-11 # ldapsearch -v -H ldap://server-Lenny -b "" -LLL -s base supportedSASLMechanisms -ZZ -d 1 ldap_url_parse_ext(ldap://server-Lenny) ldap_create ldap_url_parse_ext(ldap://server-Lenny:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP server-Lenny:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.82.0.234:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x9d73280 msgid 1 wait4msg ld 0x9d73280 msgid 1 (infinite timeout) wait4msg continue ld 0x9d73280 msgid 1 all 1 ** ld 0x9d73280 Connections: * host: www-mmldap port: 389 (default) refcnt: 2 status: Connected last used: Thu Jan 29 18:17:22 2009 ** ld 0x9d73280 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x9d73280 request count 1 (abandoned 0) ** ld 0x9d73280 Response Queue: Empty ld 0x9d73280 response count 0 ldap_chkResponseList ld 0x9d73280 msgid 1 all 1 ldap_chkResponseList returns ld 0x9d73280 NULL ldap_int_select read1msg: ld 0x9d73280 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x9d73280 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x9d73280 0 new referrals read1msg: mark request completed, ld 0x9d73280 msgid 1 request done: ld 0x9d73280 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_start_tls: Connect error (-11) In the /var/log/syslog I have: Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 fd=21 ACCEPT from IP=10.82.0.234:50441 (IP=0.0.0.0:389) Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 STARTTLS Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 RESULT oid= err=0 text= Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 fd=21 closed (TLS negotiation failure) This is very important for use openldap with user certificates. Anybody have a help for me? Tanks!

16 years, 4 months

Proxycache overlay to back-ldap with cn=config

by Nicolas Brisac

Hi, I'm trying to set up a proxy-cache to a couple of OpenLDAP servers configured in mirror mode. The back-ldap part is working fine and I can query the underlying slapd instances through the proxy. However, I'm still struggling with the caching bit. I couldn't find any documentation or posts related to setting this up using the new cn=config way of configuring LDAP. So after some reading and a bit of guessing, I came up with the following config: # {1}ldap, config dn: olcDatabase={1}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {1}ldap olcSuffix: dc=sol1,dc=net olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=Subschema" by * read olcAccess: {2}to * by self write by users read by anonymous auth olcRootDN: uid=ldapadmin,dc=sol1,dc=net olcRootPW: secret olcDbURI: "ldap://192.168.200.12 ldap://192.168.200.14" olcDbACLBind: bindmethod=simple binddn="uid=ldapadmin,dc=sol1,dc=net" credentials="secret" starttls=no # {0}pcache, {1}ldap, config dn: olcOverlay={0}pcache,olcDatabase={1}ldap,cn=config objectClass: olcOverlayConfig objectClass: olcPcacheConfig olcOverlay: {0}pcache olcPcache: bdb 10000 3 1000 100 olcPcacheAttrset: 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass olcPcacheAttrset: 1 sudoCommand sudoHost olcPcacheAttrset: 2 gidNumber olcPcacheTemplate: (&(objectClass=)(uid=)) 0 300 olcPcacheTemplate: (sudoUser=) 1 300 olcPcacheTemplate: (&(objectClass=)(memberUid=)) 2 300 # {2}bdb, config dn: olcDatabase={2}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {2}bdb olcDbDirectory: /var/lib/ldap/cache olcSuffix: cn=proxy olcRootDN: uid=ldapadmin,dc=sol1,dc=net olcDbCacheSize: 5000 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: uid eq olcDbIndex: cn eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: memberUid eq olcDbIndex: uniqueMember eq olcDbIndex: mail eq olcDbIndex: surname eq olcDbIndex: givenname eq olcDbIndex: sambaSID eq olcDbIndex: sambaPrimaryGroupSID eq olcDbIndex: sambaDomainName eq olcDbIndex: sudoUser eq But running ldapsearch keeps returning: # search result search: 2 result: 52 Server is unavailable text: pcachePrivDB: cacheDB not available I didn't find any way to specify which database to use when declaring the overlay, apart from the 'bdb' part of olcPcache, but that seems to be interpreted as the database type, not its name (I've tried replacing it with cn=proxy, but that throws an error). Looking at the pcache overlay source (I'm running 2.4.21 from Ubuntu Lucid and also checked the latest 2.4.23 stable source), I can see this bit: { "pcache-", "private database args", 1, 0, STRLENOF("pcache-"), ARG_MAGIC|PC_PRIVATE_DB, pc_cf_gen, NULL, NULL, NULL }, That seems to be for the private DB options, but the other equivalent "pcacheXXXX" in this file have the corresponding attribute declaration for the schema instead of 'NULL, NULL, NULL'. Anyway, I'm obviously missing something :) If someone who's got this working or a developer could point me in the right direction, that would be greatly appreciated! Thanks, Nico

14 years, 10 months

Re: data import very slow for data migration

by anil beniwal

Hi Please ignore me previous mail. 1. There are too many errors like above. Ans:-We are having some 48 files of 500 M each and no of such errors on each files on average are 15-20 2 increase cachesize to at least 4GB that is set_cachesize 4 0 1 Ans:- i have done this in DB_CONFIG file set_cachesize 0 4294967295 0 it showing in db_stats as 3GB 1023M 1023K Please let me know if its wrong and how and where i should modify this. 3.checkpoint 128 15 I would set checkpointing to 0 15 Ans:- Its for only data import or after data import also. 4. Please not that overlay declarations follow all database declarations, modify slapd.conf accordingly. Ans:- We are using static config file for all configuration, i didn't get how it matters declaration of overlays, can i specify just after schema declaration. Thanks a lot, it gives me some better insight. On Wed, Dec 26, 2012 at 9:58 AM, anil beniwal <beni.anil(a)gmail.com> wrote: > Hi > > I didn't get it. > > Can you please elaborate it a bit. It would be great help for me. > > > > > On Wed, Dec 26, 2012 at 2:37 AM, Dieter Klünter <dieter(a)dkluenter.de>wrote: > >> Am Tue, 25 Dec 2012 21:27:39 +0530 >> schrieb anil beniwal <beni.anil(a)gmail.com>: >> >> > Hi >> > >> > We are having 4 million users to migrate, all data exported from >> > oracle to multiple ldif files. >> > Imported 1 million till now, took almost 28 hours. and openldap-data >> > dir of about 28G. >> > openldap version 2.4.33 bdb version 5.1.29 RHEL 6.3 RAM 8G 4 cpu , >> > system is a VM. >> > >> > Currently running slapadd output >> > + /apps/openldap/sbin/slapadd -q -c -w -f >> > /apps/openldap/etc/openldap/slapd.conf -l /root/User9.ldif >> > bdb_monitor_db_open: monitoring disabled; configure monitor database >> > to enable >> > . 2.27% eta 21h31m elapsed 29m57s >> > spd 1.6 k/s str2entry: invalid value for attributeType >> > postalAddress #0 (syntax 1.3.6.1.4.1.1466.115.121.1.41) >> > slapadd: could not parse entry (line=394416) >> > * 2.81% eta 19h59m elapsed 34m40s spd >> > 10.1 k/s >> >> 1. There are too many errors like above. >> >> > Its seems to be taking weeks go import whole data. >> >> It takes about 2 - 4 hours in order to slapadd 4 mio.entires, depending >> on file system and disk type. >> > >> > is there any tool or any other approach which we can use to make it >> > fast,Or we are going with wrong configuration. >> > Or we have to switch to ODS or RHDS >> >> There is no necessity for other tools, just modify the ldif file. >> >> [...] >> > DB_CONFIG >> > >> > set_cachesize 0 4294967295 0 >> >> increase cachesize to at least 4GB that is >> set_cachesize 4 0 1 >> >> [...] >> > checkpoint 128 15 >> >> I would set checkpointing to 0 15 >> [...] >> >> > concurrency 100 >> > index entryCSN eq >> > index entryUUID eq >> > index >> > >> mail,uid,postalCode,smail,channelType,channelValue,answer,behavName,objectclass,tokenID,type >> > eq >> > index givenName,sn,city,question,behavValue,cn,extName sub >> > index displayName approx >> > # Replication Configuration >> > overlay syncprov >> > syncprov-checkpoint 100 10 >> > syncprov-sessionlog 100 >> > >> > serverid 1 >> > >> > syncrepl rid=111 >> > provider=ldap://s01.com >> > binddn="cn=Manager,dc=example,dc=com" >> > bindmethod=simple >> > starttls=yes >> > tls_reqcert=allow >> > schemachecking=off >> > credentials=G00gle# >> > searchbase="dc=example,dc=com" >> > type=refreshAndPersist >> > retry="5 5 300 +" >> > interval=00:00:00:10 >> > >> > syncrepl rid=222 >> > provider=ldap://m04.com >> > binddn="cn=Manager,dc=example,dc=com" >> > bindmethod=simple >> > starttls=yes >> > tls_reqcert=allow >> > schemachecking=off >> > credentials=G00gle# >> > searchbase="dc=example,dc=com" >> > type=refreshAndPersist >> > retry="5 5 300 +" >> > interval=00:00:00:10 >> > >> > ###### >> > >> > mirrormode TRUE >> > >> > directory /apps/openldap/var/openldap-data >> > >> > overlay unique >> > unique_attributes mail >> > >> > overlay ppolicy >> > ppolicy_default "cn=default,ou=pwdPolicy,dc=example,dc=com" >> > ppolicy_use_lockout >> >> Please not that overlay declarations follow all database declarations, >> modify slapd.conf accordingly. >> >> -Dieter >> >> -- >> Dieter Klünter | Systemberatung >> http://dkluenter.de >> GPG Key ID:DA147B05 >> 53°37'09,95"N >> 10°08'02,42"E >> >> > > > -- > > Thanks&Regards > Anil Beniwal > +919891695048 > > -- Thanks&Regards Anil Beniwal +919891695048

12 years, 5 months

RE: difference between /etc/ldap.conf /etc/openldap/ldap.conf

by Lynn York

You also should check the sshd_config and make sure you have "UsePAM yes" in the config -----Original Message----- From: GanGan [mailto:gangan@zalteam.com] Sent: Wednesday, October 29, 2008 12:03 PM To: Lynn York Cc: Hallvard B Furuseth; Openldap technical Subject: RE: difference between /etc/ldap.conf /etc/openldap/ldap.conf I did not touch so I do not think it comes from this files On Wed, 29 Oct 2008 11:55:29 -0400, Lynn York <lyork(a)inetu.net> wrote: > Make sure have configured PAM properly. Here is an example of a > system-auth-ac file that I use that works properly: > > [ /etc/pam.d/system-auth-ac ] > #%PAM-1.0 > # This file is auto-generated. > # User changes will be destroyed the next time authconfig is run. > auth required pam_env.so > auth sufficient pam_unix.so nullok try_first_pass > auth sufficient pam_ldap.so use_first_pass > auth required pam_deny.so > > account required pam_unix.so broken_shadow > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 500 quiet > account [default=bad success=ok user_unknown=ignore] pam_ldap.so > account required pam_permit.so > > password requisite pam_cracklib.so try_first_pass retry=3 > password sufficient pam_unix.so md5 shadow nullok try_first_pass > use_authtok > password sufficient pam_ldap.so use_authtok > password required pam_deny.so > > session optional pam_keyinit.so revoke > session required pam_limits.so > session [success=1 default=ignore] pam_succeed_if.so service in crond > quiet use_uid > session required pam_unix.so > session optional pam_ldap.so > [ end /etc/pam.d/system-auth-ac ] > > > -----Original Message----- > From: openldap-technical-bounces+lyork=inetu.net(a)openldap.org > [mailto:openldap-technical-bounces+lyork=inetu.net@openldap.org] On Behalf > Of > GanGan > Sent: Wednesday, October 29, 2008 11:28 AM > To: Hallvard B Furuseth > Cc: Openldap technical > Subject: Re: difference between /etc/ldap.conf /etc/openldap/ldap.conf > > > thank you > > I have a problem with my users authentication. > > getent passwd > gives me my 4 users ldap > > [...] > > videl:x:503:1000:videl:/home/videl:/bin/bash > azerty:x:501:1000:azerty:/home/azerty:/bin/bash > wizz:x:515:1000:wizz:/home/wizz:/bin/bash > shen:x:509:1000:shen:/home/shen:/bin/bash > > but impossible to connect. > > [root@clitest3 /]# ssh videl(a)srvtest3.test.org > videl(a)srvtest3.test.org's password: > Permission denied, please try again. > videl(a)srvtest3.test.org's password: > Permission denied, please try again. > videl(a)srvtest3.test.org's password: > Permission denied (publickey,password). > > log ldap server (srvtest3): > > Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 fd=14 ACCEPT from > IP=127.0.0.1:40706 (IP=0.0.0.0:389) > Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=0 STARTTLS > Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 fd=14 TLS established > tls_ssf=256 ssf=256 > Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=0 RESULT oid= err=0 text= > Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=1 BIND dn="" method=128 > Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=1 RESULT tag=97 err=0 > text= > Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=2 SRCH > base="ou=user,dc=midian,dc=org" scope=2 deref=0 > filter="(&(objectClass=posixAccount)(uid=videl))" > Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=2 SRCH attr=uid > userPassword uidNumber gidNumber cn homeDirectory loginShell gecos > description objectClass > Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=2 SEARCH RESULT tag=101 > err=0 nentries=0 text= > Oct 29 16:25:45 srvtest3 slapd[1947]: conn=19 op=3 SRCH > base="ou=user,dc=midian,dc=org" scope=2 deref=0 > filter="(&(objectClass=posixAccount)(uid=videl))" > Oct 29 16:25:45 srvtest3 slapd[1947]: conn=19 op=3 SRCH attr=uid > userPassword uidNumber gidNumber cn homeDirectory loginShell gecos > description objectClass > Oct 29 16:25:45 srvtest3 slapd[1947]: conn=19 op=3 SEARCH RESULT tag=101 > err=0 nentries=0 text= > Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 fd=17 ACCEPT from > IP=127.0.0.1:40707 (IP=0.0.0.0:389) > Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=0 STARTTLS > Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=0 RESULT oid= err=0 text= > Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 fd=17 TLS established > tls_ssf=256 ssf=256 > Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=1 BIND dn="" method=128 > Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=1 RESULT tag=97 err=0 > text= > Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=2 SRCH > base="ou=user,dc=midian,dc=org" scope=2 deref=0 > filter="(&(host=srvtest3.test.org)(uid=videl))" > Oct 29 16:25:45 srvtest3 slapd[1947]: <= bdb_equality_candidates: (host) > index_param failed (18) > Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=2 SEARCH RESULT tag=101 > err=0 nentries=0 text= > > I do not understand why it is not working. :( > any idea ? -- - GanGan - www.system-linux.eu merci pour le clique sur la pub :p

16 years, 7 months

Error "got search entry without sync state control" on N-Way Multimaster cn=config Runtime Configuration

by jon brandt

I'm getting this error when trying to get N-Way Multimaster configuration working between two servers using cn=config (Runtime Configuration) method: "do_syncrep2: rid=002 got search entry without SyncState control" >From some searching around, I found out this normally means the provider side doesn't have the syncprov overlay configured correctly. I think I have the correct syncprov overlay configured in both my servers (I get the same error on both), but I must have something messed up. I did find this very helpful link in the SUSE bugzilla database (bug 384787): https://bugzilla.novell.com/show_bug.cgi?id=384787 This cleared up some confusion I had with regard to the olcModuleLoad: syncprov.la which the OpenLDAP documentation describes as needed in cn=config. Apparently that is out of date info according to Ralf H. who responded to the above report. He mentions that the overlays are compiled into slapd now, so this isn't needed. Thanks Ralf! Anyway, with or without the olcModuleLoad stuff, my configuration still doesn't work correctly. Here it is, and any help is very much appreciated! Note that I left out the schema ldif files below, they are the following standard ones: core, cosine, inetorgperson, nis. Server 1 (linux-h4bt): *cn=config.ldif* dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: b0a2110e-2926-102f-9fef-bbe8cc5f05fe creatorsName: cn=config createTimestamp: 20100721151632Z olcServerID: 3 entryCSN: 20100721160215.521297Z#000000#000#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160215Z contextCSN: 20100721160232.622424Z#000000#003#000000 *cn=module{0}.ldif* dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: ../../../servers/slapd/overlays olcModuleLoad: {0}syncprov.la structuralObjectClass: olcModuleList entryUUID: 1d89971e-292d-102f-9f46-af88272e60b3 creatorsName: cn=manager,cn=config createTimestamp: 20100721160232Z entryCSN: 20100721160232.622424Z#000000#003#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160232Z *olcDatabase={0}config.ldif* dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcRootDN: cn=manager,cn=config olcRootPW:: Y29uZmln structuralObjectClass: olcDatabaseConfig entryUUID: b0a2daa8-2926-102f-9ff5-bbe8cc5f05fe creatorsName: cn=config createTimestamp: 20100721151632Z entryCSN: 20100721151632.935961Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721151632Z *olcDatabase={1}bdb.ldif* dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=phoenix,dc=com olcRootDN: cn=manager,dc=phoenix,dc=com olcRootPW:: c2VjcmV0 structuralObjectClass: olcBdbConfig entryUUID: b0a2ed7c-2926-102f-9ff7-bbe8cc5f05fe creatorsName: cn=manager,cn=config createTimestamp: 20100721151632Z olcAccess: {0}to attrs=userPassword by * auth by * +0 break olcAccess: {1}to * by dn.base="cn=manager,dc=phoenix,dc=com" read by * +0 br eak olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcSyncrepl: {0}rid=002 provider=ldap://unidome88xxx bindmethod=simple timeout =0 binddn="cn=manager,dc=phoenix,dc=com" credentials="secret" starttls=no fil ter="(objectclass=*)" searchbase="ou=users,dc=phoenix,dc=com" scope=sub attrs ="*,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" olcMirrorMode: TRUE entryCSN: 20100721160215.966913Z#000000#003#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160215Z *olcDatabase={-1}frontend.ldif* dn: olcDatabase={-1}frontend objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: b0a2dddc-2926-102f-9ff6-bbe8cc5f05fe creatorsName: cn=config createTimestamp: 20100721151632Z entryCSN: 20100721151632.936051Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721151632Z *olcOverlay={0}syncprov.ldif* dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 structuralObjectClass: olcSyncProvConfig entryUUID: 135f0e4a-292d-102f-9f45-af88272e60b3 creatorsName: cn=manager,cn=config createTimestamp: 20100721160215Z entryCSN: 20100721160215.566453Z#000000#003#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160215Z Server 2 (unidome88xxx): *cn=config.ldif* dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: 24af41c0-292c-102f-9291-b374f89e9aa0 creatorsName: cn=config createTimestamp: 20100721155535Z olcServerID: 2 entryCSN: 20100721160201.051314Z#000000#000#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160201Z contextCSN: 20100721160215.084570Z#000000#002#000000 *cn=module{0}.ldif* dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: ../../../servers/slapd/overlays olcModuleLoad: {0}syncprov.la structuralObjectClass: olcModuleList entryUUID: 1315872a-292d-102f-8dcc-97104602b49d creatorsName: cn=manager,cn=config createTimestamp: 20100721160215Z entryCSN: 20100721160215.084570Z#000000#002#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160215Z *olcDatabase={0}config.ldif* dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcRootDN: cn=manager,cn=config olcRootPW:: Y29uZmln structuralObjectClass: olcDatabaseConfig entryUUID: 24b12f3a-292c-102f-9297-b374f89e9aa0 creatorsName: cn=config createTimestamp: 20100721155535Z entryCSN: 20100721155535.129218Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721155535Z *olcDatabase={1}bdb.ldif* dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=phoenix,dc=com olcRootDN: cn=manager,dc=phoenix,dc=com olcRootPW:: c2VjcmV0 structuralObjectClass: olcBdbConfig entryUUID: 24b1553c-292c-102f-9299-b374f89e9aa0 creatorsName: cn=manager,cn=config createTimestamp: 20100721155535Z olcAccess: {0}to attrs=userPassword by * auth by * +0 break olcAccess: {1}to * by dn.base="cn=manager,dc=phoenix,dc=com" read by * +0 br eak olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcSyncrepl: {0}rid=002 provider=ldap://linux-h4bt bindmethod=simple timeout=0 binddn="cn=manager,dc=phoenix,dc=com" credentials="secret" starttls=no filte r="(objectclass=*)" searchbase="ou=users,dc=phoenix,dc=com" scope=sub attrs=" *,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" olcMirrorMode: TRUE entryCSN: 20100721160201.689045Z#000000#002#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160201Z *olcDatabase={-1}frontend.ldif* dn: olcDatabase={-1}frontend objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 24b134a8-292c-102f-9298-b374f89e9aa0 creatorsName: cn=config createTimestamp: 20100721155535Z entryCSN: 20100721155535.129372Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721155535Z *olcOverlay={0}syncprov.ldif* dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 structuralObjectClass: olcSyncProvConfig entryUUID: 0adcc5dc-292d-102f-8dcb-97104602b49d creatorsName: cn=manager,cn=config createTimestamp: 20100721160201Z entryCSN: 20100721160201.290849Z#000000#002#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160201Z * *

14 years, 10 months

Problem with new writetimeout

by Christian Manal

Hi everyone, I have noticed a problem regarding the new writetimeout feature in OpenLDAP 2.4.17. I have a setup with one master and four replicas running on Solaris 10, using the hdb-backend with BDB 4.4 from the opencsw repository. Clients are Sun, Linux and Mac boxes in every possible variation. I updated my servers last Friday from version 2.4.15 and now some cronjobs accessing the directory were sporadically failing over the weekend. I monitored the server logs (log level 'stats') while running the involved scripts repeatedly and got something like the following results after fail-runs on all servers: (IPs and DNs altered) > Jul 20 11:42:43 ldapserver slapd[9053]: [ID 848112 local4.debug] conn=12479 fd=79 ACCEPT from IP=192.168.1.1:50210 (IP=0.0.0.0:389) > Jul 20 11:42:43 ldapserver slapd[9053]: [ID 270379 local4.debug] conn=12479 op=0 EXT oid=1.3.6.1.4.1.1466.20037 > Jul 20 11:42:43 ldapserver slapd[9053]: [ID 560212 local4.debug] conn=12479 op=0 STARTTLS > Jul 20 11:42:43 ldapserver slapd[9053]: [ID 875301 local4.debug] conn=12479 op=0 RESULT oid= err=0 text= > Jul 20 11:42:43 ldapserver slapd[9053]: [ID 105384 local4.debug] conn=12479 fd=79 TLS established tls_ssf=256 ssf=256 > Jul 20 11:42:43 ldapserver slapd[9053]: [ID 215403 local4.debug] conn=12479 op=1 BIND dn="uid=dummyuser,ou=System,dc=example,dc=com" method=128 > Jul 20 11:42:43 ldapserver slapd[9053]: [ID 600343 local4.debug] conn=12479 op=1 BIND dn="uid=dummyuser,ou=System,dc=example,dc=com" mech=SIMPLE ssf=0 > Jul 20 11:42:43 ldapserver slapd[9053]: [ID 588225 local4.debug] conn=12479 op=1 RESULT tag=97 err=0 text= > Jul 20 11:42:43 ldapserver slapd[9053]: [ID 469902 local4.debug] conn=12479 op=2 SRCH base="ou=people,dc=example,dc=com" scope=2 deref=2 filter="(objectClass=posixAccount)" > Jul 20 11:42:43 ldapserver slapd[9053]: [ID 744844 local4.debug] conn=12479 op=2 SRCH attr=uid userpassword uidnumber gidnumber gecos homedirectory loginshell > Jul 20 11:43:00 ldapserver slapd[9053]: [ID 485650 local4.debug] conn=12479 fd=79 closed (writetimeout) I don't have the writetimeout keyword configured on any of the boxes and the affected script doesn't do any writes anyway. Also, the problem only seems to arise if the client takes a while to process a search result. The failing scripts are Net::LDAP based Perl scripts running on some old SPARC boxes, so it took them up to half a minute and more to complete. Setting writetimeout to a high enough value seems solve the problem, but referring to the docs, this shouldn't happen with the keyword unset or set to 0. Is this a bug or did I miss something? Did anyone else encounter this so far? Regards, Christian Manal

15 years, 10 months

Re: OpenLDAP TLS server authority verification

by Michael Ströder

Daniel Pocock wrote: > On 03/03/12 12:46, Michael Ströder wrote: >> Using DNS SRV is simply not specified regarding SSL/TLS. There's no way >> to map a naming context to a server cert despite your local security >> policy says your DNS is trusted by some other means. >> >>> A hostname can be a reference identity >>> >>> But a reference identity is not always a hostname. It depends on the >>> client configuration. >> >> The naming context (aka search root) cannot be a reference identity in >> the context of SSL/TLS. Period. > > The RFC does not say that. It does not have to say that. > Neither does it state that an implementation > should support the concept. It appears to leave the implementor some > discretion about their choice of reference identity. Yes. >> Feel free to write an Internet draft updating TLS-RFCs and RFC 2782. >> This could specify how a naming context is compared to some information >> in a subjectAltName extension since there's no standard saying something >> about this yet. A suitable GeneralName choice would be directoryName. > > It is already in RFC 6125: > > http://tools.ietf.org/html/rfc6125#section-6.2 I can't see any language which clearly defines rules how to derive the reference identity from a LDAP naming context. Just poiting out that it is no problem with SIP is not sufficient. > Many a mini-RFC about best practice for RFC 6125 in the LDAP world would > be useful though You would have to clearly define what a client has to do to derive and check the reference identity if its configuration simply contains ldaps:///dc=example,dc=com Frankly I don't like RFC 6125. IIRC I gave up reviewing the I-Ds when the authors insisted on adding support for wildcard certs. >> The right discussion forum could be the ldap-ext and ietf-tls mailing >> lists. > > My question is really about how OpenLDAP client code supports this (or > is anyone working on such things already) If there are no clear rules yet OpenLDAP IMO cannot support it. Basically we both disagree on what we consider to be sufficiently specified and secure: If I understood you correctly you propose that if a server's cert contains subjectAltname::dNSName:example.com this cert should be accepted for any application protocol having something like dc=example,dc=com, @example.com etc. I don't like that approach. It broadens the semantics in such a way that you cannot have distinct server certs for different services. Mainly I think that untyped GeneralName::dNSName was defined before we had several types of SRV RRs (except MX RRs) and no-one ever clearly specified its semantics. Same problem like looking up MX RR for a domain and then connecting to the MX servers with StartTLS. For a naming context ldaps:///dc=example,dc=com one could specify that subjectAltname MUST contain dNSName:_ldaps._tcp.example.com to at least express the connection to the SRV RR for the LDAP service. Or other approaches with other types of GeneralName. Ciao, Michael.

13 years, 3 months

openldap-technical search results for query "starttls"