Regarding the first question:
I've worked with another LDAP system that allowed 'login' against various user attributes. The solution was to do two connections. The first connection, probably anonymously bound, queries LDAP with the user-supplied information to locate the RDN of their user object. The second connection attempts a bind-with-password with the discovered RDN and the supplied password. It's a two step process, and it works.
Though, if this app is going to get a lot of logins with supplied attributes that are not the RDN itself, it'll be a real good idea to index those attributes. It's a performance thing.
Two:
OpenLDAP supports LDAP-SSL so far as I remember (TCP/636), which may be a better route than an HTTPS tunnel. By default LDAP binds are in the clear, but there are LDAP extensions that allow additional methods. Active Directory allows NTLM LDAP-binds for instance, and I'm pretty sure LDAP has been kerberized as well at some point. I don't know what methods openLDAP supports.
Three:
I have LDAP sources that have emails of the "firstname.lastname@org.edu" format in attributes. Where it gets more dicey is with the naming attributes, and that's where my openLDAP experience falls flat. I don't know what it supports for that. I know that Active Directory allows spaces in the naming attributes, and Novell eDirectory allows both spaces and periods (though it isn't recommended to do so). Typically the naming attribute is userID and attributes like givenName, surname, emailAddress, contain the special characters. As they're not naming attributes they don't have the same restrictions.
You need to set AuthLDAPSubGroupDepth
to make this work. The integer you provide here specifies the maximum sub-group nesting depth that will be evaluated before the user search is discontinued.
Add this to your config:
AuthLDAPSubGroupDepth 1
More Info: here and here.
Best Answer