DOS Client cannot connect to XP (Professional) SMB Server

[c2z4s9]

DOS Client cannot connect to XP (Professional) SMB Server

Please forgive the length of this message, I am trying to be comprehensive.

Let me first describe all of the contenders involved in this little affair. I have one MS-DOS 6.22 client that I will call “DOSM”, one Windows XP (Professional) system that I will call “XPM”, and a laptop (also running XP Professional) that I will call “XPLT”. The three above computers are connected via a network hub (not a switch). The goal is to successfully connect DOSM to XPM via NetBIOS over NetBEUI.

The problem, obviously, is that they cannot currently connect. As I just mentioned DOSM is running DOS 6.22, and using NetBIOS over NetBEUI. I have the other two systems: XPM, and XPLT configured to support the NetBEUI protocol. I have created shares on XPM and XPLT, configured file system permissions, and configured share permissions for the DOSM user to connect. I am not using the XP’s “simple file sharing” scheme, but am requiring real user (and password) authentication.

Interestingly enough, DOSM CAN connect to XPLT without issue, but can not connect to XPM. First, I tried to eliminate all of the “standard” mishaps associated with such a problem. I started by checking the XP firewall settings, and I believe they are acceptable. I have tested this connection with the firewall disabled. I have checked both group policy system settings and the security template for both machines (XPM, XPLT) attempting to remove differences between the two, or to see a potential reason why XPM would not authenticate the DOSM user, while XPLT would authenticate. I saw no appreciable difference in security settings between XPM and XPLT.

Next, I tried looking at the specific error received on DOSM. When attempting to connect (to XPM) I receive the following:

Error 5: Access has been denied

This is not the most helpful error message that I have seen in my time, but so be it. Checking XPM reveals slightly more information. I receive two errors in the security log of XPM that are of relevance here.

EventID: 680

This error message provides the DOSM user account connecting to XPM (the username is correct), and an error code: 0xC000006A.

EventID: 529

(Unknown user name or bad password).

After a little searching I quickly discovered that error 0xC000006A means that the client attempted a logon with a bad password. Interesting, says I. So it appears that DOSM is logging on XPM with the correct user name, but providing a bad password (please remember that DOSM can connect to XPLT).

Dig a little deeper. Viewing the network traffic between DOSM and XPM does not lend much more information. I have come to understand that the base protocol in question here (for authentication reasons) is SMB (server message block). During the initial handshaking that takes place, the two machines are supposed to determine an authentication scheme to use, and then authenticate based on that scheme. DOSM provides XPM with a list of those schemes that it supports. DOSM supports the following authentication schemes: PC NETWORK PROGRAM 1.0, MICROSOFT NETWORKS 3.0, DOS LM1.2X002. It is my understanding that DOS LM1.2X002 is essentially the same as Lanman 2.0, but provides DOS compatible error codes. XPM responds (to negotiate the protocols) with the authentication scheme it chooses to use. XPM says back “Dialect Index: 2, Greater than CORE PROTOCOL and up to LANMAN 2.1”. I am still slightly confused about which protocol it is really choosing here. Is XPM picking MICROSOFT NETWORKS 3.0, or DOS LM1.2X002? Perhaps this is the answer to the problem. It is clear that XPM is running in USER security mode, and wants to receive both a username and an encrypted password (what it calls a challenge/response).

Anyway, after choosing the authentication scheme and demanding a username and password, XPM waits for a response from DOSM. DOSM promptly responds with a username and encrypted password. This is where things break. Every single time XPM responds with “Access is denied” (this is packet information). Keep in mind that I can see exactly the same sequence of events occurring in communication between DOSM and XPLT. The difference is that XPLT authenticates DOSM’s user and allows access. Strange eh?

I have a couple of other things you may want to keep in mind. I have tried many different users for this connection between DOSM and XPM, and none of the users are authenticated. I always receive the same “bad password” error message in the security log (on XPM). I can connect to XPM from XPLT using NetBIOS over NetBEUI. Unfortunately, I am unable to recreate the same authentication scheme (because XPLT just supports more schemes; I could not lower the Lan Manager authentication level enough to enable only simple challenge/response. It just does more stuff).

One more thing, and this is important. After first setting up the XPM (which is a service pack 2) system, it COULD COMMUNICATE with DOSM. Yes, that’s right, DOSM and XPM were happily talking for a time. Between when it worked and when it broken I believe all I did was update windows via the windowsupdate web page. I suppose that I could start from scratch, destroy XPM, rebuild it and then test the network connection after each individual Microsoft patch (some 30, I believe), but I really really don’t want to do that. It is my feeling that a windows patch may have broken something in this system, or changed some obscure security setting which now will deny access from a legacy system such as DOS. I am praying that someone recognizes what it is and tells me. If someone had some idea of where I could potentially look next, I would be grateful.

[cluberti]

I would consider installing netcap (from the support folder on the XP CD) on the XP machine, then get a network trace via netcap of the issue occurring. The trace should show you what is actually happening in the SMB communications between boxes, but you'll need to install a program such as Netmon or Ethereal to open the resulting .cap file.

[c2z4s9]

I am currently using ethereal to look at the network traffic between machines.

I can see that both machines (DOSM and XPM) agree on an SMB dialect (Microsoft Networks 3.0), and then DOSM sends the username and encrypted password. XPM always rejects this logon, based on a bad password (information in the security log).

The traffic between DOSM and XPLT is exactly the same with one important difference, it works.

What could be set wrong (broken maybe?) on XPM?

[c2z4s9]

OK, here’s the deal. There actually exist two passwords for each user that is on the Windows XP system. Here is a snippet:

Password storage in the account database

User records are stored in the security accounts manager (SAM) database or in the Active Directory database. Each user account is associated with two passwords: the LAN Manager-compatible password and the Windows password. Each password is encrypted and stored in the SAM database or in the Active Directory database.

This second password is essentially the legacy password. Now, I had set in the local security policy "Do not store LAN Manager hash value on next password change." When you think about how I was configuring the systems this makes perfect sense because:

I would initially generate a drive using Windows XP and would set the DOSM (see above reference, this is the user that connects from the DOS Machine) user’s password. I would then set the security policy, which had the above mentioned setting. This would set that “Do not save the lan manager hash”, essentially the legacy password, upon change of password. So the deal is it would work just fine if I didn't change the password for this user. if I changed the password again – Even if I set it to the same password, DOSM's user would never work again because the Windows XP machine would no longer be able to authenticate using NTLM because there existed no NTLM password!!! So I would screw myself as soon as I changed the DOSM user password. With no NTLM password the system would automatically attempt to authenticate the only password that it had left, that is, the Microsoft authentication package (1.0) 's password. The DOS machine would be incapable of providing that password because its encryption, etc, schemes are so much simpler.

So the resolution is you must ensure that this “Do not store lan manager hash upon change of password” is set to DISABLED!!! That way the system will store the hash and hence have a NTLM password that it can use to authenticate legacy systems with.