openldap-software

openldap-software@openldap.org

2719 discussions

client authentication
by prasanth allada 09 Jul '08

09 Jul '08

Hi i want to write a program to access the data from an ldap server using client authentication. what sasl mechanism should i use to connect to the server and what options should i set inorder for the client to connect to the server without using any passwords the connections should take place based on the client certificate. thanks and regards prasanth

1 0

cn=config multimaster olcAuthzRegexp not working
by Gémes Géza 09 Jul '08

09 Jul '08

Hi, I'm running openldap 2.4.9 on three boxes one production, two in the process of setting them up for multimaster replication (in case of success the third is going to be joined to the setup) I've successfully migrated from slapd.conf to cn=config using slaptest -f ... -F ..., at this step everything works as expected. After ldapmodifying (for multimaster syncrepl) with the following ldif (a customized version of the one from the admin guide): dn: cn=config changetype: modify add: olcServerID olcServerID: 1 ldaps://first.kzsdabas.hu olcServerID: 2 ldaps://second.kzsdabas.hu olcServerID: 3 ldaps://third.kzsdabas.hu dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldaps://first.kzsdabas.hu bindmethod=sasl saslmech=GSSAPI authcid=ldapsyncrepl searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldaps://second.kzsdabas.hu bindmethod=sasl saslmech=GSSAPI authcid=ldapsyncrepl searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=003 provider=ldaps://third.kzsdabas.hu bindmethod=sasl saslmech=GSSAPI authcid=ldapsyncrepl searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={1}bdb,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=004 provider=ldaps://first.kzsdabas.hu bindmethod=sasl saslmech=GSSAPI authcid=ldapsyncrepl searchbase="dc=kzsdabas,dc=hu" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=005 provider=ldaps://second.kzsdabas.hu bindmethod=sasl saslmech=GSSAPI authcid=ldapsyncrepl searchbase="dc=kzsdabas,dc=hu" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=006 provider=ldaps://third.kzsdabas.hu bindmethod=sasl saslmech=GSSAPI authcid=ldapsyncrepl searchbase="dc=kzsdabas,dc=hu" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE everything still works, but after restarting slapd, the bdb database dc=kzsdabas,dc=hu becomes unaccessible. slapd runing with debuglevel set to -1 writes: => bdb_search bdb_dn2entry("DC=kzsdabas,DC=hu") => bdb_dn2id("DC=kzsdabas,DC=hu") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30990) Thanks for any ideas Geza

2 3

List of syncrepl fixes in each version?
by Brad T Waldorf 08 Jul '08

08 Jul '08

Hi. In reference to a multimaster question, Howard Chu said that there have been a couple hundred bug fixes from 2.4.7 to 2.4.9. http://www.openldap.org/lists/openldap-technical/200805/msg00119.html And i saw a post yesterday from Michael Stroeder saying that there have been important fixes to syncrepl for 2.4.10. I'm on 2.4.6, able to use refreshOnly and refreshAndPersist successfully, but finding many pitfalls with Mirror Mode. Just wondering... is there a list of syncrepl fixes in each version? I'm curious to see whether the problems i'm having are known/fixed in future releases (or if it's a problem with my system/configuration). Thanks in advance

3 3

incompatible access control between versions
by openldap 08 Jul '08

08 Jul '08

Hi listers i observed the following: in openldap version 2.3.39 the following was acceptable: the access control statements for an ldap-database follow the definition of the database, i.e. in the slapd.conf file (and its includes) you could have the following sequence: <general section> <database1 secion> <access-control section to database1> <database2 section> <access-control section to database2> ... in openldap-version 2.4.8-3, however, the above sequence is no longer accepted, all access-controls must be in the general-section: the access-control, you get in this case, is the default one: "everyone authenticated can read everything", i.e. your access-controls are silently disregarded. you don't find a hint what's wrong with your access control, neither in the log nor on the error output. only after increasing the debug level to -d255 (-d15 is not sufficient), when starting slapd, you get "warning: ACL appears to be out of scope within backend naming context". i would rather have liked to see an error "access control error ..." on the error output when starting slapd, and the start failing alltoghether. suomi

2 1

Inappropriate matching (18): additional info: modify/delete: postalAddress: no equality
by Michael Ströder 06 Jul '08

06 Jul '08

HI! using OpenLDAP 2.4.10 (RE24) I'm trying to explicitly delete a value of attribute postalAddress: --------------------------------------------------------------- dn: cn=Fred Feuerstein,ou=Testing,dc=stroeder,dc=de changetype: modify delete: postalAddress postalAddress: zeile 1$zeile 2$zeile 3 - --------------------------------------------------------------- But this results in an error: modifying entry "cn=Fred Feuerstein,ou=Testing,dc=stroeder,dc=de" ldapmodify: Inappropriate matching (18) additional info: modify/delete: postalAddress: no equality matching rule But postalAddress is declared in the schema like this: ( 2.5.4.16 NAME 'postalAddress' DESC 'RFC2256: postal address' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) Aarrgh! What's up with that? If the equality matching rule is not implemented it should not be announced in the subschema. The server should not simply report what might have been defined in some RFC. Background: When generating deltas in web2ldap attribute values are now explicitly deleted if there's an EQUALITY matching rule defined for an attribute type. This is done to prevent applying changes in case an entry and its attributes was changed during the user editing the entry. Ciao, Michael.

1 0

One more ACL question
by manu＠netbsd.org 06 Jul '08

06 Jul '08

Hello I have a tree where each ou has a manager attribute containing the DN of users allowed to perform some administrative operations: dn: ou=foo,o=home ou: foo objectClass: netExampleService manager: uid=admin,ou=bar,o=home I already have an ACL allowing managers to create and delete children in the ou where they are listed as manager: access to dn.regex="(ou=.+,o=home)$" attrs=children by group/netExampleService/manager.expand="$1" write stop by * read stop Now I would like to restrict the delete operation to children that do not have a given attribute set. i.e.: I want the ACL above to apply only on children matching the filter (!(locked=TRUE)) Is it possible? If it is not, is there a way to give the addition right without giving the delete right? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 1

openldap tls using ip addresses
by Yao Mingxi 06 Jul '08

06 Jul '08

Hi, I am trying to set up tls for ldap connection using self signed certificates and I realized that I must use the host name of the openldap server as the uri for tls to work. Is there a way to use ip addresses as uri and utilizing tls? And is there a way for multiple replicated openldap server to accept a single tls certificate? Any help is greatly appreciated. Mingxi

2 1

Re: segfaults with syncrepl
by Liutauras Adomaitis 04 Jul '08

04 Jul '08

On Wed, Jul 2, 2008 at 9:20 PM, Dieter Kluenter <dieter(a)dkluenter.de> wrote: > "Liutauras Adomaitis" <liutauras.adomaitis(a)gmail.com> writes: > > > On Tue, Jul 1, 2008 at 11:07 PM, Dieter Kluenter <dieter(a)dkluenter.de> > wrote: > > > > Hi, > > > > "Liutauras Adomaitis" <liutauras.adomaitis(a)gmail.com> writes: > > > > > Ok, I solved my problem with glueing databases.I added ldif file > > > > > Alias problem is not solved. Although I can use my luma browser and > see > > > replicas as if they were one database, aliases are not working. Is > this > > by > > > design? Is there any way to make them work in glued databases? I > just > > need a > > > confirmation if somebody thinks I'm not reading manuals :) > > > > I haven't thought about it in depth and i haven't tested it, but > think > > about > > what is to be replicated, the alias entry or the aliased entry, or > > both? slapd doesn't know, if the alias entry is to be replicated, the > > relax control has to be initiated, otherwise the follow alias > > parameter in ldap.conf. > > > > Ok,I tried that: > > added DEREF always to my replicas /etc/openldap/ldap.conf file and > restarted > > ldap > > My provider started throwing: > > SRCH base="o=BranchX,dc=example,dc=com" scope=2 deref=3 > filter="(objectClass= > > *)" > > SRCH attr=* + > > SEARCH RESULT tag=101 err=2 nentries=0 text=illegal value for > derefAliases > > UNBIND > > > probably the seeAlso attribut type may be convenient to you. > > > > Could you please explain how? > > just an example entry: > > dn: cn=foo bar,ou=people,o=myCompany > objectClass: person > cn: foo bar > sn: foo > seeAlso: cn=foo bar,ou=otherPeople,o=myCompany > Ups, I think I sent previous message only to Dieter, so resending it again, and dear ask Dieter again: I couldn't find any good info about seeAlso atribute, so what should I expect out of the this entry should it behave similar as alias? I'm using my aliases for authenticated (just in case it is important) Liutauras

2 1

Chaining
by Jorge Medina 03 Jul '08

03 Jul '08

One more question, this time on the chaining overlay. "What is chaining? It indicates the capability of a DSA to follow referrals on behalf of the client, so that distributed systems are viewed as a single virtual DSA by clients that are otherwise unable to "chase" (i.e. follow) referrals by themselves." In the example shown at http://www.openldap.org/doc/admin24/overlays.html#Chaining Is the chaining overlay example used to forward write requests from the syncrepl slaves to the master server? -Jorge

2 3

ACL Help Please
by david stackis 02 Jul '08

02 Jul '08

Hello List - Please forgive my ignorance regarding the ACL's in OpenLDAP. For Starters I'm using OpenLDAP Software 2.4, and I've obtained the software from sunfreeware.com. OpenLDAP is running on a Solaris 10 Sparc system. My goal is to have each one of my user able to read/write to their own personal address book. I've added my initial LDIF file, and configured slapd as best I could understand. I can ldapadd using the root dn, and I can see all of the entries that I added using ldapsearch. However when I try to add to my personal entry, I receive this error. ldapadd -D "cn=Elliott Smith,ou=users,dc=Company,dc=com" -f contact.ldif Enter bind password: adding new entry cn=Nick Drake,ou=addressbook,dc=Company,dc=com ldap_add: Insufficient access ldap_add: additional info: no write access to parent Below are my LDIF and slapd. I want to express that I have read through as much of this list as I could regarding the "no write access to parent", and I've found many have similar issues. I feel that my setup is fairly straight forward. Any help is much appreciated. Let me know if you need more information. The LDIF I used to begin... # Initialize the suffix entry defined in slapd.conf # dn: dc=company,dc=com objectclass: top objectclass: dcObject objectclass: organization dc: company o: corporate # # Initialize the AddressBooks heirarchy # dn: ou=addressbook,dc=company,dc=com objectclass: top objectclass: organizationalUnit ou: addressbook # # Define individual address books # dn: o=hr,ou=addressbook,dc=company,dc=com objectclass: top objectclass: organization o: hr # # Initialize the Users heirarchy # dn: ou=users,dc=company,dc=com objectclass: top objectclass: organizationalUnit ou: users # # Define individual users # dn: cn=Elliott Smith,ou=users,dc=company,dc=com objectclass: top objectclass: person cn: Elliott Smith sn: Smith userPassword: mysecret uid: esmith The slapd I'm using... # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.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_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.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 # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # # access to dn.regex="(.+,)?(uid=[^,]+,o=isc)$" by dn.exact,expand="$2" write 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 ####################################################################### database bdb suffix "dc=Company,dc=com" rootdn "cn=root,dc=Company,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data # Indices to maintain index objectClass eq ------------------- david stackis uc santa barbara

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