openldap-software October 2007

openldap-software@openldap.org

84 participants
107 discussions

Fwd: setting up admin password on openldap
by Naufal Sheikh 30 Oct '07

30 Oct '07

---------- Forwarded message ---------- From: Naufal Sheikh <naufalzamir(a)gmail.com> Date: Oct 30, 2007 1:16 PM Subject: Re: setting up admin password on openldap To: Michael Ströder <michael(a)stroeder.com> please find the embedded answers. On 10/30/07, Michael Ströder <michael(a)stroeder.com> wrote: > > Naufal Sheikh wrote: > > > > I compiled and installed openldap version 2.2.20 > > Why the hell are you using such an ancient version? > > If you're already building yourself why didn't you use recent stable > version 2.3.3x? I have already had a discussion on this. My boss does not allow me to change versions, and I cannot help it! > The only catch being that I was never asked to > > supply any password during the installation, > > It does not work like that. Ok I thought So as well. > which some of the posts in the mailing list suggested. > > I doubt that anyone here claimed that 'make install' asks for a password. > I have a running version of 2.2.20 on Solaris 8.0. > > So watch out for rootdn and rootpw in the file slapd.conf. rootpw line is hashed on the production system and I am using the same rootDN on my linux server as it is on my production. > I first copied all of the slapd.conf from solaris server file to my red > > hat server, but the slapd gave errors and was not able to start > initially. > > If you don't provide the exact error message noone will be able to help. AS I said I have been able to resolve that already and that is no more a problem. > I then used slapcat on my production system to generate an ldif which I > > imported on red hat server using slapadd. I had few errors about the > > syntax of "clientOrg" attribute being not correct, but those entries > > contained the extended character set in their values and I deleted them > > from the ldif file till I was able to import all the ldif from the > > production system to red hat server. > > Do you really know what you're doing? I bet "clientOrg" is a custom > schema. Who defined that? Isn't the data therein important for you? there was a custom schema on the production system, and I did inlcuded it in my new installation as well. Umm yeah I am not really sure till now how openldap works and I am more of trying to replicate what I have on my old server. > Now as Piotr suggested that > > after creating a password I can hash the rootpw line again, so that the > > authentication can be done using only the passwords in the database. So > > using slappasswd i generated a hash value of the password and copied it > > into the slapd.conf. While slapd starts fine it still cannot connect to > > ldap using the supplied credentials saying invalid credentials. > > Does your LDIF contain an entry with attribute "userPassword" for the > "rootdn" in slapd.conf? Maybe try changing rootdn in slapd.conf to > something else and try with that one. The ldiff I have genrated using slapcat on my new server in order to keep it as backup has the hashed entry of password in the entry of the administrator. ldap browser has the plain text password in the uid of the administrator. Here is my slapd.conf from my new server : # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /main/soft/openldap/TRAC/tracweb//etc/openldap/schema/core.schem a include /main/soft/openldap/TRAC/tracweb//etc/openldap/schema/cosine.schema include /main/soft/openldap/TRAC/tracweb//etc/openldap/schema/inetorgperson.sche ma include /main/soft/openldap/TRAC/tracweb/etc/openldap/schema/trac.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 /main/soft/openldap/TRAC/tracweb//var/run/slapd.pid argsfile /main/soft/openldap/TRAC/tracweb//var/run/slapd.args # Load dynamic backend modules: # modulepath /main/soft/openldap/TRAC/tracweb//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.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # 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") # #access to * \ # by peername.regex="IP=128\.230\.156\." read stop # by * none stop # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### allow bind_v2 backend bdb database monitor database bdb suffix "o=trac" rootdn "cn=nsadmin,o=trac" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw test # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /main/soft/openldap/TRAC/tracweb//var/openldap-data # Performance cachesize 1000 #dbnosync #threads 1 #dbnosync #threads 16 #timelimit 3600 #sizelimit 9999 sizelimit unlimited mode 600 #dbcachesize 10000000 # Indices to maintain index uid eq index cn pres,eq,sub index sn pres,eq,sub index mail eq index default sub index objectClass eq #index uniqueMember eq #index affiliation eq #index mailPreferenceOption eq #index keyWords eq index telephoneNumber pres,eq,sub #index cn,sn,mail pres,eq,approx,sub database bdb suffix "" rootdn "cn=nsadmin" directory /main/soft/openldap/TRAC/tracweb//var/openldap-data2 index uid eq index cn pres,eq,sub index sn pres,eq,sub index mail eq index default sub index objectClass eq The only custom schema I have which I copied from my old server and inlcuded is trac.schema as following: # TRAC's Extended Schema objectIdentifier TracOID 1.3.6.1.4.1.25088 objectIdentifier TracSNMP TracOID:1 objectIdentifier TracLDAP TracOID:2 objectIdentifier TracAttributeType TracLDAP:1 objectIdentifier TracObjectClass TracLDAP:2 attributetype ( TracAttributeType:1 NAME 'contactinfo' DESC 'Information about the contact' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributetype ( TracAttributeType:2 NAME 'regsite' DESC 'Registered site' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributetype ( TracAttributeType:3 NAME 'tracfedquota' DESC 'Quota tracfed' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:4 NAME 'clientorg' DESC 'Client organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributetype ( TracAttributeType:5 NAME 'clearpassword' DESC 'Clear text password' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:6 NAME 'regdate' DESC 'Date of registration' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:7 NAME 'keyWords' DESC 'keywords' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:8 NAME 'affiliation' DESC 'Affiliation' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributetype ( TracAttributeType:9 NAME 'billpostaladdress' DESC 'Bill postal address' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:10 NAME 'billpostalcode' DESC 'Billing postal code' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:11 NAME 'middlename' DESC 'Middle name' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:12 NAME 'regip' DESC 'IP address during registration' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:13 NAME 'siteip' DESC 'IP address of the site' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:14 NAME 'sitemaxlocker' DESC 'Maximum number of locker data per site' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:15 NAME 'sitemaxusers' DESC 'Maximum number of users at the site' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:16 NAME 'siteuid' DESC 'Site User ID' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributetype ( TracAttributeType:17 NAME 'maxqueries' DESC 'Maximum number of queries' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:18 NAME 'userflags' DESC 'Maximum number of queries' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:19 NAME 'termsagree' DESC 'Maximum number of queries' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:20 NAME 'morequeries' DESC 'Maximum number of queries' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:21 NAME 'overusemethod' DESC 'Overuse handling method' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:22 NAME 'queryfee' DESC 'Query fee' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:23 NAME 'licenddate' DESC 'Date of license end' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:24 NAME 'licstartdate' DESC 'Date of start of license' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:25 NAME 'subscribedate' DESC 'Date of subscription' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) #attributetype ( TracAttributeType:9 NAME 'mailpreferenceoption' # DESC 'Mail preference option' # SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} # ) attributetype ( TracAttributeType:26 NAME 'lastModifiedBy' DESC 'The user who last modified the entry' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) attributetype ( TracAttributeType:27 NAME 'lastModifiedTime' DESC 'The time the entry was last modified' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32768} ) objectclass ( TracObjectClass:1 NAME 'tracperson' DESC 'RFC2256: a person' SUP inetOrgPerson STRUCTURAL MUST ( sn $ cn ) MAY ( contactinfo $ regsite $ tracfedquota $ clientorg $ clearpassword $ regdate $ keyWords $ affiliation $ mailPreferenceOption $ billpostaladdress $ billpostalcode $ middlename $ regip $ siteip $ sitemaxlocker $ sitemaxusers $ siteuid $ maxqueries $ userflags $ termsagree $ morequeries $ overusemethod $ queryfee $ licenddate $ licstartdate $ subscribedate $ lastModifiedBy $ lastModifiedTime )) ldif entry for cn=nsadmin is as following: dn: uid=nsadmin,o=trac objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: SuiteSpot Administrator sn: Administrator givenName: SuiteSpot uid: nsadmin creatorsName: cn=nsadmin createTimestamp: 19980218204619Z userPassword:: e1NIQX12bm4rOFpBNFNzdzJJMnlQOVZ2clBJVFlGRzg9 modifiersName: uid=nsadmin,o=trac modifyTimestamp: 19980722182149Z structuralObjectClass: inetOrgPerson entryUUID: 8179b9a2-74d7-102a-9988-90f8caf384a9 entryCSN: 20060511011623Z#000003#00#000000 I am not sure where the problem is, everything is in order but I cannot connect using the credentials. I will try your suggestion about changing the rootdn and will let you know. Ciao, Michael. >

2 2

problem with access by set and group membership (posixgroup, groupofnames)
by "Dr. Hansjörg Maurer" 30 Oct '07

30 Oct '07

Hi I am trying to garnt users access to a group by there group membership. Because the groups are posixgroups and not groupofnames I have tried the following ACL's according to (running openldap-2.3.27-5) http://www.openldap.org/faq/data/cache/1133.html and http://www.mail-archive.com/openldap-software@openldap.org/msg08524.html access to dn.sub="cn=Domain Admins,ou=Groups,dc=byn,dc=drv" by set="([uid=] + ([cn=domain admins,ou=groups,dc=byn,dc=drv])/memberUid + [,ou=users,dc=byn,dc=drv]) & user" write by * none or by set="user/uid & [cn=Domain Admins,ou=Groups,dc=byn,dc=drv]/memberUid" write The group has the folowing members dn: cn=Domain Admins,ou=Groups,dc=byn,dc=drv memberUid: NetAdmin1 memberUid: Netadmin5 memberUid: NT_IEXPLORE memberUid: Siadmin memberUid: Netadmin3 memberUid: NT_FSecure but a search as uid=Netadmin3,ou=Users,dc=byn,dc=drv does not succeedd Here the logs Oct 26 12:41:11 master slapd[18574]: => access_allowed: search access to "cn=Domain Admins,ou=Groups,dc=byn,dc=drv" "cn" requested Oct 26 12:41:11 master slapd[18574]: => dn: [3] cn=domain admins,ou=groups,dc=byn,dc=drv Oct 26 12:41:11 master slapd[18574]: => acl_get: [3] matched Oct 26 12:41:11 master slapd[18574]: => acl_get: [3] attr cn Oct 26 12:41:11 master slapd[18574]: => acl_mask: access to entry "cn=Domain Admins,ou=Groups,dc=byn,dc=drv", attr "cn" requested Oct 26 12:41:11 master slapd[18574]: => acl_mask: to value by "uid=netadmin3,ou=users,dc=byn,dc=drv", (=0) Oct 26 12:41:11 master slapd[18574]: <= check a_set_pat: ([uid=] + ([cn=domain admins,ou=groups,dc=byn,dc=drv])/memberUid + [,ou=users,dc=byn,dc=drv]) & user Oct 26 12:41:11 master slapd[18574]: >>> dnNormalize: <cn=domain admins,ou=groups,dc=byn,dc=drv> Oct 26 12:41:11 master slapd[18574]: <<< dnNormalize: <cn=domain admins,ou=groups,dc=byn,dc=drv> Oct 26 12:41:11 master slapd[18574]: <= check a_dn_pat: * Oct 26 12:41:11 master slapd[18574]: <= acl_mask: [2] applying none(=0) (stop) Oct 26 12:41:11 master slapd[18574]: <= acl_mask: [2] mask: none(=0) Oct 26 12:41:11 master slapd[18574]: => access_allowed: search access denied by none(=0) If I use something simple like by set="([uid=] + user/uid + [,ou=users,dc=byn,dc=drv]) & user " write in order to test if by set works, the search works Oct 26 12:35:45 master slapd[18488]: => acl_mask: to value by "uid=netadmin3,ou=users,dc=byn,dc=drv", (=0) Oct 26 12:35:45 master slapd[18488]: <= check a_set_pat: ([uid=] + user/uid + [,ou=users,dc=byn,dc=drv]) & user Oct 26 12:35:45 master slapd[18488]: >>> dnNormalize: <uid=netadmin3,ou=users,dc=byn,dc=drv> Oct 26 12:35:45 master slapd[18488]: <<< dnNormalize: <uid=netadmin3,ou=users,dc=byn,dc=drv> Oct 26 12:35:45 master slapd[18488]: => bdb_entry_get: ndn: "uid=netadmin3,ou=users,dc=byn,dc=drv" Oct 26 12:35:45 master slapd[18488]: => bdb_entry_get: oc: "(null)", at: "uid" Oct 26 12:35:45 master slapd[18488]: bdb_dn2entry("uid=netadmin3,ou=users,dc=byn,dc=drv") Oct 26 12:35:45 master slapd[18488]: => bdb_entry_get: found entry: "uid=netadmin3,ou=users,dc=byn,dc=drv" Oct 26 12:35:45 master slapd[18488]: bdb_entry_get: rc=0 Oct 26 12:35:45 master slapd[18488]: <= acl_mask: [1] applying write(=wrscxd) (stop) Oct 26 12:35:45 master slapd[18488]: <= acl_mask: [1] mask: write(=wrscxd) Oct 26 12:35:45 master slapd[18488]: => access_allowed: read access granted by write(=wrscxd) Oct 26 12:35:45 master slapd[18488]: conn=0 op=1 ENTRY dn="cn=domain admins,ou=groups,dc=byn,dc=drv" It seems that the ([cn=domain admins,ou=groups,dc=byn,dc=drv])/memberUid is not expanded to all members I have tried several cases (Groups or groups) with no success. Is this the correct way of using posixgroups for ldap acl's? If not, what is the right way? If yes, what am I doing wrong? greetings hansjörg -- Dr. Hansjörg Maurer itsystems Deutschland AG Linprunstraße 10 80335 München Tel: +49-89-52 04 68-41 Fax: +49-89-52 04 68-59 E-Mail: hansjoerg.maurer(a)itsd.de Web: http://www.itsd.de Amtsgericht München HRB 132146 USt-IdNr. DE 812991301 Steuer-Nr. 143/100/81575 Aufsichtsratsvorsitzender: Stefan Adam Vorstand: Dr. Michael Krocka Dr. Hansjörg Maurer Dr. Wilfried Trinkl

2 3

Re: setting up admin password on openldap
by Gavin Henry 30 Oct '07

30 Oct '07

<quote who="Naufal Sheikh"> > Hello Piotr, > > I tried to do what you said. Initially my root dn just contained > cn=nsadmin, > and thus I caould not start slapd. Then I added to rootdn my suffix as > well, > and unhashed the rootpw line in slapd.conf. I tried using a clear text > "secret" as well as hashed value created through slappasswd and putting it > in the slapd.conf. In both cases, when I modify the entry and it asks me > to > give ldap password, it says invalid credentials. How are you trying to modify? What tool?

2 1

Re: setting up admin password on openldap
by Naufal Sheikh 30 Oct '07

30 Oct '07

Hello Piotr, I tried to do what you said. Initially my root dn just contained cn=nsadmin, and thus I caould not start slapd. Then I added to rootdn my suffix as well, and unhashed the rootpw line in slapd.conf. I tried using a clear text "secret" as well as hashed value created through slappasswd and putting it in the slapd.conf. In both cases, when I modify the entry and it asks me to give ldap password, it says invalid credentials. On 10/28/07, Piotr Wadas <pwadas(a)jewish.org.pl> wrote: > > > > On Fri, 26 Oct 2007, Naufal Sheikh wrote: > > > Hi, > > > > Can any one please give me a pointer on how to setup an admin password > on > > ldap. my sladp.config file does not hold any password and the line is > > hashed. It gives an error about something needing to be in suffix. I am > not > > sure what it is, but it is working fine on the production system from > which > > I am trying to migrate. > > > > I have successfully installed openldap on my linux system and it never > asked > > me for any password in the installation. Also I have imported the ldiff > from > > the production system. It has an entry of admin but has no password, > while > > on production system somehow the password is set. > > Look into manpage for slapd.conf, and add rootdn and rootpw directives > into slapd.conf configuration file, after appropriate "database" keyword. > Then, bind to ldap in with these credentials, and, if you wish, add ldap > object, with DN accordingly to rootdn, set password attribute using any > ldap browser - finally, you can remove rootpw from slapd.conf, to make > authorization check against database-stored password only. AFAIR any root > dn you'll set in rootdn directive must stay "below" related database > suffix ("cn=Directory Manager,dc=foo" cannot be rootdn of database > available under dc=bar suffix - or any other than "dc=foo" - suffix). > > Regards, > PW. >

2 1

change my database directory
by Gérard Madiot 29 Oct '07

29 Oct '07

Hi, I would like to change my database directory. I changed for newdir in slapd.conf and DB_CONFIG I have deleted my default database directory /var/lib/openldap/openldap-data When I run: slapd -Tt -F /home/ldap/newdir -f /home/ldap/newdir/slapd.conf I get the message: bdb_db_open: Cannot access database directory /var/lib/openldap/openldap-data (2) but I don't find any reference to openldap-data in my config files. Any suggestion?.

2 1

reducing information duplication
by Guillaume Rousse 29 Oct '07

29 Oct '07

Hello list. I'm looking for a way to reduce information duplication in an LDAP directory, using the equivalence of joint in SQL databases. Basically, all my user entries (inetorgperson + posixAccount) need to have a 'secretary' and a 'manager' field, but given than all users from the same group have the same secretary and the same manager, I'd prefer to refer to them at the group level, and refer to the group from the user entry. I've had a quick look at slapo-dynlist man page, it seems it could achieve it using 'see-also' attribute to refer to the group dn, and probably an additional schema to add 'secretary' and 'manager' attributes to my group entries (posixGroup + groupOfNames). Ideally, I would also use the same system to get the userGid attribute for the users. Does it sound like a good idea ?

6 15

slapd-monitor - monitorCounter/description ?
by Sadique Puthen 29 Oct '07

29 Oct '07

Hi, I checked openldap-2.2 and 2.3 and can see that monitorCounter is the attribute which describes slapd-monitor counter. Then, is there any truth in the http://www.samag.com/documents/s=9766/sam0506d/0506d.htm which says "description" attributes holds monitor counter? dn: cn=Current,cn=Connections,cn=Monitor objectClass: top objectClass: monitor objectClass: extensibleObject cn: Current description: 46 Regards, --Sadique

1 0

Re: setting up admin password on openldap
by Gabriel Stein 29 Oct '07

29 Oct '07

You see a rootpw with password hashed in slapd.conf, like Quanah said in another email. The slappaswd syntax: slappasswd -h HASH{MD5 or CRYPT, for example} -s password. For example: slappasswd -h {MD5} -s password Cheers. On 10/28/07, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > --On Friday, October 26, 2007 5:25 PM -0400 Naufal Sheikh > <naufalzamir(a)gmail.com> wrote: > > > > Any pointers will be appreciated > > Actually sending the error message would be useful. If there is no > password in slapd.conf, how can it be in slapd.conf, and hashed? I assume > you mean there's a rootpw line in slapd.conf that is hashed. Simply run > slappasswd to generate the hash of a password you know, and update > slapd.conf. Given the limited information you've supplied, that's the > best > shot in the dark I can make. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- /\ Gabriel Stein gabrielstein(a)gmail.com MSN: gabrielstein(a)hotmail.com Administrador de Redes - Network Administrador Linux User #223750 51-92796310 Porto Alegre - RS - Brasil

1 0

Re: Access Control by group
by Jason Dearborn 29 Oct '07

29 Oct '07

Quanah pointed out we're running a pretty old version, which could be the culprit. I know + signs in sets aren't supported. I'm slightly less than enthusiastic about upgrading since we rely on LDAP+Samba groups. It's been a few years since I slogged through that implementation, but it may be time to revist. Cheers, Jason On 10/26/07, Donn Cave <donn(a)u.washington.edu> wrote: > > > On Oct 26, 2007, at 1:42 PM, Jason Dearborn wrote: > > > Ack. > > > > Just found this: > > http://www.openldap.org/lists/openldap-software/200710/msg00343.html > > and this: > > http://www.mail-archive.com/openldap-software@openldap.org/ > > msg08524.html > > > > Looks like other people are trying to work with posixGroups as well. > > > Well, you see a lot of weird things on the web. I wouldn't take > this too seriously. > > I have not used posixGroup - we use groupOfNames, just like everyone > else except the posixGroup heretics and the groupOfUniqueName heretics. > But as far as I know, any of these works the same, and your syntax is > right. > > If you can turn debugging up on a test service, you can watch the whole > authorization thing happen in gory detail. This may uncover an issue > that has nothing to do with choice of group schema - like, you're > getting > stuck on another authorization in the configuration, or your member > values > don't actually match the authenticated names as intended, etc. I would > look at that before giving up on your schema, if you have some other > reason to need posixGroup. (If you don't, of course, groupOfNames is > the Right Way!) > > Donn Cave, donn(a)u.washington.edu > > >

2 1

Replication Problem
by Marcus Frischherz 29 Oct '07

29 Oct '07

Hi, I think I searched the internet and the documentation carefully, and still have problems: Master and slave are both openSuSE 10.2, running openldap 2.3.27 (unaltered SuSE version). I set up in the master: replogfile /var/lib/ldap/slurpd/slurpd.replog replica host=frifri_vpn:389 binddn="uid=rmanager,ou=intern,o=rori" bindmethod=simple credentials=xxx and on the slave: [...beginning of access rules] access to * by dn.exact="uid=rmanager,ou=intern,o=rori" write by * break access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword,userPKCS12 by self write by * auth access to attrs=shadowLastChange by self write by * read access to * by * read [...] updatedn="uid=rmanager,ou=intern,o=rori" updateref rori_vpn:389 and populated the slave's database with slapadd and restarted slapd on master and slave, + slurpd on master. Everytime I make a change on the master I get in the rejection file the same error code: ERROR: Constraint violation: structuralObjectClass: no user modification allow ed replica: frifri_vpn:389 time: 1193340583.0 dn: cn=test test,ou=people,o=rori changetype: add sn: test givenName: test mail: x@y mozillaCustom2: FriFri cn: test test objectClass: top objectClass: inetOrgPerson objectClass: abookPerson objectClass: mozillaOrgPerson structuralObjectClass: mozillaOrgPerson entryUUID: 6208a648-177c-102c-9f5a-29bdb5d43dbc creatorsName: cn=Manager,o=rori createTimestamp: 20071025192943Z entryCSN: 20071025192943Z#000000#00#000000 modifiersName: cn=Manager,o=rori modifyTimestamp: 20071025192943Z I have found various references to "Constraint violation: structuralObjectClass: no user modification allowed" on the internet, e.g. pointing out that a restore of a slapcat produced ldif with ldapadd will result in this error message (and ran myself into that problem, until I found out I was supposed to use slapadd), and apparently various people had the same occuring with replication, but I didn't see a solution. It seems that either master's ldap should not produce the structuralObjectClass: mozillaOrgPerson line (and other organization ones neither), or slave's ldap should accept it. The permissions I set according to advices on the list and slapd.access man page. What am I missing? kind regards, Marcus

5 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software October 2007