Forti EMS on non-domain server

[skyegool]

Hi,

We're planing on puting Forti EMS in DMZ, so clients can pick up telemetry from public.

Does Forti EMS server needs to be domain joined machine or we can just connect it via LDAP(S) with AD?

Forti EMS will also comunicate with Fortigates for ZTNA tag collection

I was looking official docs, all I can find is that EMS cant be installed on DC

Thanks

[fcb · Accepted solution]

You can run it as not part of the domain, sure, but under the direction of Fortinet Support, we have it joined our to the domain and have it in a DMZ and are just tightly controlling the allowed ports between EMS and the rest of the non-DMZ network. We are using split DNS (I think that's the correct term) where we have A records for ems.domain.com on the outside and on the inside. This way if a client comes "on-net" they can communicate and do what they need to do and if they go "off-net" the hostname is resolvable and hits a VIP that translates TCP.8013 to the DMZ server.

If you don't want to join the domain, I'm sure you can since deployment has a place to specify credentials when it's time to install/upgrade. The "domain" section is nothing more than an LDAP bind over to a DC so no need there but I can tell you that from our EMS server to our internal network still only requires a handful of ports and would be one less if we were NOT part of the domain and having to use the domains DNS servers. If you have a Fortianalyzer (a must have if you have Fortigates or FortiClients or FortiAnything to be honest) will be VERY easy to get the port requirements that you need exactly for your domain/setup but below are what EMS requires at a minimum.

A lot of this will depend on how you will install to an endpoint that has never had FTC installed on it before or in other words how you will "deploy" it. Once the initial FortiClient installation has been completed (installed for the the first time) it will from that point forward use TCP.8013 for EVERYTHING that it needs to do when interacting from Server to client (which it really doesn't do) and from Client to Server (client checks in on an interval) which is how it's done exclusively once the initial deployment is complete. If I've missed something here, or am wrong, or if Fortinet's advice to setup the split DNS was wrong or not as secure as it should be, someone please enlighten me. I've been concerned with this topology for some time.

[Kenundrum · Accepted solution]

We started with a domain-joined EMS and then migrated to one that is not on the domain and is sitting in a public-facing DMZ. It's working for us no problem. As mentioned you may need to allow some ports through depending on what the server is doing. We have as little as just LDAPS out to a domain controller for admin logins. We don't use it to distribute brand new FCT installs, so no need for the SMB/DCE-RPC, but updated clients can be pushed out using the telemetry sessions coming in from clients phoning home (if needed). 

[fcb · Accepted solution]

You can run it as not part of the domain, sure, but under the direction of Fortinet Support, we have it joined our to the domain and have it in a DMZ and are just tightly controlling the allowed ports between EMS and the rest of the non-DMZ network. We are using split DNS (I think that's the correct term) where we have A records for ems.domain.com on the outside and on the inside. This way if a client comes "on-net" they can communicate and do what they need to do and if they go "off-net" the hostname is resolvable and hits a VIP that translates TCP.8013 to the DMZ server.

If you don't want to join the domain, I'm sure you can since deployment has a place to specify credentials when it's time to install/upgrade. The "domain" section is nothing more than an LDAP bind over to a DC so no need there but I can tell you that from our EMS server to our internal network still only requires a handful of ports and would be one less if we were NOT part of the domain and having to use the domains DNS servers. If you have a Fortianalyzer (a must have if you have Fortigates or FortiClients or FortiAnything to be honest) will be VERY easy to get the port requirements that you need exactly for your domain/setup but below are what EMS requires at a minimum.

A lot of this will depend on how you will install to an endpoint that has never had FTC installed on it before or in other words how you will "deploy" it. Once the initial FortiClient installation has been completed (installed for the the first time) it will from that point forward use TCP.8013 for EVERYTHING that it needs to do when interacting from Server to client (which it really doesn't do) and from Client to Server (client checks in on an interval) which is how it's done exclusively once the initial deployment is complete. If I've missed something here, or am wrong, or if Fortinet's advice to setup the split DNS was wrong or not as secure as it should be, someone please enlighten me. I've been concerned with this topology for some time.

[Kenundrum · Accepted solution]

We started with a domain-joined EMS and then migrated to one that is not on the domain and is sitting in a public-facing DMZ. It's working for us no problem. As mentioned you may need to allow some ports through depending on what the server is doing. We have as little as just LDAPS out to a domain controller for admin logins. We don't use it to distribute brand new FCT installs, so no need for the SMB/DCE-RPC, but updated clients can be pushed out using the telemetry sessions coming in from clients phoning home (if needed). 

[fcb · Accepted solution]

Exactly correct... the only thing I'd not be sure of in that scenario is if you can fully leverage the Compliance stuff that comes into play starting at 6.4.2 I believe. I'm referring to the whole "If/Then" and how you can base rule-sets off of AD Sec groups and the like. I'd assume though if you had a solid LDAPs on 636 you'd be good to pull any of that information. I'd think your biggest hurdle would be around DNS and EMS being able to properly catch the latest DNS updates and be able to properly resolve the names of the endpoints that are under its care... You're certainly not going to be able to do it if you're pointing at quad 8's and if you're already bringing 53 traffic back into the domain then there's only maybe a two or three net gain on the number of ports your having to bring in on a domain joined vs a non-domain joined box. Truthfully for me the ease of management (and the security of the EMS server itself) far outweigh those two or three fewer ports that the non-domain joined EMS servers will realize. When considering the ports/protocols that have to be allowed vs not allowed that small gain is w/o a doubt negligible in my book.

[skyegool]

Thanks

I tried to leverage between practicaly (domain joined) and theoreticaly (isolated standalone box in DMZ...) best options.

We will start with AD joined and when we well establish whole sytem, we will migrate to standalone, that's the plan at least.

I think that punching hole with 8013 is not that big of a deal.

Will also apply geo-block with security profiles and "heavier" monitoring and we're good to go (I think).

I also noticed that there is no forticlient application signature in Application Control, it would be nice if filtration could be done that way also.

@fcb

I wanted split DNS, but decided that even local users pull telemetry from public side.

If we would do split dns, all of our branches would have to access DMZ from inside and that a hustle to config

It is working fine like this, but I have a feeling that am I missing something :)

[fcb]

skyegool wrote:

I wanted split DNS, but decided that even local users pull telemetry from public side.

Why did you decide to pull telemetry from public side? We are just allowing our internal clients to access it from the LAN side or the same side that EMS talks through to the internal services it needs (ie: Domain Controllers, DNS, ETC). and so far so good, no issues at all.

[Kenundrum]

The huge benefit in allowing access from the outside is that you can publish updates to profiles and all clients will get it regardless of their on-network status. Our big fear was ending up with a device that was marooned due to some change down the road. We can change all the different properties of the profile. As long as the outside telemetry address doesn't change, all the clients will be able to pull the new configuration successfully. 

You can also include multiple telemetry addresses in the profiles, so the clients will connect to a local one if they're on-network or the public-facing one if they're not.