I have a tri-homed ISA server with internal users who access the web via HTTP on the external interface, and use local applications to access the servers in the DMZ hanging off the ISA server. I have created access rules to allow the protocols needed, and this works great as long as I don't define user access controls on the rules. When I do, expecting that the Firewall Client will pick up the authentication duties, it doesn't. The traffic is denied at the ISA server and interestingly, I get <domain>\<computername>$ as the Client Username in the logs.
LLi, what do you mean that some protocols don't support authentication? I thought the whole point of the firewall client was that it did the authentication for a user session using the Firewall Client control channel so that authentication could be used regardless of the application or client. The authentication is completely independant of the protocol - or so I thought.
Clint: I remember reading your post regarding CIFS and the firewall client; I'm not using that protocol or SMB in this case however. Some of the protocols are 3rd-party, so I've created user-defined protocols for them; a couple of the apps need to use RPC as well. I suppose I should be ready to hear that the Firewall client can't authenticate RPC connections either? Even if that was the case, I do have other apps which are using their own protocols, and they don't get authenticated either. Is there any way I can check whether the Firewall client is actually communicating properly with the ISA server? And any reasons why it wouldn't be, if it detects it fine both automatically & manually?
Bummage - you're kinda out of luck on the RPC auth as well - RPC <RpcSs> resides in SVCHOST just like SMB requests.
For the other apps, do they run as services, or just plain vanilla user apps? If it's a service, then whatever account is used to start the service will need to have access as that is the 'user' that initiates the connection. If that doesn't apply, you might consider taking a network sniff from that particular client to see if the FWC is even picking up the traffic - it should be on TCP 1745 initially.
The other apps are a mix of service- & user-run; I have in each case applied the appropriate group permissions. I do see connections to ISA on 1745 so I'm assuming this means that the FWC is at least doing something. I did read something about the clients getting their FWC configuration from the FWC installation share - is this correct? I thought it came down straight from the ISA sever when the clients connected. I haven't actually installed a FWC share anywhere in the network.
Would it make any difference if I published the servers these apps are trying to connect to, instead of just creating access rules? It seems silly that things like RPC, SMB, etc, which is precisely the traffic you would usually want to restrict as much as possible, are precisely the ones that you can't filter any better than a normal dumb firewall.
They get their initial config from the Firewall Client share but then periodically (every 6 hours or when the client is rebooted) pull down the current config from the ISA Server.
These apps don't run under the System user context do they? If so, then you'll need to look into the DisableEx entry for the Firewall Client for this app - normally, the Firewall Client doesn't process connections from services using the System account - you use DisableEx to override this.
I agree with you on the inability to control SMB and RPC by user (except in the VPN Client scenario). It's a bummer...
< Message edited by ClintD -- 8.Dec.2005 11:31:28 PM >
Would it do any good to create an IPSec tunnel just for those protocols? The apps all run under either a service or user account, not system accounts. ISA would lose visibility over the traffic but since [I'm assuming] it's not doing anything with them anyway that wouldn't be a big loss..
Failing that, maybe there are other RPC/SMB filters that ISA can use to inspect/verify the traffic to some extent?
As for the RPC/SMB filters, ISA can only verify the UUID called and a few other things (overflow protection for example) - for domain joined machines, once the initial RPC call is made, the rest of the communiation is encrypted using the Kerberos ticket for the key so ISA can't do much there.
OK well I'm going to use IPSec for another app that needs CFIS traffic on 445 ( :rolleyes: ) but I'm going to give this RPC filter thing a go for this instance. Well I'm going to try at least.. got problems with that as well... :(