Installing
by Dalen, van William
Hi,
When i want to install OpenLDAP i began with install the deamon and utils with the command
sudo apt-get install slapd ldap-utils
I got an error. This is the output:
Preconfiguring packages ...
Unquoted string "pm" may clash with future reserved word at /usr/share/perl5/Deb
conf/Element/Noninteractive/Boolean.pm line 5, <GEN1> line 1.
Can't locate object method "new" via package "Debconf::Element::Noninteractive::
Boolean" (perhaps you forgot to load "Debconf::Element::Noninteractive::Boolean"
?) at /usr/share/perl5/Debconf/FrontEnd.pm line 68, <GEN1> line 1.
(Reading database ... 52208 files and directories currently installed.)
Unpacking slapd (from .../slapd_2.4.23-6ubuntu6_amd64.deb) ...
Unquoted string "pm" may clash with future reserved word at /usr/share/perl5/Deb
conf/Element/Noninteractive/Boolean.pm line 5, <GEN1> line 2.
Can't locate object method "new" via package "Debconf::Element::Noninteractive::
Boolean" (perhaps you forgot to load "Debconf::Element::Noninteractive::Boolean"
?) at /usr/share/perl5/Debconf/FrontEnd.pm line 68, <GEN1> line 2.
dpkg: error processing /var/cache/apt/archives/slapd_2.4.23-6ubuntu6_amd64.deb (
--unpack):
subprocess new pre-installation script returned error exit status 9
Errors were encountered while processing:
/var/cache/apt/archives/slapd_2.4.23-6ubuntu6_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
I am a newbie to Linux and OpenLAP. I don't know what this output means, so i can't solve the problem (for now).
Please can anyone help me?
With regards, William
11 years, 4 months
cn=config configuration method
by Giles Coochey
I'm trying to get my head round configuring OpenLDAP 2.4 until Centos 6.
So much documentation refers to slapd.conf
Under Centos 6, it appears that cn=config is in use.
So is reconfiguring OpenLDAP simply a case of editing the .ldif files in
/etc/openldap/slapd.d
Or should I be modifying the directory to reconfigure - presumably by some
combination of slapadd etc...
Thanks
Giles
11 years, 4 months
after restart slapd server I cannot search single record in ldap servers
by Marcin Więcek
Hello,
I set up an slapd with slapd-meta backend. I have two Active Directory
servers which don't share any portion of naming context. I would like
to get one virtual domain. I configure it and it works fine until I
restart slapd server. When I restart slapd server then I am unable to
search in my ldap servers single record.
When I search one single record (samAccountName=testdom1) then I have
got 0 result.
root@slapd:~# ldapsearch -b 'dc=dom,dc=com' -h 172.30.14.190 -p 389 -D
'cn=Manager,dc=dom,dc=com' -w secret '(samAccountName=testdom1)'
# extended LDIF
#
# LDAPv3
# base <dc=dom,dc=com> with scope subtree
# filter: (samAccountName=testdom1)
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
root@slapd:~#
In the log (full debug) I have:
Jul 27 16:12:17 dom slapd[12096]: daemon: read active on 9
Jul 27 16:12:17 dom slapd[12096]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Jul 27 16:12:17 dom slapd[12096]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Jul 27 16:12:17 dom slapd[12096]: connection_get(9)
Jul 27 16:12:17 dom slapd[12096]: connection_get(9): got connid=1000
Jul 27 16:12:17 dom slapd[12096]: connection_read(9): checking for
input on id=1000
Jul 27 16:12:17 dom slapd[12096]: op tag 0x42, time 1311775937
Jul 27 16:12:17 dom slapd[12096]: ber_get_next on fd 9 failed errno=0 (Success)
Jul 27 16:12:17 dom slapd[12096]: connection_read(9): input error=-2
id=1000, closing.
Jul 27 16:12:17 dom slapd[12096]: connection_closing: readying
conn=1000 sd=9 for close
Jul 27 16:12:17 dom slapd[12096]: connection_close: deferring conn=1000 sd=9
Jul 27 16:12:17 dom slapd[12096]: conn=1000 op=2 do_unbind
Jul 27 16:12:17 dom slapd[12096]: conn=1000 op=2 UNBIND
Jul 27 16:12:17 dom slapd[12096]: connection_resched: attempting
closing conn=1000 sd=9
Jul 27 16:12:17 dom slapd[12096]: connection_close: deferring conn=1000 sd=9
Jul 27 16:12:17 dom slapd[12096]: daemon: activity on 1 descriptor
Jul 27 16:12:17 dom slapd[12096]: daemon: activity on:
Jul 27 16:12:17 dom slapd[12096]:
Jul 27 16:12:17 dom slapd[12096]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Jul 27 16:12:17 dom slapd[12096]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Jul 27 16:12:17 dom slapd[12096]: conn=1000 op=1 SEARCH RESULT tag=101
err=0 nentries=0 text=
Jul 27 16:12:17 dom slapd[12096]: connection_resched: attempting
closing conn=1000 sd=9
Jul 27 16:12:17 dom slapd[12096]: connection_close: conn=1000 sd=9
Jul 27 16:12:17 dom slapd[12096]: =>meta_back_conn_destroy: fetching
conn=1000 DN="cn=manager,dc=dom,dc=com"
Jul 27 16:12:17 dom slapd[12096]: daemon: removing 9
Jul 27 16:12:17 dom slapd[12096]: conn=1000 fd=9 closed
Then when I search full list of record (samAccountName=*) I have got
full list of records from two ldap servers.
root@slapd:~# ldapsearch -b 'dc=dom,dc=com' -h 172.30.14.190 -p 389 -D
'cn=Manager,dc=dom,dc=com' -w secret '(samAccountName=*)'
# search result
search: 2
result: 0 Success
# numResponses: 39
# numEntries: 38
root@slapd:~#
And this is the trick. From now... When I again search one single
record I got correct result - until I restart slapd server again. I
don't know what can be wrong. Any ideas?
root@slapd:~# ldapsearch -b 'dc=dom,dc=com' -h 172.30.14.190 -p 389 -D
'cn=Manager,dc=dom,dc=com' -w secret '(samAccountName=testdom1)'
# extended LDIF
#
# LDAPv3
# base <dc=dom,dc=com> with scope subtree
# filter: (samAccountName=testdom1)
# requesting: ALL
#
# testdom1, dom.com
dn: cn=testdom1,dc=dom,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: USER
cn: testdom1
givenName: testdom1
distinguishedName: cn=testdom1,dc=dom,dc=com
INSTANCETYPE: 4
WHENCREATED: 20110726100434.0Z
WHENCHANGED: 20110726160313.0Z
DISPLAYNAME: testdom1
USNCREATED: 24630
USNCHANGED: 24756
name: testdom1
OBJECTGUID:: +ERwSjOp5Uex1n86v5CurA==
USERACCOUNTCONTROL: 66048
BADPWDCOUNT: 0
CODEPAGE: 0
COUNTRYCODE: 0
BADPASSWORDTIME: 129561692315625000
LASTLOGOFF: 0
LASTLOGON: 129561692402968750
PWDLASTSET: 129561697935781250
PRIMARYGROUPID: 513
OBJECTSID:: AQUAAAAAAAUVAAAAMkafw9OC5FYbZ2/5UwQAAA==
ACCOUNTEXPIRES: 9223372036854775807
LOGONCOUNT: 0
SAMACCOUNTNAME: testdom1
SAMACCOUNTTYPE: 805306368
USERPRINCIPALNAME: testdom1(a)dom1.com
OBJECTCATEGORY: CN=Person,CN=Schema,CN=Configuration,DC=dom1,DC=com
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
root@slapd:~#
The log:
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "BADPWDCOUNT" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in
cache (CODEPAGE)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "CODEPAGE" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in
cache (COUNTRYCODE)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "COUNTRYCODE" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in
cache (BADPASSWORDTIME)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "BADPASSWORDTIME" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in
cache (LASTLOGOFF)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "LASTLOGOFF" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in
cache (LASTLOGON)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "LASTLOGON" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in
cache (PWDLASTSET)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "PWDLASTSET" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in
cache (PRIMARYGROUPID)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "PRIMARYGROUPID" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in
cache (OBJECTSID)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "OBJECTSID" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in
cache (ACCOUNTEXPIRES)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "ACCOUNTEXPIRES" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in
cache (LOGONCOUNT)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "LOGONCOUNT" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in
cache (SAMACCOUNTNAME)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "SAMACCOUNTNAME" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in
cache (SAMACCOUNTTYPE)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "SAMACCOUNTTYPE" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in
cache (USERPRINCIPALNAME)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "USERPRINCIPALNAME" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: result not in
cache (OBJECTCATEGORY)
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access to
"cn=testdom1,dc=dom,dc=com" "OBJECTCATEGORY" requested
Jul 27 16:19:22 dom slapd[12096]: <= root access granted
Jul 27 16:19:22 dom slapd[12096]: => access_allowed: read access
granted by manage(=mwrscxd)
Jul 27 16:19:22 dom slapd[12096]: conn=1003 op=1 ENTRY
dn="cn=testdom1,dc=dom,dc=com"
Jul 27 16:19:22 dom slapd[12096]: <= send_search_entry: conn 1003 exit.
Jul 27 16:19:22 dom slapd[12096]: send_ldap_result: conn=1003 op=1 p=3
Jul 27 16:19:22 dom slapd[12096]: send_ldap_result: err=0 matched="" text=""
Jul 27 16:19:22 dom slapd[12096]: send_ldap_response: msgid=2 tag=101 err=0
Jul 27 16:19:22 dom slapd[12096]: conn=1003 op=1 SEARCH RESULT tag=101
err=0 nentries=1 text=
Jul 27 16:19:22 dom slapd[12096]: daemon: activity on 1 descriptor
Jul 27 16:19:22 dom slapd[12096]: daemon: activity on:
Jul 27 16:19:22 dom slapd[12096]: 9r
Jul 27 16:19:22 dom slapd[12096]:
Jul 27 16:19:22 dom slapd[12096]: daemon: read active on 9
Jul 27 16:19:22 dom slapd[12096]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Jul 27 16:19:22 dom slapd[12096]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Jul 27 16:19:22 dom slapd[12096]: connection_get(9)
Jul 27 16:19:22 dom slapd[12096]: connection_get(9): got connid=1003
Jul 27 16:19:22 dom slapd[12096]: connection_read(9): checking for
input on id=1003
Jul 27 16:19:22 dom slapd[12096]: op tag 0x42, time 1311776362
Jul 27 16:19:22 dom slapd[12096]: ber_get_next on fd 9 failed errno=0 (Success)
Jul 27 16:19:22 dom slapd[12096]: connection_read(9): input error=-2
id=1003, closing.
Jul 27 16:19:22 dom slapd[12096]: connection_closing: readying
conn=1003 sd=9 for close
Jul 27 16:19:22 dom slapd[12096]: connection_close: deferring conn=1003 sd=9
Jul 27 16:19:22 dom slapd[12096]: conn=1003 op=2 do_unbind
Jul 27 16:19:22 dom slapd[12096]: conn=1003 op=2 UNBIND
Jul 27 16:19:22 dom slapd[12096]: connection_resched: attempting
closing conn=1003 sd=9
Jul 27 16:19:22 dom slapd[12096]: connection_close: deferring conn=1003 sd=9
Jul 27 16:19:22 dom slapd[12096]: daemon: activity on 1 descriptor
Jul 27 16:19:22 dom slapd[12096]: daemon: activity on:
Jul 27 16:19:22 dom slapd[12096]:
Jul 27 16:19:22 dom slapd[12096]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Jul 27 16:19:22 dom slapd[12096]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Jul 27 16:19:22 dom slapd[12096]: connection_resched: attempting
closing conn=1003 sd=9
Jul 27 16:19:22 dom slapd[12096]: connection_close: conn=1003 sd=9
Jul 27 16:19:22 dom slapd[12096]: =>meta_back_conn_destroy: fetching
conn=1003 DN="cn=manager,dc=dom,dc=com"
Jul 27 16:19:22 dom slapd[12096]: daemon: removing 9
Jul 27 16:19:22 dom slapd[12096]: conn=1003 fd=9 closed
My OpenLDAP version:
root@slapd:~# slapd -V
@(#) $OpenLDAP: slapd 2.4.23 (Jul 26 2011 14:53:23) $
root@slapd:/root/openldap-2.4.23/servers/slapd
My slapd.conf:
root@slapd:~# cat /usr/local/etc/openldap/slapd.conf
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/etc/openldap/schema/core.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
# Load dynamic backend modules:
# modulepath /usr/local/libexec/openldap
# moduleload back_bdb.la
# moduleload back_hdb.la
# moduleload back_ldap.la
loglevel 0xFFFF
access to * by * read
#######################################################################
# database definitions
#######################################################################
database meta
suffix "dc=dom,dc=com"
rootdn "cn=Manager,dc=dom,dc=com"
rootpw secret
chase-referrals no
#nretries forever
nretries 3
# 1 sec timeout for binds
bind-timeout 1000000
#norefs true
dncache-ttl DISABLED
conn-ttl 90
idle-timeout 1m30s
onerr CONTINUE
# ldap1
uri "ldap://dc1.dom1.com:389/dc=dom,dc=com"
suffixmassage "dc=dom,dc=com" "cn=Users,dc=dom1,dc=com"
idassert-bind bindmethod=simple
binddn="cn=LDAPconnector,cn=Users,dc=dom1,dc=com"
credentials="pass"
mode=none
flags=non-prescriptive
# ldap2
uri "ldap://dc2.dom2.com:389/dc=dom,dc=com"
suffixmassage "dc=dom,dc=com" "cn=Users,dc=dom2,dc=com"
idassert-bind bindmethod=simple
binddn="cn=LDAPconnector2,cn=Users,dc=dom2,dc=com"
credentials="pass"
mode=none
flags=non-prescriptive
root@slapd:~#
King regards,
Marcin
11 years, 4 months
Excessive logging at stats loglevel: any useful alternative to none?
by Nick Urbanik
Dear Folks,
We are running openldap-servers-2.3.43-12.el5_6.7 on CentOS 5 on four
HP blades. We have only stats loglevel:
grep level /etc/openldap/slapd.conf
loglevel stats
...but these servers are rather busy, and the logfiles are massive:
# ls -lSr | tail -n4
-rw------- 1 root root 7160148590 Jul 28 10:48 ldap
-rw------- 1 root root 24102619198 Jul 26 04:02 ldap.3
-rw------- 1 root root 25034865261 Jul 27 04:02 ldap.2
-rw------- 1 root root 25504838803 Jul 28 04:02 ldap.1
and are threatening to fill the disk. We want *some* logging, but we
don't want too much. Can anyone suggest a useful log level here?
It would be great to have some control over the verbosity of logging
of each subsystem; for example, we cannot log any information about
syncrepl, as that would totally fill our disks.
--
Nick Urbanik http://nicku.org 808-71011 nick.urbanik(a)optusnet.com.au
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24
I disclaim, therefore I am.
11 years, 4 months
Translucent overlay
by Conger,Keith
Hi List Members
I'm using OpenLDAP in a translucent overlay configuration to store the
attributes for our custom schema. All other attributes come from the
backend LDAP server(ActiveDirectory). When I try to modify an attribute
that is stored on the backend LDAP Server(ActiveDirectory), the change
is stored in the translucent overlays database and not written to the
backend LDAP server(ActiveDirectory). Is it possible for a client
connected to OpenLDAP to modify an attribute in the backend LDAP
server(ActiveDirectory)? The attribute I'm mainly concerned with is
"unicodePwd" which Active Directory uses for password storage. If this
isn't possible, does anyone have a different approach I'm missing?
Background:
Were creating a password reset web app that I'd like to only communicate
to OpenLDAP. OpenLDAP will store of password question/answer along with
some other identity verification data, but the password needs to be set
within Active Directory since there are Desktops authenticating users.
Thanks for any help
--
Keith Conger
Enterprise Systems Administrator
Onondaga Community College
4585 West Seneca Turnpike
Syracuse, N.Y. 13215-4585
Phone: 315.498.2767
Email/JID: congerk(a)sunyocc.edu
Web: http://myhome.sunyocc.edu/~congerk/
11 years, 4 months
client LDAP configuration issue
by Christophe Thibault
Hello,
I'm currently encountering a weird issue I don't understand.
I'm working on this problem since 3 days now, withount any clue.
My problem:
I built a sample client that connect to a LDAP server, to test
authentication.
It works fine for LDAP, but fails for LDAPS, as long as I don't provide
the right certs.
The issue is that I tried setting the TLS_CACERT in different locations
without success (I tried in the system /etc/ldap/ldap.conf, custom
location by setting the LDAPCONF env variable, setting environment
variable LDAPTLS_CACERT, etc.)
What is weird (for me) is that using the same ldap.conf (global or
user), or environment variable works for the ldapsearch client that
comes witth the openldap distribution.
More strange, is that setting the TLS_REQCERT parameter (either in
ldap.conf or in an environment variable) works for my custom client.
In my client, displaying
I probably missed something, do I need to explicitely call some function
to initialize these parameters?
Is there any way to trace calls to these internal functions that should
read the ldap.conf or environment variables?
Any idead is welcome!
thanks,
chris
11 years, 4 months
SASL Pass-through password reset
by Conger,Keith
Hi,
Does anyone know if its possible to reset a password when using OpenLDAP
with SASL pass-through to an 2008 Active Directory either through GSSAPI
or LDAPS. I've read that you you can change a password, but we need to
be able to reset with an administrative level account when a user
forgets their password.
Thanks in Advance,
Keith
--
Keith Conger
11 years, 4 months
SlapD is using more CPU
by arun.sasi1＠wipro.com
Hello Team,
Whenever the number of search increase to the master server... slapd is
utilizing more about more than 100%... What could be the reason and also
is there any bench mark defined...
Whenver it goes 100% slapd server is getting stopped...
Thanks & Regards,
Arun Sasi V
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
11 years, 4 months
Active Directory OpenLDAP Proxy
by Marc Schöchlin
Hello OpenLDAP Users,
i setup da openldap-instance as described at
https://help.ubuntu.com/10.04/serverguide/C/openldap-server.html.
It seems that the Objectclass "olcOverlayConfig" is missed - where can i
find that objectclass?
Is there a complete manual available which describes how to setup a
active directory proxy server?
Is it possible to modify the configuration using a ldap browser like
active directory studio?
To use that server to be a proxy to a active directory server i am
trying to add the following configuration:
proxy2.ldif
---
dn: olcDatabase={2}ldap
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: {2}ldap
olcSuffix: dc=proxy,dc=foobar,dc=de
olcRootDN: dc=foobar,dc=local
olcDbURI: "ldap://10.45.2.11:389"
dn: olcOverlay={0}pcache
objectClass: olcOverlayConfig
objectClass: olcPcacheConfig
olcOverlay: {0}pcache
olcPcache: bdb 100000 1 1000 100
olcPcacheAttrset: 0 mail postalAddress telephoneNumber
olcPcacheTemplate: "(sn=)" 0 3600 0 0 0
olcPcacheTemplate: "(&(sn=)(givenName=))" 0 3600 0 0 0
olcPcacheTemplate: "(&(departmentNumber=)(secretary=))" 0 3600
dn: olcDatabase={0}hdb
objectClass: olcHdbConfig
objectClass: olcPcacheDatabase
olcDatabase: {0}hdb
olcDbDirectory: ./proxy-db.2.a
olcDbCacheSize: 20
olcDbIndex: objectClass eq
olcDbIndex: cn,sn,uid,mail pres,eq,sub
---
LDAP-ADD Complains:
# ldapadd -vvv -Y EXTERNAL -H ldapi:/// -f /etc/ldap/proxy.ldif
ldap_initialize( ldapi:///??base )
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
add objectClass:
olcDatabaseConfig
olcLDAPConfig
add olcDatabase:
{2}ldap
add olcSuffix:
dc=proxy,dc=foobar,dc=de
add olcRootDN:
dc=foobar,dc=local
add olcDbURI:
"ldap://10.41.2.12:389"
adding new entry "olcDatabase={2}ldap"
ldap_add: Invalid syntax (21)
additional info: objectClass: value #1 invalid per syntax
I
11 years, 4 months
retry: counter not reaching zero, continuing on
by ml+openldap＠esmtp.org
While trying to determine how syncrepl behaves in various error
conditions, I encountered an unexpected behaviour in which
the retry specification doesn't seem to work. A MASTER is
set up to use push replication to a REPLICA as follows:
database ldap
hidden on
suffix ""
rootdn "cn=slapd-ldap"
uri ldap://REPLICA/
lastmod on
restrict all
sync_use_subentry true
acl-bind bindmethod=simple
binddn="cn=Monitor"
credentials=password
syncrepl rid=001
provider=ldapi://%2Fvar%2Frun%2Fldapi
binddn="cn=Manager"
bindmethod=simple
credentials=passwd
searchbase=""
type=refreshAndPersist
retry="5 5 60 +"
When I stop the REPLICA and add an entry on the MASTER, then the MASTER
is retrying every 5s and claims that 4 (sometimes 3) retries are left:
Jul 22 13:12:52 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left)
Jul 22 13:12:57 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left)
Jul 22 13:13:02 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left)
Jul 22 13:13:07 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left)
Jul 22 13:13:12 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left)
Jul 22 13:13:17 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left)
Jul 22 13:13:22 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left)
Jul 22 13:13:28 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left)
Jul 22 13:13:33 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left)
Jul 22 13:13:38 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left)
Jul 22 13:13:43 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left)
Jul 22 13:13:48 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left)
Jul 22 13:13:53 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left)
Jul 22 13:13:58 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left)
When I start REPLICA again, syncrepl succeeds.
Do I have to set some other option such that the retry specification
is actually used? That is, try every 5s for 5 times, then try every
60s. Or is the retry logic dependent on the error syncrepl encounters?
The full log for one failed retry is:
conn=1004 op=0 BIND dn="cn=manager" method=128
conn=1004 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0
conn=1004 op=0 RESULT tag=97 err=0 text=
conn=1004 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)"
conn=1004 op=1 SRCH attr=* +
srs csn 20110722201233.471069Z#000000#001#000000
log csn 20110722201233.471069Z#000000#001#000000
cmp 0, too old
log csn 20110722201252.820971Z#000000#001#000000
Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000
syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000
syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0
conn=1004 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi)
syncrepl_entry: rid=001 be_search (52)
syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com
null_callback : error code 0x34
syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52)
syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52)
do_syncrepl: rid=001 rc 52 retrying (4 retries left)
conn=1004 op=2 UNBIND
conn=1004 fd=15 closed
connection_read(15): no connection!
connection_read(15): no connection!
11 years, 4 months
