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@xxxxxxxxxxxx> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
