locked
Windows 7 too secure for old Samba software RRS feed

  • Question

  • I am using an old version of Samba on a QNX 4 system to access shared folders on a Windows system.  Unfortunately, it is not possible to upgrade the Samba software.  Everything has worked fine for years with Windows 95, 2000 and XP, but I cannot get it to work with Windows 7 Home Premium :-(
    My Advanced Sharing Settings are:
      Network Discovery - on
      File and Printer Sharing - on
      Public Folder Sharing - off
      File Sharing For Devices Using 40 or 56 Bit Encryption - on
      Password Protected Sharing - on
      Use user Accounts and Passwords To Connect To Other Computers
    Security settings for the shared folder - the remote user has Allow for everything
    Advanced Sharing - caching - not available offline
                              - permissions - the remote user has Allow for everything
    There is a Standard user with a name and password matching the remote user information created.
    Using this user/password combination from a Windows XP system, I can access the share on the Windows 7 system.

    So the issue has to be that the security protocols being used by Windows 7 are too advanced for the old Samba software.

    I have tried the following registry modification:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    Created key LmCompatibilityLevel
    Tried values of 1 and 0 (including rebooting)

    So far, no luck.  What other registry changes are possible to dumb down the security ?
    Thanks !
    Friday, January 8, 2010 4:31 AM

Answers

  • I suggest posting you entire smb.conf file so I can see what changes, if any, are needed.

    It is located in /etx/samba/smb.conf



    Vote if answered or helpful, I am running for Office (joke)! IT/Developer, Windows/Linux/Mainframe

    Server: ASRock P4-2GHz, 1.5 GB RAM, Linux Server, need IDE/SATA disks for my chess site

    Workstation: Asus M2NBP-VM CSM, Athlon64 X2 4200+ 65W CPU, 2GB RAM, x600, 320GB + 160G backup, Windows 7 Ultimate x64.
    Saturday, January 9, 2010 7:50 PM

All replies

  • I am on a private network, so I will settle for little security and something that works.
    I am totally stuck with Samba 2.0.7 on QNX4 - very old.

    smbclient -L WindowsXP
    This works fine to a Windows XP system and shows the list of shares.
    smbclient -L Windows7
    This fails to the Windows 7 Home Premium system.  ERRDOS - ERRunsup (The operation is unsupported).
    smbclient -U user //Windows7/share  - does connect and work, providing access to the share for manual file transfers.

    SMBfsys &
    user_smb user 'password'
    mount_smb  //Windows7/share  /mountpoint   - this fails permission denied

    But I am wondering whether this message is bogus if SMBfsys is unable to query for the share.
    Saturday, January 9, 2010 5:41 PM
  • Ok.  Here is my config file.  Note that it has been unchanged for more than a decade.  The printers are no longer connected to the QNX system.

    smbclient -L Windows7 fails, so the QNX system cannot get a list of the shares available on the Windows 7 system.
    What has changed about the ability to list shares on Windows 7 compared to Windows XP ?

    Thanks !

    ; /etc/smb.conf
    [global]
     netbios name = mercury
     load printers = yes
     printing = qnx
     security = user
     revalidate = no
     username map = /etc/smb.map
     encrypt passwords = yes
     workgroup = WORKGROUP
     guest account = nobody
     lock directory = /tmp/spool/smbd
     message command = popmsg %s &
     interfaces 192.168.1.101/24
     log file = /syslog/smbd
     browseable = yes
     status = yes
     dead time = 15
     keep alive = 300
     local master = no
     preferred master = no
     remote announce = 192.168.1.255/WORKGROUP

    [printers]
     path = /tmp/spool/smbd
     writeable = no
     printable = yes
     read only =yes
     public = yes
     guest ok = yes
     print command = /bin/cp %s /pr/smb; rm %s
     lpq command = /usr/ucb/lprq -P %p

    [homes]
     vaid users = Mercury
     writeable = yes
     browseable = no
     create mask = 0600
     directory mask = 0700

    • Proposed as answer by Gaffy13 Monday, October 3, 2011 11:38 AM
    Friday, January 15, 2010 9:37 PM
  • I tried changing the mask values, but it still fails, as I expected.  The mask values relate to Windows accessing shares on the QNX system.  The problem I am having is with the QNX system mounting shares on the Windows 7 system.

    I type the following on the QNX system, to troubleshoot QNX failing to mount the Windows shares:
      smbclient -L WindowsXP         This works fine to a Windows XP system and shows the list of shares.
      smbclient -L Windows7           This fails to the Windows 7 Home Premium system.  ERRDOS - ERRunsup (The operation is unsupported).
    Tuesday, January 19, 2010 4:32 AM
  • Just a point here, but the OP says he is accessing 7 FROM *nix. In this case the smb.conf is not involved. That is for the *nix server process.

    With an old samba client, your problem most likely relates to communications-signing.

    1: Disable SMB2 on the 7 box if you haven't already. It's buggy. And exploitable!

    2: in the group policy editor (gpedit.msc) turn off the policy which enforces "Always sign communications"

    Windows Settings/Local Policies/Security Options: Digitally sign server communication (Always) >Disabled.

    (I think the latter may be equivalent to the registry key you changed. Give it a try anyway.)
    Tuesday, January 19, 2010 8:54 AM
  • ..and your point?

    BTW, setting 777 permissions on a unix filesystem is inadvisable if the box has any Internet-visible services. 770 is safer.

    Wednesday, January 20, 2010 8:19 AM

  • the OP asked :

      What other registry changes are possible to dumb down the security ?

    In a related note, what other legacy support was turned off in windows 7 networking?

    I'm having a similar issue that I've narrowed down to shares on a windows 7 system.  Something in that final packet sent back to the NON MICROSOFT SMB CLIENT is not being read correctly, and it's something that even Windows XP manages to do correctly out of the box.

    Oh, and that NON-MICROSOFT product is still working with XP shares.


    Either:

    It's busted because it's coded wrong in windows 7

       or

    It defaults to being incompatible with legacy clients in the policy settings, such as compelling NTLM v2 client support is now the default in windows 7.

    Sunday, January 24, 2010 8:50 PM
  • I resolved my issue by uninstalling Windows Live sign in assistant on the windows 7 system.  Go figure.  Found it in an xbox media center thread.  Tried it because nothing else has worked so far, and voila.

    Regardless, I read his issue as being one of accessing shares on windows 7 from QNX as a client.

    The samba spec does include a smb client running on linux, but he may be mistaken thinking that his implementation of samba includes using it to access windows shares.

    Tuesday, January 26, 2010 1:34 AM
  • I finally got it working, so I thought I would post what I did here in case it is of assistance to someone else.

    Just to clarify, QNX is _not_ a Linux distribution.  QNX is a POSIX-compliant (meaning it looks just like UNIX), realtime operating system.  It is commonly used for process control, industrial automation, medical systems etc.  I am using a really old version that is impractical to upgrade due to a huge porting effort for many different applications, including Samba.

    I am using Samba backwards to the way most people think of it.  QNX added to the old version of Samba with a utility called SMBfsys, which allows mounting Windows shared folders and printers so they can be accessed by applications on the QNX system.  So a QNX executable can modify files on drive C: and print to Windows printers and so on.  Samba can still be used in the normal sense to allow Windows users to access files on the QNX system, but that is not how I am using it (and at this point, it only works with Windows XP and earlier, but I am not troubleshooting it).

    I finally solved the problem by using Wireshark to analyze the packets.  It is pretty good at displaying the message content.  It turned out that the old version of Samba was sending a Lan Manager encrypted password, but Windows 7 didn't have a copy to compare that with, so it produced a permission denied error.

    Windows Home Premium does NOT include the group policy manager, so everything must be done with registry modifications.  Good luck to typical home users that might ever try to connect a Windows 95 computer to Windows 7 !

    The following registry settings were needed:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    "LmCompatibilityLevel"=dword:1         -allow older Lan manager style messages
    "NoLmHash"=dword:0                       -store the older, less secure Lan Manager encrypted password

    HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Netlogon\Parameters
    "AllowNT4Crypto"=dword:1                -allow less secure encrypted passwords (intermediate keys must be created)

    HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters
    "RequireSecuritySignature"=dword:0   -don't require new message signatures
    This value may have already existed, I don't remember



    • Proposed as answer by themightygirth Tuesday, March 23, 2010 5:37 PM
    Tuesday, February 2, 2010 3:48 PM
  • Thanks for this post. I have nearly the opposite problem. Samba 2.0.2 server with a Win 7 client but with the same issue

    I found the following worked; I added item 3 and I think section 2 may not be required as I think you may have typo'd

    1) in hklm\system\currentcontrolset\control\lsa, created LmCompatibilityLevel = dword "1", changed NoLmHash from "0" to "1"
    2) in hklm\software\policies\microsoft created key netlogon
        in hklm\software\policies\microsoft\netlogon created key Paramaters
        in hklm\software\policies\microsoft\netlogon\paramaters created AllowNT4Crypto = dword "1"
    3) in hklm\system\currentcontrolset\services\netlogon\paramaters created AllowNT4Crypto = dword "1"
    4) in hklm\system\currentcontrolset\services\lanmanserver\paramaters requiresecuritysignature was already = dword "0"

     

    Anyway, it works now and it didn't before.

     

    Gareth

    Tuesday, March 23, 2010 6:35 PM
  • I searched my registry to confirm.  I have:
    HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Netlogon\Parameters
    "AllowNT4Crypto" as a dword with a value of 1

    I think that is what fixed it for me. 

    Tuesday, March 23, 2010 8:10 PM
  •  

    hello,

    I m having the same problem with samba 2.0.7, it does not connect with windows 7 ultimate. I tried all the posibilities mentioned by you but still haven't got through. Here is my smb.conf

    # Samba config file created using SWAT
    # from frbnotebook (192.168.152.90)
    # Date: 2005/07/12 16:02:07

    # Global parameters
    [global]
        netbios name = MACHINE103
        security = SHARE
        guest account = root

    [all]
        comment = all files on this computer
        path = /
        read only = No
        guest ok = Yes

    So please try to figure my problem ...

    Thanks,

    Maulik.

     

    Saturday, April 3, 2010 1:00 PM
  • After you make the registry change to set "NoLmHash" to 0, it is also important to change the password of the user account you are attempting to login as.  By changing the password you ensure that the legacy lan manager password hash is generated and stored.  The actual password doesn't have to change, you can use the same one, just make sure to go through the CTRL-ALT-DEL -> Change Password process.

    This made the difference for me, and I had a similar problem where a QNX system was trying to access windows file shares on Windows 7 & Vista with plain-text passwords.  These are the steps I had to make to get it to work:

    Change the registry settings:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    "LmCompatibilityLevel"=dword:1         -allow older Lan manager style messages
    "NoLmHash"=dword:0                       -store the older, less secure Lan Manager encrypted password

    Run "gpupdate /force" so these settings take effect.

    Change the password (to the same password) for the user(s) that need to connect.

    Thursday, December 16, 2010 9:09 PM
  • Sorry to everyone that posted before me, and, Sorry to be resurecting such and old post, but I just HAD to do it.

    Did any of these people that replied to this post actually read what was written? I have to wonder...

    " I am using an old version of Samba on a QNX 4 system to access shared folders on a Windows system "

    AND.....

    "  Public Folder Sharing - off" on the above mentions windows share

    EQUALS....

    NO CONNECTION.

    How many people attempted to answer what they thought was the question?  Why didn't they just read the question and say...

    Please turn on public folder shareing if you want that folder to be seen by a unix box...

    sheesh... So much work to answer the wrong question.


     

     

     

    • Proposed as answer by biospot Saturday, January 14, 2012 6:37 AM
    Saturday, January 14, 2012 6:36 AM
  • try using mount.cifs //ip/share /directory -o user=xxx,rw,pass=xxx

    Tuesday, January 17, 2012 9:01 PM
  • Hello,

    I had the same problem: had to copy files from Windows 7 pro to samba 2.0.1 ...

    The solution here is: FTP. We made user to connect to the samba and it works fine.

    I hope it works for You too

    Thursday, June 28, 2012 9:44 AM