site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com The manifestation of this is that you can't log in to the GUI whilst authenticating against an LDAP server whose user accounts have passwords stored in SHA-1 hashes, but you can log in using ssh (and possibly other stuff). -Jason _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On May 27, 2005, at 7:21 PM, Michael Bartosh wrote: On May 20, 2005, at 3:12 PM, Finlay Dobbie wrote: Don't map the password attribute in the LDAPv3 Plug-in. DirectoryService will perform an LDAP bind to authent the user. iirc it will to aCRAM-MD5 bind if the server is capable. If I were you I'd disable clear-text binds. Or use ssl. At any rate giving the OS access to the hashes is a bad idea, since someone could brute force them. Still, Finlay has a good point that more hash types should be supported. Not mapping the Password attribute is the appropriate workaround, but really the LDAP plug-in should be updated to deal with all the common hash types. While doing a secure authentication is certainly preferable, if a password hash is readable then it should be used rather than doing a cleartext bind. Login Window is intentionally using a different authentication method here, but I believe the problem is that when a hash is found it (which is not understood by the plug-in) it is not returning the appropriate eDSAuthFailedClearTextOnly which indicates that login can proceed. A secondary authentication will allow cleartext if the initial one is not a failure. This email sent to site_archiver@lists.apple.com