Two factor authentication everywhere with privacyIDEA LDAP-Proxy

In order to secure the login process with two factor authentication in an application there are different approaches.

Two-Factor-Authentication via standard protocols and plugins

With privacyIDEA we used standard protocols like RADIUS and SAML. If the application that you need to protect can facilitate RADIUS or SAML, the validate of the second factor can be performed by the privacyIDEA RADIUS Server or by privacyIDEA acting as a SAML Identity Provider. In this case you only need to change the configuration of the application, but you do not need to change the application.

Other applications provide an authentication framework, where the authentication can be extended using plugins. For such scenarios many different plugins are available to connect the application to the privacyIDEA Authentication Server. As of know a long list of plugins is already available for applications like TPYO3, ownCloud, NextCloud, WordPress, dokuwiki, django, OTRS, Apache, NGINX, PAM/OpenVPN and also for authenticating at the Windows Desktop.

But some applications do not support RADIUS or SAML and also do not provide an authentication framework to add 2FA via a plugin. Sometimes simply time is short, to develop a plugin in the corresponding programming language.

privacyIDEA LDAP-Proxy

To also provide strong authentication also for those applications and authenticate the users with two factors against privacyIDEA, we develop the privacyIDEA LDAP-Proxy.

The privacyIDEA LDAP-Proxy can be used, if the application authenticates the users against an LDAP server like OpenLDAP or Microsoft Active Directory. The privacyIDEA LDAP-Proxy is plugged between the application and the originial LDAP server. The application is reconfigured, to not use the LDAP server for authentication anymore, but to authenticate users against the LDAP-Proxy. Now, the privacyIDEA LDAP-Proxy can authenticate the users and verify the the authentication against the privacyIDEA Server and use the original LDAP server to only fetch user data.

The two factor authentication is totally transparent for the user and for the application.

The advantage of the IT department is obvious: The originial LDAP server is not touched or modified. The program code of the application is not modified or exteneded. The application is only reconfigured within the limits of the intended possibilities and supported scenarios. To the application the LDAP-Proxy looks like a normal LDAP server. Thus you will not loose any warranty and support by the vendor of the application.

In contrast to two factor solutions, which are solely based on OpenLDAP, the privacyIDEA LDAP-Proxy has one big advantage. It will work with any kind of originial LDAP server, be it OpenLDAP, Microsoft Active Directory or Samba.

Example Scenario

In our example scenario we look at the login at SuiteCRM. SuiteCRM is an Open Source Customer Relation Management solution. There are no two factor plugins for SuiteCRM. But SuiteCRM authenticates it’s users against LDAP. So we will configure SuiteCRM to authenticate the users against the privacyIDEA LDAP-Proxy to add transparent two factor authentication to SuiteCRM.

We could also look at any other application, which authenticates users against an LDAP server. But SuiteCRM suites us well. We install SuiteCRM on the Univention Corporate Server. The installation of the application works like a charm, SuiteCRM is nicely configured against the Univention Corporate Server Domain Controller – the original LDAP server. This is just to have the test scenario up and runing in a few minutes.

We can install the privacyIDEA Authentication Server on any Linux distribution or we can also install the privacyIDEA Server on the Univention Corporate Server. privacyIDEA is also contained in the Univention App Center and can be installed on the UCS within a few minutes. Then privacyIDEA is setup against the users in the Univention LDAP server automatically and the administrator only needs to enroll or assign tokens like Yubikeys, OTP tokens or smartphone apps to the users.

SuiteCRM will be configured this way, that it does not connect to the UCS LDAP server but to the privacyIDEA LDAP-Proxy.

If needed several of the components can be installed on one single system.

Integration

LDAP-Proxy installieren und konfigurieren

The privacyIDEA LDAP-Proxy is currently available via Github in a beta version. It is developed based on Python and Twisted. Thus there are many different ways for the deployment. All necessary configurations are done in configuration file once.

The administrator needs to tell, were the original (UCS) LDAP server and the privacyIDEA instance are located. In the SuiteCRM setup an additional LDAP service account is needed, which the administrator also adds to the configuration file.

For more detailed information see the file README.md.

To start the LDAP proxy run

twistd -n ldap-proxy -c config.ini

In a productive environment you would start the LDAP proxy automatically as a service via systemd. The configuration file config.ini can be stored at the location of your choice. The file example-proxy.ini contains a lot of comments, which explain all possible configuration settings.

The configuration file

The administrator needs to adapt the following configuration settings:

The parameter instance in the section privacyidea determines, where the LDAP proxy can contact the privacyIDEA Authentication Server.

The administrator needs to define the connection to the original LDAP server in the section ldap-backend including IP address or FQDN and the protocal being LDAP, LDAPS or LDAP+STARTTLS

The parameter endpoint in the ldap-proxy section also contains the information on which port the original LDAP server is listening.

Finally the administrator needs to configure the LDAP attribute which contains the loginname. This can be done using the paramter attribute in the sections user-mapping.

The service account allows common LDAP searches

Simple applications, which only verify the user with a user bind do not need any additional settings. However, SuiteCRM uses an additional service account for common LDAP searches. The administrator needs to add this service account in the section ldap-proxy with the parameter passthrough-binds and in the section service-account.

Configure SuiteCRM

In SuiteCRM the administrator only needs to reconfigure the LDAP server. Go to the Admin-Menu which can be reached in the upper right corner.

Choose Password Managemant.

Here you can configure the LDAP server. Enter the FQDN or IP address of the new LDAP proxy.

Done.

Conclusion

The SuiteCRM user is now authenticated via the LDAP proxy against privacyIDEA. The complete password entry is sent to privacyIDEA for validation. The user has to enter his static (probably LDAP password) and the OTP value. Thus you can also do smooth migrations since this looks the same to the user.

Which device (2nd factor) the user has to use for authentication is completely centrally defined by privacyIDEA. The administrator can also assign different device types to the users. Some users can authenticate with Yubikeys, others with OTP tokens or OTP cards, some with a smartphone app like the Google Authenticator and some users may get their login code via SMS or Email.

We will continue developing the LDAP-Proxy and we are looking forward to any feedback. If you want to stay updated watch the Github repository or subscribe to our newsletter.

 

privacyIDEA Enrollment Station for Yubikey and Nitrokey

privacyidea-enrollment-station

The Raspberry PI can act as a great enrollment station for Yubikey and Nitrokey.

Using the Yubikey and the Nitrokey with privacyIDEA is great. With the privacyIDEA admin client you can initialize the secret seeeds on both devices and thus achieving the highest trust with privacyIDEA. The vendor does not generate the seeds anymore – you do.

But to initializes these devices you need some drivers on your system. This is why it can be a good idea to set up a dedicated enrollment station. This integration guide takes you through the steps of setting up a Raspberry PI 3B as enrollment station. Thanks to the form factor this enrollment station looks like a simple smartcard reader on your desk. You connect it the LAN and power and you are done.

You connect with SSH (e.g. via putty or any other SSH client) to the enrollment station and issue a single command to initialize the tokens.

Putting Ubuntu 16.04 on the Raspberry PI

We are choosing Ubuntu 16.04 since it comes with the correct versions of all necessary drivers. Ubuntu Mate is available as 16.04 for the Raspberry PI 3.

You need to download the image and write it to the SD card. Please see the notes on the Ubuntu Mate page on how to do this on either Linux oder Windows.

After writing the SD card, insert the SD card in the Raspberry PI, connect power, monitor, keyboard and mouse and boot into the system.

Preparing for Yubikey

Install the follogin packages to be able to enroll the Yubikey.

apt-get install yubikey-personalization python-sqlite python-requests \
python-usb python-cffi python-enum python-yubico libykpers-1-1

Preparing for Nitrokey

The Nitrokey driver is not contained in the Ubuntu repositories. But you need to install the following prerequisites:

apt-get install libhidapi-dev git

You need to use the Nitrokey library available at github:

git clone https://github.com/nitrokey/libnitrokey
git checkout v1.0
make CXX=g++

After the successfull build, simple copy the nitrokey library to a system directory.

cp build/libnitrokey.so /usr/lib

Install privacyIDEA admin client

You need the privacyIDEA admin client to enroll the Yubikey and Nitrokey.

add-apt-repository ppa:privacyidea/privacyidea
apt-get update
apt-get install privacyideaadm

Enrolling Tokens

To enroll Yubikeys you can now issue the command

privacyidea -U https://your.privacyidea.server --admin super token yubikey_mass_enroll

while “super” being the name of your administrator. If you do not have a trusted certificate during your tests, you might use the option “–nosslcheck”.

This command will enroll the connected Yubikey and ask you to insert the next Yubikey. It will initialize Yubikeys and create new token objects in privacyIDEA until you hit Ctrl-C to exit the program.

To enroll Nitrokeys you can run the command

privacyidea -U https://your.privacyidea.server --admin super token nitrokey_mass_enroll

Ease your life

You will login to the enrollment station via SSH when you mass enroll tokens. You may find it tedious to enter all the parameters. Thus you can use a configuration file for the admin client. Create a file “yubikey” with all the parameters as content:

-U
https://172.16.200.108
--admin
super
token
yubikey_mass_enroll

and now you can easily enroll tokens with the command

privacyidea @yubikey

The “@yubikey” will read the parameters from the file “yubikey”. In the same way you can create a file for enrolling Nitrokeys.

Two-Factor-Authentication for ownCloud

Here we will show you, how you can add enterprise ready two factor authentication to your ownCloud installation.

You need an ownCloud installation with a version equal or greater than 9.1. Then you need a privacyIDEA installation. For a guide of how to install these components, please refer to other documentations. There are different ways to install privacyIDEA.

Finally you need the privacyIDEA ownCloud App, which is available via subscription and SLA.

Connect your userstore

privacyIDEA can connect to many different user stores. You probably will connect to your company’s LDAP or Active Directory. In case you run a single ownCloud installation or a lab setup, you may also want to connect to ownClouds own user store.

Create an ownCloud resolver.

Create an ownCloud resolver.

In privacyIDEA you first you need to set up the connection to ownCloud database. This will fetch the users from the ownCloud database.

This userstore is now added to a new realm.

Add users to the "owncloud" realm.

Add users to the “owncloud” realm.

Now privacyIDEA knows all your ownCloud users and you can start to enroll tokens to these users. Enrolling tokens is not covered here.

For enrolling tokens, please see some youtube videos or the online documentation.

Install privacyIDEA ownCloud App

Please get your privacyIDEA ownCloud App with your subscription and support agreement. You need to copy the privacyIDEA App to the ownCloud directory apps/twofactor_privacyidea/.

After this, the privacyIDEA App is available and can be activated.

You need to configure the privacyIDEA App.

Configure where the privacyIDEA server is located.

Configure where the privacyIDEA server is located.

The most important part is to configure the URL, where the privacyIDEA system can be reached. Here you need to specify the complete path, including possible subpaths. The default configuration would be https://your.privacyidea.server/validate/check.

Log in

After enrolling tokens to the users and activating the privacyIDEA ownCloud app users are now required to authenticate with a second factor, which is verified against privacyIDEA.

Login to ownCloud with a second factor managed by privacyIDEA.

Login to ownCloud with a second factor managed by privacyIDEA.

Using privacyIDEA you can authenticate to ownCloud with many more tokens – others than smartphone TOTP. You can use any hardware device and also special devices like the Yubikey.

Thanks to the sophisticated policy framework of privacyIDEA you can setup any workflow or user combination. Users may need a 2nd factor or not. Some users may authenticate only with a secure hardware device like the Yubikey, others may use a smartphone app.

Using the privacyIDEA ownCloud App you lift two factor authentication with ownCloud to the next level.

NPS 2012 for two factor authentication with privacyIDEA

The Microsoft Network Policy Server (NPS) is the Microsoft RADIUS server. It also provides additional services like Network Access Protection (NAP) and quarantine.

This integration guide will lead you step by step through the process of configuring NPS to work with privacyIDEA.

Network overview

Your setup might look like this or be a bit different. We assume, that you already have a NPS server installed. You may have some RADIUS clients like a firewall, VPN, switch, router or client computers connected to your NPS server.

NPS-privacyidea

The RADIUS request on the NPS is forwarded to privacyIDEA.

The RADIUS request is still sent to the Microsoft NPS. But then the RADIUS request is forwarded to privacyIDEA which verifies the one time password (OTP) and thus performs the two factor authentication.

Configure NPS for two factor authentication

Create privacyIDEA RADIUS client

On your privacyIDEA system you are also running the FreeRADIUS server with privacyIDEA. The NPS will forward the RADIUS request to the privacyIDEA server. Thus the NPS acts as a RADIUS client.

You need to add the client configuration to /etc/freeradius/clients.conf:

client NPSServer {
    secret = mySpecialNPSsecret
    ipaddr = 172.16.200.113
}

Change the IP address of your NPS server accordingly and make up a good new RADIUS secret. Restart the FreeRADIUS server.

    service freeradius restart

Configure NPS

Create a new RADIUS server group

We assume, that you already performed the basic setup of the NPS server and that you already installed privacyIDEA. On your Windows 2012 server open the Network Policy Server configuration tool.

npsremote01

Create a new forward RADIUS server

Under RADIUS clients and servers create a new Remote RADIUS server.

npsremote02

Name the new remote RADIUS server group

Create a new RADIUS server group and give it an identifying name, you remember. Like privacyIDEA.

Now you can add several RADIUS servers to this group. In this basic configuration we simply add the one RADIUS server of privacyIDEA. So click the button Add to add the privacyIDEA RADIUS server to this group.

npsremote03

Set the IP address of the privacyIDEA system

npsremote04

Specify the RADIUS secret for the communication with privacyIDEA RADIUS server

When adding the privacyIDEA RADIUS server to the server group you need to specify the IP address and the RADIUS shared secret. On the first tab give the IP address and on the second tab you need to set the RADIUS secret (e.g. mySpecialNPSsecret).

Click OK, to add the server to the server group.

If you are running more than one privacyIDEA server you can repeat this step for all of your privacyIDEA servers.

 

 

 

 

Now you have one privacyIDEA server in your server group.

npsremote05

One privacyIDEA RADIUS server in the server group

Create a new policy

Policies define how the NPS reacts to authentication requests. You need to define a policy, that tells the NPS server which RADIUS requests should be forwarded to the privacyIDEA server group.

Go to Policies and on Connection Request Policies right click and click New.

npsremote06

Create a new Connection Request Policy

The policy needs a nice name, so that you can identify it in the list.

npsremote07

Create a new policy with a new name

You can add as many conditions as you wish to. If these conditions are met, the policy will trigger. So in this basic example we just create a condition matching Client IPv4 Address in our subnet.

npsremote08

Define conditions

In the Authentication section we check Forward Request to the following RADIUS server group and select our group “privacyIDEA”.

npsremote09

Choose the previously defined server group “privacyIDEA”

You may add additional attributes to the request. But in our basic example, we can leave this untouched.

npsremote10

No attributes needed

The basic policy for forwarding two factor authentication requests to the privacyIDEA system is done. You may click the button Finish which takes you back to the overview.

npsremote11

Finish policy definition

You may define several policies in the list, reorder and enable and disable these policies. In our basic example we are just using the single policy, that forwards the requests to privacyIDEA.

npsremote12

Policy ordering

Conclusion

Configuring the NPS to forward two factor authentication requests to privacyIDEA is easy. Using more specialized functions of NPS like more conditions and more sophisticated policies you can combine the best from two wolds. Using NPS for your Windows Network access and privacyIDEA for a flexible centralized two factor authentication and management system.

Contact us for planning your network setup or get your service level agreement for privacyIDEA today.

Migrating a proprietary OTP / two factor solution

Easy migration of an existing OTP system to privacyIDEA

Often customers decide to switch their existing, proprietary OTP / two factor authentication system. They do it for several reasons. The existing system is to old and they get no useful updates anymore. Often the existing system is not flexible enough. The tokens, which run with this system, do not comply with the todays requirements. Companies merge and each company comes with its own proprietary authentication system. Sometimes the existing system is simply to expensive. And sometimes the customer prefers to use a transparent open source solution due to the increasing problems in trust and survailance.

These are reasons, why customers decide to use privacyIDEA.

Today privacyIDEA provides several possibilities to perform such a smooth migration. E.g. the RADIUS token. But starting with privacyIDEA version 2.11 there will be an even simpler migration scenario. privacyIDEA 2.11 will be released on March, 18th. If you want to stay tuned, please subscribe to our newsletter.

Centrally defined RADIUS servers

With privacyIDEA 2.11 you get the possibility to centrally define RADIUS servers. This is similar to the possibility to define SMTP servers centrally, which was introduced in privacyIDEA 2.10.

Centrally defined RADIUS server "RSA SecurID"

Centrally defined RADIUS server “RSA SecurID”

These RADIUS server definitions now can be used within RADIUS tokens or policies!

Up to privacyIDEA 2.10 each user had to get his own RADIUS token. Such a RADIUS token points to the RADIUS server of the obsolete OTP system. As long as the user has no real OTP token within privacyIDEA, the user will be authenticated against the obsolete OTP system.

One policy for all users

Starting with version 2.11 you now can define a privacyIDEA policy based on this centrally defined RADIUS server.

radius-passthru-en

The centrally defined RADIUS server “RSA SecurID” is used in the passthru-policy.

To do this, the existing passthru-policy was enhanced. The passthru policy fires, if a user has no token assigned within privacyIDEA. With the passthru-policy the authentication request is forwarded to the LDAP or AD or — new in version 2.11 — to a centrally defined RADIUS server.

This means, that you only need to define one single policy to start a smooth migration from your old OTP system to privacyIDEA. You can then enroll new tokens to the users within privacyIDEA step by step without a hurry or without doing a hard switch!

Migrate!

The scenario described in this post works flawlessly with all systems, that use a RADIUS server. Including systems like Kobil, RSA SecurID, SafeNet, Vasco (in alphabetical order).

Just ask us!

Additional Service for privacyIDEA support customers: CentOS 7 repository

We are enhancing the services for the support levels for privacyIDEA.

Services for Support Customers

privacyIDEA-200px

Depending on the Service Level Agreement support customers already receive interesting services. Thanks to these services privacyIDEA is ready for the use in enterprise environments. NetKnights guarantees the functionality of the software. This way support customers do not need to worry about the Open Source “No Warranty”-disclaimer. According to the reaction times in the SLAs we work on eventual problems to solve these quickly and fuss-free. In addition we inform support customers in a timely manner about bugs and security issues.

With the support levels Gold and Platinum we offer more services like consultancy, special updates and priorization of feature requests.

In the course of further improving the services for our support-customers we also like to ease the process of installation and updates of privacyIDEA. To do so we now provide a repository for CentOS 7.

privacyIDEA CentOS 7 Repository

centos-logo-light

Many companies rely on CentOS or Red Hat as their Linux distribution. This is why we decided to provide a repository for CentOS 7 (or RHEL 7). Using this repository privacyIDEA can be quickly and easily installed and also easily updated.

Support customers get access to this repository. This way they can receive quick and realiable updates during their support life time.

Configuration and Installation

On the CentOS 7 system you need to create the file /etc/yum.repos.d/privacyidea.repo with the following content:

[privacyidea]
name=privacyidea
baseurl=https://user:password@lancelot.netknights.it/rpmrepo/centos/7/x86_64/
enabled=1
gpgcheck=0

Then the following commands must be executed:

yum update
yum install privacyidea-server

privacyidea-server is a meta package, that will install the privacyIDEA program code, the Apache2 webserver and MariaDB. All components will be configured accordingly. After running the install command the only thing left to do is create an administrator and the new privacyIDEA system is up and running and ready for use.

You can find the usual and additional installation and configuration instructions in the online documentation.

Updates

Customers get their updates via the usualy yum update mechanism.

Your Service Level Agreement

Do you want to use those enhanced services? Get your Service Level Agreement today and by that you can assure, that all your important logins are protected with a 2nd factor and that you are always running the latest software release of privacyIDEA.

 

Update 2015/01/28

If you want to run FreeRADIUS you need to add a further repo:

[privacyidea-noarch]
name=privacyidea-noarch
baseurl=https://user:password@lancelot.netknights.it/rpmrepo/centos/7/noarch/
enabled=1
gpgcheck=0

Then run:

yum install epel-release
yum install privacyidea-radius

Two Factor Authentication and SSO with privacyIDEA and SAML

privacyIDEA works well with the Univention Corporate Server. In a guest blog article on the Univention Blog Cornelius Kölbel describes how privacyIDEA increases Single Sign On Security with Two Factor Authentication.

Easy and simple OTP mass deployment

If you need to deploy a huge number of OTP tokens to your end users, this is often a tricky challenge. The two factor authentication with these enrolled tokens may only be as secure as the enrollment process itself. Often a simple password is not enough to let the user enroll or assign a token as second factor. If an attacker gets hold on the users password, the attacker easily can enroll a token for himself also getting access with two factors.

In this case the user has to be identified securely with an additional step. Sending a postal letter with a registration code may help. Thus the user can only enroll a two-factor OTP token, if he knows the password and has phyiscal access to the letter box where he will find the registration code.

privacyIDEA provides the possibility to use such a registration code enabling you to secure the automated deployment process with a huge number of users.

NetKnights helps you planning your authentication infrastructure and designing workflows, that fit your requirements.