Skip to main content
skyegool
skyegool
New Member
July 15, 2021
Solved

Forti EMS on non-domain server

  • July 15, 2021
  • 1 reply
  • 11819 views

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

      Best answer by fcb

      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.

      1 reply

      fcb
      fcb
      Visitor III
      July 15, 2021

      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
      Kenundrum
      New Member
      July 15, 2021

      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
      fcbAnswer
      Visitor III
      July 15, 2021

      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.

      Terms & ConditionsAccessibility statement