openldap-software

openldap-software@openldap.org

2719 discussions

Re: solaris compile options
by Brett ＠Google 24 Jan '10

24 Jan '10

i am using CFLAGS="-fast -xtarget=ultraT1 -xarch=sparcvis2 -xcode=pic32 -g -xs -O" one set of solaris docs i read implied that -xarch=sparcvis2 was equivalent to -xarch=v9 (which used to trigger 64 bit), but looking at the sun studio 12 compiler options, the more specific versions of -xarch (ie. other than -xarch=v9 or v9a or v9b) may no longer imply that the 64 bit memory model should be used. so maybe i need to add a -m64 to the above ? (compiling on a Sun T2000, with a homegenous build / execute environment, so favouring speed over cpu compatibility is ok) On Thu, Mar 12, 2009 at 1:31 AM, Aaron Richton <richton(a)nbcs.rutgers.edu>wrote: > On Wed, 11 Mar 2009, Brett @Google wrote: > > /data/openldap/backups/ldap_090302.ldif: Value too large for defined data >> type >> > > man lfcompile, and/or switch to 64-bit binaries? >

2 3

trouble setting initial replication between multiple masters
by Guillaume Rousse 19 Jan '10

19 Jan '10

Hello list. I'm trying to achieve multi-master setup, starting from a working single-master setup. I took the master node configuration, added the following directives, and distributed it identically on two nodes: # global serverID 1 ldap://10.202.11.8:389/ serverID 2 ldap://10.202.11.9:389/ # db ... syncrepl rid=1 provider=ldap://10.202.11.8:389/ starttls=yes tls_reqcert=never type=refreshAndPersist retry="60 +" logbase="cn=log" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog searchbase="dc=msr-inria,dc=inria,dc=fr" scope=sub schemachecking=off bindmethod=simple binddn="cn=syncrepl,ou=roles,dc=msr-inria,dc=inria,dc=fr" credentials=XYZ syncrepl rid=2 provider=ldap://10.202.11.9:389/ starttls=yes tls_reqcert=never type=refreshAndPersist retry="60 +" logbase="cn=log" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog searchbase="dc=msr-inria,dc=inria,dc=fr" scope=sub schemachecking=off bindmethod=simple binddn="cn=syncrepl,ou=roles,dc=msr-inria,dc=inria,dc=fr" credentials=XYZ mirrormode on The 'tls_reqcert=never' is needed because those two servers are accessed from a virtual interface under a load-balancing server, and the certificate name matches the name of this virtual interface, not the actual interface of the servers (I wonder if openldap would support altSubjName in x509 certs, but that's another issue). Then I imported my base in the first server, and launched both of them. When node1 (full) tries to access node2 (empty), it fails, because it can't authenticate with a DN still not present in other node database, which is quite understandable. However, node2 connects successfully, sync the the OU object in the DIT, then fails to actually sync the first user object, with this error message in his logs: Jan 13 11:29:20 avron2 slapd[20939]: null_callback : error code 0x13 Jan 13 11:29:20 avron2 slapd[20939]: syncrepl_entry: rid=001 be_add uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr (19) Jan 13 11:29:20 avron2 slapd[20939]: syncrepl_entry: rid=001 be_add uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr failed (19) Jan 13 11:29:20 avron2 slapd[20939]: do_syncrepl: rid=001 rc 19 retrying In node1 logs: Jan 13 10:28:31 avron1 slapd[15713]: conn=1000 op=1 BIND dn="cn=syncrepl,ou=roles,dc=msr-inria,dc=inria,dc=fr" method=128 Jan 13 10:28:31 avron1 slapd[15713]: conn=1000 op=1 BIND dn="cn=syncrepl,ou=roles,dc=msr-inria,dc=inria,dc=fr" mech=SIMPLE ssf=0 Jan 13 10:28:31 avron1 slapd[15713]: conn=1000 op=1 RESULT tag=97 err=0 text= Jan 13 10:28:31 avron1 slapd[15713]: conn=1000 op=2 SRCH base="dc=msr-inria,dc=inria,dc=fr" scope=2 deref=0 filter="(objectClass=*)" Jan 13 10:28:31 avron1 slapd[15713]: conn=1000 op=2 SRCH attr=* + Jan 13 10:28:31 avron1 slapd[15713]: send_search_entry: conn 1000 ber write failed. Jan 13 10:28:31 avron1 slapd[15713]: conn=1000 fd=21 closed (connection lost on write) It's hard to tell if the failure occurs on the provider (ber write failed message) or consumer side (null_callback : error code 0x13). Any hint welcome. -- BOFH excuse #288: Hard drive sleeping. Let it wake up on it's own...

2 2

referral with authentication
by "Sabine Hanß" 17 Jan '10

17 Jan '10

Hi list, I'm having some problems getting referrals working at the moment. I have a situation where not all user data is stored on one server, but distributed over two servers. Server A is always asked for user authentication, however in some cases that information wont be stored there but on server B instead. In fact with some users, absolutely no information will be stored about them at all on Server A. In these cases, server A has to refer to server B. There are in my opinion two patterns to do the referral: 1. Server A sends only the referral back to the client and the client itself asks Server B for authentication. 2. Through the configuration option overlay chain the server A sends the authentication to server B, which should then provide the validation, and then pass it back to the client. In my scenario the client (liferay portal - http://www.liferay.com) the client should do the referral. So I have tried using the Subordinate Knowledge style, which as I understand is the correct method for this type of authentication. I have checked also to see if any data at all is passed from server A to server B, but none at all is passed. When I search (with ldapsearch) users stored in server B I get as result the reference: # search reference ref: ldap://serverA:389/cn=subtree,dc=suffix??sub When I try to authenticate via a user stored in server B I get this error message: bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) The referral object I created on Server A was from the following ldif file: dn: cn=subtree,dc=suffix objectClass: referral objectClass: extensibleObject cn: subtree ref: ldap://serverA:389/cn=subtree,dc=suffix and I also set the ACLs to access to * by * read access to attrs=userPassword by anonymous auth I also tried the overlay chain, but I doubt if this is the right way to solve my problem. To except the case that the client does something wrong I'm looking for a client to simply test my scenario. ldapsearch can't test the authentication, I think. I now find myself quite lost as to what is going on and appreciate with some help from someone. Thank you and best regards Sabine -- Sabine Hanß *** email sabine.hanss(a)charite.de

1 0

idassert-bind, etc., assistance
by j＠gropefruit.com 17 Jan '10

17 Jan '10

Is there any way to use the idassert feature ONLY for anonymous connections, while allowing all other binddns to be directly proxied as themselves? I ask because we have root LDAP servers that have ACL configurations that work for our purposes, and we don't want to change them. We also do not allow anonymous binds to our root servers. To be clear, we do not want to change anything whatsoever on our root servers. however, some clients do need to be able to bind anonymously. We're ok with this, as long as anonymous is allowed against LDAP proxies only, and not on our root LDAP servers. This way, we can control what anonymous user sees. I am trying to make the proxy behave in the following ways: * authenticated non-admin Users may bind as themselves, they can see groups, etc., (anything non-confidential) but can only see their own account (we have this one working, but is an essential element of the larger picture) * anonymous users see all of the same non-sensitive material, but no user accounts whatsoever * there are proxybind users in our DIT, one for read-ops and one for write-ops. The writer-proxybind user typically is needed for changing a users' password, etc. The read user is the one that performs lookups for strictly read-only operations. He can see all users. If I set the idassert-bind to the read-only user, then no one can do writes. If i set it to the write-user, then everyone (even those who shouldn't) can do writes (except anonymous, which is good). The understanding I have is that we should be setting the proxy user in slapd's proxy config to be the highest-privileged user that we're ok with being "asserted". For example, we're not asserting to the rootdn or anything, rather we assert to a bind user that is designed to read the very information that the proxy is designed to lookup. Here is our running config, though its been hacked up so much you should understand its probably not perfect around the edges. Also ignore the comments as they haven't been updated with the rest of the real parameters. PS - I tried to upload as anonymous to your ftp and got this: local: j-gropefruit-100114.txt remote: j-gropefruit-100114.txt 229 Entering Extended Passive Mode (|||60518|) 553 j-gropefruit-100114.txt: Permission denied. So you'll just have to read it here: ################################### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/sudo.schema include /etc/ldap/schema/dhcp.schema include /etc/ldap/schema/samba.schema include /usr/share/doc/libpam-ldap/ldapns.schema include /etc/ldap/schema/hdb.schema include /etc/ldap/schema/uber.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats stats2 conns parse idletimeout 0 sizelimit unlimited timelimit unlimited defaultsearchbase dc=fake,dc=example,dc=com limits dn.regex="^uid=([^,]+).,cn=plain,*" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited access to dn.base="" by * read access to dn.base="cn=Subschema" by * read ## Load modules here modulepath /usr/lib/ldap moduleload back_relay moduleload back_ldap moduleload back_hdb moduleload pcache moduleload rwm.la ## SSL/TLS TLSCertificateFile /etc/ldap/ssl/wildcard.fake.example.com.crt TLSCertificateKeyFile /etc/ldap/ssl/wildcard.fake.example.com.key TLSCACertificateFile /etc/ldap/ssl/wildcard.fake.example.com.pem ## This is for SASL/GSSAPI authentication sasl-realm FAKE.EXAMPLE.COM sasl-host ds-fake-int.fake.example.com authz-regexp "uid=$.*$,cn=FAKE.EXAMPLE.COM,cn=gssapi,cn=auth" "uid=$1,cn=plain,cn=auth,dc=real,dc=example,dc=com" authz-regexp "uid=$.*$,cn=DEV.EXAMPLE.COM,cn=gssapi,cn=auth" "uid=$1,cn=plain,cn=auth,cn=dev,dc=real,dc=example,dc=com" ## Define the actual 'database', as referenced by the suffix. database ldap uri ldaps://10.9.8.7:636/ suffix "dc=real,dc=example,dc=com" rootdn "uid=rootdn,cn=plain,cn=auth,dc=real,dc=example,dc=com" overlay rwm rwm-rewriteEngine on # all dataflow from server to client rwm-rewriteContext searchEntryDN rwm-rewriteRule "(.+,)?dc=real,dc=example,dc=com$" "$1dc=fake,dc=example,dc=com" ## When proxying information, configure what identity to assert. #acl-bind # bindmethod="simple" # binddn="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" # credentials="pass" # starttls="no" # tls_reqcert="never" idassert-bind bindmethod="simple" binddn="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" credentials="pass" starttls="no" tls_reqcert="never" mode="legacy" flags="override,non-prescriptive" idassert-authzFrom "dn.subtree:cn=plain,cn=auth,dc=real,dc=example,dc=com" idassert-authzFrom "dn.subtree:cn=plain,cn=auth,dc=real,dc=example,dc=com" idassert-authzFrom "dn.exact:" chase-referrals NO rebind-as-user NO ## Cache data for PERFORMANCE - this only works when the upstream proxy ## is online. There's no way to cache data in its entirety if the provider ## goes down (that's what actual replication is for). overlay pcache proxycache hdb 2000 5 100 1800 directory "/var/lib/ldap/cache" dbconfig set_cachesize 0 4097152 0 dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 1048576 dbconfig set_lg_dir /var/lib/ldap/cache dbconfig set_tmp_dir /tmp index uid,cn,sn,givenName eq,sub index uidNumber,gidNumber eq index homeDirectory,loginShell,gecos,objectClass eq proxycachequeries 10000 proxyattrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass proxytemplate (&(objectclass=)(uidNumber=)) 0 1200 proxytemplate (&(objectclass=)(uid=)) 0 1200 proxyattrset 1 objectclass proxytemplate (objectclass=) 1 1200 proxyattrset 2 uid proxytemplate (uid=) 2 1200 proxyattrset 3 cn nisNetgroupTriple memberNisNetgroup proxytemplate (&(objectClass=)(cn=)) 3 1200 proxyattrset 4 gidNumber proxytemplate (&(objectClass=)(memberUid=)) 4 1200 ## Set a global rule to allow everything to our service/proxy users, then forbid ## all others access, but BREAK the rule so it keeps processing the rest of the rules, ## which are all much less-permissive ... access to dn.subtree="dc=real,dc=example,dc=com" by group/groupOfUniqueNames/uniqueMember="cn=ldapadmin,cn=ldap,cn=groups,dc=real,dc=example,dc=com" write by dn.regex="^uid=plain$modify|change$,cn=plain,cn=auth,dc=real,dc=example,dc=com" write by dn.regex="^uid=plain$proxy|agent$,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break access to attrs=userPassword by self =w by * =x ## OMFGZZZZ the Solipsism rule - if you touch this I will kill you. ## This fixes the MUST-BIND-AS-SELF logic problem with Sun VDI access to dn.regex="^uid=([^,]+),cn=plain,cn=auth,dc=real,dc=example,dc=com" by dn.base,expand="uid=$1,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break ########## Relay Instance for the "fake" zone database relay suffix dc=fake,dc=example,dc=com relay dc=real,dc=example,dc=com overlay rwm rwm-suffixmassage dc=real,dc=example,dc=com rwm-rewriteEngine on rwm-normalize-mapped-attrs yes rwm-rewriteContext searchAttrDN rwm-rewriteRule "(.+,)?dc=real,dc=example,dc=com$" "$1dc=fake,dc=example,dc=com" access to dn.subtree="dc=fake,dc=example,dc=com" by group/groupOfUniqueNames/uniqueMember="cn=ldapadmin,cn=ldap,cn=groups,dc=real,dc=example,dc=com" write by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainagent,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break access to dn.children="cn=plain,cn=auth,dc=fake,dc=example,dc=com" attrs=userPassword filter=(&(uid=*)(|(objectClass=posixAccount)(objectClass=simpleSecurityObject)(objectClass=shadowAccount)(objectClass=inetOrgPerson)(objectClass=account))) by self write by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" write by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" write by anonymous auth by * none break access to dn.children="cn=plain,cn=auth,dc=fake,dc=example,dc=com" filter=(&(uid=*)(|(objectClass=posixAccount)(objectClass=simpleSecurityObject)(objectClass=shadowAccount)(objectClass=inetOrgPerson)(objectClass=account))) by self read by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainagent,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break access to dn.subtree="cn=groups,dc=fake,dc=example,dc=com" filter=(|(objectClass=posixGroup)(objectClass=nisNetgroup)(objectClass=groupOfUniqueNames)(objectClass=groupOfNames)(objectClass=organizationalRole)) by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainagent,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by anonymous read by * none break access to dn.onelevel="cn=gssapi,cn=auth,dc=fake,dc=example,dc=com" by dn="uidNumber=0+gidNumber=0,cn=peercred,cn=external,cn=auth" read by * none break access to dn.onelevel="cn=FAKE.EXAMPLE.COM,cn=gssapi,cn=auth,dc=fake,dc=example,dc=com" by dn="uidNumber=0+gidNumber=0,cn=peercred,cn=external,cn=auth" write by * none break access to dn.subtree="cn=sys,dc=fake,dc=example,dc=com" by * read access to dn.subtree="cn=tester,dc=fake,dc=example,dc=com" by * read access to dn.subtree="cn=dev,dc=fake,dc=example,dc=com" by * none access to dn.subtree="cn=elements,dc=fake,dc=example,dc=com" by * none ################################### The man pages and examples on OpenLDAP.org have helped tremendously, but I need some living & breathing opinions. Thanks J

2 1

n-way multimaster replication slapd.conf
by DT Piotr Wadas 16 Jan '10

16 Jan '10

Hello, Using openldap 2.4.17. I've read this: http://www.openldap.org/doc/admin24/replication.html#N-Way Multi-Master Is there a way to setup N-Way multimaster via slapd.conf , not by cn=config? After I configure it with cn=config, will it be stored after slapd restart - where and how? Regards, DT

1 1

start_tls: connect error
by Dieter Kluenter 14 Jan '10

14 Jan '10

Hi, I just wonder whether this is a bug in openSSL or in openLDAP, anyhow the subjectAltName attribute values are nor honoured. openssl-0.9.8k-3.5.3.x86_64 openldap-2.4.21 ldapwhoami -Y EXTERNAL -ZZ -H ldap://localhost ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate openssl x509 -in cert.pem -noout -text Subject: C=DE, L=Hamburg, O=AVCI, OU=Certificate Authority, CN=rubin.avci.de/emailAddress=hdk(a)dkluenter.de ... X509v3 Subject Alternative Name: DNS:localhost, DNS:ldap.xxxx.de, DNS:dkluenter.xxxx.org Not to mention that this is OK with other versions of openldap and openssl. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°37'09,95"N 10°08'02,42"E

5 9

multiple replication scenarios questions
by Guillaume Rousse 13 Jan '10

13 Jan '10

Hello list. I had a look at section 18 of the admin manual, as I was trying to figure difference between scenarios 18.2.2 (N-way multi-master) and 18.2.3 (mirror mode). Whereas the descriptions of both scenarios are quite clear, given examples configuration are quite confusing (at least for me). First, they are quite hard to compare, as the first one uses LDIF syntax, whereas the second uses the classical file configuration syntax. Second, they both use the same directives: - a different serverId for each nodes - mirrormode on for each nodes - syncrepl directives for each nodes The only difference being than for multi-master, each node has syncrepl directives for each nodes (including himself), whereas for mirrror mode, each node only has syncrepl directives for other nodes. But it's hard to figure if that's because of the replication scenario, or just because in the first case, the configuration has to be identical everyhwere given that it's replicated automatically. So, what is supposed to be different at configuration level between those two scenarios ? Additonal question: doesn't a classical single-master + multiple slaves scenarios, where each slave use chain overlay to automatically forward all changes to the master, also achieve exactly what is described in the mirror mode description ? -- BOFH excuse #248: Too much radiation coming from the soil.

3 2

Re: Admin Guide: Tuning 21.1.2 Disks and virtual servers
by Gavin Henry 13 Jan '10

13 Jan '10

----- "Francis Swasey" <Frank.Swasey(a)uvm.edu> wrote: > Is the info in this section intended for only physical LDAP servers or > > for servers that are virtual (such as VMware) as well? > Physical servers are faster as you have more control over the disks that aren't shared underneath. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

6 6

DN Validation
by Tod Schmidt 13 Jan '10

13 Jan '10

I am running into an issue when trying to rewrite the bindDN where the function ldap_bv2dn is called before rewriting and rejecting certain dn values. Specifically I am trying to bind using just the email address, in the form "user(a)host.net" however this gets flagged and returns -4, ldap decoding error. >>> dnPrettyNormal: <user(a)host.net> => ldap_bv2dn(user(a)host.net,0) ldap_err2string <= ldap_bv2dn(user(a)host.net)=-4 Decoding error bind: invalid dn (user(a)host.net) send_ldap_result: conn=0 op=0 p=3 send_ldap_result: err=34 matched="" text="invalid DN" Using an attribute form, "mail=user(a)host.net" gets properly passed to the rewrite function and all works as expected. My question is whether there is any way around the validation that is performed before the rewrite beyond hacking the source code. Any help is appreciated. Thanks, Tod Schmidt

1 0

Re: searching using component matching feature
by med s 11 Jan '10

11 Jan '10

I am using openLDAP 2.4.20 and BDB 4.8.24 On 1/11/10, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Friday, January 08, 2010 1:41 AM -0800 med s <medinaseid(a)gmail.com> > wrote: > >> hello. >> I have successfully compiled openldap and the comp_match module >> but when seraching it outputs the following error on the server > > What OpenLDAP Version? > > What BDB version? Is the BDB version fully patched? > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software