This helped me on 16.04: http://kennywest.blogspot.co.at/2007/04
/pamccreds-howto.html
>> QUOTE
Update /etc/pam.d/common-auth:
auth sufficient pam_unix.so
auth [authinfo_unavail=ignore success=1 default=die] pam_ldap.so use_first_pass
auth [default=done] pam_ccreds.so action=validate
Modified version of the ldap-with-ccreds
** Attachment added: ldap-with-ccreds
https://bugs.launchpad.net/ubuntu/+source/libpam-ccreds/+bug/799605/+attachment/3773162/+files/ldap-with-ccreds
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
the ldap-with-ccreds should include a line after priority saying:
Conflicts: ldap
as it does not stack over ldap, but actually is a slight modification of
it, unless there is a cleaner way to actually modify ldap pam defs when
used in conjunctions with ccreds.
my guess this
a file that can be placed in /usr/share/pam-configs that will create
another choice in pam-update-auth to use ldap in conjunction with ccreds
is attached.
should it be included in ccreds package for example? or is there a
totally different and/or better approach?
** Attachment added:
So, what can fix this bug? does pam-update-auth have a mechanism to make
complix or mutually exclusive selections?
If not, either such a capability is to be impleneted; or a package for
ldap+ccreds is created and user will have to manaully select it from the
menu of pam-update-auth. is there
i second #6 , the recipe here
http://ubuntuforums.org/showthread.php?t=1708785 works for me too, the
critical section is also as mentioned authinfo_unavail=1 . fixing this
will boost ubuntu linux usage in network environment with central auth !
--
You received this bug notification because you
I've also got it to work by commenting out the line:
account requisitepam_deny.so
in common-account
This is also not satisfactory i guess; it will never deny, right?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I've subsequently implemented a slightly more elegant solution:
# here are the per-package modules (the Primary block)
account [success=2 new_authtok_reqd=done default=ignore]pam_unix.so
account [success=1 default=ignore] pam_ldap.so
# here's the fallback if no module succeeds
** PLEASE IGNORE THE ABOVE COMMENT **
It's the wrong common-account.
This is the correct one:
# here are the per-package modules (the Primary block)
account [success=2 new_authtok_reqd=done default=ignore]pam_unix.so
account [success=1 authinfo_unavail=1 default=ignore] pam_ldap.so
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: libpam-ccreds (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/799605
Title:
* Implement a (dummy?) account method in pam_ccreds and add that into the
relevant profile for cached credentials in pam_auth_update
That's what needs to happen here. pam_unix has no way of knowing why
the user's shadow entry is missing; and arguably this is a bug in your
NSS setup anyway
I agree that cached shadow would enable pam_unix to operate correctly.
As far as I'm aware, nss_updatedb does not support local caching of
shadow, only passwd and group, and the db option can't be used on the
shadow entry (only files and ldap) in nsswitch.conf. I presume that's
because of
12 matches
Mail list logo
