Search results for "starttls" - openldap-technical

Re: What attributes to authenticate (or) How to block the ldap tree for anonymous users

by Holger Schier

Hi Diego, I tried your ACLs. Here are my entries: olcAccess: {0}to attrs=shadowLastChange,userPassword by dn.base="cn=admin,dc=MY,dc=DC" write by anonymous auth by self write by * none olcAccess: {1}to * by dn.base="cn=admin,dc=MY,dc=DC" write by users read by * none Then I tried to login and failed. "Login incorrect". In my messages: slapd[5527]: slapd starting login[4786]: pam_ldap: ldap_search_s No such object login[4786]: FAILED LOGIN 1 FROM /dev/tty1 FOR UNKNOWN, User not known to the underlying authentication module If I change the last line of the ACLs to: by * read everything works fine. So, I did some more logging: ----- slapd[8440]: conn=1 fd=13 ACCEPT from IP=127.0.0.1:41031 (IP=0.0.0.0:389) slapd[8440]: connection_get(13) slapd[8440]: conn=1 op=0 EXT oid=1.3.6.1.4.1.1466.20037 slapd[8440]: do_extended: oid=1.3.6.1.4.1.1466.20037 slapd[8440]: conn=1 op=0 STARTTLS slapd[8440]: conn=1 op=0 RESULT oid= err=0 text= slapd[8440]: connection_get(13) slapd[8440]: connection_get(13) slapd[8440]: conn=1 fd=13 TLS established tls_ssf=256 ssf=256 slapd[8440]: connection_get(13) slapd[8440]: conn=1 op=1 BIND dn="" method=128 slapd[8440]: send_ldap_result: err=0 matched="" text="" slapd[8440]: conn=1 op=1 RESULT tag=97 err=0 text= slapd[8440]: connection_get(13) slapd[8440]: SRCH "dc=MY,dc=DC" 2 0 slapd[8440]: 1 0 0 slapd[8440]: filter: (&(objectClass=shadowAccount)(uid=schier)) slapd[8440]: attrs: slapd[8440]: uid slapd[8440]: userPassword slapd[8440]: shadowLastChange slapd[8440]: shadowMax slapd[8440]: shadowMin slapd[8440]: shadowWarning slapd[8440]: shadowInactive slapd[8440]: shadowExpire slapd[8440]: shadowFlag slapd[8440]: slapd[8440]: conn=1 op=2 SRCH base="dc=MY,dc=DC" scope=2 deref=0 filter="(&(objectClass=shadowAccount)(uid=schier))" slapd[8440]: conn=1 op=2 SRCH attr=uid userPassword shadowLastChange shadowMax shadowMin shadowWarning shadowInactive shadowExpire shadowFlag slapd[8440]: => access_allowed: search access to "dc=MY,dc=DC" "entry" requested slapd[8440]: => acl_get: [2] attr entry slapd[8440]: => acl_mask: access to entry "dc=MY,dc=DC", attr "entry" requested slapd[8440]: => acl_mask: to all values by "", (=0) slapd[8440]: <= check a_dn_pat: cn=admin,dc=MY,dc=DC slapd[8440]: <= check a_dn_pat: users slapd[8440]: <= check a_dn_pat: * slapd[8440]: <= acl_mask: [3] applying none(=0) (stop) slapd[8440]: <= acl_mask: [3] mask: none(=0) slapd[8440]: => slap_access_allowed: search access denied by none(=0) slapd[8440]: => access_allowed: no more rules slapd[8440]: send_ldap_result: err=32 matched="" text="" slapd[8440]: conn=1 op=2 SEARCH RESULT tag=101 err=32 nentries=0 text= slapd[8440]: conn=2 fd=14 ACCEPT from IP=127.0.0.1:41032 (IP=0.0.0.0:389) slapd[8440]: connection_get(14) slapd[8440]: conn=2 op=0 EXT oid=1.3.6.1.4.1.1466.20037 slapd[8440]: do_extended: oid=1.3.6.1.4.1.1466.20037 slapd[8440]: conn=2 op=0 STARTTLS slapd[8440]: conn=2 op=0 RESULT oid= err=0 text= slapd[8440]: connection_get(14) slapd[8440]: connection_get(14) slapd[8440]: conn=2 fd=14 TLS established tls_ssf=256 ssf=256 slapd[8440]: connection_get(14) slapd[8440]: conn=2 op=1 BIND dn="" method=128 slapd[8440]: send_ldap_result: err=0 matched="" text="" slapd[8440]: conn=2 op=1 RESULT tag=97 err=0 text= slapd[8440]: connection_get(14) slapd[8440]: SRCH "dc=MY,dc=DC" 2 0 slapd[8440]: 1 0 0 slapd[8440]: filter: (&(objectClass=posixAccount)(objectClass=posixAccount)(uid=schier)) slapd[8440]: attrs: slapd[8440]: slapd[8440]: conn=2 op=2 SRCH base="dc=MY,dc=DC" scope=2 deref=0 filter="(&(objectClass=posixAccount)(objectClass=posixAccount)(uid=schier))" slapd[8440]: => access_allowed: search access to "dc=MY,dc=DC" "entry" requested slapd[8440]: => acl_get: [2] attr entry slapd[8440]: => acl_mask: access to entry "dc=MY,dc=DC", attr "entry" requested slapd[8440]: => acl_mask: to all values by "", (=0) slapd[8440]: <= check a_dn_pat: cn=admin,dc=MY,dc=DC slapd[8440]: <= check a_dn_pat: users slapd[8440]: <= check a_dn_pat: * slapd[8440]: <= acl_mask: [3] applying none(=0) (stop) slapd[8440]: <= acl_mask: [3] mask: none(=0) slapd[8440]: => slap_access_allowed: search access denied by none(=0) slapd[8440]: => access_allowed: no more rules slapd[8440]: send_ldap_result: err=32 matched="" text="" slapd[8440]: conn=2 op=2 SEARCH RESULT tag=101 err=32 nentries=0 text= login[8129]: pam_ldap: ldap_search_s No such object login[8129]: FAILED LOGIN 1 FROM /dev/tty1 FOR schier, User not known to the underlying authentication module Am 04.10.2010 20:30, schrieb Diego Lima: > Hi Holger, > > I'd try with the following ACLs: > > access to attrs=userPassword,shadowLastChange > by dn="cn=admin,dc=example,dc=com" write > by anonymous auth > by self write > by * none > > access to * > by dn="cn=admin,dc=example,dc=com" write > by users read > by * none > > > This way you'll be allowing unauthenticated users to log in using > their password fields and you'll restrict read access on the rest of > the base to authenticated users. The first ACL also allows users to > change their own passwords (write in the userPassword and > shadowLastChange attributes). Holger

14 years, 1 month

Re: mmr pair stops replicating: "consumer state is newer than provider"

by btb

On 6/27/17 4:55 PM, Quanah Gibson-Mount wrote: > --On Tuesday, June 27, 2017 5:35 PM -0400 btb <btb(a)bitrate.net> wrote: > >> On 6/27/17 10:27 AM, Quanah Gibson-Mount wrote: >>> --On Tuesday, June 27, 2017 10:37 AM -0400 btb <btb(a)bitrate.net> wrote: >>>> i'm using 2.4.44 on freebsd, built from ports. i can provide any >>>> config >>>> details etc - i just didn't want to inundate the post with guesses on >>>> detail that might not be relevant. >>> >>> What is your accesslog purge setting? Do you have long periods of time >>> with no write activity? >> >> there are some extended periods of time with no write activity, yes. > > That's one form of a known issue then with using accesslog (ITS#8100). > I've made a suggestion on how it could be fixed, and Howard agreed that > would be the correct solution. Just need the fix. :) > > In the meantime, you can set up a cronjob that does a modify once a day > on some object that doesn't really do anything, like if you had: > > dn: cn=someobject,dc... > objectClass: ... > cn: someobject > description: blah > > you could have a job that does: > dn: cn=someobject,dc... > changetype: modify > replace: description > description: blah > > So it in effect does nothing, but it keeps an active change in the > accesslog alive. > > Basically what happens with the accesslog empty is that it'll end up > generating its own new contextCSN that differs for that server than the > one stored in the rootDB, and will be /newer/ than it as well, which is > why you get that message. You can also fix the problem simply by doing > a modify on each master, and it'll reset the contextCSNs and things will > flow (i.e., no need to do a dump/reload, etc). i see, thanks. i tested this, and did a modify on each, but didn't see replication resume. emulating the syncrepl connection with a manual search against each master, there do seem to be accesslog entries now, on both masters: ldapsearch -ZZxWLLLH 'ldap://dsa1.example.org/' -D 'uid=dsa2_slapd-repl-content,ou=dsa2.example.org,ou=services,ou=accounts,cd=example,dc=org' -b 'cn=accesslog' '(&(objectClass=auditWriteObject)(reqResult=0))' reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Enter LDAP Password: dn: reqStart=20170628033755.000000Z,cn=accesslog reqType: add reqDN: cn=project_management_users,ou=general,ou=groups,cd=example,dc=org reqMod: member:+ uid=jdoe,ou=People,cd=example,dc=org reqMod: member:+ uid=mkline,ou=People,cd=example,dc=org reqMod: member:+ uid=astavins,ou=People,cd=example,dc=org reqMod: cn:+ project_management_users reqMod: objectClass:+ groupOfNames reqMod: objectClass:+ top reqMod: structuralObjectClass:+ groupOfNames reqMod: entryUUID:+ ea9a8246-effe-1036-966a-9d166400a934 reqMod: creatorsName:+ uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=or g reqMod: createTimestamp:+ 20170628033755Z reqMod: entryCSN:+ 20170628033755.410123Z#000000#001#000000 reqMod: modifiersName:+ uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=o rg reqMod: modifyTimestamp:+ 20170628033755Z entryCSN: 20170628033755.410123Z#000000#001#000000 dn: reqStart=20170628033931.000000Z,cn=accesslog reqType: modify reqDN: uid=jdoe,ou=People,cd=example,dc=org reqMod: givenName:+ john reqMod: entryCSN:= 20170628033931.892952Z#000000#001#000000 reqMod: modifiersName:= uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=o rg reqMod: modifyTimestamp:= 20170628033931Z entryCSN: 20170628033931.892952Z#000000#001#000000 dn: reqStart=20170628034017.000000Z,cn=accesslog reqType: modify reqDN: uid=jdoe,ou=People,cd=example,dc=org reqMod: sn:= doe reqMod: entryCSN:= 20170628034017.532972Z#000000#001#000000 reqMod: modifiersName:= uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=o rg reqMod: modifyTimestamp:= 20170628034017Z entryCSN: 20170628034017.532972Z#000000#001#000000 dn: reqStart=20170628034119.000000Z,cn=accesslog reqType: modify reqDN: uid=mkline,ou=People,cd=example,dc=org reqMod: givenName:+ michael reqMod: entryCSN:= 20170628034119.327974Z#000000#001#000000 reqMod: modifiersName:= uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=o rg reqMod: modifyTimestamp:= 20170628034119Z entryCSN: 20170628034119.327974Z#000000#001#000000 but the same log messages persist. what can i look at next? are these the relevant contextcsn values? dsa1 cn=accesslog: 20161019002438.652359Z#000000#000#000000 20170521175113.974560Z#000000#002#000000 20170530214415.204052Z#000000#001#000000 dsa1 dc=example,dc=org: 20170520031415.276678Z#000000#000#000000 20170530214231.171959Z#000000#002#000000 20170530214415.204052Z#000000#001#000000 dsa2 cn=accesslog: 20170520031415.276678Z#000000#000#000000 20170521175113.974560Z#000000#002#000000 20170628034119.327974Z#000000#001#000000 dsa2 dc=example,dc=org: 20170520031415.276678Z#000000#000#000000 20170619014933.531051Z#000000#002#000000 20170628034119.327974Z#000000#001#000000 if it might be of value, here are the olcsyncrepl attributes from each master: dsa1: {0}rid=000 provider=ldap://dsa2.example.org/ starttls=critical tls_cacert=/usr/local/etc/pki/trusted_root_authorities/root_ca-cert.pem bindmethod=simple binddn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,cd=example,dc=org" credentials="xxxxxxxxxxxxxxxxxxxxxx" searchbase="dc=example,dc=org" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="15 +" syncdata=accesslog dsa2: {0}rid=000 provider=ldap://dsa1.example.org/ starttls=critical tls_cacert=/usr/local/etc/pki/trusted_root_authorities/root_ca-cert.pem bindmethod=simple binddn="uid=dsa2_slapd-repl-content,ou=dsa2.example.org,ou=services,ou=accounts,cd=example,dc=org" credentials="xxxxxxxxxxxxxxxxxxxxxx" searchbase="dc=example,dc=org" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="15 +" syncdata=accesslog thanks -ben

7 years, 4 months

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

by GanGan

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

Re: Have daemon reload rotated certs

by David Arnold

Cool, I'm getting there! Unfortunately and for good reasons the creator of ae-dir.com has restricted modifying access for config (in order to tightly control runtime config state). So this is how far as I get: ``` [nix-shell] ➜ aedir-ldap.k8s git:(da-openldap-base) ✗ just mprovider SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: /var/run/certs/svid.pem - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /var/run/certs/svid_key.pem modifying entry "cn=config" ldap_modify: Server is unwilling to perform (53) additional info: operation restricted command terminated with exit code 53 error: Recipe `mprovider` failed with exit code 5 ``` Furthermore, would this dummy change also reload the certificates that are configured for the syncrepls? See: ``` dn: olcDatabase={2}mdb,cn=config olcSyncrepl: rid=001 provider=<ldaps://aedir-0.aedir.aedir-provider.svc.cluster> .local bindmethod=sasl timeout=5 network-timeout=5 saslmech=EXTERNAL keepaliv e=240:10:30 starttls=no tls_cert="/var/run/certs/svid.pem" tls_key="/var/run/ certs/svid_key.pem" tls_cacert="/var/run/certs/svid_bundle.pem" tls_reqcert=d emand tls_cipher_suite=ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384: ECDH-RSA-AES256-GCM-SHA384:!ADH tls_protocol_min=3.3 tls_crlcheck=none filter ="(objectClass=*)" searchbase="ou=ae-dir" scope=sub attrs="*,+" schemacheckin g=on type=refreshAndPersist retry="30 +" ``` I'm starting to think plain process signalling for reloading the TLS context would actually be a cleaner, more elegant and stable solution. Would you be ok if I opened an issue for that? On Fri, Aug 21, 2020 at 12:00, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Friday, August 21, 2020 2:56 PM -0500 David Arnold > <dar(a)xoe.solutions <mailto:dar@xoe.solutions>> wrote: > >> Since the paths don't actually change (and I have no means to make >> them >> change), can I do a dummy modification that would trigger cert >> reloading? > > Yeah, just do a replace op, like: > > ldapmodify ... > dn: cn=config > changetype: modify > replace: olcTLS.. > olcTLS...: original value > > For the slapd.conf configuration to enable the cn=config db just have: > > database config > rootpw somepassword > > and then you can bind to it w/ that password. Alternatively, you can > set up an authz-regexp, etc. > > > Regards, > Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com <http://www.symas.com/>>

4 years, 3 months

Re: top-level data entries not replicating, 2.4.15

by Brian Neu

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 updateref ldaps://victory2.srg.com database monitor access to * by dn.exact="cn=Manager,dc=srg,dc=com" write by * none </consumer slapd.conf> --- On Thu, 8/20/09, Jonathan Clarke <jonathan(a)phillipoux.net> wrote: > From: Jonathan Clarke <jonathan(a)phillipoux.net> > Subject: Re: top-level data entries not replicating, 2.4.15 > To: "Brian Neu" <proclivity76(a)yahoo.com> > Cc: openldap-technical(a)openldap.org > Date: Thursday, August 20, 2009, 8:02 AM > On 19/08/2009 19:29, Brian Neu > wrote: > > Even with no logfilter on the consumer, > > > cn=replicator,dc=domain,dc=com& > > > sambaDomainName=SRG,dc=domain,dc=com > > > > don't replicate, even after wiping the database and > restarting. Everything else seems to replicate fine. > > > > How do I get top-level data entries to replicate? > > This really depends on your syncrepl configuration on the > consumer. > If you provide it here, maybe we can take a look. > > Aside from that, the latest version, 2.4.17, contains a few > fixes that > might help with this problem. > > Jonathan >

15 years, 3 months

Syncrepl on glued databases only replicates the superior and the first subordinate

by Robert Minsk

Openldap version 2.4.35 Our global ldap server has the following naming contexts: namingContexts: o=global,ou=studios,dc=methodstudios,dc=net namingContexts: o=chi01,ou=studios,dc=methodstudios,dc=net namingContexts: o=det01,ou=studios,dc=methodstudios,dc=net namingContexts: o=la01,ou=studios,dc=methodstudios,dc=net namingContexts: o=ny01,ou=studios,dc=methodstudios,dc=net namingContexts: o=lon01,ou=studios,dc=methodstudios,dc=net namingContexts: o=van01,ou=studios,dc=methodstudios,dc=net namingContexts: ou=studios,dc=methodstudios,dc=net namingContexts: ou=login,dc=methodstudios,dc=net ou=studio,dc=methodstudios,dc=net is the superior database and global, chi01, det01, la01, ny01, lon01, van01 are all have "subordinate advertise" and are all sync providers. The sync provider: database mdb suffix "ou=studios,dc=methodstudios,dc=net" rootdn ... rootpw ... directory /var/lib/ldap/studios.methodstudios.net maxsize 17179869184 serverID 201 overlay glue overlay syncprov syncprov-reloadhint TRUE syncprov-checkpoint 100 5 sync_use_subentry true ... The sync consumer only has a database for ou=studios,dc=methodstudios,dc=net. database mdb suffix "ou=studios,dc=methodstudios,dc=net" rootdn ... rootpw ... directory /var/lib/ldap/studios.methodstudios.net maxsize 17179869184 serverID 202 syncrepl rid=201 provider=ldap://<providor host name> type=refreshAndPersist retry="60 10 300 +" searchbase="ou=studios,dc=methodstudios,dc=net" bindmethod=simple starttls=yes binddn="..." credentials=... schemachecking=off sizelimit=unlimited timelimit=unlimited updateref ldap://<providor host name> It seems to be only syncing ou=studios,dc=methodstudios,dc=net and o=global,ou=studios,dc=methodstudios,dc=net. If I change the order of the provider server so that chi01 comes before global then only syncing ou=studios,dc=methodstudios,dc=net and o=chi01,ou=studios,dc=methodstudios,dc=net get sync. Am I doing anything obviously wrong? -- Robert Minsk Systems and Software Engineer WWW.METHODSTUDIOS.COM <http://www.methodstudios.com> 730 Arizona Ave, Santa Monica, CA 90401 O:+1 310 434 6500 <tel:+13104346500> // F:+1 310 434 6501 <tel:+13104346501> Los Angeles <http://www.methodstudios.com/signature/url/los-angeles><http://www.methodstudios.com/signature/url/los-angeles> This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.

10 years, 11 months

[Solved] AW: Re: AW: Re: AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable))

by Hauke Coltzau

Hi all, Wow, it seems to be done ;-) To put it in a nutshell: - apt-get purge MIT-Kerberos* - apt-get install Heimdal* - tried and failed, tried and failed, ... - apt-get purge heimdal*, cyrus*, openldap* - apt-get libssl-dev and libdb dev packages - got cyrus, openldap and heimdal tarballs - configured, compiled, tested, failed, configured, compiled, tested, failed, conf.......... ...... ...... ... --- ... ... --- ... configured, compiled, succeeded! - Followed well known configuration instructions Voila! ldapsearch -Y GSSAPI works ldaps works (without client verification, did not solve that yet, server verification works fine) login with kerberos authentication works (with proxy ticket for the machine, this way I avoid having PLAIN username/password send to slapd) su, id, etc. works Seems, as if doing it by hand is still the best way ;-) Thanks again for your help, Hauke ----- Ursprüngliche Mail ----- Von: "Quanah Gibson-Mount" <quanah(a)zimbra.com> An: "Hauke Coltzau" <hauke.coltzau(a)FernUni-Hagen.de> CC: openldap-software(a)openldap.org Gesendet: Montag, 8. September 2008 21:44:16 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien Betreff: Re: AW: Re: AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable)) --On Monday, September 08, 2008 9:26 PM +0200 Hauke Coltzau <hauke.coltzau(a)FernUni-Hagen.de> wrote: > ii libsasl2-modules-gssapi-mit 2.1.22.dfsg1-18ubuntu2 \\ > Cyrus SASL - pluggable authentication module I would highly recommend using Heimdal on the master side. But that's up to you. ;) > - In the first approach, the user already has a TGT and asks the KDC for > a "ldap/fqdn@REALM-ticket"? This is done by ldapsearch, not by slapd? > Hence, slapd "only" needs access to its keytab to be able to decrypt the > clients messages? I believe that is correct, yes. At Stanford, I had to point slapd at the keytab in a shell script, but I believe that was because I was using SASL/GSSAPI to do replication as well. It's been a while. ;) > - And in the second one, the user provides username and password (plain), > slapd converts the username into a principle (user@REALM) and forwards > this to saslauthd? So this should be secured via TLS? You can try securing it via startTLS, but nothing blocks a user from still doing it in the clear, unfortunately (i.e., you can reject the non-secured bind, but they'll have already sent their credentials, so anyone sniffing would be able to get them). > There used to be a well-known howto for all this at > http://www.bayour.com/LDAPv3-HOWTO.html but the site is offline for some > days now. This howto is completely wrong, and the various folks have asked the author to take it down for years. I'm glad to hear it is not accessible. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --

16 years, 2 months

Multi-master replication (ldap_sasl_bind_s failed)

by Artur Nike

Hi all, My adventure with LDAP lasts a few months, and I came to the topic of replication, namely multiple-master replication. cn = config is replicated perfectly, but the schema, say, dc = example, dc = com does not want to: (. I have two servers slap1 and slap2 I have a standard installation ##Server slap1 whezzy debian 64bit apt-get install-y slapd ldap-utils added my scheme ldapadd-Y EXTERNAL-H ldapi :///-f $ CURRENT / memberof.ldif ldapadd-Y EXTERNAL-H ldapi :///-f $ CURRENT / refint.ldif # Add "ldap :/ / ldap1 / in /etc/default/slapd sed-i "/^ SLAPD_SERVICES/s/=[^]*/=\"ldap:\/\/slap1\//'/etc/default/slapd ldapmodify-Y EXTERNAL-H ldapi :/ / /-f replica1.ldif where replica1.ldif (replication configuration):: dn: cn=config changetype: modify add: olcServerID olcServerID: 1 dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: {1}syncprov.la dn: olcDatabase={0}config,cn=config changetype: modify add: olcRootPW #only for tests olcRootPW: 123 dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldap://slap1/ olcServerID: 2 ldap://slap2/ dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://slap1/ binddn="cn=admin,cn=config" bindmethod=simple credentials=123 searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldap://slap2/ binddn="cn=admin,cn=config" bindmethod=simple credentials=123 searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE This same scenario takes on a server slap2 (the name change slap1 -> slap2) where replica2.ldif (replication configuration only servers slap2) : dn: cn=config changetype: modify add: olcServerID olcServerID: 2 dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: {1}syncprov.la dn: olcDatabase={0}config,cn=config changetype: modify #only for tests add: olcRootPW olcRootPW: 123 dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldap://slap1/ olcServerID: 2 ldap://slap2/ dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://slap1/ binddn="cn=admin,cn=config" bindmethod=simple credentials=123 searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldap://slap2/ binddn="cn=admin,cn=config" bindmethod=simple credentials=123 searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE and it works , the whole configuration is replicated . Now I want ( I'm trying to add a replication scheme . ) Adds only one server , eg slap2 : ldapmodify - Y EXTERNAL -H ldapi :/ / / -f rep_schema.ldif where rep_schema.ldif : # add replica schema dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcRootPW olcRootPW: 123 - replace: olcRootDN olcRootDN: cn=admin,dc=example,dc=com dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcLimits olcLimits: dn.exact="cn=admin,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited - add: olcSyncRepl olcSyncRepl: rid=004 provider=ldap://ldap1/ binddn="cn=admin,dc=example,dc=com" bindmethod=simple credentials="123" searchbase="dc=example,dc=com" starttls=no filter="(objectclass=*)" attrs="*,+" scope=sub schemachecking=of type=refreshAndPersist interval=00:00:00:10 retry="5 5 10 5" timeout=1 olcSyncRepl: rid=005 provider=ldap://ldap2/ binddn="cn=admin,dc=example,dc=com" bindmethod=simple credentials="123" searchbase="dc=example,dc=com" starttls=no filter="(objectclass=*)" attrs="*,+" scope=sub schemachecking=off type=refreshAndPersist interval=00:00:00:10 retry="5 5 10 5" timeout=1 - add: olcDbIndex olcDbIndex: entryUUID eq - add: olcDbIndex olcDbIndex: entryCSN eq - add: olcMirrorMode olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov Configuration replicates and the end, schema does not replicate. If you try to replicate one of the servers are in the logs I see: Dec 15 23:44:48 slap1 slapd[4496]: do_syncrepl: rid=004 rc -1 quitting Dec 15 23:44:48 slap1 slapd[4496]: slap_client_connect: URI=ldap://ldap2/ DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Dec 15 23:44:48 slap1 slapd[4496]: do_syncrepl: rid=005 rc -1 retrying Dec 15 23:44:58 slap1 slapd[4496]: =>do_syncrepl rid=005 Dec 15 23:44:58 slap1 slapd[4496]: slap_client_connect: URI=ldap://ldap2/ DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Dec 15 23:44:50 slap2 slapd[4456]: do_syncrepl: rid=004 rc -1 retrying Dec 15 23:44:54 slap2 slapd[4456]: =>do_syncrepl rid=005 Dec 15 23:44:54 slap2 slapd[4456]: slap_client_connect: URI=ldap://ldap2/ DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Dec 15 23:44:54 slap2 slapd[4456]: do_syncrepl: rid=005 rc -1 quitting Dec 15 23:45:00 slap2 slapd[4456]: =>do_syncrepl rid=004 Dec 15 23:45:00 slap2 slapd[4456]: slap_client_connect: URI=ldap://ldap1/ DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1) from server slap2 to search slap1: ldapsearch -x -D cn=admin,dc=example,dc=com-H ldap://slap1/ -b dc=example,dc=com -w 123 (working) from server slap1 to search slap2: ldapsearch -x -D cn=admin,dc=example,dc=com-H ldap://slap2/ -b dc=example,dc=com -w 123 (working) I'm out of ideas... user : DN="cn=admin,dc=example,dc=com" is created automatically when I install slapd Can anyone have any suggestions or experience with this problem. For all, thank you in advance. Muniek

10 years, 11 months

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

2 months

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, 3 months

openldap-technical search results for query "starttls"