Installation and Trouble-Shooting.

1. How can I find out what version and build number my SmartGate server is running?
2. Mac SmartPass installation.
3. OLR error messages
4. How do I brand my SmartPass client.
5. I get a "Cannot find Disk 3" error in my SmartPass Install.
6. Sometimes the proxy settings in Netscape are grayed out, How do I fix this?
7. I can't access my tokens via the control panel, What is wrong?
8. How to set-up and IPSEC Site-to-Site Tunnel?
9. Licensing errors and vladmin.

SmartPass and Proxy Servers.

1. How to run OLR and use Web permissions from behind a MS Proxy Server and a Firewall ?
2. SmartPass behind a proxy server/firewall.
3. Using SOCKS to pass SmartGate applications through a proxy server.
4. Using SmartPass behind a MS Proxy Server with Authentication.

Smartgate/Pass Authentication methods.

1. SmartGate/SDI debugging tips.
2. Configuring Livingston Radius to work with SmartGate.
3. What to do if an access code is forgotten by your end-user.
4. How can I re-install SmartPass and keep my old token ?
5. How do you transfer a token from one machine to another in Smartpass 3.4 and ABOVE?
   
   

1. How can I find out what Version and Build number my SmartGate server is running?

On the server, go to /usr/smartgate/bin and enter the following command

./sgadm -v

the Version and Build Number will be displayed.

2. SmartPass for Mac OS

Installing SmartPass on the Macintosh Operating System

1. Download the client from the web site.
2. Click on the SmartPass_Installer application.
   Choose to create a folder on the "Desktop" called SmartPass Folder and install all files there.
3. You will be prompted to reboot the computer.
4. After restart, open up the SmartPass folder and click on SmartPass.
5. SmartPass will ask you to create a token - place the token in the SmartPass Folder.
6. You will then be prompted to select a pin code.
7. Open up a browser and point to Your_OLR_Page:3845/OLR and fill out the registration page, then click on register.
8. You will now be able to access the secure site

Un-installing Smartpass on a MAC

1. Close SmartPass.
2. Delete the SmartPass Folder.
3. Delete the V-One Data folder located in System Folder/Preferences.
4. Delete the SmartPass Module located in System Folder/Extensions.

3. OLR Error Messages

Below are the OLR error messages and their meanings. These may show up from time to time:

• 161 "SERVER ERROR %s: Unable to open reginfo.dat file."
• 162 "SERVER ERROR %s: Unable to get public key name."
• 163 "SERVER ERROR %s: Unable to open public key file."
• 164 "SERVER ERROR %s: Unable to get public key."
• 165 "SERVER ERROR %s: Unable to open Entrust environment file."
• 166 "SERVER ERROR %s: Unable to get server's domain name."
• 167 "SERVER ERROR %s: Bad group list in reginfo.dat file."
• 171 "SERVER ERROR %s: Unable to talk to authentication server."
• 172 "SERVER ERROR %s: Unable to read from authentication server."
• 131 "SERVER ERROR %s: Failed to connect to uid-server."
• 132 "SERVER ERROR %s: uid-server failed to generate uid."
• 133 "SERVER ERROR %s: Request rejected by uid-server."
• 141 "SERVER ERROR %s: Unable to connect authentication server."
• 142 "SERVER ERROR %s: Failed to add user."
  (A good indication that the license is bad or that the license server is down).
• 143 "SERVER ERROR %s: User name already exists."
• 112 "SERVER ERROR %s: OLR server does not accept VONE registration."
• 113 "SERVER ERROR %s: OLR server does not accept PAGER registration."
• 114 "SERVER ERROR %s: OLR server does not accept NETRUST registration."
• 120 "SERVER ERROR %s: Invalid public/private key pair."

4. How do I brand my SmartPass Client ?

Many customers desire the option of changing the name of the SmartPass client to reflect their company or product name. This is an option that AEP Networks supports in various ways.

When performing the Online Registration (OLR) process the default web page the client accesses (ip:2090/30reg.html) can be modified to reflect the customers Company name on the top line by modifying the "Company Name" field in the SmartAdmin, OLR Setup, OLR Branding Settings.

In this same SmartAdmin screen other fields can be modified which will show up on the web page that is displayed upon successful registration. These other fields include Address, e-mail, and Web page phone number. Ref: SmartGate Administrator’s Guide

5.  I get a "Cannot Find Disk 3" error on my Smartpass install

Some things to check are as follows...

1. Check your packages list  in your setup.ini and make sure all of the packages are spelled correctly.
2. Check your distribution and make sure that all listed packages are present (files that end with .z)
3. If you are usings FIPSTOKEN or VCAT then make sure you have MCOS.Z in your distribution.

6. Sometimes the proxy settings in Netscape are grayed out, How do I fix this?

There are times when using older versions of SmartPass that the proxy settings are grayed out on a Netscape browser and the user is unable to modify the proxies.

The solution to this issue is to overwrite the netscape.cfg file stored in the same directory as the Netscape executable with a default netscape.cfg file. To make it permanent you take the default netscape.cfg file and overwrite the files nscpexcl.cfg and nscpprox.cfg in the SmartPass directory.

7. I can't access my tokens via the control panel. What is wrong?

There are many reasons for this kind of error, these reason range from corrupt install media to a corrupt OS. There is one thing however that should be checked during an installation of SmartPass 3.4 and below that can cause this problem. In the setup.ini file, there is a setting called "packages=". If there are more than nine options under this setting, you will not be able to access the token via the control panel. To fix this, remove one of the options that you will not use so that there are only a maximum of eight options in "packages=" and re-install.

8. How to set up a Site-to-Site IPSEC Tunnel?

Site-to-Site IPSEC Tunnel's are available with Windows OS SmartGate Servers with IPSEC installed. This example and steps use ficticious Locations A & B, and example IP ranges. Be sure to follow the proceedure with the correct information for your locations.

• Location A:
  10.3.7.0 - 10.3.7.11[SmartGate Server]
  206.20.11.10 - Internet
• Location B:
  192.168.10.0 - 192.168.10.11[SmartGate Server]
  205.177.23.10 - Internet

1. On your SmartGate Server in Location A, open SmartGate Admin and go to the IPSEC Site-to-Site Tab
2. Click “Add”
3. In the name field enter the name of your tunnel from Location A to Location B.
4. Make sure the Enabled box is checked.
5. Enter in your Internal Nets/Hosts (Location A)
   i.e. 10.3.7.0:255.255.255.0
6. Enter in External Nets/Hosts (Location B)
   i.e. 192.168.10.11:255.255.255.0
7. Enter in the Remote Gateway. This will be the External IP Address of the Location B Server.
   205.177.23.10
8. For the Channel, leave it encrypted.
9. Click “Save”
10. Click and Highlight your Tunnel, and Click “Generate New Keys”
11. You tunnel will now change colors, to Blue.
12. Click “Export” to save your Tunnel to a file. (*.tun)
13. Email/FTP the *.tun file to the Admin at Location B.
14. Now its time for some ROUTER configuration. You need to ADD a route on your internal router to say….If my Destination is 192.168.10.0 (Location B) then the gateway is 10.3.7.11 (internal IP of the Location S SmartGate Server)

Now here are the Steps for the Admin at Location B to do once (s)he gets the file.

1. On your SmartGate Server, open SmartGate Admin and go to the IPSEC Site-to-Site Tab
2. Click “Import”
3. Point it to the *.tun file you received from Location A
4. Now its time for some ROUTER configuration. You need to ADD a route on your internal router to say…. If my Destination is 10.3.7.0 (Location A Network) then the gateway is 192.168.10.11 (internal IP of the Location B SmartGate Server)

Now you should be able to ping back and forth between the two networks. Use the “tracert” command and a sniffer to troubleshoot.

9. Licensing Errors and vladmin.

If you are having errors enabling or OnLine Registering users, there may be an issue with your SmartGate Server licensing. To check this, AEP Networks has provided a small application to check the status of your licensed host name and available seats.

On a Windows Server the program is located in the C:\Program Files\V-ONE\SmartGate directory. From a command line in this directory type:

vladmin -l

On a UNIX Server, the program is located in the /usr/smartgate/bin directory, at a command prompt type:

./vladmin -l

The results will show your licensed hostname, and the number of soft and hard seats remaining on your license.

A common error is "License does not match licensed host." There are a few problems that could of caused this.

1. The hostname of the SmartGate Server has changed
2. The license was signed for just the hostname, but the Server is using FQDN
3. The license was signed for the FQDN, but the Server is using just the hostname.

To figure out what happened, first find out what your license was signed for. Remember you uploaded a sgc.ini file to get your license? The activation server uses that file to sign the license file. So open the sgc.ini file and see what name your license was signed for.

Example…
[servername]
name=extranet.domain.com

So by looking at the sgc.ini file, I can tell my license was signed for the FQDN.

On a Windows Server you can make sure your TCP/IP Properties are using the FQDN. Go to the Network Properties, and then go to your TCP/IP properties. Click on the DNS tab and make sure you have “domain.com” in the DOMAIN field.
If your sgc.ini file only listed the hostname, then make sure you don’t have “domain.com” in the DOMAIN field in the TCP/IP DNS Configration properties.

If the information is incorrect, and you did change the hostname. Then you need to have your serial number re-set, and you need to re-activate your license with the correct information in the sgc.ini file.

SmartGate/Pass and Proxy Server FAQs

1. How to run OLR and use Web permissions from behind a MS Proxy server and a Firewall.

**This was tested using Smartpass 3.2a on NT workstation, MS proxy server 2.0 on NT server, Gauntlet 4.x on BSD, and Smartgate 2.5 on BSD.**

If you use TCP permissions, the "server port" will have to be opened. Using single port proxy it will be 3845.

OLR (On Line Registration)

1. Verify that your web proxy works on the proxy server or firewall.

2. Proxy your browser via "HTTP" to "proxy server/firewall" on port "80"

3. OPEN http://your.smartgate.server.ip:3845/OLR or http://your.smartgate.server:2090:30reg.html (earlier than
SP3.2 and SG2.5)

4. Turn OFF the proxy settings in browser.

5. Fill in the Fields, and in the "Use Firewall" Field put in… your.proxy.server:80 (If your proxy server uses a
different port for http, you need to use that port)

6. Click Register

This section is split up. One for No SHIM, and one for a SHIM. The SHIM is a re-direct to localhost

No SHIM

1. Proxy your browser via "HTTP" to "127.0.0.1" on port "2080"

2. Open Smartpass click, "View" , "Options" , "Web Proxy Tab" Verify the settings to the proxy server is correct.
Your.proxy.server:80

3. Connect to your secure Web site.

SHIM

1. Don’t Proxy your browser

2. Follow steps 2 and 3 in "NO SHIM" Section.

FAQ

Q: But I use the Proxy in my browser to get to the proxy server on port 80

A: Then you need to do two things.

1. Install the SHIM

2. Go to the browser Proxy settings, and use the "Exceptions" part. Put in all the Web access permissions in this
section. So when you browse normally it will go to the proxy server, and when you go to a secure site, the
browser wont sent it to the proxy server, and the Winsock file will SHIM it to Smartpass.

2. SmartPass behind a Proxy Server/Firewall.

There have been many requests for information on how to use a smartpass that is behind a proxy
server to access a Smartgate Server through a proxy server. There are many proxy servers out in the
market but the basic setup is the same. If the user is behind a firewall or proxy server and has to go
to the server and is just access http permissions, then all they have to do is to set the web proxy of
the smartpass client to point to the address and http port of their firewall/proxy server. (See FAQ 21
and the Smartgate admin for more details). Included in this FAQ is information on how to have full
access to the Smartgate server from a Smartpass client in a variety of proxy servers/firewalls. The
instructions below assume that the default single port proxy of 3845 will be used.

3. Using SOCKS to pass Smartgate applications through a proxy server.

There are many users who use SmartPass behind the WinGate proxy server. While there is no problem in sing HTTP access via the HTTP proxy, many users want to have full SmartPass/Gate access. Normally port 3845 would be opened, however, this does not work with WinGate. Keith
Page has come up with a solution that allows full access to the SmartGgate server from a SmartPass client through a Wingate server.

1. Verify that SOCKS 4 or 5 is supported and enabled on the proxy server.
2. The second step is to install a SOCKS client like Hummingbird (free on internet at www.hummingbird.com) and install it on the machine with SmartPass and reboot.
3. The second step is to configure the sock.cnf file in the window/system directory to point to the proxy server for all applications. See the below example.
   
   # Configuration File Description
   
   #
   # Each line in the socks.cnf file is one of the following :
   #
   BIND-MODULE expr | *
   PROXY-NAME @=your.proxy.IP.address
   # DENY [*=userlist] dst_addr dst_mask [op dst_port]
   #DIRECT 192.168.0.0 255.255.255.0
   # BALANCE
   SOCKD @=your.proxy.IP.address 0.0.0.0 0.0.0.0
   SOCKD4 @=your.proxy.IP.address 0.0.0.0 0.0.0.0
   SOCKD5 @=your.proxy.IP.address 0.0.0.0 0.0.0.0
   # GSS encryption_type
   #
   
   How this works is that all network activities are forwarded to the WinGate proxy server on port 1080 and then sent normally to where they have to go. This bypasses going through the proxy server because this setup allows the connection to be originated from the proxy server. This will also work with other SOCKS compatible proxy servers.
   
   Q. Will this conflict with the SmartPass Shim
   A. No. This SOCKS client shim resides on another part of the network layer.

How SmartPass can navigate an intervening Microsoft Proxy server which requires user authentication.

Key Points: A user will have a userid and password at the proxy server

What to do on the machine running MS proxy server:

Configure the proxy server to allow SSL connects to servers on port 3845 (see microsoft knowledge base article Q184028)
http://support.microsoft.com/support/kb/articles/Q184/0/28.ASP

Use regedit on the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Proxy\Parameters
Value Name: SSLPortListMembers
Value: This is a multistring entry containing port numbers in ascii with
0x00 separating each entry and 0x00 0x00 at the end of the list
overwrite the last 0x00 with 0x33 0x38 0x34 0x35 0x00 0x33 0x38 0x34 0x35
0x00 0x00 (if you are using a port other than 3845 then change the above ascii bytes accordingly)

What to do on the IIS web server:

Allow ‘Basic’ authentication

What to do on the Microsoft proxy server’s WEB PROXY configuration:

Give user permission to do ‘Secure’ protocol

What to do on the SmartPass client:

Set the following options using the smartpass options dialogs:

• Web Proxy - Proxy Server - Choose ‘Connect through proxy server (authentication required) Enter IP of proxy server and port (usually 80)
• SSL Proxy - same as Web Proxy (same port too!)
• Generic Proxy - select ‘Use the SSL tunneling proxy defined on the SSL proxy
  tab’
• FTP Proxy - select ‘Use the SSL tunneling proxy defined on the SSL proxy tab

What to do in your browser:

Set HTTP proxy to 127.0.0.1 port 2080 (even if you are using the shim!)
Set HTTPS proxy to 127.0.0.1 port 443 (even if you are using the shim!)

Smartpass/Gate Authenitication

1. SmartGate/SDI Debugging Tips

System Engineers who wish to set up this type of authentication should familiarize themselves with the instructions contained in the manual. Some of those instructions may be repeated here, but in a different form.

My goal here is to collect a lot of the common problems we are beginning to see into this document and make it the "de-facto" guide to troubleshooting SDI authentication issues. Thus I’ve used a "question-answer" format as well as an easy reference for the types of client error messages that you may be seeing.

If you think you don’t need to understand how the SG/SDI server works, think again. Both RADIUS and ENTRUST will use the same exact architecture and potentially open up the same types of issues when they are widely deployed. You will save yourself many hours of agony by understanding the types of problems that can occur with SDI and help overcome them with expediency. You will also save me many hours of agony debugging your installation problems.

Additionally, as one might expect with any third-party product, we are in the unique position of having to understand both our product, an additional proprietary authentication procedure/protocol, and the ACE/Server product in order to help our clients set up their sites to use SDI authentication, which makes troubleshooting a tricky business indeed.

Understanding the SDI Protocol

The SG/SDI uses the SDI API to communicate with the ACE/Server. The SmartPass client, however, uses a different, TCP-based protocol for its exchanges with the SG/SDI service. The SG/SDI service can be thought of as a "proxy" which simply collects information from SmartPass and sends it in proper SDI protocol format.

http://john33.fence.v-one.com

contains all of the SDI functional specification parameters, how the daemon works, network diagrams, and including the dialog boxes. Barring perusal of that document, which should also be considered required reading, let me introduce you to the basics of the protocol (most of which can be ascertained by the curious onlooker through the use of a sniffer):

SDI is a UDP-based protocol. It uses two UDP ports : 5500 and 5510. Most basic authentication requests will transpire over port 5500.

Authentication can go in two, possibly three different phases :

Phase I will be seen as an initial UDP packet sent to the CE/Server which is then returned right back at the SG/SDI server. This packet exchange contains time synchronization information as well as a DES secret (if DES is being utilized).

Phase II consists of the transmission of the actual authentication information itself. Although the username is in plaintext, the actual pin/tokencode combination is encrypted with the DES secret, among other things such as the local host’s IP (which can cause mega-problems if the host is multihomed).

For normal authentication requests, the server will respond with the status of the request (permitted/denied). Otherwise we go on to….

Phase III consists of special actions that the server commands of the client. It can include responses to requests by the server for the user to enter a new PIN for his/her token, or a Next Tokencode request.

When successful authentication takes place, if DES encryption is being used, a file securid containing the DES secret will be dropped onto the client for expediency of future authentication requests. This file will not appear on the SG/SDI server until at least one user has authenticated successfully using the service.

Basic Troubleshooting Tips

The following tips may help to isolate common problems during SG/SDI installation.

Is there a firewall on the system with SmartGate ?

Gauntlet has both proxies and ip-filtering capability. By default it does not allow UDP traffic through the firewall unless there is a plug, even if it is coming from the internal interface. ACE/Servers behind a Gauntlet with a stock configuration will not be able to send their protocol responses back to the SG/SDI service because the packets will be dropped.

Raptor firewalls are application-level firewalls, but the newer versions (5.0) do have port-controlling capabilities. You will have to open up the port used for the SG/SDI service (port 2095) to the outside world. Once you start the SG/SDI service on the firewall you should be able to telnet cleanly from the SmartPass client machine to the SG/SDI machine in question. On UNIX this file is usually located in

/usr/adm/sg/ and is called portcontrol.cf.

The following comes from an internal document on Raptor 5.0/SG installation document:

copy the following into /usr/adm/sg/portcontrol.cf

enable tcp 2023

enable tcp 2021

enable tcp 2080

enable tcp 3838

enable tcp 9023

enable tcp 9090

enable tcp 8090

enable tcp 2090

enable tcp 3843

enable tcp 3844

enable tcp 3845

enable tcp 3521

enable tcp 3846

enable tcp 3900

enable tcp 3901

enable tcp 3902

enable udp 5500

enable udp 5510

then edit /etc/rc2.d/S72inetsvc, the very last line of the file.

uncomment the /usr/sbin/inetd -s line and restart the machine.

If you are not doing SDI you don’t need the two UDP ports. You can turn on or off proxy ports 2021, 2023, 2080, 3521 as needed without effecting the entire server. You can turn off 2090 if you do not need OLR.

Is the SG/SDI Server set up correctly?

Look at the process table. You are looking for a process called sdiServer. This process indicates that the SG/SDI server is up and running. An encrypted binary file from the ACE/Server’s data directory, sdconf.rec needs to be copied to the SG/SDI host and located under its etc/ directory under UNIX or data/ directory under NT.

Is the client set up correctly?

The SmartPass client must be told to authenticate using SG/SDI. If there is a firewall between the SmartPass client and the SG/SDI server, this firewall MUST ALLOW TCP connections to the SmartGate server on port 2095. You can accomplish this with a generic TCP proxy on the firewall. The client must also be told it is connecting through a proxy and an accompanying setting for the client (click on "settings" on the main SDI Login Dialog Box, or use the Control Panel to access the SDI Authentication Service and perform the same task).

A simple way to determine if SG/SDI, or any service proxy (like sgftp or sgora) is accessible from the client is to telnet from the SmartPass client host to the SmartGate server on whatever port the service you are testing is located on. For SG/SDI this port is 2095.

Is the service running properly ?

telnet from the local console to localhost, port 2095 to ensure that the process is running. Raptor also has a daemon under NT called "Vulture." This daemon kills any service that it does not recognize. You can either disable the vulture by editing raptor/eagle/sg/vulture.runtime and placing a -1 in the first line, or add the sgsdi service to this list so that it will not get killed.

Is there a clear path between the ACE/Server and the SG/SDI server?

Its possible that since SDI is a UDP-based protocol that it is not being properly passed back to the ACE/Server from the SG/SDI Server. Use the traceroute utility to determine if there are additional hops between the two. These hops may be filtering UDP requests and should be opened to pass UDP on ports 5500 and 5510 at the bare minimum.

Is the ACE/Server on the same system as the firewall ?

This is probably an uncommon setup but it can happen. Currently I don’t have enough data on this type of setup to make helpful advice, but check to see that both internal and external interfaces are defined for the client setting of the SG/SDI server in the ACE/Server database.

Most of the UDP requests back and forth between the SG/SDI Server and the ACE/Server should be taking place over "localnet" or the lo0 interface (127.0.0.1). Most firewalls, such as Gauntlet, will have rules to handle spoofed localhost packets from being accepted at either the internal or external interfaces and thus will inherently trust all localnet packets. So generally problems that could plague installations on separate servers dropping UDP traffic between the two should not occur in these types of setups. Check for

Is the ACE/Server side configured correctly ?

The ACE/Server should be set with the SG/SDI Server as a client, with all of the users who are going to use this service enabled to authenticate through this client. Occasionally, ACE/Servers will appear to reject authentication requests with "ACCESS DENIED, PASSCODE INCORRECT" appearing in the ACE/Server logs, even though all other steps have been performed. This probably means that the ACE/Server has a bad idea of who is sending the authentication requests and therefore is decoding them wrong. The following internal document should assist in diagnosing, understanding, and solving this problem.

This problem will manifest itself in the ACE/Server logs as PASSCODE INCORRECT, Authorization failed. It will be especially mysterious to SEs that have followed the "by-the-book" installation and configuration of the SG/SDI client. At Credit Lyonais we even had successful authentication with another client (a Shiva Access
Server on the same subnet as the ACE/Server).

A recent problem, as well as other mysterious failures of the SG/SDI server to authenticate properly (such as the demo machine for Technet) are due to the properties of multiple interfaces and the SDI protocol.

When an SDI client submits an authentication request to an ACE/Server, in addition to the shared secret, it also uses the client IP retrieved locally to encrypt the passcode. On a machine with multiple interfaces there is a legitimate question as to what is defined as the "primary interface." This IP designation for this firewall is retrieved and used to encrypt the pincode that is sent to the ACE/Server.

Under ACE/Server configuration a "client" can possess multiple interfaces. If an SG/SDI installation is sitting on a firewall all of those designations MUST be present in the client definition (the secondary interfaces). They are added via the "define secondary nodes" option on the client configuration screen.

Here is the somewhat interesting and confusing part : whatever the client defines as its primary interface must be defined as the IP of the client. Even if the ACE/server is on the inside of the firewall, and the only way that it can talk is through the internal interface, the client must be defined with its primary interface IP to the ACE/Server.

Its other interfaces are then specified as secondary nodes for that client (which may be the actual IP that the ACE/Server communicates with the SG/SDI client on the SmartGate server).

This is an oversimplification and may contain inaccurate data but should illustrate the problem adequately. At Credit Lyonais the firewall in question had three interfaces (qfe0, qfe1,qfe2) :

qfe0 : 34.138.0.4 (external and leads to their router connected to the internet)

qfe1 : 10.55.201.4 (internal and leads to another router connected to the ACE/Server)

qfe2 : 10.55.202.1(internal and leads to another router, which is connected to their DMZ)

Initially Peg had specified that the client configuration for this machine on the ACE/Server be specified as the qfe1 IP, which was the ONLY interface that the ACE/Server could talk to the client on. This makes perfect sense and jibes with 99% of our lab tests and setups.

However, this was not the primary interface for that machine and was not the local IP that was used to encrypt client requests.

The ACE/Server administrator had to delete and add the client with 34.138.0.4 as its IP and the other two IPs as its secondary node. Its important to note that the ACE/Server couldn't even resolve the external interface when it was added, but it would not authenticate properly until this step was done.

Specifying the proper IP for the client designation as well as all of the secondary IPs that could be encapsulating SDI requests is vital. It does not affect how the packets are returned or routed back to the initiating client, as this is handled by TCP/IP. It only affects decryption of the client requests.

At this point, we need to address some issues :

1. How does SG/SDI, specifically the ACE SDK API level used to communicate to the ACE/Server, define the "primary interface" for the machine it is sitting on?
   
   My best guess was to go with the interface that the default route was on. However this may not jibe in certain installations. Until we isolate it best method is by trial and error. I'll have a much better idea once I take a closer look at the API code on Wed. SDI’s suggestion is to use the "first interface defined" by the firewall, which usually means the external one.
   
   
2. What types of installations will this potentially effect ?
   
   Two types stand out in my mind. At a customer site we had a Sparc Ultra 1 with its normal ethernet card, and a special quad-interface NIC card which was used to route all of the firewall traffic. For the failed Technet installation, the ACE/Server was installed on the same machine as the firewall and SmartGate.
   
   Potentially, any machine with multiple interfaces.
   
   Basic SG/SDI Client Error Messages and Hints Unable to configure the ACE/Server
   
   Typically means the SG/SDI service cannot "talk" to the ACE/Server. Possible sources could be : corrupted sdconf.rec file, UDP traffic being blocked en-route to the ACE/Server, ACE/Server not running, incorrect client information for the SG/SDI server on the ACE/Server.
   
   The client cannot retrieve the server’s public key.
   
   Your key on the SG/SDI server is corrupted. The client requires this key to encrypt authentication requests between itself and the SG/SDI service. Possible sources could be : corrupt or missing *.pub/*.cer files on the SmartGate server.
   
   Error #XXXXXX
   
   If you get an unknown error on the client when attempting to add the SG/SDI server you could be having port blockage or the service is down. Possible causes : the traffic destined for port 2095 on the SmartGate server is blocked or controlled by a firewall configuration or the service is not running.
   
   Authentication failed.
   
   If the setup proceeded okay, the ACE/Server is running and the SG/SDI server is running and you are receiving mysterious authentication errors refer back to the instructions for multihomed machines above. Make sure this is not due to mistyping, capitalization errors, or any other conceivable user errors.
   
   Possible causes : Mistyped pincode/tokencode, incorrect synchronization between token clock and server clock, multihomed machines using incorrect system identification information to encrypt client passcodes.

2. Getting Livingston Radius for NT to work with SmartGate for authentication

This document will explain the setup of the Livingston NT Radius server and SmartGate 2.5 for UNIX (2.5 for NT does not work with Radius at the time this document was written).

Setting up the Radius Server Getting Livingston Radius for NT to work with SmartGate for.

Install the Radius server making sure to add the udp ports 1645 and 1646 in the winnt/system32/drivers/etc/services directory.

Example:

radius 1645/udp #radius server

radacct 1646/udp #radius accounting

After adding these entries, start the service. After doing this edit the client file in the winnt/system32/drivers/etc/raddb/clients to point to the SmartGate server and also to create a 10 digit shared key.

Example:

# Server Address #Server Key

123.0123456789

The user information must also be placed in a file called the winnt/system32/drivers/etc/raddb/users file. There are many configurations that can be done with this file (consult your radius manual), however the example below will show a simple entry for a user logging in via a network.

Example:

[username] Password = "userpassword"

Service-Type = Login-User

**Note: In the password = line it is important to enter the password between quotation marks.

This concludes the configuration of the server. Make sure that the service is up and running and go to the SmartGate server.

1.Configuring the SmartGate server and the SmartPass client.

The first thing to do is to start the setup program in the /usr/smartgate/bin directory. Press C to configure the SmartGate server and press E to configure the SmartGate extensible components. Select R to enable radius authentication and select G to configure the SmartGate server to authenticate with the Radius server. Fill out the information as it applies to your Radius Server.

Example:

[1] Primary Host : 198.125.123.124 (Radius Server address)

Primary Host Shared Secret : 0123456789

(shared secret as entered on the Radius client’s file)

Primary Host use CHAP : Primary Host timeout : 120

Once this information is added then save the information by exiting the setup program. I also advise re-booting the SG server.

Configuring the client is the last step. Go to the control panel and choose the radius icon (provided that it was set to be installed in the setup.ini file during the installation of smartpass). Click on the ‘set as default authentication method’ and click on apply. After this start the SmartPass client and enter the IP address of the SmartGate server. After the connection is made to the server add your user name and password just like it is in the Radius ‘users’
file. If everything is setup correctly you will be authenticated and can use the SmartGate server.

3. What to do if your customer looses his access code

(**this FAQ is only for end-users with the SmartPass 3.x version**)

As an administrator or help-desk technician there are times when a end-user will call up saying that they have forgotten the SmartPass access code. Usually the end-user will have to re-install the SmartPass client and re-register to the SmartGate server, but with a little planning they do not have to re-install the SmartPass client, only re-register or manually add in the previous user information from the Smartgate server.

Procedure to save a ‘ready to register’ token.

1. Perform a clean install of SmartPass on a machine. During the install process the installer will be asked to enter an access code. At this time, put in a generic code, for example, 'pincode’ and finish the install. DO NOT register with any Smartgate server.
   
2. Go to the C:\Program Files\V-one\SmartPass 3.x\vcat sub-directory and move it to a safe place. The files in this sub-directory are your ‘ready to register’ vcat token.

Procedure to replace the ‘old’ token with the ‘ready to register’ token.

1. Have the end-user remove the files from the C:\Program Files\V-one\SmartPass 3.x\vcat sub-directory.
   
2. Send the user the files of the ‘ready to register’ token and place them into the C:\Program Files\V-one\SmartPass
   3.2\vcat sub-directory. Once this is done the user will have a fresh token with the ‘generic’ password that was set up. There are two options that can take place to register the new token to the SmartGate server.

Procedure to register the new token to the SmartGate server.

1. Re-register via OLR. (Recommended for remote users due to security risk in transferring the user’s server data in the clear).
   
2. Manually add the user’s server information. This information can be retrieved from the server by using the following command ‘sgadm –list [user name] key’. Instructions as to adding this information to the token are given on pages 13-4 through 13-7 in the SmartGate 2.5 admin manual.
   
   Change the generic access code to one of the end-user’s choosing. This information can be found on pages 13-5
   and 13-6 of the SmartGate admin manual.

1. Uninstall SmartPass and Re-install.
   
   One way you can reinstall SmartPass is to uninstall it. Although SmartPass will be erased, the vcat will note.
   You can then re-install SmartPass and use it normally, the vcat directory will not be written over by the new installation.
   
2. Move the vcat token to a safe place.
   
   Another way to reinstall SmartPass and keep the vcat is to back the vcat directory up in a safe place where nobody but you can get to it. That way, if the disk crashes or SmartPass is completely erased, you can re-install SmartPass, erase the default vcat that is installed in the new installation, and copy your original one in its place.
   
   These steps can save you time and headaches in the event that you need to reinstall SmartPass or it is accidentally erased.
   
   

5. How do I transfer a virtual token from one machine to another in SmartPass 3.4 and ABOVE?

For FIPS or VCAT Token, only change the name of the Control Panel, they are identicial. The only check, default token is the one in use.

1. Open path C:\Program Files\V-ONE\SmartPass 3.x\Data.
   
2. Copy file: "user.tkn" on a clean floppy disk (or transfer to another machine via other means).
   
3. Insert the floppy disk in the target machine and open Window Explorer.
   
4. At the machine, copy: "user.tkn" from the floppy disk to the path c:\Program Files\V-ONE\Smartpass 3.x\Data/
   
5. The token should authenticate.

VCAT token...

1. Open path C:\Program Files\V-ONE\SmartPass 3.x\vcat
   
2. Copy directory: "vcat" on a clean floppy disk (or transfer to another machine via other means).
   
3. Insert the floppy disk in the target machine and open Window Explorer.
   
   
4. At the machine, copy the directory: "vcat" from the floppy disk to the path c:\Program Files\V-ONE\Smartpass 3.x\Data/
   
5. The token should authenticate.
   
   In all cases make sure that the setting tab in the control panel icon is set to read the correct directory where the tokens are stored