[turba] Re: Turba 1.2.2 and ldap

[Jānis]

Citēju Craig White <craigwhite at azapple.com>:

> On Mon, 2005-03-21 at 20:07 +0200, JÄ&#65533;nis wrote:
> > CitÄ&#65533;ju Craig White <craigwhite at azapple.com>:
>
> > > > In case of common addressbook, i can add and entry just a plain entry
> with
> > > name, if i try to add anything else, i get "There was an error adding
> this
> > > object."
> > > > and in horde log:
> > > > Mar 21 16:56:49 HORDE [error] [turba] Failed to add an object: [65]
> "Object
> > > > class violation" (attributes: [a:3:{s:2:"cn";s:12:"XXXX
> > > >
> YYYYY";s:4:"mail";s:11:"jkbjk at jk.lk";s:11:"objectclass";s:6:"person";}]).
> > > [on
> > > > line 41 of "/home/htdocs/morda/horde/turba/addobjectaction.php"]
> > > ----
> > > seems as though you would need a 'sn' attribute (surname - last name) as
> > > that is required by person objectclass
> >
> > ok, but i am going to add new entries using Turba and in that case the
> input
> > form does not contain sn/gn fields, just name. Hereto, if i enter info in
> > any of the other fields, i get the same "error adding object"... I think,
> there
> > is something to do with horde/ldap field mappings in turba conf...
> ----
> no not turba.conf
>
> turba/config/sources.php
>
> if you look at localldap and personal_ldap structures in the
> sources.php.dist
>
> you will note that the personal_ldap structure has a mapping for
>         'lastname' => 'sn',
>
> If you plan to add entries with objectclasses of person or
> inetOrgPerson, you MUST have an 'sn' attribute as those objectclasses
> require it - that is the error you are experiencing above
>
> You are free to modify localldap or any ldap item that you create to
> map/display attributes as needed or desired. In the case of adding
> entries with the objectclasses above, you need to know that the 'sn'
> attribute is needed.

here is the citation of core.shema modified according to the core.shema.patch

objectclass ( 2.5.6.6 NAME 'person'
        DESC 'RFC2256: a person'
        SUP top STRUCTURAL
        MUST cn
        MAY ( sn $ userPassword $ telephoneNumber $ seeAlso $ description ) )

from that i see, that sn is optional.
Regarding modification - can I only change mappings or more?

> > i made ldif file based on ISO8859-13 and slapcat can't add this as well (it
> > seems that only UTF8 is accepted) - just changed an ldif, which was
> accepted
> > previously
> ----
> if you can't slapadd/ldapadd an entry, there's little prospect for turba
> getting it done.

clear...


> ----
> >
> > > > as for personal address book, i can go further than:
> > > > slapd[17402]: conn=7 fd=14 ACCEPT from IP=xx.xx.xx.xx:40640
> > > (IP=0.0.0.0:389)
> > > > slapd[17423]: conn=7 op=0 BIND dn="cn=XXXX,ou=People,dc=d,dc=v"
> method=128
> > > > slapd[17423]: conn=7 op=0 RESULT tag=97 err=49 text=
> > > ----
> > > isn't that an insufficient privileges error?
> >
> > i don't think so (slapd.conf):
> > access to * by * write
> ----
> what you think isn't correct - looking at ldap.h
>
> err=49 is indeed INVALID CREDENTIALS
>
> #define LDAP_SECURITY_ERROR(n)  LDAP_RANGE((n),0x30,0x32) /* 48-50 */
>
> #define LDAP_INAPPROPRIATE_AUTH         0x30
> #define LDAP_INVALID_CREDENTIALS        0x31
> #define LDAP_INSUFFICIENT_ACCESS        0x32
> ----
> >
> > > > May be there issomething wrong woth directory config of turba config,
> > > because
> > > > all address book users are registered in ou=People as posixusers
> > > ----
> > > you have to manage your own ldap DSA - I wouldn't have turba writing to
> > > my ou=People leaf since I keep the posix stuff there and all security
> > > would be out the window. I tend to think of the ou=People not as an
> >
> > no, personal addressbooks are not under ou=People, but under
> > personal_addressbook:
> >
> > dn: ou=janis,ou=personal_addressbook,dc=dv,dc=lv
> > ou: janis
> > objectClass: top
> > objectClass: organizationalUnit
> > structuralObjectClass: organizationalUnit
> >
> > It should be noted that the only intended function of ldap at the moment is
> > storage of addrbooks for the use by Horde apps.
> ----
> seems rather short-sighted
>
> it's gonna make you work harder to 'authenticate' users to LDAP if you
> don't use LDAP for authentication but since your ACL is 'access to * by
> * write' - security and authentication have been rendered meaningless
> anyway.

it is set as recommended in Patrick Ni paper
(www.redant.ca/consulting/ldap/turba.php) for temporary use.


> anyway, something that I have never played with is an option in
> sources.php
>
>         'charset' => 'utf-8',
>
> you might be able to set it to something more to your liking

can't check because of the Error 49  i can't get authenticated
***