On Tue, Feb 15, 2011 at 4:40 PM, Andrew Findlay < andrew.findlay(a)skills-1st.co.uk&gt; wrote: > On Tue, Feb 15, 2011 at 04:04:57PM -0200, Leonardo Carneiro wrote: > > > Hmm, still did not worked. > > > > If i do a ldapsearch specifying '-D cn=root,dc=dominio,dc=com,dc=br" and > the > > password, the search goes ok. if i do not specify, is asks me for a > sasl/md5 > > authentication and fails, and just asks for a password. if i include a > '-x' > > parameter, also does not work: > > > > chester@reploid:~$ ldapsearch -v -h 192.168.0.2 -b > "dc=dominio,dc=com,dc=br" > > '(objectclass=*)' -LLL -x > > ldap_initialize( ldap://192.168.0.2 ) > > filter: (objectclass=*) > > requesting: All userApplication attributes > > No such object (32) > > You always need the -x flag. (You can only leave it out if > you supply SASL credentials, and that is a complexity we do > not need right now). > > Things are just complicated the way they are. if this will bring a extra layer of complexity I WILL NOT use right now. :) > It seems that anon users still cannot see the suffix entry > at all. > > Try adding this line just under your 'lastmod off' line: > > access to * by * read > > Make sure that you restart the slapd process after doing > this. Then try the search: > > ldapsearch -x -v -h 192.168.0.2 -b "dc=dominio,dc=com,dc=br" > '(objectclass=*)' > > If you still get nothing, set SLAPD_OPTIONS="-d 128" in > /etc/default/slapd and restart the server. It should not go > into the background, and should produce some output on the > screen. DO NOT REBOOT with this setting in place. > Now retry just the search above, and post the debug output > along with the new state of the slapd config file. > Remove the "-d 128" again. > > > Putting the "-d 128" made the script that starts the server do not go into the background, but it did not throw any output, so i called the server "by hand" with the following command: fileserver:/etc/ldap# /usr/sbin/slapd -h ldapi:/// ldap:/// -g openldap -u openldap -F /etc/ldap/slapd.d -d 128 @(#) $OpenLDAP: slapd 2.4.23 (Nov 22 2010 23:39:34) $ @biber:/build/buildd-openldap_2.4.23-7-i386-mi96UQ/openldap-2.4.23/debian/build/servers/slapd => access_allowed: search access to "cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => access_allowed: search access to "cn=module{0},cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => access_allowed: search access to "cn=schema,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => access_allowed: search access to "cn={0}core,cn=schema,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => access_allowed: search access to "cn={1}cosine,cn=schema,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => access_allowed: search access to "cn={2}nis,cn=schema,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => access_allowed: search access to "cn={3}inetorgperson,cn=schema,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => access_allowed: search access to "cn={4}samba,cn=schema,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => access_allowed: search access to "olcDatabase={-1}frontend,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) Backend ACL: access to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * +0 break Backend ACL: access to dn.base="" by * read Backend ACL: access to dn.base="cn=subschema" by * read => access_allowed: search access to "olcDatabase={0}config,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) Backend ACL: access to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * +0 break /etc/ldap/slapd.d: line 1: warning: cannot assess the validity of the ACL scope within backend naming context Backend ACL: access to * by * none /etc/ldap/slapd.d: line 1: warning: cannot assess the validity of the ACL scope within backend naming context => access_allowed: search access to "olcDatabase={1}bdb,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) Does these changes that we are making into slapd.conf really being processed? Normally, i see just the "-F /etc/ldap/slapd.d" flag and never the "-f /etc/ldap/slapd.conf".

On Tue, Feb 15, 2011 at 05:08:43PM -0200, Leonardo Carneiro wrote: > fileserver:/etc/ldap# /usr/sbin/slapd -h ldapi:/// ldap:/// -g openldap -u > openldap -F /etc/ldap/slapd.d -d 128 Aha! Your server is using LDAP-based config so it is ignoring the config file entirely. > Does these changes that we are making into slapd.conf really being > processed? Normally, i see just the "-F /etc/ldap/slapd.d" flag and never > the "-f /etc/ldap/slapd.conf". I suspect the config file was converted to a config dir during the Debian upgrade process, so the file is now being ignored. I also suspect that there may not be a valid password set on the cn=config suffix, so you will not be able to manage the server through LDAP either.

I don't have a Debian Squeeze server at present so I cannot check that. Where is this documented? I am having great trouble finding any clear description of how to actually access cn=config in the bootstrap case. Similarly I cannot find anything that clearly describes the use of SASL EXTERNAL with ldapi. If you can point me at some authoritative statements I will propose a patch for the Admin Guide.

(2) Using ldapi: - particularly with SASL EXTERNAL, which is almost essential if you want to do a file-free bootstrap.

OK - forget the link to cn=config - that is just what got me interested in ldapi: to start with. The ldapi: transport seems to be almost undocumented. There is a brief (but useful) mention in ldap.conf(5) but very little elsewhere. I have found enough hints in the archives to get started, so I will file some suggestions.

On Wed, Feb 16, 2011 at 02:51:19AM -0800, Howard Chu wrote: >> I also suspect that there may not be a valid password set on the >> cn=config suffix, so you will not be able to manage the server through >> LDAP either. > > Since it's starting on ldapi:/// he should just do a SASL EXTERNAL > bind on ldapi:// using Unix root. Pretty sure Debian packages it > with the appropriate authz-regexp already configured. I don't have a Debian Squeeze server at present so I cannot check that. Where is this documented? I am having great trouble finding any clear description of how to actually access cn=config in the bootstrap case.

Similarly I cannot find anything that clearly describes the use of SASL EXTERNAL with ldapi.

If you can point me at some authoritative statements I will propose a patch for the Admin Guide. Andrew

On Wed, Feb 16, 2011 at 03:29:45PM -0800, Howard Chu wrote: > >Similarly I cannot find anything that > >clearly describes the use of SASL EXTERNAL with ldapi. > > http://tools.ietf.org/html/draft-chu-ldap-ldapi-00 Excellent, thanks. That one is remarkably hard to find without a direct pointer. Could you add it to the doc/drafts directory in the source perhaps? Andrew

Am Thu, 17 Feb 2011 11:28:59 -0200 schrieb Leonardo Carneiro <chesterman86(a)gmail.com&gt;: > On Thu, Feb 17, 2011 at 9:09 AM, Andrew Findlay < > andrew.findlay(a)skills-1st.co.uk&gt; wrote: > >> On Wed, Feb 16, 2011 at 03:29:45PM -0800, Howard Chu wrote: >> [...] > Here is the search that Apache is doing. Note that "usuarios" in the > search means "users" in portuguese. It doesn't seems even to check if > the user really does part of the group defined in the apache config. > [...] > filter="(&(objectClass=*)(uid=lscarneiro))" > Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=1 SRCH attr=uid > Feb 17 11:11:39 fileserver slapd[2054]: <= bdb_equality_candidates: > (uid) not indexed > Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=1 ENTRY > dn="uid=lscarneiro,ou=usuarios,dc=dominio,dc=com,dc=br" here uid=lscarneiro has been found > Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=1 SEARCH RESULT > tag=101 err=0 nentries=1 text= > Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=2 BIND anonymous > mech=implicit ssf=0 > Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=2 BIND > dn="uid=lscarneiro,ou=Usuarios,dc=dominio,dc=com,dc=br" method=128 > Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=2 RESULT tag=97 > err=49 text= invalid credentials were presented

On Thu, Feb 17, 2011 at 1:03 PM, Pierangelo Masarati < masarati(a)aero.polimi.it&gt; wrote: > Dieter Kluenter wrote: > >> Am Thu, 17 Feb 2011 11:28:59 -0200 >> schrieb Leonardo Carneiro <chesterman86(a)gmail.com&gt;: >> >> On Thu, Feb 17, 2011 at 9:09 AM, Andrew Findlay < >>> andrew.findlay(a)skills-1st.co.uk&gt; wrote: >>> >>> On Wed, Feb 16, 2011 at 03:29:45PM -0800, Howard Chu wrote: >>>> >>>> [...] >> >>> Here is the search that Apache is doing. Note that "usuarios" in the >>> search means "users" in portuguese. It doesn't seems even to check if >>> the user really does part of the group defined in the apache config. >>> >>> [...] >> >>> filter="(&(objectClass=*)(uid=lscarneiro))" >>> Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=1 SRCH attr=uid >>> Feb 17 11:11:39 fileserver slapd[2054]: <= bdb_equality_candidates: >>> (uid) not indexed >>> Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=1 ENTRY >>> dn="uid=lscarneiro,ou=usuarios,dc=dominio,dc=com,dc=br" >>> >> >> here uid=lscarneiro has been found >> >> Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=1 SEARCH RESULT >>> tag=101 err=0 nentries=1 text= >>> Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=2 BIND anonymous >>> mech=implicit ssf=0 >>> Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=2 BIND >>> dn="uid=lscarneiro,ou=Usuarios,dc=dominio,dc=com,dc=br" method=128 >>> Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=2 RESULT tag=97 >>> err=49 text= >>> >> >> invalid credentials were presented >> > > Or insufficient access or any other error that would not be disclosed > occurred. > > p. > Hi guys. i saw something interesting now look at here: fileserver:/etc/ldap/slapd.d# smbldap-usershow lscarneiro | grep userPassword userPassword: {CRYPT}$1$IDz3CwLp$r5MsSU8QyMyoHUv8r.eqi. fileserver:/etc/ldap/slapd.d# ldapsearch -v -LLL -h 192.168.0.2 -b "dc=dominio,dc=com,dc=br" -D "cn=root,dc=dominio,dc=com,dc=br" -w [password] "(uid=lscarneiro)" ldap_initialize( ldap://192.168.0.2 ) filter: (uid=lscarneiro) requesting: All userApplication attributes userPassword:: e0NSWVBUfSQxJElEejNDd0xwJHI1TXNTVThReU15b0hVdjhyLmVxaS4= I think this explains why every single bind that i try with users other than cn=root gives me "invalid credentials". Is my assumption correct? Anyone knows why this passwords are not matching?

On Sat, Feb 19, 2011 at 10:16 AM, <masarati(a)aero.polimi.it&gt; wrote: > > On Thu, Feb 17, 2011 at 1:03 PM, Pierangelo Masarati < > > masarati(a)aero.polimi.it&gt; wrote: > > > >> Dieter Kluenter wrote: > >> > >>> Am Thu, 17 Feb 2011 11:28:59 -0200 > >>> schrieb Leonardo Carneiro <chesterman86(a)gmail.com&gt;: > >>> > >>> On Thu, Feb 17, 2011 at 9:09 AM, Andrew Findlay < > >>>> andrew.findlay(a)skills-1st.co.uk&gt; wrote: > >>>> > >>>> On Wed, Feb 16, 2011 at 03:29:45PM -0800, Howard Chu wrote: > >>>>> > >>>>> [...] > >>> > >>>> Here is the search that Apache is doing. Note that "usuarios" in the > >>>> search means "users" in portuguese. It doesn't seems even to check if > >>>> the user really does part of the group defined in the apache config. > >>>> > >>>> [...] > >>> > >>>> filter="(&(objectClass=*)(uid=lscarneiro))" > >>>> Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=1 SRCH attr=uid > >>>> Feb 17 11:11:39 fileserver slapd[2054]: <= bdb_equality_candidates: > >>>> (uid) not indexed > >>>> Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=1 ENTRY > >>>> dn="uid=lscarneiro,ou=usuarios,dc=dominio,dc=com,dc=br" > >>>> > >>> > >>> here uid=lscarneiro has been found > >>> > >>> Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=1 SEARCH RESULT > >>>> tag=101 err=0 nentries=1 text= > >>>> Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=2 BIND anonymous > >>>> mech=implicit ssf=0 > >>>> Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=2 BIND > >>>> dn="uid=lscarneiro,ou=Usuarios,dc=dominio,dc=com,dc=br" method=128 > >>>> Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=2 RESULT tag=97 > >>>> err=49 text= > >>>> > >>> > >>> invalid credentials were presented > >>> > >> > >> Or insufficient access or any other error that would not be disclosed > >> occurred. > >> > >> p. > >> > > Hi guys. i saw something interesting now look at here: > > > > fileserver:/etc/ldap/slapd.d# smbldap-usershow lscarneiro | grep > > userPassword > > userPassword: {CRYPT}$1$IDz3CwLp$r5MsSU8QyMyoHUv8r.eqi. > > fileserver:/etc/ldap/slapd.d# ldapsearch -v -LLL -h 192.168.0.2 -b > > "dc=dominio,dc=com,dc=br" -D "cn=root,dc=dominio,dc=com,dc=br" -w > > [password] > > "(uid=lscarneiro)" > > ldap_initialize( ldap://192.168.0.2 ) > > filter: (uid=lscarneiro) > > requesting: All userApplication attributes > > userPassword:: e0NSWVBUfSQxJElEejNDd0xwJHI1TXNTVThReU15b0hVdjhyLmVxaS4= > > > > I think this explains why every single bind that i try with users other > > than > > cn=root gives me "invalid credentials". Is my assumption correct? Anyone > > knows why this passwords are not matching? > > The two passwords match perfectly; only, the latter is base64-encoded for > LDIF presentation (as indicated by the double colon ('::')). > > I suggest you run slapd with -d acl in order to see whether the > authentication failure is related to access control, incorrect password or > so. > > p. > > Thanks for the tip Masarati I runned the test you told me and try to authenticate my apache in ldap. First it uses the cn=root to bind and search the uid informed by the user. Then, it trys to bind anonymous and match the password. I didn't understood this part of the log quite well. Here it is: Feb 19 10:24:07 fileserver slapd[18421]: conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Feb 19 10:24:07 fileserver slapd[18421]: conn=1001 op=2 BIND anonymous mech=implicit ssf=0 Feb 19 10:24:07 fileserver slapd[18421]: conn=1001 op=2 BIND dn="uid=lscarneiro,ou=Usuarios,dc=dominio,dc=com,dc=br" method=128 Feb 19 10:24:07 fileserver slapd[18421]: => access_allowed: result not in cache (userPassword) Feb 19 10:24:07 fileserver slapd[18421]: => access_allowed: auth access to "uid=lscarneiro,ou=Usuarios,dc=dominio,dc=com,dc=br" "userPassword" requested Feb 19 10:24:07 fileserver slapd[18421]: => acl_get: [1] attr userPassword Feb 19 10:24:07 fileserver slapd[18421]: => acl_mask: access to entry "uid=lscarneiro,ou=Usuarios,dc=dominio,dc=com,dc=br", attr "userPassword" requested Feb 19 10:24:07 fileserver slapd[18421]: => acl_mask: to value by "", (=0) Feb 19 10:24:07 fileserver slapd[18421]: <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth Feb 19 10:24:07 fileserver slapd[18421]: <= check a_dn_pat: * Feb 19 10:24:07 fileserver slapd[18421]: <= acl_mask: [2] applying +0 (break) Feb 19 10:24:07 fileserver slapd[18421]: <= acl_mask: [2] mask: =0 Feb 19 10:24:07 fileserver slapd[18421]: => dn: [2] Feb 19 10:24:07 fileserver slapd[18421]: => dn: [3] cn=subschema Feb 19 10:24:07 fileserver slapd[18421]: <= acl_get: done. Feb 19 10:24:07 fileserver slapd[18421]: => slap_access_allowed: no more rules Feb 19 10:24:07 fileserver slapd[18421]: => access_allowed: no more rules Feb 19 10:24:07 fileserver slapd[18421]: conn=1001 op=2 RESULT tag=97 err=49 text= Feb 19 10:24:07 fileserver slapd[18421]: conn=1001 op=3 UNBIND Feb 19 10:24:07 fileserver slapd[18421]: conn=1001 fd=15 closed What can i learn from this?

> On Sat, Feb 19, 2011 at 10:37 AM, Leonardo Carneiro > Hey, it finally worked! I've added the follwing in the cn=config database: > > olcAccess: {0}to * by * read > > Since there was no acl rules for this cn or the bdb. > > I cannot thanks enough everyone that helped me, specially Andrews, Howard > and Piearangelo for the killing tips. This rule (the first rule, as I infer from the prefix {0}) means that anyone can read everything, including passwords. This probably solves one problem you're having, but opens a can of worms. p. Yeah, i'm well aware of that. Now that we've found what the problem is, and

Andrew Findlay wrote: > On Tue, Feb 15, 2011 at 05:08:43PM -0200, Leonardo Carneiro wrote: > > fileserver:/etc/ldap# /usr/sbin/slapd -h ldapi:/// ldap:/// -g openldap >> -u >> openldap -F /etc/ldap/slapd.d -d 128 >> > > Aha! Your server is using LDAP-based config so it is ignoring the config > file entirely. > > Does these changes that we are making into slapd.conf really being >> processed? Normally, i see just the "-F /etc/ldap/slapd.d" flag and never >> the "-f /etc/ldap/slapd.conf". >> > > I suspect the config file was converted to a config dir during the > Debian upgrade process, so the file is now being ignored. > > I also suspect that there may not be a valid password set on the > cn=config suffix, so you will not be able to manage the server through > LDAP either. > Since it's starting on ldapi:/// he should just do a SASL EXTERNAL bind on ldapi:// using Unix root. Pretty sure Debian packages it with the appropriate authz-regexp already configured. Tks for the tips guys. I'll try all this stuff at launch time here in

On Wed, Feb 16, 2011 at 8:51 AM, Howard Chu <hyc(a)symas.com <mailto:hyc@symas.com>> wrote: Andrew Findlay wrote: On Tue, Feb 15, 2011 at 05:08:43PM -0200, Leonardo Carneiro wrote: fileserver:/etc/ldap# /usr/sbin/slapd -h ldapi:/// ldap:/// -g openldap -u openldap -F /etc/ldap/slapd.d -d 128 Aha! Your server is using LDAP-based config so it is ignoring the config file entirely. Does these changes that we are making into slapd.conf really being processed? Normally, i see just the "-F /etc/ldap/slapd.d" flag and never the "-f /etc/ldap/slapd.conf". I suspect the config file was converted to a config dir during the Debian upgrade process, so the file is now being ignored. I also suspect that there may not be a valid password set on the cn=config suffix, so you will not be able to manage the server through LDAP either. Since it's starting on ldapi:/// he should just do a SASL EXTERNAL bind on ldapi:// using Unix root. Pretty sure Debian packages it with the appropriate authz-regexp already configured. Tks for the tips guys. I'll try all this stuff at launch time here in Brazil (about 2 hours from now). There are to many users using Samba right now, and every time I have to restart the OpenLDAP something on samba crashes.

As far as i'm concerned, i didn't have the need to use SASL, and it seems that all this SASL mechanism was auto-introduced in my setup after the upgrade. Is it safe to edit /etc/defaults/slapd and remove the "ldapi:///" parameter in SLAPD_SERVICES line or i can break something very hard doing this?

The new slapd.d was created successfully and now i can do searches anonymously. Searches like: ldapsearch -x -h server -D cn=config -w [passwd] -b cn=config ldapsearch -x -h server -b "dc=dominio,dc=com,dc=br" are working ok now. Unfortunally, services are not able to do the search yet. At least with the configuration that was working before the upgrade.

I notice some of my services do bind as cn=root,dc=dominio,dc=com,dc=br.

Here it is a example of the apache: AuthBasicProvider ldap AuthName "who are you?" AuthzLDAPAuthoritative OFF AuthLDAPURL "ldap:// 192.168.0.2/ou=users,dc=dominio,dc=com,dc=br?uid" AuthLDAPGroupAttribute memberUid AuthLDAPGroupAttributeIsDN OFF AuthLDAPBindDN "cn=root,dc=dominio,dc=com,dc=br" AuthLDAPBindPassword "[password]" Require ldap-group cn=devteam,ou=groups,dc=dominio,dc=com,dc=br In the apache log, it just seams that the apache did bind it to ldap, but the search results were null. It should work ok know, since i can even bind anonymous, write?

On Wednesday, 16 February 2011 20:37:45 Leonardo Carneiro wrote: > On Wed, Feb 16, 2011 at 8:43 AM, Andrew Findlay < > > andrew.findlay(a)skills-1st.co.uk&gt; wrote: > > On Tue, Feb 15, 2011 at 05:08:43PM -0200, Leonardo Carneiro wrote: In the original question: > Hello everyone, > > I upgraded my debian machine from lenny to squeeze (the new stable) > that comes with samba 3.5.6 and openldap 2.4.23. this machines works > primarily as a PDC. > > i have 3 services authenticating on ldap: samba, apache and redmine. > samba is acting very weird, but it's kinda working, but redmine and > apache aren't working at all. So, I take it Apache was upgraded as well? From what version? To what version? > > > fileserver:/etc/ldap# /usr/sbin/slapd -h ldapi:/// ldap:/// -g openldap > > > > -u > > > > > openldap -F /etc/ldap/slapd.d -d 128 > > > > Aha! Your server is using LDAP-based config so it is ignoring the config > > file entirely. > > > > > Does these changes that we are making into slapd.conf really being > > > processed? Normally, i see just the "-F /etc/ldap/slapd.d" flag and > > > never the "-f /etc/ldap/slapd.conf". > > > > I suspect the config file was converted to a config dir during the > > Debian upgrade process, so the file is now being ignored. > > > > I also suspect that there may not be a valid password set on the > > cn=config suffix, so you will not be able to manage the server through > > LDAP either. > > > > One solution is to change the startup process to use the config file (-f > > option) rather than the config dir (-F option). Once you have a file > > that does what you want you have the option of converting it to a > > > > directory: > > Move aside the existing config directory /etc/ldap/slapd.d > > and make a new one with the same ownership and permissions. > > > > Start slapd with both the -f and the -F options. > > > > If you are going to do this, I suggest adding a rootpw for the config > > database first. Append this to your slapd.conf file: > > > > ######################################################################## > > database config > > > > rootdn "cn=config" > > rootpw example > > ######################################################################## > > > > You will then be able to do normal LDAP operations on the config: > > > > ldapsearch -x -D cn=config -w example -b cn=config '(objectclass=*)' > > > > I think we're really near to success here =D. > > The new slapd.d was created successfully and now i can do searches > anonymously. Searches like: > > ldapsearch -x -h server -D cn=config -w [passwd] -b cn=config > ldapsearch -x -h server -b "dc=dominio,dc=com,dc=br" > > are working ok now. Unfortunally, services are not able to do the search > yet. At least with the configuration that was working before the upgrade. > > I notice some of my services do bind as cn=root,dc=dominio,dc=com,dc=br. > Here it is a example of the apache: > > AuthBasicProvider ldap > AuthName "who are you?" > AuthzLDAPAuthoritative OFF > AuthLDAPURL "ldap:// > 192.168.0.2/ou=users,dc=dominio,dc=com,dc=br?uid" > AuthLDAPGroupAttribute memberUid > AuthLDAPGroupAttributeIsDN OFF > AuthLDAPBindDN "cn=root,dc=dominio,dc=com,dc=br" > AuthLDAPBindPassword "[password]" > Require ldap-group > cn=devteam,ou=groups,dc=dominio,dc=com,dc=br If you now have Apache 2.2.x, either you have include only some of the relevant statements, or you are missing a "Satisfy" statement, e.g. "Satisfy All". > In the apache log, it just seams that the apache did bind it to ldap, but > the search results were null. It should work ok know, since i can even bind > anonymous, write? Show the log of the LDAP search by apache, so we can be sure. But, when upgrading from Apache 2.0 to Apache 2.2, one thing that messed me around for a few hours was the 'Satisfy' statement. Without it, the behaviour didn't make sense ... Regards, Buchan