[Catalyst] LDAP question

[Kenneth S Mclane]

ok, making progress, I am getting all the data back in the return hash, =

however, I get the error: "Unable to locate user matching user info =

provided in realm: ldap" and get redirected back to the login page. I =

built this using some examples from the tutorial and the definitive guide, =

so I may have a wire crossed somewhere. Any ideas?

Luis Mu=F1oz <luisemunoz at gmail.com> wrote on 05/21/2012 11:18:48 AM:

> From:
> =

> Luis Mu=F1oz <luisemunoz at gmail.com>
> =

> To:
> =

> The elegant MVC web framework <catalyst at lists.scsys.co.uk>
> =

> Date:
> =

> 05/21/2012 11:20 AM
> =

> Subject:
> =

> Re: [Catalyst] LDAP question
> =

> =

> On May 21, 2012, at 12:02 PM, Kenneth S Mclane wrote:
> =

> > I have no control over the LDAP server, How would I change things =

> so the submitted username and password would be inserted as the =

> credentials to be used as the initial bind? =

> =

> You use that from the client.
> =

> Below is a snippet from a configuration file from a tool we use at =

> $work for managing LDAP entries. It works in the way I described before.
> =

> Pay attention to the binddn (the account to do the initial bind) and
> basedn (the place where you begin your search for a matching =

> username, using the filter expression). Start simple and build up =

> your expression to narrow down the tuples that it can retrieve. I'm =

> pro very strict filters based on object types, but there are perhaps
> other opinions.
> =

> Best regards
> =

> -lem
> =

> --8<----
> =

> # Configure the authentication subsystem. This is the component that
> # validates the current password for change requests. This service is
> # provided by Catalyst::Authentication::Store::LDAP.
> # =

> # The ldap realm is mandatory, as this is used not only for
> # authentication but for access to the user's LDAP entry, both for
> # searching and for updating it. This means that we need to use a
> # binddn with enough privileges to read and write to the
> # directory. It's not enough to rely on the users' credentials for
> # rebinding, because in the case of a password recovery, we don't have
> # user credentials.
> =

> authentication:
>   default_realm: ldap
>   realms:
>     ldap:
>       credential:
>         class:          Password
>         password_field: password
>         password_type:  self_check
>       store:
>         class:          LDAP
>         ldap_server:    localhost:3389
>         binddn:         cn=3Dyour_initial_id,dc=3Ddomain,dc=3Dcom,dc=3DIN=
VALID
>         bindpw:         Y0urS3cr3tB!ndP@$sw0rd
>         user_basedn: =

> ou=3DThe,ou=3DContainer,ou=3DHierarchy,dc=3Ddomain,dc=3Dcom,dc=3DINVALID
>         user_filter: (&(objectClass=3DinetOrgPerson)(|(uid=3D%s)(email=3D=
%s)))
>         user_field:     uid
>         use_roles:      0
> =

> =

> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: =

http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
> =

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20120521/404ea=
e53/attachment.htm