openldap-software July 2008

openldap-software@openldap.org

72 participants
81 discussions

Re: Meta Idassert-bind
by Andrew Graham 28 Jul '08

28 Jul '08

*** Before acting on this email or opening any attachment you are advised to read the disclaimer at the end of this email *** If it helps at all, I'm running 2.4.11 under SLES 10. >>> "Andrew Graham" <andrew.graham(a)agustawestland.com> 25/07/2008 11:37 >>> I have moved local users into a seperate branch of the local DIT, set idassert-authzFrom to this branch and set the 'non-prescriptive' flag on the targets. With this config, remote users can bind correctly to a target. If another target is in the scope of the query, openldap will attempt to bind with no credentials. This behaviour is fine. If the root user binds to the local database, openldap will use bind to all targets in scope with the full idassert credentials. If a local user (but not root) binds to the local database, openldap uses the idassert dn to bind, but does not supply a password. This is now the problem, as most of my targets require a successful bind in order to perform queries. Thanks, Drew Andrew Graham ICT AgustaWestland UK Tel No: +44 (0) 1935 70 4421 andrew.graham(a)agustawestland.com >>> Pierangelo Masarati <ando(a)sys-net.it> 25/07/2008 10:59 >>> > I've been racking my brains trying to understand the syntax of > idassert-bind. > > In my current setup I have a local bdb database with some users and > the > base entry for the tree. I have a meta database that is subordinate > to > the bdb database. > > If I bind to the proxy as root, and search for anything, with any > base > (within the tree) openldap will bind to the relevant targets using > the > credentials defined in the idassert-bind directives. > > If I bind to the proxy as a user that exists locally (within the bdb > database) but not in any of the targets, openldap will bind to the > targets anonymously using the dn defined in idassert-bind but no > password. > > If I bind to the proxy as a user that exists in one of the targets, > it > will bind to that target with the supplied credentials, and bind > anonymously using the dn defined in idassert-bind to all other > targets > within scope. > > Ideally, I would like the following situation: > > If a user binds with local credentials, openldap should bind to the > targets with the credentials supplied with idassert-bind. > > If a user binds with remote credentials, openldap should bind to that > target with the credentials supplied by the user, and either bind to > the > other targets using the pre-defined credentials OR not attempt to > bind > to those targets. If I get your wishes correctly, you should work at the idassert-authzFrom level to only enable identity assertion for local users, disabling it for remote users. You may need to set "non-prescriptive" in order to allow non-authorized users to connect anonymously. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it ----------------------------------- *** Disclaimer *** The information contained in this E-Mail and any subsequent correspondence may be subject to the Export Control Act (ECA) 2002. The content is private and is intended solely for the recipient(s). For those other than the recipient any disclosure, copying, distribution, or action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful. If received in error please return to sender immediately. Under the laws of England misuse of information that is subject to the ECA 2002, is a criminal offence. Westland Helicopters Ltd Lysander Road Yeovil BA20 2YB England Registered in England under No 604352

1 0

Re: ppolicy pwdReset
by greek ordono 28 Jul '08

28 Jul '08

Hello, I've changed my acl like this: access to attrs=userPassword,shadowLastChange,sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdMustChange by dn="cn=nssldap,ou=DSA,dc=moldex,dc=group" write by anonymous auth by self write access to * by self write by * read and still get. => access_allowed: read access to "uid=techsupport,ou=Users,dc=moldex,dc=group" "userPassword" requested => acl_get: [1] attr userPassword => slap_access_allowed: result not in cache (userPassword) => acl_mask: access to entry "uid=techsupport,ou=Users,dc=moldex,dc=group", attr "userPassword" requested => acl_mask: to value by "", (=0) <= check a_dn_pat: cn=nssldap,ou=dsa,dc=moldex,dc=group <= check a_dn_pat: self <= check a_dn_pat: anonymous <= acl_mask: [3] applying auth(=xd) (stop) <= acl_mask: [3] mask: auth(=xd) => slap_access_allowed: read access denied by auth(=xd) => access_allowed: no more rules this only happend if smbk5pwd is enabled. My pam_ldap config looks like this: base dc=moldex,dc=group uri ldap://127.0.0.1 ldap_version 3 rootdn cn=nssldap,ou=dsa,dc=moldex,dc=group referrals yes timelimit 30 bind_timelimit 30 bind_policy hard nss_reconnect_tries 1 nss_reconnect_sleeptime 1 nss_reconnect_maxsleeptime 2 nss_reconnect_maxconntries 1 nss_base_passwd ou=Users,dc=moldex,dc=group?one nss_base_passwd ou=Computers,dc=moldex,dc=group?one nss_base_shadow ou=Users,dc=moldex,dc=group?one nss_base_group ou=Groups,dc=moldex,dc=group?one nss_initgroups_ignoreusers backup,bin,daemon,dhcp,games,gnats,irc,klog,libuuid,list,lp,mail,man,news,openldap,proxy,root,sshd,sync,sys,syslog,uucp,www-data ssl off pam_lookup_policy yes pam_password exop Thanks, greek --- On Sat, 7/26/08, Dieter Kluenter <dieter(a)dkluenter.de> wrote: From: Dieter Kluenter <dieter(a)dkluenter.de> Subject: Re: ppolicy pwdReset To: openldap-software(a)openldap.org Date: Saturday, July 26, 2008, 5:28 PM greek ordono <grexk(a)yahoo.com> writes: > I'm getting this error: > > => access_allowed: read access to "uid=techsupport,ou=Users,dc=moldex,dc=group" "userPassword" requested > => acl_get: [1] attr userPassword > => slap_access_allowed: result not in cache (userPassword) > => acl_mask: access to entry "uid=techsupport,ou=Users,dc=moldex,dc=group", attr "userPassword" requested > => acl_mask: to value by "", (=0) > <= check a_dn_pat: cn=replicator,ou=dsa,dc=moldex,dc=group > <= check a_dn_pat: * > <= acl_mask: [2] applying +0 (break) > <= acl_mask: [2] mask: =0 > => acl_get: [2] attr userPassword > => slap_access_allowed: result not in cache (userPassword) > => acl_mask: access to entry "uid=techsupport,ou=Users,dc=moldex,dc=group", attr "userPassword" requested > => acl_mask: to value by "", (=0) > <= check a_dn_pat: cn=samba,ou=dsa,dc=moldex,dc=group > <= check a_dn_pat: cn=nssldap,ou=dsa,dc=moldex,dc=group > <= check a_dn_pat: cn=squid,ou=dsa,dc=moldex,dc=group > <= check a_dn_pat: self > <= check a_dn_pat: anonymous > <= acl_mask: [5] applying auth(=xd) (stop) > <= acl_mask: [5] mask: auth(=xd) > => slap_access_allowed: read access denied by auth(=xd) > => access_allowed: no more rules > send_search_entry: conn 9 access to attribute userPassword, value #0 not allowed For this search your rule no. 5 is applicable, and this rule disallows read access to attribute userPassword. Change your access rules accordingly. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

2 2

Re: Re: slapd dies immediately with signal 9
by openldap.lists＠frei-family.ch 28 Jul '08

28 Jul '08

Hi all, Aaron landed a direct hit ! as soon as I used "make install STRIP=''" the binary in the destination directory turned out as perfectly usable and the size compared to the one in the build directory is identical. The strip utility which hit me is /usr/local/bin/strip (GNU Strip V2.17, obtained as package SMCbinut from sunfreeware.com - since I didn't personally install that package I only checked now and there's some warnings at sunfreeware.com regarding SMCbinut). When I tried Aaron's second suggestion of "make install STRIP='/usr/ccs/bin/strip'" my terminal was stuffed with error messages. I managed to slim down that somewhat bloated slapd binary by setting the CPPFLAGS for gcc to "-g0". Now I have a properly working binary (as far as I can see) and I'd be interested if there's a possible problem / negative impact with the approach I've chosen (no strip but -g0). Does anyone have a comment on that ? Many thanks to all that helped to overcome the troubles of my build attempt ! Christoph

2 1

DN index delete failed
by Norman Gaywood 27 Jul '08

27 Jul '08

I am running Buchan Milne's build of openldap-2.3.43-1.rhel5.x86_64 on a RedHat 5.2 system running kernel 2.6.18-92.1.6.el5. in a VMware instance. This system runs as a master to 3 other syncrepl slaves. Very few queries are made against this system, it is simply a central place to direct updates to. Writes are infrequent, averaging 4-5 and hour. Databases are hdb. This system was running openldap-servers-2.3.39-3.rhel5.x86_64 for several months until a few days ago when I did a update via yum pointing to http://staff.telkomsa.net/packages/rhel5/openldap/x86_64/ This system has been running without issues until last night. Then this appeared in the logs during deletion of a user account: Jul 25 02:41:51 janus slapd[31075]: conn=7142 op=1 DEL dn="uid=pcass,ou=People,dc=une,dc=edu,dc=au" Jul 25 02:41:51 janus slapd[31075]: conn=7142 op=1 RESULT tag=107 err=80 text=DN index delete failed Other accounts have been deleted before and after this event. Further attempts to delete this particular entry always fail with the same error. In an attempt to fix this, I shutdown slapd, ran /usr/bin/slapd_db_recover in the /var/lib/ldap directory and restarted slapd. Attempting to delete the entry after this produced: Jul 25 14:20:14 janus slapd[15043]: conn=3 op=1 DEL dn="uid=pcass,ou=People,dc=une,dc=edu,dc=au" Jul 25 14:20:14 janus slapd[15043]: conn=3 op=1 RESULT tag=107 err=32 text= Further attempts return us to: Jul 25 14:24:54 janus slapd[15043]: conn=19 op=1 DEL dn="uid=pcass,ou=People,dc=une,dc=edu,dc=au" Jul 25 14:24:54 janus slapd[15043]: conn=19 op=1 RESULT tag=107 err=80 text=DN index delete failed Searching the list, I see similar problems mentioned in these threads: http://www.openldap.org/lists/openldap-software/200801/msg00257.html http://www.openldap.org/lists/openldap-software/200802/msg00045.html There did not seem to be any resolution to these however. -- Norman Gaywood, Computer Systems Officer University of New England, Armidale, NSW 2351, Australia ngaywood(a)une.edu.au Phone: +61 (0)2 6773 3337 http://mcs.une.edu.au/~norm Fax: +61 (0)2 6773 3312 Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

4 4

make output of ldapsearch readable (disable base64)
by Zhang Weiwu 26 Jul '08

26 Jul '08

Hello. Since I have been working on a Chinese language based directory the ldapsearch tool was difficult for me to use, the result is always not readable. This is because if an attribute value contain Chinese, it's automatically displayed using base64. I had to copy & paste the result to 'base64 -d' to read every result, which kills my efficiency. I had to switch to a GUI ldapbrower, which kills my efficiency more because I cannot store most of my frequent queries and call them back as easily would be done on console with readline support. Is there a way to use ldapsearch and disable using base64 for non-ascii characters? I searched into the manual without a clue. Example of un-readable output: zhangweiwu@esmeralda:~$ ldapsearch -H ldap://gtz.ods.org -D uid=admin,st=jiangxi,o=LGOP -x -w secret -b st=jiangxi,o=LGOP '(pwdFailureTime=*)' pwdFailureTime pwdAccountLockedTime # extended LDIF # # LDAPv3 # base <st=jiangxi,o=LGOP> with scope subtree # filter: (pwdFailureTime=*) # requesting: pwdFailureTime pwdAccountLockedTime # # \E5\90\89\E5\AE\89\E5\B8\82, jiangxi, LGOP dn:: b3U95ZCJ5a6J5biCLHN0PWppYW5neGksbz1MR09Q pwdFailureTime: 20080513080747Z # \E4\B9\9D\E6\B1\9F\E5\B8\82, jiangxi, LGOP dn:: b3U95Lmd5rGf5biCLHN0PWppYW5neGksbz1MR09Q pwdFailureTime: 20080612200319Z pwdFailureTime: 20080612200326Z # \E5\8D\97\E6\98\8C\E5\B8\82, jiangxi, LGOP dn:: b3U95Y2X5piM5biCLHN0PWppYW5neGksbz1MR09Q pwdFailureTime: 20080726054305Z pwdFailureTime: 20080726054306Z # \E6\96\B0\E4\BD\99\E5\B8\82\E5\88\86\E5\AE\9C\E5\8E\BF, jiangxi, LGOP dn:: b3U95paw5L2Z5biC5YiG5a6c5Y6/LHN0PWppYW5neGksbz1MR09Q pwdFailureTime: 20080613022146Z # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4

4 11

Synrepl
by Francois Marot 25 Jul '08

25 Jul '08

Hello all, I would like to have an advise on how to use syncrepl. Here's the situation: I plan on having one master server, and, later, adding a slave server. I would like this slave to have all the data contained in the master + replicate any modification done on the master. Thus, if the master fails, my application (knowing the address of the slave server) could detect it and switch to the slave server. But what is the best way to do when I switch on the slave server ? Is there an automatic way for the synrepl setting to initiate the slave in the same state as the master when the slave is switched on. For the moment I managed to have the slave replicate the changes made on the master, but I could not auto-initiate the slave to the same data that the master contains. So I did it by hand by exporting/importing an ldif file. I must add that my database contains very few data (about 200 entries). Thanks a lot for any feedback Francois Marot

4 4

Re: how to configure multi-master
by Buchan Milne 25 Jul '08

25 Jul '08

Please stay on-list. On Tuesday 22 July 2008 10:41:18 Liutauras Adomaitis wrote: > On Tue, Jul 22, 2008 at 10:02 AM, Buchan Milne <bgmilne(a)staff.telkomsa.net> > > wrote: > > On Monday 21 July 2008 14:48:23 Liutauras Adomaitis wrote: > > > On Mon, Jul 21, 2008 at 12:49 PM, Buchan Milne < > > > > bgmilne(a)staff.telkomsa.net> > > > > > wrote: > > > > On Sunday 20 July 2008 23:34:03 Liutauras Adomaitis wrote: > > > > [...] > > > > > > > It shows, that it is adding MirrorMode TRUE. So why? > > > > > > > > The configuration directive may have been overloaded when > > > > multi-master was added (after mirrormode). AFAIK it allows the > > > > database in question > > > > to > > > > > > both have a syncrepl directive, yet take updates from a DN besides > > > > the updatedn (see the description on the slapd.conf man page). > > > > > > are you saying, that in multimaster configuration I have to have > > > updatedn directive to be able to do writes? > > > > No. Without mirrormode or multi-master, a slave would only accept updates > > from > > the updatedn. In multi-master, the master is also a slave, so it needs to > > accept updates from any DN, while being configured as a slave (having > > replication configuration). > > Sorry, but still don't get it. As you say node in multimaster configuration > is master and slave at the same time. As a slave it can accept writes only > having updatedn directive. Right? > I'm really sorry if I don't understand, but it seems that "No" contradicts > other sentences. No means: your interpretation that it is multimaster requires updatedn to be set is incorrect. > > > In thread "explain diff between multimaster and mirror mode" I found > > > out, that mirrormode is kind of high availability implementation for > > > openldap. In my case I want to have multimaster replication, which > > > could allow me > > > > to > > > > > do writes to different master servers at a time. > > > > You may want to think very carefully about why you want this, and not > > mirrormode, or a single master. > > Yes maybe it is not necessary. I have read some posts saying the same - > people do multimaster then they really don't need it at all. This is my > first acquaintance with syncrepl and ldap replication, so I don't really > know what is best for me. I tried master- slave, but it had some undisired > side effects, If you are that unspecific about the issues, we can't comment on your decision. > so I decided to switch to configuration there I could do > writes on "slaves", and turned those slaves into masters. I didn't know > about updatedn directive which maybe is suitable for me, but needs to be > tested. > I decided not to do mirrormode, because according to Dieter Kluenter: > "Mirror mode is a sort of backup and standby system. Only > one ldap server should be visible and available, thus allowing write > operations, while the second ldap-server is in hot standby position, > and only available to clients" > But I need to do writes at both master at the same tme. You haven't explained why, so we can't give you feedback on your decision to use multimaster. > > Are you sure it is not some other aspect of your configuration? Have you > > posted details? Have you posted the error message? > > The most probably it is my configuration and I'm missing something. > The error is "shadow context; no update referral at ...", I have posted in > my first letter. I receive this error on any master I try to do writes. If > add mirrormode true to the end - I can do writes. Exactly. Enabling "mirrormode" is a prerequisite for multimaster. The difference between mirrormode an multimaster (as far as I know) these days (post 2.4.6) is really your architecture (whether you allow writes to one master, or more), not the configuration (though more than two syncrepl statements does mean that it can't be mirrormode). > I have one central master, and other master are replicated from this one. This is not the definition of multimaster. As far as I know, the recommended architecture for multimaster is that all masters can see (replicate from) each other. Otherwise, they are locally writable slaves, with no guarantee of convergence. > Configuration of other masters are the same, except serverID are 2 and 3 > respectively and they have only one syncrepl directive pointing to central > master. So there is no replication between master002 and master 001. Regards, Buchan

6 8

virtual view strategies: replying differently to different clients
by Guillaume Rousse 25 Jul '08

25 Jul '08

Hello list. We're using some braindead appliance that insist on having internal telephone numbers in LDAP, whereas we need to also store external numbers (external prefix + internal number) for other purposes. I didn't found any way to dynamically alter the content of the telephonenumber attribute when asked by the client (filtering the prefix on the fly), so I quickly opted to store the information twice: the short and the long number. The appliance doesn't allow to select which attribute to use, it always use the first value from telephoneNumber attribute. So the current solution is to store both values in this attribute, and use the valsort overlay to always have the short number first. However, this rely on client being aware of the trick, and using to the second value when several are available, whereas we'd prefer to do the trick server-side. I then tried to use different attributes (homePhone vs telephoneNumber) to store those different values, and use attribute mapping to reply with the expected value depending on the client. I had a quick look at rwm overlay, but attribute mapping seems to be global only, not for a given client only. On Buchan's suggestion, I tried relay backend instead, so as to only remap attributes values using a specific context. This seems the correct strategies, however I'm facing a few issues. First, using a distinct database doesn't allow to provide a virtual view from a branch in my original database to another branch in the same database. Meaning, I can't have ou=telephony,dc=myprefix a virtual view of ou=users,dc=myprefix, I need to use a distinct prefix. Second, trying the solution at the end of slapo-rwm man page to only map some attributes and exclude others is actually filtering too much. As soon as I use 'map attribute *' to exclude unmapped attributes, I can't list entries anymore. Adding the pseudo-attributes 'entry' to mapped attributes, which is documented as needed for research operation in slapd.access man page, doesn't help. So I had to ressort to ACLs instead to exclude unwanted attribute. Third, this solution doesn't work currently when trying to sync the appliance users from ldap. From ldap log, it seems some specific control is not supported with relay backend: Jul 22 13:46:12 etoile slapd[10826]: conn=3 fd=23 ACCEPT from IP=193.55.250.9:37225 (IP=0.0.0.0:389) Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=0 BIND dn="cn=callmanager,ou=roles,cn=telephony" method=128 Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=0 BIND dn="cn=callmanager,ou=roles,dc=msr-inria,dc=inria,dc=fr" mech=SIMPLE ssf=0 Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=0 RESULT tag=97 err=0 text= Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=1 SRCH base="ou=users,cn=telephony" scope=2 deref=3 filter="(objectClass=inetOrgPerson)" Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=1 SRCH attr=uid givenname initials sn manager departmentnumber telephonenumber mail title homephone mobile pager Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=1 SEARCH RESULT tag=101 err=12 nentries=0 text=critical control unavailable in context When using a different loglevel, the only critical control requested is 1.2.840.113556.1.4.319, pagedControl. However, the client request for it seems to succeed: Jul 22 13:48:10 etoile slapd[11317]: => get_ctrls Jul 22 13:48:10 etoile slapd[11317]: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) Jul 22 13:48:10 etoile slapd[11317]: <= get_ctrls: n=1 rc=0 err="" My wild guess is that the control doesn't survive the context switch from the original base (dc=msr-inria,dc=inria,dc=fr) to the virtual base (cn=telephony). Should I report this as a bug, or am I misunderstanding ? I'm using openldap 2.4.11, and here is the virtual base configuration, if that matters: database relay suffix "cn=telephony" relay "dc=msr-inria,dc=inria,dc=fr" overlay rwm rwm-suffixmassage "dc=msr-inria,dc=inria,dc=fr" access to dn.subtree="cn=telephony" attrs=userPassword by anonymous ssf=56 auth by anonymous peername.ip=193.55.250.9 auth by * none access to dn.subtree="ou=users,cn=telephony" filter=(telephoneNumber=*) attrs=entry,objectClass,telephoneNumber,uid,givenName,sn,manager,mail by * read access to dn.subtree="ou=users,cn=telephony" filter=(telephoneNumber=*) by * none map attribute telephoneNumber homePhone map attribute telephoneNumber Any hint welcome, either on the solution choice, or on the selected solution troubles. -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62

2 1

rwm and sasl authz
by Konstantinos Koukopoulos 25 Jul '08

25 Jul '08

Hello, I was wondering if it is a known issue that when using sasl authorization combined with the rewrite module, one doesn't have access to either the binddn or the authz dn. The rewrite context bindDN is only called when the client supplies a DN in the simple-bind fashion (-D when using ldapsearch). But if one uses a sasl mechanism (in order to use proxy auth for example) then the binding will happen with the result of the authz-regexp rewrite but this is not in a context of slapo-rwm, whose bindDN context sees whatever, if any, arbitrary bind DN the request contained (for example through -D). Additionally there is no context regarding the authorization DN, which is pretty much a necessity if you plan on using authFrom and have remapped the dit. Thank you, Kostas Koukopoulos

2 6

overlay rwm crashing server
by Eric 25 Jul '08

25 Jul '08

Hello, OpenLDAP v2.3.42 I have found that using "overlay rwm" along with "database meta", where "database meta" refers to a Windows Active Directory server, causes OpenLDAP to crash with the following error: -- client sends -- ldapsearch -x -W -D "cn=ef87,dc=ad,dc=company,dc=com" -b "ou=users,dc=ad,dc=company,dc=com" -- server crashes -- ... PROXIED attributeDescription "MSEXCHMAILBOXGUID" inserted. ber_scanf fmt ([W]) ber: ber_scanf fmt ({m) ber: slapd: attr.c:141: attr_dup: Assertion `j == i' failed. # slapd.conf ... overlay rwm database meta suffix "dc=ad,dc=company,dc=com" uri "ldap://dc.example.com/dc=ad,dc=company,dc=com suffixmassage "dc=ad,dc=company,dc=com" dc=ad,dc=example,dc=com" idassert-bind bindmethod="simple" binddn="cn=ProxyUser,dc=ad,dc=example,dc=com" credentials="secret" mode="self" map objectclass posixaccount user map objectclass posixgroup group map attribute uid samaccountname map attribute uniquemember member map attribute mail userPrincipalName map attribute maillocaladdress proxyaddresses #map attribute * ... The error can be avoided by either 1.) removing the "overlay rwm" from slapd.conf, 2.) move "overlay rwm" below a second database definition, 3.) use "map attribute" in the "database meta" section to select only certain attributes. I would certainly like the two to work together in order to perform rewrites at a global level (and not have to configure my slapd.conf to work around a server crash). Thanks, ef

7 16

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software July 2008