----- Original Message -----
Sent: Thursday, July 27, 2000 5:15
PM
Subject: RE: [FW1] ACE -URGENT
Hi
Victor,
Where would you put the sdconf.rec file on the FW ?
I
was going through the authentication tab for defining user authentication
on the firewall and when I select from the pull down menu "SecurID", it shows
that there are no specific settings for it on the firewall. Now as I
understand from your comments and after reading the RSA paper is that the FW
has the ACE/Agent embedded in it. The only thing that I need to define is that
on the ACE server itself and copy that sdconf.rec file over to the FW, is this
correct?
Gulrez Jamadar
Lucent NetworkCare
Network Systems
Engineer
CCNA,MCSE,CNE
1500 Broadway, Suite 808,
NY, NY 10036
Page- 1-800-453-6775
Tel- 1-212-398-5650 x382
Hi gulrez
1. You don�t need to install software on each
FW. ACE/agent is embedded in FW-1. The only thing you need
is copy sdconf.rec file from ACE/Server to FW-1 and select in FW object
properties, SECURID as a authentication scheme allowed.
Then, in ACE/Server, you need to define your FW
as a ACE/Server Client.
2. You can avoid the burden of maintaining
multiple user databases by defining a user
named “generic*” whom
FireWall-1 treats in a special way. FireWall-1 applies the restrictions
specified in the User Properties window (for example, Allowed Sources), but
for authentication purposes, uses the name typed in by the user instead of
“generic*.” In this way, the external authentication server “sees” the
user’s real name and authenticates him or her accordingly.
You can use the generic user feature as
follows:
1 Define a user group named
SecurIDUsers (for example).
2 Define a user named
generic* as a member of SecurIDUsers.
3 Specify SecurID as the
Authentication Scheme for generic*.
4 Add a rule to the Rule
Base similar to this:
Source
Destination Services Action
Track
Install On
SecurIDUsers@Any
tower telnet
UserAuth Long Log
Gateways
5 Install the Security
Policy.
NOTES ABOUT USING GENERIC* USER
- By using this feature with an external
server, you disable VPN-1/FireWall-1’s
ability to detect invalid user
names.
The responsibility of authenticating the user is passed to the
external
server. You will only get an alert or log if the authentication
fails on the
external server. Without this option, it is possible to get
an alert or log
when an invalid user name is entered.
- By
default, all the users defined in the external server are allowed
access.
There is no way to treat the users differently (but see item 3
below). The
System Administrator should carefully consider the
implications of allowing
this blanket access.
- If you wish to
deny access to a specific user, define that user in the VPN-1/
FireWall-1
User Database and set the user’s Authentication Scheme
to
Undefined.
- To disable this feature, delete generic* from the
VPN-1/FireWall-1 User
Database, or set generic*’s Authentication Scheme
to Undefined.
- This feature does not work with the S/Key and
VPN-1/FireWall-1 Password
Authentication Schemes.
The user generic*
will always fail S/Key and VPN-1/FireWall-1 Password
authentication,
because these schemes are implemented directly by VPN-1/
FireWall-1 and
not by external servers, so their users must be defined in
the
VPN-1/FireWall-1 User Database.
Nevertheless, there is still an advantage
to be gained by defining a user
generic* with the VPN-1/FireWall-1
Password Authentication Scheme. An
attacker who guesses at a user name
will not see the error message
“unknown user.” Instead, the attacker will
see a message indicating that
the authentication failed, and will not
know whether it is the name or the
password that is
invalid.
- generic* cannot be used as the name of a real
user.
Best regards,
Victor Barrientos
