[Samba] Fwd: Windows user unable to change password over VPN with samba 3.6.20
gaiseric.vandal at gmail.com
Sun Mar 16 11:54:38 MDT 2014
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
NetBIOS name query request timed out
timeout was 2 seconds
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
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
#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.
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
More information about the samba