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 8388Just 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 radiusACCEPT 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.
- Download this file to the token directory: http://www.wikidsystems.com/webdemo/tokens/j2se/jw.properties
- Edit the file setting debug=true
- Run the token from the command line: java -jar wikidtoken.jar (or perhaps wikidtoken-x.x.x.jar)
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@c272bcThe 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: 160The 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: 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:
If you get any response to this commmand, it may be that you didn't run this command: Or that you did not reboot or run this command:netstat -anp | grep 5432
diff /opt/WiKID/conf/templates/pg_hba.conf and /var/lib/pgsql/data/pg_hba.conf
/opt/WiKID/sbin/wikidserver_config.sh
/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:
You need to install the JCE Unlimited Strength Jurisdiction Policy Files. You will also need to delete the intCAKeys.p12 in /opt/WiKID/private: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
# 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:
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:
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.
