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.
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
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.
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
[EMAIL PROTECTED]
Tivoli certified Consultant
RSA Security Certified RSA ACE/Server Engineer
Tel: 54-11-4819-3903
Fax: 54-11-4811-7103
Telef�nica
unifon
www.unifon.com.ar
Tivoli certified Consultant
RSA Security Certified RSA ACE/Server Engineer
Tel: 54-11-4819-3903
Fax: 54-11-4811-7103
Telef�nica
unifon
www.unifon.com.ar
----- Original Message -----
From: Gulrez Jamadar <[EMAIL PROTECTED]>
To: 'Victor Barrientos' <[EMAIL PROTECTED]>
Sent: Thursday, July 27, 2000 10:19 AM
Subject: RE: [FW1] ACE -URGENT
>
> First of all, thanks for your inputs. A couple of questions
>
> 1. Do you have to install software on each client machine or its independent
> of the sytem used as I need to authenticate each user individually. I know
> that on Checkpoint FW, there is a tab in the user properties window which
> allows you to select the type of authentication each client requires.
>
> 2. Do you have to create users on both the firewall as well as the ACE
> server ? As to my understanding you would have to because in the FW rulebase
> you are selecting a group@network which requires authentication. So I would
> assume that you would have to create users at both ends.
>
> The scenario in my network is that network A has some users who need access
> to network B connected through a T1 line having FW1 on my side i.e net A. I
> need to deny access to everyone else except this user group and at the same
> time authenticate each user of this group to maintain each individual
> responsible for any incident. The authentication mechanism needs to be
> flexible in terms of protocols or applications used.
>
> Any other method which can be used here?
>
> Thanks.
>
> Gulrez Jamadar
> Lucent NetworkCare
>
>
>
> -----Original Message-----
> From: Victor Barrientos [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 26, 2000 4:16 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [FW1] ACE
>
>
> Hi Gulrez,
>
> Security Dynamics ACE/Server software provides SecurID identification
> and authentication
> of users on TCP/IP networks.
> The ACE/Server works with SecurID tokens to authenticate the identity of
> users, granting
> access only to authorized users on valid ACE/Agents. The ACE/Agent software
> runs on a
> number of different platforms so that a variety of network resources can
> take advantage of
> ACE/Server protection. Firewall-1 is one of them. ACE/Agent is embedded in
> FW-1 and works fine.
> The ACE/Server integrates a commercial database application developed by
> Progress
> Software Corporation to allow for scalability to large numbers of users and
> tokens and to
> provide programming interfaces for writing custom reports that can include
> ACE/Server and
> other data.
> The ACE/Server also includes a toolkit for creating custom
> administration applications. The
> Administration Toolkit consists of functions and executables that can read
> from and write to
> the ACE/Server databases.
>
> Best Regards,
>
> [EMAIL PROTECTED]
> Tivoli certified Consultant
> RSA Security Certified RSA ACE/Server Engineer
> Tel: 54-11-4819-3903
> Fax: 54-11-4811-7103
> Telef�nica
> unifon
> www.unifon.com.ar
>
>
>
>
>
>
>
>
>
>
>
>
> ----- Original Message -----
> From: Gulrez Jamadar <[EMAIL PROTECTED]>
> To: 'Victor Barrientos' <[EMAIL PROTECTED]>
> Sent: Wednesday, July 26, 2000 5:00 PM
> Subject: RE: [FW1] ACE
>
>
> > Hi Victor,
> >
> > Iam at a client wherein they are planning to deploy some kind of
> > authentication server which should integrate well with their Checkpoint
> FW1
> > system.
> >
> > Any suggestions? How is the RSA secuID application?
> >
> > Gulrez Jamadar
> >
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Victor Barrientos
> > Sent: Friday, July 21, 2000 11:47 AM
> > To: Grzegorz Rymarski
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [FW1] ACE
> >
> >
> >
> > Grzegorz,
> >
> > ACE/Server client is built-in in FW-1.
> > The only thing you need is copy sdconf.rec file to your Firewall (/var/ace
> > on UNIX Firewall, \winnt\system32 in NT Firewall) and define an user with
> > SecurID authentication method in your Firewall.
> >
> > If you need more information, feel free to contact me.
> >
> >
> > Victor Barrientos
> > Security Engineer
> > [EMAIL PROTECTED]
> > Tivoli certified Consultant
> > RSA Security Certified RSA ACE/Server Engineer
> > Tel: 54-11-4819-3903
> > Faxl: 54-11-4811-7103
> > Telef�nica
> > unifon
> > www.unifon.com.ar
> >
> > ----- Original Message -----
> > From: Grzegorz Rymarski <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Friday, July 21, 2000 12:24 PM
> > Subject: [FW1] ACE
> >
> >
> > >
> > > How can I integrate my Firewall-1 with ACE Server?
> > >
> > > [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> >
> ============================================================================
> > ====
> > > To unsubscribe from this mailing list, please see the instructions
> at
> > > http://www.checkpoint.com/services/mailing.html
> > >
> >
> ============================================================================
> > ====
> >
> >
> >
> >
> ============================================================================
> > ====
> > To unsubscribe from this mailing list, please see the instructions at
> > http://www.checkpoint.com/services/mailing.html
> >
> ============================================================================
> > ====
> >
>
