You want to use two factor authentication for all your users? But you are always wondering how you should enroll an authentication device to every single of your users? Existing solutions do not provide convenient ways to equip thousands of users easily with a second factor?

Using automated processes with a REST API and an automating event handler privacyIDEA provides the necessary means to easily do this task.

At FOSDEM Cornelius will give a talk about how easy it can be using privayIDEA to enroll second factors to all your lots of users. Join FOSDEM in Brussels and February 4th and learn about those great features of privacyIDEA.

Look at my Nitrokeys. The pre-release of the Nitrokey Pro, the Nitrokey Storage and Nitrokey HSM. The Nitrokey is a crypto device, which you can use to store your PGP Keys or just RSA keys and thus sign and decrypt data. It comes with a password safe and the ability to generate one time passwords. It is open hardware and all necessary software is open source. Thus it is a great device to be combined with the open source authentication system privacyIDEA.

Nitrokey managed by privacyIDEA

You can manage your keys locally on your desktop with the Nitrokey-App. You can reset the user PIN and the administrator PIN (SO PIN). And you can manage the passwords in your password safe.

But you can not use the OTP functionality as you need a backend or an application to authenticate against. The idea to manage the Nitrokey with privacyIDEA was around for a while. Issues have been filed to the privacyIDEA github project and the privacyIDEA command line client. Managing the OTPs of the Nitrokey seemed to be a logical first step.

Just yesterday I pushed the code to the github repository of the privacyIDEA command line client. The good news is, that there are no changes in the privacyIDEA backend necessary. The Nitrokey acts as an HOTP or TOTP token – both token types are already supported by privacyIDEA. The command line client takes care of initializing the Nitrokey and creates the token object in the privacyIDEA backend.

privacyIDEA and hardware tokens

privacyIDEA already supports several hardware tokens, which can be seeded: like the Yubikey, U2F devices, eToken NG or daplug token. Most of these tokens (except U2F) are initialized via the command line client. The great thing with the command line client is, that the tokens like the Yubikeys can be mass enrolled. This way the administrator can initialize hundrets of tokens in a few minutes and initialize these with new key material – being independent of the vendor.

With the Nitrokey you can do this, too. But you also get a bonus. You are indepent with your key material of any vendor and you get a hardware, that is open, where you can simply run your audits on it.

Enroll a Nitrokey HOTP token

To be able to enroll the Nitrokey you need to get and install the Nitrokey-App and libnitrokey. The privacyIDEA admin client uses libnitrokey to initialize the OTP slot. The Nitrokey support in the privacyIDEA admin client is totally new. It is not contained in the packages of the privacyIDEA admin client, yet. So you also need to get the github repository and install the privacyIDEA admin client via

  python setup.py install

Now you can enroll Nitrokeys:

  privacyidea -U https://localhost --admin super --nosslcheck token nitrokey_mass_enroll --slotname meiner0 --slot 0

The new command option nitrokey_mass_enroll will start the mass enrollment process for Nitrokeys. This will only work if all Nitrokeys have the same admin PIN. At the moment the admin PIN is requested during startup and not for each enrolled Nitrokey.

You can specify which slot should be written. There are 3 HOTP slots, so this value can be 0 – 2. You can also set a slotname for this slot.

The admin client will ask you for the next Nitrokey to be inserted. This way you can initialize OTP slots of many Nitrokeys and then give these keys to your users.

The great thing is, the admin client will read the serial number of each Nitrokey during the rollout process. It then create an HOTP token object in the privacyIDEA backend with the token serial NK<serial>_<slotnumber>. This way you can easily identify devices.

Maximum trust

privacyIDEA once more improves the level of trust by supporting the open hardware Nitrokey. Get transparent software and transparent hardware to boost trust to the max.

Self Registration and Password Reset

privacyIDEA comes with a new policy scope “register”. If this policy is set new users may create a new account. The creation of the account can be limited to certain realms or to certain email addresses. This way you can define, that only user with an email address from a certain domain are allowed to register.

The user will get an email with a registration token, that can be used to access the privacyIDEA Web UI.

User registration was also introduced in a previous blog post.

User registration is possible due to the concept of writeable userstores, which was introduced earlier. Another possibility that arises from the writeable userstores and which is introduced in version 2.10 is User Password Reset. In a user-policy you may define, if a user should be allowed to reset his userstore password.

Token Wizard

Enrolling tokens to the user is always quite a challenge. No project or installation works the same, has the same requirements and chooses the very same enrollment strategy. It always seems very tempting to let users enroll their tokens, hoping that this strategy will not generate high traffic and costs in the help desk.

With privacyIDEA 2.10 the token user selfenrollment was drastically simplified providing a token enrollment wizard. The token enrollment wizard can be enabled using a policy. The enrollment wizard will jump in, if the user has no token. When the user logs in to the WebUI he will be presented a two step enrollment without any distracting additional questions or choices.

The tokenwizard works for all kind of tokens. In this example it is a smartphone based Google Authenticator HOTP token.

Email

After all this user stuff another important feature is the configuration of the Email-capabilities in privacyIDEA. Emails are used at different locations like EMail Token, SMS Token, Registration process and Password Reset. Therefore you can defined SMTP Server configurations centrally and choose which SMTP configuration you want to use for the specified task.

ChangeLog

This is the complete changelog of version 2.10:

Version 2.10, 2016-02-11

Features

• User Registration: A user may register himself and thus create his new user account.
• Password Reset: Using a recovery token a user may issue a password reset without bothering the administrator or the help desk.
• Enrollment Wizard for easy user token enrollment
• SMTP Servers: Define several system wide SMTP settings and use these for
  • Email token,
  • SMTP SMS Provider,
  • registration process,
  • or password reset.

Enhancements

• Ease the Smartphone App (Google Authenticator) rollout. Hide otplen, hash, timestep in the UI if a policy is defined.
• Add import of Aladdin/SafeNet XML file.
• Add import of password encrypted PSKC files.
• Add import of key encrypted PSKC files.

Fixes

• Support LDAP passwords with special non-ascii characters.
• Support LDAP BIND with special non-ascii characters.
• Fix problem with encrypted encryption key.
• Fix upgrading DB Schema for postgresql+psycopg2.
• Fix UI displaying of saved SMS Provider.
• Do not start challenge response with a locked/disabled token.

The admin client already provided an easy way to enroll a bunch of yubikeys by initializing them one after another. Running

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

you are able to plugin a yubikey, wait for the admin client to initilize it within a second pull it and plug in the next. Without even pressing a key. (Hit Ctrl-C when you are done). This would write all the otpkey material directly to the specified privacyIDEA system. This was the status quo. This way you are able to initialize hundrets of yubikeys just by plugging in and pulling out.

Anyway. In certain cases this would not work, since you might have no USB access on the machine, from which you are accessing the privacyIDEA server.

With privacyIDEA admin client 2.5 it is now possible to initilize a bunch of yubikeys without the privacyIDEA server available. The otpkeys will be written to a file which you can import to privacyIDEA later. Run

privacyidea token yubikey_mass_enroll --filename secrets.csv

and all the secret otp keys will be written to secrets.csv. (Please note, that this file is not encrypted and contains the new secret keys of the initilized yubikeys)

Now you can import the file to any privacyIDEA system.

privacyIDEA is moving towards a central point to manage authentication items. This was done by adding the machine concept, SSH keys, using Yubikeys for booting LUKS and now by adding the possibility to manage certificates.

privacyIDEA acts as a central control room to manage all relevant points. In 2.3 the managing of client certificates was added. But privacyIDEA is not just another certificate authority. No, privacyIDEA follows the same concept as for user resolvers, machines and applications and lets you define CA connectors that – as the name suggests – connects to existing certain certificate authorities. Thus you may even have several CAs for different purposes and configure privacyIDEA to connect to them all.

Then you can assign certificates (a new token type) to the users and have the users enroll their certificates easily from within the modern Web UI. You can read more about this at the online documentation.

Also other interesting things were added like the registration token type, which eases the process of mass enrollment.

Adding the SCIM Resolver provides better means to be integrated into Cloud setups.

The new TYPO3 plugin is interesting for all Web Hosting companies.

The complete ChangeLog looks like this:

• Add connector to remote Certificate Authority.
• Add Tokentype “certificate” to manage certificates for users Certificates or Certificate Requests can be uploaded. Certificate Requests.(Keypair) can be generated in the browser.
• Add Tokentype “registration” for easier enrollment scenarios.
• Add TokenType “Email” to send OTP via Email.
• Add “First Steps” to online documentation to ease the process of getting up and running.
• Add handling of validity period of token.
• Enable download of Audit log as CSV.
• Add Resolver Priority, to handle a duplicate user in a realm.
• Add TYPO3 Plugin to enable OTP with TYPO3
• Add SCIM Resolver to fetch users from SCIM services
• Several Fixes like:
  • Failcounter issue
  • NTLM password check
  • timestep during enrollment
  • Yubikey CSV import

As usual there are several different ways to install or upgrade the system.

Today I will show you, how you can setup a scenario, where users can authenticate with Yubikey and/or Google Authenticator and you can define centrally, for which server the users need a Yubikey to authenticate and for which other server a Google Authenticator would be sufficient. Thus you can enforce security levels, meaning servers carrying more sensitive data can only be accessed with a hardware device like the Yubikey while others are ok to be accessed with a software token like the Google Authenticator.

Unique user, two tokens, many machines

You should already have read about enrolling yubikeys and how to use privacyIDEA for  two factor authentication to your server farm. So I assume, that you have a running installation.

You should have enrolled two tokens to the user root as depicted below:

The user root has a Google Authenticator (serial OATH…, OTP PIN “google”) and a Yubikey (serial UBOM…, OTP PIN “yubi”) token.

Both tokens can be used to authenticate from all configured clients. From localhost (172.16.200.41):

[root@centos6 ~]# echo "User-Name=root, Password=google977398" | radclient -sx localhost auth testing123
Sending Access-Request of id 167 to 127.0.0.1 port 1812
 User-Name = "root"
 Password = "google977398"
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=167, length=48
 Reply-Message = "privacyIDEA access granted"
Total approved auths: 1
 Total denied auths: 0
 Total lost auths: 0

[root@centos6 ~]# echo "User-Name=root, Password=yubi899739" | radclient -sx localhost auth testing123
Sending Access-Request of id 100 to 127.0.0.1 port 1812
 User-Name = "root"
 Password = "yubi899739"
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=100, length=48
 Reply-Message = "privacyIDEA access granted"
Total approved auths: 1
 Total denied auths: 0
 Total lost auths: 0

Or from a remote host (172.16.200.106):

cornelius@puckel ~ % echo "User-Name=root, Password=google308786" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 11 to 172.16.200.41 port 1812
    User-Name = "root"
    Password = "google308786"
rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=11, length=48
    Reply-Message = "privacyIDEA access granted"

       Total approved auths:  1
       Total denied auths:  0
       Total lost auths:  0

cornelius@puckel ~ % echo "User-Name=root, Password=yubi867011" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 47 to 172.16.200.41 port 1812
    User-Name = "root"
    Password = "yubi867011"
rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=47, length=48
    Reply-Message = "privacyIDEA access granted"

       Total approved auths:  1
       Total denied auths:  0
       Total lost auths:  0

The idea

The idea is to allow access on the machine 172.16.200.106 only with yubikeys. This is the machine that carries tons of sensitive data and we do not want users to authenticate with their Google Authenticator.

The host with the higher security level

To accomplish this privacyIDEA provides a special authorization policy that will only grant access, if the the authentication was performed with the correct token.

So lets configure a policy:

This policy tells the system, that if the client 172.16.200.106 issues an authentication request, it should only be approved, if the serial number of the authenticating token contains the string “UBOM”.

Note: As we are using RADIUS the client 172.16.200.106 issues a radius request to the RADIUS server 172.16.200.41 and the RADIUS server issues the request to the privacyIDEA server 172.16.200.41/127.0.01. Thus the request that arrives at the privacyIDEA server will always be issued by the RADIUS server. So we need to allow the RADIUS server to overwrite the client information – thus the RADIUS server will tell the privacyIDEA server, what the calling RADIUS client was.

We can set this in the system config.

We set the localhost and the eth0 IP of the RADIUS server in a comma seperated list: 127.0.0.1, 172.16.200.41.

The yubikey now can successfully authenticate at the sensitive host:

cornelius@puckel ~ % echo "User-Name=root, Password=yubi773998" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 88 to 172.16.200.41 port 1812
 User-Name = "root"
 Password = "yubi773998"
rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=88, length=48
 Reply-Message = "privacyIDEA access granted"
 Total approved auths: 1
 Total denied auths: 0
 Total lost auths: 0

while the Google Authenticator fails to do so:

cornelius@puckel ~ % echo "User-Name=root, Password=google850707" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 24 to 172.16.200.41 port 1812
 User-Name = "root"
 Password = "google850707"
rad_recv: Access-Reject packet from host 172.16.200.41 port 1812, id=24, length=55
 Reply-Message = "privacyIDEA server denied access!"
 Total approved auths: 0
 Total denied auths: 1
 Total lost auths: 0

We can see this in the privacyIDEA audit log:

Google Authenticator is still good for default servers

But we can still use the Google Authenticator for the default server with lower security level:

[root@centos6 ~]# echo "User-Name=root, Password=google069728" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 162 to 172.16.200.41 port 1812
    User-Name = "root"
    Password = "google069728"
rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=162, length=48
    Reply-Message = "privacyIDEA access granted"

       Total approved auths:  1
         Total denied auths:  0
           Total lost auths:  0

We can check this in the audit log, again:

Conclusion

privacyIDEA can be used to enroll many different authenticators to your users and mange these devices centrally.

In a second step you can decide who authenticates where with which device without bothering to reenroll any device.

Thus you can enforce your security policies easily. Additionally the audit log keeps track of all events that do not comply to your security policy.