Replication problem
by Luiz Gustavo P Tonello
Hi Folks!
I have a problem with replication between ldap master and slave.
When I change password, add new user or delete user, my slurpd.replog grows absurdly (like 1GB, 2GB the each minute).
And my command not complete, because I need put Ctrl+C for can back my console.
Well, that's situation don't repeat ever. Sometimes, I can execute all commands normally (smbldap-usershow, useradd, userdel, etc.), and a replication occur perfectly.
Any ideas for this problem?
BTW: When slurpd.replog growing, and I open this file, see that this repeat any times, like a loop, right?
Thank's for any kind of help!
--
Luiz Gustavo P Tonello.
11 years, 10 months
Allow creation of one single entry (own addressbook)
by Lukas Haase
Hi,
I adopted the address book sample from the FAQ but I want to have a
separate hierarchy. Also included there: The public address book.
Why? Because on the client I need to enter only one base and the global book automatically merges with the global one.
This are my current ACLs:
# admin is allowed to do all
access to *
by dn.exact="uid=admin,ou=int,ou=users,dc=example,dc=com" write
by * break
access to attrs=userPassword
by anonymous auth
by self =wscx
by * none
access to attrs=shadowLastChange,sambaNTPassword,sambaLMPassword
by self =wscx
by * none
# individual books
# read the own book
access to dn.regex="^ou=([^,]+),ou=Address Book,dc=example,dc=com$" attrs=entry,@organizationalUnit
by dn.exact,expand="uid=$1,ou=int,ou=users,dc=example,dc=com" read
by * break
# create children in address book
access to dn.regex="^ou=([^,]+),ou=Address Book,dc=example,dc=com$" attrs=children
by dn.exact,expand="uid=$1,ou=int,ou=users,dc=example,dc=com" write
by * break
# create entries
access to dn.regex="[^,]+,ou=([^,]+),ou=Address Book,dc=example,dc=com$" attrs=entry,@inetOrgPerson
by dn.exact,expand="uid=$1,ou=int,ou=users,dc=example,dc=com" write
by * break
# global
access to dn.exact="ou=Address Book,dc=example,dc=com"
by dn.regex="^uid=[^,]+,ou=int,ou=users,dc=example,dc=com$" read
by * break
access to dn.subtree="ou=global,ou=Address Book,dc=example,dc=com"
by dn.regex="^uid=[^,]+,ou=int,ou=users,dc=example,dc=com$" read
by * break
# "reader" should be able to read anything else (libnss-ldap etc).
access to *
by dn="uid=reader,dc=example,dc=com" read
by self read
by * none
Now I want the users to be also able to create their own container under ou=Address book.
What is the correct ACL entry for that?
Best regards,
Luke
PS: Is the ACL layout bad in common? What would you change?
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
11 years, 10 months
Do we need Berkeley DB's Concurrent Data Store for Concurrency in OpenLDAP
by dfas dfas
Hi,
I am currently looking to implement an OpenLDAP solution with a BDB backend that needs to support concurrent access by multiple users. As there are different flavours of the Berkeley DB available, can I just ask if we need to purchase the Concurrent Data Store version of Berkeley DB or can I just stay with the Data Store version?
I ask this because OpenLDAP already has its own concurrency support and I was just wondering if this implies that OpenLDAP will ensure that BDB will only be accessed thru a single thread of control?
Any help will be greatly appreciated. Thanks.
New Email names for you!
Get the Email name you've always wanted on the new @ymail and @rocketmail.
Hurry before someone else does!
http://mail.promotions.yahoo.com/newdomains/sg/
11 years, 10 months
Re: changing userPassword from custom application
by Quanah Gibson-Mount
--On Tuesday, December 15, 2009 12:28 PM +0000 "J. Landamore"
<jal(a)mcs.le.ac.uk> wrote:
> Sorry to butt in on this, but how do you let the OpenLDAP server use its
> default encryption? Since 2.4 whatever I have done stores the
> userPassword attribute in clear text when using passwd(1) from our Linux
> or Solaris boxes. ldappasswd states that is not a replacement for
> passwd(1), what I'd like is to return to the state in OpenLDAP-2.2 and
> previous where the passwords were stored encrypted in some fashion.
> I've been banging my head about this for 3 months so any pointers would be
> very much appreciated.
If you have questions, please keep them on the list. Thanks.
<http://www.openldap.org/software/man.cgi?query=slapd.conf&apropos=0&sekti...>
password-hash <hash> [<hash>...]
This option configures one or more hashes to be used in
generation of user passwords stored in the userPassword
attribute during processing of LDAP Password Modify Extended
Operations (RFC 3062). The <hash> must be one of {SSHA}, {SHA},
{SMD5}, {MD5}, {CRYPT}, and {CLEARTEXT}. The default is {SSHA}.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
11 years, 10 months
OpenLDAP syncrepl message: AttributeDescription contains inappropriate characters
by Jorgen Lundman
openldap-2.3.41
db-4.2.52.NC-PLUS_5_PATCHES
SunOS ldapmaster01.unix 5.10 Generic_127128-11
Our LDAP setup has been running rather well for the last 2 years or so, but
increasingly we have had to restart slapd more and more frequently. Occasional
core-dumps and "very large" process footprints as well.
I suspect that it is perhaps stuck on replication, this message show up on the
clients fairly frequently:
Dec 14 11:30:49 forward01.unix slapd[10494]: [ID 190661 local4.debug] <=
entry_decode: slap_str2undef_ad( 20091027142315Z#000001#00#000000):
AttributeDescription contains inappropriate characters
Dec 14 11:30:49 forward01.unix slapd[10494]: [ID 818565 local4.debug]
null_callback: error code 0x50
Dec 14 11:30:49 forward01.unix slapd[10494]: [ID 776556 local4.debug]
syncrepl_entry: rid 405 be_add failed (80)
Dec 14 11:30:49 forward01.unix slapd[10494]: [ID 747041 local4.debug]
do_syncrepl: rid 405 retrying (9 retries left)
Which makes me think that it has been stuck since 20091027. Is there a way for
me to find out which entry 20091027142315Z#000001#00#000000 refers to, so I can
just delete it? (or fix it).
The pertinent lines in ldapmaster are:
lastmod on
checkpoint 128 15
directory /usr/local/var/openldap-data
index objectClass eq
index uid eq
index uidNumber eq
index mail eq
index mailAlternateAddress pres,eq
index deliveryMode eq
index accountStatus eq
index gecos eq
index radiusGroupName eq
index o pres,eq
index entryCSN,entryUUID eq
index gidNumber eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
And each slave has identical conf, except for the RID which is based on the last
octet of the IP address:
lastmod on
checkpoint 128 15
directory /usr/local/var/openldap-data
index objectClass eq
index uid eq
index uidNumber eq
index mail eq
index mailAlternateAddress pres,eq
index deliveryMode eq
index accountStatus eq
index gecos eq
index radiusGroupName eq
index o pres,eq
index entryCSN,entryUUID eq
index gidNumber eq
syncrepl rid=405
provider=ldap://172.20.12.113
type=refreshAndPersist
interval=00:00:00:30
searchbase="ou=mail,dc=gmo,dc=jp"
filter="(objectClass=*)"
attrs="*"
scope=sub
schemachecking=off
updatedn="cn=admin,dc=gmo,dc=jp"
bindmethod=simple
binddn="cn=admin,dc=gmo,dc=jp"
credentials="*censored*"
retry="60 10 300 +"
updateref ldap://172.20.12.113
In general, do they seem reasonable? Everything has been appearing to be
correct, except for the 20091027 entry. What is the recommended procedure?
Reading the documentation makes me think I should also index "ContextCSN"?
A recent ldapmaster core was triggered here:
#0 0xce7948da in t_delete () from /lib/libc.so.1
#1 0xce79417f in _malloc_unlocked () from /lib/libc.so.1
#2 0xce794058 in malloc () from /lib/libc.so.1
#3 0x08133175 in ber_memalloc_x ()
#4 0x08133487 in ber_dupbv_x ()
#5 0x0813352b in ber_dupbv ()
#6 0x0807c22e in attr_dup ()
... which I believe is replication-related due to a post made earlier in the
list. Most likely also fixed in later versions.
Thanks for any reply,
Jorgen Lundman
--
Jorgen Lundman | <lundman(a)lundman.net>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
11 years, 10 months
no shared cipher error
by Josh.Mullis＠cox.com
Good day all,
I am getting the following error on an openldap v2.3 server when attempting communication from an ldap client...
------------------------
TLS trace: SSL_accept:before/accept initialization
TLS trace: SSL3 alert write:fatal:handshake failure
TLS trace: SSL_accept:error in SSLv3 read client hello B
TLS trace: SSL_accept:error in SSLv3 read client hello B
TLS: can't accept.
TLS: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr.c:974
------------------------
I only get this when connecting to openldap server from a client.
I do not get this error when I use the openssl client / server commands method.
Output below....
Thanks for any help.
-Josh
-----------------------------------------------------
openssl s_server -accept 1982 -cert /etc/openldap/cacerts/servercrt.pem -key /etc/openldap/cacerts/serverkey.pem
ACCEPT
-----BEGIN SSL SESSION PARAMETERS-----
--hidden-text--
--hidden-text--
--hidden-text--
-----END SSL SESSION PARAMETERS-----
Shared ciphers:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:DHE-DSS-RC4-SHA:RC4-SHA:RC4-MD5:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5
CIPHER is DHE-RSA-AES256-SHA
------------------------------------------------------
-------------------------------------------------------------------
openssl s_client -connect ldapurl.example.com:1982 -CAfile /path/to/cacert
CONNECTED(00000003)
depth=1 --hidden-text--
verify return:1
depth=0 --hidden-text--
verify return:1
---
Certificate chain
0 s:/--hidden-text--
i:/--hidden-text--
---
Server certificate
-----BEGIN CERTIFICATE-----
--hidden-text--
--hidden-text--
--hidden-text--
--hidden-text--
-----END CERTIFICATE-----
subject=/--hidden-text--
issuer=/--hidden-text--
---
No client certificate CA names sent
---
SSL handshake has read 1250 bytes and written 276 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: --hidden-text--
Session-ID-ctx:
Master-Key: --hidden-text--
Key-Arg : None
Start Time: 1260195189
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
---------------------------------------------------------------------------------------------
11 years, 10 months
Asyncronous, non blocking back- connector for Openldap
by hptf
Hello all,
I would like to know if any of you have ever experiment a NONBLOCKING,
socket based back-* for OpenLdap server.
For obscure reasons, out of the scope of this mailing list, I must
compile openldap slapd with non-threaded option activated.
The data storage, we get data from, is accessed via standard TCP socket;
but some read can take time. Thus we cannot wait in a blocking TCP read .
We start our experiment with a modified version of back-sock ( using TCP
), but this back- use a blocking scheduling model.
Thus,
How can we put in slapd scheduling loop an alien socket managed by a
back- library ? ( SLAPD_ADD.... ?)
How can back- be scheduled on socket reception ( Listener* ?)
How can we asynchrously send LDAP response, and set the context for them
What should be answered at the first ldap request ( in the
back_search() for example) to say 'will be answered later' ?
Any help, or pointer to help, even for only one of this point, would be
much appreciate!
hp tf
11 years, 10 months
custom auth
by Marten Lehmann
Hello,
for a mail relay setup I need to check a login and password against ldap
by trying to bind with authentication.
In my slapd.conf I have these lines (among others):
suffix "dc=mail"
rootdn "cn=admin,ou=users,dc=mail"
access to attrs=userPassword
by anonymous auth
by * none
How do I tell OpenLDAP to authenticate against
cn=<login>,ou=users,dc=mail and its userPassword attribute?
Kind regards
Marten
11 years, 10 months
unexpected userPassword content
by Marten Lehmann
Hello,
I am writing a MD5-password to openldap:
cleartext: 654321
md5: c33367701511b4f6020ec61ded352059
hex2b64: wzNncBURtPYCDsYd7TUgWQ==
So in my call, I am setting
userPassword={MD5}wzNncBURtPYCDsYd7TUgWQ==
But when I retrieve the userPassword content later, I get this value:
e01ENX13ek5uY0JVUnRQWUNEc1lkN1RVZ1dRPT0=
What has openldap done to it? What do I have to do with the cleartext
password to get the same value?
Kind regards
Marten
11 years, 10 months
ldap proxy resolution by rewriting in meta-backend
by yamina
Hello,
I want to use the "LDAP Proxy resolution" mode related in the
"slapd-meta" man but I don't manage to make it works.
I wonder if it is implemented yet because I saw a message dated Fri, 16
Jan 2004 17:09:10 +0100 in which the same problem is not solved.
My slapd.conf looks like:
uri "ldap://127.0.0.1:390/ou=a,ou=mysociety,c=fr"
...
rewriteRule '(.*-b\))' 'ldap://127.0.0.1:391/ou=b,ou=mysociety
<ldap://ldap1.my.org/%0%27>,c=fr' <ldap://ldap1.my.org/%0%27> ':@'
rewriteRule '(.*-c\))' 'ldap://
<ldap://ldap2.my.org/%0%27>127.0.0.1:392/ou=c,ou=mysociety,c=fr'
<ldap://ldap1.my.org/%0%27> ':@'
in order that when I search for example for uid=toto-b, it would do it
through openldap running on port 391, if I search for uid=titi-c, it
would do it through openldap running on port 392 and if I search
anything not ending by "-b" or "-c", il would do it through openldap
running on port 390(target).
But the search nevers goes to the openldap running on ports 391 and 392.
Any help would be mostly appreciated.
Kind regards
11 years, 10 months
