Ralf Becker escribió:
Hi Oscar,
I have no idea why the root_dn should be “recalculated”, as far as I
know it’s only used to auth against the LDAP server, for creating or
modifying users.
I don’t know if an anonymous login is tried, but surely there’s
something at the login screen that tries to walk around ldap tree.
For contacts stored in LDAP with authenticate with the user itself and
the the root_dn, but otherwise it should be the unchanged root_dn
specified in setup.
The code is in phpgwapi/inc/class.accounts_ldap.inc.php in the
constructor arround line 133:
$this->ldap = new ldap();
$this->ds = $this->ldap->ldapConnect(
$this->frontend->config[‘ldap_host’],
$this->frontend->config[‘ldap_root_dn’],
$this->frontend->config[‘ldap_root_pw’]);
The read and save methods are in that class, right behind the
constructor - they just use the connection and authentication to the
LDAP made in the constructor.
Can you confirm you configured the following in setup:
Root DN: cn=admin,dc=subdomain1,dc=domain,dc=com
Root Pw: ********
Base DN for users: ou=people,dc=subdomain1,dc=domain,dc=com
Base DN for groups: ou=groups,dc=subdomain1,dc=domain,dc=com
Yes, I confirm that. Where do you think it’s best so I can debug why is
that rootdn being used? What appears on screen is this:
Error: Can’t bind to LDAP server:
cn=admin,dc=subdomain2,dc=domain,dc=com! accounts_ldap::__construct /
accounts::__construct / accounts::getInstance / egw::setup /
egw::__construct / include(/phpgwapi/inc/functions.inc.php) /
include(/header.inc.php)
Error: Can’t bind to LDAP server:
cn=admin,dc=subdomain2,dc=domain,dc=com! accounts_ldap::__construct /
accounts::__construct / CreateObject(phpgwapi.accounts)
Warning: ldap_search(): supplied argument is not a valid ldap link
resource in
/home/oscar2/public_html/egroupware/svnsite/trunk/egroupware/phpgwapi/inc/class.accounts_ldap.inc.php
on line 830
Warning: ldap_get_entries(): supplied argument is not a valid ldap link
resource in
/home/oscar2/public_html/egroupware/svnsite/trunk/egroupware/phpgwapi/inc/class.accounts_ldap.inc.php
on line 831
Warning: ldap_search(): supplied argument is not a valid ldap link
resource in
/home/oscar2/public_html/egroupware/svnsite/trunk/egroupware/phpgwapi/inc/class.accounts_ldap.inc.php
on line 847
Warning: ldap_get_entries(): supplied argument is not a valid ldap link
resource in
/home/oscar2/public_html/egroupware/svnsite/trunk/egroupware/phpgwapi/inc/class.accounts_ldap.inc.php
on line 849
www.eGroupWare.org
Your session could not be verified.
There’s extra info that should be transparent: I use one ldap server,
but to separate info, I have tree subtrees in different contexts,
invisible from one another (using different directories for every ldap
context under /var/lib/ldap so no data is shared). I’ve been able to get
some success when:
- Setting the “problematic” domain as only context in the ldap server
- Stick on the inetorgperson schema (it’s based on 1.2), so I’ll have
to find a way to migrate the schema (not the egw specifics, but other
settings related to the mentioned tracker id #57).
The mail domain (in your case “domain2.domain.com”) has nothing to do
with LDAP, it’s only used to construct email addresses, if none is
explicitly specified for an account or to authenticate against the IMAP
server, if multidomain is selected as IMAP type.
Then we log into the IMAP server with username@domain2.domain.com. If
IMAP (or SASL) is authenticating also against LDAP, maybe that causes
the wrong authentication you are seeing at the LDAP server.
I could do, but I don’t intend (at this time) to perform auth via email
address instead of uid of the user.
Btw. if we have a multi-domain setup, we usually use as base:
o=domain1.domain.com,dc=local and o=domain2.com,dc=local
as that allows to query all domains the mailserver is responsible from
LDAP and to have domains in different TLD’s. That’s not a requirement.
Apart from multicontext mentioned above (it’s for personal testing, not
in production), I’m using here also a multidomain egw installation, for
if that helps to solve the problem.
Regards.
Ralf
Oscar Manuel Gómez Senovilla schrieb:
Hi.
I’m currently testing in my laptop (ubuntu hardy) a migrated ldap tree.
The base context is dc=subdomain1,dc=domain,dc=com, and the rootdn is
cn=admin,dc=subdomain1,dc=domain,dc=com (i.e, in the first level, and I
specify the full dn). Then, the people tree is in ou=people(+basedn),
and the email domain for people is “subdomain2.domain.com”. I’ve set
auth and accounts to use in ldap. Though in /setup I put these
parameters as admin account (and when going back to main setup screen) I
get no errors, even for the admin account to be created, when “going to
the login screen”, egw tries to bind as
"cn=admin,dc=subdomain2,dc=domain,dc=com" instead of subdomain1, so
login always fails. I’ve tried for egw domain name both subdomain1 and
subdomain2 (appending domain.com), but egw always tries to bind using
"cn=admin,dc=subdomain2,dc=domain,dc=com", regardless whatever I set in
/setup as rootdn and the egw domain name.
I’m trying to work around tracker id #57, where the dn of the users is
the cn attribute instead of the uid. It looks like the rootdn specified
in /setup is recalculated. IMHO, the rootdn specified in /setup should
be respected, and if it’s not recalculated, then it’s a bug (maybe
because I’m using three levels instead of two for the base dn). I can’t
go on
If I should file a bug, please let me know.
Regards.
–
----------------------------------------------------------------------|
http://counter.li.org info: Linux user: 92390 - Linux machine: 39301 |
Oscar Manuel Gómez Senovilla - omgsATescomposlinux.org |
GPG Key at http://pgp.escomposlinux.org |
----------------------------------------------------------------------|
This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
