| Planning what we are in for [message #121645] |
Thu, 28 May 2015 22:31  |
Bud Durland
Messages: 588
Registered: December 2013
Location: Plattsburgh, NY
|
|
|
|
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] Report message to a moderator |
|
|
|
| Re: Planning what we are in for [message #121901 is a reply to message #121645] |
Tue, 09 June 2015 21:43  |
nate.keegan
Messages: 46
Registered: June 2015
|
|
|
|
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.
|
|
|
|
|
|
| Re: Planning what we are in for [message #121973 is a reply to message #121645] |
Fri, 12 June 2015 07:39 |
Stepan Potys (Kerio)
Messages: 34
Registered: April 2010
|
|
|
|
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
|
|
|
|
| Re: Planning what we are in for [message #121992 is a reply to message #121973] |
Fri, 12 June 2015 22:47 |
Bud Durland
Messages: 588
Registered: December 2013
Location: Plattsburgh, NY
|
|
|
|
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?
|
|
|
|
| Re: Planning what we are in for [message #122072 is a reply to message #121992] |
Tue, 16 June 2015 19:27 |
 |
Pavel Stepanek (Kerio)
Messages: 17
Registered: January 2005
Location: Kerio Technologies
|
|
|
|
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?
|
|
|
|
| Re: Planning what we are in for [message #122075 is a reply to message #122072] |
Tue, 16 June 2015 19:42 |
Bud Durland
Messages: 588
Registered: December 2013
Location: Plattsburgh, NY
|
|
|
|
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.
|
|
|
|
|
|
| Re: Planning what we are in for [message #122079 is a reply to message #122078] |
Tue, 16 June 2015 20:53 |
nate.keegan
Messages: 46
Registered: June 2015
|
|
|
|
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.
|
|
|
|
| Re: Planning what we are in for [message #122089 is a reply to message #121645] |
Wed, 17 June 2015 01:20 |
|
Pavel Stepanek (Kerio)
Messages: 17
Registered: January 2005
Location: Kerio Technologies
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Members
Search
Help
Register
Login
Home
