Skip to main content

Various guides for Linux, WiKID and information security.

Frequently Asked Questions about the WiKID Strong Authentication Server.

The token client uses port 80. Because we use asymmetric encryption, there is no need for SSL. If you are behind a proxy, your token client won't connect to the WiKID server. Proxy support is coming in version 3.0. The WiKIDAdmin web interface uses port 443.

Network clients use a variety of ports. Radius is typically 1812, LDAP 389, wAuth is 8388 and TACACS+ is 49. To see if the listener is running on the WiKID server, enter the following command at the WiKID server terminal:

# netstat -anp | grep 8388
Just change the port to the service you are looking to check. The output for wAuth looks like this:
netstat -anp | grep 8388
tcp        0      0 0.0.0.0:8388            0.0.0.0:*               LISTEN      11955/java          
tcp        0      0 127.0.0.1:8388          127.0.0.1:34817         ESTABLISHED 11955/java          
tcp        0      0 127.0.0.1:8388          127.0.0.1:34826         ESTABLISHED 11955/java          
tcp        0      0 127.0.0.1:34826         127.0.0.1:8388          ESTABLISHED 12044/java          
tcp        0      0 127.0.0.1:34817         127.0.0.1:8388          ESTABLISHED 12066/java    

To help with troubleshooting and to demonstrate wAuth, we have included example.jsp in /opt/WiKID/tomcat/webapps/WiKIDAdmin/. If you edit line 47 and change defaultservercode to your server code and line 52 changing the localhost "passphrase" to your passphrase, you can browse to the page logged in as WiKIDAdmin.

Look for this line:

wc = new wClient("127.0.0.1", 8388, Config.getValue("BASEPATH") + "private/localhost.p12", "passphrase",
        Config.getValue("BASEPATH") + "private/CACertStore", "changeit");

And change "passphrase" to the passphrase for your localhost certificate.

NB: The passphrase for CACertStore on line 53 is, misleadingly, "changeit". However, it does not need to be changed.  Also, line numbers may change slightly.

If you get a tomcat error, check the passphrase you entered. If you still get an error, check that your clock is accurate. If your clock is not accurate, you may have created certificates that are no longer valid. You can delete them in /opt/WiKID/private. Just don't delete WiKID.cer.

This page demonstrates how easy it is to configure a JSP-based web-application for two-factor authentication with WiKID using wAuth. Each wAuth network client includes an example file.

If you get the error "The wClient connection to the server was NOT successfully established." Please double-check your passphrase. You might also make sure your certificates are valid.

Run the following command (all on one line):

keytool -list -v -keystore /opt/WiKID/private/intCAKeys.p12 -storetype pkcs12 -storepass yourpassphrase

and

keytool -list -v -keystore /opt/WiKID/private/localhost.p12 -storetype pkcs12 -storepass yourpassphrase

for the localhost certificate.

If you created the certificates and then discovered that the clock was not correct, your certificates might be expired. You can simply re-create them via the WiKIDAdmin.

To see if the WiKID server's firewall is allowing connections from your network client (VPN or web application, e.g.), you can run this command using grep to limit the request to a specific protocol:

iptables -L | grep radius


ACCEPT     udp  --  localhost.localdomain  anywhere            state NEW udp dpt:radius 
ACCEPT     tcp  --  localhost.localdomain  anywhere            state NEW tcp dpt:radius 


But instead of localhost you will see your IP address.

 


If you are able to connect to the server using some clients but not all, you can troubleshoot issues by running the token in debug mode.

Here's what the file looks like:

domainSuffix=wikidsystems.net
useIpBeforeDns=true
debug=true

You can also find it and copy it on your computer.  The domainSuffix is used to change the default DNS.  The default is to use wikidsystems.net. UsIpBeforeDns tells the token to check to see if the domain is a zero-padded ip address before checking for a dns entry.  Debug=true turns on debug mode. 

Now, run the software token client from the command line:

$ java -jar jWiKID.jar

This is what the output from the software token should look like for adding a new domain:

devPub.length: 
162
Sending 178 bytes of post data from pullConfig
wComms.connectInternal(): connecting to http://333.344.445.555/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=0&S=333344445555&CT=1
Opening http://333.344.445.555/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=0&S=333344445555&CT=1
wComms.connectInternal(): connecting to http://333344445555.wikidsystems.net/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=0&S=333344445555&CT=1
Opening http://333344445555.wikidsystems.net/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=0&S=333344445555&CT=1
POST /wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=0&S=333344445555&CT=1 HTTP/1.1
Wrote 178 bytes.
Reading response iteratively ...
Returning data ... (296 bytes)
Read 296 bytes from the server
Reading 128 of ciphertext.
Reading 160 of server pub key data.
Recieved and Parsed Domain Configuration
serverCode:333344445555
name:Token client test
minPIN:4
PINLifetime:60
deviceID:-767379240169441339
registeredURL:https%3a%2f%2fwww.wikidsystems.com%2fsignup%2ftestclient.jsp
pubKey:[B@c272bc
The token first tries http://333.344.445.555, which doesn't exist, so it then tries http://333344445555.wikidsystems.net, which succeeds. The token gets the domain configuration information such as the registered URL and minium PIN and the user is asked to set their PIN.
Making connection to server.
wComms.connectInternal(): connecting to http://333.344.445.555/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=1&D=-767379240169441339&S=333344445555&CT=1
Opening http://333.344.445.555/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=1&D=-767379240169441339&S=333344445555&CT=1
wComms.connectInternal(): connecting to http://333344445555.wikidsystems.net/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=1&D=-767379240169441339&S=333344445555&CT=1
Opening http://333344445555.wikidsystems.net/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=1&D=-767379240169441339&S=333344445555&CT=1
POST /wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=1&D=-767379240169441339&S=333344445555&CT=1 HTTP/1.1
Wrote 128 bytes.
Reading response iteratively ...
Returning data ... (272 bytes)
Recieved 256 bytes from server.
regcode length: 19
public key length: 160
Offline key size: 160
The PIN is encrypted and sent to the server. The server responds with the registration code, which is a 19 digit number. The number is hashed by the server's public key (to prevent a MITM attack during this process) and presented to the user as an 8 digit alphanumeric.

 

If you see an issue during this process, think about where it is occurring? Can the token write the WiKIDToken.wkd file (which has the public/private keys and domain information) to the file system? Can the token reach the server at http://333.344.445.555 or a DNS entry such as http://333344445555.wikidsystems.net? Does the DNS resolve? Do you see an attempt to connect to the WiKID Server in the WiKIDAdmin logs?

If you would like to  see how big the database is before cleaning up run:

# su - postgres  
-bash-3.2$  psql -d wikid
wikid=# select pg_size_pretty(pg_database_size('wikid')) As fulldbsize;

That will tell you the size.

In the WiKIDAdmin, go to the Logs link in the top right corner.  Click on the button on the right that says "Archive Logs".  Select Zip to save or delete the logs and click the archive button.

Now on the terminal run:

# su - postgres
-bash-3.2$ vacuumdb -afvz

You can re-run the commands above to see the improvement. Note the if you are running in replication, then you need to a '-p 5434' to  the postgres user commands.

 

If you can't login to the WiKIDAdmin site due to a bad username and password, there is probably an issue with database connectivity. Check that postgres is running on the proper port:

netstat -anp | grep 5432

Check that 127.0.0.1 is the first item in /etc/hosts and not the IPv6 ::1 listing. (Though this seems to be less of an issue with 3.0)

Make sure that postgresql-jdbc is installed.

Disable SELinux.

Check that the pg_hba.conf file copied properly:

diff /opt/WiKID/conf/templates/pg_hba.conf and /var/lib/pgsql/data/pg_hba.conf

If you get any response to this commmand, it may be that you didn't run this command:

/opt/WiKID/sbin/wikidserver_config.sh

Or that you did not reboot or run this command:

/opt/WiKID/conf/templates/wikid-firstboot.sh

You have installed the WiKID two-factor software token on your Blackberry and you are connected on your mobile network, but when you try to add a domain, you get a message saying you are offline and need to be online to create a WiKID Domain.

Try rebooting the Blackberry, check your firewall settings and make sure that you can access the internet via the browser.

You've logged in with the correct username and password for the WiKIDAdmin web interface, but you get a 404 error from Tomcat:

HTTP Status 404 - /WiKIDAdmin/login.jsp

type Status report

message /WiKIDAdmin/login.jsp

description The requested resource (/WiKIDAdmin/login.jsp) is not available.
This happens occasionally if your browser has cached the session. In the URL bar, remove the login.jsp file name so the URL is just https://wikidservername/WiKIDAdmin/ and hit enter. The WiKIDAdmin page should come up.

If you get this error:

Error: There is a problem with your certificate request
java.io.IOException: exception encrypting data - java.security.InvalidKeyException: Illegal key size

Please go back and try again

You need to install the JCE Unlimited Strength Jurisdiction Policy Files.

You will also need to delete the intCAKeys.p12 in /opt/WiKID/private:

# rm /opt/WiKID/private/intCAKeys.p12

Then restart WiKID. 

If you are using IE, you may need to add your WiKID server into the list of trusted sites. Go to Tools --> Internet options --> Security --> Trust sites and add your WiKID server.

If you can telnet to port 443 on your WiKID server (ping is blocked by the WiKID server firewall) and if you run 'netstat -anp | grep 443' on the WiKID server to see that the listener is up and the URL shows but there is no error or any content at all on the web page, then your browser probably doesn't like the WiKIDAdmin certificate.

Typically, this means that for some reason, the java.security files in the WiKID packages did not get copied to your java location. 

Run:

# locate java.security

You will see one in /opt/WiKID/conf/templates/java.security and one or more in your java directories.  Copy the one from the WiKID directory to the one in your working java directory.   BouncyCastle needs to be set as the second provider as in the WiKID copy:

security.provider.1=sun.security.provider.Sun
security.provider.6=com.sun.net.ssl.internal.ssl.Provider
security.provider.3=com.sun.rsajca.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvider
security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider

 

This problem is typically a networking problem.  Double-check that you can get out to the Internet from the server.  Check that your gateway setting is correct. If there is a firewall between the WiKID server and the Internet, make sure it is not blocking out-bound port 80 traffic.

For example, on a SonicWall you may need to uncheck the box that says: Enforce Host Tag Search for CFS and hit apply.

 

 

 

If you are using the ISO or the VMWare image and you are having trouble starting the server because the passphrase is bad, it might be because the keyboard for the terminal is set to the US. The passphrase is created in the browser, which is more than likely set to your local key map. If when you enter that passphrase into the terminal, you get an error, it is probably the keyboard mapping - especially if you are using non-alphanumeric characters.

To change the keyboard mapping on the terminal, run the loadkeys command with the appropriate keyboard map as the only argument:

# loadkeys uk.map.gz

To see the complete list of keymaps run:

# ls /lib/kbd/keymaps/i386/qwerty

Are you behind a proxy? Proxy support is available on the J2SE tokens.  Under Actions, Set Preferences you can enter your proxy information.  Please contact your network administrator for your proxy information if you don't know it.

First, check the logs in the WiKIDAdmin. The link is in the upper right hand corner. When the one-time passcode is sent to the token client, the log reads "Passcode Request Successful (128)". After that, you should see entries on your two-factor authentication attempt. If you don't see any, then the WiKID server is not getting the request from the network client to authenticate the user.  

  • Make sure that the network client has the correct IP address of the WiKID server and that it can route to it.
  • Set the log level to debug to see more information. 
  • Make sure that the shared-secrets are correct, if you're using radius.
  • Did you run 'wikidctl restart' on the server after creating the network client? If not, the firewall on the WiKID server might be blocking the authentications.
  • Does your setup work without WiKID? 
  • Have you tested WiKID using the example.jsp page?

 

You will need to re-generate an intermediate CA. You will need to do this on the command line of the WiKID server. Log in as root and change to the cert directory:

cd /opt/WiKID/private
The directory will look something like this:
# ls -all
-rw-r--r--   1 root root 2718 Jul  6  2006 CACertStore
-rw-r--r--   1 root root 2237 Jun 21  2007 extranet.p12
-rw-r--r--   1 root root 2984 Jul  6  2006 intCAKeys.p12
-rw-r--r--   1 root root 2271 Jul  6  2006 localhost.p12
-rw-r--r--   1 root root  387 Oct 16 15:09 tacacs.conf
-rw-r--r--   1 root root 1752 Mar 19  2006 WiKIDCA.cer
You will need to remove or move CACertStore and the .p12 files.
# rm CACertStore
and:
rm *.p12
The localhost cert and any wAuth p12 files will also need to be recreated and redeployed if necessary. You should not have to recreate any network clients that use radius, ldap or tacacs+

The WiKIDToken.wkd file includes the domain information and the public/private key pairs for the software token. If you delete this file, it will be re-generated by the application with new keys, so you will need to delete the user in WiKIDAdmin and re-validate the user.

When first integrating WiKID and your VPN using radius, it can be difficult to troubleshoot without detailed logging.

Remember: you must restart the WiKID service after creating a new network client! This opens the firewall and caches the radius information. 

NB:  There may be a bug in the system currently. The stop command fails to fully stop the radius server.  Use this instead:

wikidctl stop
killall -9 java
wikidctl start

If you need to better understand how the flow and architecture works, please see our short pdf on adding two-factor authentication to your network.

Is the server getting the request?

Start by getting an OTP from your WiKID token. We assume you have register your username to that token.   Login with your username and the OTP.  Once you get your OTP, check the WiKIDAdmin logs. Set the log level to debug and hit Filter.  You will see:

Issued OTP

Now, enter the username and OTP and try to login.    Return to the WiKIDAdmin logs and hit Filter to refresh.  If you see nothing above your OTP issuance, then the server is most likely not getting the RADIUS request at all.  Check your VPN or radius server settings.  If you are using NPS, check Event Viewer or whatever you use for Windows logging.

Unknown NAS Error

Radius will reject packets from unknown IPs.   This error looks like:

Unknown NAS  error

In this instance, the IP 192.168.56.1 is not the same IP as the one used in the Network Clients on the WiKID server.  Update the IP and restart the WiKID service.

Using TCPDump

TCPDump can also provide valuable troubleshooting information. 

yum install tcpdump
tcpdump -vvv port radius

Now you can see what requests, if any, are coming to your WiKID server.  Check to make sure that they are coming from the same IP address as listed in the Network Client's tab.  Make sure that the NAS IP that is requesting the authentication is exactly the same as entered in the Network Client.  Hit ctrl-C to cancel tcpdump.

 Run 'iptables -L -n' on the server - make sure the IP address of the NAS IP is listed too.  WiKID should open up ports for network clients.

The lifetime of an unregistered token is set for 60 minutes by default. This value can be set to a longer time by going to Configuration > Set Parameters > RegCodeTTL, and changing 60 to whatever you feel is appropriate.

This error indicates that the software token client cannot get to the WiKID Strong Authentication server. The software token client communicates with the server over port 80. Check to see if you can reach the IP address of the server/WiKID domain using telnet or traceroute. It could also be that the domain is mis-configured. If no client can create a domain, then it is probably the networking on the WiKID Strong Authentication server or perhaps the zero-padded domain identifier is incorrect.   Be sure to enter your proxy information under Actions, Set Parameters if you are behind a proxy.

You can also download the jw.properties file from the src directory and edit it to set debug to true.  Then if you run WiKID from the command line with "java -jar jWiKID.jar" you may see helpful information on the command line.



 

Copyright © WiKID Systems, Inc. 2017 | Two-factor Authentication