Hi Vin, Thanks for your reply. I'm currently in contact with RSA's Asia Pacific helpdesk and have a case open with them. Apparently someone on the list (possibly you ?) forwarded my email to RSA and it's been bouncing round for a while :-). RSA's representative informed me that I should just need to set the firewall to be a client of the ACE server and then to edit the sdconf.rec file to use the DMZ interface's address. We'd done as much, and were still having no joy. Through the use of sniffers I've found out that the firewall is actually not passing the traffic on. (The FW is Borderware 6.1.1 with the recommended patches etc) Your message got me thinking, if MAC addresses are going to cause a problem, would it be possible to take the NIC from the firewall, configure the sdconf.rec file on a machine using that card and then replace the NIC back in the firewall ? Time isn't a primary concern at the moment, so if waiting three or four months will allow us to us ACE 5.0 that might be an option. Thanks for your help, Alex Hague -----Original Message----- From: Vin McLellan [mailto:[EMAIL PROTECTED]] Sent: Thursday, 18 January 2001 10:42 To: Hague, Alex Cc: [EMAIL PROTECTED] Subject: Re: Secure ID through firewall and other Extranet Authentication Alex Hague <[EMAIL PROTECTED]> queried the FW Listocracy: >Has anyone managed to get secureID authentication working through a >NAT'ing firewall ? How do others on the list secure their extranets ? Hi Alex, Your assumptions about why you have had a problem passing the ACE client/server protocol through your NATing Firewall -- to support RSA SecurID authentication -- are, unfortunately, right on target. You wrote: >I think that problem is our Firewall using MAT / NAT. Unfortunately we are >unable to use anything but NAT when coming from the DMZ to the internal >network. It's my guess that the secureID agent includes it's IP Address in >the information being sent to the ACE server, and of course the IP Address >that the information comes from is actually the firewall's internal >interface. In the ACE client/server interaction, a MAC is used to check the validity of the "OK" response sent from the ACE/Server (behind the firewall) to your ACE/Agent. Predictably, because of the NAT, the message can not be authenticated. There are ways to get around this, but you will probably need direct support with RSA's local office or its NZ reps. Your RSA Sales Support Engineer (SSE), or RSA's Customer Support, should be able to offer you the traditional work-around -- although I can't say whether it would be appropriate, since I don't understand your threat environment. Alternatively, they may suggest you wait for the new ACE/Server 5.0, now in beta, and expected to be released sometime in the next couple of months. The 5.0 ACE/Server is harbinger for a whole new suite of ACE/Agents and proxies. ACE 5.0 will also introduce a new ACE client/server protocol which -- by rumor at least -- may allow you to sidestep the NAT issue completely. There are a dozen big ACE 5.0 beta sites out there, but I don't think they are allowed to comment about the new technology until it is announced. I'm a consultant to RSA myself (so please appropriately discount my remarks), but I don't know enough about the new products to offer meaningful feedback. You really do need to talk to some well-informed RSA folk, either in RSA Sales or Customer Support: <www.rsasecurity.com>. The traditional fix for this problem was clever, but it also had some inherent limitations. The ACE/Server has historically managed backwards compatibility -- through a decade's worth of ACE/Agents -- by checking the version number in the sdconf.rec file in the ACE/Agent. IP addresses were introduced into the ACE client/server exchange with, I think, the ACE/Server v. 2.3, to provide an additional level of security for the interaction. RSA's Customer Support engineers have a trick whereby they can build the crucial ACE file (sdconf.rec) on a pre-2.3 ACE/Server -- but with your information -- and then graft that file on to your more-modern ACE/Agent. The net effect would be that one or more of your ACE/Agents would be seen as a pre-2.3 Agent by your ACE/Server, so (to maintain compatability) the ACE/Server would not include the MAC check. Since it sacrifices some security, this is not a universal fix. Quite frankly, it is not always appropriate. If the new ACE protocol finally does away with this problem while maintaining full and appropriate security, as I expect, there will probably be a lot of happy campers out there among RSA's huge installed base. Surerte, _Vin PS. As I hope is self-evident, only RSA speaks for RSA. ----------------------- Mr. Hague wrote: >Detail: > >We're investigating an extranet solution. We have our internet servers on a >DMZ and are going to add an extranet server to the DMZ. We already have a >SSL Relay (Apache compiled with mod-ssl, mod-proxy and mod-rewrite) which we >use for our OWA server. We plan to use the SSL-Relay to encrypt our extranet >traffic and I don't expect to have any problems doing this. The platform for >the actual extranet will be IIS 4 on NT 4. > >The area that is proving to be a bit difficult is authentication. We don't >want to have the extranet server on our internal network (which we would >have to do if we wanted to authenticate against domain accounts, or have a >huge hole in the firewall between the DMZ and the internal network ! (not an >option)). > >We've come up with the following possible solutions: > 1 - Have a generic username and password for access to the extranet >(this would just mean a user account on the Extranet box) > 2 - Assign each extranet user a username and password (multiple >accounts on the extranet box) > 3 - Some sort of proxy / replication of domain account information >to the extranet box > 4 - secureid authentication > >Of these options we've decided that the only one that provides good security >4. To issue secureid tokens to our extranet users and to use the ACE IIS >plugins to authenticate them. We can successfully set everything up on the >internal network, but as soon as we put a firewall in between it all stops >working. We're opening up port 5500 UDP from the DMZ to the internal >network, but there's no joy. We've used a sniffer to check that this (port >5500 UDP) is the only port being used. > >I think that problem is our Firewall using MAT / NAT. Unfortunately we are >unable to use anything but NAT when coming from the DMZ to the internal >network. It's my guess that the secureID agent includes it's IP Address in >the information being sent to the ACE server, and of course the IP Address >that the information comes from is actually the firewall's internal >interface. > >I'm looking for suggestions on: > 1 - Anything that I can try to get the secureID authentication >working through a firewall > 2 - How other people on the list secure their extranet (pros/cons of >methods that have been chosen and relevant network design / structure) > 3 - Anything else that maybe relevant > >Looking forward to the responses, >Alex - [To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe firewalls" in the body of the message.] - [To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe firewalls" in the body of the message.]
