Map XP to Windows 7 share

[time]

I'm trying to do this through a VPN without success. I've set the workgroup the same and turned off everything I can see in the Win 7 security Advanced Settings. I can connect with RDP using the local (admin) user.

I can't browse the Windows 7 PC in my workgroup, but more importantly I can't map a drive on the XP box to a share on the Windows 7 box. What works/what do I need to do to get this to work the same as XP did before?

 

[ddrueding]

There are a bunch of things that I do to make this work. The easiest is to turn off password protected sharing on the Windows 7 box by pressing the start button and typing "sharing". Choose "Advanced Sharing Settings" from the list, scroll down, and turn it off. If that doesn't work, let me know.

 

[time]

Nope, already done that. How about 128-bit encryption and Let Windows manage things?

I'm getting this error after it times out:

"A device attached to the system is not functioning."

There's no domain at this stage, just a workgroup: "Workgroup".

 

[ddrueding]

Are you sharing with "everyone"? IIRC, this means you also need to enable the guest account. Not the most secure thing to do.

 

[time]

Yes, I'm sharing with Everyone. This is an exercise in getting things working - security is way off the agenda until everything else is in place.

I'm pretty sure I tried enabling 'Guest'. I assume you're supposed to log in as Guest (no password) in this case? Or is it just another Microsoft misnomer?

 

[Chewy509]

Yes, I'm sharing with Everyone. This is an exercise in getting things working - security is way off the agenda until everything else is in place.

I'm pretty sure I tried enabling 'Guest'. I assume you're supposed to log in as Guest (no password) in this case? Or is it just another Microsoft misnomer?

Have you enabled blank passwords for CIFS in local group policy? Other you may have problems with Guest accounts gaining access to SMB shares, or attempts for users on other computers to gain access to the SMB shares.

Open gpedit.msc and it's in:
Computer > Windows Settings > Security Settings > Local Policies > Security Options > Accounts: Limit local account use of blank passwords to console logon only.

You may need to reboot both server and all clients for this to come into effect? (On some systems it comes into effect straight away, and for others you need to reboot).

 

[time]

Do I really need to use Guest without a password, or can I just use a real or arbitrary username and password like every other version of Windows?

I'm wondering if turning off password protection in Advanced Settings could actually be working against me? That is, I think that hands control to Windows, which probably means it's broken.

 

[Chewy509]

Do I really need to use Guest without a password, or can I just use a real or arbitrary username and password like every other version of Windows?

My preference would be to use a real user account with a password instead of the Guest. Enabled the Guest user account on the LAN side of things is just a really bad idea with Windows.

I'm wondering if turning off password protection in Advanced Settings could actually be working against me? That is, I think that hands control to Windows, which probably means it's broken.

IIRC, in Advanced Settings, you need to set:
"Turn on network discovery", "Turn on file and printer sharing", "Turn on password protected sharing" and "Use user accounts and passwords to connect to other computers", for WinXP (and earlier) and Linux/UNIX clients to connect successfully. You only need to drop the encryption down a notch if you have NT4 systems to worry about.

Something else to be aware of, installing Windows Live 2011 (and I think it's specifically the Messenger component) will update the CIFS server in Windows 7, slightly modifying the SMB protocol being used for file sharing. If you don't have this installed on all the other clients, you may have connection problems. (For Linux/UNIX clients, you need to run a very recent version of SAMBA, as only recent versions know how to talk this updated protocol).

The technical answer for the above statement. Installing the messenger component adds some new protocol definitions to SMB/CIFS in relation to P2P LAN messenging, which unfortunately broke the SMB/CIFS protocol in regards to authentication. You either need to have all clients running the same version of Windows Live, or if you have Linux/UNIX clients either don't install Windows Live 2011 or ensure your distro includes a very recent version of SAMBA which knows about the changes.

 

[Chewy509]

Or is it just another Microsoft misnomer?

You log in as your normal user account.
When connecting to a foreign machine, Windows will attempt to authenticate with your user account. If authentication fails, it will then try authenticate as "Guest" with no password, and if that fails will attempt to authenticate as the Computer name with no password, which in earlier versions of Windows gave you the IPC$ login prompt.

Since WinXP (and I think it was SP1 or SP2), blank passwords on LAN connections would automatically be refused, even when you had a valid username. The GPO object I linked to earlier allows you to revert to the old behaviour of allowing blank passwords on LAN connections (which also allows LAN connections to authenticate as Guest).

 

[time]

Unfortunately, that doesn't seem to work either. I'm just using the default admin user that was set up at installation, eg "user1", "password1".

That being the settings in Chewy's previous post.

Is there any point in adding a dummy user to the userlist of the host PC, eg HostPC\Dummy ?

 

[Stereodude]

I'm a little confused, are you trying to map a drive from a XP system over the network on a Windows 7 system, or do it the other way?

I found Windows 7 has no problems mapping XP administrative shares. XP won't map Windows 7 (or Vista) administrative shares unless you edit the registry of the Windows 7 box. link

 

[time]

Trying to map a drive letter on an XP box through a VPN to a share on a Windows 7 box, eg \\192.168.1.2\share.

Thanks for the link, but that seems to be about reduced access rights rather than failing to get the connection at all.

I dunno, they've broken something. I can't see the sort of entries in the firewall that I thought might cause the problem, but it's got to be something like that.

Bear in mind that I can map to the share from other Windows 7 PCs on the same subnet. But not from XP through a VPN, even though I've used the same VPN to do just that with XP and Samba hosts.

 

[Bozo]

Have you tried disabling the firewalls on both computers?

 

[Chewy509]

On the Win7 PC, in event log> security, do you see the WinXP client attempting to authenticate? (I can't remember if Win7 records success/fail login attempts on shares or not. If not, just enable the right GPO objects to do the recording).

This may give you some clues as to what is going on.

 

[LiamC]

Have you tried creating a user (i.e. not using Administrator or Guest), account on both machines and giving this user the same password on both machines? This works well for me. Both users must have access permissions to the resource(s) you are trying to share (and that's better than using Everyone).

 

[time]

I expect it's some piece of Microsoft joke security but I can't guess which part of the process it's afflicting. I had looked through the logs but couldn't see anything - 18 million other things, including cheerful stuff like an integrity audit failure on some Windows file that started up yesterday (which I don't believe for an instant).

Perhaps it's a clue that it's not even getting that far? I dunno, I was getting tired, so I'll have to do it all again.

Can I safely disable the firewall without killing my RDP? I don't trust Microsoft an inch. Come to think of it, where are the firewall logs?

LiamC, logically I shouldn't have to do that because the login details are attached to each drive mapping and work locally on the LAN. But I'm not even getting that far, I can't even see the damn PCs, i.e. \\192.168.1.#\share is just timing out with YAMMEM (yet-another-misleading-Microsoft-error-message). Still thinking of trying it in case that's the joke though.

Meanwhile, I can happily RDP in and get it to share my drive on the remote host. There's nothing like consistency to make your job easier.

 

[Stereodude]

Can you even ping the PC?

 

[time]

Uh, no. I can ping it from other PCs on the LAN, you see ...

So I turned off the firewall and now I can ping the box through the VPN. It doesn't solve my problem, but the timeouts seem shorter now. Anyone care to hazard a guess as to which cryptic firewall option would allow pings from a different subnet or whatever it's detecting (it's not called that with Windows 7)?

I did find this interesting page. When I checked the policy setting, rather than Microsoft's claimed default of NTLMv2 only, it was set to none. The fix worked fine after a restart.

Fuck Microsoft and every piece of demon spawn they've ever created.

 

[time]

To finish up, I needed to tweak the firewall to allow Netlogon Service, and then created a custom rule to respond to ping requests, as per this page.

So presumably I need to patch every workstation just so I can ping the f*ckers.

 

[Chewy509]

Fuck Microsoft and every piece of demon spawn they've ever created.

Now, now, don't be so harsh. The answer to all your problems is here or here.

 

[Chewy509]

So presumably I need to patch every workstation just so I can ping the f*ckers.

Glad you got it working. Alternatively setup a domain, and set all that as a domain wide GPO, that way you only need to do it once to it'll be applied all machines within the domain.

 

[Howell]

May e on the windows 7 machines change the network type from public to work or even home.

 

[time]

It's already set to Work rather than Public (Home or whatever they call their 'simple' networking these days is unavailable with Pro editions - although I'm sure you could get around it with a few hundred hacks).

The plan has always been to setup a domain, it's just been deferred because of the other issues that Microshit threw my way at the start of the week. Now I'm remote and everything's live so it's just a teensy bit more difficult to progress.

Sorry if I'm grumpy, I really can't see Windows surviving as a viable platform past another release. Single Home PC, yes, but for that people will be running games platforms and iPads, right? In the corporate world, it's going to be all browser-based. More than ever, there's an opportunity for a product with decent Excel compatibility - maybe they're restricted due to copyright or some other crap?

 

[Howell]

Take a break and come back to it time you're not thinking clearly. All versions of windows 7 have all three network/firewall settings.
http://windows.microsoft.com/en-US/windows7/Choosing-a-network-location

This may have already been posted, but
http://windows.microsoft.com/en-US/...mputers-running-different-versions-of-Windows

 

[time]

I read all that before I set it up. Having read it again, there's nothing I need to change.

However, I did notice this hint at the bottom of the second link:

Before a computer running Windows XP can be detected and appear on the network map, you might need to install the Link-Layer Topology Discovery (LLTD) protocol on that computer.

I'm not interested in their 'network map' or making the remote XP PC discoverable, and installing LLTD would result in a default setting that is incompatible with XP, but at least it's a clue to what's going on in their minds when they contrive this bastardry.

Of course, that wouldn't have helped with my VPN issues and therefore it would still be broken.

And why did they think it smart to add all these firewall gimmicks to PCs, which are inevitably on INTERNAL networks, i.e. behind NAT at least? How is security tangibly improved?

 

[Chewy509]

And why did they think it smart to add all these firewall gimmicks to PCs, which are inevitably on INTERNAL networks, i.e. behind NAT at least? How is security tangibly improved?

Internal firewalls were/are implemented to stop worms from travelling around the LAN, when brought in by other means like USB keys. The problem is, most worms use services/protocols that need to be open on the firewall by default for anything useful to be done. eg Admin file shares.

My biggest grief with Windows, that you can't turn some network services off, or have them listent to localhost connections only. In contrast most other OSes, have this behaviour by default, and the user must explicitly enable a service to listen to any LAN connection.

IIRC, on a default installation:
Solaris 10/11 only SSH listens on LAN, all other services are localhost only.
Most decent Linux distributions, all other services are localhost only.
OpenBSD/FreeBSD/NetBSD, all other services are localhost only.
MacOS X, don't really know, as haven't had too much to do with it.