openldap-technical

openldap-technical@openldap.org

3 participants
9898 discussions

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

syncrepl proxy problem - consumer gets cleared
by Sebastian Hofmann 03 Nov '10

03 Nov '10

Hello, I have a problem setting up replication with syncrepl proxy (push-based) according to http://www.openldap.org/doc/admin24/replication.html#Syncrepl%20Proxy. I got it working but sometimes the client gets cleared. This happens when consumer is down and some changed occur at the provider. When restarting the consumer, the changes will be replicated and after that the consumer gets cleared from searchbase down. Here is the log of the consumer. I removed dc=max,dc=pamuser,dc=sourcepark,dc=de at the provider while the consumer was down: conn=0 op=311 SRCH base="dc=pamuser,dc=sourcepark,dc=de" scope=2 deref=0 filter="(objectClass=*)" conn=0 op=311 SRCH attr=entryUUID conn=0 op=311 SEARCH RESULT tag=101 err=0 nentries=153 text= conn=0 op=312 DEL dn="dc=max,dc=pamuser,dc=sourcepark,dc=de" conn=0 op=312 RESULT tag=107 err=0 text= conn=0 op=313 DEL dn="dc=pamuser,dc=sourcepark,dc=de" conn=0 op=313 RESULT tag=107 err=66 text=subordinate objects must be deleted first ######################### My provider config: allow bind_v2 allow bind_anon_dn include /home/sebastian/ldap-master/schema/core.schema include /home/sebastian/ldap-master/schema/cosine.schema include /home/sebastian/ldap-master/schema/nis.schema include /home/sebastian/ldap-master/schema/inetorgperson.schema include /home/sebastian/ldap-master/schema/evolutionperson.schema include /home/sebastian/ldap-master/schema/automount.schema include /home/sebastian/ldap-master/schema/openldap.schema include /home/sebastian/ldap-master/schema/misc.schema include /home/sebastian/ldap-master/schema/gum.schema include /home/sebastian/ldap-master/schema/samba.schema include /home/sebastian/ldap-master/schema/sudo.schema pidfile /home/sebastian/ldap-master/run/slapd.pid modulepath /usr/lib/ldap moduleload back_bdb moduleload syncprov.la moduleload back_monitor.la moduleload back_ldap.la backend bdb database bdb suffix "dc=sourcepark,dc=de" checkpoint 512 30 directory "/home/sebastian/ldap-master/data" index objectClass eq lastmod on rootdn "cn=test,dc=sourcepark,dc=de" rootpw test access to attrs=userPassword by dn="cn=test,dc=sourcepark,dc=de" write by anonymous auth by self write by * none access to dn.base="" by * read access to dn.subtree="ou=Contacts,dc=sourcepark,dc=de" by users write by self write by * auth access to * by dn="cn=test,dc=sourcepark,dc=de" write by * read overlay syncprov syncprov-checkpoint 1000 60 database monitor database config rootpw testing database ldap hidden on suffix "dc=sourcepark,dc=de" rootdn "cn=slapd-ldap" uri ldap://localhost:9010/ lastmod on restrict all acl-bind bindmethod=simple binddn="cn=replicator,dc=sourcepark,dc=de" credentials=test syncrepl rid=001 provider=ldap://localhost:9009/ binddn="cn=replicator,dc=sourcepark,dc=de" bindmethod=simple credentials=test searchbase="dc=pamuser,dc=sourcepark,dc=de" scope=sub type=refreshAndPersist retry="5 5 300 5" overlay syncprov #################### My consumer conf: moduleload syncprov allow bind_v2 allow bind_anon_dn include /home/sebastian/ldap-slave/schema/core.schema include /home/sebastian/ldap-slave/schema/cosine.schema include /home/sebastian/ldap-slave/schema/nis.schema include /home/sebastian/ldap-slave/schema/inetorgperson.schema include /home/sebastian/ldap-slave/schema/evolutionperson.schema include /home/sebastian/ldap-slave/schema/automount.schema include /home/sebastian/ldap-slave/schema/openldap.schema include /home/sebastian/ldap-slave/schema/misc.schema include /home/sebastian/ldap-slave/schema/gum.schema include /home/sebastian/ldap-slave/schema/samba.schema include /home/sebastian/ldap-slave/schema/sudo.schema pidfile /home/sebastian/ldap-slave/run/slapd.pid loglevel 16384 modulepath /usr/lib/ldap moduleload back_bdb backend bdb database bdb suffix "dc=sourcepark,dc=de" checkpoint 512 30 directory "/home/sebastian/ldap-slave/data" index objectClass eq lastmod on rootdn "cn=test,dc=sourcepark,dc=de" rootpw test access to attrs=userPassword by dn="cn=test,dc=sourcepark,dc=de" write by anonymous auth by self write by * none access to * by dn="cn=replicator,dc=sourcepark,dc=de" write by dn="cn=test,dc=suretecsystems,dc=com" write by * break access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write by * read limits dn.exact="cn=replicator,dc=sourcepark,dc=de" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited updatedn "cn=replicator,dc=sourcepark,dc=de" updateref ldap://localhost:9009 ###################### Any help would be greatly appreciated. Thanks Sebastian

2 3

ACL and SSF
by Christian Bösch 03 Nov '10

03 Nov '10

Hi, I forced encryption with olcSecurity but some of our applications do not support ldaps etc. Now I disabled globally the security and wanted to do it with ACLs to force all clients with encryption except for the ip addresses from those application servers. For this I thought it would work to add the first ACL line like this: {0}to * by ssf=256 auth by peername.ip=172.16.122.210 auth {1}.... {2}... .... But this doesn't seem to work.... Can somebody tell me if there is an error in reasoning or how to solve this approach? /thx,chris

1 0

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

03 Nov '10

thanks for the input guys.. I have to admit at this point, setting this up under FreeBSD was a breeze compared to what is going on now. I have made 3 attempts at this today.. twice on CentOS 5.4 and once on Ubuntu 10 Server. Given the differences in platform with identical outcomes I am thinking that it _has_ to be something with my slapd.conf file. I am still getting error 49s even if I use the actual word secret as the pass. Nov 2 19:02:00 ldap2 slapd[15768]: conn=0 fd=11 ACCEPT from IP=127.0.0.1:44448 (IP=0.0.0.0:389) Nov 2 19:02:00 ldap2 slapd[15768]: conn=0 op=0 BIND dn="cn=Manager,dc=acadaca,dc=net" method=128 Nov 2 19:02:00 ldap2 slapd[15768]: conn=0 op=0 RESULT tag=97 err=49 text= Nov 2 19:02:00 ldap2 slapd[15768]: conn=0 fd=11 closed (connection lost) And this is how my ldap.conf is setup BASE dc=acadaca,dc=net HOST localhost I would appreciate it greatly if someone could please give it a look. Thank you On Tue, Nov 2, 2010 at 6:35 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, November 02, 2010 11:07 PM +0100 Benjamin Griese > <der.darude(a)gmail.com> wrote: > >> Hello Tim, >> >> the "password" you supply won't work, as it is not encoded in base64. >> >> Try to generate a password hash + base64-enc with "slappasswd" and set >> this string as your password hash for rootpw. >> http://linux.die.net/man/8/slappasswd > > Benjamin, > > There is no requirement that the password value for the rootpw entry in > slapd.conf be SSHA hashed or Base 64 encoded. > > I.e., > > rootpw secret > > is perfectly valid. > > Also, an LDIF file with > > userPassword: secret > > is also perfectly valid, as either slapadd or slapd (via ldapadd) will take > care of encoding it to Base64. > > --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!!

1 0

system schema changes
by Engel, Jay A 02 Nov '10

02 Nov '10

I want to change an attribute type in system schema (e.g., CN / Equality = caseExactMatch). Is this possible? Does it require source code modification? Jay

2 1

Issue with OpenLDAP shared libraries complie on AIX 6.1 using IBM xL Compiler
by Peter Lambrechtsen 02 Nov '10

02 Nov '10

Hello I'm having an issue when using the IBM xL Compiler (not GNU GCC or any other part of the GNU stack) and the configure script fails to detect that ld can link shared libaries. The configure I am using is: ./configure --prefix=/opt/openldap --disable-slapd --disable-man --disable-client --enable-shared --with-tls --with-cyrus-sasl A snipit from the below configure show's that the configure script fails to detect that ld can compile shared libraries. checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking the maximum length of command line arguments... 131072 checking command to parse /usr/ccs/bin/nm -B output from cc_r -qlanglvl=extc89 object... ok checking for objdir... .libs checking for ranlib... ranlib checking for strip... strip checking if cc_r -qlanglvl=extc89 static flag works... yes checking for cc_r -qlanglvl=extc89 option to produce PIC... checking if cc_r -qlanglvl=extc89 supports -c -o file.o... yes checking whether the cc_r -qlanglvl=extc89 linker (/usr/ccs/bin/ld) supports shared libraries... no checking dynamic linker characteristics... no checking how to hardcode library paths into programs... unsupported checking whether stripping libraries is possible... no checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... no checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes configure: creating libtool checking how to run the C preprocessor... cc_r -qlanglvl=extc89 -E checking whether we are using MS Visual C++... no checking for be_app in -lbe... no checking whether we are using the GNU C compiler... (cached) no Any idea why this is happening??? checking whether the cc_r -qlanglvl=extc89 linker (/usr/ccs/bin/ld) supports shared libraries... no Or assistance on how I could modify the configure script to work. Cheers Peter

2 1

OpenLDAP works slower on a server with LDAP-based authentication
by Konstantin Boyandin 02 Nov '10

02 Nov '10

Hello, I have two servers used in Samba domain setup. Both computers are running CentOS 5.5 x86_64, all updates installed, both are using the openldap-servers-2.3.43-12 and other requried packaged of the same version (2.3.43-12). All the required ports are open. Master OpenLDAP server uses LDAP authentication, slave doesn't (Un*x authentcation). Slave syncs with the master (syncrepl) every several minutes. All the config files of both are the same, including DB_CONFIG. All recommended records are indexed. The only difference is the replciation section in /etc/opeldap/slapd.conf on slave. When I run ldapsearch against slave (Un*x authentication), it responds almost immediately. When I run ldapsearch against master (LDAP authentication), it takes 2 to 10 seconds to receive data. I would appreciate any hint on where to look for the reason of slow response on master server. Thank you! Sincerely, Konstantin

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical