Problem solve Get help with specific problems with your technologies, process and projects.

Which is safer: Domains or workgroups?

My question is based on security and the best way to handle sensitive data and file sharing. Should domains or workgroups be used on the following systems?

Our organization has migrated to the Windows 2000 Active Directory as an organizational unit (OU). We are still...

in mixed mode with 2000, NT4 systems, however.

These systems collect and run data for analysis. Access to the data on these systems is through a local share folder. This in turn allows the user to access the data on their client-side system.

Lately, there are concerns about whether the systems that collect data should be joined to the domain or left in a workgroup setting. If joined to the domain, a single-sign would be used. If left on the workgroup, a separate set of user and password access would be used. Since we are an OU, and thus some control is restricted, it is a problem.

If joined to the domain, what are the security risks? If left as a workgroup, is this better from a security/hacking perspective?

I need some way to justify one way or the other to the other network admins. What are our options and what is the best way to do this? We want to develop some sort of best practices here. Constructive advice is appreciated!

As you seem to be aware, there is no perfect answer here. Certainly joining the computers to the domain allows you the benefit of some additional security, such as smart cards for logon, central control over groups and group members (Is someone delegating administrative control over the OU?), OU-specific IPSec policies for managing access and for potentially encrypting the data stream between client systems and servers, group policies that lock down systems and so on.

Leaving the servers in a workgroup allows you to partition your data. By requiring separate logons to access the data, the compromise of a domain level account would not mean access to all the resources that individual has access to. Local IPSec policies, indeed local security policies, can be used effectively to tighten controls and lock down systems. In addition, a separate password and account lockout policy can be created at the local level. As domain members, you are subject to the same policy as all domain users. However, domain membership allows automatic policy refresh and easier, centralized control (one policy for all like systems in the OU). You could have a sub-OU for the file servers and create a specific policy.

I'm in favor of the centralized control simply because managing many servers correctly is often difficult, whereas applying the same controls to multiple servers is not. However, in circumstances where the risk to data that might result from single sign-on outweighs the benefits of centralized security policy, that may be preferred -- as well as in cases where adequate investment in the management of security on each workgroup system is available.

There is also a third alternative: Why not have the best of both worlds? You can insist on local account usage for access to resources on the file servers, while managing their security policy centrally. There is nothing to prevent the setting of resource permissions to only allow local accounts access, thus domain users must still use the local account and password to access the resources. On the down side, domain administrators can, of course, change these policies. Should someone accidentally or maliciously do so, (just as it would be in any environment) your careful security defenses would be compromised.

Best practices widely recommend, however, that local user accounts not be used in a domain setting, as they are often neglected and abused.

So the question here really becomes one of doing a realistic risk analysis with all of your factors and issues addressed. I've way too little information on your specific circumstances to say that I have the best solution, and you must know, it's a topic that requires far more than a simple answer in a Web forum.

Thanks you for this opportunity to address this most interesting issue, if only in a minor way.

Dig Deeper on Windows 10 security and management