Linux Zimbra

Brief Introduction to Zimbra Internal Architecture

In some cases, you might want to recover your data from Zimbra, or you may be curious about how Zimbra manages users and emails behind the scenes.

I dug into Zimbra’s nuts and bolts because we lost Zimbra’s local LDAP, which took more than 3 days to fix, so I wanted to share what I found about this email server with anyone else who might be experiencing the same problem.

Zimbra uses LDAP, MySQL, and file systems to store emails and relate them to users.

Zimbra Uses local LDAP even if you define an external one for authentication. In fact all users in Zimbra have two different id, one id is stored in mysql which is usually starts from 1 and increase sequentially and the other is resides in a local LDAP and the format of id is universally unique identifier (uuid) a randomly generate number.

There is a table in Zimbra’s MySQL called mailbox where database id is mapped to LDAP uuid and usernames are stored in a field called comment.

Now that we understand how MySQL and LDAP are related, let’s examine how meta data of emails is stored in Zimbra.

In Mysql database you’ll find mboxgroup1..mboxgroup100 databases, these are databases that stores metadata according to actuall .msg files stored in /opt/zimbra/store/0/{ID}. In fact these metadata are the ones are show inside webapp or the one shows with IMAP/POP3.

Each user ID in Zimbra is sharded in Mysql, so if a user logs into his mailbox for the first time, Zimbra will record his ID incrementally in Mysql and then divide by 100 to determine which database the user’s ID will be assigned. You can read more about Zimbra database structure here.

Notes for Recovering a Faulty Zimbra:

If you are going to recover a faulty internal LDAP within Zimbra you need to know couple of notes.

  • Order of users are important, if user id in old Zimbra is 1 then the same user’s id in new Zimbra should be 1 as well
  • You might not need internal LDAP since it only saves uuid, you can create new users in LDAP using zmprov ca username@domain password
  • LDAP database resides in /opt/zimbra/data/ldap/mdb/db/ and its size is 80GB
  • You need to recover mboxgroup1 to 100 if you really care about your old data, you can get a backup using Mysql tools inside Zimbra similar to a regular Mysql
    • //You have have to be root user
    • su - zimbra
    • source ~/bin/zmshutil
    • zmsetvars
    • /opt/zimbra/mysql/bin/mysqldump --user=root --password=$mysql_root_password --socket=$mysql_socket \ --all-databases --flush-logs > {dump-file}.sql
  • Also you need to recover the Zimbra database (this database is inside Mysql don’t confuse this name with the actual Zimbra service). You need to copy this database as well. Within Zimbra’s database there is a table called config. Within this table is a field called db.version which keeps track of changes in Zimbra. Make sure this value is the same inside the new Zimbra as it was in the old Zimbra.
  • Actual Email files are in /opt/zimbra/store/0/{ID}. The {ID} is the same as the id inside mailbox table.

Java Linux

How to Create JWT Token Using LDAP and Spring Boot Part 1

If you are working in an enterprise infrastructures, chances are that you are using a centralized authentication system, most likely Active Directory or openLDAP. In this blog I’ll explore how to create a REST API using spring boot to authenticate against openLDAP and create a JWT token in return.

Before getting our hand dirty, we need to review the architecture of spring security and the way we want to utilise it, in a REST API endpoint. According to openLDAP, I’ve explained it’s concept briefly before, you can read more about it here. Also I’ll assume that you know how Spring Boot and JWT works.

Spring Security

In this example I will extend the WebSecurityConfigurerAdapter. This class will assist me to intercept security chain of spring security and insert openLDAP authentication adapter in between.

In fact this abstract class provides convenient methods for configuring spring security configuration using HTTPSecurity object.

First of all I injected three different beans as follows :

   private OpenLdapAuthenticationProvider openLdapAuthenticationProvider;
   private JwtAuthenticationEntryPoint jwtAuthenticationEntryPoint;
   private JwtRequestFilter jwtRequestFilter;

Then override the configure(AuthenticationManagerBuilder auth) :

    protected void configure(AuthenticationManagerBuilder auth) throws Exception {

This will let us to override default behaviour of spring security authentication. In addition we need to override the configure(HttpSecurity httpSecurity):

    protected void configure(HttpSecurity httpSecurity) throws Exception {
        // We don't need CSRF for this example
                // dont authenticate this particular request
                // all other requests need to be authenticated
                // make sure we use stateless session; session won't be used to
                // store user's state.
                // Add a filter to validate the tokens with every request
                httpSecurity.addFilterBefore(jwtRequestFilter, UsernamePasswordAuthenticationFilter.class);

Also For the sake of manually authenticating a user in /api/login we will expose the authenticationManagerBean() :

    public AuthenticationManager authenticationManagerBean() throws Exception {
        return super.authenticationManagerBean();

After configuring WebSecurityConfig, I’ll provide my customer authentication adapter. This adapter will utilise spring’s LdapTemplate and let us to establish a connection to a LDAP server.

public class OpenLdapAuthenticationProvider implements AuthenticationProvider {

    private LdapContextSource contextSource;

    private LdapTemplate ldapTemplate;

    private void initContext() {
// I use anonymous binding so, no need to provide bind user/pass
        ldapTemplate = new LdapTemplate(contextSource);

    public Authentication authenticate(Authentication authentication) throws AuthenticationException {

        Filter filter = new EqualsFilter("uid", authentication.getName());
        Boolean authenticate = ldapTemplate.authenticate(LdapUtils.emptyLdapName(), filter.encode(),
        if (authenticate) {
            List<GrantedAuthority> grantedAuthorities = new ArrayList<>();
            grantedAuthorities.add(new SimpleGrantedAuthority("ROLE_USER"));
            UserDetails userDetails = new User(authentication.getName() ,authentication.getCredentials().toString()
            Authentication auth = new UsernamePasswordAuthenticationToken(userDetails,
                    authentication.getCredentials().toString() , grantedAuthorities);
            return auth;

        } else {
            return null;

    public boolean supports(Class<?> authentication) {
        return authentication.equals(UsernamePasswordAuthenticationToken.class);

Another part that we have to take into consideration is, implementing user login controller. Since we haven’t provided any filter for controlling username and password we ought to implementing it manually as follows :

public class LoginController {

    private AuthenticationManager authenticationManager;

    private JwtTokenUtil jwtTokenUtil;

    private UserService userService;

    public ResponseEntity<?> createAuthenticationToken(@RequestBody JwtRequest authenticationRequest) throws Exception
        authenticate(authenticationRequest.getUsername(), authenticationRequest.getPassword());
        final User userDetails = userService.loadUserByUsername(authenticationRequest.getUsername());
        final String token = jwtTokenUtil.generateToken(userDetails);
        return ResponseEntity.ok(new JwtResponse(token));

    private void authenticate(String username, String password) throws Exception {
        try {
            authenticationManager.authenticate(new UsernamePasswordAuthenticationToken(username, password));
        } catch (DisabledException e) {
            throw new Exception("USER_DISABLED", e);
        } catch (BadCredentialsException e) {
            throw new Exception("INVALID_CREDENTIALS", e);

These are the pillars of having a REST API + JWT + LDAP back-end using spring boot.

Now we can test the API using a REST client.

After getting the JWT token we can call authorized endpoints

You can find a working source code on my github.

For the next part I’ll make this code more concise.

Java Linux

How to Authenticate Against openLDAP Without Knowing DN Using java

In fact you can’t do it without knowing DN! There is an anonymous access in openLDAP which is enabled by default. The anonymous access let one to query(search filter) openLDAP without knowing bind username/password.

Run following command on your openLDAP server :

ldapwhoami -H ldap:// -x

If you get “anonymous” as result you are all set and your openLDAP is supporting anonymous query, otherwise this blog is not the one you are looking for!

So What’s the Deal?

Assume you know UID of the user in ldap directory but not his DN and assume the root directory hierarchy is : dc=devcrutch,dc=com . How do you want to get CN and then DN of such user in LDAP just by using UID? you might think of such query to get data out of openLDAP


If you run this query, it’ll get you to nowhere.

Here Comes the Anonymous Query

First of all you have to query the whole directory for finding such user. You have to create a query similar to following:


This query will search the entire Directory Information Tree (DIT) for such user name.

ldapsearch -x -h -b dc=devcrutch,dc=com "(&(objectClass=*)(uid=USERNAME))"

With such query you can get the DN. Using DN and password you can authenticate against LDAP.

Well this was the idea, applying a search filter using USERNAME via anonymous identity then find the DN and finally login using the retrieved DN.

Time for Some java

Now we have the rough idea it’s time to implement it in java. For finding DN you need to query the entire LDAP directory (note: in real world searching the entire directory is not a good idea, you have to narrow your query, otherwise your query might consume all the server’s resources)

private String findDN(String user) throws Exception {
    DirContext ctx = getContext();
    String dn = null;
    String filter = "(&(objectClass=*)(uid=" + user + "))";
    NamingEnumeration answer ="", filter, getSimpleSearchControls());
    if (answer.hasMore()) {
        SearchResult result = (SearchResult);
        dn = result.getNameInNamespace();
    return dn;

Then after finding the correct DN you can bind your username and password

public DirContext bind(String username, String password) throws Exception {
        DirContext dirContext;
        Hashtable<String, String> env = new Hashtable<String, String>();
        String dn = findDN(username);
        env.put(Context.SECURITY_AUTHENTICATION, "simple");
        env.put(Context.SECURITY_PRINCIPAL, dn);
        env.put(Context.SECURITY_CREDENTIALS, password);
        try {
            dirContext = getContext(env);
        } catch (javax.naming.AuthenticationException e) {
            throw new Exception(e);
        return dirContext;

That’s it.

You can find a working source code on my github


Installing openLDAP and Making it Replicable

OpenLDAP installation is fairly straight-forward and doesn’t have any caveats, but making it replicable has ambiguity. We will start with installing openLDAP. I will use following configs :

  • ubuntu 16.04 server
  • openLDAP 2.4.x
  • phpLDAPadmin

Installing openLDAP :

First thing first, update your ubuntu box :

sudo apt-get update

Install openLDAP :

sudo apt-get install slapd ldap-utils

During installation process you will prompted to enter administrator password. After installing the ldap server you need to configure it :

sudo dpkg-reconfigure slapd

You will see a basic gui with couple of prompts of how to configuring your openLDAP here is my config:

  • Omit openLDAP Server Configuration : No
  • DNS Domain : your domain in my case,
  • Organization Name : whatever you fancy, lab
  • Database : MDB (It’s an in-memory database based on BerkeleyDB. In case you were curious)
  • Remove Database when openLDAP is Removed : No
  • Move Old Database : Yes
  • Allow LDAP2 : No

That’s it, if you ever want to check status of your openLDAP :

ldapwhoami -H ldap:// -W -D "cn=admin,dc=lab,dc=devcrutch,dc=com"

This command will prompt you to enter your password and if you enter it correctly you will get following response :


You are all set to use openLDAP. Now let’s add an user for replication purposes inside provider (master) node. The replication user only needs to have a password and an OU, run following commands to add repl user with only a password

dn: cn=repl,dc=lab,dc=devcrutch,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: repl
userPassword: {SSHA}Px1UjD+3EMII0g+JZBdZkdO6lhZt4j4k
#password is abc123

Save the above file in an LDIF file and run following command. I will call this file add_repl.ldif

ldapadd -Y EXTERNAL -H ldapi:// -f add_repl.ldif

This user needs to have a privilege to only read couple of items from directory, the most important items to read, is userPassword, cn, uid and shadowLastChange. But before granting such access there is an issue with openLDAP’s configs that shipped by Ubuntu 16.04. It is best to remove those configs using following command :

#Run ldapsearch -Y EXTERNAL -H ldapi:// -b "cn=config"

#Not approapriate configs for making your openLDAP replicable
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read

For deleting them run:

ldapmodify -Y EXTERNAL -H ldapi://

In the prompt write following lines one by one (this way you will delete them step by step for the sake of not getting any error)

dn: olcDatabase={1}mdb,cn=config 
changetype: modify
delete: olcAccess
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
#press enter
dn: olcDatabase={1}mdb,cn=config 
changetype: modify
delete: olcAccess
olcAccess: {0}to attrs=shadowLastChange by self write by * read
#press enter
dn: olcDatabase={1}mdb,cn=config 
changetype: modify
delete: olcAccess
olcAccess: {0}to * by * read
#Press ctrl-d at the end

And add following configs :

#Execute ldapmodify -Y EXTERNAL -H ldapi://
#Then write these configs in it, at end press ctrl-d
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=lab,dc=devcrutch,dc=com" write by dn="cn=repl,dc=lab,dc=devcrutch,dc=com" read by * none
#press enter
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {1}to dn.base="" by * read
#press enter
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {2}to * by self write by dn="cn=admin,dc=lab,dc=devcrutch,dc=com" write by * read

Now your provider is ready. We will go to consumer server. First of all install openLDAP using mentioned configs, it should be the same as the master. At the end add following configs into your consumer’s openLDAP :

#run ldapmodify -Y EXTERNAL -H ldapi://
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID eq
#press enter
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryCSN eq
#press enter
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: ou eq
#press enter
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: uid eq
#press enter
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: cn eq
#press enter
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: dc eq
#press enter
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: rid=001 provider="ldap://YOUR_MASTER_IP_ADDRESS:389/" type=refreshAndPersist retry="60 30 300 +" searchbase="dc=lab,dc=devcrutch,dc=com" bindmethod=simple binddn="cn=repl,dc=lab,dc=devcrutch,dc=com" credentials="abc123"

The reason I separate configs is because of stupidity level of ldap tools. If you happen to have one of these configs inside your openLDAP previously, the ldapmodify nags about it and will kick you out without knowing which config is saved and which one isn’t, so the best way for me was saving them sequentially.

Reason for having another user rather the “cn=admin” was because of  security, if you take a closer look at the latter config you will see that you have to add your password as a plain text. So it’s best to not to reveal your admin’s password. The repl user is a readonly user.

At the end you can install phpOpenLDAP in provider and consumer :

sudo apt-get install phpldapadmin

Edit below config :

sudo vim /etc/phpldapadmin/config.php

Change the following :

Find the line contains


Change it to


And another line contains


Change it to


Note: In this tutorial I’ve tried to create a replication server, replication doesn’t mean you have availability, which means if your master(provider) server is down then your client querys the slave(consumer) server. Replication means consistency not availability. If you happen to want availability you need to config openLDAP in multi-master mode.