Posts

, ,

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!

 

,

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.

,

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 2.19 – Performance, U2F and secure Smartphone Apps

Today we released privacyIDEA 2.19. Packages are available in the Launchpad-Repos for Ubuntu 14.04LTS and 16.04LTS. You can also install privacyIDEA on any Linux distribution using the python package index.

New Features in privacyIDEA

Authentication performance

privacyIDEA 2.19 is up to 72% faster!

In tests in the lab privacyIDEA 2.19 shows improved performance. Authentication requests are up to 72% faster than in the previous version. This is also due to a new generic user cache. This user cache stores the link between login name and user object in the local SQL database. Thus time consuming requests to the originial user store like LDAP servers or Active Directory get obsolete.

Filter U2F devices for the users

Using policies the administrator can define which type of U2F device the user is allowed to register. In further policies the administrator can also define, which U2F types the users can use to authenticate at certain applications. This way the usage of certain U2F devices can be denied in your company or certain devices from specific vendors can be required for login to sensitive systems.

Secure smartphone apps with privacyIDEA

The classical smartphone app enrollment comes with several problems, which privacyIDEA 2.19 can solve.

In a previous blog post we already pointed out the limitations of the usual smartphone enrollment with the Google Authenticator.  As a company or large organization you want to keep control over the enrollment processes of your users. Thus in version 2.19 of privacyIDEA a better rollout possibility was added. The smartphone and the privacyIDEA server do a mutual key generation. Both create a component, the secret key is generated from both components. This avoids easy copying of the QR-Codes.

Read more details in the privacyIDEA Blog.

More functions

Version 2.19 comes with further detail improvements like using the IP address or the browser user agent in the event handler framework. The date and timeformat was consolidated. Now the complete ISO date with timezone is saved to the database. This heavily eases working across timezones in international setups.

You may want to take a look at the complete Changelog.

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 test the system yourself? Register for a test instance!

You want to know more? Get in touch!

,

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.

 

,

Two-Factor-Authentication privacyIDEA 2.14 on Univention Corporate Server

privacyIDEA on Univention Corporate ServerLogo_UCS_certified

privacyIDEA 2.14 is available on the Univention Corporate Server via the AppCenter. With 2.14 the Event-Handler-Framework was improved. Administrators can now import encrypted seed files – protecting the secret seeds even better. Performance for slow LDAP and Active Directory connections was improved.

Subscription and Testlicense

You can get a subscription for privacyIDEA4UCS or request your test license.

 

,

privacyIDEA 2.14 released – Improved Event Handling and Encryption

Today privacyIDEA 2.14 was released. It supports the import of encrypted seed files. The event handler framework was improved in many ways.

Read more on the project website.