Initially this problem was announced in PR#71202. I was asked by marcus to divde this PR and so I'm doing. This problem (and two others) is described in the article: http://www.iem.pw.edu.pl/~wielebap/ldap/pam_ldap/pam_ldap_doc.pdf You can also check PR #71287(pam_ldap). Description I cannot change passwords LDAP users passwords via pam_ldap. Why it is prohibited??? Are there any security problems??? Please let me know, CU Pawel Wieleba Example config: % cat /etc/pam.d/passwd password sufficient pam_unix.so no_warn try_first_pass nullok password sufficient pam_ldap.so use_first_pass Fix: You have to change and recompile /usr/src/usr.bin/passwd to enable changing pam_ldap passwords (I use this patch). A patch: %diff -u passwd.c.orig passwd.c #define pam_check(func) do { \--BYuUmyOWOZEqpRBy5RLgeGWUxhN5cRDA0e80WFTmYbTC2m2e Content-Type: text/plain; name="file.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="file.diff" --- /usr/src/usr.bin/passwd/passwd.c.orig Mon May 24 19:41:40 2004 +++ /usr/src/usr.bin/passwd/passwd.c Tue Aug 31 18:03:00 2004 @@ -121,8 +121,7 @@ break; default: /* XXX: Green men ought to be supported via PAM. */ - errx(1, - "Sorry, `passwd' can only change passwords for local or NIS users."); + fprintf(stderr, "Now you can change LDAP passwordi via PAM\n"); }
This is a multi-part message in MIME format.
Responsible Changed From-To: freebsd-bugs->des This sounds that this might be something for you Dag-Erling, can you have a look please? otherwise please reassign it to me and I'll look for a possible candidate :)
----- Forwarded message from Dag-Erling Smørgrav <des@des.no> ----- From: Dag-Erling Smørgrav <des@des.no> To: Mark Linimon <linimon@lonesome.com> The solution isn't as simple as the messages in the audit trail claim: 1) the current (admittedly gnarly) implementation attempts to preserve pre-existing functionality - the ability to change only the local password - which we probably will have to reimplement in some way or another. 2) applying the proposed patch as-is will leave a trail of dead code, non-functional command line options and outdated documentation, all of which needs to be cleaned up. 3) changing passwd(1) in this manner will expose code in our PAM modules which previously hasn't been used much (or at all), and which may contain surprises. We should probably look at what NetBSD did when they implemented PAM. (for suitable values of "we") DES -- Dag-Erling Smørgrav - des@des.no ----- End forwarded message -----
State Changed From-To: open->suspended Mark this as suspended for now, for reasons detailed in des' followup in the Audit-Trail.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Are there any updates? I seem to face the same issue as well. I have several FreeBSD systems that use LDAP to centrally manage user database. I used nss-pam-ldapd + NSS as the user database and used its PAM module for authentication and password modification. I added the pam_ldap.so to /etc/pam.d/passwd but passwd told me that it can only change passwords for local or NIS users. I looked at its source code and found there are nothing special with local or NIS users: passwd already uses pam and changing passwords is the work for specific pam modules. The hard coded check makes no sense for me and only makes passwd useless. On my machine, I manually removed the check and re-compiled passwd then it works perfectly of changing passwords for LDAP users using pam_ldap.so provided by nss-pam-ldapd. I do not see any reasons of keeping this limit. Are there any plans to remove it?
*** Bug 117812 has been marked as a duplicate of this bug. ***
Briefly summarized, in order to decide how to dispatch the pam_chauthtok call correctly, PAM needs to know where the user comes from (local, NIS, LDAP etc.), and it can't, because NSS and PAM are completely separate and unaware of each other. And even if it could, there is no mechanism in PAM for enabling or disabling individual service functions in a chain based on external information. The best solution is probably to use pam_exec to run a script that checks the UID and tells LDAP users to run ldappasswd instead, while allowing chauthtok calls for non-LDAP users (such as root) to proceed using pam_unix.
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>