openldap-technical

openldap-technical@openldap.org

17 participants
9799 discussions

comp match module has unusable X509 cert code
by Lehnert, Hartmut 10 Aug '10

10 Aug '10

Hi all! I have performed some tests with the comp match module (yes it runs if you work around ITS 6556 ;-)). The result is that the comp match module only works with very simple X509 certs that use old algorithms! For example if you use X509 certificates with long serial numbers the snacc generated asn.1 parser (contained in file certificate.c) fails decoding the serial number. Another drawback: The attributes in Name components subject and issuer (cn, c, o, ou) have to be PrintableStrings; if for example there is an UTF8String present in the issuer the asn.1 parser fails decoding the issuer. All modern algorithms (sha256WithRSA, sha512WithRSA) are not recognized by the parser; if your X509 certificate is signed with sha256WithRSA the asn.1 parser fails decoding the AlgorithmIdentifier. In modern times these drawbacks aren't acceptable. Another appropriate asn.1 module for the X509 certificate structure has to be compiled with the openldap esnacc compiler. I would have done this but the openldap esnacc fails parsing its own modules!!! See something like this: openldap@ocsp-openldap24:~/Certificate> ~/openldap-snacc-2.3.6/compiler/esnacc -E BER_COMP -E GSER -t -d -f -I /home/openldap/openldap-snacc-2.3.6/asn1specs -I . Certificate.asn1 /home/openldap/openldap-snacc-2.3.6/asn1specs/asn1module.asn1(91) : parse error at symbol ""OID"" Parsing errors---cannot proceed The code in the asn.1 module: 88 ModuleId ::= SEQUENCE 89 { 90 name MyString, 91 oid OBJECT IDENTIFIER OPTIONAL --snacc cTypeName:"OID" isPtr:"TRUE" 92 } 93 Does anybody know how the esnacc error can be avoided? Regards, Hartmut

5 33

Multiple Admin
by Tears ! 09 Aug '10

09 Aug '10

Dear Users! I have ldap server running. Here is my ldap structure *dc=umar,dc=com (base) * 1) *dc=imran.com,dc=umar,dc=com *ou=users,dc=imran.com,dc=umar,dc=com ou=groups,dc=imran.com,dc=umar,dc=com 2) *dc=irfan.com,dc=umar,dc=com *ou=users,dc=irfan.com,dc=umar,dc=com ou=groups,dc=irfan.com,dc=umar,dc=com Ldap main user is (admin) which is master account. Now i want create another 2 admin users like (admin-irfan and admin-imran). *admin-imran* is the owner of *dc=imran.com* and *admin-irfan* is the owner of *dc=irfan.com*. Both admin can create,delete,update account in their respective domains. Would you please help me how i can do this. Regards, -- Umar Draz

1 0

ldap on Ubuntu 10.0.4
by Raymond Norton 09 Aug '10

09 Aug '10

Ubuntu 10.0.4 uses ldap 2.4.21, which does not use slapd.conf. I am having difficulty finding good documentation to configure openladap without slapd.conf. Is there a simple doc available on this? Raymond

11 13

repost: what makes client use mech=SIMPLE?
by Klavs Klavsen 08 Aug '10

08 Aug '10

Hi, I asked this before, but appearently no one took notice - or no one knows :( I have many ubuntu 8.04 clients which all work fine with my ldap server. I am now trying to connect a 10.04 client to the server - but login fails - and the only difference in output (in the debug file on the server) is the mech=SIMPLE line in the client that works. The one that works: Aug 4 10:21:36 ldap01 slapd[3077]: conn=1439319 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 4 10:21:36 ldap01 slapd[3077]: conn=1439319 op=2 BIND anonymous mech=implicit ssf=0 Aug 4 10:21:36 ldap01 slapd[3077]: conn=1439319 op=2 BIND dn="cn=Klavs Klavsen,ou=People,dc=example,dc=net" method=128 Aug 4 10:21:36 ldap01 slapd[3077]: conn=1439319 op=2 BIND dn="cn=Klavs Klavsen,ou=People,dc=example,dc=net" mech=SIMPLE ssf=0 Aug 4 10:21:36 ldap01 slapd[3077]: conn=1439319 op=2 RESULT tag=97 err=0 text= The one that fails: Aug 4 10:19:20 ldap01 slapd[3077]: conn=1439273 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 4 10:19:20 ldap01 slapd[3077]: conn=1439273 op=2 BIND anonymous mech=implicit ssf=0 Aug 4 10:19:20 ldap01 slapd[3077]: conn=1439273 op=2 BIND dn="cn=Klavs Klavsen,ou=People,dc=example,dc=net" method=128 Aug 4 10:19:20 ldap01 slapd[3077]: conn=1439273 op=2 RESULT tag=97 err=49 text= Any idea what makes the client try binding with mech=SIMPLE? or perhaps a hint as to why the first "method=128" doesn't work? I hope you have ideas :) As to what I could find in the documentation method=128 (which they both use first) means SIMPLE-auth - so it "should" be the same they are doing.. obviously not - and "annoyingly" it's run over ldaps - so it's a bit harder to sniff :( Thank you in advance -- Regards, Klavs Klavsen, GSEC - kl(a)vsen.dk - http://www.vsen.dk "Those who do not understand Unix are condemned to reinvent it, poorly." --Henry Spencer

1 0

Re: Unclear attribute: entry
by Jonathan CLARKE 06 Aug '10

06 Aug '10

On 05/08/2010 10:59, Klaus Ethgen wrote: > Hi, > > Dieter Kluenter<dieter(a)dkluenter.de> schrieb: >>> So my question is what is the rights that are needed for which entry >>> attribute (in tree) to allow read, write, search or other access to >>> other attributes? >> entry and children are so called pseudo attributes. They are mainly >> used to allow access to children of an entry. As example you have an >> entry ouers,dcample,dcm and want to allow access to children >> of this entry but no read or write access to the entry itself, a rule >> set could be >> >> access to dn.onelevelers,dcample,dcm >> by users write >> by anonymous auth >> access to dn.baseers,dcample,dcm attrstry,children >> by users write >> by anonymous auth > > Thanks for your answer. But it do not makes that clear for me. I did > found some examples with entry and children but the description about > ist not clear for me. > > The children attribute might be somewhat clear. But the real mysteric is > the entry attribute and as the logic seems to be somewhat identical also > the real meaning of children. > > For example: > [1] access to attrs=sn > by * read > > [2] access to attrs=entry,sn > by * read > > [1] will not allow to read the attribute sn. Only with [2] that will > work. However, _I_ would expect that all attributes of that particular > entry would be readable with [2] but only the sn attribute with [1]. And > exactly there is my problem with the understanding. Indeed. Reading any object requires access to the entry pseudo attribute. All the requirements regarding these two pseudo attributes are documented in the man page, slapd.access(5), under "OPERATION REQUIREMENTS". For example, for searching and reading attributes: > The search operation, requires search (=s) privileges on the entry pseudo-attribute of the searchBase > (NOTE: this was introduced with OpenLDAP 2.4). Then, for each entry, it requires search (=s) privileges on > the attributes that are defined in the filter. The resulting entries are finally tested for read (=r) > privileges on the pseudo-attribute entry (for read access to the entry itself) and for read (=r) access on > each value of each attribute that is requested. Jonathan -- ========================================== Jonathan CLARKE ------------------------------------------ Normation 44 rue Cauchy, 94110 Arcueil, France ------------------------------------------ Telephone: +33 (0)1 83 62 26 96 ------------------------------------------ Web: http://www.normation.com/ ==========================================

1 0

Re: Unclear attribute: entry
by Dieter Kluenter 06 Aug '10

06 Aug '10

Klaus Ethgen <klaus+usenet(a)ethgen.de> writes: > Hi, > > Dieter Kluenter <dieter(a)dkluenter.de> schrieb: >>> So my question is what is the rights that are needed for which entry >>> attribute (in tree) to allow read, write, search or other access to >>> other attributes? >> entry and children are so called pseudo attributes. They are mainly >> used to allow access to children of an entry. As example you have an >> entry ouers,dcample,dcm and want to allow access to children >> of this entry but no read or write access to the entry itself, a rule >> set could be >> >> access to dn.onelevelers,dcample,dcm >> by users write >> by anonymous auth >> access to dn.baseers,dcample,dcm attrstry,children >> by users write >> by anonymous auth > > Thanks for your answer. But it do not makes that clear for me. I did > found some examples with entry and children but the description about > ist not clear for me. > > The children attribute might be somewhat clear. But the real mysteric is > the entry attribute and as the logic seems to be somewhat identical also > the real meaning of children. > > For example: > [1] access to attrs=sn > by * read > > [2] access to attrs=entry,sn > by * read > > [1] will not allow to read the attribute sn. Only with [2] that will > work. However, _I_ would expect that all attributes of that particular > entry would be readable with [2] but only the sn attribute with [1]. And > exactly there is my problem with the understanding. Well, if [1] doesn't allow read access then there are other rules which prevent this. The only function of the pseudo attributes entry and children is to allow the access parser to check whether the referenced object and subentries exist. Just to give an example, the last acl rule of my slapd.conf is access to dn.base="o=avci,c=de" attrs=entry,children by group.exact="cn=Administratoren,o=avci,c=de" write by users read by anonymous auth A search with base o=avci,c=de and scope subtree results in the following acl parsing: => access_allowed: search access to "o=avci,c=de" "entry" requested -Dieter -- Dieter Klünter | Systemberatung sip: 7770535(a)sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6

1 0

Capturing events in OpenLDAP
by Suneet Shah 06 Aug '10

06 Aug '10

Hello, Is there a way to capture events such as creating a new user, changing a users, changing the password, etc in openLDAP in real time? If so, how? Any guidance to docs or examples would be greatly appreciated. If its not possible to capture these as an event, is there an alternative? Thanks in advance

2 1

Client Configuration on Windows
by Wallus, Harald Dr. 06 Aug '10

06 Aug '10

Hi all, I just ty to figure out client certificates for the access to ldap. My problem I can't configure e.g. ldapsearch on windows properly. If I understood it right, I must define and store some directives within a ldap.conf (see an example at the bottom), But what I must do that e.g. ldapsearch will read the configuration? Harald URI ldaps://myldap.mydomain.de BASE OU=myOrg,O=mydomain,C=DE BINDDN CN=me,OU=USERS,OU=myorg,O=mydomain,C=DE TLS_CACERT C:/OpenSSL-Win32/bin/demoCA/cacert.pem TLS_CERT C:/app/H23232/product/11.2.0/client_2/BIN/owm/wallets/H23232/clientcert.pem TLS_KEY C:/app/ H23232/product/11.2.0/client_2/BIN/owm/wallets/H23232/privateKeyOhnePass.pem TLSCipherSuite HIGH:MEDIUM:+SSLv2 #TLS_REQCERT never #TLS_REQCERT allow #TLS_REQCERT try TLS_REQCERT demand

2 2

can't get slapd to do pass-through authentication
by Brent Bice 05 Aug '10

05 Aug '10

I've been trying to get Pass-Through authentication to work using a userPassword attribute of the form {SASL}username@realm. At this point I'm guessing but is there a way to tell slapd what pathspec to use to talk to saslauthd? (I'm guessing maybe it's using one path but saslauthd is using a different one for the socket file) I've got saslauthd running ok and can authenticate using testsaslauthd so I'm fairly sure I'm ok there. And I've got openldap compiled with --enable-spasswd option so it ought to support the SASL pass-through option, right? I ran saslauthd with debugging on so I can see every auth request and whether it succeeds or fails and I can see it when testsaslauth connects and succeeds. But when I try to bind to slapd using the DN whose userPassword is {SASL}bbice@ldap the authentication to slapd fails and saslauthd doesn't show any authentication attempt at all. It's as if it's not even trying (or can't find) saslauthd. I ran slapd with the -d 255 option and saved the output to a file. Here's all the lines containing the string sasl: >>> dnPretty: <cn=SASL> => ldap_bv2dn(cn=SASL,0) <= ldap_bv2dn(cn=SASL)=0 <= ldap_dn2bv(cn=SASL)=0 <<< dnPretty: <cn=SASL> >>> dnNormalize: <cn=SASL> <<< dnNormalize: <cn=sasl> ldap_sasl_bind_s ldap_sasl_bind SASL Canonicalize [conn=1000]: authcid="bbice@ldap" SASL Canonicalize [conn=1000]: authcid="bbice@ldap" SASL Canonicalize [conn=1001]: authcid="bbice@ldap" SASL Canonicalize [conn=1001]: authcid="bbice@ldap" So if I'm reading that right, slapd does see that it's supposed to hand off the authentication to saslauthd and it has picked out the username and realm. But it doesn't seem to be connecting to or using saslauthd. Any ideas? What am I missing here? Brent Bice bbice(a)sgi.com

4 8

Change User Password (passwd vs. ldappasswd)
by weigao88＠gmail.com 05 Aug '10

05 Aug '10

Hi, I have set up and configured openldap 2.3 servers (master-slave) that comes with CentOS 5.4. I use openldap to centralize Linux/Unix user account management. Everything works as expected. However, I am confused about changing user password. Without LDAP, we use file-based authentication (/etc/passwd and /etc/shadow), so users can change their password via "passwd" command. Now I have migrated all my users to LDAP with default password policy, users can still use passwd command to change the password, but LDAP password policy is not enforced, for example, my ldap password policy has a minimum password length requirement of 12, and I am able to change user password to something less than 12 characters. However, if users use "ldappasswd -x -vv -S -W -D uid=user1,ou=People,dc=IT,dc=Company" to change their password, the LDAP password policy will be enforced, ie they will not allow to change to a password less than 12 characters. Are the users supposed to use passwd OR ldappasswd command to change their password? It's very inconvenient for users to use ldappassword command to change password as you can see they have to do much more typing, and some novice users are not even aware of ldappasswd command. I am confused here. Any help would be greatly appreciated. Thanks Wei

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical