11:22 a.m.
Date: Fri, 09 May 2008 17:34:37 -0700
From: Noriko Hosoi<nhosoi(a)redhat.com>
Subject: [Fedora-directory-devel] Please review: LDAPI+AUTOBIND
To: "Fedora Directory server developer discussion."
<fedora-directory-devel(a)redhat.com>
Message-ID:<4824ED9D.3080400@redhat.com>
Content-Type: text/plain; charset="utf-8"
LDAPI and AUTOBIND had been implemented some time back, but AUTOBIND did
not have an option to enable at the configuration.
That was an intentional decision, with a lot of strong reasons behind it. You
seem to be ignoring all the discussion that went into this before.
https://www.redhat.com/archives/fedora-directory-devel/2007-February/msg0...
The following review
requests includes
1. introducing the congirutation option --enable-autobind,
2. cleaning up the Directory Server instance creation code to support
AUTOBIND, and
3. bug fixes in the non-Linux part of slapd_get_socket_peer.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5:47 p.m.
On Sat, 2008-05-10 at 09:22 -0700, Howard Chu wrote:
> Date: Fri, 09 May 2008 17:34:37 -0700
> From: Noriko Hosoi<nhosoi(a)redhat.com>
> Subject: [Fedora-directory-devel] Please review: LDAPI+AUTOBIND
> To: "Fedora Directory server developer discussion."
> <fedora-directory-devel(a)redhat.com>
> Message-ID:<4824ED9D.3080400@redhat.com>
> Content-Type: text/plain; charset="utf-8"
>
> LDAPI and AUTOBIND had been implemented some time back, but AUTOBIND did
> not have an option to enable at the configuration.
That was an intentional decision, with a lot of strong reasons behind it. You
seem to be ignoring all the discussion that went into this before.
https://www.redhat.com/archives/fedora-directory-devel/2007-February/msg0...
I think the correct patch for review should be to remove this feature.
If someone really, really wants this, it should not be very hard at all
to create a deamon that listens on a temporary, per-user ldapi://
socket, and does an EXTERNAL bind on another (ns-slapd) socket before
passing the rest of the stream along.
If this is being setup to be enabled, what is the consumer of the API?
If not, why is this being made more visible?
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
1:20 p.m.
New subject: [Fedora-directory-devel] Please review (revised): LDAPI+AUTOBIND
Thank you for the background info and suggestions, Howard and Andrew.
We are thinking auto-bind could be useful for some type of applications
and trying to make it co-existing safely with the current features.
Here is the summary of the changes:
436388 (Item 1): --enable-autobind is supported. Unless it's set, the
auto-bind code is not compiled in.
436390 (Item 2): I updated the previous proposal based upon the
feedbacks: now auto-bind is executed only from the bind code and when
the client explicitly sends the SASL/EXTERNAL request to the server. On
the server side, it's disabled, by default. To enable it,
nsslapd-ldapiautobind needs to be set to "on" by an administrator.
Having these changes, e.g., this search request is authenticated as
Directory Manager if it's launched by a super user.
# ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-<ID>.socket
-b "cn=config" "(cn=*)"
If the EXTERNAL request is not passed, it's bound as anonymous.
436400 (Item 3): Currently, dse.ldif stores extra configuration
attributes only necessary for auto-bind, by default. They should not be
there unless auto-bind is enabled.
Your comments would be greatly appreciated.
Thanks,
--noriko
Item 1)
Summary: LDAPI: introduce --enable-autobind to support AUTOBIND
https://bugzilla.redhat.com/show_bug.cgi?id=436388
------- Additional Comments From nhosoi(a)redhat.com 2008-05-09 18:35
EST -------
Created an attachment (id=304990)
--> (https://bugzilla.redhat.com/attachment.cgi?id=304990&action=view)
cvs diff configure.ac Makefile.am
Files:
ldapserver/configure.ac
ldapserver/Makefile.am
Description: introduced --enable-autobind
By default, autobind is off.
Item 2)
Summary: LDAPI: support auto-bind
https://bugzilla.redhat.com/show_bug.cgi?id=436390
------- Additional Comments From nhosoi(a)redhat.com 2008-05-09 19:52
EST -------
Created an attachment (id=304994)
--> (https://bugzilla.redhat.com/attachment.cgi?id=304994&action=view)
cvs diff slap.h getsocketpeer.c daemon.c
Files:
ldap/servers/slapd/slap.h
/getsocketpeer.c
/daemon.c
Description:
Debugged the basic code of slapd_get_socket_peer, which is used for
Solaris9
and HP-UX. The recvmsg call returns an error immediately if no data
is waiting
to be received since the socket is set PR_SockOpt_Nonblocking
(O_NONBLOCK). To
make slapd_get_socket_peer more robust, we have to retry recvmsg if it
returns
EAGAIN. But set a retry count not to hang there.
Also introduced c_local_valid in the Connection handle to tell the
autobind
code that the uid/gid pair is valid or not.
------- Additional Comments From nhosoi(a)redhat.com 2008-05-13 12:23
EST -------
Created an attachment (id=305257)
--> (https://bugzilla.redhat.com/attachment.cgi?id=305257&action=view)
cvs diff daemon.c bind.c
Files:
ldap/servers/slapd/daemon.c
/bind.c
Description:
In addition to the previous changes, I'm modifying the code as
follows. The
change in daemon.c stops the automagic/unconditional auto-bind. In
bind.c,
slapd_bind_local_user (in which auto-bind is implemented) is called.
It was
called in do_bind even before, but there was no bind type or method
restriction
set. I'm proposing to change the code to call it only when SASL/EXTERNAL
request is passed.
Item 3)
Summary: LDAPI: cleaning up template-ldapi*.ldif files
https://bugzilla.redhat.com/show_bug.cgi?id=436400
------- Additional Comments From nhosoi(a)redhat.com 2008-05-09 18:52
EST -------
Created an attachment (id=304993)
--> (https://bugzilla.redhat.com/attachment.cgi?id=304993&action=view)
cvs diff template-ldapi-default.ldif.in DSCreate.pm.in
Files:
ldap/ldif/template-ldapi-default.ldif.in
ldap/admin/src/scripts/DSCreate.pm.in
Description:
LDAPI itself requires these 2 configuration parameters.
nsslapd-ldapifilepath: /var/run/slapd-<ID>.socket
nsslapd-ldapilisten: on
The rest is needed only when autobind is enabled.
Modified DSCreate to generate the following parameters when the DS is
configured with --enable-autobind.
nsslapd-ldapiautobind: off
nsslapd-ldapimaprootdn: cn=Directory Manager
nsslapd-ldapimaptoentries: off
nsslapd-ldapiuidnumbertype: uidNumber
nsslapd-ldapigidnumbertype: gidNumber
nsslapd-ldapientrysearchbase: <your_suffix>
nsslapd-ldapiautodnsuffix: cn=peercred,cn=external,cn=auth
Fixed nsslapd-ldapientrysearchbase value to set the server's suffix
(instead of
hardcoded dc=example,dc=com).
template-ldapi-default.ldif.in seems not used. But to reduce the
confusion, I
updated the file, as well, for the future use.
7:41 p.m.
New subject: [Fedora-directory-devel] Please review (revised): LDAPI+AUTOBIND
On Wed, 2008-05-14 at 11:20 -0700, Noriko Hosoi wrote:
Thank you for the background info and suggestions, Howard and
Andrew.
We are thinking auto-bind could be useful for some type of applications
and trying to make it co-existing safely with the current features.
Here is the summary of the changes:
436388 (Item 1): --enable-autobind is supported. Unless it's set, the
auto-bind code is not compiled in.
436390 (Item 2): I updated the previous proposal based upon the
feedbacks: now auto-bind is executed only from the bind code and when
the client explicitly sends the SASL/EXTERNAL request to the server. On
the server side, it's disabled, by default. To enable it,
nsslapd-ldapiautobind needs to be set to "on" by an administrator.
Having these changes, e.g., this search request is authenticated as
Directory Manager if it's launched by a super user.
# ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-<ID>.socket
-b "cn=config" "(cn=*)"
If the EXTERNAL request is not passed, it's bound as anonymous.
436400 (Item 3): Currently, dse.ldif stores extra configuration
attributes only necessary for auto-bind, by default. They should not be
there unless auto-bind is enabled.
Your comments would be greatly appreciated.
This looks much better.
If the client explicitly sends the SASL EXTERNAL bind, then this is a
desirable feature, and should (subject to ACLs and some configuration
that maps from unix to directory identities) work, preferably in the
default build (but perhaps, like OpenLDAP, without gaining any useful
privileges unless enabled by configuration).
I don't have any objection to SASL EXTERNAL binds, when described as
such. Howard and I have both objected to the concept, as described in
the wiki page, of AutoBind, where contrary to the spec, requests are
authenticated implicitly, without that SASL EXTERNAL bind.
In short: SASL EXTERNAL is the right way to do this, if you do it this
way, the objections go away.
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
2:05 a.m.
New subject: [Fedora-directory-devel] Please review (revised): LDAPI+AUTOBIND
Andrew Bartlett wrote:
> This looks much better.
If the client explicitly sends the SASL EXTERNAL bind, then this is a
desirable feature, and should (subject to ACLs and some configuration
that maps from unix to directory identities) work, preferably in the
default build (but perhaps, like OpenLDAP, without gaining any useful
privileges unless enabled by configuration).
I don't have any objection to SASL EXTERNAL binds, when described as
such. Howard and I have both objected to the concept, as described in
the wiki page, of AutoBind, where contrary to the spec, requests are
authenticated implicitly, without that SASL EXTERNAL bind.
Exactly.
In short: SASL EXTERNAL is the right way to do this, if you do it
this
way, the objections go away.
Agreed. In fact, in that case, it would make sense to have it always enabled
(whenever the platform supports it). This is what we do with OpenLDAP.
Andrew Bartlett
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10:48 a.m.
New subject: [Fedora-directory-devel] Please review (revised): LDAPI+AUTOBIND
Thank you, Andrew! Thank you, Howard! I'm so happy to hear your
comments. I thought I fixed the bug following your suggestion, but I
was afraid I might have missed something important. So, your feedback
made me relieved... Thanks! I'm going to check in the diffs.
--noriko
Howard Chu wrote:
Andrew Bartlett wrote:
>> This looks much better.
>
> If the client explicitly sends the SASL EXTERNAL bind, then this is a
> desirable feature, and should (subject to ACLs and some configuration
> that maps from unix to directory identities) work, preferably in the
> default build (but perhaps, like OpenLDAP, without gaining any useful
> privileges unless enabled by configuration).
>
> I don't have any objection to SASL EXTERNAL binds, when described as
> such. Howard and I have both objected to the concept, as described in
> the wiki page, of AutoBind, where contrary to the spec, requests are
> authenticated implicitly, without that SASL EXTERNAL bind.
Exactly.
> In short: SASL EXTERNAL is the right way to do this, if you do it this
> way, the objections go away.
Agreed. In fact, in that case, it would make sense to have it always
enabled (whenever the platform supports it). This is what we do with
OpenLDAP.
> Andrew Bartlett
8:37 a.m.
New subject: Re[2]: [Fedora-directory-devel] Please review (revised): LDAPI+AUTOBIND
Hi,
On the page of ldapi/auto-bind I have found the following paragraph :
If "nsslapd-ldapimaptoentries" value is "on", the uid and gid
are
searched with the filter "(&(uidNumber=<uid>)(gidNumber=<gid>)"
under
the search base "nsslapd-ldapientrysearchbase". Once a matched entry
is found, the client is authenticated as the entry. The uidNumber and
gidNumber attribute name are configurable with
"nsslapd-ldapiuidnumbertype" and
"nsslapd-ldapigidnumbertype",
respectively. Password is not necessary in the authentication.
What happens if there are serveral entries corresponding to the
abovementioned filter? The bind is refused or there is a random bind?
Or it will make an anynymous bind? I think this question should be
clearly defined (as it is defined in PKI external authentification
avec FDS).
Andrey Ivanov
Direction des Systemes d'Information
Ecole Polytechnique
91128 Palaiseau CEDEX
France
11:14 a.m.
New subject: [Fedora-directory-devel] Please review (revised): LDAPI+AUTOBIND
Andrey,
Thank you for pointing it out. If multiple entries are found, the
MapToEntries is considered failed. And it falls through the next step:
checking whether the client user is a super user or not. If it's not,
it's going to be an anonymous bind. I'm updating the memo.
Thanks!
--noriko
Andrey Ivanov wrote:
Hi,
On the page of ldapi/auto-bind I have found the following paragraph :
If "nsslapd-ldapimaptoentries" value is "on", the uid and gid
are
searched with the filter
"(&(uidNumber=<uid>)(gidNumber=<gid>)" under
the search base "nsslapd-ldapientrysearchbase". Once a matched entry
is found, the client is authenticated as the entry. The uidNumber and
gidNumber attribute name are configurable with
"nsslapd-ldapiuidnumbertype" and
"nsslapd-ldapigidnumbertype",
respectively. Password is not necessary in the authentication.
What happens if there are serveral entries corresponding to the
abovementioned filter? The bind is refused or there is a random bind?
Or it will make an anynymous bind? I think this question should be
clearly defined (as it is defined in PKI external authentification
avec FDS).
Andrey Ivanov
Direction des Systemes d'Information
Ecole Polytechnique
91128 Palaiseau CEDEX
France
--
Fedora-directory-devel mailing list
Fedora-directory-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
5880
days inactive
5891
days old
389-devel@lists.fedoraproject.org
7 comments
4 participants
participants (4)
-
Andrew Bartlett -
Andrey Ivanov -
Howard Chu -
Noriko Hosoi