openldap-software

openldap-software@openldap.org

2719 discussions

Problem when using 'accesslog' and 'refint' overlays in combination
by Alina Dubrovska 02 May '07

02 May '07

Hello dear list, Please try respond to this post, because that's very important for out project to fix described problem! We are trying to configure access logging in my OpenLDAP server (version is 2.3.27) using slapo-accesslog overlay. In slapd.conf I have configured accesslog database according to manual: database bdb suffix "cn=accesslog" rootdn "cn=root,cn=accesslog" rootpw accesslog index reqStart eq database bdb suffix "dc=main_domain,dc=com" checkpoint 1024 5 cachesize 10000 rootdn "cn=Administrator,dc=main_domain,dc=com" overlay accesslog logdb "cn=accesslog" logops writes logold (objectclass=person) In previous version of slapd.conf there was also slapo-refint overlay enabled to support 'uniqueMember' attribute update after member entry is renamed or deleted: overlay refint refint_attributes uniqueMember After turning on access logging I inspect the following problem: I create 2 users (objectclass=person) and a group (objectclass=groupOfUniqueNames), then I add both users to that group (add users DN values to uniqueMember attribute). Next I'm trying to rename (or delete) one of the member users and... LDAP hangs up with no response. When I connect once again, then I see that action was performed (user is renamed or deleted, but old member reference is present in group attributes). However, I'm not able to modify directory (that is add some new entry, modify attribute value etc) LDAP hangs up on any attempt and only OpenLDAP restart helps. Last note is that this problem appears only when both accesslog and refint are enabled. Separately they are working as expected. Does anybody have an idea about the reason of such a problem? We tried to find some useful information in logs, but nothing is there (maybe we just looked in wrong place) Maybe it's possbile to configure access-log to use database on different LDAP server? Maybe that could help? Please help! We need to have this working together! Thanks in advance, Alina.

2 1

back-config: close database, keep suffix
by Hallvard B Furuseth 02 May '07

02 May '07

I suspect I asked this before, but I don't remember... Can I do this? Close a database, replace it with a fresh slapadded one and reopen it, _without_ clients seeing its subtree temporarily disappear. So instead of deleting the database entry, modify it so operations against it either fail with 'unavailable' or (preferably) wait for the database to become on-line again, subject to the normal time limits. -- Regards, Hallvard

2 2

RE: LDAP Reference Works?
by Mark Mcdonald 02 May '07

02 May '07

Despite not understanding the architecture completely, it sounds like LDAP will fill your needs. Have a read of the following man pages to see if it's what you're after: slapd-ldap slapo-translucent slapo-chain Good luck! _____ From: Yang Sun [mailto:aegir.china@yahoo.com.cn] Sent: Monday, April 30, 2007 10:59 PM To: openldap-software(a)openldap.org Subject: LDAP Reference Works? Hi, I am new to LDAP world. And I am trying to design a distribute data structure for storing the user information in our project. I am not sure whether using ldap reference is the right way to do this job. Please give me some suggestion. The detailed situation is: We manage tens of sites. And the sites are orgnized in a tree structure. The requirement is to store the information in the local site (means no central place to store the information for all the sites). It will give the system the maximum flexiblity to expand and when the site is isolated the local site still works well. Sometimes, the local site will need information stored in other sites. I think it is a distribute database architecture. And it reminds me to use the LDAP reference function. So each local site will have a reference to its parent site and some references to its child sites. It gives a logical view of the tree with information for all the sites. I am not sure whether it is possible to do that and whether it has some difficulties to implement it using OpenLDAP. Any suggestion? Thanks, Yang Sun

2 1

Re: cn=config howto?
by Wai Phang 01 May '07

01 May '07

Hi Dieter, Thank you for the hint. Finally, I am able to add a new database. Also, I figured that rootDN doesn't allow quotation marks as well. Rgds Wai Phang >Hi, >olcSuffix syntax does not allow quotation marks. >-Dieter

1 0

Syncrepl-Consumer deletes entries
by Joachim Hergeth 01 May '07

01 May '07

Hello list, I have an OpenLDAP provider/consumer installation on two SLES10 systems. One is set up as a provider LDAP, the second is a consumer LDAP using "refreshOnly" synrepl synchronization. The LDAP provides user information for a Samba installation. The initial synchronization of the consumer works as expected. All LDAP entries are copied to the consumer directory. But after some time, usually when users log in into the Samba running with the provider LDAP, nearly 50% of all LDAP entries on the consumer are deleted. This happens without any change on the provider LDAP! Checking the logs I found, that delete-messages can be found in the consumers system log. I do not understand the source of the problem. No entries in the provider LDAP are deleted, so no entries should be deleted in the consumer. To check the installation, I set up a second consumer in a VMWare environment. And also in this system, which had been set up from scratch and only holds the OpenLDAP-consumer, the entries are deleted at the same time when they are deleted in the "real" OpenLDAP consumer system. When I change an attribute of an entry in the provider LDAP which has been deleted from the consumer by this process, like adding a description, this change is forwarded to th consumer and the entry "reappears" in the LDAP of the consumer. Any help or suggestion is appreciated. Thanks in advance Joachim Hergeth The providers slapd.conf is: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema #include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/samba3.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 /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args # Load dynamic backend modules: modulepath /usr/lib/openldap/modules # moduleload back_ldap.la # moduleload back_meta.la # moduleload back_monitor.la # moduleload back_perl.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access to user password # Allow anonymous users to authenticate # Allow read access to everything else # Directives needed to implement policy: ## Yast2 samba hack ACL ## allow the "ldap admin dn" access, but deny everyone else access to attrs=SambaLMPassword,SambaNTPassword by dn="cn=Administrator,dc=master-ldap,dc=gts-systems.de" write by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by * none ## Yast2 samba hack ACL done access to dn.base="" by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by self write by * auth access to dn.base="cn=Subschema" by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by * read access to attrs=userPassword,userPKCS12 by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by self write by * auth access to attrs=shadowLastChange by self write by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by * read access to * by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by * read by anonymous auth # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### schemacheck on idletimeout 30 loglevel 131 backend bdb database bdb suffix "dc=master-ldap,dc=gts-systems.de" rootdn "cn=Administrator,dc=master-ldap,dc=gts-systems.de" rootpw <some working password> directory /var/lib/ldap/ checkpoint 1024 5 cachesize 10000 index objectClass,entryCSN,entryUUID,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres index memberUID eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub overlay syncprov syncprov-checkpoint 100 1 syncprov-sessionlog 1 --------------------------------------------------------------------------- the consumers slapd.conf is: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema #include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba3.schema include /etc/openldap/schema/yast.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 /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args # Load dynamic backend modules: modulepath /usr/lib/openldap/modules # moduleload back_ldap.la # moduleload back_meta.la # moduleload back_monitor.la # moduleload back_perl.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access to user password # Allow anonymous users to authenticate # Allow read access to everything else # Directives needed to implement policy: access to dn.base="" by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by self write by * auth access to dn.base="cn=Subschema" by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by * read access to attrs=userPassword,userPKCS12 by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by self write by * auth access to attrs=shadowLastChange by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by self write by * read access to * by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write # by anonymous auth by * read # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### schemackeck on idletimeout 30 loglevel 15288 # TLSCertificateFile /etc/ssl/servercerts/servercert.pem # TLSCACertificatePath /etc/ssl/certs/ # TLSCertificateKeyFile /etc/ssl/servercerts/serverkey.pem database bdb suffix "dc=master-ldap,dc=gts-systems.de" rootdn "cn=Administrator,dc=master-ldap,dc=gts-systems.de" rootpw "<some working password>" directory /var/lib/ldap checkpoint 1024 5 cachesize 10000 index objectClass,uidNumber,gidNumber,entryCSN,entryUUID eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres index memberUID eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub syncrepl rid=321 provider=ldap://192.168.1.210:389 type=refreshOnly interval=00:00:00:30 searchbase="dc=master-ldap,dc=gts-systems.de" scope=sub schemachecking=off bindmethod=simple binddn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" credentials=<another nice password> ---------------------------------------------------------------------------

4 5

ppolicy, is a password reset the only way to unlock an account?
by Sam Tran 30 Apr '07

30 Apr '07

Hi All, I am currently testing slapo-ppolicy in OL 2.3.35. I have the following ppolicy: pwdFailureCountInterval: 0 pwdGraceAuthNLimit: 0 pwdInHistory: 0 pwdLockout: TRUE pwdLockoutDuration: 0 pwdMaxFailure: 3 pwdMustChange: FALSE pwdSafeModify: FALSE My question is the following: Let's say I lock my account after 3 unsuccessful binds. Is a password reset the only way to unlock it? Thanks, Sam

1 0

LDAP Reference Works?
by Yang Sun 30 Apr '07

30 Apr '07

Hi, I am new to LDAP world. And I am trying to design a distribute data structure for storing the user information in our project. I am not sure whether using ldap reference is the right way to do this job. Please give me some suggestion. The detailed situation is: We manage tens of sites. And the sites are orgnized in a tree structure. The requirement is to store the information in the local site (means no central place to store the information for all the sites). It will give the system the maximum flexiblity to expand and when the site is isolated the local site still works well. Sometimes, the local site will need information stored in other sites. I think it is a distribute database architecture. And it reminds me to use the LDAP reference function. So each local site will have a reference to its parent site and some references to its child sites. It gives a logical view of the tree with information for all the sites. I am not sure whether it is possible to do that and whether it has some difficulties to implement it using OpenLDAP. Any suggestion? Thanks, Yang Sun

1 0

rewriting compare ava with overlay rwm
by Jens Grigel 30 Apr '07

30 Apr '07

Hi, we're using openldap 2.3.35 as ldap proxy to support anonymous binds and searches to a restricted ldap server. We're now trying to rewrite existing cn's with old suffix to new cn's with new suffix of the restricted ldap server. So far almost everything is working with rwm-suffixmassage and overlay rwm except rewriting AVA's from ldapcompare. I'm still not sure if this is actually possible with overlay rwm or if i'm misunderstanding the manpage of slapo-rwm. Rewriting the cn's in searches, searchresults, bindDN and compareDN works, but the AVA from the compared attribute (here: cn) is not changed from rewriteContext compareAttrDN. "man slapo-rwm" says that the rewriteContext compareAttrDN rewrites compare AVA, but whatever i try it's not changing anything in the ldapcompare. What format of the rwm-rewriteRules for rewriteContext compareAttrDN is expected for rewriting to succeed? Or is this actually impossible what i'm thinking of? Here my shortened (removed a lot of rewriteRules, but still working) slapd.conf: # slapd.conf loglevel -1 include /usr/local/etc/openldap/schema/core.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args modulepath /usr/local/libexec/openldap moduleload rwm.la overlay rwm rwm-suffixmassage "o=sskm" "ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" database ldap suffix "ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" uri "ldap://5.1.35.254/" network-timeout 3 chase-referrals no idassert-bind bindmethod=simple binddn="cn=q001ldap,ou=dienstkonten,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" credentials="secret" mode=none idassert-authzFrom "dn.regex:.*" overlay rwm rwm-rewriteEngine on rwm-rewriteContext searchFilter rwm-rewriteRule "cn=99([0-9]{3})" "cn=s001x$1" ":@" rwm-rewriteContext bindDN rwm-rewriteRule "cn=99([0-9]{3}),(.+)" "cn=s001x$1,$2" ":@" rwm-rewriteContext searchEntryDN rwm-rewriteRule "cn=s001x([0-9]{3}),(.+)" "cn=99$1,$2" ":@" rwm-rewriteContext compareDN rwm-rewriteRule "cn=99([0-9]{3}),(.+)" "cn=s001x$1,$2" ":@" rwm-rewriteContext compareAttrDN rwm-rewriteRule "99([0-9]{3})" "s001x$1" # end slapd.conf The basic idea from this simple setup is to rewrite a cn=99854 to cn=s001x854 and back whereever possible. I'm trying with ldapcompare -x -D "" -H ldap://testproxy cn=99854,o=sskm cn:99854 this fails and produces the following logs slapd[9789]: do_compare slapd[9789]: >>> dnPrettyNormal: <cn=99854,o=sskm> slapd[9789]: <<< dnPrettyNormal: <cn=99854,o=sskm>, <cn=99854,o=sskm> slapd[9789]: [rw] compareDN: "cn=99854,o=sskm" -> "cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" slapd[9789]: >>> dnPrettyNormal: <cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: <<< dnPrettyNormal: <cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>, <cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: do_compare: dn (cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern) attr (cn) value (99854) slapd[9789]: conn=1 op=1 CMP dn="cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" attr="cn" slapd[9789]: [rw] compareDN: "cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" -> "cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" slapd[9789]: >>> dnPrettyNormal: <cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: <<< dnPrettyNormal: <cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>, <cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: send_ldap_result: conn=1 op=1 p=3 slapd[9789]: send_ldap_result: err=5 matched="" text="" packet capturing shows that the value is not rewritten when sent to the ldap server. Using the value which i was trying to rewrite to ldapcompare -x -D "" -H ldap://testproxy cn=99854,o=sskm cn:s001x854 succeeds slapd[9789]: do_compare slapd[9789]: >>> dnPrettyNormal: <cn=99854,o=sskm> slapd[9789]: <<< dnPrettyNormal: <cn=99854,o=sskm>, <cn=99854,o=sskm> slapd[9789]: [rw] compareDN: "cn=99854,o=sskm" -> "cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" slapd[9789]: >>> dnPrettyNormal: <cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: <<< dnPrettyNormal: <cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>, <cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: do_compare: dn (cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern) attr (cn) value (s001x854) slapd[9789]: conn=10 op=1 CMP dn="cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" attr="cn" slapd[9789]: [rw] compareDN: "cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" -> "cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" slapd[9789]: >>> dnPrettyNormal: <cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: <<< dnPrettyNormal: <cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>, <cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: send_ldap_result: conn=10 op=1 p=3 slapd[9789]: send_ldap_result: err=6 matched="" text="" -- Jens Grigel Citysavingsbank Munich, Germany Dept. of Network/Security

2 3

Replication on RDBMS level?
by Martin Cizek 28 Apr '07

28 Apr '07

Hi all, is it safe to use several slapd servers with slapd-sql backend connected to a replicated database? Are there any drawbacks of using RDBMS-level replication in comparison to slurpd? Thank you, Martin

1 0

How long should replication take?
by Norman Gaywood 27 Apr '07

27 Apr '07

I have a server and slave setup with syncrepl, openldap 2.3.34 Here is my syncrepl stanza on the slave: syncrepl rid=1 provider=ldap://ldap1.sample.edu.au:389 starttls=yes type=refreshAndPersist interval=00:00:01:00 retry=1,2,3,4,5,+ searchbase="dc=sample,dc=edu,dc=au" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off updatedn "cn=Replica,dc=sample,dc=edu,dc=au" bindmethod=simple binddn="cn=SyncUser,dc=sample,dc=edu,dc=au" credentials="secret" If I do only a few updates, the sync seems quite fast. If I run a script to make about 60,000 modifications on the master, this takes about 20 minutes to run. The slave starts updating immediately, however it soon falls behind. It takes over an hour, since the last change to the master, for the slave to be in sync. Is this expected behaviour? -- Norman Gaywood, Systems Administrator University of New England, Armidale, NSW 2351, Australia Please avoid sending me Word or Power Point attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

2 2

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