Hello. Finally got some time to pick this discussion back up.
On Wed, 2005-07-27 Benjamin Smee wrote: > Instead I think it is much more secure to simply require an auth bind > BEFORE giving away ANY information, even information as trivial as to > the layout of the DIT or the subtree's etc etc. OK, I understand what you are saying. As far as user authentication goes, RFC 2307bis already describes the schema and organization expected when LDAP is used for a centralized user directory. However, you may be running any number of customizations, etc., so I can see why you might feel the way you do on this issue. I would agree with your earlier characterization that your attitude is more of a paranoid one than most admins have :) . > the changes you made for system-auth in /etc/pam.d/chsh should do it. In system-auth, the changes required are listed (for example) in the Gentoo LDAP guide: http://www.gentoo.org/doc/en/ldap-howto.xml passwd's PAM configuration works as-is with LDAP once system-auth is properly configured, since it seems to stack on system-auth by using "include system-auth" for the auth, account, and password directives. Making sure these "include system-auth" directives are present in the chsh PAM config file does not change the behavior of chsh in that it fails if it does not literally find the user in /etc/passwd . I'm not sure if I'm missing additional trickery that can be done in the PAM config files for chsh or chfn . Additionally, I haven't been able to find the "include" keyword in the PAM docs. > I see, precisely what would your wrapper tools do that would be better > then just invoking ldapX ? You have said that your users are happy on > the unix command line so I am not sure what you are trying to gain via > using wrappers. Do you think it's reasonable to expect Unix users to mess around with LDIF files and syntax, just because they're OK in a command-line environment? I certainly don't. Wrappers could easily be written to emulate the shadow suite utilities, and aside from passing on the additional LDAP password request to the user, an "ldapmodify-wrapped" chsh or chfn would work equivalently from the perspective of the end-user to the Unix counterparts. Aside from the fact "intermediate" level users who know about /etc/passwd might get confused by the fact it has nothing but system accounts on it, novice and advanced users alike should see the system as a standard Unix environment, and aside from the occasional extra password prompt, the fact LDAP is being used should be pretty transparent. > The point is that all of the usual command line tools are NOT LDAP > aware (eg poppasswd_ceti) so that when using auth binds and LDAP the > tool breaks because it gets an extra prompt request. I suppose it depends on what you define as the "usual command line tools" -- I certainly wouldn't consider poppasswd_ceti a usual command-line tool from the perspective of a Unix user. I understand again what you're getting at, but for a Unix user at a command-line, at worst he will see an additional password prompt, or the LDAP string, but it won't require any more information than he already has (namely his login and password). I agree that infratructure built atop the standard command-line tools that deal with /etc/passwd will be likely to break if they assume typical shadow suite behavior. > Even if they do and you are trying to use them in an > automated manner to manage OTHER accounts, then you must keep the auth > bind password somewhere on the system in a file. Again, I refer to my designated "directory manager" user described earlier in this thread. Connecting to the directory as that user is something only root/the sysadmin will have to do to add/remove users or groups or group memberships. This technique keeps the password for that user in the same directory as the user passwords, and not in slapd.conf or similar. Assuming an LDAP-aware replacement for the shadow suite (like the packages I mentioned earlier in this thread), the user will at most get an extra password prompt if he wants to change say, his login shell, since these tools will authenticate to the directory as the user himself and the user will have the ability to write to this attribute via the LDAP ACLs. ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs -- [email protected] mailing list
