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

Admin Article

Article Information

This article applies to the following ZCS versions.

ZCS 8.0 Article ZCS 8.0 ZCS 7.0 Article ZCS 7.0 ZCS 6.0 Article 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.

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.

Unrelated External DN for the user

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
Jump to: navigation, search