Fwd: setting up admin password on openldap
by Naufal Sheikh
---------- 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.
>
15 years, 11 months
problem with access by set and group membership (posixgroup, groupofnames)
by "Dr. Hansjörg Maurer"
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
15 years, 11 months
Re: setting up admin password on openldap
by Gavin Henry
<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?
15 years, 11 months
Re: setting up admin password on openldap
by 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.
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.
>
15 years, 11 months
change my database directory
by Gérard Madiot
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?.
15 years, 11 months
reducing information duplication
by Guillaume Rousse
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 ?
15 years, 11 months
Re: setting up admin password on openldap
by Gabriel Stein
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
15 years, 11 months
Re: Access Control by group
by Jason Dearborn
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
>
>
>
15 years, 11 months
Replication Problem
by Marcus Frischherz
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
15 years, 11 months
