openldap-technical

openldap-technical@openldap.org

18 participants
9897 discussions

Re: get_ava: illegal value with translucent proxy
by Petteri Heinonen 28 Jul '09

28 Jul '09

Pierangelo Masarati [masarati(a)aero.polimi.it] wrote: > Petteri Heinonen wrote: > > Hi, I've setup a translucent proxy. Now, I have tried to do some test > > searches. For example this works ok: > > > > ldapsearch -x -W -D "cn=admin,dc=company,dc=com" -b > > "OU=Users,OU=Department,DC=company,DC=com" "(givenName=Myname)" > > > > Search is proxied through proxy to the actual server, and correct result > > is returned. However, if I try this: > > > > ldapsearch -x -W -D "cn=admin,dc=company,dc=com" -b > > "OU=Users,OU=Department,DC=company,DC=com" "(objectClass=User)" > > > > I get no results. I have monitored the traffic between proxy and backend > > server, and the query is not even sent there. In OpenLDAP log there is: > > > > Jul 27 15:51:00 ldaptr01 slapd[17772]: begin get_filter > > Jul 27 15:51:00 ldaptr01 slapd[17772]: EQUALITY > > Jul 27 15:51:00 ldaptr01 slapd[17772]: get_ava: illegal value for > > attributeType objectClass > > Jul 27 15:51:00 ldaptr01 slapd[17772]: end get_filter 0 > > > > What would be the problem here? > > The objectClass "User" is not defined in the proxy's schema? > > p. > That's correct. But in translucent overlay's documentation, there is: "Note: The Translucent Proxy overlay will disable schema checking in the local database, so that an entry consisting of overlay attributes need not adhere to the complete schema." But it seems that schema checking is still in affect when doing searches. Is there a way to disable local schema checking altogether? Or do I have to build some dummy schema so that OpenLDAP is aware about objectClasses I want to search for? -Petteri Heinonen --

2 1

send_search_entry: conn 9279837 ber write failed
by jakjr 27 Jul '09

27 Jul '09

Hello, some time ago I upgraded our server to version 2.4.16. Since then, for 3 times, the server hangs with this message: Jul 27 09:31:50 sseed0013 slapd[22555]: conn=9279837 fd=110 ACCEPT from IP=XXX.XXX.XXX.XX:41577 (IP=0.0.0.0:389) Jul 27 09:31:50 sseed0013 slapd[22555]: conn=9279837 op=0 BIND dn="cn=admin" method=128 Jul 27 09:31:50 sseed0013 slapd[22555]: conn=9279837 op=0 BIND dn="cn=admin" mech=SIMPLE ssf=0 Jul 27 09:31:50 sseed0013 slapd[22555]: conn=9279837 op=0 RESULT tag=97 err=0 text= Jul 27 09:31:50 sseed0013 slapd[22555]: conn=9279837 op=1 SRCH base="ou=seed" scope=2 deref=0 filter="(&(uidNumber=12916)(phpgwAccountType=u))" Jul 27 09:31:50 sseed0013 slapd[22555]: conn=9279837 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Jul 27 09:31:50 sseed0013 slapd[22555]: conn=9279837 op=2 SRCH base="ou=seed" scope=2 deref=0 filter="(&(uidNumber=12916)(phpgwAccountType=u))" Jul 27 09:31:50 sseed0013 slapd[22555]: conn=9279837 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Jul 27 09:31:51 sseed0013 slapd[22555]: conn=9279837 op=3 SRCH base="ou=seed" scope=2 deref=0 filter="(uidNumber=12916)" Jul 27 09:31:51 sseed0013 slapd[22555]: conn=9279837 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= Jul 27 09:31:51 sseed0013 slapd[22555]: conn=9279837 op=4 SRCH base="ou=seed" scope=2 deref=0 filter="(&(uidNumber=12916)(phpgwAccountType=u))" Jul 27 09:31:51 sseed0013 slapd[22555]: conn=9279837 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text= Jul 27 09:31:51 sseed0013 slapd[22555]: conn=9279837 op=5 SRCH base="ou=seed" scope=2 deref=0 filter="(&(gidNumber=20877)(phpgwAccountType=g))" Jul 27 09:32:33 sseed0013 slapd[22555]: conn=9279837 op=6 SRCH base="ou=seed" scope=2 deref=0 filter="(&(uidNumber=20877)(phpgwAccountType=u))" Jul 27 09:32:36 sseed0013 slapd[22555]: conn=9279837 op=6 SEARCH RESULT tag=101 err=0 nentries=0 text= *Jul 27 09:32:42 sseed0013 slapd[22555]: send_search_entry: conn 9279837 ber write failed.* The config and load of this server is almost the same of the old version (2.3.30) Thanks for any tip, Regards, João Alfredo

2 2

ACL on referral object (chaining) does not work
by Kay.Kirchhoefer＠t-systems.com 27 Jul '09

27 Jul '09

Hi, I have a question regarding ACL used together with chaining overlay configuration. I´m building several ldap servers which should chain each other, based on the selected path. I now wanted to prevent a chaining loop by using ACLs, but that doesn´t work for me. It seems like the ACL is not used for the referral objects. sample referral object: dn: o=testldap2,c=de objectClass: referral objectClass: extensibleObject o=testldap2 ref: ldap://testldap2/c=de <ldap://testldap2/c=de> chaining config: overlay chain chain-uri ldap://testldap2 <ldap://testldap2> chain-rebind-as-user yes chain-idassert-bind bindmethod="simple" binddn="cn=xxxxxx" credentials="yyyy" mode="self" chain-max-depth 1 chain-return-error TRUE ACL config: access to dn.base="o=testldap2,c=de" by peername.ip=192.168.1.1 none by * read 192.168.1.1 is the ip address of "testldap2". Everytime a request from this ip occurs, the server should block the access to the (referral) object because it must be a "chained" request But that doesn´t work. Also the parameter "chain-max-depth" seems not to work. I´m currently using OpenLDAP version 2.3.20 (but I also tried the latest one). Yours sincerely, Kay

2 1

get_ava: illegal value with translucent proxy
by Petteri Heinonen 27 Jul '09

27 Jul '09

Hi, I've setup a translucent proxy. Now, I have tried to do some test searches. For example this works ok: ldapsearch -x -W -D "cn=admin,dc=company,dc=com" -b "OU=Users,OU=Department,DC=company,DC=com" "(givenName=Myname)" Search is proxied through proxy to the actual server, and correct result is returned. However, if I try this: ldapsearch -x -W -D "cn=admin,dc=company,dc=com" -b "OU=Users,OU=Department,DC=company,DC=com" "(objectClass=User)" I get no results. I have monitored the traffic between proxy and backend server, and the query is not even sent there. In OpenLDAP log there is: Jul 27 15:51:00 ldaptr01 slapd[17772]: begin get_filter Jul 27 15:51:00 ldaptr01 slapd[17772]: EQUALITY Jul 27 15:51:00 ldaptr01 slapd[17772]: get_ava: illegal value for attributeType objectClass Jul 27 15:51:00 ldaptr01 slapd[17772]: end get_filter 0 What would be the problem here? Regards, Petteri Heinonen

2 1

Problem - ldapadd invalid syntex (21)
by Bruno Steven 24 Jul '09

24 Jul '09

Hello I am newbie in use OpenLdap , I have simple problem I can´t add structure of tree directory, the file org.lidf show my structure dn: dc=labcom,dc=factory objectClass: top objectClass: dcObject #objectClass: organization dc: labcom o : Linuxtech When I type this command ldapadd -f /etc/openldap/lidfs/org.ldif -x -D "cn=adm,dc=labcom,dc=factory" -W Show this message error Enter LDAP Password: adding new entry "dc=labcom,dc=factory " ldapadd: Invalid syntax (21) Why this message error ? I have include the follow schemas include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema The process slapd have been started by user root, so haven´t problem of permission That is ... Thanks -- Bruno Steven - Administrador de sistemas. LPIC-1 - LPI ID: lpi000119659 / Code: p2e4wz47e4 https://www.lpi.org/caf/Xamman/certification MCP-Windows 2003 - TranscriptID: 793804 / Access Code: 080089100 https://mcp.microsoft.com/authenticate/validatemcp.aspx

4 5

syncrepl and "no equality matching rule"
by Alain ZAMBONI 24 Jul '09

24 Jul '09

Hello, I run an LDAP directory on 3 servers : one master, and two slaves, synchronised with syncrepl. The 3 servers are running FreeBSD 7.0 and openLDAP 2.4.13. I encountered yesterday an issue with syncrepl that should have been solved with openLDAP 2.4.13 http://www.openldap.org/lists/openldap-software/200812/msg00040.html The synchronisation was blocking on the deletion of a facsimileTelephoneNumber. When the problem occured, the master entry was (only showing the facsimileTelephoneNumber attribute) : dn: uid=veinantep,ou=uds,ou=people,o=annuaire facsimileTelephoneNumber: 0388613347 And the slave entry was : dn: uid=veinantep,ou=uds,ou=people,o=annuaire facsimileTelephoneNumber: 0388612908 facsimileTelephoneNumber: 0388613347 The application doing the modification on the master is always using a "replace" operation, to avoid the "no equality matching rule" problem. It seems that syncrepl tries to synchronise the slave by generating the forbidden operation of deleting a precise facsimileTelephoneNumber. Is this problem known ? the release between 2.4.13 and 2.4.16 don't mentionned something about it. I managed to unlock the situation by completely deleting the "facsimileTelephoneNumber" on the master, then adding it again. The big problem of this little issue is that it is blocking all the synchronisation process between master and slaves ... By the way, is there a way to check the good state of the synchronisation with syncrepl (besides parsing the sync logs or doing recurring diff between the servers) ? I must admit that I miss slurpd's .rej files. Just in case, here are the log of one of the slaves : syncrepl_entry: rid=101 be_search (0) syncrepl_entry: rid=101 uid=veinantep,ou=uds,ou=people,o=annuaire bdb_modify: uid=veinantep,ou=uds,ou=people,o=annuaire bdb_dn2entry("uid=veinantep,ou=uds,ou=people,o=annuaire") bdb_modify_internal: 0x0001fc23: uid=veinantep,ou=uds,ou=people,o=annuaire <= acl_access_allowed: granted to database root bdb_modify_internal: delete facsimileTelephoneNumber bdb_modify_internal: 18 modify/delete: facsimileTelephoneNumber: no equality matching rule bdb_modify: modify failed (18) send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=18 matched="" text="modify/delete: facsimileTelephoneNumber: no equality matching rule" null_callback : error code 0x12 syncrepl_entry: rid=101 be_modify (18) syncrepl_entry: rid=101 be_modify failed (18) Thanks, -- Alain ZAMBONI Direction Informatique Université de Strasbourg

2 2

access control
by Darryl Moore 24 Jul '09

24 Jul '09

I'm trying to set up access controls for the server. Here are the rules I am trying to impliment olcAccess: {0}to attrs=userPassword,shadowLastChange by anonymous auth by self write by * none olcAccess: {1}to dn.regex="ou=Contacts,uid=([^,]+),ou=People,dc=moores,dc=ca$" by dn.exact,expand="uid=$1,ou=People,dc=moores,dc=ca" write by * none olcAccess: {2}to dn.regex="ou=Contacts,cn=([^,]+),ou=Groups,dc=moores,dc=ca$" by group.exact,expand="cn=$1,ou=Groups,dc=moores,dc=ca" write by * none olcAccess: {3}to dn.regex="cn=([^,]+),ou=Groups,dc=moores,dc=ca$" by group.exact,expand="cn=Admin,cn=$1,ou=Groups,dc=moores,dc=ca" write by group="cn=Management,ou=Groups,dc=moores,dc=ca" write by users read olcAccess: {4}to dn.base="ou=Groups,dc=moores,dc=ca$" by group.exact="cn=Management,ou=Groups,dc=moores,dc=ca$" write by users read olcAccess: {5}to dn.base="ou=People,dc=moores,dc=ca$" by group.exact="cn=Management,ou=Groups,dc=moores,dc=ca$" write by users read olcAccess: {6}to * by users read by * none - Basically I have groups, and within those groups I have Contact lists and administrators. I want the administrator to have write access, other members to have read access, and non members to have none. This rule is what I think should work for that: dn.regex="ou=Contacts,cn=([^,]+),ou=Groups,dc=moores,dc=ca$" by group.exact,expand="cn=$1,ou=Groups,dc=moores,dc=ca" write by * none I know this rule works for individual user contact lists: dn.regex="ou=Contacts,uid=([^,]+),ou=People,dc=moores,dc=ca$" by dn.exact,expand="uid=$1,ou=People,dc=moores,dc=ca" write by * none I think the problem I am running into is having the <who> field as group.exact,expand Can I not do this? If not, is there any way to acheive the same result? thanks, darryl

3 5

Dying LDAP process and TLS
by Florian Götz 24 Jul '09

24 Jul '09

Hello everybody, I got some two serious problems with my LDAP, maybe you got a hint for it. Problem 1 might have a connection to nr 2, but I´m not sure. I use OpenLDAP 2.4.12 on a SLES11 system. The initscript to start/stop the service called "rcldap" know 3 states: unused, running and dead. When I startup the LDAP it´s in state running. It takes about 10-15min, the LDAP doesn´t respond anymore and a "rcldap status" tells me that the service is dead. I have no clue why it behaves this way. The logs tell me, that the Backup-System fetches some data and then the log ends without any further notice. The pid file still exists, but the process is gone. Problem 2 has to do with TLS. I got the CA of our (sub)company, a certificate for the ldap-machine and the associated private key file. The certificate chain is: Deutsche Telekom Root CA -> Company CA -> Subcompany CA -> Certificate of LDAP machine. The certificate for the ldap machine seems to be generated with/by the Company CA. If I put these files into the slapd config with: TLSCACertificateFile /etc/openldap/certs/SubcompanyCA.pem TLSCertificateFile /etc/openldap/certs/ldapcert.pem TLSCertificateKeyFile /etc/openldap/certs/ldapprivkey.pem TLSVerifyClient demand and the following lines in the /etc/ldap.conf: TLS_CACERT /etc/openldap/certs/SubcompanyCA.pem TLS_REQCERT demand it crashes at the TLS certificate verification, because he can´t get the local issuer certificate. If I use the Company CAs in both places instead of the Subcompany CA it´s failing too. If I mix it up with the SubcompanyCA in the slapd.conf and the CompanyCA in the ldap.conf, the certificate verification succeeds, but I get a TLS trace: SSL3 alert read:fatal:handshake failure I don´t know how to handle that problem. -- Best regards, Florian Götz -----

2 1

Propagation of proxyAuthz control
by Javier Manteiga 24 Jul '09

24 Jul '09

Hi all, We are trying to set a system with the DIT split in several servers, using the Meta backend to proxy the LDAP requests among them. In the remote servers we would like to check the ACLs using the identity of the client that sent the request, instead of the identity used to create the proxy connections. For this we have configured the idassert parameters in the meta targets as follows: idassert-bind bindmethod=simple binddn="cn=manager,dc=operator,dc=com" (root user of the backend receiving the proxied query) credentials="manager" mode=self iddassert-authzFrom "dn:*" When the first proxy is made everything is OK. The proxyAuthz extension control is added to the LDAP message and the remote server behaves as expected. Our problem is that in some cases we have requests that must be proxied several times. E.g: consider a scenario with three servers in A, B and C. in which the LDAP request sent by the external client is received in A, this server proxies it to B. Finally B proxies it to C. When B tries to set the proxyAuthz control it detects that there is already one and it returns the error "proxyAuthz not allowed within namingContext". Is there anyway in which we can avoid this error and propagate the credentials of the external client to the last server?. Thank you very much for your help. Best regards. Javier Manteiga

2 1

ACL processing performance
by Christian Manal 24 Jul '09

24 Jul '09

Hi, I've got a question regarding ACLs and their processing performance. I use the NIS-schema to store userinformation and the likes in OpenLDAP (using the maps passwd, group, services, ethers, hosts, automount stuff etc.) plus samba-schema plus some self defined stuff. I have ACLs defined for some special attributes, like userPassword, and for each OU (People, Groups, ...). If I start multiple searches without a filter (so everythin accessible will be displayed) anonymously or with some user, I can get the CPU load of my servers up to 80-90%. It's definitely the ACLs, since I have no problems when using the rootDN or if I reduce the ACLs. What I'd like to know now is, what is so damn expensive in my ACLs and how I could reduce the cost without lessening the access restrictions... OpenLDAP version is 2.4.17 using back-hdb with BDB 4.4 from opencsw respository on Solaris 10 (SunOS 5.10 Generic_139556-08). There are around 30k entries in my database. I have one master and four slaves using delta-syncrepl for replication. Configuration files can be found here: http://www.informatik.uni-bremen.de/~moenoel/ldap/ Thanks in advance. Regards, Christian Manal

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical