Domain vs Local (The tale of the home/remote user)

There are several releases of Windows but all have a Home version and a Pro(fessional) version. The overall concept is a Pro version has more features to make the computer easier to use in a business/enterprise environment, while the home version has the basic core features providing an operating system that works fine for the individual.

The Home version although cheaper, does not come with the domain features built in, which is underlying problem from a remote user and IT person’s viewpoint. Extra work has to be done to allow the user access to the company network facilities (more rightly the domain).

Unless you have a grasp of the concepts between local and domain user, things can start to get confusing for the user, not only remembering different passwords and becomes a security nightmare for IT and so on.  I could cut this article down by ending it here, saying only purchase Pro versions, but going against “golden rules” it is possible to use local computing within a domain. PROVIDED THE USER AND YOU KNOW THE CONSEQUENCES.


The perfect scenario

The company domain requires that the person accessing the domain is recognised. This is done by the bouncer of the domain the domain controller, quite simply if your name is not on the list, you’re not coming in. The user is listed on that domain controller and provided a password, which they can use to get by the bouncer.

The domain controller also has other skills which soften its role to the wedding usher, in that once you’re in it will control (to a degree) where you are allowed to sit in the congregation. Or, more correctly what can and cannot have access to (note there are other factors that can govern this).

Generically there are two base types of domain users:-

Domain admin: These logins are the security pass of the domain, when you log in you have control and the ability to change settings within the domain, this can be to allow access privileges, add devices etc.etc. It makes sense you don’t give domain admin access to lots of folks, simply because they could go around changing settings, without immediately letting other users what they’ve done. It’s an access level that should be held by trusted competent staff.

Domain user: This user is a worker, and therefore has to be given the right tools for the job. The concept being is that they are wrapped in cotton wool to degree, given the access to what they need to complete the task. For example, a production user doesn’t need management or finance information, so they can’t access that information. While a management user may need access to finance to check budgets, so they must cross over into other territory. This can be done easily under a domain.

Control over the domain user allows that user to safely wander about the company network and never into an area they are not supposed to be in. Should they need access to a restricted area it can be requested and provided by the domain admin. This ensure the smooth and safe running of the network domain overall.




The home user ‘threat’.

Although a home version of windows doesn’t come with domain features as standard, it does not prevent that machine from being used on a domain.

And here’s the first disadvantage: The journey through the domain is not a smooth one, unlike a domain account they won’t be presented with the drives that they can access, instead they will have to reference them, and then provide their domain identity, to “prove” they can access.

But certain features will still be unavailable, such as network printers, as they never checked in but sneaked around the DC it never gave them full domain access via policy. The immediate good news security wise is the DC is still the governor and won’t let them wander where they’re not supposed to, provided that their access isn’t domain admin.

And that’s where the problems start users get frustrated and have to start remembering that the document drive P: for example, is actually a directory share off a domain device and is referenced something like


Although it’s not rocket science, users won’t care that the document drive is really called\finance_documents they just want to access P: drive. Yes, you can create a shortcuts to make it easy to remember, but IT have to provide the name if it’s not known by the user, the link only works when you user is connected to the domain via the company Wi-Fi or remotely by VPN.

The real issue is….

I used the word “threat” in the previous section, at most so far things are a minor irritation to IT and user. But here’s the serious stuff.

When the local machine is set up it’s configured with a local administrator access, and rightly so, as you must install the OS and any applications that you use locally, and here starts the problem.

Unwittingly, let’s say that the user requires a program they need to use (it may well be for business purposes) being a local admin they can download for example adobe pdf reader, but instead of going to the official site, they take one of the many other links that are available, yes the download the application, but they also risk inheriting a load of malware/virus extra’s that they’ve gladly given their permission to as administrator.

AV is not a bullet proof jacket, it can stop most but not all things, and the user allowing things thro as administrator of their own machine as just opened the door to unwelcome quests on their own machine.

Which as we’ve just explained can hop onto the domain, opens up P: drive on the network and your local malware/virus has a whole new section of the menu to start considering to gorge on.

Yes, the domain will have AV, but you’ve forced your way into the domain you’ve possibly sneaked past the protection, and now are running the risk of infecting others, simply by saving files back to the network drives. IT IS THIS THAT IS THE REAL ISSUE


Should local machines be allowed?

The scenario above is not limited to enterprise, it’s a serious threat to your company network and others is if you’re a remote user. Although without shadow of a doubt the answer is YES don’t use home versions within a company it’s a sledgehammer to crack a nut solution.

I would put forward that you can safely use home versions within a company, BUT (it’s a big but) you educate and enforce users, it should not be an option to all, and it will create extra work for IT in maintaining such users but here’s the general rules.

Always use a strong AV and scan for infections

Goes without saying, ideally with any BYOD it should be checked by the company IT first to ensure is clean and safe enough to use for company business.

UAC a work account

If you have a local machine, that you need to use for work DON’T USE THE ADMINISTRATOR account. But create a second user account on that machine. Stop and think about what you need for that account and ensure that its loaded/configured by qualified staff, if you’re uncertain ask.

Never store passwords

Two good reasons for this, first one being loss of the machine, or leaving the system accessible, risks others being able to access domain features. The next reason is cached credentials; your local version will remember your domain password. A good network forces users to change the password periodically, so a time will come when you suddenly click on a mapped share you created and you’re asked for your password, you type it in and you’re not allowed access as the domain knows you need to change your password, but your local copy has the old one stored.

‘Fun’ begins and I use the word in inverted commas, as the user doesn’t know what’s going on and IT now have to start unlocking your domain login as the attempted entry with wrong password has locked you out. ! The problem magnifies itself if users start using phones to access email on another device that constantly checks the passwords

The problem can be rectified switching off other devices firstly and with clearing cached credentials on the local machine, so start googling and learning how to do that!


Safest option is to use the local machine as a simple terminal for office work, don’t use the machine at all for directly working on, but remote desktop to, or call on a remote desktop service to provide you with a domain registered system. There are advantages to this in that a cheap machine can be used as a terminal (so there’s hardware cost savings) which can access a more powerful desktop

Everything is done on the remote machine (be it physical/virtual) and is covered by the network protection. In the case of RDS the VM’s they can be destroyed after their use, so the possible risk of infecting the word macro on that machine is eliminated as its never saved for another user to make use of (again not a bullet proof jacket but a definite extra layer of protection


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s