Can Enterprise Console manage non domain computers?

Hello LY

I have rephrased the subject - you not only want to manage them (install Sophos by whatever means on the clients which then connect to the management server) but also use Protect Computers.

Yes, it can be done. The credentials necessary for protect computers are IMO the most confusing part of SEC. While error indication has improved compared to previous versions and the explanation is much better it's not intuitive. I'll try to explain.

Protect Computers does the following

• From the server an immediate task is scheduled on the client. For that to work RPC must be running (available) on the client, Firewalls must permit these connection and you have to connect with an account with sufficient rights to schedule a task on the client. Obviously you have all this but still ...
• The task is started on the client which uses calls the setup.exe (with some parameters) from the bootstrap location (CID) using (IIRC) a UNC path. Since the task runs with the credentials you specified for scheduling it this user must have permission to access the CID. The server hosting your CID must permit network access by non-domain accounts or (horrors) anonymous access, and share and NTFS permissions must allow read access.

SEC4 is - at least that's my impression - now checking the latter when you try to use Protect Computers  (previous versions did not and you got an error from the scheduled task) and if the requirements are not met the command fails immediately.

Hope this helps

Christian

(can't resist :smileywink: I checked it very thoroughly, and that quite definitely is the answer. I think the problem, to be quite honest with you, is that you've never actually known what the question is.)

Hi,

The Sophos management service, the component that creates the scheduled task on the remote machine, needs to impersonate the account you enter in the protection wizard; so this account must be permitted to log on to the management server. It would of course also need to have administrative rights over the target machine. 

I would expect the machines in the workgroup to have a common username and password and you have a domain account with the same username and password and which is permitted to log on to the Sophos managment server.  Using that account in the form: <account> rather than <domainname>\<account> in the protection wizard should then work.  In my experience it is worth testing logging on to the management server as the deployment account just to check there is no security policy preventing it, even if it's with a runas command. 

The check is really if the scheduled task is being created on the target machine.  It might also be worth checking to see if you can manually create the scheduled task on the remote machine when logged on the managment server as the same account you are specifying in the deloyment wizard as this will test both ends.

As this remote deployment to the machine is typically a one time event, the other option is to manually or through a script deploy Sophos.  Once the machine has RMS installed it will be managed by Enterprise Console and you can then define policies etc.. 

If you wish to look into that as an option the following article should help:
http://www.sophos.com/support/knowledgebase/article/12570.html

Thanks

Thanks for the explanations. Now I can manage non-domain computers from the console. But I have one more question:

I have two VLANs. I can Protect non-domain computers in the same VLAN as the console. But for those in another VLAN, I can find them by IP address. However, when I tried to Protect them, it failed and gave error 00000034. But from these computers, I can map and view the CID folder in the server. My question is: can the console manage non-domain computers in another VLAN?

I also searched Sophos knowleage base and found there is a way to do manual installation. I am thinking since I am unable to push from the server, maybe I can manually install Sophos in these computers which are in another VLAN. So can I do this? If can, can console push the policies to these computers after the manual installation?

Thanks in advance.

Hello LY

If you install Sophos from a package which includes RMS and the clients can connect to the server (ports 8192-8194 should be "open", preferably in both directions) they can be managed by the console. 

VLANs shouldn't be a problem if

1. The server can be accessed using the name specified in the update policy (for Protect Computers the value in the tab Initial Install Source is used). Do you have to specify a FQDN (or IP address) to map the share?
2. The clients can connect to the share (obvious and obviously possible in your case - I just mention it here because I've seen more than once that the firewall silently blocked SMB between the VLANs)
3. The management ports are permitted

Christian

Thanks. I am able to manage the non-domain computers from console now. But I still got one problem:

I can manually install the Sophos software in the non-domain computers. So from these computers, I go to the SophosUpdate share folder in the server, double click setup.exe and install it on the computers. After that I can manage them from the console. There is no problem.

Howver, I am unable to install software by Protect these PCs from console. When I click Protect Computers,  it asked me to put in the credentials. When I put in the crendetntials, it gave an error message which said invalid credentials. The credentials I put in is local admin on the computer and it is also a domain admin account.

Can you help on this? Thanks

---

LY wrote:
However, I am unable to install software by Protect these PCs from console. When I click Protect Computers,  it asked me to put in the credentials. When I put in the crendetntials, it gave an error message which said invalid credentials. The credentials I put in is local admin on the computer and it is also a domain admin account.

---

Doesn't work like this - you have to specify domain accounts as domain\user. If  in the local security policy the Sharing and security model for local accounts is set to Classic - local users authenticate as themselves you can use the account on the client to access the server provided a local user with the same credentials exists on the server. But you can't "map" a local account to a domain account (if on the server a local account exists with the same name as a domain account - which one should be used?). As I've said you need a local account on the server with the same credentials as the admin-account on the client (but this account needs only read access to the share server - I'd advise against giving it more rights).

I hope I could clarify this point.

Christian

Hi EMK,

I have same issue with Ly. But my policy company dont give me use account domain same with account local on server workgroup. How i can use a account domain not same with account local server ?

Thanks,