Thanks for replies, I think I need to better describe what I'm testing.
As I said I've a central repository for credentials accessible via ldaps.
389dirsvr stores some information, but before get them I need that a user authenticate on
the central repository.
So I've activated and configured PAM Pass Through Authentication Plug-in, and
following instructions creating a specific /etc/pam.d/ldapserver as well as
/etc/pam_ldap.conf
This is working, I mean that if I type
ldapsearch -v -LLL -Hldaps://my389 -b"dc=myDC" -D "uid=myUser" -W -x
the PAM PTA strips myUser from binddn and use that as login username for PAM.
Let me just say that in production I'll use a different repository based on Active
DIrectory, so probably I'll use SSSD, as you suggest.
The problem.
If I use a command like
ldapsearch -v -LLL -Hldaps://my389 -b"dc=myDC" -D "myUser" -W -x
it fails, since 389dirsrv makes a syntax check on binddn before pass stripped myUser value
to PAM PTA
This is really trye since I do not any attempt on ldap central repository access logs.
Here my question : is it mandatory using as binddn (-D) a syntax like uid=myUser or
cn=myUser, or is it possible to configure 389dirsrv to rewrite myUser in uid=myUser before
process it ?
Regards,
Paolo.
On 15/gen/2014, at 23:13, Dan Lavu <dan(a)lavu.net> wrote:
Why are you using pam passthrough, what are you using as your
authentication mechanism? SSSD has all commonly implemented authentication mechanisms.
On 01/15/2014 12:54 PM, Jonathan Vaughn wrote:
> If you want to be able to map the simple username "myUser" to say,
"uid=myUser,cn=Users,dc=mycompany,dc=net", you probably are best off using SSSD
to handle that.
> SSSD can be configured to know where to search and how to apply the supplied username
to the search (i.e. to look for anything under cn=Users,dc=mycompany,dc=net where uid=[the
supplied username]).
>
> SSSD in turn provides a PAM module to talk to the SSSD daemon itself, which is where
you can hook up your PAM passthrough authentication.
>
> i.e., we use SSSD for SSO login to our Linux machines, and have the following lines
(in addition to the usual stuff) in our pam.d/password-auth :
>
> auth sufficient pam_sss.so use_first_pass
> account [default=bad success=ok user_unknown=ignore] pam_sss.so
> password sufficient pam_sss.so use_authtok
> session optional pam_sss.so
>
>
>
>
> On Wed, Jan 15, 2014 at 3:46 AM, Paolo Barbato <paolo.barbato(a)igi.cnr.it>
wrote:
> Hi 389-users,
>
> I'm testing last released 389 dirsrv on a rhel 6.5.
>
> I've deployed a PAM passthrough, since I have a central repository for
credentials, and it works.
>
> I guess if it would be possible to use a simple username or it's mandatory use
syntax like uid=myuser (or cn=..) as bind dn.
>
> ldapsearch -v -LLL -Hldaps://my389 -b"dc=myDC" -D "uid=myUser" -W
-x works
>
> ldapsearch -v -LLL -Hldaps://my389 -b"dc=myDC" -D "myUser" -W -x
doesn't work
>
> ldap_bind: No such object (32)
> additional info: Bind DN [myUser] is invalid or not found
>
> So the question is if would be possible rewrite in some way the bind dn before syntax
check.
>
> Regards,
> Paolo.
>
>
------------------------------------------------------------------------------------------------
> Paolo Barbato
>
> Consorzio RFX
> corso Stati Uniti,4
>
> Network Administrator
> phone: +39 049 8295097 fax: +39 049 8700718
>
------------------------------------------------------------------------------------------------
>
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
> --
> 389 users mailing list
>
> 389-users(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
------------------------------------------------------------------------------------------------
Paolo Barbato
Consorzio RFX
corso Stati Uniti,4
35127 Padova - Italy
Network Administrator
phone: +39 049 8295097 fax: +39 049 8700718
------------------------------------------------------------------------------------------------