Accessing C$

Hi,
I want to remotely access the c$ administrative share on some computers
running Windows XP Professional ,SP1.

Well, for this, theoretically, I only need an administrator account. But
this does not work *always* !!!!

I tested with user Administrator, and this works most of the time.
When it doesn't work, using Guest account with administrative rights works.

I don't understand ...

Does anybody knows what's the trick here ?

C$ is an administrative share that gives admins access to every file and
folder on the C: partition over the network. No guest is allowed to access
it as it would be a serious security violation. It shouldn't be too hard to
understand.

"Sorin Mustaca" wrote in message
...
Hi,
I want to remotely access the c$ administrative share on some computers
running Windows XP Professional ,SP1.

Well, for this, theoretically, I only need an administrator account. But
this does not work *always* !!!!

I tested with user Administrator, and this works most of the time.
When it doesn't work, using Guest account with administrative rights
works.

I don't understand ...

Does anybody knows what's the trick here ?

Sorin Mustaca wrote:

I want to remotely access the c$ administrative share on some computers
running Windows XP Professional ,SP1.

Well, for this, theoretically, I only need an administrator account. But
this does not work *always* !!!!

I tested with user Administrator, and this works most of the time.
When it doesn't work, using Guest account with administrative rights works.

I don't understand ...

Hi

If the remote WinXP computer is not in a domain, it can be a ForceGuest issue.

WinXP in a workgroup setting defaults to authenticate all connections coming
from "the network" as the Guest User (only possible to change on WinXP Pro).

More about this he
http://groups.google.com/groups?selm...11%40hydro.com


--
torgeir
Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of the 1328 page
Scripting Guide:
http://www.microsoft.com/technet/com...r/default.mspx

You should be able to force whatever user you want in Home edition from the
command line:
"net use * \\computername\C$ /user:administrator password".

"Torgeir Bakken (MVP)" wrote in message
...
Sorin Mustaca wrote:

I want to remotely access the c$ administrative share on some computers
running Windows XP Professional ,SP1.

Well, for this, theoretically, I only need an administrator account. But
this does not work *always* !!!!

I tested with user Administrator, and this works most of the time.
When it doesn't work, using Guest account with administrative rights
works.

I don't understand ...

Hi

If the remote WinXP computer is not in a domain, it can be a ForceGuest
issue.

WinXP in a workgroup setting defaults to authenticate all connections
coming
from "the network" as the Guest User (only possible to change on WinXP
Pro).

More about this he
http://groups.google.com/groups?selm...11%40hydro.com


--
torgeir
Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of the 1328 page
Scripting Guide:
http://www.microsoft.com/technet/com...r/default.mspx

Also, if the password for "Administrator" is blank it will, by default,
block access regardless of anything else. XP has a setting that does not
allow accounts with blank passwords to gain access over the network. This
is new and was not in NT or 2000.


--
Colin Nash
Microsoft MVP
Windows Printing/Imaging/Hardware



"Sorin Mustaca" wrote in message
...
Hi,
I want to remotely access the c$ administrative share on some computers
running Windows XP Professional ,SP1.

Well, for this, theoretically, I only need an administrator account. But
this does not work *always* !!!!

I tested with user Administrator, and this works most of the time.
When it doesn't work, using Guest account with administrative rights
works.

I don't understand ...

Does anybody knows what's the trick here ?

Thank you ,yhis solved my problem.
My computers were not in a NT domain. It was a workgroup.

But this is strange, because on some computers accessing the c$ worked ...
on others didn't ...

Who might have set this ForceGuest registry value ?

Are there any know programs who does this ?
A service pack ?

"Torgeir Bakken (MVP)" wrote in message
...
Sorin Mustaca wrote:
If the remote WinXP computer is not in a domain, it can be a ForceGuest
issue.

WinXP in a workgroup setting defaults to authenticate all connections
coming
from "the network" as the Guest User (only possible to change on WinXP
Pro).

More about this he
http://groups.google.com/groups?selm...11%40hydro.com


--
torgeir
Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of the 1328 page
Scripting Guide:
http://www.microsoft.com/technet/com...r/default.mspx

Xref: kermit microsoft.public.windowsxp.general:1008843 microsoft.public.windowsxp.network_web:192494 microsoft.public.windowsxp.security_admin:139647

Also see

http://www.practicallynetworked.com/...rpasswords.htm

_____________
Eric


"Colin Nash [MVP]" wrote in message
...
Also, if the password for "Administrator" is blank it will, by default,
block access regardless of anything else. XP has a setting that does not
allow accounts with blank passwords to gain access over the network. This
is new and was not in NT or 2000.


--
Colin Nash
Microsoft MVP
Windows Printing/Imaging/Hardware



"Sorin Mustaca" wrote in message
...
Hi,
I want to remotely access the c$ administrative share on some computers
running Windows XP Professional ,SP1.

Well, for this, theoretically, I only need an administrator account. But
this does not work *always* !!!!

I tested with user Administrator, and this works most of the time.
When it doesn't work, using Guest account with administrative rights
works.

I don't understand ...

Does anybody knows what's the trick here ?

Sorin Mustaca wrote:

Thank you ,yhis solved my problem.
My computers were not in a NT domain. It was a workgroup.

But this is strange, because on some computers accessing the c$ worked ...
on others didn't ...

Who might have set this ForceGuest registry value ?

Are there any know programs who does this ?
A service pack ?

Hi

No known programs or service packs changes this value as far as I know,
but e.g. if you disable simple file sharing, ForceGuest is also
disabled (the registry value is set to 0).

So I would think that for the computers that you could access c$,
the procedure in the link below had been done previously:

http://www.practicallynetworked.com/...plesharing.htm



--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/com...r/default.mspx

On Tue, 16 Mar 2004 16:27:51 +0100, "Sorin Mustaca"

I want to remotely access the c$ administrative share on some computers
running Windows XP Professional ,SP1.

Does anybody knows what's the trick here ?

Let's hope there *is* a trick, else malware's gonna have a field day
with that one. Best-practice is never to write-share any part of the
startup axis, and here we have hidden shares that do just that.


-- Risk Management is the clue that asks:
"Why do I keep open buckets of petrol next to all the
ashtrays in the lounge, when I don't even have a car?"
----------------------- ------ ---- --- -- - - - -

On Tue, 16 Mar 2004 22:14:59 -0500, "Colin Nash [MVP]"

About hidden c$ admin share...

Also, if the password for "Administrator" is blank it will, by default,
block access regardless of anything else. XP has a setting that does not
allow accounts with blank passwords to gain access over the network. This
is new and was not in NT or 2000.

That's great news for XP users! I guess it's Darwin take the hindmost
for Win2000 or NT tho, unless there's a patch that retrofits this?

Almost all my clients are standalones or small peer-to-peer where all
who have physical access are trusted equallity. They want:
- no remote access rights whatsoever
- unfettered local access by all users
- one user profile per PC

They also expect data to be recoverable from sick or bonked HDs, and
that pre-payload active malware can be cleaned up without barfing the
system. Those standard Win9x expectations can be delivered on FATxx.

So my approach has been:
- 1 user account per PC, with full rights
- FATxx file systems throughout
- simple file sharing
- no admin password (at Safe Mode or RC level)
- account pwd that's auto-logged on (TweakUI) as needed for Tasks
- highly selective shares that exclude C:\ and OS subdir
- further patches, risk management, goalies of last resort (av)
- firewall if possible (tricky when forced to F&PS on TCP/IP)

In this situation: Would c$ have blank password and be blocked, or
(because the sole user account is Admin rights) use the account's pwd?
As it is, I've taken to applying a .REG to kill these admin shares, as
they look like 100% risk, 0% benefit to me in the contexts I describe.

When, and only when, I have some users needing to do things other
users shouldn't be allowed to do, do I switch to the "turn it on but
hide it under a password" approach. Also, only then do I find clients
actually start listening when I describe user/pwd-based security; for
the first time, it sounds like something they actually *want* :-)



-------------------- ----- ---- --- -- - - - -
Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
-------------------- ----- ---- --- -- - - - -

You're talking about XP? Shares don't have passwords. Any account with a
blank password is denied remote access. I doubt this change will be
backported to Win2k or NT unless they have a "security release" like XP is
getting with SP2, but I'm not directly involved with that team, so I can't
say for certain.

--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.


"cquirke (MVP Win9x)" wrote in message
...
On Tue, 16 Mar 2004 22:14:59 -0500, "Colin Nash [MVP]"

About hidden c$ admin share...

Also, if the password for "Administrator" is blank it will, by default,
block access regardless of anything else. XP has a setting that does not
allow accounts with blank passwords to gain access over the network.
This
is new and was not in NT or 2000.

That's great news for XP users! I guess it's Darwin take the hindmost
for Win2000 or NT tho, unless there's a patch that retrofits this?

Almost all my clients are standalones or small peer-to-peer where all
who have physical access are trusted equallity. They want:
- no remote access rights whatsoever
- unfettered local access by all users
- one user profile per PC

They also expect data to be recoverable from sick or bonked HDs, and
that pre-payload active malware can be cleaned up without barfing the
system. Those standard Win9x expectations can be delivered on FATxx.

So my approach has been:
- 1 user account per PC, with full rights
- FATxx file systems throughout
- simple file sharing
- no admin password (at Safe Mode or RC level)
- account pwd that's auto-logged on (TweakUI) as needed for Tasks
- highly selective shares that exclude C:\ and OS subdir
- further patches, risk management, goalies of last resort (av)
- firewall if possible (tricky when forced to F&PS on TCP/IP)

In this situation: Would c$ have blank password and be blocked, or
(because the sole user account is Admin rights) use the account's pwd?
As it is, I've taken to applying a .REG to kill these admin shares, as
they look like 100% risk, 0% benefit to me in the contexts I describe.

When, and only when, I have some users needing to do things other
users shouldn't be allowed to do, do I switch to the "turn it on but
hide it under a password" approach. Also, only then do I find clients
actually start listening when I describe user/pwd-based security; for
the first time, it sounds like something they actually *want* :-)



-------------------- ----- ---- --- -- - - - -
Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
-------------------- ----- ---- --- -- - - - -

On Mon, 22 Mar 2004 15:44:31 -0800, "Drew Cooper [MSFT]"

You're talking about XP?

Yep - mainly XP Home, but Pro too.

Shares don't have passwords. Any account with a
blank password is denied remote access.

The user's account (which has admin rights) has a (typically trivial)
non-blank pwd, and AFAIK the hidden system accounts do too. The the
"super" admin account that Safe Mode and RC use would have a black
pwd. Is that available at runtime for exploitation?

I doubt this change will be backported to Win2k or NT unless they
have a "security release" like XP is getting with SP2,

Sure. Surprised it wasn't in one of the SPs that have been and gone.

(context; the question was as below)

In this situation: Would c$ have blank password and be blocked, or
(because the sole user account is Admin rights) use the account's pwd?



-------------------- ----- ---- --- -- - - - -
Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
-------------------- ----- ---- --- -- - - - -

The user's account (which has admin rights) has a (typically trivial)
non-blank pwd, and AFAIK the hidden system accounts do too. The the
"super" admin account that Safe Mode and RC use would have a black
pwd. Is that available at runtime for exploitation?

Not sure what hidden system accounts those might be.
The "super" admin account is the built-in local administrator. I certainly
haven't heard of any way to escalate to that account.

Frankly, I think your fears are misplaced. The user with the weak password
is the easiest account to attack over the wire. And if that user is a
member of the administrators group . . . One admin is really as powerful as
another - who cares *which* admin the attacker becomes?
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.


"cquirke (MVP Win9x)" wrote in message
...
On Mon, 22 Mar 2004 15:44:31 -0800, "Drew Cooper [MSFT]"

You're talking about XP?

Yep - mainly XP Home, but Pro too.

Shares don't have passwords. Any account with a
blank password is denied remote access.

The user's account (which has admin rights) has a (typically trivial)
non-blank pwd, and AFAIK the hidden system accounts do too. The the
"super" admin account that Safe Mode and RC use would have a black
pwd. Is that available at runtime for exploitation?

I doubt this change will be backported to Win2k or NT unless they
have a "security release" like XP is getting with SP2,

Sure. Surprised it wasn't in one of the SPs that have been and gone.

(context; the question was as below)

In this situation: Would c$ have blank password and be blocked, or
(because the sole user account is Admin rights) use the account's pwd?



-------------------- ----- ---- --- -- - - - -
Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
-------------------- ----- ---- --- -- - - - -

On Wed, 24 Mar 2004 17:11:58 -0800, "Drew Cooper [MSFT]"
(the other guy in this thread is usually me)

The user's account (which has admin rights) has a (typically trivial)
non-blank pwd, and AFAIK the hidden system accounts do too. The the
"super" admin account that Safe Mode and RC use would have a black
pwd. Is that available at runtime for exploitation?

Not sure what hidden system accounts those might be.

I'm not in front of an XP box right now, but they are visible
(assuming you have Windows Explorer in "don't hide things" mode, which
IMO is a must) in "C:\Documents and Settings" and as entries in HKU.
Names like "Network", "Local System" etc. come to mind.

The "super" admin account is the built-in local administrator. I certainly
haven't heard of any way to escalate to that account.

Is it running at runtime?

Frankly, I think your fears are misplaced. The user with the weak password
is the easiest account to attack over the wire.

In what contexts is a password the only thing standing between the
Internet and the PC? As I have no desire to let the Internet do
ANYTHING on the PC, I'd prefer to rip out those functionalities by the
roots than have to rely on password "protection".

Killing off admin shares is a part of that quest.

And if that user is a member of the administrators group . . . One admin
is really as powerful as another

Er, not really - the "super" admin you refer to has longer arms :-)

who cares *which* admin the attacker becomes?

We're losing focus a bit here (as this is beyond c$ etc.) but OK;
let's deal with this matter of "why be admin?" and "why avoid multiple
user accounts?". MS seems genuinely surprised some users are taking
to these brave new features like rats to cats (i.e. running away)

There are three big reasons why I avoid multiple user accounts, and
why the accounts I use are always Admin:

1) Loss of settings back to MS defaults

This, for me, kills non-Admin user accounts stone dead, rendering them
unfit for use. When I created an account, set it up, and then dropped
it to User in XP Home, it fell back to "hide file name extensions",
"hide files", "don't show full paths" and a host of cosmetically
annoying junk. That's trading one risk for another - how can one
practice "safe hex" if you can't evaluate risk, or manage files if
half of what you are looking for is hidden from you?

2) Inability to pre-set settings in account prototype

Every new account starts with MS duhfaults such as those objected to
above, but also the IMO hopeless standard shell folder locations.
Hopeless? Well, yes, if one is trying to run a more clueful model:
- locate data and bloat off C:
- keep data set on D:, and clean and lean for auto-backup
- locate bloated Music and Pictures on E:, out of data set
- locate incoming risky junk OUT OF DATA SET !!
Every newly created account locates data on C:, where it's subject to
C:'s engine-room write traffic and thus risks of corruption. It nests
bloated Music and Pictures and risky "My Recieved Files" within the
data set, making it too big to auto-backup and too risky to blindly
restore after a (malware payload?) disaster. Plus, each account
wastes an absurd amount of space on web cache that is repeated for
each account - bloats and fragments what should be a lean and fast C:

3) Tedium of applying settings across multiple accounts

Every malware strike requires one to tour the startup axis and check
risk settings that may have been reduced ("broken fences"). There's
no view that allows these to be displayed for all accounts, or allows
them to be set across all accounts, and if the tech doesn't have the
account pwd, that account can't be fixed and remains a risk. Same
applies to baseline risk management you'd like to apply pre-infection,
e.g. NoDriveAutoRun = 9D 00 00 00

So I'd rather have one properly set up and fully functional account
than the sort of mess that ensues when users spawn new accounts every
time someone wants a different wallpaper.

We can chat about pwds as substitute for lockdown later :-)


-- Risk Management is the clue that asks:
"Why do I keep open buckets of petrol next to all the
ashtrays in the lounge, when I don't even have a car?"
----------------------- ------ ---- --- -- - - - -

By default on a Workgroup, XP Pro forces all authentication requests to be
from the Guest account. Even if the Guest account is enabled though, it
does not have permissions on the C$ System share.

What you want to do is disable Simple File Sharing and reboot. This will
make it no longer require a Guest logon. Now when the Credentials box shows
up on the other machine you should be able to enter a username and password.
You want to enter MACHINENAME\UserName and then the password for that
account and you should be able to access the share without a problem.

Ideally, you would want to turn on the Guest account and rather than share
out all of your C Drive just choose a sub-folder to keep the items you are
interested in transferring back and forth from.

--
Michael Burk

Longhorn Shell
http://msdn.microsoft.com/longhorn
----===========================----

This posting is provided "AS IS" with no warranties, and confers no rights.
"Faraz Azhar" wrote in message
om...
Hello everyone,

I need to understand how to access my C$ share. I have WinXP pro
(machine1) and i will be accessing this from another XP Pro
(machine2). When i try to connect from the machine2, it asks for
password. I have an account here in machine1 which is by my name
[Faraz Azhar] and has a password. I enter the password and it does not
open the share, and it gives quite a lenghty error message, i dont
remember what it is. Ive gone through that practicallynetwork website
again n again and couldnt find any solution to this. I have disabled
Simple-File-Sharing.

Is there any easier way to access my C$ from machine2? Please explain
in layman language. Do I need to enable/disable my guest account?
should a password be supplied to the guest account? Of course I dont
want 'any' person to access my C$, (im on a workgroup) so it should
ask me for my password. And it is also a problem for me to create an
account in all the other machines.

Please advise. Thank you.

- Faraz Azhar