Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Connect Multi-Server » Planning what we are in for (if we implement multiserver)
  •  
Bud Durland

Messages: 371
Karma: 39
Send a private message to this user
I believe that we are a candidate for migrating to Kerio Connect Multi-Server (KC-MS, because I'm a lazy typist). We currently have 3 sites, with Kerio Connect hosted on Windows at the main site supporting about 300 users, with a message store just shy of 1 TB. Seems like we would reap some benefit from KC-MS. I've been studying http://kb.kerio.com/1667, and doing some "what if?" planning.

Some Background:
- all KC users are stored in the local database, no directory service is configured.
- each of the three sites has it's own AD domain, and there are no plans to change that
- we have redundant VPNs to each of the sites

Obviously, we would deploy a backend server at each site, and roll users to the appropriate backend server. This actually seems pretty straight forward. Clients are configured to connect to the Front End server, which then sends them to their home server. Is that done as a proxy process? 90% of my users are employing Outlook with the Kerio off-line connector. So if I have a user connecting with outlook from Atlanta, and the front end server is in Plattsburgh, and his home server is in Cleveland, how is the connection made?

It also sounds like the front-end server could be a single point of failure. Can I have multiple front end servers and use round-robin DNS to make sure everybody finds at least one of them?

KC-MS requires the use of a directory service such as AD. I presume that all the KC-MS Directory Server does is connect to the directory services (in this case, an Active Directory domain controller). All of my users will have to be converted from the local user database to a directory service. Can each of the planned back-end servers use a different directory service configuration? It seems that the transition will be easier if I move all my users to being directory service based first, before migrating to KC-MS. It is impractical for me to do all the users at once -- is this migration something that can be done in small groups of people?

My migration scenario is specifically mentioned in KB1667, and references mapping my users from an OpenLDAP server. Where's that?

We have our own Zabbix & syslog servers. Can we use them?

[Updated on: Fri, 19 June 2015 14:31]

  •  
nate.keegan

Messages: 46
Karma: 0
Send a private message to this user
From what I understand the Front-End system is both a proxy and a session server. If you have multiple Front-End systems one of the systems (first installed I believe) is the session server.

The other Front-End systems would reference the session information on the session server.

If the session server is restarted, services restarted, etc authenticated clients would need to login again to Kerio. In the case of KOFF/Kerio Connector I would suspect that any client authentication would be transparent to the user if they have already saved their credentials.

If one were truly paranoid the question would be how to move the session server over to another Front-End system if the system hosting the Front-End is currently down or unavailable. I would imagine there is a mechanism for this, haven't gotten that far yet in our testing.

In theory RR DNS would work for this purpose although a L4 load balancer might be cleaner as RR DNS cannot handle the failure of a Front-End system (outage, maintenance, etc) while a load balancer can.

With a load balancer you would use one or more virtual IP/DNS names and then map those, in the load balancer, to the back-end systems.

Under that type of a setup you could have a VIP for each site - kerio-atlanta.foo.com, kerio-plattsburgh.foo.com, and kerio-cleveland.foo.com - with the same or different Kerio Front-End servers in the load balancer farm or pool.

You could also just go for a single VIP name like 'kerio.foo.com' and do the same mapping if everyone is using the same Front-End servers.

Users hit the VIP for POP, IMAP, SMTP inbound, HTTP, etc and wouldn't need to know what the name of their Back-End server is. With some health checks it would be easy to have the LB bypass a Front-End which is no longer handling say SMTP or POP.

That is the operational theory, still working on the final testing of this in our lab.

I don't see an issue with using your own Syslog server. We plan on doing this since we already have centralized Syslog setup on our network.

Our plan is to lab out the Zabbix installation and then plunder the Zabbix role server to find the Kerio template used and import that into our own Zabbix installation if that makes sense.

I'm still working through what parts of Kerio Multi-Server use say Active Directory vs local directory. I suspect that with Kerberos authentication enabled my users will be able to use their Windows credentials and the Back-End systems will be able to pull AD attributes from our AD servers via the AD connector. Kerio specific attributes would be stored in the Kerio directory server.
  •  
nate.keegan

Messages: 46
Karma: 0
Send a private message to this user
If you PM me I can shoot you an image that Kerio support sent over which shows the multiple Front-End relationship in a nice pretty way
  •  
Stepan Potys (Kerio)

Messages: 86
Karma: 2
Send a private message to this user
Hello Bud,

Quote:
Obviously, we would deploy a backend server at each site, and roll users to the appropriate backend server. This actually seems pretty straight forward. Clients are configured to connect to the Front End server, which then sends them to their home server. Is that done as a proxy process? 90% of my users are employing Outlook with the Kerio off-line connector. So if I have a user connecting with outlook from Atlanta, and the front end server is in Plattsburgh, and his home server is in Cleveland, how is the connection made?

The front-end server is a kind of reverse proxy so your connection and it's every request goes from Atlanta via Plattsburgh to Cleveland and the response goes back to Plattsburgh before it finally reaches Atlanta.

Quote:
It also sounds like the front-end server could be a single point of failure. Can I have multiple front end servers and use round-robin DNS to make sure everybody finds at least one of them?

Yes, you can have multiple front-ends.

Quote:
KC-MS requires the use of a directory service such as AD. I presume that all the KC-MS Directory Server does is connect to the directory services (in this case, an Active Directory domain controller). All of my users will have to be converted from the local user database to a directory service. Can each of the planned back-end servers use a different directory service configuration? It seems that the transition will be easier if I move all my users to being directory service based first, before migrating to KC-MS. It is impractical for me to do all the users at once -- is this migration something that can be done in small groups of people?

My migration scenario is specifically mentioned in KB1667, and references mapping my users from an OpenLDAP server. Where's that?

OpenLDAP is a part of multi-server deployment (the directory role). You can prepare your multi-server environment containing the directory, and migrate users in small groups.

Quote:
We have our own Zabbix & syslog servers. Can we use them?

If you already have a monitoring system you can use it of course. There is no specific binding to the Kerio Zabbix monitoring. As you're probably familiar with zabbix you can install zabbix client on every node yourself and configure it to report to your zabbix server.

Stepan Potys
Connect Core team leader
Kerio Technologies
  •  
Bud Durland

Messages: 371
Karma: 39
Send a private message to this user
Quote:
OpenLDAP is a part of multi-server deployment (the directory role). You can prepare your multi-server environment containing the directory, and migrate users in small groups.


I hope I'm not being dense here, because I'm still not quite getting it. Here's how I think I understand what you've said:

The Multi-Server 'Directory Server' is where OpenLDAP is actually running. It is configured to use my Active Directory domain controller to validate user identities. User names and credentials are not configured directly on the the Multi-Server 'Directory Server'.

I'm still not clear on the best practice for when to convert my existing 'local database' users to authenticate against the directory. Do I upgrade my 'stand-alone' 8.4.3 server to 8.5 first, then convert the users to authenticate against active directory, then deploy multi-server?

Or do I deploy a new multi-server infrastructure, then join the 8.4.3 server to it as a 'distributed domain' and convert the users to active directory authentication small batches?
  •  
Pavel Stepanek (Kerio)

Messages: 29
Karma: 0
Send a private message to this user
Dear Nate,

Kerio Multiserver has the same demand for the directory server as the Distributed domain setup had. You need to have Directory server, which hold all the users. So you can not simply bind the user to local AD which is local to one of the sites.

The reason for this is that all the Backend servers use the Directory server to find each user's home server. If you have only limited user list within the directory server, backend does not know where to point the user request if it is not based on this directory server.

From my point of view and as far as I understand your setup so far, you might need to move your Kerio Connect users to either the Multi-Server Directory Server or the Active Directory server. This way you can have a single user directory. Drawback of this is that the Directory server is single point of failure for other servers for which it is not in local site. Migration to this server would be possible through the export of users and building the LDIF import file for the OpenLDAP directory server. You will loose passwords during this transition.


Better solution would be to consolidate the directory servers and you can benefit from Active Directory replication feature. This means either move all user to one domain and use eg. Organzatinal Units (OUs) to distinguish between each office / site. Local passwords will be lost, but you'll be able to use Active Directory credentials to log in (including password policy deployed for you Active Directory servers).

I understand that each option has different demands and may not fit exactly your needs. Personally I would recommend you the option with Active Directory server, as replicas can help you mitigate directory server single point of failure for your backend nodes. And it can be also backup AD for your site in case of failure. Moreover you will utilize existing environment you already use and you might benefit from AD login and single identity management point.


It seems there are more transition steps in your current setup. First one we need to solve is the Directory Server requirement and how to migrate users to the directory server. Could you let me know which option is preferred one for you please?
  •  
Bud Durland

Messages: 371
Karma: 39
Send a private message to this user
Pavel;

Thank you for the detailed explanation. I've begun to think that I misunderstood a key concept. Is it required that the Multi-Server Directory Server be connected to my Active Directory server, or can the Multi-Server Directory Server be run "stand alone"?

This will definitely influence how I decide to go forward.
  •  
Pavel Stepanek (Kerio)

Messages: 29
Karma: 0
Send a private message to this user
It is either A or B:

A)

MultiServer Directory Server, which is not integrated with Active Directory. You can add users according to the KB article from the Kerio Connect Admin interface. The import from AD is not available in GUI, but it is possible using few scripts (you can export your users from AD to an LDIF file, adopt the LDIF file for the OpenLDAP in the MultiServer Directory server and import it. Passwords can not be obviously migrated.

B)

You can use Active Directory for your user definitions. The Active Directory server must have all the user definitions for all the back-end servers.

Note: The MultiServer Directory role is required in any case. It is used as a caching server for back-end servers even it is not used for user mapping. It needs to be installed and available for backend servers as it is a requirement for access to shared folders on all the servers in the MultiServer setup.

[Updated on: Tue, 16 June 2015 20:45]

  •  
nate.keegan

Messages: 46
Karma: 0
Send a private message to this user
Sorry to pop in here but we are wrangling with a similar issue as far as figuring out the relationship of MultiServer Directory and AD in the previous post.

A is pretty clear - no AD, just MultiServer Directory

For B I understand that we install MultiServer Directory for internal use by the MultiServer roles, however, I'm assuming, and figured I would ask, that integration of AD users to Kerio and Kerberos authentication would be just like it is with a single server Kerio Connect installation meaning the same process using the AD connector to pull in AD user information and then setup Kerberos authentication on the Kerio server so that users can use their Windows credentials to login to Kerio.

Is that a correct statement with regard to option B?

I have this on our punchlist to test but haven't gotten that far yet.
  •  
Pavel Stepanek (Kerio)

Messages: 29
Karma: 0
Send a private message to this user
Yes, it is correct statement. There is no difference between MultiServer AD mapping and current single server setup and directory mapping. You just need to set correctly Directory Mapping tab on all backends and set the Kerberos in Advanced settings ( in case of MultiServer Appliance / linux Appliance you need to install kerberos packages according to the Debain appliance guide - http://kb.kerio.com/784).
  •  
nate.keegan

Messages: 46
Karma: 0
Send a private message to this user
Thank you, very useful information.
  •  
nate.keegan

Messages: 46
Karma: 0
Send a private message to this user
  •  
Bhardwaj

Messages: 8

Karma: 0
Send a private message to this user
Hi,

I have three kerio multi backend server i.e backend-1, backend-2 and backend-3 and create some users on these all server i.e abc@vinod.com is hosted on my backend-1 server, def@vinod.com hosted on my backend-2 server and ghi@vinod.com hosted on my backend-3 server my question is if hardware of my backend-1 server has failed in this condition how can access user mail of my user abc<_at_>vinod.com or other user's mail which was hosted on backend-1 server.


Thanks
Vinod

Vinod Bhardwaj
  •  
Sam Cizkovsky (Kerio)

Messages: 27
Karma: 0
Send a private message to this user
Hi Vinod,
If hardware fails on any backend then you have to go through standard recovery scenarios depending on what happened.

First backend is master backend and it is mandatory for other backends - it enables connection between front-end and other backends. So if hardware fails on master backend, front-end is not able to recieve messages nor users can login through front-end to Kerio Connect Client.

Samuel Čížkovský
QA Engineer | Kerio
Stay Connected Anytime, Anywhere. Discover Kerio Cloud!
Bhardwaj

Messages: 8

Karma: 0
Send a private message to this user
Hi,

First backend is master backend and it is mandatory for other backends - it enables connection between front-end and other backends. So if hardware fails on master backend, front-end is not able to recieve messages nor users can login through front-end to Kerio Connect Client.


My question is when first backend server has failed can we setup another backend server as master backend i.e if my backend-1 server has failed can i setup my backend-2 as a master if yes then how we can.


Vinod Bhardwaj
Previous Topic: Installation stalls
Next Topic: Migration fails "Failed (Error initializing MigrationDownloader)"
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Fri Apr 28 12:14:57 CEST 2017

Total time taken to generate the page: 0.08136 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.