openldap-software June 2008

openldap-software@openldap.org

62 participants
64 discussions

slapauth - requires SASL support?
by Brad T Waldorf 17 Jun '08

17 Jun '08

Hi Sorry again if this is the wrong place for OpenLDAP questions. I've got a question about slapauth... We don't have SASL support enabled. The immediate question is... does slapauth require SASL support? (I've seen a bunch of SASL references in my quest to find some slapauth examples on the web.) So here's the only slapauth example i've been able to find (repeatedly) .... The command /usr/local/sbin/slapauth -f //usr/local/etc/openldap/slapd.conf -v \ -U bjorn -X u:bjensen tests whether the user bjorn can assume the identity of the user bjensen provided the directives authz-policy from authz-regexp "^uid=([^,]+).*,cn=auth$" "ldap:///dc=example,dc=net??sub?uid=$1" are defined in slapd.conf(5). I've read the authz-policy and authz-regexp descriptions in the slapd.conf man page, but i'm relatively new to OpenLDAP, and admittedly don't understand much of those descriptions. I've been trying the following command, which i think should yield a successful authorization, but the authorization fails. /usr/local/sbin/slapauth -v -f /usr/local/etc/openldap/slapd.conf -U "cn=BDB1man,o=BDB1" -X u:"cn=John Thayer,o=BDB1" bdb_monitor_open: monitoring disabled; configure monitor database to enable <= bdb_equality_candidates: (objectClass) not indexed <= bdb_equality_candidates: (objectClass) not indexed ID: <cn=BDB1man,o=BDB1> authcDN: <uid=cn\3Dbdb1man\2Co\3Dbdb1,cn=auth> authzDN: <uid=cn\3Djohn thayer\2Co\3Dbdb1,cn=auth> authorization failed "cn=BDB1man,o=BDB1" is my rootdn, and "cn=John Thayer,o=BDB1" is an entry in the o=BDB1 tree.: My database declaration in slapd.conf is as follows... database bdb suffix "o=BDB1" rootdn "cn=BDB1man,o=BDB1" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw plop timelimit 1 idletimeout 4 # The userPassword attribute is writeable by the entry itself and # "StoogeAdmin". It may be used for authentication purposes, but # is otherwise not readable access to attrs=userPassword by self write by anonymous auth by dn.base="cn=BDB1man,o=BDB1" write by * none # All other attributes are writeable by the entry itself and # "StoogeAdmin", and may be read by all users access to * by self write by dn.base="cn=BDB1man,o=BDB1" write by * read # 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 sn,mail,uid,title eq So since i allow "cn=BDB1man,o=BDB1" write access to everything, i was thinking he should be able to assume the identity of "cn=John Thayer,o=BDB1", and the slapauth authorization should be allowed. But if slapauth requires SASL support, then this whole thing is easily explained. (that would be why the authorization is failing right?) Thanks in advance for your help!

1 0

Re: openldap
by Michael Ströder 17 Jun '08

17 Jun '08

Aravind Arjunan wrote: > ldap_modify: Cannot modify object class (69) > additional info: structural object class modification from > 'person' to ' > inetOrgPerson' not allowed You cannot change a structural object class. 'person' and 'inetOrgPerson' are both structural object classes with the latter derived from the former. In this case you have to delete and re-add the entries. See also: http://www.openldap.org/faq/data/cache/1341.html Ciao, Michael.

1 0

Can't add, delete or modify entries
by Rob Tanner 17 Jun '08

17 Jun '08

I can no longer add, delete or modify existing entries. For all intents and purposes, this an all-of-the-sudden it quit working. Actually it's my test environment and it's where I point to when I'm developing code that reads/writes to LDAP. The machine hung about a week ago and it actually had to be power cycled to get it back but since I haven't actually accessed that server in several weeks, I don't know if the problem is related to the server problem. I couldn't find any reason so I shut the OpenLDAP down, used slapcat to dump the whole database and then I removed everything but the DB_CONFIG file and all the files under /var/log/ldap. I used slapadd (as the ldap user) to rebuild the database and thn started up OpenLDAP again. No difference. Slapadd put everything back, but I can't can't add, delete or modify. I m running OpenLDAP v.3.2.7 and Fedora Core 6. Fortunately this is not the production server so I've got room to play. Any ideas about what I need to play with? Thanks, Rob Tanner Linfield College

3 2

Re: openldap
by Michael Ströder 17 Jun '08

17 Jun '08

Aravind Arjunan wrote: > ldap_add: Object class violation (65) > additional info: attribute 'mail' not allowed > > What i need to do for adding this attribute. tell me the correct > objectclass for this attribute. Most people use object class 'inetOrgPerson' for adding attribute 'mail' to user/person entries. Since you don't provide an example entry nobody can tell what's right for your data. Ciao, Michael.

1 0

Re: syncrepl in OpenLDAP 2.3.x and updating on a replica
by Michael Ströder 16 Jun '08

16 Jun '08

Filipe Brandenburger wrote: > So, my questions are: > > 1. How do I get ldapmodify, ldapdelete, ... to follow referrals? > > 2. Will pam_ldap (when changing passwords) follow referrals? You shouldn't chase referrals at the client's side. Rather use slapo-chain to let the server chase the referral (chain the request to the master). > I will try to see if referrals will work first, then I'll > start going down that route. The LDAPv3 specification is incomplete regarding referrals since it does not specifiy what the client should do regarding binding to the referred server. So vendors implemented it differently. Example: The rule within MS AD domains is to just use the domains credentials you used before. But it's not implemented like this in OpenLDAP libs since not generally true. In web2ldap I'm presenting a login form to the user letting him interactively decide what to do when chasing the referral. Ciao, Michael.

1 0

slapo-rwm and map attribute
by Raphaël 'SurcouF' Bordet 16 Jun '08

16 Jun '08

Hi, I'm using OpenLDAP 2.3.38 under Solaris 10 and I'm trying to configure a relay from a another base. I've set many rwm-map directives and they, minus one, works fine : /----( /etc/ldap/slapd.conf )---- database relay suffix "o=Example,c=FR" relay "dc=example,dc=org" overlay rwm rwm-map objectclass frGovPerson organizationalPerson rwm-map objectclass inetOrgPerson * rwm-map objectclass person * rwm-map attribute mail * rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute ou o rwm-map attribute telephoneNumber * rwm-map attribute departmentNumber * rwm-map attribute departmentUID * rwm-map attribute l * rwm-map attribute postalCode * rwm-map attribute description * rwm-map attribute title rank rwm-map attribute facsimileTelephoneNumber * rwm-map attribute uid * rwm-map attribute initials * rwm-map attribute employeType * rwm-map objectclass * rwm-map attribute * \---8<---8<---8<---8<---8<---8<--- With this above configuration, I'm getting all attributes as mentionned by rwm-map attribute directives but no objectclass. If I comment the last directive, I get all attributes minus the objectclass that should have been removed with the similar line above it. Best regards, -- Raphaël 'SurcouF' Bordet

1 0

slurpd -d 65535 Invalid credentials error
by Yao Mingxi 14 Jun '08

14 Jun '08

Hello! I’m a newbie to openldap and I am trying to set up a replication openldap server following the guide at http://www.ibm.com/developerworks/linux/library/l-openldap/ . After configuration, slapd and slurpd started successfully but when I tried to use the slurpd –d 65535 command, the following error message pop up: Error: ldap_simple_bind_s for 10.0.11.6:389 failed: Invalid credentials The configurations of slapd.conf are as follow: Master: replogfile /var/lib/ldap/replog replica uri=ldap://10.0.11.6 binddn=”cn=Mananger,dc=example,dc=com” bindmethod=simple credentials=testing Slave: updatedn “cn=Manager,dc=example,dc=com” updateref ldap://10.0.11.5 The “cn=Manager,dc=example,dc=com” is the rootdn of both master and slave servers and I can use the password “testing” to successfully authenticates commands such as ldapsearch on both machines. What possibly could be the problem? Any help is greatly appreciated. Thanks! Sincerely, Yao Mingxi

3 2

API for assertion control
by Michael Ströder 14 Jun '08

14 Jun '08

HI! I'd like to implement the assertion control in python-ldap. Are there already any utility functions usable for generating the control value? Basically this would be turning a filter string representation into the BER. Yes? Preferrably in OpenLDAP 2.3.x libs (since 2.3 is currently the minimum requirement for building python-ldap). Ciao, Michael.

2 4

bdb 4.7?
by Dominic Hargreaves 13 Jun '08

13 Jun '08

Hello, I wondered if anyone had tested OpenLDAP with Berkeley DB 4.7? It's not listed as a possibility on http://www.openldap.org/doc/admin24/appendix-recommended-versions.html but maybe someone's looked at it anyway? I ask mostly out of curiosity, but also in case we need to move to 4.7 for other reasons. Thanks, Dominic. -- Dominic Hargreaves, Systems Development and Support Team Computing Services, University of Oxford

2 1

Seems I do not understand the ssf entries..... either that or something a bit more strange.
by Pat Riehecky 13 Jun '08

13 Jun '08

>From the doc ( http://www.openldap.org/doc/admin24/security.html ) ----------------- security controls disallow operations when appropriate protections are not in place. For example: security ssf=1 update_ssf=112 requires integrity protection for all operations and encryption protection, 3DES equivalent, for update operations (e.g. add, delete, modify, etc.). See slapd.conf(5) for details. ----------------- This sounds good to me, so I read the man page, added this to my slapd.conf, and restarted openldap but now I get "stronger confidentiality required for update" when making updates..... As a test I lowed the value to 34 (security ssf=1 update_ssf=34) halted slapd and ensured I got a clean restart. Updates still fail. If I lower it down to 31 it succeeds. Initial reactions would be to blame a lack of SSL for the low ssf failure. I assure you I am connecting with -ZZ and an ldapsearch -ZZ returns results. I have a suspicion that the problem is in part due to my lack of understanding. Here are the logs from an attempt (loglevel 256) conn=0 fd=17 ACCEPT from IP=127.0.0.1:48533 (IP=0.0.0.0:389) conn=0 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=0 op=0 STARTTLS conn=0 op=0 RESULT oid= err=0 text= TLS: gnutls_certificate_verify_peers2 failed -49 conn=0 fd=17 TLS established tls_ssf=32 ssf=32 conn=0 op=1 BIND dn="cn=admin" method=128 conn=0 op=1 BIND dn="cn=admin" mech=SIMPLE ssf=0 conn=0 op=1 RESULT tag=97 err=0 text= conn=0 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.1 conn=0 op=2 PASSMOD id="uid=test,ou=People,dc=testldap,dc=iwu,dc=edu" new conn=0 op=2 RESULT oid= err=13 text=stronger confidentiality required for update conn=0 op=3 UNBIND conn=0 fd=17 closed Where I think I am getting screwed up is at either tls_ssf=32 or mech=SIMPLE ssf=0 The tls_ssf seems very low to me. gnutls is perhaps not at the top of everyone's SSL list, but my reading of the doc is that it promises TLS1.0 and SSL3.0 without SSL2.0 ( http://www.gnu.org/software/gnutls/ ) and that "SSF greater than one (>1) roughly correlates to the effective encryption key length." ( http://www.openldap.org/doc/admin24/security.html ) I would not expect something that refuses SSL2 support to select a 32 bit cipher.... The ssf=0 for simple sasl auth makes perfect sense, I am trying a simple bind. A few vendor apps I have on hand wont do more than a simple bind so that is my low water mark as it were. In an ideal world I would like security update_ssf=128 simple_bind=112 to be working (force 3DES or better for a bind, for AES or better for an update), but I will settle for what must I do to make the documented example work for me? Pat Ubuntu 8.04 OpenLDAP 2.4.7 (installed from repo, linked against gnutls)

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software June 2008