openldap-software

openldap-software@openldap.org

2719 discussions

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

25 Jul '08

*** Before acting on this email or opening any attachment you are advised to read the disclaimer at the end of this email *** 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

Meta Idassert-bind
by Andrew Graham 25 Jul '08

25 Jul '08

*** Before acting on this email or opening any attachment you are advised to read the disclaimer at the end of this email *** 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. I have tried using 'flags=override', which works well to solve the local user problem. However if a user binds with remote credentials, openldap will first bind with those credentials, then rebind with the pre-defined credentials. The problem here is that the predefined credentials may not have the same privileges as the supplied credentials. Here's something like my slapd.conf... require authc access to * by dn="cn=user a,dc=example,dc=com" read by dn="cn=user b,dc=example,dc=com" read by * auth access to dn.sub="dc=target a,dc=meta,dc=example,dc=com" by dn="cn=user a,dc=example,dc=com" write by self write # Meta Database database meta suffix "dc=meta,dc=example,dc=com" subordinate rootdn "cn=root,dc=example,dc=com" ## Target A uri "ldap://192.168.1.10/dc=target a,dc=meta,dc=example,dc=com" idassert-bind bindmethod=simple binddn="cn=ldapproxy,o=example" credentials="secret" mode=none idassert-authzFrom "dn:*" rewriteEngine on suffixmassage "dc=target a,dc=meta,dc=example,dc=com" "o=example" ## Target B uri "ldap://192.168.1.20/dc=target b,dc=meta,dc=example,dc=com" idassert-bind bindmethod=simple binddn="cn=ldapproxy,dc=another,dc=com" credentials="secret" mode=none idassert-authzFrom "dn:*" rewriteEngine on suffixmassage "dc=target b,dc=meta,dc=example,dc=com" "dc=another,dc=com" # Local bdb database database bdb suffix "dc=example,dc=com" directory /usr/local/var/openldap-data/example-base/ rootdn "cn=root,dc=example,dc=com" rootpw "secret" index objectclass eq index cn,sn eq,sub Thankyou for taking the time to read this, any help would be greatly appreciated. Best Regards, Drew Andrew Graham ICT AgustaWestland UK Tel No: +44 (0) 1935 70 4421 andrew.graham(a)agustawestland.com *** 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

2 1

Troubles with Country (c) attribute limited to two characters
by Mavric Domen 24 Jul '08

24 Jul '08

Hello, at the moment we have installed OpenLDAP 2.3.17 on our production servers. Recently we've decided to upgrade to 2.4.9 version and we came across an issue which doesn't seem easy to solve. It's about the "c" (country) attribute syntax definition which has been changed in the core schema between 2.3.17 and 2.4. In older days this attribute allowed string values, but now it has been limited to 2-characters only ("Country String"). Country value is a part of suffix in our DIT (e.g. l=$locality,c=$country), the problem is that our users in some cases used 3 or more letters for country attribute . This was on 2.3 server. Now I want to upgrade the server to the new version and at the same time I want to convert the old-fashioned slapd.conf configuration to dynamic one (slapd.d). When I try to bring up the database, the server fail to start and I get the following error: (a snippet from slapd debug): ... >>> dnPrettyNormal: <olcDatabase={-1}frontend> <<< dnPrettyNormal: <olcDatabase={-1}frontend>, <olcDatabase={-1}frontend> >>> dnNormalize: <cn=config> <<< dnNormalize: <cn=config> >>> dnNormalize: <cn=config> <<< dnNormalize: <cn=config> <= str2entry(olcDatabase={-1}frontend) -> 0x828cba4 >>> dnPrettyNormal: <l=kranj,c=slo> ldap_err2string config error processing olcDatabase={-1}frontend,cn=config: <olcDefaultSearchBase> invalid DN 21 (Invalid syntax) send_ldap_result: conn=-1 op=0 p=0 slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. OK, I understand that this is happening because of schema violation, but nevertheless, I still need some advices or tips, how to avoid getting into trubles when upgrading the servers. Is there an easy way to get rid of the problem, but still using this type of suffix with country value longer that 2 characters? Thanks a lot. Best Regards, Domen

4 5

syncrepl consumer fails with segmentation-fault
by openldap 24 Jul '08

24 Jul '08

Hi listers we are running 3 openldap servers: one as provider with openldap-servers-2.3.39-3.fc8 the other 2 as consumers with openldap-servers-2.4.8-6.fc9.i386 the provider runs fedora 8, the consumers run fedora 9. as i am aware that the slurpd mechanism for synchronization is no longer supported in openldap-2.4.xxx, i tried to install syncrepl, all to no avail. ........ the actual situation is that as soon as i do a change in the provider, the consumers immediatly get a segmentation fault and leave the bdb in an unusable state. when i restart the consumers, they inform me about the unusable db, refresh it and redo the pending syncrepl-request, which again makes them do a segmentation-fault. we use sleepycat dbs exclusively. the version on the consumers is db4-4.6.21-5.fc9.i386 the config with regard to syncrepl is: ---- in the provider: ... index entryCSN,entryUUID eq .... modulepath /usr/lib/openldap/ moduleload syncprov.la ... # syncrepl as a provider overlay syncprov #syncprov-checkpoint 100 10 syncprov-sessionlog 100 (i commented out syncproc-checkpoint after having read a corresponding issue from a mailing-list) ---- in the consumers ... index entryUUID,entryCSN eq ... modulepath /usr/lib/openldap/ moduleload syncprov.la ... # syncrepl as a consumer syncrepl rid=1 provider=ldap://ldapadmin.mydom.com/ binddn="cn=manager,dc=mydom,dc=com" bindmethod=simple credentials=XXXXXXXXXXXXXX searchbase="dc=mydom,dc=com" filter="(objectClass=*)" attrs="*,structuralObjectClass,entryUUID,entryCSN, \ creatorsName,createTimestamp,modifiersName,modifyTimestamp" schemachecking=off scope=sub type=refreshAndPersist retry="5 5 300 5" .............. when doing a change on the provider, the providers log is: Jul 24 15:01:18 violina slapd[17811]: conn=25 fd=33 ACCEPT from IP=xxx.xxx.xxx.163:34702 (IP=0.0.0.0 :636) Jul 24 15:01:18 violina slapd[17811]: conn=25 fd=33 TLS established tls_ssf=56 ssf=56 Jul 24 15:01:18 violina slapd[17811]: conn=25 op=0 BIND dn="" method=128 Jul 24 15:01:18 violina slapd[17811]: conn=25 op=0 RESULT tag=97 err=0 text= Jul 24 15:01:18 violina slapd[17811]: conn=25 op=1 SRCH base="" scope=0 deref=2 filter="(objectClass =*)" Jul 24 15:01:18 violina slapd[17811]: conn=25 op=1 SRCH attr=namingContexts Jul 24 15:01:18 violina slapd[17811]: conn=25 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Jul 24 15:01:18 violina slapd[17811]: conn=25 op=2 BIND dn="cn=config" method=163 Jul 24 15:01:18 violina slapd[17811]: conn=25 op=2 RESULT tag=97 err=14 text= Jul 24 15:01:18 violina slapd[17811]: conn=25 op=3 BIND dn="cn=config" method=163 Jul 24 15:01:18 violina slapd[17811]: conn=25 op=3 BIND authcid="myuser@ldap" authzid="myuser@ldap" Jul 24 15:01:18 violina slapd[17811]: conn=25 op=3 BIND dn="cn=myuser,ou=pam-ldap,dc=mydom,dc=com" mec h=DIGEST-MD5 sasl_ssf=0 ssf=56 Jul 24 15:01:18 violina slapd[17811]: conn=25 op=3 RESULT tag=97 err=0 text= Jul 24 15:01:18 violina slapd[17811]: conn=25 op=4 MOD dn="cn=ACCUG,ou=LDIF-Test,dc=mydom,dc=com" Jul 24 15:01:18 violina slapd[17811]: conn=25 op=4 MOD attr=description Jul 24 15:01:18 violina slapd[17811]: conn=25 op=4 RESULT tag=103 err=0 text= Jul 24 15:01:18 violina slapd[17811]: conn=25 fd=33 closed (connection lost) when the syncrepl from one of the consumers comes in, the providers log is: Jul 24 15:13:03 violina slapd[17811]: conn=109 fd=35 ACCEPT from IP=xxx.xxx.xxx.165:59830 (IP=0.0.0.0:389) Jul 24 15:13:03 violina slapd[17811]: conn=109 op=0 BIND dn="cn=manager,dc=mydom,dc=com" method=128 Jul 24 15:13:03 violina slapd[17811]: conn=109 op=0 BIND dn="cn=Manager,dc=mydom,dc=com" mech=SIMPLE ssf=0 Jul 24 15:13:03 violina slapd[17811]: conn=109 op=0 RESULT tag=97 err=0 text= Jul 24 15:13:03 violina slapd[17811]: conn=109 op=1 SRCH base="dc=mydom,dc=com" scope=2 deref=0 filter="(objectClass=*)" Jul 24 15:13:03 violina slapd[17811]: conn=109 op=1 SRCH attr=entryUUID creatorsName createTimestamp modifiersName modifyTimestamp * objectClass structuralObjectClass entryCSN Jul 24 15:13:03 violina slapd[17811]: conn=109 fd=35 closed (connection lost) ........................ when the consumer tries do do a syncrepl the consumer's log is: Jul 24 14:59:16 mirador slapd[31054]: null_callback : error code 0x10 Jul 24 14:59:16 mirador slapd[31054]: syncrepl_updateCookie: rid=001 be_modify failed (16) and then it fails with a Segmentation fault: when running slapd -d7, i get: .... ldap_write: want=265, written=265 0000: 30 82 01 05 02 01 02 63 81 a9 04 0e 64 63 3d 61 0......c....dc=a 0010: 79 6e 69 2c 64 63 3d 63 6f 6d 0a 01 02 0a 01 00 yni,dc=com...... 0020: 02 01 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 ...........objec 0030: 74 43 6c 61 73 73 30 7b 04 09 65 6e 74 72 79 55 tClass0{..entryU 0040: 55 49 44 04 0c 63 72 65 61 74 6f 72 73 4e 61 6d UID..creatorsNam 0050: 65 04 0f 63 72 65 61 74 65 54 69 6d 65 73 74 61 e..createTimesta 0060: 6d 70 04 0d 6d 6f 64 69 66 69 65 72 73 4e 61 6d mp..modifiersNam 0070: 65 04 0f 6d 6f 64 69 66 79 54 69 6d 65 73 74 61 e..modifyTimesta 0080: 6d 70 04 01 2a 04 0b 6f 62 6a 65 63 74 43 6c 61 mp..*..objectCla 0090: 73 73 04 15 73 74 72 75 63 74 75 72 61 6c 4f 62 ss..structuralOb 00a0: 6a 65 63 74 43 6c 61 73 73 04 08 65 6e 74 72 79 jectClass..entry 00b0: 43 53 4e a0 54 30 52 04 18 31 2e 33 2e 36 2e 31 CSN.T0R..1.3.6.1 00c0: 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 39 2e 31 2e .4.1.4203.1.9.1. 00d0: 31 04 36 30 34 0a 01 03 04 2c 72 69 64 3d 30 30 1.604....,rid=00 00e0: 31 2c 63 73 6e 3d 32 30 30 38 30 37 32 34 30 39 1,csn=2008072409 00f0: 34 33 33 33 5a 23 30 30 30 30 30 31 23 30 30 23 4333Z#000001#00# 0100: 30 30 30 30 30 30 01 01 ff 000000... =>do_syncrep2 rid=001 ldap_result ld 0xb9c94970 msgid 2 wait4msg ld 0xb9c94970 msgid 2 (timeout 0 usec) wait4msg continue ld 0xb9c94970 msgid 2 all 0 ** ld 0xb9c94970 Connections: * host: ldapadmin.mydom.com port: 389 (default) refcnt: 2 status: Connected last used: Thu Jul 24 16:02:25 2008 ** ld 0xb9c94970 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0xb9c94970 request count 1 (abandoned 0) ** ld 0xb9c94970 Response Queue: Empty ld 0xb9c94970 response count 0 ldap_chkResponseList ld 0xb9c94970 msgid 2 all 0 ldap_chkResponseList returns ld 0xb9c94970 NULL ldap_int_select connection_get(12) connection_get(12): got connid=0 =>do_syncrepl rid=001 =>do_syncrep2 rid=001 ldap_result ld 0xb9c94970 msgid 2 wait4msg ld 0xb9c94970 msgid 2 (timeout 0 usec) wait4msg continue ld 0xb9c94970 msgid 2 all 0 ** ld 0xb9c94970 Connections: * host: ldapadmin.mydom.com port: 389 (default) refcnt: 2 status: Connected last used: Thu Jul 24 16:02:25 2008 ** ld 0xb9c94970 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0xb9c94970 request count 1 (abandoned 0) ** ld 0xb9c94970 Response Queue: Empty ld 0xb9c94970 response count 0 ldap_chkResponseList ld 0xb9c94970 msgid 2 all 0 ldap_chkResponseList returns ld 0xb9c94970 NULL ldap_int_select read1msg: ld 0xb9c94970 msgid 2 all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 48 02 01 02 79 43 80 0H...yC. ldap_read: want=66, got=66 0000: 18 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 .1.3.6.1.4.1.420 0010: 33 2e 31 2e 39 2e 31 2e 34 81 27 a3 25 04 0c 63 3.1.9.1.4.'.%..c 0020: 73 6e 3d 2c 72 69 64 3d 30 30 31 01 01 ff 31 12 sn=,rid=001...1. 0030: 04 10 55 1f 4d f6 a7 44 10 29 99 1e ee 7e f2 a8 ..U.M..D.)...~.. 0040: 1c 52 .R ber_get_next: tag 0x30 len 72 contents: read1msg: ld 0xb9c94970 msgid 2 message type intermediate ldap_parse_intermediate ber_scanf fmt ({) ber: ber_scanf fmt (a) ber: ber_scanf fmt (O) ber: ber_scanf fmt (t{) ber: ber_scanf fmt (m) ber: Segmentation fault [root@mirador /etc/openldap]# i also thought, it might probably be a memory error and run the memory-check for more than an hour: nothing was found. what can i do else? thank for all hints. suomi

3 2

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

24 Jul '08

Hi all, thanks for your valuable input. The hint towards the crle tool is a good one but I'd like to keep that kind of heavy artillery as a measure of last resort. In the meantime I analysed further and here's what I found: - I followed the fact that "make test" ran through without a single failed test, therefore the slapd which is fired up during that phase must be healthy. - The slapd / slurpd information I posted in my original email was taken from my destination directory. - By comparing the slapd binary in the build directory with the one at the destination it became apparent that they differ in size (build: about 8MBytes, destination: about 3 MBytes) - When checking out the slapd in the build directory I encountered a completely healthy binary which could be started and checked with ldd, truss etc. So the problem must be somewhere in the "make install" step - in a simplistic view that should merely be a simple file copy from build to destination but apparently the slapd is not only copied but somehow "re-assembled" which leads to an incomplete state of slapd that dies immediately. As I couldn't find any options for "make install" in the admin guides I'd be grateful for any hints/pointers helping me to overcome that last hurdle. Thanks Christoph

2 1

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

24 Jul '08

Hi all, I'm in the process of compiling/installing OpenLDAP 2.3.39 for Solaris 10 with OpenSSL 0.9.8g and BDB 4.5.20 as underlying libraries. What I've accomplished so far: - Built BDB 4.5.20, installed openssl 0.9.8g (SMCossl) - Got through with OpenLDAP installation (all steps from "configure" via "make depend", "make", "make test" to "make install") without any errors The problem I encounter: - I'm trying to start slapd as "root" (with -u and -g to a technical user) and it dies immediately with just "Killed" as the sole error message - If I'm executing ldd against my slapd binary it goes: "ldd: ./slapd: execution failed due to signal 9" - Similar problem with truss: "truss: cannot execute program: ./slapd" When doing the above tries I had the environment set as follows: PATH=/usr/bin:/usr/sbin:/usr/local/bin:.:/usr/sfw/bin:/usr/ccs/bin:/usr/local/ssl/:/opt/eplatform/db-4.5.20.NC-p2/bin/ LD_LIBRARY_PATH=/usr/lib:/usr/local/lib:/opt/eplatform/db-4.5.20.NC-p2/lib:/usr/local/ssl/lib and slapd/slurpd look like: -rwxr-xr-x 1 root other 3631552 Jul 22 08:32 slapd -rwxr-xr-x 1 root other 745236 Jul 22 08:32 slurpd slapd doesn't even get a chance to write into its log, so I'm really not having many clues. Does anyone have any clues as to what slapd is suffering from ? Thanks Christoph

4 5

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

23 Jul '08

Hi all, I called configure as follows (everything on one line): env LDFLAGS="-L/opt/eplatform/db-4.5.20.NC-p2/lib -L/usr/local/ssl/lib -R/opt/eplatform/db-4.5.20.NC-p2/lib -R/usr/local/ssl/lib" CPPFLAGS="-I/opt/eplatform/db-4.5.20.NC-p2/include -I/usr/local/ssl/include" ./configure --prefix=/opt/eplatform/openldap-2.3.39 --with-tls --with-cyrus-sasl --enable-overlays --enable-bdb --enable-hdb --enable-ldap --enable-meta --enable-cleartext --enable-spasswd --disable-crypt --disable-passwd --enable-monitor --enable-aci --enable-rewrite --enable-debug --enable-syslog --enable-relay so I suppose, yes I had LDFLAGS set and it also contained the -R flag for both BDB and OpenSSL. The following calls of make I did without any special environment set, i.e. just make depend make make test make install Thanks so far Christoph

3 2

how to configure multi-master
by Liutauras Adomaitis 22 Jul '08

22 Jul '08

Hello, I feel a little bit spaming this list, but still - how to setup multi-master? Reading http://www.zytrax.com/books/ldap/ch7/#ol-syncrepl http://www.openldap.org/doc/admin24/replication.html gave me impression that simply adding serverID in global (above database) section, syncrepl and overlay syncprov in database section should give me multi master setup. THis did worked - meaning I got the same data on both servers, but I couldn't make updates to either of servers. Google says absolutely nothing about that. The error is "shadow context; no update referral at ..." Adding updateref directive to conf file seemed to me wrong, because multi master is meant to be multi write nodes setup, so I didn't tried that. After about four hours of searching for any full working example of multi-master implementation I decided to put mirror mode true on both servers at the end of conf file - that did the trick. So do I need add mirror mode or not? It is not clear the difference of multi-master and mirror mode, which I asked on different message. I didn't tried setting mirror mode false and see if updates are working, but if this is what I missed, then it is very strange, that official administrators guide is missing such a key point. Thanks a lot if anybody would explain my mistakes Liutauras

3 7

smbk5pwd help
by greek ordono 22 Jul '08

22 Jul '08

Hello, I having error while trying to change password with smbk5pwd enabled. ERROR: slapd: symbol lookup error: /usr/lib/ldap/smbk5pwd-2.4.so.2: undefined symbol: MD4_Init OS: Ubuntu Hardy LDAP: 2.4.7-6ubuntu3 Thanks, grexk

6 7

Problems with SASL EXTERNAL and ldapi:// on solaris
by David Markey 22 Jul '08

22 Jul '08

When trying to bind to ldapi:// with SASL EXTERNAL auth i get this error from slapd on solaris. ==> sasl_bind: dn="" mech=EXTERNAL datalen=0 send_ldap_result: err=7 matched="" text="SASL(-4): no mechanism available: " connection_get(12) ber_dump: buf=82c5408 ptr=82c5408 end=82c540d len=5 0000: 02 01 02 42 00 slapd.conf(snippet): sasl-secprops minssf=0 sasl-regexp .*uidNumber=0.*,cn=peercred, cn=external,cn=auth uid=heimdal,dc=services,dc=dmarkey,dc=com Would anyone be able to help me? Solaris 10 x86, slapd 2.3.39(have also tried 2.4) I've established this is a solaris specific problem, i compiled everything from scratch on CentOS with the same options and it worked fine. Anyone have any ideas? are sockets different on solaris? Much appreciated. David Markey

3 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software