Strange LDAP Auth Requirement

[mriedelumb]

Hello!

I work at a university, and we're exploring moving to Zimbra for our student email system.

We have sort of a weird LDAP authentication requirement, that I don't think got across to our sales representatives during the demo, so I'm going to ask the other administrators here if they know whether Zimbra can handle this or not.

OK, here's the scenario:

We assign users email addresses like auser001@domain.edu

However, when a user logs into our email system, they may use any of several "usernames," which may or may not match their email address. For example, auser001@domain.edu may log in with their student ID number, their Library card number or some pre-defined alias (such as "auseratschool").

So, when a user logs in, the LDAP filter will search for any of those attributes, find a DN, and do a successful bind, thus authenticating the user.

Once the user is authenticated, the mail server does a translation and says, "OK, the person who authenticated uses the mailbox auser001@domain.edu"..

From what I can tell, based on Zimbra's default LDAP authentication mechanism, that whatever the LDAP filter searches on has to match a given mailbox name. There doesn't seem to be a way to tell Zimbra, "Authenticate against this attribute, but the user's ID is this attribute."

Has anyone here done anything like this?

Thanks,
Matt

[pacsteel]

I'm not sure I understand quite what you are asking Zimbra to do.

Do you in essence want a user to have multiple user-ids with which to log into Zimbra, but they all really just use the same mailbox/Zimbra account?

For example, do you want it set up so user MikeB@MYU.org can log into Zimbra as CS101MikeB, or LIBIDMikeB or MikeB, but they are all the same account?

If so, then yes Zimbra can do that with no problem using aliases. When an account has aliases, any of the aliases can be used to log into that account.
If authenticating with an external LDAP (Active directory in my case), the actual account owner ID (MikeB@MYU.org in my example) is the one sent to the Active Directory for authentication, no matter which alias logged into Zimbra. Likewise, if using another client (Thunderbird in my case) to search the Zimbra LDAP, using any of the aliases will return the master email address.

[Rich Graves]

Downside of using aliases is that they all become deliverable email addresses, which might lead to information leaks.

I would just say no to student ID and library ID as logins. Arbitrary aliases, fine; use Zimbra aliases.

It should also be possible to allow login with any of those things as username, without exposing them as deliverable email addresses, by putting all of those values in one multivalued attribute on your non-Zimbra LDAP backend. What you can't do is have Zimbra search multiple attributes.

[mriedelumb]

Downside of using aliases is that they all become deliverable email addresses, which might lead to information leaks.

I would just say no to student ID and library ID as logins. Arbitrary aliases, fine; use Zimbra aliases.

It should also be possible to allow login with any of those things as username, without exposing them as deliverable email addresses, by putting all of those values in one multivalued attribute on your non-Zimbra LDAP backend. What you can't do is have Zimbra search multiple attributes.

Yes, mail delivery to a login alias is a deal breaker.

But your scenario is correct- the user user@domain.edu should be able to *log in* (and that's it), with one of several attributes. But once the user is logged in, all reference to the login value should be forgotten, and the server should act like they only have one mailbox.

Furthermore, our users have the ability to change their login name on a whim, whenever they like. So provisioning the aliases will become problematic when the user changes them.

It's a really stupid system, I agree, but I also didn't come up with it. I just have to design something that works in this framework.

Is this something a custom authorization scheme can do?