This tutorial will demonstrate how to secure Postgresql databases using two-factor authentication from the WiKID Strong Authentication server via PAM on Linux. We assume you have Postgresql and the WiKID Strong Authentication server configured.
Configuring Postgresql
Configuring Postgresql to use PAM authentication is trivial. Edit the pg_hba.conf file to use PAM and add an entry for PAM for the appropriate network:
host all all 192.168.0.0/24 pam postgresql
This entry specifies that all the users from the local lan (192.168.x.x) will use PAM, specifically the file postgresql which on redhat flavors is found in /etc/pam.d. We assume you have a separate line for access by applications. You don't want to break any applications that are using Postgres.
Configuring PAM
If your system does not have a package for pam_radius you can download the source from the Pam Radius website. Installation documentation is also available.
Once installed, edit the postgresql PAM file to use radius:
#%PAM-1.0 auth sufficient /lib/security/pam_radius_auth.so account include system-auth password include system-auth session include system-auth
PAM settings vary by linux flavor, so please consult your distribution's PAM documentation.
Now edit the /etc/raddb/server file to point to your WiKID server:
# server[:port] shared_secret timeout (s) #127.0.0.1 secret 1 192.168.0.10 your_shared_secret 3
Configuring the WiKID Strong Authentication Server
Adding a domain to the WiKID server
The WiKID Authentication System employs the concept of authentication domains. An authentication domain is a segmentation of authentication authority. Any given token client using the system can participate in any number of authentication domains. These domains may exist on an individual WiKID Strong Authentication Server or they may exist on separate and discrete servers (or any combination). Conversely, a WiKID Strong Authentication Server may provide authentication services for any number of discrete domains. These domains may be exclusive or inclusive of any set of token clients.
An authentication domain is initially defined by the 12-digit code used in token client provisioning. This code allows any un-configured, unrelated token client to locate and register with a particular WiKID Strong Authentication Server and domain. In practice, the 12-digit code signifies a zero-padded IP address that is Internet accessible. Optionally, if may designate a prefix in the wikidsystems.net domain. For example, a WiKID Strong Authentication Server with the public IP address of 27.232.7.14 would be directly accessible via the 12-digit code 027232007014. Using the wikidsystem.net service, codes signifying non-routable IP addresses may be used, such as 999888777666. You can also alter the DNS settings by deploying a custom jw.properties file with your software token.
Selecting the [Domains] header option will display the current domains served by this WiKID Strong Authentication Server. See Figure 1 below.
Figure 1 – Domain Configuration Screen
Selecting [Create New Domain] on this screen will allow the administrator to establish a new authentication domain for this server. The new domain parameter screen is depicted in Figure 2.
The required domain configuration options are:
Domain Name – This is a descriptive label for this domain visible only in the administration system.
Device Domain Name – This is the domain label that will appear in the menu option on the token client. This label should be relatively short to facilitate viewing on a mobile device.
Minimum PIN Length - This is the minimum allowable PIN length for this domain. Any attempt to set a pin shorter than this value will generate an error on the client token client.
Passcode Lifetime – This parameter specifies the maximum lifetime of the one-time passcode generated in this domain. After N elapsed seconds, the one-time passcode will automatically be invalidated.
Server Code – This is the zero-padded IP address of the server or the pre-registered prefix in the wikidsystems.net domain. This value must be exactly 12 digits in length.
Max Bad PIN Attempts – The maximum number of bad PINs attempted by a token client in this domain before the token is disabled.
Max Bad Passcode Attempts – The maximum number of bad passcodes entered for a userid registered in this domain before the userid is disabled.
Max Sequential Offlines – The maximum number of times a token client may use the offline challenge/response authentication before being required to authenticate online. This feature is used in the Enterprise version for the wireless clients when they are out-of-network coverage.
Use TACACS+ Select this to use TACACS+ for this domain.
Creating Network Clients
Network clients are systems that request one-time password validation from a WiKID Strong Authentication Server. These systems act in a proxy capacity, accepting questionable information from users and communicating with the WiKID Strong Authentication Server for validation. Network clients utilize one of the installed protocol modules. The protocol module must be installed, initialized and enabled before you can configure add a network client for it.
Each network client must be configured on the WiKID Strong Authentication Server before it will allow the client to request validation. Figure 3 shows the initial network client screen.
Initial Network Client Screen
Select – Create new Network Client - to begin adding a network client. You will be presented with a screen similar to Figure 4 below.
Network Client Properties Screen
These are the general network client properties. These values are required for each network client configured, regardless of the protocol selected. Property definitions are:
Name – The descriptive name of the server. This will be the primary display name in the administrative system and in system logs and reports. It is recommended that you use a combination of hostname, and WiKID domain for clarity.
IP Address – The IP address of the network client.
Protocol – The communications protocol used by this network client. Only protocols previously enabled will be available. The protocol selection will dictate the additional properties that must be defined for this client. In this instance, choose Radius.
Domain – This is the WiKID authentication domain in which this client will request credential validation. Your postgresql administrators will need to have their tokens registered in this domain.
Radius traffic is encoded by a shared secret, so we need to enter the same shared secret here as we entered on Postgresql server's /etc/raddb/server file:
That's it! To access Postgresql from the command line or from any GUI interface will require a one-time passcode from the WiKID Strong Authentication server.