5 Replies Latest reply on Jun 22, 2018 11:36 AM by ZachW

    Managing DMZ servers using CSA

    BGCBates Apprentice

      What are the steps that I need to take to manage a server in the DMZ with the CSA? Any special agent settings?


      We already have a CSA in place and we used to manually patch servers in the DMZ and we want to start using LANDesk to do the patching.  The current DMZ servers don't have an agent installed on them so that will need to be done.

        • 1. Re: Managing DMZ servers using CSA
          phoffmann SupportEmployee

          Depends on what you're after here.


          By and large, you mainly need to be mindful that:

          • These are servers
          • ... they're coming in through the CSA


          ... so you can't push stuff out TO them (assuming here that the Core doesn't have direct access to the DMZ), but rather rely on THEM checking in with the Core (both for policies & patches). This *can* complicate things when you're got patch maintenance windows configured, but then don't run those repair jobs during those maintenance windows.


          You might want to consider creating / using something like a scope "just for those guys" so that you can do scope-based auto-fixing ... so that they automatically patch vulnerabilities as they detect them, and "simply" control (very tightly) WHEN they scan for vulnerabilities.


          Problem with that is of course that you may not want to enable all patches for all systems like that - often stuff like .NET and/or Java versions can be very sensitive to the software running on those servers.


          ... so THOSE are the problems I would envisage for you to have to solve. Other than that, "it's just regular" going through the CSA to the Core stuff.


          Was there anything in particular that concerned you?

          • 2. Re: Managing DMZ servers using CSA
            BGCBates Apprentice

            I'll keep those things in mind.


            The thing that concerns me is the ease of getting the Server in the DMZ to communicate with the CSA.  I have already determined that I can't access the external facing IP for the CSA from a server in the DMZ.  I can access the internal IP for the CSA.  Is that enough or will name resolution along with routing to the outside and back in be needed.

            • 3. Re: Managing DMZ servers using CSA
              phoffmann SupportEmployee

              "shouldn't" - since you can't use name resolution to poke clients "out there, in the wild internets" either.


              And since the only software / vulscan related packages that can be downloaded *TO* clients must be on the Core itself, you should be fine there (which is another point - you'll HAVE to host the patches on the Core, because you won't be able to access any "alternate server" through the CSA). It allows for connections to the Core only.


              Now Patch stores its content & patches on the Core by default anyway - but it can be a bit of a surprising disk muncher (especially if you have multiple languages to be mindful of) - so just something to watch out for. People can easily go over 1 TB of storage for patches alone.

              • 4. Re: Managing DMZ servers using CSA
                Frank Wils ITSMMVPGroup

                Actually, there is one exception here... In the Distribution and Patch settings you could configure that patches come directly from their vendor on internet when deploying through a CSA.


                So that could be a concern less...



                • 5. Re: Managing DMZ servers using CSA

                  I am fighting this same issue right now and support has been unable to get a working solutions for me with a single NIC setup of the CSA in the DMZ. The CSA by default sets itself up to have clients use the External IP so DMZ servers on the same subnet as the CSA cannot communicate. If Ivanti was smart they would use DNS from the client side to connect instead of the IP, thus allowing admins to control the IP when the client is internal vs external. Using the internal IP works fine so DNS would work as well and I have tested that by editing the cert, broker.conf.xml, and clientconnectivity.xml files to point to the internal address of the CSA. The problem is that occasionally the client will notice updates and re-download the Cert and XML files from the core overwriting my changes I have manually made. In order to stop the clientconnectivity from changing I have setup two connections from the core to the CSA, One of which is using the DMZ subnet IP as the external address, and has the agent configuration pointed to use this CSA connection. The issue is still with the cert and broker.conf.xml files since they update with the external IP occasionally. I ended up changing file security of these two files so they don't get overwritten by Ivanti and it will remain working ,but I don't like having to do this hack when there is an easy fix using DNS. DNS would also allow easy updating of the CSA IP for any future reasons that is needed.


                  Does anyone have a good solution for this yet?