Mgolfieri Provisioning with a username unrelated to any email address: Difference between revisions
mNo edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
{{Article Infobox|{{admin}}|{{ZCS 8.0}}|{{ZCS 7.0}}|{{ZCS 6.0}}||}}=Disclaimer= | {{Archive}}{{Unsupported}}{{Article Infobox|{{admin}}|{{ZCS 8.0}}|{{ZCS 7.0}}|{{ZCS 6.0}}||}}=Disclaimer= | ||
'''The following steps are NOT supported, this is a community-driven workaround. You can rely on the zimbra forums to ask for help. | '''The following steps are NOT supported, this is a community-driven workaround. You can rely on the zimbra forums to ask for help. | ||
''' | ''' |
Revision as of 11:09, 30 March 2015
Article Information |
---|
This article applies to the following ZCS versions. |
Disclaimer
The following steps are NOT supported, this is a community-driven workaround. You can rely on the zimbra forums to ask for help.
Description
This article describes how to allow log into Zimbra by using an username totally unrelated to real email addresses connected to the account.
Root cause
At the moment Zimbra accounts are tightly connected to their email addresses. Any login inserted when authenticating has to be part of a email address. This is true even if we then rely on external directories for authentication.
The following bug would avoid this whole workaround by introducing an extra field in LDAP: Bug 19561: Auth using login ID
Scenario
As an example (you will need to change domain to the domain name you need), assuming we need to plan the provisioning for a whole company, a sample user has the following details:
First, Last: John Ryan
Main email address: john.ryan@domain.com
Alias email address: jryan@domain.com
Domain username: 001234
Login for the user: 001234
Domains and User provisioning
NOTICE: From now on, every command has to be run as the zimbra user]
If not in place already, the Domain should be created first. From the CLI, this can be done via:
zmprov cd domain.com
We now create an unroutable domain, which will host our usernames:
zmprov cd domain.local
Then we need to make this unroutable domain the default domain so that when users log into the webmail, the authentication form will then assume that the username will be looked into this domain by default.
zmprov mcf zimbraDefaultDomainName domain.local
The user should then be created as follow:
zmprov ca john.ryan@domain.com password # Real email address, it will act as the main username as well. This is very important, otherwise many other issues might arise. zmprov aaa john.ryan@domain.com jryan@domain.com # (optional) Alias email address for legacy reasons. zmprov aaa john.ryan@domain.com 001234@domain.local # Alias email address to host the username part we need. We'll then see how to remove it from anywhere in Zimbra to avoid its usage in production.
Optionally, if external authentication for the domain was configured against AD or LDAP and the entry isn't related in any way to the zimbra account name john.ryan@domain.com, we can set zimbraAuthLdapExternalDn on the account to contain the direct reference to the full DN of the user on the directory service we are relying on for authentication:
zmprov ma zimbraAuthLdapExternalDn "CN= jr032342,OU=Students,DC=University,DC=COM # Full DN of the user in AD
Or, another example, in case of an external LDAP directory:
zmprov ma zimbraAuthLdapExternalDn "cn=jr032342, ou=people,dc=example,dc=com" # Full DN of the user in LDAP
Removing the username alias from the ZCS webclient
At this point we'll now see though that if we go in Preferences->Accounts we can still set the alias 001234@domain.local, which is obviosly a problem. To avoid users to set it for their account we need to patch the code so that the unroutable address is not shown. The following don't contain line numbers, since they might vary from release to release. It is therefore necessary human intervention to apply such changes. Again, the following are unsupported changes, please proceed at your own risk. Furthermore, the changes will be lost from upgrade to upgrade, it will be required to manually reapply the changes once the standard upgrade procedure is over
Advanced interface (AJAX)
Use your favorite editor to patch the JS code by opening /opt/zimbra/jetty/webapps/zimbra/js/zimbraMail/mail/view/prefs/ZmAccountsPage.js. Find the following section:
ZmAccountsPage.prototype._getAllAddresses = function() { var username = appCtxt.get(ZmSetting.USERNAME); var addresses = appCtxt.get(ZmSetting.ALLOW_FROM_ADDRESSES); var aliases = appCtxt.get(ZmSetting.MAIL_ALIASES); return [].concat(username, addresses, aliases); };
Now add the following code highlighted in Bold (MG prefix is to avoid any namespace clashing, Javascript does not have the concept of scoping and visibility as -for example- OOP languages):
ZmAccountsPage.prototype._getAllAddresses = function() { var username = appCtxt.get(ZmSetting.USERNAME); var addresses = appCtxt.get(ZmSetting.ALLOW_FROM_ADDRESSES); var aliases = appCtxt.get(ZmSetting.MAIL_ALIASES); var MGpattern = /local$/; for (var i = 0; i < aliases.length;) { if (MGpattern.test(aliases[i])) { aliases.splice(i, 1); } else { i += 1; } } return [].concat(username, addresses, aliases); };
You can check that everything is working by appending ?dev=1 to the URL (Refer to: http://wiki.zimbra.com/wiki/Web_Client_URL_Tricks for more information).
Once it's verified that the code patching works fine, to make the change visible to everybody without the need of appending ?dev=1, we need to repackage the optimized java code within Zimbra .zgz files. Please refer to http://wiki.zimbra.com/wiki/How_to_modify_JAVASCRIPT_used_by_Zimbra%3F for further information on how to achieve this. The file you need to repackage is /opt/zimbra/jetty/webapps/zimbra/js/Preferences_all.js.zgz. Following the said wiki, find the following source code section and insert the part in Bold:
ZmAccountsPage.prototype._getAllAddresses=function(){ var a=appCtxt.get(ZmSetting.USERNAME); var t=appCtxt.get(ZmSetting.ALLOW_FROM_ADDRESSES); var e=appCtxt.get(ZmSetting.MAIL_ALIASES); var MGpattern = /local$/; for (var mgi = 0; mgi < e.length;) { if (MGpattern.test(e[mgi])) { e.splice(mgi, 1); } else { mgi += 1; } } return[].concat(a,t,e) };
Once done, repackaging is required as per the wiki instructions referred above.
Standard interface (HTML)
Use your favorite editor to patch the code by opening /opt/zimbra/jetty/webapps/zimbra/WEB-INF/tags/options/optAccounts.tag so that you can insert the following changes highlighted in Bold:
<select name="zimbraPrefFromAddress"> <c:set var="fromAddr" value="${fn:toLowerCase(mailbox.defaultIdentity.fromAddress)}"/> <c:forEach var="address" items="${mailbox.accountInfo.emailAddresses}"> <c:if test="${not fn:endsWith(address,'local')}"> <option <c:if test="${fn:toLowerCase(address) eq fromAddr}"> selected</c:if> value="${fn:escapeXml(address)}"> ${fn:escapeXml(address)} </option> </c:if> </c:forEach> </select>
Now a restart of mailboxd is required to apply:
su - zimbra zmmailboxdctl restart
Blocking the unroutable address at the MTA level
To minimize chances of having these addresses slipping through the system, the following change can be done in the MTAs.
To do so, reconfigure postfix header checks on all MTA servers. We need to append two lines to /opt/zimbra/conf/postfix_header_checks.in:
/^To:.*?@domain\.local.*/i REJECT /^From:.*?@domain\.local.*/i REJECT
Modify /opt/zimbra/conf/zmmta.cf, you need to find the following section:
if VAR zimbraMtaBlockedExtensionWarnRecipient POSTCONF header_checks fi
This section resets header checks when amavis is used to filter certain types of attachments. We need to comment these lines so that the postfix_header_checks (generated from postfix_header_checks.in) will be applied. At this point, comment the code, so that it will look as the following:
#if VAR zimbraMtaBlockedExtensionWarnRecipient # POSTCONF header_checks #fi
Now we need to restart the MTAs (so that rewriting takes place):
su - zimbra zmmtactl restart