On Thu, 29 Aug 1996 potlicker @
morebbs .
com wrote:
> Anyone one else had trouble or success getting Secure ID to run on a
> TIS Gauntlet?
> PoT_LiCkEr
We had great success getting securid running on our TIS. All we had to do
was register the TIS box with the master server, move a copy
of the sdconf.rec file to the /var/ace directory on the TIS and
remove the existing securid file. A new securid file is created
by the system at the time the first authentication login is
accomplished.
Here's what did:
CONFIGURING SECURID
First, register the firewall as a client system on your ACE server. Any users
that will authenticate from the firewall must be registered in the ACE server
with the firewall as one of their clients.
Second, copy the /var/ace/sdconf.rec from the ACE server to
/var/ace/sdconf.rec on the firewall. You will need to make the /var/ace
directory.
Third (this may not be strictly necessary) add an entry in the
/usr/local/etc/netperm-table reading
authsrv: securidhost x.x.x.x
where "x.x.x.x" is the address of the *firewall* interface that is
registered as the ACE client.
Register a user as using SecurID authentication, then try to log in.
If you've already done all the above and it still doesn't work, verify that
you have connectivity to the ACE server - you've got to have a route to the
system with no filters or firewalls in between (the SecurID protocol uses
UDP). If you can't ping the ACE server, you can't use it to authenticate.
One final note - there is a bug in the 2.0 ACE server - when you add a client
(like the firewall) it initially rejects all login attempts with "Invalid
PRN". Eventually (this appears to take days), things start to work. Security
Dynamics has a patch for this problem.
TIP
There is one passage in the 3.1 administrators guide that could be misleading.
On page 84, "If your ACE server is running on a machine other than the
firewall...". That part of the line makes it sound like one can run the
Gauntlet system as the ACE server out of the box. Not true. Keep in mind
also that Gauntlet only implements the client part of the SecurID code and
that you will still need a SecurID server.
One feature that may make your life easier is the "default user" capability we
are adding to Gauntlet. What this allows you to do is set up a default user
in Gauntlet that can force new users into a particular authentication scheme
automatically. One of our customers uses it like this:
a) They configure all of their information into the ACE server.
b) On the Gauntlet, they only add the default user.
c) When a new user logs in (no user record in the Gauntlet), a new
record is added for the user and authentication is passed to the
SecurID ACE server.
d) When that user logs in subsequent times, they already have
the record in Gauntlet.
The advantage of this system is you don't have to do everything twice
(e.g. set them up in SecurID and then in Gauntlet).
A problem (editing a SecurID user displays them as S/Key) was recently
reported by another customer - we've generated a patch to fix this.
Please download "authedit.patch" (and "patch.patch" if you haven't already
installed it) from ftp.tis.com, directory /gauntlet/patches/3.1 - install
patch.patch using "sh patch.patch", then "sh authedit.patch". This patch also
fixes a bug that would not allow you to edit a user with a name consisting of
more than 10 characters.
Because you are using SecurID for authentication, you may also want to install
the authsrv.patch - this patch gives you the ability to add a default user
using SecurID authentication - once this is done, any unknown user is
automatically added to the Gauntlet authentication server using information
from the "default" user - if you set up the default user using SecurID, any
unknown user will be verified using the ACE server without requring you to add
them in two places.
Hope this helps. Good luck....
|/
---o0o-@@-o0o---------
Gary G. Hull - Technical Consultant
email: gary_hull @
glaxowellcome .
com
References:
|
|
