On Mon, 2009-11-16 at 20:21 -0500, Brian J. Murrell wrote: > On Tue, 2009-11-17 at 01:01 +0100, Jakub Hrozek wrote: > > Per the discussion on sssd-devel list, nss_sss should not return a > > hardcoded value but this should rather be configurable to allow whatever > > the OS or distribution thinks is the best for the particular case. > > I disagree with the nature of this fix. The decision as to what to > return in the password field of the passwd map is not really a > per-distribution issue. Even within the same distribution, different > configurations should have different results and altering the > configuration will change the results. > > With regard to the "x" as the password field, the rules/conditions are > quite clear. If there is shadow information available for the account, > the password field should be set to an "x". > > So in the case of an /etc/passwd and /etc/shadow, the password field > in /etc/passwd should be "x" and sssd should return that if it were > proxying for /etc/passwd (which I'm not even sure if it does). > > In the case of LDAP, if the entry for the user had shadow information > available (i.e. it has the shadowAccount object class in the entry) then > the password field should be returned as "x" and if it does NOT have > that object class, then the password field should return something else. > Probably, if the ldap entry has an otherwise viable password entry, it > should be returned, but if it does not, returning "*" seems to be > acceptable given that if the LDAP entry does not have a password, then > something else (i.e. kerberos) will be getting used. > > So as you can see what to return is much more local configuration > dependent than distro-policy. > > One could argue that the sysadmin should set the value to be returned to > something reasonable for his configuration, but what about a mixed mode > even, where some users are authenticated out of LDAP and some out of > kerberos? Then even a single configuration item is not possible.
We don't support shadow maps so we never return shadow information currently. So I don't see the need for this to be conditional at this stage. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel