On Mon, Nov 11, 2013 at 08:08:39AM -0800, Quanah Gibson-Mount wrote:

--On Monday, November 11, 2013 3:03 PM +0400 Oleg lego12239@yandex.ru wrote:

...

Hello.

Our slapd listens on outer interfaces and i want to create an access rule for rootdn to allow admin access only from 127.0.0.1 ip. So, i try to add "dn: cn=admin,cn=config" record to config database:

~# cat admin.ldif dn: cn=admin,cn=config objectClass: person cn: admin sn: admin userPassword: 1

~# ldapadd -xWD 'cn=admin,cn=config' -f admin.ldif Enter LDAP Password: adding new entry "cn=admin,cn=config" ldap_add: Object class violation (65)

I got no extra info, just this. According to core.schema mandatory fields are only cn and sn. So, i don't understand why i see this error. Can anybody help me?

You are trying to create a user entry in the cn=config db. Clearly that will not work.

ok. How can i place restrictions for admin access to cn=config db? According to docs i must add a user to a db to do this.

On 11/11/2013 12:52 PM, Quanah Gibson-Mount wrote:

--On Monday, November 11, 2013 8:39 PM +0400 Oleg lego12239@yandex.ru wrote:

...

ok. How can i place restrictions for admin access to cn=config db? According to docs i must add a user to a db to do this.

I suggest looking at what Debian does in their default configurations, which restricts the admin user to using the ldapi:/// socket and the root user only, which meets your criteria for locking it down to localhost and even goes beyond that to locking down the user that is mapped to the rootdn as well.

--Quanah

Hi all,

I am trying to do something similar, and am experiencing issues as well. At the end of the day, my goal is to migrate from some older Mirapoint LDAP servers. Mirapoint uses OpenLDAP, but adds their own schema to the mix, and I'll have to import that as well. I also need the Samba support. Since Samba is a recognized service and schema, I thought I'd start with that.

Following your advice, here are some of my relevant config lines (though, not Debian):

******************* # rootdn can always read and write EVERYTHING! ...

database config access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none

...

rootdn "cn=Manager,dc=ndtel,dc=com" *******************

I can use cn=Manager,dc=ndtel,dc=com (and the associated password) to do other things (IE: see the existing structure and schemas in PHPLdapAdmin), but I cannot seem to update the config db.

Here's what happens when I attempt to import a schema LDIF, as explained at http://www.linuxquestions.org/questions/linux-server-73/how-to-add-a-new-sch...:

******************* [root@ldap1 ~]# ldapadd -x -W -D 'cn=Manager,dc=ndtel,dc=com' -W -f ./samba.ldif -H ldap://10.255.255.40 Enter LDAP Password: adding new entry "cn=samba,cn=schema,cn=config" ldap_add: Insufficient access (50) *******************

I have been researching this for a couple of days, and I can't seem to find the solution.

BTW: Centos 6.4, updated.

[root@ldap1 ~]# slapd -V @(#) $OpenLDAP: slapd 2.4.23 (Apr 29 2013 07:47:08) $

mockbuild@c6b7.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd

If anything else is needed to help with this troubleshooting or to help me understand what it is I am missing (which is what I prefer: to learn), please let me know.

Thanks!

Alex

On 11/12/2013 10:23 AM, Quanah Gibson-Mount wrote:

--On Tuesday, November 12, 2013 9:43 AM -0600 Alex Moen alexm@ndtel.com wrote:

...

[root@ldap1 ~]# slapd -V @(#) $OpenLDAP: slapd 2.4.23 (Apr 29 2013 07:47:08) $ mockbuild@c6b7.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23 /openldap-2.4.23/build-servers/servers/slapd

If anything else is needed to help with this troubleshooting or to help me understand what it is I am missing (which is what I prefer: to learn), please let me know.

First thing would be to run a current release, such as:

http://ltb-project.org/wiki/download#openldap

The build shipped by RH is ancient.

Second, it appears you are using slapd.conf, not cn=config, so I expect you to encounter failures for some config operations.

--Quanah

--

Quanah Gibson-Mount Architect - Server Zimbra, Inc.

---

Zimbra :: the leader in open source messaging and collaboration

Quanah,

Thanks so much for the advice and the pointer to ltb. This has solved most of my problem. I still have somewhat of an issue, but I will start a new thread about it.

Alex

On 11/12/2013 05:42 PM, Alex Moen wrote:

Hi all,

We are migrating from a Mirapoint OpenLDAP server to a new, Centos 6.4 OpenLDAP server:

[root@ldap1 ~]# /usr/local/openldap/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.36 (Aug 21 2013 09:39:54) $

clement@localhost.localdomain:/home/clement/build/BUILD/openldap-2.4.36/servers/slapd

I have added quite a few schema, including the Mirapoint, mgrp (another Mirapoint schema), parts of RFC2307, and samba, in order to support our exported LDIF from the Mirapoint server.

So, one of the entries in the exported LDIF is as follows:

dn: uid=maxUid,ou=ndtcadministration,o=ndtc objectClass: top objectClass: extensibleObject uidNumber: 55083

This DN is used to track the last (or next, maybe, I don't remember how I coded this function) UID number for newly added users. Each time a user is added, the number is incremented.

Again, this was taken directly from the exported LDIF from the Mirapoint server.

When I attempt to add the LDIF, I get the following:

[root@ldap1 ~]# /usr/local/openldap/bin/ldapadd -x -D "cn=admin,o=ndtc" -W -f rg600-usersonly.ldif -H ldap://localhost Enter LDAP Password: adding new entry "uid=maxUid,ou=ndtcadministration,o=ndtc" ldap_add: Object class violation (65) additional info: no structural object class provided

I am guessing that the OpenLDAP version that Mirapoint is using is less stringent than this new one, so it would allow the maxUid object to be created even though it is not exactly correct.

Any advice on this? What would the proper way to fix it be?

Thanks!

Alex

Scratch this... I intended to start a new thread, not add to this one. Please ignore this one and accept my apologies for my boneheadedness...

--On Tuesday, November 12, 2013 6:03 PM -0600 Alex Moen alexm@ndtel.com wrote:

Any advice on this? What would the proper way to fix it be?

Add a structural objectClass to the entry. All objects are required to have a basic structural objectClass.

--Quanah

--

Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

On Wed, 13 Nov 2013, Ulrich Windl wrote:

...

...

...

Quanah Gibson-Mount quanah@zimbra.com schrieb am 13.11.2013 um 02:24 in

Nachricht <90CA8980100EF12CE4C38252@[192.168.1.93]>:

...

--On Tuesday, November 12, 2013 6:03 PM -0600 Alex Moen alexm@ndtel.com wrote:

...

Any advice on this? What would the proper way to fix it be?

Add a structural objectClass to the entry. All objects are required to have a basic structural objectClass.

Sure? slapadd needs it, but ldapadd refuses to accept a structural objectclass specification in my experience.

The original poster was trying to add this LDIF:

dn: uid=maxUid,ou=ndtcadministration,o=ndtc objectClass: top objectClass: extensibleObject uidNumber: 55083

'top' is an abstract object class, while extensibleObject is an auxiliary object class, so none of that entry's object classes are structural object classes.

Philip Guenther

On 11/12/2013 07:24 PM, Quanah Gibson-Mount wrote:

--On Tuesday, November 12, 2013 6:03 PM -0600 Alex Moen alexm@ndtel.com wrote:

...

Any advice on this? What would the proper way to fix it be?

Add a structural objectClass to the entry. All objects are required to have a basic structural objectClass.

--Quanah

OK, deserved that... :)

I mistakenly thought "top" was structural, and after some more reading and research I see it's considered abstract...

Thanks!

Alex

dn: uid=maxUid,dc=europaschule,dc=do,dc=nw,dc=schule,dc=de objectClass: top objectClass: inetOrgPerson objectClass: extensibleobject uid: maxUid uidNumber: 55083 sn: maxUid cn: maxUid

Ulrich Windl wrote:

At this point I wonder whether there is some tool you can feed with a collection of LDAP schemas to find conflicts

You should define in detail what "find conflicts" means.

and at the end the tool should output the merge of all schemas (without duplicates).

What should the tool do if the schema elements differ in some details, like attribute type descriptions differing in matching rules definitions.

I also wonder if there is a standard for dumping the elements of a schema to a filesystem in a unique way

In web2ldap I simply use a subschema subentry with a pseudo-DN as LDIF file for providing a fallback schema in the configuration (which is used in the case a real subschema subentry is not readable for whatever reason).

Ciao, Michael.