#61 Directory admin 1.5.1-1 fails under openldap 2.1

[Anonymous]

We upgraded to openldap 2.1 and have been using Dir
ADmin up till now. I installed a src rebuilt rpm for
1.5.1-1 on red hat 9. It installs fine.

However, on start up, there is a seg fault when I try
to start it up as it goes to read the ldap directory.

[Chad Walstrom]

Logged In: YES
user_id=459

There were changes to OpenLDAP with
respect to how it handles
objectClass
attributes. It will only accept one
objectClass of type
STRUCTURAL.
Currently, directory administrator uses
three STRUCTURAL classes in assigning
user accounts (account, inetOrgPerson,
and sambaAccount). In addition, it uses
two STRUCTURAL classes in assigning
group membership (posixGroup,
groupOfNames).

You can fix the personal accounts by
dropping the "host" attribute
and
"objectClass: account" attribute. Then
change sambaAccount to AUXILLARY
in the
schema file. To fix groups, convert all
"member" attributes to "memberUid" and
replace the field contents with just the
uid of the personal account. Then, drop
the "objectClass: groupOfNames"
attribute.

It's a pain, I know, but OpenLDAP is
simply being pedantic about schema
handling. The consistency is nice. The
only way I can think to fix the lack of the
host attribute is either by creating your
own AUXILLARY class, or by changing
"account" to AUXILLARY (which I highly
discourage!).

[Nobody/Anonymous]

Logged In: NO

You can update to Samba-3.0.x, it uses sambaSAMaccount
objectclass, what is Auxiliary.
But DA doesnt support samba3 still.

[Manuel Amador (Rudd-O)]

Logged In: YES
user_id=150358

We cannot remove the member attribute from groups. The
member attribute is crucial to be able to specify a
particular group in the directory where there are two or
more groups with the same name on different branches of an
organization (large organizations). The member attribute is
also used in OpenLDAP configuration and ACEs for access
control, and for mailing lists with mailman.

Groupofnames has to stay.

[Dieter Kluenter]

Logged In: YES
user_id=28312

I am using diradmin-1.5.1 as well with OpenLDAP-2.1.19 and
view the same error
It is due to an objectClass violation because of

called: ldap_create_record
LDAP_MOD_ADD objectclass
organizationalPerson
inetOrgPerson
account
top
posixAccount
shadowAccount
LDAP_MOD_ADD host
*
Although no host is added, objeclass account is being added
to an entry,
as account is a structural objectclass as person and its
enheritance, that surely will cause a violation

[Nathan Dial]

Logged In: YES
user_id=364140

I believe this schema bug would happen in openldap 1.2 as
well, as it's a problem with schemas breaking "LDAP rules"
rather than code itself, but 1.2 doesn't check schemas by
default and 2.1 does.

schema checking can be disabled in 2.1 by adding the line:

schemacheck off

to your slapd.conf.

After adding that line to my (2.1.22-8, Redhat rpm)
slapd.conf I was able to add users without segfaulting.

[Chad Walstrom]

Logged In: YES
user_id=459

Perhaps it's time that directory-administrator proposes its
own LDAP schema enhancements. How about an introspective
look at the SCHEMA of a given server that you're connecting
to and changing the behavior based on that (i.e. A real
data-driven application rather than an application that
drives data.)?

nathandial's suggestion works, but is it the Right(tm)
solution???

[David Miller]

Logged In: YES
user_id=648592

We're running into the group issue on our server... The
current version of OpenLDAP will not allow you to have a
single object that is both groupOfNames and posixAccount.
It has to be one or the other. We need posixAccount for our
system authentication. This ought to be a checkbox in the
compatibility panel in prefs if you can't autodetect it,
just like it does for the password attribute.

[podzap]

Logged In: YES
user_id=405496

Hi,
I submitted a patch a few hours ago which claimed to fix
this bug, but now that I look at the description, it does
not fix this bug.

The patch fixes a bug nonetheless: the inability to perform
an LDAPv3 bind. OpenLDAP 2.2.15 at least will not allow
LDAPv2 binds by default.

I could look at fixing some of the other bugs if this
project is still active. And assuming that my first patch is
accepted.

BR,
--
mike