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).
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.
Andrew
On Tue, Feb 15, 2011 at 4:40 PM, Andrew Findlay < andrew.findlay@skills-1st.co.uk> 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 5:08 PM, Leonardo Carneiro chesterman86@gmail.comwrote:
On Tue, Feb 15, 2011 at 4:40 PM, Andrew Findlay < andrew.findlay@skills-1st.co.uk> 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".
I uninstalled the recommended upgrade from the first link (the one that told to upgrade from libnss-ldap and libpam-ldap to libnss-ldapd and libpam-ldapd). Now i can do 'su - [login]' and have normal access to files again.
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.
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=*)'
Andrew
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.
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 Wednesday, February 16, 2011 12:16 PM +0000 Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
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.
Why? This is something Debian/Ubuntu chose to do for configuring the cn=config backend, not the OpenLDAP project. It should be something clearly documented by those projects. If you take the time to read the Ubuntu 10.04 LDAP guides, I know it is correctly documented there as it should be.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On Wed, Feb 16, 2011 at 08:09:55AM -0800, Quanah Gibson-Mount wrote:
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.
Why? This is something Debian/Ubuntu chose to do for configuring the cn=config backend, not the OpenLDAP project. It should be something clearly documented by those projects. If you take the time to read the Ubuntu 10.04 LDAP guides, I know it is correctly documented there as it should be.
This is not a Debian-specific issue. The OpenLDAP project is promoting the use of cn=config in place of slapd.conf yet when I look in the Admin Guide I find that there is not enough information to use it properly.
There are two separate issues:
(1) Getting a good initial config so that slapd can be managed through cn=config This is fairly well covered, with a few areas that need tidying up. I have proposed a couple of changes.
(2) Using ldapi: - particularly with SASL EXTERNAL, which is almost essential if you want to do a file-free bootstrap.
I am willing to help write the docs, but I am having trouble finding authoritative descriptions of how ldapi: behaves and should be used. I am sure there is useful info in the list archives somewhere - I just have not found it yet. Maybe I should use Ubuntu as the primary source?
Andrew
--On Wednesday, February 16, 2011 4:34 PM +0000 Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
(2) Using ldapi: - particularly with SASL EXTERNAL, which is almost essential if you want to do a file-free bootstrap.
I don't get where you're getting this idea from. I've never been required to use ldapi for setting up cn=config. The requirement of using ldapi for cn=config management is something Debian/Ubuntu is doing. Which is why, again, I say this specifically is not something to be documented by the OpenLDAP project as a cn=config requirement.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On Wed, Feb 16, 2011 at 08:37:01AM -0800, Quanah Gibson-Mount wrote:
I don't get where you're getting this idea from. I've never been required to use ldapi for setting up cn=config. The requirement of using ldapi for cn=config management is something Debian/Ubuntu is doing. Which is why, again, I say this specifically is not something to be documented by the OpenLDAP project as a cn=config requirement.
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.
Andrew
--On Wednesday, February 16, 2011 6:00 PM +0000 Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
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.
Yes, that seems worthwhile. ;)
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Andrew Findlay wrote:
On Wed, Feb 16, 2011 at 08:37:01AM -0800, Quanah Gibson-Mount wrote:
I don't get where you're getting this idea from. I've never been required to use ldapi for setting up cn=config. The requirement of using ldapi for cn=config management is something Debian/Ubuntu is doing. Which is why, again, I say this specifically is not something to be documented by the OpenLDAP project as a cn=config requirement.
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.
Everything worth noting about ldapi: was already published as an IETF Informational Draft, and I've already posted the link to that document several times. Beyond that it's no different from any other LDAP URL.
Andrew Findlay wrote:
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.
I don't know where Debian documents their bootstrap config, you'll have to ask them.
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
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.
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
On Thu, Feb 17, 2011 at 9:09 AM, Andrew Findlay < andrew.findlay@skills-1st.co.uk> wrote:
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.
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
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.
Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 fd=21 ACCEPT from IP= 172.16.14.2:34691 (IP=0.0.0.0:389) Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=0 BIND dn="cn=root,dc=dominio,dc=com,dc=br" method=128 Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=0 BIND dn="cn=root,dc=dominio,dc=com,dc=br" mech=SIMPLE ssf=0 Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=0 RESULT tag=97 err=0 text= Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=1 SRCH base="ou=Usuarios,dc=dominio,dc=com,dc=br" scope=2 deref=3 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" 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= Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 op=3 UNBIND Feb 17 11:11:39 fileserver slapd[2054]: conn=1014 fd=21 closed
Am Thu, 17 Feb 2011 11:28:59 -0200 schrieb Leonardo Carneiro chesterman86@gmail.com:
On Thu, Feb 17, 2011 at 9:09 AM, Andrew Findlay < andrew.findlay@skills-1st.co.uk> 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 [...]
-Dieter
Dieter Kluenter wrote:
Am Thu, 17 Feb 2011 11:28:59 -0200 schrieb Leonardo Carneiro chesterman86@gmail.com:
On Thu, Feb 17, 2011 at 9:09 AM, Andrew Findlay < andrew.findlay@skills-1st.co.uk> 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.
On Thu, Feb 17, 2011 at 1:03 PM, Pierangelo Masarati < masarati@aero.polimi.it> wrote:
Dieter Kluenter wrote:
Am Thu, 17 Feb 2011 11:28:59 -0200 schrieb Leonardo Carneiro chesterman86@gmail.com:
On Thu, Feb 17, 2011 at 9:09 AM, Andrew Findlay <
andrew.findlay@skills-1st.co.uk> 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?
Tks in advance.
On Thu, Feb 17, 2011 at 1:03 PM, Pierangelo Masarati < masarati@aero.polimi.it> wrote:
Dieter Kluenter wrote:
Am Thu, 17 Feb 2011 11:28:59 -0200 schrieb Leonardo Carneiro chesterman86@gmail.com:
On Thu, Feb 17, 2011 at 9:09 AM, Andrew Findlay <
andrew.findlay@skills-1st.co.uk> 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.
On Sat, Feb 19, 2011 at 10:16 AM, masarati@aero.polimi.it wrote:
On Thu, Feb 17, 2011 at 1:03 PM, Pierangelo Masarati < masarati@aero.polimi.it> wrote:
Dieter Kluenter wrote:
Am Thu, 17 Feb 2011 11:28:59 -0200 schrieb Leonardo Carneiro chesterman86@gmail.com:
On Thu, Feb 17, 2011 at 9:09 AM, Andrew Findlay <
andrew.findlay@skills-1st.co.uk> 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 chesterman86@gmail.comwrote:
On Sat, Feb 19, 2011 at 10:16 AM, masarati@aero.polimi.it wrote:
On Thu, Feb 17, 2011 at 1:03 PM, Pierangelo Masarati < masarati@aero.polimi.it> wrote:
Dieter Kluenter wrote:
Am Thu, 17 Feb 2011 11:28:59 -0200 schrieb Leonardo Carneiro chesterman86@gmail.com:
On Thu, Feb 17, 2011 at 9:09 AM, Andrew Findlay <
andrew.findlay@skills-1st.co.uk> 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?
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.
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.
On Sun, Feb 20, 2011 at 2:26 PM, masarati@aero.polimi.it wrote:
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
how to solve it, i'll make more sofisticated rules that adresses this problem too.
Tks again.
On Thu, Feb 17, 2011 at 11:28:59AM -0200, Leonardo Carneiro 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.
That is a simple authentication sequence, to validate your username and password. If you expect Apache to check group membership you should check its config. Remember that it may be using Unix-style groups, in which case there may be a cache involved (e.g. the nscd daemon) - in that case you may not see the LDAP queries at the same time as the login is processed.
Andrew
On Wed, Feb 16, 2011 at 8:51 AM, Howard Chu 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?
On Wed, Feb 16, 2011 at 10:22:58AM -0200, Leonardo Carneiro wrote:
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?
I would leave that alone. It does not introduce any extra problems, and you may need it later.
Andrew
Leonardo Carneiro wrote:
On Wed, Feb 16, 2011 at 8:51 AM, Howard Chu <hyc@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.
The entire point of using cn=config for configuration is that config changes don't require slapd restarts.
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?
Removing that would be dumb. It's there to give you an easy means to administer the server.
On Wed, Feb 16, 2011 at 8:43 AM, Andrew Findlay < andrew.findlay@skills-1st.co.uk> 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.
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
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 Wed, Feb 16, 2011 at 04:37:45PM -0200, Leonardo Carneiro wrote:
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.
OK - at least you now have some control over the server.
I notice some of my services do bind as cn=root,dc=dominio,dc=com,dc=br.
That may not be best practice, but I would leave it as-is for now.
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?
That depends on what searches Apache is issuing, and what data is really in the LDAP server. One way to find out is to turn up the logging in slapd. Something like:
loglevel 768
This will cause LDAP requests and results to be logged - probably to /var/log/syslog
Andrew
On Wednesday, 16 February 2011 20:37:45 Leonardo Carneiro wrote:
On Wed, Feb 16, 2011 at 8:43 AM, Andrew Findlay <
andrew.findlay@skills-1st.co.uk> 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
On Thu, Feb 17, 2011 at 7:50 AM, Buchan Milne bgmilne@staff.telkomsa.netwrote:
On Wednesday, 16 February 2011 20:37:45 Leonardo Carneiro wrote:
On Wed, Feb 16, 2011 at 8:43 AM, Andrew Findlay <
andrew.findlay@skills-1st.co.uk> 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
I don't have that "Satisfy" statement. The upgrade was from 2.2.9 to 2.2.16. I'll check the logs to see what filter apache was trying to do. In fact, i'm very noob in the syntax of the filters in ldapsearch, but everything i tried didn't work it out. I'll grab the logs and post back here.
openldap-technical@openldap.org
-
Andrew Findlay -
Buchan Milne -
Dieter Kluenter -
Howard Chu -
Leonardo Carneiro -
masarati＠aero.polimi.it -
Pierangelo Masarati
-
Quanah Gibson-Mount