From proff Sun Sep 1 14:21:08 1996 Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id OAA22910 for best-of-security; Sun, 1 Sep 1996 14:21:08 +1000 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by suburbia.net (8.7.4/Proff-950810) with ESMTP id NAA18752 for ; Sun, 1 Sep 1996 13:20:25 +1000 Received: from miles.greatcircle.com by relay5.UU.NET with ESMTP (peer crosschecked as: miles.greatcircle.com [198.102.244.34]) id QQbffp13481; Sat, 31 Aug 1996 23:19:35 -0400 (EDT) Received: (majordom@localhost) by miles.greatcircle.com (8.7.1-lists/Lists-960417-1) id TAA06261 for firewalls-outgoing; Sat, 31 Aug 1996 19:50:47 -0700 (PDT) Received: from gatekeeper.glaxo.com (gatekeeper.glaxo.com [192.58.204.201]) by miles.greatcircle.com (8.7.4/Miles-951221-1) with SMTP id TAA06254 for ; Sat, 31 Aug 1996 19:50:39 -0700 (PDT) Received: by gatekeeper.glaxo.com (5.65/fma-120691); id AA26123; Sat, 31 Aug 96 22:50:22 -0400 Received: by ussun1d.glaxo.com id WAA20329; Sat, 31 Aug 1996 22:57:28 -0400 (EDT) Received: (from ggh14854@localhost) by ussun2f. (8.7.5/8.7.3) id WAA17103; Sat, 31 Aug 1996 22:52:23 -0400 (EDT) Date: Sat, 31 Aug 1996 22:52:23 -0400 (EDT) From: "Gary G. Hull" X-Sender: ggh14854@ussun2f To: potlicker@morebbs.com Cc: firewalls@GreatCircle.COM Subject: Re: S/key & secureid In-Reply-To: <9608291851.0QHX700@morebbs.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: proff Precedence: bulk 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