1. Computer problem? Tech Support Guy is completely free -- paid for by advertisers and donations. Click here to join today! If you're new to Tech Support Guy, we highly recommend that you visit our Guide for New Members.

DOS Client cannot connect to XP (Professional) SMB Server

Discussion in 'Networking' started by c2z4s9, Mar 24, 2006.

Thread Status:
Not open for further replies.
Advertisement
  1. c2z4s9

    c2z4s9 Thread Starter

    Joined:
    Jul 9, 2003
    Messages:
    21
    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.
     
  2. Tracker.ca

    Tracker.ca

    Joined:
    Mar 26, 2006
    Messages:
    3
    I am experiencing the same issues, DOS Client 3.0 (Drive Image boot disk) could connect with XP Pro for the last time in October 2005. When I tried in December, I could not get them to connect again... same problems yesterday!

    I don't have much to offer, but want to keep an eye on this thread...

    Tracker
     
  3. c2z4s9

    c2z4s9 Thread Starter

    Joined:
    Jul 9, 2003
    Messages:
    21
    Cool! I feel your pain! I am still working on this problem.

    I believe that the standard security template, applied when the operating system is installed (called "setup security"), sets a value that may be of interest to us:

    “Network access: Sharing and security model for local accounts”
    The default setting for this parameter is:
    “Guest only – local users authenticate as guest”

    Now, this "should" allow the DOS client to connect IF the guest account is not disabled. You may want to check the status of the guest account.

    If you are like me, and want your users to connect with a username and password, then you want to set this to "User -- local users authenticate as themselves."

    Check this setting by opening up My Computer / Tools / Folder Options / View (a tab at the top). From here look at the "Advanced Settings" window, scroll to the bottom, and check the status of "Use simple file sharing". If this has a check in it, then all of the users that connect will authenticate as guest (BUT the guest account must be enabled). If this does not have a check in it, then users will attempt to authenticate as themselves.

    I have not solved this problem, and on the "broken" system neither having the guest account enabled and using "simple file sharing" OR having users authenticate as themselves work, but it may be worth checking.
    Our two problems may just have the same symptom. I also suggest that if you are NOT using "simple file sharing" you check the share permissions AND the file system permissions (they must both be set) of the share in question. If you are using "simple file sharing" check the file system permissions of the share.

    I am under the impression that a windows update may have broken something that has to do with authentication for these legacy systems. I have discovered that a DOS client connects (via NetBIOS) to a Windows XP server using a different authentication scheme than when a Windows XP client attempts to connect to the same Windows XP Server.

    Currently, I am updating a test drive via the windows update web site one update at a time. There are about 30 updates to get me currently. Hopefully, one of these updates will break the DOS client connection to this Windows XP server on the test system (currently, it is working).

    Good Luck! We can figure this out!!!
     
  4. Tracker.ca

    Tracker.ca

    Joined:
    Mar 26, 2006
    Messages:
    3
    I got it fixed here... and it is so simple that I am ashamed that I lost so much time on this! :mad:

    Well, I got another laptop connected and was surprised to see that the DOS client could connect without problems... puzzling to say the least!

    Checking the solution for a similar problem a guy was having with Windows 98 and XP, I found that he fixed it by reseting the password on the XP box to the same password again(?!?!??!).

    Being desperate, I tried to reset the password on my XP Desktop to the same password, AND IT WORKED!!!

    I believe that the password is stored in multiple levels and maybe the lowest level (MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
    ) got corrupted, but because it doesn't affect XP to XP authentication, nobody realy notice until you get a DOS or WFW client trying to connect.

    Well, give it a try and let me know, OK?

    Tracker
     
  5. c2z4s9

    c2z4s9 Thread Starter

    Joined:
    Jul 9, 2003
    Messages:
    21
    I have attempted to reset the password on the system. I was unaware that the password was stored in multiple levels. How can I change the password and be sure that it is changed on these other levels? Do you know how to determine whether the MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 has become corrupt? I am aware of only one file assosciated with this package (msv1_0.dll or something similar). I replaced that file, to no avail!

    I'm glad you got it working.
     
  6. Tracker.ca

    Tracker.ca

    Joined:
    Mar 26, 2006
    Messages:
    3
    Well,

    AFAIK, once you reset the password, it changes for all authentication methods.

    You might have something else interfering with the logon process. Another thing I found is that you should have the digital signature turned off to allow low-level authentication to work.

    Local Security Policy / Security Options / Microsoft Network Server: Digitally Signed Communications (Always) - Should be Disabled.

    Tracker
     
  7. neilfairall

    neilfairall

    Joined:
    Apr 5, 2006
    Messages:
    1
    Fascinating. I have just started to experience the same problem, and changing the password did the trick right away. I'd love to see an MS answer to exactly what happened there, but I haven't been able to find a likely answer so far.

    My scenario: MS-DOS client (using TCP/IP in my case) to a Windows XP box. Exactly the same errors.

    I changed the password on the XP box and was immediately able to access it from the DOS client. Changed the password back to the one I was using previously and it still works.

    When I talk about changing the password I am simply talking about doing a CTRL-ALT-DELETE and changing it there - no logging off or rebooting or anything.

    Thanks for the tip, Tracker!
     
  8. c2z4s9

    c2z4s9 Thread Starter

    Joined:
    Jul 9, 2003
    Messages:
    21
    I have figured it out! Amazing.

    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.
     
  9. Sponsor

As Seen On
As Seen On...

Welcome to Tech Support Guy!

Are you looking for the solution to your computer problem? Join our site today to ask your question. This site is completely free -- paid for by advertisers and donations.

If you're not already familiar with forums, watch our Welcome Guide to get started.

Join over 733,556 other people just like you!

Loading...
Thread Status:
Not open for further replies.

Short URL to this thread: https://techguy.org/452497

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice