First mistake is when someone sets up a network, and uses a valid internet domain when they set up the server. I have more than a few customers who cannot access their own web sites because AD uses DNS, and we have the same name space used for two purposes.

Hi Ned, you mean if someone names their AD tree "MyCompany.COM" instead of bumping it a level such as "Corp.MyCompany.COM" ?? Does DCPromo really let you do that?

Or... you can seperate them completely by using MyCompany.LOCAL, though Microsoft Best Practices do prefer the method you described.

The trouble with corp.mycompany.com:

If I control the "public" DNS for mycompany.com (as a service provider) then the IT staff at "mycompany" has to either mirror my infrastructure, or they need me to delegate (one or more NS records pointed at their name server(s)) the "corp" subdomain so that queries that end up outside end up back inside.

That does two things: it means there is a path from the dot all the way to every desktop on the LAN, and it means some extra coordination (which I'm fine with, after all I'm a service provider) but it does add a little complexity to what could have been two completely separate namespaces.

My main complaint about DNS as a replacement for WINS is that these issues didn't exist when there was one method for finding names on the LAN and another for accessing resources in the rest of the world. They could have accomplished that by using DNS, but just changing the port -- so the DNS resolvers could tell if they needed the internal database or the external database (with recursion).

---

... and when I see "mycompany.com" I frequently find that the server was sold by a consultant who is a Microsoft Certified Systems Engineer.

... {sigh} lots of those guys can't architect their way out of a paper bag.

That's because it wasn't part of the MCSE class.

Actually, I think the root cause is the lack of a robust NCTP as part of the IP protocol suite.

We've got SMTP, and SNMP, and NTP, and NNTP, and TFTP, but there are no implementations of NCTP, and no RFC describing it.

---

I like this post best, I was working to stay away from "Anything Policy." As there are Nasty things that can bite you... The Good News is that "policy" can be exported and carried to "another machine" and imported. Once again that adds a layer of complexity. I have connected remote resources TCP/IP only with authenication. There are tools that will allow you to do that.

Well, I work in an environment where I have an older Samba server offering some shares I need access to that I couldn't access when I upgraded to Windows 7 on my laptop. What I found that worked was to dumb the Windows 7 system down to the older NTLM. I found this on the Web and it worked perfectly fine for me:

On the Windows 7 Laptop:

Control Panel - Administrative Tools - Local Security Policy
Local Policies - Security Options
Network Security: LAN Manager Authentication Level
"Send LM & NTLM Responses"

Minimum session security for NTLM SSP
Disable "Require 128-bit encryption"

This should let your Windows 7 client access shares from a Samba or older Windows based Server. The caveat being that you have now downgraded your Windows 7 client to a much less secure security environment. If your file sharing is all at home and behind a firewall, it's less of a concern. But tighter security is always a good thing in the world of computers these days...

This covers your concerns about being able to access the shares, with your stated issues being the NTLMv2 and 128-bit encryption. But even when I couldn't access my Samba shares, I could still list them. It just couldn't negotiate a secure connection to access them. So your ultimate problem may be different.

In the world of SMB shares, there's normally a BrowseMaster that keeps the list of resources available. And by default, the newest version MS O/S is going to want to take that role. Maybe there's your problem then... As I understand it, the installation of A/D will actually trump the O/S version card. The A/D Domain Controller wins over the latest O/S. And should by default enable the BrowseMaster functionality, whereas your workstation level installation on the Laptop may not have offered to be part of the BrowseMaster elections. Which would leave your older server offering the shares as the BrowseMaster. Which, oh by the way, you can't establish a secure connection to to access the list. Maybe that is the issue. (My Samba server is a member of an A/D Domain so it wouldn't have been the BrowseMaster. So my Win7 Laptop *could* get the list from the network, even when it couldn't authenticate to access the shares...)

When I setup my Win7 RC1, I setup simple sharing on the network. I went into the Network adapter settings and under Advanced setting, "WINS" ENABLED NetBIOS over TCP/IP (My home router does not provide that). The net result is that NetBOIS Ports 136-139 are enabled for NetBOIS traffic (on the Private Network). My Server handles the master Browser information. My first connection to my Server File share was from an Adminsitrative Command pronter withe simple statement.

net use z: //servername/sharename /U:administrator *

The net effect was this contacted the server and asked it there was a share there by the name that I could connect to at the Lowest Protocol level. It prompted me for the "password" which I typed in. I connected.

So on my home network, I Do Not have DNS setup, I Do No have WINS setup and I Do Not have Active Directory setup.. The Server takes care of the Master Browser. I do have the very "chatty" NetBIOS installed.

Important: In my Router Firewall I DO Block ports 135 through 139 and 445 which prevents the outside world from seeing my NetBIOS Traffic. Or just "ANYONE" trying to connect. Many inexspenive routers can leave these ports open to teh world... That is why I HATE Linksys! After rebuilding a machine actually saw someone attempting to break via NetBIOS. Before those ports were specifically blocked. They danced me around until the router was out of warranty and then told me to have a nice life.

I will say that I really like the improvements in the Win7 Firewall compared to Vista. Vista's was Braindead. But then, I have managed firewalls before and have and idea of what they should look like.


Regards

---

Please consider a Donation to the Seti Project.

or novell network shares

Just so long as you're not still running IPX/SPX?? :-)

IPX/SPX had one huge advantage not shared by NetBIOS over TCP/IP: it's drop-dead simple.

Our "modern" windows networks were born as an IBM product designed for networks around five nodes, and have been continually kluged to make them "scale" to the size of an enterprise. "Browsers" to cut down on broadcasts, "Master Browsers" to cut down on browser traffic, Domain Controllers to layer better security, WINS to map NetBIOS names to IP addresses, then the DNS kluge to replace WINS (and put internal and external resolution into the same pile) and finally Active Directory.

All of that while IPX just worked.

If I remember my networking history correctly NetBIOS over TCP/IP is really just a hack.

In the begining Windows used NetBEUI and Browse Masters/Domain Controllers (pre-Active Directory) basically provided a mechinism for replicating computer names across logical ethernet segments. NetBEUI networks were also drop dead easy. The only requirement was a unique computer name.

NetBEUI wasn't a routable protocol. NetBEUI was also a very chatty protocol, I remember one installation where we had a thick net backbone and 100 nodes, network utilization at night (machines idle) was something like 15%. Thick net was a 10 MBit network.

IPX/SPX was routable, and primarily used in Novell Netware environments.

Basically both Novell and Microsoft saw the writing on the wall with TCP/IP becoming the standard and changed directions.

Microsoft created WINS as a way to migrate name resolution of computer names from a NetBIOS/NETBEUI centric environment to the longer term DNS name resolution scheme.

I haven't tried lately, but I believe in the Active Directory/DNS world, you can do away with WINS. Both the UNC spec and the SMB/CIFS spec support DNS name resolution. The computer browser lists are handled via UDP I believe.

---

----- Rom
BOINC Development Team, U.C. Berkeley
My Blog