privacyIDEA Authenticator – the better smartphone factor

privacyIDEA Authenticator Smartphone App

The smartphone is our daily tool and the digital copy of our own identity. This is not the place to discuss the social implications. We just state the fact.

The Smartphone as the second factor

Due to this fact many organisations and companies like to use smartphones for a security improved authentication process. The smartphone is “always” with the user and is the device, that is accepted by the user. Using applications like Google Authenticator the smartphone is supposed to become the second factor for authentication. Although the smartphone is obviously not as secure as a dedicated hardware token, the privacyIDEA Authentication System has supported smartphones as  a possible second factor right from the start.

But taking a look at a smartphone app like the Google Authenticator there are some security issues. We discussed this in detail in a previous blog post. The problems with the rollout process using the Key URI defined for the Google Authenticator, finally made us develop our own privacyIDEA Authenticator. As an Open Source company we use the Github-Repository to transparently develop the privacyIDEA Authenticator app.

Secure enrollment

The first and most important feature from the long feature list is securing the enrollment process. To do so, the privacyIDEA Authenticator allows to generate one key component on the smartphone itself and another key component on the privacyIDEA Server. The final OTP seed / key is generated from both components.

This way we avoid the easy cloning of the secret OTP seed during the enrollment process. By cloning the OTP seed users were easily able to create undistinguishable copies of the OTP token and thus making the smartphone as a second factor to identify the user useless. Using the privacyIDEA Authenticator you will be able to leave this problem behind.

Beta testing

The privacyIDEA Authenticator app is backward compatible with Google Authenticator and FreeOTP. Its full potential will be unleashed with the privacyIDEA Server starting with version 2.21. Starting with this version the mentioned two-step-enrollment is supported.

The privacyIDEA Authenticator app is available in a controlled beta state. privacyIDEA 2.21 will be available this month. Using the Python Package Index or the developer PPA repository for Ubuntu 14.04LTS or 16.04LTS you can already install the release candidate of the server.

Install using the Python Package Indes:

pip install privacyidea==2.21dev2

Or install using the PPA respository:

add-apt-repository ppa:privacyidea/privacyidea-dev

You can get more information about the installation in the online documentation.

If you want to test the privacyIDEA Authenticator app you are welcome to drop us a note. We will add you to the beta test. You have the possibility to influence the development of the app. The privacyIDEA Authenticator is currently available for Android. The installation during the beta tests is done via the Google play store. Thus you do not need to change any settings of your smartphone.

Get in touch to be part of the beta test!

Transaction signature and federated authentication with privacyIDEA4UCS 2.20.1

The privacyIDEA Enterprise Edition version 2.20.1 is now available for Univention Corporate Server. You can install or update privacyIDEA 2.20.1 on the UCS easily from the Univention App Center.

Please note that the subscription handling was changed in privacyIDEA4UCS. You now no longer need a special license file but the common subscription file, which is used with the common privacyIDEA Enterprise Edition. Existing clients already received the new subscription file. If you are running tests in a demo environment, you can create your own demo subscription file for privacyIDEA4UCS.

OCRA, Display-TAN and Federation in privacyIDEA 2.20.1

We already posted about the common release of privacyIDEA version 2.20.1. Now also customers running privacyIDEA on UCS can use the awesome new features:

New token types OCRA token and the Display-TAN card are not supported. In contrast to classic authentication scenarios the OCRA token also allows the signing of transaction data. Using an OCRA token the user can testify, that the data set he is sending is correct. The recepient can cryptographically verify, that the received data is still valid and unmodified. This can be used in banking scenarios and other applications, where data must not be modified.

A second main feature is the federation handler. This allows to forward special authentication requests to other, subordinate privacyIDEA systems. This is interesting for federated organizations and infrastructures. Departments may run their own privacyIDEA systems. A central privacyIDEA system in the orgnization can then forward the authentication requests to the corresponding departments.

A complete changelog can be found here.

Get your personal subscription file for privacyIDEA4UCS!

We are happy to answer any of your questions!

 

privacyIDEA 2.20.1 Enterprise Edition released

Today we released the stable version 2.20.1 of the privacyIDEA Enterprise Edition.

The Enterprise Edition as version 2.X.1 is released a few weeks after the corresponding major public release and contains necessary bug fixes. We already wrote about version 2.20.

Version 2.20.1 now fixes some minor bugs:

  • When using PostgreSQL database the administrator can now filter for the data as expected.
  • During enrollment the default realm will be set as default in the UI.
  • Errors with PassOnNoUser and PassOnNoToken were fixed.
  • The genkey parameter during enrollment was consolidated.

The Enterprise Edition of the Multi-Factor-Authentication system privacyIDEA is ment for enterprises and organizations, which need a reliable update process. It is available for Ubuntu 14.04LTS, Ubuntu 16.04LTS, CentOS7, RHEL7 and the Univention Corporate Server.

Federated authentication with privacyIDEA 2.20

Today we released privacyIDEA 2.20. Packages are publically available in the Laundpad repositories for Ubuntu 14.04LTS and 16.04LTS. You can also install the new version via the Python Package Index on any other distribution.

New Features in privacyIDEA

Federation-Handler

The new federation handler allows to forward authentication requests to sibling privacyIDEA instances.

This way you can setup network structures, where brances of an enterprise or sub organizations can run their own privacyIDEA instance under their own control. Authentication requests will be handled by a central privacyIDEA instance and forwarded to the corresponding instance, where the user and the user’s tokens are managed.

This way business devisions, departments or sub contractors can manage the tokens of their own employees.

The federation handler also offers new possibilities and business models for service providers.

New token type OCRA and DisplayTAN

In version 2.20 we also added the basic token type OCRA and the special type DisplayTAN. The DisplayTAN is a hardware card, which can communitcate with a smartphone via Bluetooth LE. This way the OCRA challenge is sent to the card, the user can check the challenge data and the card will generate an OTP value as response.

OCRA is specified in RFC 6287. A common use case is signing bank transactions. This way a TAN (OTP value) can be generated in hardware, and this TAN totally depends on the transaction information. Thus privacyIDEA can be perfectly used to manage authentication and signing devices for banking scenarios. We already talked about this in a previous blog post.

Login with different login names

The LDAP resolver now allows that a user can login with different LDAP attributes. The administrator can specify the list of attributes, which may be used as login names. This way an user can choose if he will login with the sAMAccountNAme, the email address or a telephone number.

Authentication cache

The administrator can now define if and how long succesful authentication should be cached. This way it is possible for a certain amount of time to authenticate with the very same OTP value again. Yes, this is not the original idea of OTP. But certain specific applications may need such a functionality. This behaviour is specified in an authentication policy, which can also depend on time and client IP.

More functions

Many policies now allow to use resolvers in the policy definition. This way the administrator can define the behaviour of privacyIDEA depending on user groups in detail.

During the rollout process of smartphone tokens, privacyIDEA display a QR-Code to the user. If the user is in doubt, that the QR-Code may be also seen by an attacker, he can now immediately regenerate the QR-Code.

All event handler definitions can now be ordered to your needs. This way the administrator can precisely define the behaviour and reaction of privacyIDEA.

The conditions of event handlers may now contain times and time deltas.

Challenge Response tokens can now be used to unlock the UI.

While installing Ubuntu packages, a PGP key pair is generated. The public PGP key can be easily used to encrypt the seed files before importing tokens.

You can find a complete changelog at Github.

Enterprise Edition and Consultancy

NetKnights provides consulting and support with the privacyIDEA Enterprise Edition. Using Open Source you optimize your total cost of ownership this way, that there are no external limitations which dictate how long or short your may use the software. Getting the privacyIDEA Enterprise Edition including an SLA you get the warranty and thus operating safety.

You want to stay tuned? Please subscribe to our newsletter!

You want to know more? Get in touch!

 

Welcome dialog and privacyIDEA subscription

privacyIDEA is enterprise software. Managing lots of authentication devices for lots of users is a task that occurs in a company network.

privacyIDEA is licensed under an Open Source license. This guarantees, that a company using the Open Source software privacyIDEA can use this software for life. In contrast prorpietary software or software-as-a-service (SaaS) can be changed, billed differently or even completely deleted. You could not do anything about it. The Open Source privacyIDEA is under your control – forever.

The Open Source license dos not mean that a company has no costs in regards to two factor authentication. At least they need to pay the administrator.

In any case the Open Source license states that this software comes without any warranty. A company using privacyIDEA needs to be aware of this.

privacyIDEA is Open Source and thus comes without any warranty by default.

Due to this we decided to add a welcome dialog in version 2.20. This welcome dialog points out the fact, that it is important to get a Service Level Agreement (privacyIDEA Enterprise Edition) when running this software in an enterprise environment.

The administrator can define a policy (scope=webui, action=hide_welcome) which deactivates this welcome dialog. Anyway, if you run privacyIDEA with more than 50 assigned tokens and without subscription/SLA, we think it is a good idea, to warn the administrator again about the intrinsic risk running a software without warranty. The welcome dialog will be displayed again.

Using this approach we hope to help companies understand the legal situation when running privacyIDEA.

You are welcome to contact us with any questions.

World Wide Web Consortium is enrolling 2FA using privacyIDEA

Kassel, September, 26th 2017. The World Wide Web Consortium (W3C) is implementing privacyIDEA for securing access to their infrastructure with a second factor. The privacyIDEA Authentication System was chosen due to its flexible nature and the possibility to allow a single sign on experience for the users.

The services and especially the users are distributed world wide. Shipping authentication devices centrally is not efficient. Allowing only one type of authentication object is not an option. For W3C this is a big advantage that privacyIDEA can manage many different token type of different vendors at the same time. The lean REST API allows easy integration into their own user portal. W3C connected privacyIDEA to their existing user management. Users will be able to choose if they want to self-enroll Smartphone-Applications or U2F devices. Depending on the device type users gain access to resources of different security levels.

“Working with NetKnights is very effective. They provide just the right amount of consultancy for us to be able to implement the open source software privacyIDEA into our network and in our workflows.” said Ted Guild, Head of W3C Systems. Cornelius Kölbel, CEO at NetKnights, added: “W3C stands for Web standards. So we are very happy that W3C chose privacyIDEA, as this is an open solution, which complies to an open development workflow and open standards.”

About the World Wide Web Consortium (W3C)

The mission of the World Wide Web Consortium (W3C) is to lead the Web to its full potential by creating technical standards and guidelines to ensure that the Web remains open, accessible, and interoperable for everyone around the globe. W3C standards HTML5 and CSS are the foundational technologies upon which all Web sites are built. For its work to make online videos more accessible with captions and subtitles, W3C received a 2016 Emmy Award.

W3C’s vision for “One Web” brings together thousands of dedicated technologists representing more than 400 member organizations and dozens of industry sectors. Organizationally, W3C is jointly run by the MIT Computer Science and Artificial Intelligence Laboratory (MIT CSAIL) in the United States, the European Research Consortium for Informatics and Mathematics (ERCIM) headquartered in France, Keio University in Japan and Beihang University in China.

For more information see www.w3.org.

About NetKnights and privacyIDEA

NetKnights GmbH is located in Kassel, Germany. It is an independent IT Security firm, providing services and products in the fields of strong authentication, identity management and encryption. NetKnights employs the core developers of the modular authentication system privacyIDEA.

privacyIDEA is open source software and thus has not vendor defined end of life. Customers can own their privacyIDEA installation and use it without restrictions. NetKnights provides different subscription and support levels of privacyIDEA Enterprise Edition to meet the requirements of companies.

From October 10th-12th NetKnights presents privacyIDEA at the IT security fair it-sa in Nuremberg, Germany, at stand 10.1-208.

Securing bank transactions with privacyIDEA

Making wiring money secure is a big challenge. We are all grateful, that we no longer need to go to the bank institute for wiring money to another bank account. It is also great that we do not need to use these TAN lists anymore, when we were asked to cross out number by number after each bank transaction.

But what are still the challenges with electronic bank transactions?

Integrity of the transaction data

The banking user uses a web interface to tell the bank, how much money he wishes to send to another account. A malware in the user’s browser, can change this data. Originially the user wanted to send €100 to the account 1234567890, but when he clicked the button “send”, the malware changed the transaction data to €10000 and to the account 666.666.XX. The bank receives the 10000 Euros for the evil account. It has no chance to know, that originally the user wanted to send 100 Euros to his friend. Also the user does not immediately know what happened.

The money might be gone.

TAN lists and OTP tokens

The transaction data could be changed before they reach the bank.

Several years ago TAN lists were used. Some banks are using OTP tokens, to identify the user, during a transaction. But the TAN lists and the OTP tokens can not ensure the integrity of the transaction data. The OTP token can be used to verify that it is really the true user, who is in the possession of the token and who triggered the transaction. But still a man in the middle can intercept a valid transaction and change the amount and account! Still neither the bank nor the user know, that something happened in between.

This is due to the problem, that there is no cryptographic link between the transaction data and the OTP.

OCRA: Linking transation and TAN

The OATH Challenge Response Algorithm (OCRA) can provide this missing link. OCRA is specified in RFC 6287. 

Just like HOTP and TOTP – which you might know from the Google Authenticator – the OCRA algorithm is defined by the Initiative for Open Authentication. Basically OCRA is some kind of enhanced HOTP algorithm.

The HOTP algorithm takes only one parameter, the “counter”, which is increased continously by each key press. In conjunction with the secret key a 6 or 8 digit one time password is calculated. The secret key represents the possession factor. Thus the one time password depends on the secret key and the parameter “counter”. In case you like buzz words like HMAC and SHA, take a look at RFC4226).

To cut a long story short, OCRA simply enhances the “counter” and allows many more input parameters for roughly the same algorithm. I.e. you can also put the account number and the amount into the OCRA algorithm. This will result in a one time password, which depends on the secret key and the complete transaction data. If you or an attacker would put other transaction data (input parameters) into the algorithm, this would result in another OTP value.

How can this be used for online banking?

The bank initially hands over the secret key to the user. The key can be contained in a hardware device or in a smartphone app. The bank knows each secret key of each user.

The user enters his transaction data on the banking website. The user also transfers the transaction data to his device (which contains the secret key). This transfer could be done manually or in any automatic manner using QR codes, network or bluetooth.

On the device the user verifies the correctness of the transaction data. Only then he continues by generating the TAN on the device. He now can add this TAN in the banking website. The transaction data and the TAN is sent to the bank.

As mentioned earlier the TAN cryptographically depends on the transaction data. The bank can use the user’s secret key to also calculate the TAN for the given transaction data. If the bank gets the same TAN, the bank knows, that the user really was willing to perform this transaction and that the transaction data were not modified by an attacker. Otherwise the modified transaction data would result in a different TAN.

In this scenario each and every transaction which is issued by a bank customer is cryptographically secure. So it is more important to protect the secret key in the device than the online banking account itself, since there can be no transaction without the secret key.

privacyIDEA, OCRA and DisplayTAN

privacyIDEA supports OCRA (the TiQR token) for quite a while. In the upcoming version 2.20 the OCRA mechanism was enhanced, so that it can be used with many different devices, especially with the DisplayTAN-card.

Banks do not need to program the key management for their web application on their own to support OCRA. They can easily use one single REST API call with privacyIDEA to add strong transaction security with privacyIDEA.

The DisplayTAN cards are attractive for customers, since they can be integrated in the banking card itself. This way the customer can have on card for all tasks.

Just ask us!

About Enterprise File Encryption

This article was first published at owncloud.

Your Data is at risk. And thus is your personal life and your company’s values.
You avoid hackers, trade espionage and rogue governments getting your data by using your own cloud storage like ownCloud. Your data under your control.

But depending on where your storage is located some risks still remain. The connection to your ownCloud installation in the hosted datacenter is TLS protected. All data are encrypted on their transport to the datacenter. But within the datacenter your data is plain text.
You are using ownClouds integrated encryption? You even have the full disk encrypted using LUKS or similar methods? This is fine but only protects you from certain attacks like stealing the sole hard disk.
But if the attacker gains access to the very location where the actual encryption takes place, the encryption is useless, since this location also contains the encryption key! Thus, if the attacker has access to the datacenter or – more probably – is a rogue or bribed employee of the datacenter the attacker can get physical access to your encryption key and finally to your data.

This is why client side encrpytion is such a good idea. With client side encryption the data is encrypted on your own client. The key material is only available on your client, not on the ownCloud server. The data is sent already encrypted to the server. Not only is the transport layer encrypted using TLS but the payload itself within the TLS can not be read anymore.
The ownCloud server and the storage never sees any clear text data and never has access to the encryption key.
The tool cryptomator which was introduced in this[link] previous blog post works this way.

Requirements

But enterprise scenarios come with a longer requirements list than tools like the slick cryptomater can cover.
Even smaller companies have to comply with the requirements of the enteprrises if they are supplier for the bigger ones.
I have run several projects where supplying companies were confronted with the requirements for encrpytion and two factor authentication since they delivered to bigger enterprises, that simple defined those requirements. Let us take a look at the requirements when you run a company or bigger organization.

File Encryption

In such scenarios when encrypting data it is important to encrypt files. In contrast to full disk encryption and encrypted containers encrypted files can be moved around without breaking the encryption. Even the encrypting file system does not provide this sticky encryption. If the user moves the file to another disk or a USB stick, the file would not be encrypted anymore, since with full disc encryption and container encryption the encryption is bound to the storage and not to the data.
The data should not be decrypted when the file is moved. This is why we require to encrypt the files and keep them encrypted when moving the file to another locatoin.

Client Side Encryption

As mentioned in the beginning the files should be encrypted and decrypted on the client. This way only encrypted data is transferred via the network. The user can also move the files as in the previous requirement but most important the encryption gets independent from the storage location.
The administrator can access the file but can not read the data in the file. This way all backup mechanisms still work, but the data is persistently protected.

Groups

When working with data in a company users are usually working on projects with other colleages.
Thus several users need access to the encrypted data. The project leader or data owner might need to add other users to the group and grant them access to the encrypted data or withdraw this access again.

It is important to note, that usually not *the* administrator gives access to the data. Complying to the concept of duty of separation, the administrator may be responsible for providing the storage and taking care of the backup, but he might not be allowed, to read the data and probalby will not be allowed to decide who is allowed to read the data.

This leads us to the requirement for a bit more sophisticated key management.

Key Management

If files are encrypted with passwords then a password based key derivation function (PBKDF) is used to generate the encryption key. A badly implemented encryption would use this key to encrypt the file. This would result in the problem, that – if you change the password – the complete file needs to be decrypted with the old password and re-encrypted with the new password. This might be fine for one small file but totally fails with a complete directory, a harddisk or a huge storage.

When you look at encryption a multi-step encryption has proven to be sensible. Even in the case of a PGP encrypted Email, the email is for many reasons not encrypted with the public key of the recipient directly but with a symmetric data encryption key (DEK), which is unique to this email.
Only this DEK is encrypted with the public key of the recipient. This is called Key Encryption Key (KEK).

The other great thing when using a DEK and KEK is, that several users can have access to the same data with different passwords – or different KEKs. This way a user who has access to the data can also be allowed to grant access on the data to a new user. The software can access the DEK with the KEK of the old user and encrypt the DEK of the file with the KEK of the new user.

This way, each file has a list of KEK-encrypted DEKs attached to it. Thus an enterprise encryption software needs to allow adding users with their key encryption key to files.
Users need to have different roles like adding users to access groups or only being allowed to access the data.

(Of course you can not effectively avoid the user breach: The user who has been granted access to the data can go rogue and print the data, take a photograph or copy. If you want to tackle with this threat you need to think about implementing data leakage prevenion.)

So what the heck with the KEK?

You might use the latest and greatest symmetric unbreakable encryption algorithms for actually encrypting the data. But these are of no use, if the access to this encryption – usually the password – is week. An attacker would always target the KEK (a.k.a. Passwords) and not the DEK (The encryption itself).

Thus, another important requirement is not only to encrypt the data but also to protect the access to this encryption. A good way to do this is not to use a password based access but to use public key cryptography.
As mentioned with the PGP example, the KEK is the public key of the user. The DEK is encrypted with the public key.
The user has to provide his private key to decrypt the DEK to access the data.

Perfectly the private key is located on a smartcard, so that the private key can not (easily) be copied or stolen.
If the private key was initially created on the smartcard, you can in addition be sure that the private key was not stolen or copied.

Data Read Escalation

As we required earlier the administrator usually can not read the data and can not add users to the group of data users, who can read the encrypted data.
But in certain cases – when all users have lost their smartcard, forgotten their passwords, have quit the job – the company needs to be able to access the encrypted data without one of the originial users available.

In this case the encryption solution needs to provide a process with preferably 4 eyes principle to regain access.
4 eyes principle is important to increase the trust and allow full deniability for all participants.

Technicaly the key management can to this by adding a system-KEK or recovery-KEK to all files.

Hardware Security Modules

Besides using smartcards for the user’s KEKs, the support for hardware security modules can be a good idea. The HSM can be used to protect the system-KEK or recovery-KEK or to sign configuration data. Otherwise a user with the right to only read encrypted data could escalate his rights to “assign-new-users to the encryption group” by flipping some bytes in the database.

Reencryption

We already said, that reencrypting the data is a bad idea and should be avoided. Nevertheless it can be necessary. E.g. if the symmetric encryption algorithm used to encrypt the files is know to have weeknesses. This is especially important if you need to upgrade the encrpytion algorithm.
In a worst case scenario the system- or backup-key could be compromized, then this keys need to be changed.
The solution should provide the possibility to reencrypt the data.

Possible Solutions

There is a quite nice long list of commercial products, which cover those requirements. Some are better and more convenient in smartcard support, some in group management and some in automation.
It is always a good idea, to identify your own needs and evaluate the right solution.
Most of the tools are products of companies located in Germany and thus comply to the (still) stirct data protection laws.

Why is there no open source?

Nevertheless there is no open source tool, which is capable of covering the requirements and competing with the commercial tools available. This might be due to the scratch-your-own-itch concept of open source development. Individuals start open source projects, which will provide a solution to their own problem. A perfect example is the tool cryptomator. It does a great job in file encryption and covers a lot of requirements but totally lacks the key management and because of this will only work for a single user, but not for project groups in a company.
Another reason might be, that the customers for such an enterprise file encryption tool in 95% of the cases runs Windows on their clients and may thus be used to install and use closed source software – so why should the software vendor bother about an open source busines model?

With the growing pressure of undemocratic survailance requests even by the German government the threat through backdoors and unpublished zero days increases dramatically. In a sensitive area like data encryption, where data obviously is to be protected from preying eyes, open source solutions can help to regain the trust in such software.
So I urge all open source companies with data storage centric products to think about enhancing their portfolio with an open source project for a trustyworthy, modern, enterprise ready file encryption solution. In my opinion this is not only a gap in the market but would also be a great help for a mature and democratic society.

privacyIDEA Appliance, UCS, LDAP-Proxy, FrOSCon und it-sa

privacyIDEA Appliance

Our enterprise customers may now install and configure privacyIDEA as a privacyIDEA appliance, based on the Ubuntu 16.04 enterprise packages. This way customers get an additional flover in addition to the python package index, CentOS, RHEL, Debian and Ubuntu for running and maintaining privacyIDEA. The Appliance allows easy setup of MySQL Master-Master-Replication, RADIUS clients and Backup and Restore. It also helps to manage the Audit log.
You may read more about the privacyIDEA Appliance in our blog post or take a look at it in action in the youtube channel.

privacyIDEA 2.19.1 available on the Univention Corporate Server 4.2

The current enterprise version 2.19.1 of privacyIDEA is now available on the Univention Corporate Server 4.2. The last version on the Univention Corporate Server was 2.18.1. With version 2.19.1 privacyIDEA is also available on the new Release 4.2 of the Univention Corporate Server. Thus customers running privacyIDEA on UCS 4.1, may easily upgrade UCS to 4.2.
Read more about this in our blog.

privacyIDEA LDAP Proxy available

The privacyIDEA LDAP Proxy is now available as ready made product. The LDAP Proxy allows an easy integration of arbitrary native applications or web applications which only allow authentication via LDAP. This way no addition plugin is necessary. The privacyIDEA LDAP Proxy acts as broker between the application, the LDAP directory or Active Directory and privacyIDEA.
Read more about the privacyIDEA LDAP Proxy on our website.

Events

Pick your calendar and write down some dates for interesting upcoming events!
At the end of summer Friedrich Weber and Cornelius Kölbel will give a talk about the privacyIDEA LDAP Proxy at the FrOSCon conference. NetKnights is also exhibitor and sponsor of FrOSCon and you will be able to ask everything you ever wanted to know about privacyIDEA and especially two factor authentication with LDAP.
FrOSCon takes place on August 19th and 20th in St. Augustin at the University Bonn-Rhein-Sieg, Germany.
You may also take a look at Cornelius’ previous, enjoyable talks (German) “Alles meins!” and “Am Puls der Zeit” on Youtube.
In October 2017 NetKnights will be at the it-sa, the biggest German IT-Security fair in Nuremberg. NetKnights will also have a stand there. Read more about this in our blog post.

privacyIDEA 2.19.1 on Univention Corporate Server

The Enterprise Version 2.19.1 of privacyIDEA is now available on the Univention Corporate Server. With version 2.19.1 privacyIDEA is now available on the Univention Corporate Server 4.2. Customers can easily upgrade from UCS 4.1 with privacyIDEA 2.18.1 to UCS 4.2 with privaccyIDEA 2.19.1.

Besides the improvements in Univention Corporate Server 4.2 privacyIDEA 2.19.1 also comes with interesting improvements. These are the generic user cache, which can reduce the authentication time dramatically. Using policies the administrator can define which U2F devices may be registered and used by the users. A Token Janitor allows the administrator to find orphaned tokens and either disable or delete these. We already blogged about the complete new features in privacyIDEA 2.19.

Service Level Agreement and Subscription

privacyIDEA4UCS can be installed on the Univention Corporate Server quickly and easily via the Univention App Center. You can find further details on privacyIDEA4UCS on the product page and also get a test subscription. The normal service level agreement for privacyIDEA also entitles the customer to use privacyIDEA on the Univention Corporate Server.