nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Windows Server 2003 - security flaw???

Markie

Hey guys.

As part of my studies, I stumbled across something quite strange. Although some of you may not see it as a security flaw, surely it has to be at least a "glitch". I should point out that my testing was done in a Virtual PC environment.

Anyway, it pertains to the situation where a computer on a "Workgroup" can communicate with computers on a "Domain" and can actually access domain resources etc.

Here is the scenario I went throught to make this occur (by accident of course):

1. Removed a computer running Server 2003 from the domain (using a domain admin a/c) and then added it to a workgroup called "WORKGROUP".

2. After restarting the computer, I logged in to the server locally by using the local administrator a/c and password. Here's the important part, the password for the local administrator a/c was the same as the password for the domain administrator a/c.

3. After logging on locally, I was able to commuicate with all other computers on the domain and access shares etc. When I went into the domain controller and browsed the network, I noticed that all computers (domain computers plus the new workgroup computer) were listed under both the domain and the workgroup (i.e. they were mirror images of eachother).

4. I decided to reset the password on the server (workgroup computer), log-off and then log on as the local administrator, but this time with the new password (a different one from the domain administrator).

5. And Voila!!! Now, when I browsed the network, I had the server listed under the Workgroup and the remaining computers listed under the domain (which is how it should be). Now, when I tried to connect to computers on the domain, I got the 'Connect to ComputerName.Domain' window asking for crudentials to access the domain.

OK, I know a lot of you guys are gonna say, why the heck did the local administrator and domain administrator a/c have the same password.

Well, as I said above, it was a test environment and who wants to have to remember a zillion passwords anyway.

Having said that, I wouldnt be surprised if there was a whole bunch of novice system administrators out there who have been using the same password for both of these accounts.

Anyway, the point I want to make is that, wasnt the concept of the Computer account implemented to prevent such occurances?

I always intrepreted the computer account as being like a second layer of security (on top of the user a/c). But in the example I have just described, there is only one layer of security (that being the user a/c).

In theory, removing a computer from a domain by using a valid domain admins a/c (which by the way disables the a/c in active directory) should prevent workgroup computers from accessing the domain, but it clearly didn't in the scenario described above.

What do you guys think?

Mark

Find more posts tagged with

SAVE $250 on Your Microsoft Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View Microsoft Boot Camps

Comments

dynamik

While I think having administrator passwords match-up in a real-world scenario would be very, very unlikely (unless it was a situation like you're describing or a very bad password, i.e. "password"), there are plenty of reasons to worry about a rogue computer being on your network. You'll want to look into domain isolation to combat these types of situations: http://technet.microsoft.com/en-us/network/bb545651.aspx

Nice observation though

Markie

Hey Dynamik.

Thanks for your response.

Although, I agree with what you say, don't you think that this type of behaviour takes away some of the credibility with respect to computer accounts?

In small to medium sized businesses, where they may use a mixture of domains and workgroups (as workgroups are cheaper and easier to configure), there's bound to be the odd occassion when the name of local machine accounts match domain accounts. All you need is a matching password and you have a security problem.

I mean, besides the "log on to" option disappearing from the logon screen (after a computer a/c has been disabled in Active Directory), I can't really see any other benefits from using computer accounts if this flaw exists.

So much for the supposed "security channel" (thats the channel that the DC uses to communicate with valid computer accounts).

I suppose the other workaround besides ensuring no identical passwords are in place, is to keep the workgroups and domains on different subnets.

At least I won't make this mistake as a Systems Admin in the future.

Mark

dynamik

Markie wrote:

Although, I agree with what you say, don't you think that this type of behaviour takes away some of the credibility with respect to computer accounts?

Not really. It bypasses things like GPOs that domain computers have, but it doesn't hurt the integrity of domain computers. This is how things were designed. I agree that it's good to be aware of such functionality.

Markie wrote:

In small to medium sized businesses, where they may use a mixture of domains and workgroups (as workgroups are cheaper and easier to configure), there's bound to be the odd occassion when the name of local machine accounts match domain accounts. All you need is a matching password and you have a security problem.

This is only really a problem if the domain account has some sort of permissions that the user of the local account shouldn't have. Your example is a good example of this. It might be necessary for someone to be a local admin, but you don't want them to be a domain admin. More often than not, it won't be an admin account, but will be just a regular user account (i.e. they bring in their laptop from home and user the same username/password there), and they won't be granted any more permissions than they would have otherwise. They're still bound by the controls placed on their user account.

Like I said, this does circumvent a lot of controls, but I really don't think that the identical credential issue is your greatest concern. Any machine hooked up to your network can easily learn a great deal about your network and can launch attacks much more easily. If it's a more casual user, he or she may be bringing in viruses or other malware. There are many reasons to keep non-domain computers off your domain (excluding things like web servers sitting in a DMZ, or something else you have control over), but I think there are much more serious issues than what you're describing.

Markie wrote:

I mean, besides the "log on to" option disappearing from the logon screen (after a computer a/c has been disabled in Active Directory), I can't really see any other benefits from using computer accounts if this flaw exists.

GPOs? Just because one (or a small number) of workgroup computers exist and may bypass the benefits of domain computers is no reason to forgo the benefits and control over the majority of computers.

Markie wrote:

So much for the supposed "security channel" (thats the channel that the DC uses to communicate with valid computer accounts).

Again, this is functioning exactly as its supposed to. The secure channel exists for computers joined to the domain.

Markie wrote:

I suppose the other workaround besides ensuring no identical passwords are in place, is to keep the workgroups and domains on different subnets.

At least I won't make this mistake as a Systems Admin in the future.

You should never use identical passwords anywhere. You should have a different password for administering Exchange, SQL, your web servers, your local accounts, etc. If one of your machines gets compromised, you want to contain the damage as much as possible. Could you imagine a laptop getting stolen, someone cracking the password to the local admin account, and then being able to successfully use that password to authenticate as the domain admin?

Also, you can rename the domain and local admin accounts. This doesn't provide that much extra security since there are ways to determine the name of the admin account, but doing something like that can protect against what you're describing with your admin accounts.

Edit: Also, I understand your concern about local credentials being transparently used to authenticate to the domain. But realistically, how secure of an environment could you possibly have if you're using identical credentials for important resources? The first thing a user will try is the credentials he or she already has. Not having this done transparently in the background might slightly decrease the likelihood of this happening, but it's inconsequential in the grand scheme of things. Moral of the story, use really good passwords, or even step up to smart cards, if you have important resources and/or accounts to secure.

Markie

Hey Dynamik,

Thanks for your response.

You've given me some things to think about. And yes, I suppose one benefit of computer accounts is that they can be used when linking GPOs.

I am sure there are a whole lot of benefits of having computer accounts existing within the AD structure. Probably the most simplest example would be administrators being able to determine the actual physical location of a computer more quickly.

I suppose I was really talking about the security benefits of having computer accounts.

I guess what has kind of confused me is that I was always under the impression that logging on to the domain and logging on to a local machine (and therefore possibly a workgroup) were two very different acts (when operating in domain environments). But maybe my example has highlighted that the distinction between the two is more 'grey' (as opposed to black and white).

I know Im being a bit stubborn on this one but its kinda frustrating when you think you understand a variety of concepts (and how things should work in theory) but then a scenario like the one I have encountered pops up and basically goes against everything you thought you understood.

Mark

NetAdmin2436

Dynamik nailed it, to add.... Not only rename the domain adminstrator account and local administrator accounts to something different from each other, but the secuirty groups as well. While the security groups don't really apply in the situation above.....it's still a MS best practice and along the same lines. It will basically protect against evil scripts that look for the default names.

Examples:
Local Administrator = Administrator --> LocAdmin
Local Administrator Group = Administrators --> LocAdmins

Local Laptop Administrator = Administrator --> LapAdmin
Local Lapotp Adminstrator Group = Administrators --> LapAdmins

Domain Administrator = Administrator --> NetAdmin

Domain Administrators = Domain Admins --> NetAdmins

These can all easily be set from a GPO.

....the same goes for other other built in accounts/groups (guest, power users). Even though the guest account is disabled, they still recommend renaming it. I guess it really depends how paranoid you are.

photex

May I ask?
After removing your server from the domain, did you remove the Computer account from te domain controller?
Cause I think when you connect to domain recources, your computer account still gives you rights to acces those recources even though your server is no longer a member?!?

Just a thought.
I'm still studying for the exam, so forgive me if i'm saying something really stupid.