It looks like you're missing a password stack in your /etc/pam.conf.
I think you got the example pam.conf here:
...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(a)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(a)redhat.com
>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>>
>>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users