openldap-technical

openldap-technical@openldap.org

9 participants
9866 discussions

Multimaster Replication
by Weiner, Michael 10 May '17

10 May '17

Searching through the archives, helpful information, but I wasn't able to find anything that quite matched my issue. Some background, I am running CentOS 7 with OpenLDAP version 2.4.40 and I have been following along a tutorial I found here: http://linoxide.com/linux-how-to/setup-openldap-multi-master-replication-ce… everything goes well, of course,until the very last step where I have to add the replication information, I recreated this ldif: dn: cn=config changetype: modify replace: olcServerID olcServerID: 101 ldap://lri-ldap1 olcServerID: 201 ldap://lri-ldap2 olcServerID: 301 ldap://lri-ldap3 olcServerID: 401 ldap://lri-ldap4 dn: olcDatabase={2}hdb,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://lri-ldap1:389/ bindmethod=simple binddn="cn=admin,dc=lerner,dc=ccf,dc=org" credentials=password12 searchbase="dc=lerner,dc=ccf,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 3" interval=00:00:05:00 olcSyncRepl: rid=002 provider=ldap://lri-ldap2:389/ bindmethod=simple binddn="cn=admin,dc=lerner,dc=ccf,dc=org" credentials=password12 searchbase="dc=lerner,dc=ccf,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 3" interval=00:00:05:00 olcSyncRepl: rid=003 provider=ldap://lri-ldap3:389/ bindmethod=simple binddn="cn=admin,dc=lerner,dc=ccf,dc=org" credentials=password12 searchbase="dc=lerner,dc=ccf,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 3" interval=00:00:05:00 olcSyncRepl: rid=004 provider=ldap://lri-ldap4:389/ bindmethod=simple binddn="cn=admin,dc=lerner,dc=ccf,dc=org" credentials=password12 searchbase="dc=lerner,dc=ccf,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 3" interval=00:00:05:00 - add: olcMirrorMode olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov and then ldapmodify -Y EXTERNAL -H ldapi:/// -f rp.ldif on all 4 masters, and what I get is, they are all just sitting there not providing me with a prompt: [root@lri-ldap4 openldap]# ldapadd -Y EXTERNAL -H ldapi:/// -f rp.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" modifying entry "olcDatabase={2}hdb,cn=config" adding new entry "olcOverlay=syncprov,olcDatabase={2}hdb,cn=config" and I cannot tell what it is actually doing at this stage. I check systemctl status spald: May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=0 RESULT tag=97 err=0 text= May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=1 MOD dn="cn=config" May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=1 MOD attr=olcServerID May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=1 RESULT tag=103 err=0 text= May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=2 MOD dn="olcDatabase={2}hdb,cn=config" May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=2 MOD attr=olcSyncRepl olcMirrorMode May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=2 RESULT tag=103 err=0 text= May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=3 ADD dn="olcOverlay=syncprov,olcDatabase={2}hdb,cn=config" And that's where it stops, but I never get a prompt on any of the masters. Has anyone else seen this? Where did I go wrong? And how can I move forward? Thanks in advance Michael =================================== Please consider the environment before printing this e-mail Cleveland Clinic is ranked as one of the top hospitals in America by U.S.News & World Report (2015). Visit us online at http://www.clevelandclinic.org for a complete listing of our services, staff and locations. Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. Thank you.

2 1

ppolicy overlay - not seeming to function?
by John Cooter 10 May '17

10 May '17

So, before I ask my question, here are my referenced objects, from a "slapcat -n 0": dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub structuralObjectClass: olcHdbConfig entryUUID: eb941fcc-bef3-1036-9d74-0d6e032eb747 creatorsName: cn=config createTimestamp: 20170426174545Z olcAccess: {0}to dn.base="" by self write by dn="cn=ldapadmin,dc=XXXXXXX ,dc=net" write by * read olcAccess: {1}to * by self write by dn="cn=ldapadmin,dc=XXXXXXX,dc=net" w rite by * read olcAccess: {2}to dn.subtree="ou=mail,ou=hosting,dc=XXXXXXX,dc=net" attrs= userPassword,UseAppPassword,children,entry,objectClass,cn,sn,uid by self w rite by dn="cn=ldapadmin,dc=XXXXXXX,dc=net" write by * auth by * read olcSuffix: dc=XXXXXXXX,dc=net olcRootDN: cn=ldapadmin,dc=XXXXXXX,dc=net olcRootPW:: e1NTSEF9K2p6YnhXL0xQTDJKZFFIZitac3l6RzVXaEN3UEhQUkc= entryCSN: 20170508155547.001404Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170508155547Z dn: olcOverlay={0}ppolicy,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {0}ppolicy olcPPolicyDefault: cn=passwordDefault,ou=policies,dc=XXXXXXX,dc=net olcPPolicyHashCleartext: FALSE olcPPolicyUseLockout: FALSE olcPPolicyForwardUpdates: FALSE structuralObjectClass: olcPPolicyConfig the passwordDefaul policy exists in the correct location, and appears to apply to all user objects BUT when I change a user object to a value that either violates the base policy (say, has only 4 characters instead of 5 or more), or would not conform to the check_password.so function, as established by various outside sources, it does not give me an error of any kind, and instead, writes the password to the DB and writes the following to the log: May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 EXT oid=1.3.6.1.4.1.1466.20037 May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 STARTTLS May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 RESULT oid= err=0 text= May 10 11:00:06 ldapv slapd[1984]: conn=1007 fd=11 TLS established tls_ssf=256 ssf=256 May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 BIND dn="cn=ldapadmin,dc=XXXXXXX,dc=net" method=128 May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 BIND dn="cn=ldapadmin,dc=XXXXXXX,dc=net" mech=SIMPLE ssf=0 May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 RESULT tag=97 err=0 text= May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 MOD dn="uid=USER,cn=TESTDOMAIN.com,ou=domain,ou=mail,ou=hosting,dc=XXXXXXX,dc=net" May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 MOD attr=userPassword May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 RESULT tag=103 err=0 text= And the entry, as referenced by phpLDAPadmin, appears to correspond to the "bad" password. How can I go about confirming that the password policy is being enforced?

1 0

Re: [SOLVED] Re: chain overlay does an anonymous bind and ignores the chain binddn (v2.4.44)
by Quanah Gibson-Mount 10 May '17

10 May '17

--On Monday, May 08, 2017 12:16 PM +0000 mailing lists <listas.correo(a)yahoo.es> wrote: > if I add the port to the updateref directive I can reproduce the > behaviour (anonymous bind vs bind with the identity configurated in the > chain overlay) only by switching the updateref beetwen the url with port > and without it. Please see <http://www.openldap.org/its/index.cgi/?findid=7768>, it looks like you would need to set a corresponding olcDbUri attribute to match your updateref value Can you let me know if this resolves the issue? If so, I can update the documentation accordingly. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Secure replication
by Quanah Gibson-Mount 09 May '17

09 May '17

--On Tuesday, May 09, 2017 2:11 AM +0000 "Real, Elizabeth (392K)" <Elizabeth.Real(a)jpl.nasa.gov> wrote: Hi Elizabeth, > If "ldap://" is secure already then I do not need to proceed further. That says nothing about whether or not your configuration is secure. Again, if it is "ldap://" with the startTLS LDAPv3 extension, and you've configured it be required that it succeed, then it is secure. You've not provided the information that would be necessary to make such a determination. I would again advise reading the slapd-config(5) man page for the olcSyncRepl attribute, specifically the bits on the starttls, tls_cacert/tls_cacertdir, tls_cipher_suite, and tls_protocol_min configuration parameters. You may also want to set olcSecurity (A value of "ssf=1" requires any and all connections to the server be encrypted). Changing this value from the default requires a server restart for it to go into effect. > SSLv3 > TLSv1.2 Those look like protocol versions, not cipher suites. ;) > Why is version 2.4.40 unsafe for multi-master replication? I can upgrade > at a later time I just wanted to find out how to enable ldaps between the > two servers. You can read through the OpenLDAP Release notes here: <http://www.openldap.org/software/release/changes.html> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Secure replication
by Michael Ströder 09 May '17

09 May '17

Ulrich Windl wrote: >>>> Michael Ströder <michael(a)stroeder.com> schrieb am 08.05.2017 um 23:39 in >> When running different replicas which terminate TLS themselves you can issue a >> different server cert with distinct subject-DN for each of them and put FQDN(s) of >> the same HA address(es) (e.g. of your load-balancer(s)) into subjectAltName >> extension in all these different server certs. > > So you have one certificate for all servers, and the answer is that you cannot > have different certificates? If so, we had discussed that before. I thought you > were advising otherwise now, and I was surprised how that would work. Did you deliberately misread my answer? I cannot imagine how I can make more clear that I have different certs on all replicas. And probably you also misread my former postings about that topic. Ciao, Michael.

1 0

Re: Secure replication
by Quanah Gibson-Mount 09 May '17

09 May '17

--On Saturday, May 06, 2017 1:56 AM +0000 "Real, Elizabeth (392K)" <Elizabeth.Real(a)jpl.nasa.gov> wrote: > The olcSyncRepl directive on both systems needs to go from: > > olcSyncRepl: rid=001 provider=ldap > > to: > > olcSyncRepl: rid=001 provider=ldaps The use of "ldap://" does not mean that you have insecure replication. The "ldaps" designation was developed to allow for SSL encrypted connections as a part of LDAPv2, which did not have a formal design spec for allowing SSL encryption. The LDAPv3 spec, which is what OpenLDAP 2.4 (and much earlier version) implement, specifically has startTLS as a part of that specification, which uses "ldap:///". I.e., ldaps is a bastardized hack for LDAPv2. The proper way to do TLS encryption with LDAPv3 capable servers such as OpenLDAP 2.[1-4+] is to use the startTLS extended operation over a "ldap:///" URI. In addition, there are other ways to have an encrypted connection between an LDAP client and server without involving TLS at all, such as SASL/GSSAPI. As Michael noted, you can, in addition to enabling TLS encryption between the client and servers, use client cert authentication (SASL/EXTERNAL) so as to remove the requirement for clear text credentials to be stored in the olcSyncRepl attribute (if using simple binds). And again, the usage of SASL/GSSAPI also precludes the neccessity of storing cleartext credentials in the olcSyncRepl attribute. As an aside, I would note that 2.4.40 is completely unsafe to use with multimaster replication. I would generally suggest forming a clear set of requirements for your replication environment, and then asking how to implement them. Your current question is too vague/general to really be answered well. Hope that helps! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Antw: Re: Secure replication
by Michael Ströder 08 May '17

08 May '17

Ulrich Windl wrote: > I have a related question: Can you have different certificates, depending on > "Normal use" and replication? I guess no, so if you use a load balancer, you'll > have a problem with every server having a different cert (This is how I reaed > your message). Didn't we discuss that before? When running different replicas which terminate TLS themselves you can issue a different server cert with distinct subject-DN for each of them and put FQDN(s) of the same HA address(es) (e.g. of your load-balancer(s)) into subjectAltName extension in all these different server certs. Does that answer your question? Ciao, Michael.

1 0

Re: [SOLVED] Re: chain overlay does an anonymous bind and ignores the chain binddn (v2.4.44)
by Quanah Gibson-Mount 08 May '17

08 May '17

--On Friday, May 05, 2017 10:27 AM +0000 mailing lists <listas.correo(a)yahoo.es> wrote: >> config to the config used in that test? > > > > the chain works as expected, with the identity configurated, if the port > is not included in the updatedn. An DN by definition wouldn't contain port information. Can you provide a real example of the problem and how you fixed it? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

ACL to authenticate gitlab users
by Xaar 07 May '17

07 May '17

Hello, I want to authenticate users via OpenLDAP to Gitlab. In Gitlab configuration there is a gitlab.rb file, where I can write some special user (let it be gitlabuser) with credentials who will be bind to ldap server. Now my question is, what acl should I provide to this user on OpenLDAP server to allow other users authenticate to Gitlab ? Now my DIT looks like this: dc=company,dc=com | | - cn=admin - cn=gitlabuser | | - ou=Groups - ou=Users -> here are users which I want to give access to Gitlab Is this entry is fair enough ? dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcAccess olcAccess: {0} to attrs=userPassword by anonymous auth by dn=„cn=admin,dc=company,dc=com” write by * none olcAccess: {1} to dn.base=„” by * read olcAccess: {2} to * by * read Best Regards !

1 0

Interpreting RFC 2849
by Joseph L. Casale 06 May '17

06 May '17

Do I read the RFC correctly regarding the value-spec for the ASCII value case stating exactly one FILL character follows the colon by zero or more SAFE-STRING occurrences? In other words, the following is OK: `attribute-type: ` but not `attribute-type:` This format only applies to changetype add, if I interpret the spec correctly, what sense does it make to ask the dsa to remove any values for the specified attribute type on the new, yet to be created entry, effectively removing the type? And why is the later not tolerated, neither makes sense to me on a changetype add? Thanks, jlc

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical