,

Simple enterprise ready 2FA for ownCloud X

A few days ago ownCloud introduced the new market place. Using the market place ownCloud adminsitrators  can easily and quickly install ownCloud apps. The privacyIDEA ownCloud App by NetKnights is one of the first available apps in the market place. Using the privacyIDEA ownCloud App companies and organizations can secure the login to ownCloud with a centrally managed multi factor authentication. The authentication devices of the users are managed within privacyIDEA authentication system.

Installing the privacyIDEA ownCloud App

Within ownCloud X the administrator can enter the market place via the top left menu.

He needs to filter the categories for “security”. There are several advantages of a centrally managed 2FA system in contrast to the integrated TOTP app. The administrator can define which user has to use a second factor and the users can use this very second factor, this authentication device for any other application like VPN or desktop login.

Clicking on the privacyIDEA ownCloud App or “privacyIDEA Two Factor Authentication” will display all the details of the app in the market place.

Now the administrator can install the app by clicking the blue “install” button. The installation is rather quick. After successful installation the blue button turns grey.

Configuring privacyIDEA ownCloud App

Now the administrator needs to configure the privacyIDEA ownCloud app.

To do this, he needs to enter the top right menu via Settings->Additional and can now see the section privacyIDEA 2FA. There he needs to configure the URL of the privacyIDEA server. Usually this is something like https://myserver/validate/check.

Warning: You maybe need to remove the checkbox “Verify SSL certificate” for your tests. We very much recommend the have this checkbox checked for productive use!

That’s all. Now the administrator is done configuring the privacyIDEA ownCloud app.

Configuration of privacyIDEA

We assume that privacyIDEA is already installed following one of the many possible installation scenarios. Now the administrator needs to configure the user store in privacyIDEA, so that privacyIDEA knows the ownCloud users and the administrator or the users can enroll tokens.

Define user store

The administrator first needs to configure the user store. In this example we are using the ownCloud database as user source. The administrator needs to go to Configuration -> Users.

Create user realm

The the configured user store needs to be joined to a realm. Under Configuration->Realm the administrator can create a realm with this user store. In this example the realm is called “oc”.

When entering the user-tab, the administrator will now see all the ownCloud users within privacyIDEA.

Enroll Token

Now the administrator or the user himself can enroll a token. This could be a TOTP/Smartphone-App or any other of the many supported token types within privacyIDEA.

The administrator can select a user object and enroll a token to this user. Alternatively users can login to the privacyIDEA WebUI and enroll a token for themselves.

Thus the administrator or IT department can manage, which user has which token (second factor). If any authentication device gets lost, privacyIDEA provides means to centrally allow temporary access for such a user or to enroll a new (temporary) token.

Login

When logging in to ownCloud, in the first step the user needs to enter his username and his ownCloud password. In a second dialog the user is asked for his second factor which is verified against privacyIDEA.

Please note, that you need a subscription file for the privacyIDEA ownCloud App for productive use.

Have a successful authentication!

, , ,

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.

, ,

Migrate LinOTP to privacyIDEA

The authentication system LinOTP 2 has been around since 2010. privacyIDEA is a fork that was introduced in 2014 which features a more modern architecture.

This post explains to you, how you can easily migrate all your authentication tokens and user settings to privacyIDEA. This is done by installing privacyIDEA with a copy of all your productive data. The LinOTP installation is not modified. This way you can test the migration and switch machines, when everything is fine.

If you want to migrate another, proprietary OTP solution, please read this post.

Backup LinOTP data

Under the hood privacyIDEA dropped the single-table configuration and uses database tables for logical structures like the resolver and realm definition. So I recommend to backup your data and work with the backed up data.

First dump your LinOTP database to a file:

mysqldump -u linotp2 -p LinOTP2 > linotp2.sql

You can find the password of the database user “linotp2” in the file /etc/linotp2/linotp.ini.

Also copy the encryption key /etc/linotp2/encKey.

Install privacyIDEA

Perform a clean installation of privacyIDEA. You can follow any installation procedure in the online documentation.

Copy the encryption file to /etc/privacyidea/enckey. Note that privacyIDEA by default does not use the uppercase “K” anymore.

Checkout and remember the database URI SQLALCHEMY_DATABASE_URI in /etc/privacyidea/pi.cfg.

 

Create a local copy of LinOTP database

On the privacyIDEA server you can now create a copy of the LinOTP database.

# mysql -u root -p
mysql> create database linotpdump;
mysql> grant all privileges on linotpdump.* to "linotp"@"localhost" identified by "topSecret";

 

You now can use the database URI mysql://linotp:topSecret@localhost/linotpdump.

Migrate the data

Download the migration script from github. In newer versions, this script might also already be packed with the privacyIDEA server.

In the script you need to adapt the lines

LINOTP_URI = "mysql://linotp2:testtest@localhost/LinOTP2"
PRIVACYIDEA_URI = "mysql://pi:pi@localhost/pi"

accordingly.

Now you can run the script

python privacyidea-migrate-linotp.py

As privacyIDEA uses internal token administrators, you should setup your first administrator

pi-manage admin add superuser

Now you can login to the WebUI as superuser and checkout all tokens.

What data is migrated?

The migration script migrates the resolver definitions, the realm definitions and all token data with all user assignments. The resolvers and realms are stored in the new privacyIDEA style. The additional tokeninfo is stored in the new extra privacyIDEA tokeninfo table.

Audit, System Config and Polcies are not migrated. We recommned creating the policies in privacyIDEA anew.

Note: At the moment only LDAP-Resolvers are migrated. Please ask us for automatic migration of any other resolver type.

, , ,

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.