Can't Connect to Shared Drives

Hi


just a compatibility thought

A few years ago, it was mandatory to set "enableplaintextpassword"
in order to be able to connect to SAMBA machines (lanmanworkstation
is the workstation service). Such a low password encryption level does
increase compatibility[1], however it makes it easier for an intruder to
use a network sniffer. In this context (requirements), it is a security risk,
of course, as you also know.


The registry key "enableplaintextpassword" can also be set using local
policies:
Administrative Tools,Local Security Policy,Local Policies,Security Options,"Send unencrypted password"


browser service and replication latencies

Quote:

---

2) Mapping to the actualy IP address instead of the server name does work for some reason.

---

This points me (as well as others (rapier57)) to the idea, that your problem had to do with the
browser service.
You can get information about your current master browser using browmon and browstat,
which are part of the resource kit[2]. Mainly, try to control which machines are
participating in the election process using
[HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Browser \Parameters].
Here, MaintainServerList (Yes, No, Auto) controls if the host should participate
at all, IsDomainMaster sets the priority.


What puzzles me, is that your problem just appeared on a running system.
Apart from possible malware (always a possiblity :) ), it might be that some
propagation error occurred (but because of what? Patch, Restart, Conflicts,...):
"SPN for the domain that is hosting the replica has not been propagated."[3].


Inconsistencies in the Browser table might be simply eliminated by
refereshing/restarting the service (debug using browmon and browstat),
as mentioned by RoadClosed.
If I recall correctly, in Win2k you still need the WINS table in order to
resolve for the IP, based on the "servername" (Win2k3 uses DNS). I hope, this
makes some sense or am I confusing something?


Cheers


[1] http://snakefoot.fateback.com/tweak/...PWD_ENCRYPTION
[2] http://www.windowsitlibrary.com/Content/155/05/2.html
[3] http://www.chicagotech.net/systemerrors.htm

I figured it out.

Oddly, the LANMAN fix was only temporary. This afternoon after a reboot my workstation once again failed to connect to the shared drives.

I finally discovered that something in the last Windows Update I ran caused this. So I removed Security Updates KB885835 and KB885836. Rebooted, and now everything is connecting as it should.

This has been a concern of mine. This data server is fairly behind in updates and is thus missing a number of security patches, but my boss is against running updates for this reason. However, obviously this means we have upatched holes in the server's W2k OS.

Odd...I'm beginning to think there's more than one cause to this.

Yesterday, things continued to run smoothly across the network after those two patches were removed...except on two computers. That's two out of ~20 or so; the rest connect fine.

One is a workstation, and the other is the backup domain controller (?!). For some mysterious reason, neither of these will connect to the shared drives, even after the fix on the data server, even despite the fact that all other computers on the network are showing no other problems connecting yet.

Again, however, if it is directed to the shared drive via IP address as opposed to the usual computer name, it will connect.

So evidently I've only partially fixed the problem. So now I have to figure out why these two machines won't cooperate while all the others will.

A hint I see: In My Network Places, the data server is one of quite a few computers these trouble computers fail to see on the network with them. When I run a search on the data server by name, it comes up with location "unknown" instead of showing the name of the network (even though they're on the same network!).

Baffling eh? I'm quite stumped at the moment.

<edit> Another hint: I keep seeing repeated occurances of DNS Error 409 on this backup domain controller in question.

Quote:

---

The DNS server list of restricted interfaces contains IP addresses that are not configured for use at the server computer.
Use the DNS manager server properties, interfaces dialog, to verify and reset the IP addresses the DNS server should listen on. For more information, see "To restrict a DNS server to listen only on selected addresses" in the online Help.

---

However, the IP addresses are indeed configured properly.

Sorry for the annoying triple-posting, but I'm finding new stuff...

This is my first introduction to browmon.exe, so you'll have to forgive my ignorance. However, I installed the tool and ran it on this pesky backup domain controller. I can indeed see the data server, I just can't connect to it. So it's at least visible, and it does show up in browman.

Anyway, I'll keep digging and will post whatever I turn up next...

Well, now I've run browstat.exe, and still no clues that I see...

Shows that everything is running well...

Yesterday I was telling you that the data server wouldn't even appear in the browser. Now it does appear, only it cannot be accessed. It is the only computer in the browser that cannot be accessed. It returns the error "The target account name is incorrect".

And again, any other machine other than these two can connect to it.

So no luck yet finding anything odd with browmon or browstat...

AngelicKnight

I have read on many occassions that all MS servers and clients should be at the same patch level...or you will start to encounter communication issues! as the security patches fix things in the protocol, authentication privledges etc

Are the clients all 2k and up?? cause Ive seen some issues with 98 and 2000 servers??

Tell your boss that you have to update..backup that data server ..twice, verify both backups and test restore from both backups.....and UPDATE!!!

Patching isnt half as bad as the old NT4 days when you patched something...which inturn would unpatch something else....or break some thing.

Patching servers is not one of my favorite things, I backup, then backup again, then I verify..test restore...start late friday ( so I have the weekend to restore...just in case :( ) cross my fingers and do my old NT4 voodoo dance (some old habits die hard :) and update.

IMHO 2k patch management was an improvement on NT4
...2003 is a GREAT improvement...although I still do the dance ;)


MLF

Unfortunately my telling the boss we must patch isn't going to do me any good, such is the downfall of me being assistant network administrator until I eventually get promoted (hopefully).

However, I keep all of our clients and most other servers up-to-date. Consider:

The data server, when patched, will not share it's drives with anyone unless the clients connect via IP address as opposed to computer name. This is definately due to the patches I noted above.

All clients are patched.

The one DC that is having trouble accessing the data server was unpatched, but I patched it yesterday. No effect.

The backup domain controller is NT isn't it? Just a guess.

If you aren't going to patch the server just give up on the whole thing You are not updating compatibility fixes, drivers, patches to prolems that may fix your issues, and in addition just dangling out security carrot and the whole lot. While I agree that sometimes these things do cause issues and you should look at what is changing - but that is what BACKUP is for and rollbacks etc. The risk of severely outdate machines for outwieghs an inconcenience that someone can't access a file share for an hour while the bug is worked out. A succesful server is a MANAGED server. ;) Just directing this at your boss not you. I hate to see how many corrupt or dropped packets or data storage issues you have on those file servers. :eek: I have had ENTIRE data stores lost from outdates SCSI drivers and bios updates I chose to put off.

Well, as far as security, the reply you'd get would be "We're secured behind our SonicWALLs".

*sigh*

Tis the same guy who won't let me get an IDS and some cheap server room security cameras because of the cost and it being "overkill".

I totally agree with you. I'm definately going to have to be creative to figure out a way to do this without patching.

I just came back from lunch, and something interesting has happened as well. I have one workstation and one BDC right here in my office, and the workstation shares the printer on the BDC. Well guess what? My workstation can't print to the server's printer now, all of a sudden, because of an "access denied" error.

It's gotta be related...or I'm just having one really bad day.

I definately agree with you guys that something's gotta be up with name resolution for these machines. Figuring out WHAT, now, that's gonna be the trick. Keep the ideas coming!

Ok, I think I'm onto something else.

Note I said in the last post that my workstation here in my office can't connect to the printer that happens to be connected to the BDC also here in my office. So I started thinking, could this BDC be the source of all my problems?

Sure enough, this BDC will not connect to the data server's shared drives either. It can see the data server in the browser, but will not connect to it. Meanwhile, this worksation of mine has "access denied" when trying to connect to the BDC. So, would this BDC be our pesky problem child then?

I'll try some stuff out and get back with you guys...in the meantime, if you think of something, throw it my way!