[Samba] Fwd: Windows user unable to change password over VPN with samba 3.6.20

[Gaiseric Vandal]

A little more information

The corporate firewall seems to block UDP port 137 connections.       
This does not affect access to file shares, which occur over TCP port 
139 (if netbios-over-tcp is enabled on the Windows client) or TCP port 
445 (if NBT is disabled.)       Packet capture on the server does not 
show any traffic on port 137 from any vpn clients , even tho traffic on 
most ports does get thru.    (138 seems blocked as well.)

The "nblookup" command on windows VPN clients (or the "nbtlookup" 
command on linux vpn clients) fails to contact the wins server, even 
when I speficially include the IP of the WINS server  (the WINS server, 
PDC and mail file server are the same machine.)

                C:\tools>nblookup /s IP_OF_WINS_SERVER somemachine

                Recursion is on

                Querying WINS Server: IP_OF_WINS_SERVER
                NetBIOS Name: somemachine
                Suffix: 20

                NetBIOS name query request timed out
                     timeout was 2 seconds


                C:\tools>





If I understand correctly, any password change traffic should happen 
over TCP port 139.        But I am guessing that , despite the use of 
the lmhosts file, the Windows client wants to do some initial 
communication with the PDC over 137.  I have not captured traffic from a 
non VPN client yet.


I have a support ticket open with the VPN vendor.    The VPN logs show 
it dropping "IP Spoofs" on traffic from windows VPN clients on port 137 
to the samba server.




-------- Original Message --------
Subject: 	Windows user unable to change password over VPN with samba 3.6.20
Date: 	Thu, 13 Mar 2014 10:35:12 -0400
From: 	Gaiseric Vandal <gaiseric.vandal at gmail.com>
Reply-To: 	gaiseric.vandal at gmail.com
To: 	Samba <samba at lists.samba.org>



I realize this is not a strictly a samba "problem" but I am hoping that 
there is a samba solution.


I have a samba 3.6.20 PDC.  I am running WINS.      We use an IPSec 
client VPN to allow users with Windows 7 laptops to connect to the 
office remotely.      The windows 7 laptops are joined to the Samba 
domain.       Password expiration policies are enforced.        When you 
login to a Windows 7  laptop offsite, it uses cached credentials.  There 
is no VPN connection until a user logs into his machine and starts the 
VPN.   At which point the client is already authenticated with cached 
credentials and does not need to connect to a domain controller.


Users are unable to change their passwords over the VPN. Change password 
with control-alt-delete results in an error message along the lines of
     "Configuration could not be read from the domain controller because 
it is either unavailable or access is denied."    Which is not 
unexpected since the user has not authenticated to a domain controller 
and the OS would not know how to locate one.


I tried with the "net user command" but no luck

            C:\>net user /myname newpassword / /DOMAIN
            The request will be processed at a domain controller for
            domain /MYDOMAIN /.

            System error 1355 has occurred.

            The specified domain either does not exist or could not be
            contacted.


            C:\>



Remote users can connect via RDP to Windows machines on the network   to 
change passwords.   They can also ssh into  unix or linux machines to 
change passwords with smbpasswd account. However when they log in to 
their laptops they still get a warning that the password is due to 
expire.     The supposed solution is to lock the screen then unlock the 
screen with the new credentials.  However this  won't work if the client 
does not an cannot locate and contact to DC.

The VPN client has a virtual NIC with an IP from the DHCP pool of the 
corporate DHCP server -  so it generally appears to be a node on the 
corporate LAN.    VPN clients can be configured to use the WINS server, 
but this did not help.    The VPN server does , by default, not allow  
Windows Networking (NetBIOS) Broadcasts to/from the VPN client.      I 
don't think we need it if WINS is used.

"nbtstat -c"  command did not show any entries with the IP address of a 
domain controller for machines connecting via VPN.  (it would for 
machines on the LAN.)


I have updated the lmhosts file on  one laptop


                 #
                 192.168.x.y     pdc         #PRE #DOM:MYDOMAIN #net 
group's DC
                 #20 chars in quotes
                 192.168.x.y   "MYDOMAIN       \0x1b"   #PRE


After a reboot, "nbtsat -c" shows a valid domain controller entry (<1C>)

         PDC                  <03>  UNIQUE 192.168.x.y        -1
         PDC                  <00>  UNIQUE 192.168.x.y        -1
         PDC                  <20>  UNIQUE 192.168.x.y        -1
         MYDOMAIN    <1C>  GROUP           192.168.x.y -1
         MYDOMAIN    <1B>  UNIQUE          192.168.x.y -1


But still no luck.  It is as if once I have logged in with cached 
credentials the laptop does not want to try looking for a domain controller.


Any ideas?


Is it possible to add a DNS entry to help clients locate domain 
controllers?  I know samba 3.x (similar to Microsoft Windows NT4) does 
not rely on DNS for locating domain controllers.   MS Active Directory 
users _SRV entries to help clients locate the appropriate "Ldap" server 
.      Which of course Samba 3.x doesn't use.  I thought there might be 
some way to use DNS to help Win 7 clients find Samba 3 domain 
controllers, even if they turn out to be Samba 3 and not Active 
Directory or Samba 4.


I have one user who's password will expire before he gets back to the 
main office.

Thanks