Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 4 subscribers
  • Views 4859 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Managing Endpoints in an untrusted domain

pdc

Hi all, 

Hoping that someone has seen this before and may be in a position to assist. I have a case open with Sophos Support, but they appear to have gone into hiding on me .. 

I have a test environment, which has been setup in on isolated network. The test environment is running a number of windows endpoints that I need to keep protected with the endpoint security suite, for compliance (auditing,etc).  In this network I have a domain setup, which is not trusted by my main production domain. 

I have a 'bastion host' setup which is dual-homed, (internal and external network cards), from which I have SUM installed. The external network card is only permitted to talk to my SEC server on my production network - I have the correct ports opened to facilitate communication between the two hosts. 

I want to have my bastion host act as the message router for the isolated domain, in addition to it pulling updates from the primary SEC server. 

I have read <https://community.sophos.com/kb/en-us/14635> , and <https://community.sophos.com/kb/en-us/50832>, and whilst I understand what's needed, I think I've hit a problem as a result of my 'untrusted' domain. 

From my primary SEC server, I can see my SUM server from the 'untrusted' domain, and I can see that traffic is passing between both SEC & SUM servers correctly. 

When I check SEC and check the Update Manager status, it reports an error 80040408 - unable to write to distribution location \\untrustedserver\SophosUpdates ...

See: <https://community.sophos.com/kb/en-us/66181>

Clearly a file permissions issue, I get this. The problem is that I can't change it. 

If you look at default configuration of the '\SophosUpdates\' distribution package you'll see that the default share will let you click 'configure' but it won't let me change the username and password settings. 

I did try creating a new distribution package, and adding this on the 'distribution' tab of the update manager configuration, then setting up the share on the target SUM server..which worked, except that it expects that the primary SEC server is the message router. 

I did try to be clever, using ConfigCID, on this new distribution package - that I created on the SEC server, but I've been unable to get the updated mrinit.conf to stay referencing the 'bastion host' , I've tried robocopies of the distribution package, between the two.. but that doesn't solve the overall task.. 

Surely I can't be the only one to have tried this ? Any assistance would be very much welcomed, as I'm losing the will to live with this one :D

Thanks in advance

 

 

 



This thread was automatically locked due to age.
  • 0

    HI,

    So the downstream/second SUM you have is unable to write a distribution location to itself? I.e. \\untrustedserver\SophosUpdate.

    Or do you have the primary upstream SUM configured to write a CID to the untrustedserver?  That wouldn't be required, you could try it but why would you need to?  The child SUM can pull files from the parent and create local CIDs for itself and the clients to update from.

    Regards,

    Jak

  • 0 in reply to jak

    Hi Jak, 

     

    In my setup, to get SUM to install on the 'downstream' (isolated) domain, I copied the contents of \\secserver\suminstallset put this into an ISO file, then mounted the ISO onto the VM that is acting as my downstream SUM server. 

    Yes, I've been trying to get my upstream  / parent SEC server to write the updates to the downstream host, maybe this is the wrong approach. 

    With this said, as the 'untrusted' downstream SUM server is shown in the update managers list in SEC, and I configured the update source to be \\secserver\SophosUpdate 

    This is where I'm seeing the 'unable to write updates to the destination server' - I assume it's SEC trying to push the updates down to the SUM server, rather than SUM running on the downstream host and pulling the updates from SEC (or have I missed something?).

    Interestingly when I run process explorer whilst the updates are running, I can see that there's activity on the 'C:\ProgramData\Sophos\Update Manager' location it's writing files, so I'm a bit stumped to why the SEC update manager details is telling me there's an error. If I compare the S000 package between the 'trusted' SEC server and the 'untrusted' downstream SUM server - the packages appear to be identical. 

    the errors being reported for the default \\sumserver\sophosupdate are:

    80040404 - Threat detection data update failed

    80040408 - unable to write to distrbution location \\sumserver\SophosUpdate for software subscription 'recommended' 

    80040401 - Software Update failed. 

     

    My gut feeling is that it's something to do with the AD account from my production domain trying to write to the untrusted domain. 

     

    In regards to changing the MRINIT.conf on the downstream server, can I change the default S000 package on the downstream server, and run configCID to direct endpoints to this server - or must I create a new package from the downwnstream server and distribute this to endpoints. 

    I had it working (briefly), but it looks like update overwrite my mrinit.conf.. so the endpoints are trying to communicate back to the parent SEC server - which will never work due to the network isolation

     

    Any thoughts/suggestions would be much appreciated

     

     

     

  • 0 in reply to pdc

    Hello pdc (and excuse me, , for interfering).

    update source [...] \\secserver\SophosUpdate
    correct, but like the endpoints's AutoUpdate it's always SUM downloading, never the source server pushing.

    unable to write to distribution location
    the     distribution location is configured under the Distribution tab, for each subscription the default share \\SERVERITSELF\SophosUpdate is pre-configured (and can't be removed) - the distribution locations for the SEC and all the SUMs are independent (and configured independently). Please check this tab for your SECSERVER (if I understand correctly it's its SUM that reports the error) - perhaps you've entered the SUMSERVER share in Distribute to:

    change the default S000 package
    the better term is configure the default S000 CID - yes, it is possible, configurations are not distributed to downstream SUMs. Don't forget you have to put the mrinit.conf in the \rms subdirectory - see Important in section 1.2 in     configuring message relay computers (be warned, if a "redirected" endpoint updates from an unconfigured CID it might revert to using the original mrinit.conf). As you can't (at least not easily) access the SUM share from SEC you have to run ConfigCID.exe on the SUM - please see Error "Failed to read signing key" in the linked article.

    Christian

  • 0 in reply to QC

    Hi Christian, 

    Many thanks for the details.. 

    On the update source, it was a bit of an odd one.. as host that acts as the SUM was able to read the share on the SEC server.. there's probably something in the file permissions, that's preventing this.

    On the distribution location - From my SEC server, my isolated sum server was listed, the default distribution point was listed as \\sumserver\sophosupdate. If the SUM server is pulling the updates from the SECserver, this would explain why the username/password cant be changed (as it's local to the SUM installation).. but I was able to get the SUM server to do a UNC share access from 'SUMserver' to 'SECserver' - again probably something with file permissions. 

    I figured that I'd create a new package distribution point [\\sumserver\sophosDP] , on the SUM server, and then from the SEC server provide details of the share - being able to set username and password details, and that appeared to update at the SUM server side. But of course I keep getting the 'software delivery failed' status on the SUM server.. the issue is always the default  \\sumserver\SophosUpdate share - which can't be removed. 

    On changing the MRINIT.conf, I think I did have this done correctly, as you outlined.. I did have endpoints in the isolated network reporting back on my SEC server, but then they stopped.. I could only pin it down to the configuration being overwritten. 

    I'd spent a little too much time trying to get to this point so I ended up having to resort to installing a separate SEC server within the isolated network environment, and only setting the SEC server retrieve updates from Sophos - it's not the way I wanted it to be done - but I have a project manager sitting on my desk asking why the other setup was taking so long.. I have to live with the additional SEC server to manage, as the project deadlines are taking priority

     

  • 0 in reply to pdc

    Hello pdc,

    a project manager sitting on my desk
    I'd rather give my guys a few more days for a solution that makes sense. Anyway ...

    the default distribution point was listed as \\sumserver\sophosupdate
    In the SUM configuration for SECSERVER the \\SECSERVER\SophosUpdate share should be greyed (and unremovable)  in the     Update to: pane, likewise for SUMSERVER. Any other entry in the Update to: pane should be removable.

    the username/password cant be changed
    as you say, credentials aren't needed as it's accessed locally. The credentials are only needed for the updating policies.

    To repeat:
    SECSERVER/Primary SUM downloads from the Sophos Warehouse, builds its own Warehouse and the default (and optionally additional) CIDs. Warehouse and CIDs are pblished on the SophosUpdate share.
    SUMSERVER downloads from the Warehouse under SECSERVER's SophosUpdate share, again building and publishing its Warehouse and CIDs. If you want to use this SUM as Message Relay it must be installed as per Deploying a message relay and SUM installation via the SUM bootstrap executable setup.exe. If necessary its CIDs can additionally be configured accordingly (but you don't need an extra CID for a relay configuration). Endpoints installing/updating from a SUMSERVER CID then communicate using it as relay.
    Update policies are naturally configured on SECSERVER, endpoints download from the server specified there.

    The error on SUMSERVER has (had) likely some other reason - too late for now. Did you install the second SEC using to credentials from the first one? This would make it easy to revert to the intended setup later. Otherwise you'd have to re-deploy the isolated endpoints when the time comes.

    Christian

Unfiltered HTML