Re: delta-sync - ContextCSN on proivder older than consumers
by Yuri Bank
I'm using the latest stable version: OpenLDAP 2.4.23 ( running on Ubuntu
10.10 )
I've also included the relevant configuration for my Provider and
Consumer[s].
Consumer[s]
# {1}hdb, config
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=test,dc=com
olcAccess: {0}to attrs=userPassword by dn="cn=admin,dc=test,dc=com" write by
an
onymous auth by self write by
group.exact="cn=DCNAS,o=Groups,dc=test,dc=com" w
rite by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to * by dn="cn=admin,dc=test,dc=com" write by
group.exact="cn=DCN
AS,o=Groups,dc=test,dc=com" write by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=test,dc=com
olcRootPW: test
olcSyncrepl: {0}rid=001 provider=ldap://10.81.255.30 bindmethod=simple
binddn=
"cn=admin,dc=test,dc=com" credentials=test searchbase="dc=test,dc=com"
logba
se="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on type=refreshOnly retry="60 +" interval=00:00:00:30
syncdata
=accesslog
olcUpdateRef: ldap://10.81.255.30
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: uid eq
olcDbIndex: uidNumber eq
olcDbIndex: cn eq
olcDbIndex: memberOf eq
olcDbIndex: entryUUID eq
Provider:
# {1}hdb, config
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=test,dc=com
olcAccess: {0}to attrs=userPassword by dn="cn=admin,dc=test,dc=com" write by
an
onymous auth by self write by
group.exact="cn=DCNAS,o=Groups,dc=test,dc=com" w
rite by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to * by dn="cn=admin,dc=test,dc=com" write by
group.exact="cn=DCN
AS,o=Groups,dc=test,dc=com" write by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=test,dc=com
olcRootPW: test
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: uid eq
olcDbIndex: uidNumber eq
olcDbIndex: cn eq
olcDbIndex: memberOf eq
# {1}syncprov, {1}hdb, config
dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
olcSpNoPresent: TRUE
# {2}accesslog, {1}hdb, config
dn: olcOverlay={2}accesslog,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {2}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 07+00:00 01+00:00
olcAccessLogSuccess: TRUE
# {2}hdb, config
dn: olcDatabase={2}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcRootDN: cn=admin,dc=test,dc=com
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
# {0}syncprov, {2}hdb, config
dn: olcOverlay={0}syncprov,olcDatabase={2}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
-Yuri
On Sun, Mar 13, 2011 at 11:47 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote:
> --On Saturday, March 12, 2011 8:59 PM -0800 Yuri Bank <yuribank(a)gmail.com>
> wrote:
>
>
>> I've found an interesting issue with delta-sync replication in which the
>>
>
>
> The first thing you should always provide is the version of OpenLDAP you
> are using.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
11 years, 2 months
execve problem with back-shell
by Michael Smith
Hello all. I'm working with openLDAP again, after some years'
hiatus, and very glad of it.
I'm having a problem which I hope somebody's seen before. I'm trying to
use back-shell (to avoid relearning Perl) for a quick-and dirty
solution to a problem too tedious to describe here.
Here's the relevant bits of slapd.conf:
--------------
moduleload back_shell.la
backend shell
database shell
suffix "dc=foo,dc=bar,dc=com"
rootdn "cn=admin,dc=foo,dc=bar,dc=com"
rootpw secretissimum-secretissimorum
add /usr/local/bin/backshell.sh
bind /usr/local/bin/backshell.sh
compare /usr/local/bin/backshell.sh
delete /usr/local/bin/backshell.sh
modify /usr/local/bin/backshell.sh
modrdn /usr/local/bin/backshell.sh
search /usr/local/bin/backshell.sh
unbind /usr/local/bin/backshell.sh
syncrepl rid=123
provider=ldap://127.0.0.1
type=refreshOnly
interval=00:00:00:05
searchbase="dc=foo,dc=bar,dc=com"
scope=sub
bindmethod=simple
binddn="uid=mik,ou=Managers,dc=foo,dc=bar,dc=com"
credentials="M0$tsecret"
-------------
backshell.sh is moronically simple at the moment:
----------------
#!/bin/bash
while read LINE
do
/bin/echo $LINE >>/var/lib/ldap2/replog.txt
done
echo RESULT
----------------
Commands to execute slapd:
~$ sudo su
# /usr/sbin/slapd -d 0x4400 -f /etc/ldap/slapd2.conf -h "ldap://127.0.0.1:3889" -u openldap -g openldap
---------------
Varia:
~$ which bash
/bin/bash
~$ ls -ld /var/lib/ldap2
drwxr-xr-x 2 openldap openldap 4096 2011-03-04 13:10 /var/lib/ldap2
Debug output from slapd:
@(#) $OpenLDAP: slapd 2.4.9 (Jul 30 2010 00:42:11) $
buildd@vernadsky:/build/buildd/openldap2.3-2.4.9/debian/build/servers/slapd
WARNING: No dynamic config support for database shell.
slapd starting
syncrepl_entry: rid=123 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
syncrepl_entry: rid=123 inserted UUID f25a0996-d888-102f-9c2e-559808098a6b
execv failed
shell: fgets failed: Success (0)
str2result () expecting "RESULT"
---------------------
... over and over again.
strace says:
[pid 19068] execve("/usr/local/bin/backshell.sh", ["/usr/local/bin/backshell.sh"], ["SHELL=/bin/bash", "TERM=xterm", "USER=root", "LS_COLORS=no=00:fi=00:di=01;34:l"..., "SUDO_USER=mike", "SUDO_UID=1001", "USERNAME=root", "PATH=/usr/local/sbin:/usr/local/"..., "MAIL=/var/mail/root", "PWD=/home/mike", "LANG=en_US.UTF-8", "SHLVL=1", "SUDO_COMMAND=/bin/su", "HOME=/root", "LOGNAME=root", "LESSOPEN=| /usr/bin/lesspipe %s", "SUDO_GID=1001", "LESSCLOSE=/usr/bin/lesspipe %s %"..., "_=/usr/sbin/slapd"]) = -1 EACCES (Permission denied)
-------------
Doesn't look like it's even able to execute my little program, right?
So this may be more a question about the subtleties of execve (and possibly
its interactions with sudo?) than about openldap, but if some kind soul
can set me on the right path, I'd be most grateful. I've manpaged and googled
everything I could think of, and drawn a blank.
--
--
Michael J. Smith
mjs(a)smithbowen.net
11 years, 2 months
newbie scenario
by Lumeng Lim
mind you i've only managed to setup ldap server under ubuntu for now.
we have 2 sites to manage and I would like for users( about 250 users
total) in both sites that is connected via vpn to be able to login to
samba/ldap in HQ
are there things to consider before going about just setting up ldap and
samba? assuming that samba is going to be used as pdc and fileserver.
11 years, 2 months
Modified Records Deleted - Multimaster
by John s
Hi All,
I have 2 way ldap multimaster setup .
Recently User names are disappeared from two Master servers .
Observed that when records are modified at one Master, records are
removed from two servers next day .
Enabled the logs and found no errors .
Let me know during the syncrepl replication is their any chance of
modified records being deleted from other Master server ...
Thanks in advance for any help .
Ldap Version: 2.4
Regards
John
11 years, 2 months
Dynamic modules unloading
by Коновалов Андрей Але ксандрович
Hello!
I have OpenLDAP 2.4.24 built with -enable-dynamic and --enable-modules options
So, dynamic modules support is on and my question is:
Why can i load module
(for example:
dn: cn=module{0},cn=config
changeType: modify
add: olcModuleLoad
olcModuleLoad: translucent.la
)
But when i'm trying to unload it (because it's not used at all), i cant do this anywhere?
dn: cn=module{0},cn=config
changeType: modify
delete: olcModuleLoad
olcModuleLoad: {6}translucent.la
# the same with simply olcModuleLoad: translucent.la
modifying entry "cn=module{0},cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
additional info: cannot delete olcModuleLoad
If it is not realised yet, you may consume my question as a feature request :)
11 years, 2 months
delta-sync - ContextCSN on proivder older than consumers
by Yuri Bank
I've found an interesting issue with delta-sync replication in which the
ContextCSN on my consumers, is higher than the contextCSN on my provider. I
believe this is causing some other problems with bringing up brand new
consumers.
I use the following command to check the ContextCSN on each consumer:
Consumer: 1
root@neteng1.oak:/etc/ldap# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b
"dc=test,dc=com" contextCSN dn: dc=test,dc=com
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <dc=test,dc=com> with scope baseObject
# filter: (objectclass=*)
# requesting: contextCSN dn: dc=test,dc=com
#
# test.com
dn: dc=test,dc=com
contextCSN: 20110313041653.752098Z#000000#000#000000
# search result
search: 2
result: 0 Success
Consumer: 2
ybank@neteng1.iad:~$ ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b
"dc=test,dc=com" contextCSN dn: dc=test,dc=com
SASL/EXTERNAL authentication started
SASL username: gidNumber=1001+uidNumber=1010,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <dc=test,dc=com> with scope baseObject
# filter: (objectclass=*)
# requesting: contextCSN dn: dc=test,dc=com
#
# test.com
dn: dc=test,dc=com
contextCSN: 20110313041653.752098Z#000000#000#000000
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
So we can see that the two consumers have matching:
ContextCSN. 20110313041653.752098Z#000000#000#000000
Lets check the Provider now.
Provider:
root@neteng0.iad:~# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b
"dc=test,dc=com" ContextCSN dn: dc=test,dc=com
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <dc=test,dc=com> with scope baseObject
# filter: (objectclass=*)
# requesting: ContextCSN dn: dc=test,dc=com
#
# test.com
dn: dc=test,dc=com
contextCSN: 20110313041653.709140Z#000000#000#000000
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
The providers CSN is smaller:
contextCSN: 20110313041653.709140Z#000000#000#000000
Now I will search cn=accesslog on the Provider:
These are the last two entries:
# 20110313041653.000003Z, accesslog
dn: reqStart=20110313041653.000003Z,cn=accesslog
objectClass: auditAdd
reqStart: 20110313041653.000003Z
reqEnd: 20110313041653.000004Z
reqType: add
reqSession: 34633
reqAuthzID: cn=admin,dc=test,dc=com
reqDN: cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com
reqResult: 0
reqMod: sn:+ Bank
reqMod: userPassword:+ {SASL}banky
reqMod: uid:+ banky
reqMod: objectClass:+ top
reqMod: objectClass:+ person
reqMod: objectClass:+ shadowAccount
reqMod: structuralObjectClass:+ person
reqMod: cn:+ Bank, Yuri(banky)
reqMod: entryUUID:+ 78a75ef6-e174-102f-9571-ffecbfef68e5
reqMod: creatorsName:+ cn=admin,dc=test,dc=com
reqMod: createTimestamp:+ 20110313041653Z
reqMod: entryCSN:+ 20110313041653.709140Z#000000#000#000000
reqMod: modifiersName:+ cn=admin,dc=test,dc=com
reqMod: modifyTimestamp:+ 20110313041653Z
# 20110313041653.000006Z, accesslog
dn: reqStart=20110313041653.000006Z,cn=accesslog
objectClass: auditModify
reqStart: 20110313041653.000006Z
reqEnd: 20110313041653.000007Z
reqType: modify
reqSession: 34633
reqAuthzID: cn=admin,dc=test,dc=com
reqDN: cn=SSLVPN,o=Groups,dc=test,dc=com
reqResult: 0
reqMod: member:+ cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com
reqMod: entryCSN:= 20110313041653.752098Z#000000#000#000000
reqMod: modifiersName:= cn=admin,dc=test,dc=com
reqMod: modifyTimestamp:= 20110313041653Z
# search result
search: 2
result: 0 Success
As you can see, the provider is not using the latest entryCSN as its
ContextCSN, where as the consumer nodes are. Is this intended?
An issue I've experienced with this is when bringing up a brand new
consumer. It gets stuck in a loop trying to add that last entry. I'm
guessing this has something to do with it using the wrong ConextCSN?
- Yuri
11 years, 2 months
ldapsearch and extended server controls?
by Brian Reichert
I have a case where I'm trying to replicate some other application's
search against Active Directory.
A deconstruction of a packet capture of that app's conversation
shows it's making use of a control that I don't know how to specify
using any combination of ldapsearch(1) or ldap.conf(5).
Specifically, I see this coming over the wire as a control on the
search:
http://msdn.microsoft.com/en-us/library/aa366989%28v=vs.85%29.aspx
1.2.840.113556.1.4.417 LDAP_SERVER_SHOW_DELETED_OID
Research shows there lots these sorts of extended control; yay, I
learned something new!
Is there a way of utilizing these sorts of controls via ldeapsearch?
Thanks for any advice you may have...
--
Brian Reichert <reichert(a)numachi.com>
55 Crystal Ave. #286
Derry NH 03038-1725 USA BSD admin/developer at large
11 years, 2 months
Re: LDAP browsers and cn=config
by Gervase Markham
Hi Torsten,
Thanks for your help!
On 07/03/11 17:37, Torsten Schlabach (Tascel eG) wrote:
> Take a look at the olcAccess attribute values of your cn=config database.
> This should tell you who's allowed to read it or not.
I did add a value to try and make this work (see below), but perhaps I
haven't done all that's necessary.
> It depends where your cn=config data comes from, but in many examples you
> will find an olcAccess attribute granting write access to a DN called
> cn=admin,cn=config. You need to have that object in your cn=config database
> then and it should have the password attribute set.
>
> Post the olcAccess sections of your LDIF here, I think this may help.
Here is my olcDatabase={0}config.ldif, with some comments:
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
# This one added by me recently:
olcAccess: {0}to * by dn.exact=cn=admin,cn=config manage by * break
structuralObjectClass: olcDatabaseConfig
entryUUID: 9dfea13e-dd1c-102f-8cc4-2fe95e0d0dbe
creatorsName: cn=config
createTimestamp: 20110307153755Z
entryCSN: 20110307153755.993390Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20110307153755Z
# These two added by me recently:
oldRootDN: cn=admin,cn=config
olcRootPW: config
So it looks like I just need to make sure I have the cn=admin,cn=config
object in my database. And I think I can probably add it using the magic
-Y EXTERNAL method and ldapadd. However, I don't know how to construct
it - what objectClass should it have?
Gerv
11 years, 2 months
Simple Bind pass-through to SASL/PLAIN
by Zach Schimke
Is there any trick to this?
I am able to get SASL/PLAIN and SASL/GSSAPI binds to work perfectly with
my ldap server. What I want to get working is the authentication
pass-through.
From what I can gather, it appears that LDAP should be able to
authenticate a simple bind, take a look at the userPassword attribute
(which contains '{SASL}username@REALM) and perform a SASL/PLAIN from there.
We want to avoid maintaining two separate passwords (LDAP and Kerberos
V) although some applications (like phpLDAPAdmin, Drupal, etc) do not
allow the use of Kerberos natively.
/etc/sasl2/slapd.conf (using CentOS):
pwcheck_method: saslauthd
Here's a snippet of my openldap.log during a simple bind:
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 ACCEPT from
IP=149.169.147.254:56106 (IP=0.0.0.0:636)
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 TLS established
tls_ssf=256 ssf=256
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 BIND dn="cn=test
account,ou=people,o=mars" method=128
Mar 3 16:45:49 kdc1 slapd[28132]: send_ldap_result: conn=2009 op=0
p=3
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 RESULT tag=97
err=49 text=
Mar 3 16:45:49 kdc1 slapd[28132]: connection_closing: readying
conn=2009 sd=39 for close
Mar 3 16:45:49 kdc1 slapd[28132]: connection_close: conn=2009 sd=-1
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 closed
(connection lost)
Anything I should double-check, modify, etc?
--
Zach Schimke
Mars Space Flight Facility
11 years, 2 months
