[Fedora-directory-devel] Re: Please review: LDAPI+AUTOBIND (Noriko Hosoi)

[Howard Chu]

> Date: Fri, 09 May 2008 17:34:37 -0700
> From: Noriko Hosoi
> Subject: [Fedora-directory-devel] Please review: LDAPI+AUTOBIND
> To: "Fedora Directory server developer discussion."
>    
> Message-ID:
> 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/msg0005...
> The following review
> requests includes
> introducing the congirutation option --enable-autobind,
> 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.

[Andrew Bartlett]

On Sat, 2008-05-10 at 09:22 -0700, Howard Chu wrote:
> > Date: Fri, 09 May 2008 17:34:37 -0700
> > From: Noriko Hosoi
> > Subject: [Fedora-directory-devel] Please review: LDAPI+AUTOBIND
> > To: "Fedora Directory server developer discussion."
> >    
> > Message-ID:
> > 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/msg0005...

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

[Fedora-directory-devel] Please review (revised): LDAPI+AUTOBIND

[Noriko Hosoi]

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 [e-mail]  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 [e-mail]  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 [e-mail]  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 [e-mail]  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.

[Fedora-directory-devel] Please review (revised): LDAPI+AUTOBIND

[Andrew Bartlett]

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

[Fedora-directory-devel] Please review (revised): LDAPI+AUTOBIND

[Howard Chu]

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

[Fedora-directory-devel] Please review (revised): LDAPI+AUTOBIND

[Noriko Hosoi]

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

Re[2]: [Fedora-directory-devel] Please review (revised): LDAPI+AUTOBIND

[Andrey Ivanov]

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] Please review (revised): LDAPI+AUTOBIND

[Noriko Hosoi]

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
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-directory-devel