openldap-technical November 2010

openldap-technical@openldap.org

86 participants
113 discussions

Re: unable to perform authenticated binds
by Tim Dunphy 04 Nov '10

04 Nov '10

hi quannah, well from the includes in slapd.conf it certainly would appear to have been installed include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/misc.schema inlcude /etc/openldap/schema/sudoers.schema include /etc/openldap/schema/openldap.schema however when I do a search for sudoRole it doesn't seem to show up [root@ldap openldap]# ldapsearch -b '' -s base '(objectclass=*)' sudoRole -x -W -D "cn=Manager,dc=acadaca,dc=net" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: sudoRole # # dn: # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 On Thu, Nov 4, 2010 at 5:41 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Are you certain the schema for sudoRole has really been added? Have you > browsed the subschema entry while the server is running to verify it is > present? > > --Quanah > > --On Thursday, November 04, 2010 5:25 PM -0400 Tim Dunphy > <bluethundr(a)gmail.com> wrote: > >> My bad Quannah in sending to your direct email .. and my apologies >> >> >> Well it seems that I am running version 2.3 on the CentOS box and >> version 2.4 on the FreeBSD box.. >> >> >> Here's the class definition for sudoRole >> >> objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL >> DESC 'Sudoer Entries' >> MUST ( cn ) >> MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ >> sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ >> description ) >> ) >> >> >> could it be just that the older version is running under CentOS? any >> advice on how to get sudoRole working under openldap 2.3? > > Are you certain the schema for sudoRole has really been added? Have you > browsed the subschema entry while the server is running to verify it is > present? > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

2 1

Re: unable to perform authenticated binds
by Tim Dunphy 04 Nov '10

04 Nov '10

My bad Quannah in sending to your direct email .. and my apologies Well it seems that I am running version 2.3 on the CentOS box and version 2.4 on the FreeBSD box.. Here's the class definition for sudoRole objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL DESC 'Sudoer Entries' MUST ( cn ) MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ description ) ) could it be just that the older version is running under CentOS? any advice on how to get sudoRole working under openldap 2.3? thanks On Thu, Nov 4, 2010 at 5:11 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, November 04, 2010 5:04 PM -0400 Tim Dunphy > <bluethundr(a)gmail.com> wrote: > >> hmm... so basically it's a syntax error in the LDIF? interesting.. >> that is the exact same entry I have under my working FreeBSD >> configuration... > > Keep your questions to the list please. My guess is that the FreeBSD > configuration is using an older version of OpenLDAP with schema checking > disabled? Since I don't know what the definition of that objectClass is, as > you haven't supplied it, I can't really say why that error is being > generated. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

2 1

Re: unable to perform authenticated binds
by Quanah Gibson-Mount 04 Nov '10

04 Nov '10

--On Thursday, November 04, 2010 5:04 PM -0400 Tim Dunphy <bluethundr(a)gmail.com> wrote: > hmm... so basically it's a syntax error in the LDIF? interesting.. > that is the exact same entry I have under my working FreeBSD > configuration... Keep your questions to the list please. My guess is that the FreeBSD configuration is using an older version of OpenLDAP with schema checking disabled? Since I don't know what the definition of that objectClass is, as you haven't supplied it, I can't really say why that error is being generated. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: unable to perform authenticated binds
by Tim Dunphy 04 Nov '10

04 Nov '10

sorry for the oversight Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 busy Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: listen=7, new connection on 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: added 12r (active) listener=(nil) Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 fd=12 ACCEPT from IP=10.203.49.140:51779 (IP=0.0.0.0:389) Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: 12r Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 BIND dn="cn=Manager,dc=acadaca,dc=net" method=128 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 BIND dn="cn=Manager,dc=acadaca,dc=net" mech=SIMPLE ssf=0 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 RESULT tag=97 err=0 text= Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: 12r Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=1 ADD dn="cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net" Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=1 RESULT tag=105 err=21 text=objectClass: value #1 invalid per syntax Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: 12r Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=2 UNBIND Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: removing 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 fd=12 closed Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL On Thu, Nov 4, 2010 at 3:49 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, November 04, 2010 3:37 PM -0400 Tim Dunphy > <bluethundr(a)gmail.com> wrote: > >> Thanks all.. I have read the man of ldif.... your advice has gotten me >> quite far both in my current implementation and in my overall >> understanding of LDAP which I am hoping grows with each passing day. >> >> In my attempt to build my current directory, I have taken a dump of >> my last successful implementation (which was created on FreeBSD 8.1) >> and substituted values for the dc=company and dc=com values with the >> correct ones for the current directory (attempting to implement under >> CentOS 5.4) and even tho the correct schemas are in place it is >> choking on this entry: >> >> # defaults, sudoers, Services, acadaca.com >> dn: cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net >> objectClass: top >> objectClass: sudoRole >> cn: defaults >> description: Default sudoOption's go here > > Since you fail to provide the error message you encountered, I see no way to > help you. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

2 1

Re: unable to perform authenticated binds
by Tim Dunphy 04 Nov '10

04 Nov '10

sorry for the frustration all... removing the leading space in front of rootpw did the trick :) the directory is now populating, however I cannot understand why it is choking on this entry # pam_ldap, Services, acadaca.net dn: cn=pam_ldap,ou=Services,dc=acadaca,dc=net cn: pam_ldap objectClass: top objectClass: inetOrgPerson sn: PAM userPassword:: {SSHA}secret AFAIK I have ALL the scemas I need to import this entry yet ldapadd chokes [root@ldap openldap]# ldapadd -h ldap -x -D "cn=Manager,dc=acadaca,dc=net" -w secret -f /home/tim/acadaca2.ldif ldapadd: invalid format (line 6) entry: "cn=pam_ldap,ou=Services,dc=acadaca,dc=net" include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/misc.schema inlcude /etc/openldap/schema/sudoers.schema I am sorry to ask for help again.. this sucks On Wed, Nov 3, 2010 at 12:20 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, November 02, 2010 7:59 PM -0700 Chris Jacobs > <Chris.Jacobs(a)apollogrp.edu> wrote: > >> If you're not calling me out via "thanks so much for the exceedingly >> useful insight" then feel free to skip the rest of this. > > I didn't think he was calling you out, myself. ;) Just noting that things > are documented, and people who don't take the time to read the official > project documentation (which happens a lot, unfortunately) don't deserve > sympathy on it. We get a lot of people who spend their time reading > documents from other sources such as Zytrax, which contain completely wrong > information, and then come here to talk about how bad the documentation is. > It gets frustrating. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

4 6

pwdChangedTime: and system timestamp
by Michael Starling 04 Nov '10

04 Nov '10

When looking at the value of pwdChangedTime on my openldap system everything seems to be correct except for the hours/minutes/seconds fields. If I have a value of pwdChangedTime: 20101104165037Z in LDAP The date command shows Thu Nov 4 13:04:30 EDT 2010 How are these the same or relatively close? -Mike

2 2

Re: Error 18: Solaris 10 Native LDAP-Client
by Benjamin Griese 04 Nov '10

04 Nov '10

Correction: -w <passwd> or -w - instead of -W On Thu, Oct 28, 2010 at 15:02, Benjamin Griese <der.darude(a)gmail.com> wrote: > Hello Günther, > > sorry for my late reply, I hate sun cluster panics after patching > those beasts. :( > > Here is the content of solaris_profile: > > dn: cn=solaris_profile,ou=profile,dc=example,dc=de > objectClass: DUAConfigProfile > objectClass: top > cn: solaris_profile > authenticationMethod: simple > bindTimeLimit: 10 > credentialLevel: proxy > defaultSearchBase: dc=example,dc=de > defaultSearchScope: sub > defaultServerList: exampleldap01 exampleldap02 (syncrepl, configured > to mirrormode) > followReferrals: FALSE > profileTTL: 3600 > searchTimeLimit: 30 > serviceSearchDescriptor: sudoers:ou=SUDOers,dc=example,dc=de?sub > serviceSearchDescriptor: group:ou=groups,dc=example,dc=de?sub > serviceSearchDescriptor: passwd:ou=people,dc=example,dc=de?sub > > > Regarding to the sorting I found this in man ldapsearch: > > "-F sep > > Use sep as the field separator between attribute names > and values. If this option has been specified, the -L > option is ignored. > > > -S [-]attribute > > Specify an attribute for sorting the entries returned by > the search. The sort criteria is alphabetical on the > attribute's value or reverse alphabetical with the form > -attribute. You can give multiple -S options to refine > the sorting, For example: > > -S sn -S givenname > > By default, the entries are not sorted. Use the -x > option to perform server-side sorting." > > If I use -x for server side sorting, I get the complete list of > uid-Objects, but not sorted in any obvious way: > # ldapsearch -v -x -b dc=example,dc=de -h exampleldap01 -D > cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)' > > ldapsearch: started Thu Oct 28 12:16:49 2010 > ldap_init( exampleldap01, 389 ) > filter pattern: (uid=*) > returning: ALL > filter is: (uid=*) > version: 1 > > If I use this string I get the complete list of uid-objects sorted by uidNumber > # ldapsearch -v -S uidnumber -b dc=example,dc=de -h exampleldap01 -D > cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)' > > ldapsearch: started Thu Oct 28 12:37:11 2010 > ldap_init( exampleldap01, 389 ) > filter pattern: (uid=*) > returning: ALL > filter is: (uid=*) > version: 1 > > If I try to search with -x and -S uidnumber I get the same message > that appears in the OpenLDAP logfile: > # ldapsearch -v -x -S uidNumber -b dc=example,dc=de -h exampleldap01 > -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)' > > ldapsearch: started Thu Oct 28 12:25:50 2010 > ldap_init( exampleldap01, 389 ) > filter pattern: (uid=*) > returning: ALL > filter is: (uid=*) > ldap_search: Inappropriate matching > ldap_search: additional info: serverSort control: No ordering rule > ldap_parse_sort_control: Requested LDAP control not found > > Finally I still have no clue how to prevent the client from doing > these kinds of searches. > And I couldn't find any templates regarding the ldapclient on my test machine. > > Any other clues or ideas? > > Bye, Benjamin. > > On Sat, Oct 23, 2010 at 19:17, Dieter Kluenter <dieter(a)dkluenter.de> wrote: >> Benjamin Griese <der.darude(a)gmail.com> writes: >> >>> Hey thanks for quick reply, >>> >>> I put the config of the ldapclient on the ML some days ago, >>> but I can't figure out how I may have set such a rule on client side. >>> Probably it is something hardcoded. >>> >>> ldapclient config: >>> NS_LDAP_FILE_VERSION= 2.0 >>> NS_LDAP_BINDDN= cn=proxyuser,ou=system,ou=people,dc=example,dc=de >>> NS_LDAP_BINDPASSWD= secret >>> NS_LDAP_SERVERS= ldap01 >>> NS_LDAP_SEARCH_BASEDN= dc=example,dc=de >>> NS_LDAP_AUTH= simple >>> NS_LDAP_SEARCH_REF= FALSE >>> NS_LDAP_SEARCH_SCOPE= sub >>> NS_LDAP_SEARCH_TIME= 30 >>> NS_LDAP_CACHETTL= 60 >>> NS_LDAP_PROFILE= solaris_profile >>> NS_LDAP_CREDENTIAL_LEVEL= proxy >>> NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=people,dc=example,dc=de?sub >>> NS_LDAP_SERVICE_SEARCH_DESC= group: ou=groups,dc=example,dc=de?sub >>> NS_LDAP_SERVICE_SEARCH_DESC= sudoers: ou=SUDOers,dc=example,dc=de?sub >>> >>> That's all I setup, its like defaultest of the defaultest I guess :) >>> >>> And thanks for describing EQUALITY. >> >> I must admit I am not that familiar with old netscape tools, but the >> openldap log ist quite clear, there is a request for a Server Side >> Sorting extended operation, which in fact is quite unusual. You really >> should check Solaris 10 setup for appropriate templates, i.e. what is >> the content of solaris_profile? By the way, AFAIR the flag for sss is >> -F so you may check any templates, Redhat provides these in >> /usr/share/dirsrv, Solaris might be different. >> >> -Dieter >> >> -- >> Dieter Klünter | Systemberatung >> sip: 7770535(a)sipgate.de >> http://www.dpunkt.de/buecher/2104.html >> GPG Key ID:8EF7B6C6 >> > > > > -- > To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To > be is to do -- Sartre | Do be do be do -- Sinatra > -- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra

4 11

unable to perform authenticated binds
by Tim Dunphy 03 Nov '10

03 Nov '10

I am attempting to setup an LDAP server under CentOS 5.4. However I am unable to search my ldap directory even tho I am supplying the proper credentials for the Manager account: [root@ldap openldap]# ldapsearch -x -h ldap -D 'cn=Manager,dc=example,dc=net' -W -b 'dc=example,dc=net' Enter LDAP Password: ldap_bind: Invalid credentials (49) Anonymous searches do work however: ldapsearch -x -h ldap -b "dc=example,dc=net" -s sub "objectclass=*" [root@ldap openldap]# ldapsearch -x -h ldap -b "dc=example,dc=net" -s sub "objectclass=*" # extended LDIF # # LDAPv3 # base <dc=example,dc=net> with scope subtree # filter: objectclass=* # requesting: ALL # # search result search: 2 result: 32 No such object I am currently attempting to use the actual word 'secret' to authenticate the Manager account: database bdb suffix "dc=example,dc=net" rootdn "cn=Manager,dc=example,dc=net" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # rootpw {CRYPT}secret And yet I am still getting error 49's in my openldap logs with loglevel set to 296 /var/log/openldap.log Nov 2 15:45:58 ldap slapd[3522]: slapd starting Nov 2 15:46:14 ldap slapd[3522]: conn=0 fd=11 ACCEPT from IP=127.0.0.1:44552 (IP=0.0.0.0:389) Nov 2 15:46:14 ldap slapd[3522]: conn=0 op=0 BIND dn="cn=Manager,dc=example,dc=net" method=128 Nov 2 15:46:14 ldap slapd[3522]: conn=0 op=0 RESULT tag=97 err=49 text= Nov 2 15:46:14 ldap slapd[3522]: conn=0 fd=11 closed (connection lost) this is how I have configured my ldap.conf BASE dc=example,dc=net HOST localhost URI ldap://ldap.example.net thanks in advance for your help -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

5 8

{SOLVED] Error 18: Solaris 10 Native LDAP-Client
by Benjamin Griese 03 Nov '10

03 Nov '10

Hello Ralf, thank you very much for your help! :) In the first place it didn't work and I was sure you have tested the functionality, so I checked what I may have configured differently/wrong. So I checked my list of supportedControls which are presented to the clients: ldapsearch -x -b "" -s base supportedControl before: supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 This shows the list of supportedControls and the denied Controls were still visible. To make it work I had to put olcAccess: {1}to dn.base="" by * read further down to olcAccess: {3}to dn.base="" by * read below the two denied Controls. after: supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 After that the supportedControls weren't visible anymore when requesting the list. Finally, my working frontend: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="cn=subschema" by * read olcAccess: {1} to dn.base="" attrs=supportedControl val/objectIdentifierMatc h=1.2.840.113556.1.4.473 by * none olcAccess: {2} to dn.base="" attrs=supportedControl val/objectIdentifierMatc h=2.16.840.1.113730.3.4.9 by * none olcAccess: {3}to dn.base="" by * read olcAccess: {4}to attrs=userPassword,userPKCS12 by self write by * auth olcAccess: {5}to attrs=shadowLastChange by self write by * read olcAccess: {6}to * by * read olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcMonitoring: FALSE olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE Now requesting passwd/group/sudoers/etc with the Solaris 10 native client works like a charm, to me its like "less is more". :) Thanks to all of you who tried to help and fix the problem, especially Ralf and Dieter. Have a nice day, Benjamin. On Wed, Nov 3, 2010 at 12:07, Ralf Haferkamp <rhafer(a)suse.de> wrote: > Am Mittwoch 03 November 2010, 09:52:26 schrieb Benjamin Griese: >> Hello Ralf, >> > [..] >> In the meantime I set the ACL, but unfortunatly it didn't help solving >> the problem, you may take a look at my example: >> >> DN: olcDatabase={1}hdb,cn=config >> olcAccess: {0}to attrs=userPassword,shadowLastChange by >> dn="cn=ldapadm,dc=example,dc=de" write by >> dn="cn=proxyuser,ou=system,ou=people,dc=example,dc=de" read by >> anonymous auth by self write by * none >> olcAccess: {1} to dn.base="" attrs=supportedControl >> val/objectIdentifierMatch=1.2.840.113556.1.4.473 by * none >> olcAccess: {2} to dn.base="" attrs=supportedControl >> val/objectIdentifierMatch=2.16.840.1.113730.3.4.9 by * none >> olcAccess: {3}to dn.base="" by * read >> olcAccess: {4}to * by dn="cn=ldapadm,dc=example,dc=de" write by * read >> >> If I remember right {4} is not opening up the access when it is >> explicitly denied in the ACLs {1} & {2}, am I right? > Yes, you are right. > >> But I'm not sure if this is the right place for this kind of ACL, >> cn=config instead should be wrong too I guess. > It has to be in the global ACL, i.e. you have to add it to > olcDatabase={-1}frontend,cn=config. > >> Bye, Benjamin. > [..] > > Ralf > -- > SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) > -- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra

1 0

ACL permission issue
by Eduardo Santos 03 Nov '10

03 Nov '10

Hi everyone, I'm facing an ACL problem for a long time, and I got to the point that I'm out of ideas. The problem is related to write in a specific branch of DIT. My DIT has the following hierachy dc=spi,dc=net -> c=cl -->ou=users --->ou=regular --->ou=admin The ACL should allow the users under the admin subtree to write in the regular subtree (admin and regular users model). SO, I have the following ACL includes in slapd.conf: include /etc/ldap/acls/acl.conf.default include /etc/ldap/acls/acl.conf The ACL files have the following lines: # /etc/ldap/acls/acl.conf.default # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=spi,dc=net" write by anonymous auth by self write by * none # Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. access to dn.base="" by * read # The admin dn has full write access, everyone else # can read everything. access to * by dn="cn=admin,dc=spi,dc=net" write by * read # /etc/ldap/acls/acl.conf access to dn.children="ou=regular,ou=users,c=cl,dc=spi,dc=net" attrs="children" by dn.sub="ou=admins,ou=users,c=cl,dc=spi,dc=net" manage by * read So, I created an user under the admin subtree with the following DN: uid=cl-admin,ou=admins,ou=users,c=cl,dc=spi,dc=net To test, I'm trying to add an user with the following LDIF file: # Teste description: Test dn: uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: spi # Customized class cn: Teste sn: teste givenName: Teste uid: teste url: http://mysite.com mail: test(a)mysite.com l: City TimeZone: GMT-4 area: Gov st: State organization: Organization o: SPI preferredLanguage: en-US However, when I try to add the user (ldapadd -x -D "uid=cl-admin,ou=admins,ou=usuarios,c=cl,dc=spi,dc=net" -W -f /tmp/test.ldif I get the following error: ldap_add: Insufficient access (50) additional info: no write access to parent The debug output log for ACL's show me the following sequence of information: Nov 3 12:00:47 nodo108 slapd[16629]: hdb_referrals: tag=104 target="uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net" matched="ou=regular,ou=users,c=cl,dc=spi,dc=net" Nov 3 12:00:47 nodo108 slapd[16629]: ==> hdb_add: uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_required entry (uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net), objectClass "spi" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "objectClass" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "cn" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "sn" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "givenName" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "uid" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "url" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "mail" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "l" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "timeZone" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "area" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "st" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "organization" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "o" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "preferredLanguage" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "structuralObjectClass" Nov 3 12:00:47 nodo108 slapd[16629]: slap_queue_csn: queing 0xb6603a32 20101103140047.629760Z#000000#000#000000 Nov 3 12:00:47 nodo108 slapd[16629]: bdb_dn2entry("uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net") Nov 3 12:00:47 nodo108 slapd[16629]: => hdb_dn2id("uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net") Nov 3 12:00:47 nodo108 slapd[16629]: <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30990) Nov 3 12:00:47 nodo108 slapd[16629]: => access_allowed: add access to "ou=regular,ou=users,c=cl,dc=spi,dc=net" "children" requested Nov 3 12:00:47 nodo108 slapd[16629]: => dn: [1] ou=regular,ou=users,c=cl,dc=spi,dc=net Nov 3 12:00:47 nodo108 slapd[16629]: => dn: [3] Nov 3 12:00:47 nodo108 slapd[16629]: => acl_get: [4] attr children Nov 3 12:00:47 nodo108 slapd[16629]: => acl_mask: access to entry "ou=regular,ou=users,c=cl,dc=spi,dc=net", attr "children" requested Nov 3 12:00:47 nodo108 slapd[16629]: => acl_mask: to all values by "uid=cl-admin,ou=admins,ou=users,c=cl,dc=spi,dc=net", (=0) Nov 3 12:00:47 nodo108 slapd[16629]: <= check a_dn_pat: cn=admin,dc=spi,dc=net Nov 3 12:00:47 nodo108 slapd[16629]: <= check a_dn_pat: * Nov 3 12:00:47 nodo108 slapd[16629]: <= acl_mask: [2] applying read(=rscxd) (stop) Nov 3 12:00:47 nodo108 slapd[16629]: <= acl_mask: [2] mask: read(=rscxd) Nov 3 12:00:47 nodo108 slapd[16629]: => slap_access_allowed: add access denied by read(=rscxd) Nov 3 12:00:47 nodo108 slapd[16629]: => access_allowed: no more rules Nov 3 12:00:47 nodo108 slapd[16629]: hdb_add: no write access to parent Nov 3 12:00:47 nodo108 slapd[16629]: send_ldap_result: conn=26 op=1 p=3 Nov 3 12:00:47 nodo108 slapd[16629]: send_ldap_result: err=50 matched="" text="no write access to parent" Nov 3 12:00:47 nodo108 slapd[16629]: send_ldap_response: msgid=2 tag=105 err=50 Nov 3 12:00:47 nodo108 slapd[16629]: conn=26 op=1 RESULT tag=105 err=50 text=no write access to parent I tried a lot of different solutions, but nothing seels to work. Anybody have a clue about how to fix it? -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical November 2010