(no subject)
by Meunier, Antonin
Hello,
In my openldap with mdb I imported a ldif that made add and modify (1000 objects).
95% of the file is processed in 2 minutes without problems.
5% of the rest of file is porcessed in more than 1 hour.
The problem is on the groupOfName with lots of member (more than 1000 members).
Each modify can take between 3 and 10 minutes.
My Openldap is MMR with 2 servers. The problem appears only on one of the two ldap server. On the second one, each modification take 2 seconds.
I've tried a reindex of the member attribute but nothing change.
I've tried a delete and reimport (ldif file from the second server) the ldap and the problem persist.
The configurations are the same on the 2 servers.
What can explain this huge time to modify a group ?
Exemple of a modification in my ldif file :
dn: cn=522495,ou=groupes,ou=XXXXXX,dc=xxxxx,dc=fr
changetype: modify
add: member
member: uid=2142279020,ou=personnes,ou= XXXXXX,dc= xxxxx,dc=fr
dn: cn=522813, ou=groupes,ou=XXXXXX,dc=xxxxx,dc=fr
changetype: modify
add: member
member: uid=1021253020,ou=personnes,ou= XXXXXX,dc= xxxxx,dc=fr
Thanks a lot by advance
Antonin Meunier
8 years, 9 months
idassert-authzFrom ignored
by Charles Bueche
Hi,
I have an OpenLDAP proxy using back_meta to talk to two back-ends
Microsoft AD servers.
My goal is to provide a single view of both AD trees.
Basically, it works, as long as I use a bind account which exists in one
of the back-end AD's.
However, to first search where an AD account is, I would like to use a
local account on the LDAP proxy. To my understanding, I need to use
database meta
suffix dc=proxy,dc=stuff,dc=ch
rootdn "cn=root,dc=proxy,dc=stuff,dc=ch"
rootpw "secret"
subordinate
...
idassert-bind
bindmethod=simple
binddn="CN=srvLDAP,..."
credentials="..."
mode=none
flags=non-prescriptive
idassert-authzFrom "dn.exact:cn=root,dc=proxy,dc=stuff,dc=ch"
The DN "cn=root,dc=proxy,dc=stuff,dc=ch" does exist in the proxy and can
do local searches. However, the account defined in the idassert is never
used, and the connections to the back-ends AD's fail. Respectively, I
think they are contacted using anonymous instead of the account I
specify (not sure about the anonymous part, the debug log isn't very
clear about it).
Hints welcome.
Below is a part of the relevant log if it helps.
Charles
..........
tls_read: want=64, got=64
0000: 65 87 ac 08 7e 49 8d 7f 95 3c d0 1f 09 57 b7 ce e...~I...<...W..
0010: d4 13 2e ac 57 c9 27 6b 58 f7 76 70 a1 95 10 3e ....W.'kX.vp...>
0020: e2 96 0d cf a1 d3 13 ff e7 0b b1 2f c0 6f dc 19 .........../.o..
0030: 93 38 07 b9 f7 e4 81 a8 e0 45 0e 97 ec 7f 21 a6 .8.......E....!.
TLS trace: SSL_connect:SSLv3 read finished A
ldap_int_poll: fd: -1 tm: 0
53679e3b conn=1000 op=1 <<< meta_search_dobind_init[0]=4
53679e3b conn=1000 op=1 <<< meta_back_search_start[0]=4
53679e3b conn=1000 op=1 meta_back_search: ncandidates=1 cnd="*"
53679e3b conn=1000 op=1 >>> meta_search_dobind_init[0]
ldap_sasl_bind
ldap_send_initial_request
ldap_int_poll: fd: 12 tm: 0
ldap_is_sock_ready: 12
ldap_ndelay_off: 12
TLS trace: SSL_connect:before/connect initialization
tls_write: want=225, written=225
0000: 16 03 01 00 dc 01 00 00 d8 03 02 53 67 9e 3b 55 ...........Sg.;U
0010: 4b 2f ee 53 01 81 ee ca 6a 3f a0 ea 85 3a c9 7e K/.S....j?...:.~
0020: e3 01 d7 e6 d1 09 65 14 21 05 ef 00 00 66 c0 14 ......e.!....f..
0030: c0 0a c0 22 c0 21 00 39 00 38 00 88 00 87 c0 0f ...".!.9.8......
0040: c0 05 00 35 00 84 c0 12 c0 08 c0 1c c0 1b 00 16 ...5............
0050: 00 13 c0 0d c0 03 00 0a c0 13 c0 09 c0 1f c0 1e ................
0060: 00 33 00 32 00 9a 00 99 00 45 00 44 c0 0e c0 04 .3.2.....E.D....
0070: 00 2f 00 96 00 41 c0 11 c0 07 c0 0c c0 02 00 05 ./...A..........
0080: 00 04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 ................
0090: 00 03 00 ff 01 00 00 49 00 0b 00 04 03 00 01 02 .......I........
00a0: 00 0a 00 34 00 32 00 0e 00 0d 00 19 00 0b 00 0c ...4.2..........
00b0: 00 18 00 09 00 0a 00 16 00 17 00 08 00 06 00 07 ................
00c0: 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 ................
00d0: 00 03 00 0f 00 10 00 11 00 23 00 00 00 0f 00 01 .........#......
00e0: 01 .
TLS trace: SSL_connect:SSLv3 write client hello A
tls_read: want=5 error=Connection reset by peer
TLS trace: SSL_connect:error in SSLv3 read server hello A
TLS: can't connect: .
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 12
0000: 30 05 02 01 03 42 00 0....B.
ldap_write: want=7 error=Broken pipe
ldap_free_connection: actually freed
53679e3b conn=1000 op=1 <<< meta_search_dobind_init[0]=0
53679e3b send_ldap_result: conn=1000 op=1 p=3
53679e3b send_ldap_result: err=0 matched="" text=""
53679e3b send_ldap_result: conn=1000 op=1 p=3
53679e3b send_ldap_result: err=0 matched="" text=""
53679e3b send_ldap_response: msgid=2 tag=101 err=0
ber_flush2: 14 bytes to sd 11
0000: 30 0c 02 01 02 65 07 0a 01 00 04 00 04 00 0....e........
tls_write: want=69, written=69
8 years, 9 months
Re : RE24 testing call (2.4.40)
by "POISSON Frédéric"
Hello,
I have tested with success the rev 55eddb0 on an RHEL 5.3 x86_64. I also copy a small test file (starting from a copy of the 051) in order to check if the new code correct the ITS#7822 "Segmentation fault while modifying olcDbMaxSize". The test file (see attachment) succeed like this :
# ./run -b mdb test065-config-update
Cleaning up test run directory leftover from previous run.
Running ./scripts/test065-config-update for mdb...
running defines.sh
Running slapadd to build slapd database...
Starting slapd on TCP/IP port 9011...
Check the olcDbMaxSize
dn: olcDatabase={1}mdb,cn=config
olcDbMaxSize: 10485760
Dynamically updating the olcDbMaxSize
Re-check the olcDbMaxSize
dn: olcDatabase={1}mdb,cn=config
olcDbMaxSize: 123456789
>>>>> Test succeeded
While if i run the same test on release 2.4.39 and older it fail with a seg fault. I'm not sure that this is a good test for future release of openldap but if you agree, the ITS#7822 could be closed if release 2.4.40 of openldap has the same behavior :-).
Thanks a lot,
Regards,
Le 11/08/14 20:58, Quanah Gibson-Mount <quanah(a)zimbra.com> a écrit :
>
> If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.39 release, please do so.
>
> Generally, get the code for RE24:
>
> <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs...>
>
> Configure & build.
>
> Execute the test suite (via make test) after it is built.
>
> Thanks!
>
> --Quanah
>
>
> --
> Quanah Gibson-Mount
> Server Architect
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
>
>
--
Frederic Poisson
8 years, 9 months
memberof overlay surpresses accesslog olcAccessLogOps = all
by Jan Prinsloo
Hi All,
I would appreciate it if someone could give me some insight into the following issue:
I have a standalone openldap 2.4.26 setup. We would like to use the accesslog overlay for auditing. I have enabled the accesslog overlay with olcAccessLogOps = all. This writes all groups of operations (writes, reads, session) to cn=accesslog without issues. We would also like to make use of the memberof overlay. The issue we're seeing is that once you enable the memberof overlay, only search, unbind, add operations are logged to accesslog. We do not see delete, modify, modrdn values logged. If I then change the logops to "olcAccessLogOps = add delete modify modrdn" we see those operations logged, but no bind, search, unbind operations (ie. no reads or session).
Is this a limitation of using these two overlay's together, or am I completely missing something?
Here is the configuration output:
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {-1}frontend
olcAccess: {0}to dn.base="" by * read
olcAccess: {1}to dn.base="cn=Subschema" by * read
structuralObjectClass: olcDatabaseConfig
entryUUID: 174cbd2c-bbe1-1033-97e1-99c5bb2fcfe1
creatorsName: cn=config
createTimestamp: 20140819113832Z
entryCSN: 20140819113832.018426Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140819113832Z
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=config
structuralObjectClass: olcDatabaseConfig
entryUUID: 174cc498-bbe1-1033-97e2-99c5bb2fcfe1
creatorsName: cn=config
createTimestamp: 20140819113832Z
olcAccess: {0}to * by * manage
entryCSN: 20140819153732.253785Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140819153732Z
dn: olcDatabase={1}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=novell,dc=com
olcAccess: {0}to attrs=userPassword by self write by * auth
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to attrs=userPKCS12 by self read by * none
olcAccess: {3}to * by * read
olcRootDN: cn=admin,dc=novell,dc=com
olcRootPW:: e1NTSEF9eTUrcGVLRmtBSlY4aytQUVJZOVVDTzByN1FwV1RrbENSZz09
olcDbCacheSize: 10000
olcDbCheckpoint: 1024 5
olcDbConfig: {0}set_cachesize 0 15000000 1
olcDbConfig: {1}set_lg_regionmax 262144
olcDbConfig: {2}set_lg_bsize 2097152
olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE
olcDbConfig: {4}set_lk_max_locks 30000
olcDbConfig: {5}set_lk_max_objects 30000
olcDbIDLcacheSize: 30000
olcDbIndex: objectclass eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: member eq
olcDbIndex: memberUid eq
olcDbIndex: mail eq
olcDbIndex: cn eq,sub
olcDbIndex: displayName eq,sub
olcDbIndex: uid eq,sub
olcDbIndex: sn eq,sub
olcDbIndex: givenName eq,sub
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
structuralObjectClass: olcBdbConfig
entryUUID: 174ccbbe-bbe1-1033-97e3-99c5bb2fcfe1
creatorsName: cn=config
createTimestamp: 20140819113832Z
entryCSN: 20140819114039.896372Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140819114039Z
dn: olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcAccessLogDB: cn=accesslog
olcAccessLogPurge: 07+00:00 01+00:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
entryUUID: 827deb2a-bbe1-1033-8b97-93a12773fffb
creatorsName: cn=config
createTimestamp: 20140819114131Z
olcOverlay: {0}accesslog
olcAccessLogOps: writes
entryCSN: 20140819154607.969610Z#000000#000#000000
modifiersName: cn=admin,dc=novell,dc=com
modifyTimestamp: 20140819154607Z
dn: olcOverlay={1}refint,olcDatabase={1}bdb,cn=config
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
objectClass: top
olcOverlay: {1}refint
olcRefintAttribute: memberof member manager owner
structuralObjectClass: olcRefintConfig
entryUUID: e5b204be-bbfb-1033-9b62-8fa7905953f2
creatorsName: cn=config
createTimestamp: 20140819145025Z
entryCSN: 20140819145025.207784Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140819145025Z
dn: olcDatabase={2}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcRootDN: cn=admin,dc=novell,dc=com
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
structuralObjectClass: olcBdbConfig
entryUUID: 827bc75a-bbe1-1033-8b95-93a12773fffb
creatorsName: cn=config
createTimestamp: 20140819114131Z
entryCSN: 20140819114131.842907Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140819114131Z
Regards,
Jan Prinsloo
8 years, 9 months
setting up mirroring with ldaps
by Sterling Sahaydak
Setting up mirroring between 2 servers - (ldap1 and ldap2)
Have a self signed cert installed on ldap1(provider) and connecting to
ldap2(consumer) which is using the same cert as ldap1.
What I'm not sure about is can I put the same self signed cert on both
ldap1 and ldap2?
Or on ldap2 create a self signed cert and copy it to ldap1 and register
it using (certutil) to fix the issue below?
Thanks!
[root@ldap1 log]# slapd -d Sync
@(#) $OpenLDAP: slapd 2.4.23 (Feb 3 2014 19:11:35) $
mockbuild@c6b10.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd
/etc/openldap/slapd.conf: line 149: warning, destination attributeType
'sAMAccountName' is not defined in schema
PROXIED attributeDescription "SAMACCOUNTNAME" inserted.
/etc/openldap/slapd.conf: line 199: rootdn is always granted unlimited
privileges.
bdb_monitor_db_open: monitoring disabled; configure monitor database to
enable
slapd starting
TLS: error: the certificate '/etc/openldap/certs/testldap1cert.pem'
could not be found in the database - error -8174:security library: bad
database..
TLS: certificate '/etc/openldap/certs/testldap1cert.pem' successfully
loaded from PEM file.
TLS: no unlocked certificate for certificate
'E=sterling.sahaydak(a)example.com,CN=ldap1.example.net,OU=IT,O=example,L=xxxx,ST=xx,C=xx'.
TLS: hostname (ldap2.example.net) does not match common name in
certificate (ldap1.example.net).
TLS: can't connect: TLS error -8157:Certificate extension not found..
slap_client_connect: URI=ldaps://ldap2.example.net
DN="cn=testsync,ou=roles,dc=example,dc=net" ldap_sasl_bind_s failed (-1)
do_syncrepl: rid=001 rc -1 retrying
8 years, 9 months
question about ldap log file
by Wang, Holly
Hello,
I am working on configure the OpenLDAP log file. Openldap has a document on the log level. However, I can't find where to configure the log file location and how to configure the log file in our current sladp.conf file. Where do we usually define the log file location? How to configure the log files?
Holly Wang
CSUN IT Department
Identity and Directory Service
818-677-2031
holly.wang(a)csun.edu
8 years, 9 months
Antw: Q: querying accesslog with reqStart>=partial time spec
by Ulrich Windl
>>> Ulrich Windl schrieb am 18.08.2014 um 11:53 in Nachricht <53F1CD10.741 : 161 :
60728>:
> Hi!
>
> Can anybody explain when openLDAP with bdb succeeds on a filter like
>(reqStart>=X) on accesslog?
> When I use "(reqStart>=2014080100)" I get "no match", but when I use
>"(reqStart>=20140801000)" I get the expected matches.
> (And I don't get any match when just using "reqStart>=20140801)")
> I see no log messages on the server's syslog...
Sorry, I was telling nonsense (my program just dropped the longer stings) due to a bad regex match. It seems I must specify the full legth date specification (20140811073600.000000Z)
>
> Regards,
> Ulrich
>
>
8 years, 9 months
using {CRYPT} for rootpw, using SHA512?
by Brian Reichert
I've been messing with trying to get SHA512 password hash formats in
openldap 2.4.39 under a 64-bit CentOS 6 distribution, using the LTB RPMs.
I have read the FAQ at http://www.openldap.org/faq/data/cache/1467.html
- The first entry describes a third-party module; I have been
using that for years on a 32-bit CentOS 5 platform, using the
vendor-provided openldap-2.3.43 RPMs.
My efforts to build that module for 2.4.39 seemed to build clean,
but effort to bind as a user with a {SHA512} hashed password cause
slapd to segfault.
I didn't try very hard to track that down, as there seem to be
better supported techniques.
- The third entry describes a slapo-pw-sha2 overlay, but no LTB RPM
provides the overlay. I tried exactly once to build this overlay,
but that failed due to a configure failure. I blame me; I'll
revisit this when I have the time.
However, I had some luck with the second entry, using {CRYPT}.
Following these instructions, I was able to create users, successfully
bind, and even use ldappasswd to change the passwords:
http://www.openldap.org/lists/openldap-technical/201305/msg00002.html
But, when I generated a hashed password using suggestions like this:
http://serverfault.com/questions/330069/how-to-create-an-sha-512-hashed-p...
# python -c 'import crypt; print crypt.crypt("test", "$6$random_salt")'
$6$random_salt$BnOQxEG8Gk2rzFYwoWXjr59zLVYzwshvca5oV0PtU8fAfT4a571evgca.E0hLnYNCdfq//zw9YyQN33QtztI10
and tried to embed this rootpw in my config file;
rootpw {CRYPT}$6$random_salt$BnOQxEG8Gk2rzFYwoWXjr59zLVYzwshvca5oV0PtU8fAfT4a571evgca.E0hLnYNCdfq//zw9YyQN33QtztI10
I would get bind errors.
Have I misunderstood how to use {CRYPT} for storing root's password?
--
Brian Reichert <reichert(a)numachi.com>
BSD admin/developer at large
8 years, 9 months
