Mirror mode with additional consumer
by Jens Thomas
Hi,
i am new at this list, please forgive me my broken english.
I have two questions, first, is it possible to setup two slapd (2.4.x)
in mirror mode and add later one or more additional consumer slapd
with syncrepl? The goal is to have a 2-server-HA system (where one
server is always writeable) and distributed cache slapd's. Are there
theoretical issues?
A second problem, maybe you can give me a pointer: I would like to
assign the right to add, modify and delete an object to an attribute
inside the same object (and necessarily to the container object).
Maybe ACI and the corresponding overlay is what i need. Or can this be
solved by using regex?
Thanks a lot,
with kind regards
Jens
--
linux systeme thomas
Jens Thomas
Völklinger Straße 9
42285 Wuppertal
Telefon: +49.202.3097507
Mobil: +49.177.9301386
eFax: +49.202.85064329
Web: http://linux-systeme-thomas.de
USt-ID: DE250711901
14 years, 4 months
Re: get_ava: illegal value with translucent proxy
by Petteri Heinonen
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
--
14 years, 4 months
send_search_entry: conn 9279837 ber write failed
by jakjr
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
14 years, 4 months
ACL on referral object (chaining) does not work
by Kay.Kirchhoefer＠t-systems.com
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
14 years, 4 months
get_ava: illegal value with translucent proxy
by Petteri Heinonen
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
14 years, 4 months
Problem - ldapadd invalid syntex (21)
by Bruno Steven
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
14 years, 4 months
syncrepl and "no equality matching rule"
by Alain ZAMBONI
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
14 years, 4 months
access control
by Darryl Moore
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
14 years, 4 months
Dying LDAP process and TLS
by Florian Götz
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
-----
14 years, 4 months
Propagation of proxyAuthz control
by Javier Manteiga
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
14 years, 4 months
