It looks like you're missing a password stack in your /etc/pam.conf. I think you got the example pam.conf here: http://docs.sun.com/app/docs/doc/816-4556/6maort2tb?a=view ...but did you omit the bottom portion of the file? This part: # # Default definition for Session management # Used when service name is not explicitly mentioned for session management # other session required pam_unix_session.so.1 # # Default definition for Password management # Used when service name is not explicitly mentioned for password management # other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 Susan wrote: > I got it from docs.sun.com: > > -bash-3.00# cat /etc/pam.conf > # > # Authentication management > # > # login service (explicit because of pam_dial_auth) > # > login auth requisite pam_authtok_get.so.1 > login auth required pam_dhkeys.so.1 > login auth required pam_dial_auth.so.1 > login auth required pam_unix_cred.so.1 > login auth sufficient pam_unix_auth.so.1 > login auth required pam_ldap.so.1 > # > # rlogin service (explicit because of pam_rhost_auth) > # > rlogin auth sufficient pam_rhosts_auth.so.1 > rlogin auth requisite pam_authtok_get.so.1 > rlogin auth required pam_dhkeys.so.1 > rlogin auth required pam_unix_cred.so.1 > rlogin auth sufficient pam_unix_auth.so.1 > rlogin auth required pam_ldap.so.1 > # > # rsh service (explicit because of pam_rhost_auth, > # and pam_unix_auth for meaningful pam_setcred) > # > rsh auth sufficient pam_rhosts_auth.so.1 > rsh auth required pam_unix_cred.so.1 > # > # PPP service (explicit because of pam_dial_auth) > # > ppp auth requisite pam_authtok_get.so.1 > ppp auth required pam_dhkeys.so.1 > ppp auth required pam_dial_auth.so.1 > ppp auth sufficient pam_unix_auth.so.1 > ppp auth required pam_ldap.so.1 > # > # Default definitions for Authentication management > # Used when service name is not explicitly mentioned for authentication > # > other auth requisite pam_authtok_get.so.1 > other auth required pam_dhkeys.so.1 > other auth required pam_unix_cred.so.1 > other auth sufficient pam_unix_auth.so.1 > other auth required pam_ldap.so.1 > # > # passwd command (explicit because of a different authentication module) > # > passwd auth sufficient pam_passwd_auth.so.1 > passwd auth required pam_ldap.so.1 > # > # cron service (explicit because of non-usage of pam_roles.so.1) > # > cron account required pam_unix_account.so.1 > # > # Default definition for Account management > # Used when service name is not explicitly mentioned for account management > # > other account requisite pam_roles.so.1 > other account required pam_unix_account.so.1 > # > > > --- George Holbert <gholbert at broadcom.com> wrote: > >> Susan, >> >> What does your PAM password stack look like on the Solaris 10 client? >> -- George >> >> Susan wrote: >> >>> Well, I've gotten authentication working for solaris 10 & FDS. (Thank you, everybody) >>> >>> As root, I can change any user's password and that works. As a regular user, however, no >>> >> luck: >> >>> -bash-3.00$ passwd >>> passwd: Changing password for test >>> passwd: Sorry, wrong passwd >>> Permission denied >>> >>> -bash-3.00$ passwd -r ldap >>> passwd: Changing password for test >>> passwd: Sorry, wrong passwd >>> Permission denied >>> -bash-3.00$ >>> >>> I've this aci: >>> >>> (targetattr="carLicense ||description ||displayName ||facsimileTelephoneNumber ||homePhone >>> ||homePostalAddress ||initials ||jpegPhoto ||labeledURL ||mail ||mobile ||pager ||photo >>> ||postOfficeBox ||postalAddress ||postalCode ||preferredDeliveryMethod ||preferredLanguage >>> ||registeredAddress ||roomNumber ||secretary ||seeAlso ||st ||street ||telephoneNumber >>> ||telexNumber ||title ||userCertificate ||userPassword ||userSMIMECertificate >>> ||x500UniqueIdentifier")(version 3.0; acl "Enable self write for common attributes"; allow >>> >> (write) >> >>> userdn="ldap:///self";;) >>> >>> Doesn't seem to be doing anything, even though userPassword is in there. Btw, in Linux, >>> >> non-root >> >>> users can change their passwords just fine! >>> >>> I've also two of these ACIs which I got from Gary Tay's site: >>> >>> (target="ldap:///dc=company,dc=com";)(targetattr="userPassword")(version 3.0; acl >>> LDAP_Naming_Services_proxy_password_read; allow (compare,search) userdn = >>> "ldap:///cn=proxyagent,ou=profile,dc=company,dc=com";;) >>> >>> (targetattr = >>> >>> > "cn||uid||uidNumber||gidNumber||homeDirectory||shadowLastChange||shadowMin||shadowMax||shadowWarning||shadowInactive||shadowExpire||shadowFlag||memberUid")(version > >>> 3.0; acl LDAP_Naming_Services_deny_write_access;deny (write) userdn = "ldap:///self";;) >>> >>> They seem to doing nothing either, i.e. removing them neither fixes nor breaks anything. >>> >>> Nothing in server/client logs either... >>> >>> Any ideas? >>> >>> __________________________________________________ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.yahoo.com >>> >>> -- >>> Fedora-directory-users mailing list >>> Fedora-directory-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> >>> >>> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> >> > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > >
