An other big update in accounts & contacts

[Ralf_Becker_6]

Hi,

just finished a few big changes in the accounts & contacts area:

1. SQL accounts table no longer stores firstname, lastname and email:

   • that info is now exclusivly in the contacts table (makes things there a
     lot easier and faster)
   • to get the updates for that right, I had to move the contacts tables
     back into the API (makes also sense if they store the account-info too)

2. LDAP stores the memberships now additionaly as a groupOfNames. This is
   needed for the ACL of group addressbooks, as LDAP itself needs the dn and
   not just the uid of the posixGroup. Unfortunally most system use the old
   nis.schema, in which posixGroup is a structural object and can therefor not
   be used together with groupOfNames. eGroupWare now “detects” that and only
   uses groupOfNames if it’s possible with the schemas used by the LDAP server.
   I updated the README in phpgwapi/doc/ldap with instructions on how to modify
   your LDAP to use the also commited newer rfc2307bis.schema, in which
   posixGroup is no structural object. Users of the SuSE distro are lucky, as
   SuSE uses this schema since some time.

3. Telefony integration is now configurable via Admin >> Addressbook >> Site
   configuration

4. Halfway finished a 3. contact repository mode “sql-ldap”, which uses SQL
   for read and search, but also updates LDAP, so one could use LDAP readonly
   (eg. for Thunderbird) and still have the features (eg. organisation views)
   and speed of SQL. This is not yet finished / operational.

Updated adressbook/doc/README and phpgwapi/doc/ldap/README.

Happy testing

Ralf

eGroupWare Training & Support ==> http://www.egroupware-support.de
1.2 Release Offer: 250Euro for a Standard Update or Installation
including 1h Telefonsupport und ein gedrucktes deutsches Handbuch

Ralf Becker
Outdoor Unlimited Training GmbH
Leibnizstr. 17
67663 Kaiserslautern

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Milosch]

It looks like the new top part of auth->compare_password() breaks my
login. I am using SSHA and SQL, and my crypted password has a + sign in it.

Ralf Becker wrote:

Hi,

just finished a few big changes in the accounts & contacts area:

1. SQL accounts table no longer stores firstname, lastname and email:

• that info is now exclusivly in the contacts table (makes things there a
  lot easier and faster)
• to get the updates for that right, I had to move the contacts tables
  back into the API (makes also sense if they store the account-info too)

2. LDAP stores the memberships now additionaly as a groupOfNames. This is
   needed for the ACL of group addressbooks, as LDAP itself needs the dn and
   not just the uid of the posixGroup. Unfortunally most system use the old
   nis.schema, in which posixGroup is a structural object and can therefor not
   be used together with groupOfNames. eGroupWare now “detects” that and only
   uses groupOfNames if it’s possible with the schemas used by the LDAP server.
   I updated the README in phpgwapi/doc/ldap with instructions on how to modify
   your LDAP to use the also commited newer rfc2307bis.schema, in which
   posixGroup is no structural object. Users of the SuSE distro are lucky, as
   SuSE uses this schema since some time.

3. Telefony integration is now configurable via Admin >> Addressbook >> Site
   configuration

4. Halfway finished a 3. contact repository mode “sql-ldap”, which uses SQL
   for read and search, but also updates LDAP, so one could use LDAP readonly
   (eg. for Thunderbird) and still have the features (eg. organisation views)
   and speed of SQL. This is not yet finished / operational.

Updated adressbook/doc/README and phpgwapi/doc/ldap/README.

Happy testing

Ralf

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Milosch]

Never mind the + sign. This change, though possibly incorrect, allows
me to login:

        // allow to specify the hash type to prefix the hash, to

easy migrate passwords from ldap

        $saved_enc = $encrypted;

        if

(preg_match(’/^\{([a-z_5]+)\}(.+)$/i’,$encrypted,$matches))

        {

            $type = strtolower($matches[1]);

            $encrypted = $matches[2];

            switch($type)   // some hashs are specially "packed" in

ldap

            {

                case 'md5':

                    $encrypted =

implode(’’,unpack(‘H*’,base64_decode($encrypted)));

                    break;

                case 'crypt':

                    // nothing to do

                    break;

                default:

                    $encrypted = $saved_enc;

                // ToDo: the others ...

            }

        }

Miles Lott wrote:

> It looks like the new top part of auth->compare_password() breaks my login. I am using SSHA and SQL, and my crypted password has a + sign in it. Ralf Becker wrote:

> > Hi, just finished a few big changes in the accounts & contacts area: 1) SQL accounts table no longer stores firstname, lastname and email: - that info is now exclusivly in the contacts table (makes things there a
> > lot easier and faster) - to get the updates for that right, I had to move the contacts tables
> > back into the API (makes also sense if they store the account-info too) 2) LDAP stores the memberships now additionaly as a groupOfNames. This is
> > needed for the ACL of group addressbooks, as LDAP itself needs the dn and
> > not just the uid of the posixGroup. Unfortunally most system use the old
> > nis.schema, in which posixGroup is a structural object and can therefor not
> > be used together with groupOfNames. eGroupWare now "detects" that and only
> > uses groupOfNames if it's possible with the schemas used by the LDAP server.
> > I updated the README in phpgwapi/doc/ldap with instructions on how to modify
> > your LDAP to use the also commited newer rfc2307bis.schema, in which
> > posixGroup is no structural object. Users of the SuSE distro are lucky, as
> > SuSE uses this schema since some time. 3) Telefony integration is now configurable via Admin >> Addressbook >> Site
> > configuration 4) Halfway finished a 3. contact repository mode "sql-ldap", which uses SQL
> > for read and search, but also updates LDAP, so one could use LDAP readonly
> > (eg. for Thunderbird) and still have the features (eg. organisation views)
> > and speed of SQL. This is not yet finished / operational. Updated adressbook/doc/README and phpgwapi/doc/ldap/README. Happy testing ;-) Ralf

> _______________________________________________
> eGroupWare-developers mailing list
> eGroupWare-developers@lists.sourceforge.net
> [https://lists.sourceforge.net/lists/listinfo/egroupware-developers](https://lists.sourceforge.net/lists/listinfo/egroupware-developers)

[Aleksander_Adamowsk1]

Ralf Becker wrote:

4. Halfway finished a 3. contact repository mode “sql-ldap”, which uses SQL
   for read and search, but also updates LDAP, so one could use LDAP readonly
   (eg. for Thunderbird) and still have the features (eg. organisation views)
   and speed of SQL. This is not yet finished / operational.

Hi!

I’ve been testing the latest version from SVN and observing the changes
made recently in the source, and I have some comments:

1. It seems to me that it still isn’t possible to configure eGroupWare
   for the most common scenario of LDAP usage with regards to Addressbook.

This scenario looks like this:
a) eGroupWare authentication is done through LDAP
b) eGroupWare user profiles are in a SQL database
c) Addressbook global, read-only contact list is based on LDAP (on the
same subtree that holds the accounts for “a)”)
d) Addressbook private, writable contacts are in a SQL database.

Specifically the “c)” part seems impossible currently because one has to
choose - store all the Addressbook either in LDAP, or in SQL.
From reading “addressbook/doc/README” I can see, that eGroupWare depens
on a specific directory layout for Addressbook, with branches named
"ou=contacts", “ou=shared”, “ou=personal”. This is an “everything or
nothing” approach - either you restructure your LDAP directory to
eGroupWare requirements, or you don’t connect Addressbook to LDAP at all.

Note that other address book implementations which access LDAP don’t
have such requirements - neither Thunderbird, nor MS Outlook, nor
Evolution or Squirrelmail require any specific LDAP layouts - you just
point them to the root DN of the branch they are to be searching, and
they do ordinary subtree search.

And in most cases, the branch for the accounts and the branch for the
address book are the same - the accounts ARE address book entries. They
are public and read-only for everyone.
This is how it is assumed to be organized for Thunderbird, MS Outlook,
Evolution, Squirrelmail, Roundcube and many others.

So e.g. we have:

dn: uid=someuser,l=Somecity,ou=People,o=Example
cn: Some User
givenName: Some
sn: User
telephoneNumber: (0-12) 345-67-89
mobile: 0-123-456-789
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: phpgwAccount
userPassword:: SOMEHASHEDPASSWORD
ou: marketing
ou: backoffice
homeDirectory: /home/someuser
uidNumber: 1234
gidNumber: 1234
mail: some.user@example.com
mail: s.user@example.com
mail: su@example.com
uid: someuser
manager: uid=otheruser,l=Othercity,ou=People,o=Example
phpgwAccountType: u

The userPassword and uid attributes are user by the LDAP server’s
authentication subsytem (to carry out LDAP BIND operations and password
changes with the “password change” extended operation from RFC3062).
The cn, uid, givenName, sn, mail attributes are used by the Addressbook
subsystem when looking up contact data (mail address, telephone number)

In eGroupWare, one cannot do it this way, one cannot hold the public
read-only addres book in LDAP, and private, writable contacs in SQL.
Instead, either everything is in SQL, or everything is in LDAP.
And to accomodate everything in LDAP, there’s a forced layout with a
separate branch for accounts (ou=accounts,o=default) and for the shared
address book (cn=default,ou=shared,ou=contacts,o=default).
Why are they separated? Why can’t Addressbook simply search for contacts
in the same branch which is used for LDAP authentication? This would be
so much simpler and avoid unnecessary redundancy. There could be just
one LDAP entry instead of two entries for each employee. Two entries
need to be somehow kept in sync and removed together when the employee
leaves the company - who would take care of that?

I understand that the given structure allows for more advanced things
being done, like storing all the address books (shared and personal) in
LDAP.
But this scheme is too complex to implement for many people and I
predict that this won’t be used by most eGroupWare implementors just
because of that complexity. I agree that this is a clever and
well-organized layout and eGroupWare should support it for larger
organizations.

But first of all, eGroupWare should support the typical, simple, popular
setup that I’ve described - the one with one subtree, storing all the
accounts in its branches, with accounts being address book entries at
the same time. Actually, this should be very simple to implement in
eGroupWare, too.

And the complex stuff with the layout from addressbook/doc/README should
be left to the brave ones, who have the time and possibility to
restructure their directory this way.

2. Keeping the private, writable contacts in LDAP may not be very wise.

The problem is that LDAP databases are usually optimized for read
performance, and typically only the users with some administrative roles
are allowed to update any directory entries.

For example, consider the following excerpts from LDAP literature
(emphasis mine):

From IBM Redbooks: “Understanding LDAP”:
-----------SNIP -----------
Because directories are meant to store relatively static information
and are
optimized for that purpose, they are not appropriate for storing information
that changes rapidly. For example, the number of jobs currently in a print
queue pro bably should not be stored in the directory entry for a printer
because that information would have to be updated frequently to be accurate.
Instead, the directory entry for the printer could contain the network
address
of a print server. The print server could be queried to learn the
current queue
length if desir ed. The informati on in the directory ( the print server
address) is
static, whereas the number of jobs in the print queue is dynamic.
-----------SNIP -----------

From http://ldapman.org/articles/intro_to_ldap.html :
-----------SNIP -----------
Is an LDAP information directory a database?
Just as a Database Management System (DBMS) from Sybase, Oracle,
Informix, or Microsoft is used to process queries and updates to a
relational database, an LDAP server is used to process queries and
updates to an LDAP information directory. In other words, an LDAP
information directory is a type of database, but it’s not a relational
database. And unlike databases that are designed for processing hundreds
or thousands of changes per minute - such as the Online Transaction
Processing (OLTP) systems often used in e-commerce - LDAP directories
are heavily optimized for read performance.
-----------SNIP -----------

So I predict with some LDAP implementations (like OpenLDAP) won’t
perform very well when eGroupWare starts storing ALL contacts in LDAP
directory.

I strongly suggest separating the address book to data sources:
a) global read-only address book (stored in LDAP)
b) writable address book (personal and shared contacts, stored in SQL).

One should use SQL for frequently changing data, and LDAP for
static/rarely changing data - this is how those database types are meant
to be used.

–
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.ab.altkom.pl

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Ralf_Becker_6]

Hi Aleksander,

thanks for your thoughts.

My comments are in your Text:

Aleksander Adamowski aleksander.adamowski.egroupware@altkom.pl wrote:

1. It seems to me that it still isn’t possible to configure eGroupWare
   for the most common scenario of LDAP usage with regards to Addressbook.

This scenario looks like this:
a) eGroupWare authentication is done through LDAP
b) eGroupWare user profiles are in a SQL database
c) Addressbook global, read-only contact list is based on LDAP (on the
same subtree that holds the accounts for “a)”)
d) Addressbook private, writable contacts are in a SQL database.

Not sure why this should be the most commen sencario. Why, for example, do
you want to store the accounts in LDAP and not use them as accounts for eGW.
(That might have made some sense with eGW 1.2, which required that extra
schema, but it makes no sense anymore.)

Specifically the “c)” part seems impossible currently because one has to
choose - store all the Addressbook either in LDAP, or in SQL.
From reading “addressbook/doc/README” I can see, that eGroupWare depens
on a specific directory layout for Addressbook, with branches named
"ou=contacts", “ou=shared”, “ou=personal”. This is an “everything or
nothing” approach - either you restructure your LDAP directory to
eGroupWare requirements, or you don’t connect Addressbook to LDAP at all.

We will later on (not yet coded) allow to support further addressbooks,
which can eg. be readonly.

So your case can simply be accomplished by leaving the standard addressbook
and (if you wish so) the accouns in SQL and just define an extra readonly
LDAP addressbook at a certain dn. These extra addressbook will not require
any structure / hirashy in LDAP.

If you asked, there’s not yet a fixed date, as other things have I higer
priority for me at the moment.

Note that other address book implementations which access LDAP don’t
have such requirements - neither Thunderbird, nor MS Outlook, nor
Evolution or Squirrelmail require any specific LDAP layouts - you just
point them to the root DN of the branch they are to be searching, and
they do ordinary subtree search.

The problem is not the search, we do the same, the problem is where do you
want to store them and limiting access. Thunderbird eg. dont care, as it
uses LDAP readonly.

And in most cases, the branch for the accounts and the branch for the
address book are the same - the accounts ARE address book entries. They
are public and read-only for everyone.
This is how it is assumed to be organized for Thunderbird, MS Outlook,
Evolution, Squirrelmail, Roundcube and many others.

The userPassword and uid attributes are user by the LDAP server’s
authentication subsytem (to carry out LDAP BIND operations and password
changes with the “password change” extended operation from RFC3062).
The cn, uid, givenName, sn, mail attributes are used by the Addressbook
subsystem when looking up contact data (mail address, telephone number)

In eGroupWare, one cannot do it this way, one cannot hold the public
read-only addres book in LDAP, and private, writable contacs in SQL.
Instead, either everything is in SQL, or everything is in LDAP.
And to accomodate everything in LDAP, there’s a forced layout with a
separate branch for accounts (ou=accounts,o=default) and for the shared
address book (cn=default,ou=shared,ou=contacts,o=default).
Why are they separated? Why can’t Addressbook simply search for contacts
in the same branch which is used for LDAP authentication? This would be

We need the hirashical structur, as we could not implement the necessary ACL
withing the limited possebilities of OpenLDAP on that account.

so much simpler and avoid unnecessary redundancy. There could be just
one LDAP entry instead of two entries for each employee. Two entries
need to be somehow kept in sync and removed together when the employee
leaves the company - who would take care of that?

Here you totaly wrong! We dont require any redundancy, as the accounts tree
is used as an addessbook too. With read access for everyone and write-access
for addmins only. You you no longer need to create your system users again
in the addessbook! This is one of the big benefits of the new addressbook.

For the rest of the text: Addressbook updates are happening very seldome,
most access is reading and search. Exactly where LDAP is made for. So I cant
follow that arguments.

Ralf

I understand that the given structure allows for more advanced things
being done, like storing all the address books (shared and personal) in
LDAP.
But this scheme is too complex to implement for many people and I
predict that this won’t be used by most eGroupWare implementors just
because of that complexity. I agree that this is a clever and
well-organized layout and eGroupWare should support it for larger
organizations.

But first of all, eGroupWare should support the typical, simple, popular
setup that I’ve described - the one with one subtree, storing all the
accounts in its branches, with accounts being address book entries at
the same time. Actually, this should be very simple to implement in
eGroupWare, too.

And the complex stuff with the layout from addressbook/doc/README should
be left to the brave ones, who have the time and possibility to
restructure their directory this way.

2. Keeping the private, writable contacts in LDAP may not be very wise.

The problem is that LDAP databases are usually optimized for read
performance, and typically only the users with some administrative roles
are allowed to update any directory entries.

For example, consider the following excerpts from LDAP literature
(emphasis mine):

From IBM Redbooks: “Understanding LDAP”:
-----------SNIP -----------
Because directories are meant to store relatively static information
and are
optimized for that purpose, they are not appropriate for storing
information
that changes rapidly. For example, the number of jobs currently in a
print
queue pro bably should not be stored in the directory entry for a printer
because that information would have to be updated frequently to be
accurate.
Instead, the directory entry for the printer could contain the network
address
of a print server. The print server could be queried to learn the
current queue
length if desir ed. The informati on in the directory ( the print server
address) is
static, whereas the number of jobs in the print queue is dynamic.
-----------SNIP -----------

From http://ldapman.org/articles/intro_to_ldap.html :
-----------SNIP -----------
Is an LDAP information directory a database?
Just as a Database Management System (DBMS) from Sybase, Oracle,
Informix, or Microsoft is used to process queries and updates to a
relational database, an LDAP server is used to process queries and
updates to an LDAP information directory. In other words, an LDAP
information directory is a type of database, but it’s not a relational
database. And unlike databases that are designed for processing hundreds
or thousands of changes per minute - such as the Online Transaction
Processing (OLTP) systems often used in e-commerce - LDAP directories
are heavily optimized for read performance.
-----------SNIP -----------

So I predict with some LDAP implementations (like OpenLDAP) won’t
perform very well when eGroupWare starts storing ALL contacts in LDAP
directory.

I strongly suggest separating the address book to data sources:
a) global read-only address book (stored in LDAP)
b) writable address book (personal and shared contacts, stored in SQL).

One should use SQL for frequently changing data, and LDAP for
static/rarely changing data - this is how those database types are meant
to be used.

–
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.ab.altkom.pl

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

–
eGroupWare Training & Support ==> http://www.egroupware-support.de
1.2 Release Offer: 250Euro for a Standard Update or Installation
including 1h Telefonsupport und ein gedrucktes deutsches Handbuch

Ralf Becker
Outdoor Unlimited Training GmbH
Leibnizstr. 17
67663 Kaiserslautern

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

[Aleksander_Adamowsk1]

Ralf Becker wrote:

Aleksander Adamowski aleksander.adamowski.egroupware@altkom.pl wrote:

1. It seems to me that it still isn’t possible to configure eGroupWare
   for the most common scenario of LDAP usage with regards to Addressbook.

This scenario looks like this:
a) eGroupWare authentication is done through LDAP
b) eGroupWare user profiles are in a SQL database
c) Addressbook global, read-only contact list is based on LDAP (on the
same subtree that holds the accounts for “a)”)
d) Addressbook private, writable contacts are in a SQL database.

Not sure why this should be the most commen sencario. Why, for example, do
you want to store the accounts in LDAP and not use them as accounts for eGW.
(That might have made some sense with eGW 1.2, which required that extra
schema, but it makes no sense anymore.)

Well, from my experimenting with the latest Subversion eGW source, I can
see that I have to modify my LDAP directory to yet another new schema:
rfc2307bis.schema, otherwise the Groups won’t work and I won’t be able
to even create the admin account.

So SQL is much simpler to set up with existing LDAP directory - this is
a significant advantage.
Messing with schema on an existing production LDAP server is a bad
idea, it’s risky. It needs extensive testing in a test environment, and
even then, with OpenLDAP, the directory needs to be stopped for a short
time, to export the whole directory to LDIF with slapcat, change the
schema and import the data again. I’ve observed that using slapcat on a
busy, running OpenLDAP directory can corrupt the database

And using simply LDAP authentication and storing accounts/groups in SQL
is much simpler, and eGroupWare can be easily connected to a running
LDAP directory this way.

BTW, in the rfc2307bis.schema, the attributetype memberUid misses this
one type of match that was present in nis.schema:
caseExactIA5SubstringsMatch

It should look like this:

attributetype ( 1.3.6.1.1.1.1.12 NAME 'memberUid’
EQUALITY caseExactIA5Match
SUBSTR caseExactIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

IMO it should be harmless to add it.

RFC 2307 has it, look for yourself:
http://www.faqs.org/rfcs/rfc2307.html

It seems that it’s missing in Your schema due to some mistake.

Also, You need to mention in phpgwapi/doc/ldap/README that after adding
"objectclass groupOfNames" to every group, all the objects need the
change in “structuralobjectClass:” special attribute (slapcat outputs it).

And there’s no example for giving a special eGroupWare LDAP user write
access to the Groups subtree.

I suggest the following changes to the README (I hope the diff won’t get
messed up by my mail program):

— README 2006-06-19 16:05:31.000000000 +0200
+++ README.olo 2006-06-25 01:06:58.000000000 +0200
@@ -6,7 +6,8 @@

• valid Groups have a posixGroup object class and store there members
  in the memberuid attribute.

If you want to use group-addressbooks in LDAP, the ACL requires that
groups get expanded by the LDAP server.
-To do so, we need to use groupOfNames together with posixGroup
(groupOfNames stores the dn, posixGroup only the uid).
+To do so, we need to use groupOfNames together with posixGroup
(groupOfNames stores the dn in the member
+attribute, posixGroup only the uid in the memberUid attribute).
If your LDAP uses the original nis.schema, posixGroup is a structural
object and can NOT be used together!
Newer SuSE distributions use a rfc2307bis schema, which can be used on
other distributions too
(instead of the nis.schema, NOT together). The schema is in the same
directory as this README.
@@ -15,6 +16,7 @@

• create an ldif from your ldap: slapcat > my.ldif
• add objectclass groupOfNames to every group (only the groups!)
  ± change every occurence of “structuralObjectClass: posixGroup” to
  "structuralObjectClass: groupOfNames"
• edit your slapd.conf:
  • remove the include of the nis.schema
  • include the rfc2307bis.schema in this dir
    @@ -26,4 +28,17 @@
    eGroupWare detects if it can use groupOfNames together with posixGroup
    and fills the member attribute,
    if you edit the group or changes the members.

+To create a dedicated LDAP account for eGroupWare, you can use the
following sample LDIF:
+
+dn: cn=eGroupWare,dc=domain,dc=com
+cn: eGroupWare
+objectClass: person
+sn: eGroupWare
+userPassword: SOME_LONG_RANDOM_PASSWORD
+
+To give eGroupWare permission to manage the groups, you can use the
following ACL:
+access to dn.subtree=“ou=groups,dc=domain,dc=com”

•    by dn="cn=eGroupWare,dc=domain,dc=com" write
  

Ralf

Specifically the “c)” part seems impossible currently because one has to
choose - store all the Addressbook either in LDAP, or in SQL.
From reading “addressbook/doc/README” I can see, that eGroupWare depens
on a specific directory layout for Addressbook, with branches named
"ou=contacts", “ou=shared”, “ou=personal”. This is an “everything or
nothing” approach - either you restructure your LDAP directory to
eGroupWare requirements, or you don’t connect Addressbook to LDAP at all.

We will later on (not yet coded) allow to support further addressbooks,
which can eg. be readonly.

So your case can simply be accomplished by leaving the standard addressbook
and (if you wish so) the accouns in SQL and just define an extra readonly
LDAP addressbook at a certain dn. These extra addressbook will not require
any structure / hirashy in LDAP.

That would be EXACTLY what I’m talking about. This is also how all the
LDAP clients in mail software work (Mozilla, Outlook, Evolution etc.).
This is how people expect it to work.
I’m looking forward to it - as soon as it arrives in Subversion, I’ll
test it

In eGroupWare, one cannot do it this way, one cannot hold the public
read-only addres book in LDAP, and private, writable contacs in SQL.
Instead, either everything is in SQL, or everything is in LDAP.
And to accomodate everything in LDAP, there’s a forced layout with a
separate branch for accounts (ou=accounts,o=default) and for the shared
address book (cn=default,ou=shared,ou=contacts,o=default).
Why are they separated? Why can’t Addressbook simply search for contacts
in the same branch which is used for LDAP authentication? This would be

We need the hirashical structur, as we could not implement the necessary ACL
withing the limited possebilities of OpenLDAP on that account.

Note that I was talking about the read-only public address book.
There’s no need for any ACLs in such case - simple anonymous bind (or on
a fixed, dedicated account) will suffice, provided that there are
relevant ACLs that provide read access.

A typical LDAP directory will have those read ACLs in place already,
because a public read-only organization-wide address book is the most
typical LDAP usage scenario.

so much simpler and avoid unnecessary redundancy. There could be just
one LDAP entry instead of two entries for each employee. Two entries
need to be somehow kept in sync and removed together when the employee
leaves the company - who would take care of that?

Here you totaly wrong! We dont require any redundancy, as the accounts tree
is used as an addessbook too. With read access for everyone and write-access
for addmins only. You you no longer need to create your system users again
in the addessbook! This is one of the big benefits of the new addressbook.

Does that mean that if LDAP is used for authentication, the new
Addressbook automatically shows all the accounts present in LDAP,
without further configuration? That would be wonderful! But I cannot get
it to work on my test installation from Subversion.
Maybe I’m doing something wrong - I have the following settings:
type of authentication: LDAP
where you want to store/retrieve use: SQL (tried with LDAP, too)
Usernames are casesensitive: Yes
Auto create account records for authenticated users: Yes
Add auto-created users to this group (‘Default’ will be attempted if
this is empty.):

I go to Addressbook, enter a fragment of my own name in the search
filed, and click search, and nothing is found.

Also, if I store accounts in LDAP, “Add auto-created users to Default
group” doesn’t seem to work - the admin user was added to the Default
group (cn=Default,ou=Groups,ROOT_DN), but an ordinary user isn’t added
to the Default group when he logs in.

My LDAP ACLs are probably OK - eGroupWare managed to add the admin user
to the Default group, only other users aren’t added…

For the rest of the text: Addressbook updates are happening very seldome,
most access is reading and search. Exactly where LDAP is made for. So I cant
follow that arguments.

Well, You’re probably right. Although some large sale departments may
generate quite a significant traffic in their Addressbooks - it’s the
main tool in their job…

What definitely shouldn’t be in LDAP, are the attributes You’ve placed
in phpgwaccount.schema: phpgwAccountLastLogin,phpgwAccountLastLoginFrom.

Updating LDAP with timestamps and IP addresses for all logins would
bring many OpenLDAP installations to a halt - they do updates very slowly!

Look carefully at rfc2307bis.schema: notice that the posixAccount and
shadowAccount objectclasses don’t have any attributes like that - only
the timestamp of lsta password change, which occurs much less frequently
than logins.

This is on purpose - LDAP isn’t designed to handle a continuous stream
of updates along with searches.

–
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.org.pl

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

---

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers