- This topic is empty.
17. May 2012 at 16:43 #7355
Hi all –
Please forgive the fact that I’m a newbie here-
I may not provide the relevant information for you, but all you need do is ask and I’ll provide anything you need to know – perhaps with some help to get the info.
I’m a Cisco firewall engineer who has been asked to look into the reason
that previously working units have begun to fail.
3x servers- one doing Citrix licensing, one doing Xenapp, one doing WyseDM.
The V10LEs are trained to authenticate automatically via NTLM
as “Kiosk” and launch our corporate Intranet site.
-We have about 26 V10LE units on our network.
-Some are directly connected to the network (aka, in various Vlans on various floors of the core buildings)
-Some are connected over lan-to-lan VPN tunnels, with no ACLs in use (aka, all packets are sent over the VPN, no restrictions, no exceptions.)
-We use FTP to deliver a single wnos.ini from the server with WyseDM.
-All clients connect and use the same “launch.ica” file to launch an IE session to our corporate Intranet site.
-DHCP/DNS is provided by the remote firewall at each site, using the same DNS servers that are in use at the corporate site.
-No DHCP options are set for FTP, etc
-V10LE units do successfully do FTP sessions and retrieve their wnos.ini file. Any changes to this file are reflected in the remote unit, so I know they’re pulling the file and using it, and FTP logs also show this.
About two months ago, all the V10LE units located over the VPN tunnels began to fail at the NTLM authentication phase.
All units connected to the regular Vlan infrastructure are fine.
You can swap a unit back and forth from VPN to local Vlan
When on local Vlan, it will work fine.
When on VPN it will fail.
Regular XP/Win7 clients at the remote sites are unaffected.
A test Linux laptop not joined to the domain is able to open NTLM based websites in the corporate network without issues, so I don’t feel that the firewall is somehow trashing NTLM, but I could be wrong.
I’ve enabled all the logging I can in the firewalls and don’t see anything
going wrong, don’t see any denied packets.
It almost looks to me like the remote units simply don’t know where to send authentication to –
I’m not certain if they do authentication directly with the domain controllers, or whether they send the credentials to the WyseDM server or Xenapp server to be passed along to the DC.
Has anyone got clues as to how the v10LE units do NTLM over a VPN
and what info they require?
A few settings from wnos.ini that seem relevant:
SignOn=NTLM ConnectionManager=Maximize EnableOK=Yes DisableGuest=Yes IconGroupStyle=Default SaveLastDomainUser=No
Privilege=None HideSysInfo=Yes SuppressTaskBar=Yes HideConnectionManager=Yes
#AdminMode=Yes admin-username=encrypted_admiabcdefghi admin-password=encrypted_
# Time server is set to tick.usno.navy.mil
# WDM Server
Password=YYYYYY18. May 2012 at 18:33 #22374
Did I scare you guys with mention of VPN?
I’ve noticed a number of views, but no one answered..
I know this is only happening over a VPN tunnel –
But nothing has changed in the FW config that we can find-
I’m not asking for VPN assistance –
Just hoping someone knows more details about the process or steps the V10LE might be using to log in with NTLM..
If I understood whether or not the V10s are sending the username/password directly to a domain controller themselves, or proxying that data back through one of the other servers, etc —
..I’d have a clue about how to understand what might be borked someplace…
Does NTLM _require_ a functioning WINS server?
Could there have been something in the thin clients config that isn’t in wnos.ini which is no longer working?
I will most definitely handle any parts of the firewall piece, just looking for some advice on which tree in the forest to look in…
Thanks for any help you can offer-
And again, if I’ve somehow tread upon the toes of the ‘rules’ for first-time posters, let me know that too..
thanks19. May 2012 at 3:31 #22378
So it turns out that WINS is at least, a fix of some sort.
I enabled a WINS server, put it in the DHCP config of the far-side firewalls, and things work.
What I don’t understand is this:
– I have not had a WINS server on the network in a long time- we disabled our last one months before deploying these thin clients.
– WINS seems like a global fix- not something that would fix only the VPN attached thin clients.
If name resolution/browsing was the problem, I’d have expected all my thin clients in any routed network segment (aka different Vlan or over VPN link, since both are routed) to have failed.
Don’t understand how units on Vlans could work being on a different subnet/broadcast domain than the servers, yet the ones over VPN would not….
- You must be logged in to reply to this topic.