Looks to be the case.... check out page 43: http://images.apple.com/server/pdfs/Open_Directory_v10.4.pdf
I'd try: nss_map_attribute userPassword ApplePasswordServer in /etc/ldap.conf "just for kicks"... you may end up needing to switch to pam_krb5 and forgetting about password attributes all together =\ -s On Dec 3, 2007 7:07 PM, Edward Ned Harvey <[EMAIL PROTECTED]> wrote: > > ldapsearch -h ldapserver -b "dc=your,dc=base" -D > > "cn=someuser,ou=People,dc=your,dc=base" "(objectClass=*)" dn -w pass1 > > ldapsearch -h ldapserver -b "dc=your,dc=base" -D > > "cn=someuser,ou=People,dc=your,dc=base" "(objectClass=*)" dn -w pass2 > > ldapsearch -h ldapserver -b "dc=your,dc=base" -D > > "cn=someuser,ou=People,dc=your,dc=base" "(objectClass=*)" dn -w pass3 > > Thank you very much for this. It works for pass1, it doesn't work for pass2 > or pass3. > > I therefore must conclude that the original password, pass1, is still the > "important" password in the ldap server. However, I've already proven that > if I change password on clienta, the new password is also usable on clientb. > So the "passwd" operation must be succeeding in changing one of the hashes, > and failing to change some other hash. > > I can only think of 2 possible causes for that: > (a) There's a difference between expected ldap structures (schema?) in linux > & mac. So the linux client updates some hash, and doesn't bother trying to > update the one the mac cares about. > Or > (b) The "passwd" operation isn't atomic (succeeds to update one hash, fails > to update another) > > I'm out of time for today, will have to come back to this later. > > > _______________________________________________ > bblisa mailing list > [email protected] > http://www.bblisa.org/mailman/listinfo/bblisa > _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
