openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

Re: Fwd: Multi-Master OpenLDAP Replication for 3 nodes -- slapadd command failing
by fal patel 05 Jan '13

05 Jan '13

Oho, so you agree that the OpenLDAP Guide Section 18.3.3 "N-Way Multi-Master" fails to work as is with the Section 10.2 "Creating a database off-line", specifically with Section 10.2.1 "The slapadd program"? And you're failing or refusing to provide a LDIF file for the above that that actually works? That means you don't have "enough understanding and general competence" to make your own product, OpenLDAP, work according to the description in your own manual, the "OpenLDAP 2.4 Administrator's Guide". Your product is a joke and you're another. I hereby unsubscribe from this mailing list. Fal On Thu, Jan 3, 2013 at 9:51 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Thursday, January 03, 2013 9:28 PM -0800 fal patel < > fal0patel(a)gmail.com> wrote: > > It should be acceptable as an LDIF as input to slapadd. >> If it is not, it is buggy by definition. >> Remember, we should be able to perform database configuration OFF-LINE. >> ie. without slapd running. >> And obviously when off-line, slapadd works whereas ldapmodify, ldapadd >> etc. cannot. >> > > If you would spend the time to start with a basic cn=config setup, and > then perform the ldap modifications as noted in the admin guide, your end > result would be a cn=config DB you could *slapcat* into LDIF, which you > could then use as a template for loading other servers. In fact, you'd be > long done with this if you'd simply done that very simple thing. > > Just because slapadd doesn't parse LDIF meant for ldap modify does *not* > mean it is buggy. It means you are following the admin guide. > > The admin guide is not a document that explains how to do anything and > everything under the sun. It is a general guide that gives working > examples of how to do various things. The end user is supposed to have > enough understanding and general competence to be able to extrapolate how > to go from there. > > In addition, you've also been pointed to test suites that set up > multi-master replication of cn=config. You could have trivially exported > those cn=config DB's via slapcat as well. > > You seem awfully determined to have other people take the time to do your > work for you, rather than doing what you could have already done weeks ago > in a few minutes. > > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

Re: About TLS - ldaps search
by Bheeshma SM 05 Jan '13

05 Jan '13

Is there a specific way, i have to configure the slapd to listem to 636 port..? And does the 389 search is a secure search...? Is there a particular way of Starting the TLS operation..? Thanks in advance On Fri, Jan 4, 2013 at 4:31 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Friday, January 04, 2013 4:09 PM -0800 Bheeshma SM < > bheeshma.manjunath(a)gmail.com> wrote: > > >> Hi guys. >> >> I have a problem in Openldap 2.4.33 on RHEL 5.8 >> >> I am able to do a " ldapsearch -x -p 389 -h -D<> -w<> -b<> " >> >> but i am not able to do >> >> " ldapsearch -x -p 636 -h -D<> -w<> -b<> >> > > Sounds like slapd is not configured to listen to port 636. No amount of > mucking with ldapsearch is going to change that. > > I would note that you can do secure searches over port 389 just fine. > Simply use the startTLS operation. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

About TLS - ldaps search
by Bheeshma SM 05 Jan '13

05 Jan '13

Hi guys. I have a problem in Openldap 2.4.33 on RHEL 5.8 I am able to do a *" ldapsearch -x -p 389 -h -D<> -w<> -b<> "* but i am not able to do *" ldapsearch -x -p 636 -h -D<> -w<> -b<>* I have done all the changes in ldap.conf and certificates are working fine. The weird thing is *"ldapsearch -x -H **ldaps://hostname* <ldaps://hostname>* -D <> -w <> -b<> " is working fine.* What i am trying to do is-- I want to disable the 389 port so that is no searches running in the non-secure port. So can any1 tell me why the *" ldapsearch -x -p 636 -h -D<> -w<> -b<>" [secure search is not working]* Please help me out in this. Thanks in advance. -bhee

2 1

Forcing TLS, but keep working SASL authentication
by Wiebe Cazemier 04 Jan '13

04 Jan '13

Hi, I want to force SSL on my OpenLDAP server (2.4.21-0ubuntu5.7, Ubuntu 10.04 LTS), but then the SASL authentication breaks. I did this to enable tls-only: # feed to ldapmodify dn: cn=config changetype: modify add: olcSecurity olcSecurity: tls=1 But, then I can't use "-Y EXTERNAL" anymore, because it then demands a TLS connection. When I enable TLS (-ZZ) on tools like ldapmodify and use ldap://hostname/ and bind with my rootDN (admin user), it doesn't work (insufficient access (50)). I guess it needs the socket to know I'm root. Inspecting all DB's with "ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config", it appears the config DB's have an olcAccess rule like: olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break gid and uid = 0, so I guess it's the system's root account. I tried adding an olcRootDN and olcRootPW to olcDatabase={0}config,cn=config so that I could modify the cn=config, but adding them gave an error: "<olcRootPW> can only be set when rootdn is under suffix". When I tried adding olcSuffix to "dc=domain,dc=tld", it said: "<olcSuffix> handler exited with 1". I also tried specifying a olcRootDN only (no olcRootPW) (like cn=admin,dc=domain,dc=tld) and then add that user to "dc=domain,dc=tld", but it didn't work. Unfortunately, I don't remember what went wrong. So, is there a way to enforce TLS but still use the SASL authentication? Any help is appreciated. Thanks in advance, Wiebe Cazemier

2 3

Fwd: Multi-Master OpenLDAP Replication for 3 nodes -- slapadd command failing
by fal patel 04 Jan '13

04 Jan '13

---------- Forwarded message ---------- From: fal patel <fal0patel(a)gmail.com> Date: Thu, Jan 3, 2013 at 3:28 PM Subject: Re: Multi-Master OpenLDAP Replication for 3 nodes -- slapadd command failing To: openldap-technica(a)openldapl.org, Howard Chu <hyc(a)symas.com>, Philip Guenther <guenther+ldaptech(a)sendmail.com> Cc: fal patel <fal0patel(a)gmail.com> Hi Howard and Philip, Thank you very much for your emails. Well, it doesn't work for me, and hasn't for the two weeks I've been wrestling with it. Could you please post a *working* LDIF file of Section 18.3.3 "N-Way Multi-Master"? (I can substitute my real values if you keep the "$xxx" labels in there, of course.) I want to be able to feed the above LDIF file in to slapadd and obtain both config db replication and also data replication. The only change I should have to make for my 3 OpenLDAP servers is that the Server#1 should have "olcServerID: 1", Server#2 should have "olcServerID: 2", etc. Thanks very much. Best regards Fal On Thu, Jan 3, 2013 at 6:40 AM, Howard Chu <hyc(a)symas.com> wrote: > fal patel wrote: > >> Hi Philip, >> >> hank you very much for your email. >> >> In that case, my original surmise is correct: The OpenLDAP >> Administrator's >> Guide's Section 18.3.3 "N-Way Multi-Master" definitely is buggy. >> Because my LDIF file is a direct copy thereof (except for my environment >> values substituted in instead of the labels such as $URI1, of course.) >> > > The example in 18.3.3 works perfectly when you substitute the correct > values in for the variables and follow the steps listed. > > > How can this be reported as a bug, please? (In OpenLDAP documentation >> or/and >> code). >> And can a *working* sample LDIF file be provided, please, for this >> important >> replication design, n-way multi-master? >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> >

3 3

authentication for users in referral branch
by Wu, James C. 04 Jan '13

04 Jan '13

Hi, I have sent out a relevant email about this issue before but the context was a little bit complicated. So I simplified the settings and post this issue again, hoping to get more attentions from this mailing list. I am trying to set up a testing environment in which there are two openldap servers and have one server (externalldap) refer to the second server (internalldap) for some users in a subtree (sub.example.com). Both servers contains some POSIX users. However, I could not get the authentication for the users in the referral branch to work. For example, this command fails. ldapwhoami -d -1 -x -H ldap://externalldap -D "uid=mark,ou=People,dc=sub,dc=example,dc=com" -w password The log of the externalldap shows as follows: 50e6279d bdb_dn2entry("uid=mark,ou=people,dc=sub,dc=example,dc=com") 50e6279d => bdb_dn2id("dc=example,dc=com") 50e6279d <= bdb_dn2id: got id=0x1 50e6279d => bdb_dn2id("dc=sub,dc=example,dc=com") 50e6279d <= bdb_dn2id: got id=0x6 50e6279d => bdb_dn2id("ou=people,dc=sub,dc=example,dc=com") 50e6279d <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) I am wondering why the externalldap did not just send the client the uri of the referral ldap box and have the client connect directly to the internalldap instead. Similarly error also happened when I use ldapsearch command ldapsearch -d -1 -x -H ldap:// externalldap -D "uid=mark,ou=People,dc=sub,dc=example,dc=com" -w password -CC The referral record is defined as follows and added into the external ldap using ldapadd command. dn: dc=sub,dc=example,dc=com objectClass: referral objectClass: extensibleObject dc: sub ref: ldap://10.42.13.212/dc=sub,dc=example,dc=com The slapd.conf of both the external and the internal ldap are defined as follows: #referral ldap://root.openldap.org pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=example;dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw password directory /usr/local/var/openldap-data # Indices to maintain index objectClass eq TLSCACertificateFile /etc/pki/tls/certs/example_cert.pem TLSCertificateFile /etc/pki/tls/certs/example_cert.pem TLSCertificateKeyFile /etc/pki/tls/certs/example_key.pem # configure the SASL parameters sasl-host localhost sasl-secprops none For the client, I am just using the default settings. I believe referral chasing is enabled by default in the ldap client library. I have spent more than two weeks on this problem and the project is delayed quite a lot. Referral in LDAP has been in RFC for more than five years. I can not believe that OpenLDAP's implementation of referral can't handle authentication. Can anyone kindly let me know what is missing from my setup? Regards, James

1 0

referral authentication
by Wu, James C. 03 Jan '13

03 Jan '13

Hi Kurt, I saw you once replied a question by Ming Hou about referral authentication. Could you let me know how to do it? I read through the man pages slap and slapd-ldap and still could not have it work. http://linux.die.net/man/5/slapd-ldap http://linux.die.net/man/8/slapd the rebind-as-user option does not seem to be supported by openldap. Regards, James

1 0

Re: Multi-Master OpenLDAP Replication for 3 nodes -- slapadd command failing
by fal patel 03 Jan '13

03 Jan '13

Hey Quanah, Oh no, my question was whether an arbitrary external variable (eg. URI1) could be set (eg. to ldap://host1.hq.mycompany.com:389/) inside an LDIF file and used in subsequent places in the file. (to avoid having to type in the value in multiple places). I suppose not? Assuming not, I typed in each value into all its relevant places in my LDIF file and re-ran slapadd. Now it gives me the following error (on latest redhat 64bit): loaded module syncprov.la *module syncprov.la: null module registered* Surely the above message signifies an error? Anyway, processing continues until it gives the following final error: >>> dnPrettyNormal: <cn=config> <<< dnPrettyNormal: <cn=config>, <cn=config> *<= str2entry: str2ad(changetype): attribute type undefined* slapadd: could not parse entry (line=48) Could you please advise? I have no clue as to what is going wrong. I have attached the LDIF file "nwaymmr2s.ldif" and the debug output from running the command slapadd -d -1 -v -F /etc/openldap/slapd.d -n 0 -l /etc/openldap/nwaymmr2s.ldif >& output.txt. Also, do I need to run slappasswd and copy the hash value from it into my LDIF' file's olcRootPW field value? Or can I just keep the original value, "secret"? And a final question, please: Why does the data replication (unlike the config replication, which does operate in refreshAndPersist mode) have to operate in refreshOnly mode? Why can't it operate in refreshAndPersist mode? Thank you very much. Fal On Mon, Dec 31, 2012 at 12:49 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Monday, December 31, 2012 9:49 AM -0800 fal patel < > fal0patel(a)gmail.com> wrote: > > Hey Quanah, >> >> Thank you very much for the debugging tip! -- Using it I got further in. >> Now I get an error "<= str2entry: str2ad(UR1): attribute type undefined". >> I must be setting my external variables (such as UR1) incorrectly in my >> LDIF file. >> What is the correct syntax for setting them, please? >> I tried each of the following sentences, none of which worked: >> URI1: ldap://host1.hq.mycompany.com:**389/<http://host1.hq.mycompany.com:389/> >> URI1: ldap://host1.hq.mycompany.com:**389<http://host1.hq.mycompany.com:389> >> URI1: "ldap://host1.hq.mycompany.**com:389/<http://host1.hq.mycompany.com:389/> >> " >> URI1="ldap://host1.hq.**mycompany.com:389/<http://host1.hq.mycompany.com:389/> >> " >> URI1="ldap://host1.hq.**mycompany.com:389<http://host1.hq.mycompany.com:389> >> " >> URI1 ldap://host1.hq.mycompany.com:**389/<http://host1.hq.mycompany.com:389/> >> > > There is no URI bit in the admin guide. I highly advise you go re-read > it. What you posted is clearly invalid. > > From the admin guide: >> > > ------------------------------**----------------------- > > Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc. > with your actual ldap urls): > > > dn: cn=config > changetype: modify > replace: olcServerID > olcServerID: 1 $URI1 > olcServerID: 2 $URI2 > olcServerID: 3 $URI3 > > ------------------------------**----------------------- > > I.e. the attribute name is "olcServerID". > > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

5 7

sasl Kerberos authentication with subordinate
by Wu, James C. 03 Jan '13

03 Jan '13

Hi, I am trying to set up an OpenLDAP and Kerberos authentication for testing purpose. The setup contains a pair of internal ldap server and Kerberos server and the pair of external ldap server and Kerberos server. I made the tree of the internal ldap server to be a subordinate of the external server and enabled the saslauthd for authentication on both the internal and the external ldap server to the respective Kerberos server. I have tested that the LDAP authentication through saslauthd using Kerberos works well on both the internal ldap and Kerberos pair and the external ldap Kerberos pair. However, when I point the client machine to the external ldap server and the add the subordinate relationship, I could not get the authentication for the uses in the internal ldap directory to work. For example, when I used "su - peter" where peter is a user in the external ldap server and the password is {SASL}peter(a)EXAMPLE.COM<mailto:%7bSASL%7dpeter@EXAMPLE.COM>. The authentication works. However, when I use "su - James" where james is a user defined in the internal ldap server with password {SASL}james(a)SUB.EXAMPLE.COM<mailto:%7bSASL%7djames@SUB.EXAMPLE.COM>, then the authentication failed. I check the log file, the internal server did get the search request forwarded from the external ldap server and returned the correct information back. However, I did not see the saslauthd process on either the external or the internal ldap server get any inquiry for the authentication. I tried to modify the /etc/krb5.conf and added the realms for both EXAMPLE.COM and SUB.EXAMPLE.COM. Still, the authentication does not work for users defined in the internal ldap server. Could anyone give me some hints for this issue? james

2 12

MDB Newbie
by Kyle Smith 02 Jan '13

02 Jan '13

Greetings and Salutations. December 20, I converted from bdb to mdb. Now my memory usage looks like this: http://faculty.ycp.edu/~ksmith8/openldap_stats.png I am concerned with the graph for "superman". How can I start tracking down the usage and why almost 50% of my memory is being consumed. These 4 are in MMR and are 2.4.33 and are nearly exact in server specification. Thanks in advance! Kyle Smith

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical