Gestern Abend ging die Webseite online. Dahinter steckt die Initiative „Starke Authentisierung – Jetzt“ bei der sich viele Experten unterschiedlicher Branchen zusammenfinden. Da sind Bankenverbände, IT-Verbände, IT-Sicherheitsunternehmen, eine Universität.

NetKnights engagiert sich

Kerngeschäft der NetKnights GmbH sind Dienstleistungen und Produkte rund um das Thema Zwei-Faktor-Authentifizierung. Mit der Opensource Produkt privacyIDEA bieten wir eine flexible und skalierbare Lösung für Behörden, Unternehme und Organisationen jeglicher Größe. Deswegen war es uns auch ein Anliegen, uns in der Initiative zu engagieren.

Auch die NetKnights GmbH ist dort aktiv. Ziel der Initiative ist es die Endbenutzer von Online-Dienste zu sensibilisieren, dass ein sicheres Anmeldeverfahren auch die persönlichen Daten sichert, die der Benutzer einem Online-Dienst anvertraut. Den Diensteanbietern soll gleichzeitig eine Übersicht gegeben werden, wie und mit welchen Lösungen sie eine nachhaltige Zwei-Faktor-Authentifizierung für ihre Kunden umsetzen können.

2FA etabliert sich

Inzwischen haben die meisten wahrscheinlich von Zwei-Faktor-Authentifzierung gehört und habe eine grobe Vorstellung davon. Es ist Zeit, dass aus dieser groben Vorstellung fundiertes Wissen, Überzeugung und echte Anwendungen entstehen.

Mehr zu in der aktuellen Pressemitteilung.

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.


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.


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.


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.

Um die Anmeldung an einer Applikation mit einem zweiten Faktor abzusichern gibt es verschiedene Ansätze, die wir mit privacyIDEA bisher auch verfolgt haben.

Zwei-Faktor-Authentifizierung mittels Standard-Protokolle und Plugins

Wenn die zu schützende Applikation Standard-Protokolle wie bspw. RADIUS oder SAML unterstützt, dann kann die Überprüfung des zweiten Faktors im RADIUS Server oder im SAML Identity Provider vorgenommen werden. An der Applikation sind somit keine Änderungen vorzunehmen. Mit privacyIDEA konnte dies bisher mit dem privacyIDEA FreeRADIUS Modul oder mit dem privacyIDEA SimpleSAMLphp Plugin gelöst werden.

Andere Applikationen bieten ein flexibles Authentifizierungs-Framework, so dass die Anmeldung an einer solchen Applikation durch die Entwicklung eines kleinen Plugins um einen zweiten Faktor erweitert werden kann. Hierzu gibt es eine breite Auswahl an Plugins für verbreitete Applikationen wie TYPO3, ownCloud, Nextcloud, WordPress, dokuwiki, django, OTRS, Apache, NGINX, PAM/OpenVPN oder die Anmeldung am Windows Desktop.

Doch manche Applikationen bieten keine RADIUS-Schnittstelle und auch kein einfaches Authentifizierungs-Framework. Manchmal ist auch einfach die Zeit zu knapp oder die Programmiersprache der Applikation zu unangenehm.

privacyIDEA LDAP-Proxy

Um in solchen Fällen ebenfalls auch diesen Applikationen die Sicherheit einer starken Authentifizierung gegen privacyIDEA zu ermöglichen, entwickeln wir den privacyIDEA LDAP-Proxy.

Der privacyIDEA LDAP-Proxy kommt dann zum Einsatz, wenn eine Applikation die Benutzer gegen einen LDAP-Server wie OpenLDAP oder Microsoft Active Directory authentifiziert. Der privacyIDEA LDAP-Proxy wird dabei zwischen die Applikation und den LDAP-Server gesetzt. Die Applikation wird derart umkonfiguriert, dass sie nicht mehr den originalen LDAP-Server sondern den LDAP-Proxy kontaktiert. der privacyIDEA LDAP-Proxy entscheidet dann, wie die Benutzer mit zwei Faktoren zu authentifizieren sind und welche Anfragen an den originalen LDAP-Server weitergeleitet werden.

Die Authentifizierung erfolgt für den Benutzer also völlig Transparent.

Der Vorteil für die IT-Abteilung liegt auf der Hand: Der originale LDAP-Server wird nicht angetastet und die Applikation erfährt lediglich eine Konfigurationsänderung im Rahmen der vorgesehen und vom Hersteller unter Support stehenden Rahmenbedingungen.

Gegenüber Zwei-Faktor-Lösungen, die rein auf OpenLDAP basieren, hat die Variante des LDAP-Proxies zusätzlich zur Unveränderbarkeit des originalen LDAP-Servers weiterhin den Vorteil, dass sie eben nicht nur mit OpenLDAP sondern auch mit jedem anderem LDAP-Dienst wie dem weit verbreiteten Microsoft Active Directory oder Samba4 funktioniert.

Das Beispiel-Szenario

In diesem beispielhaften Szenario betrachten wir die Anmeldung an SuiteCRM. SuiteCRM ist eine Open Source Customer Relation Managemet Lösung, für die es kein Zwei-Faktor-Plugin gibt. Allerdings kann SuiteCRM die Benutzer gegen LDAP authentifizieren. Daher soll in diesem Fall der privacyIDEA LDAP-Proxy zum Einsatz kommen.

Wir könnten genauso jede beliebige andere Applikation betrachten, die Benutzer aus einem LDAP-Verzeichnis verwendet. Wir installieren SuiteCRM auf einem Univention Corporate Server, da die Installation und Konfiguration sich hier als extrem einfach erweist. Nach der Installation ist SuiteCRM sofort so konfiguriert, dass Benutzer, die im Univention Corporate Server Domain Controller angelegt sind, sich an SuiteCRM mit ihrem LDAP-Passwort anmelden können. Statt eines UCS Domain Controllers hätten wir genauso eine native OpenLDAP-Instanz oder ein Microsoft Active Directory verwenden könnten.

Auch der privacyIDEA Authentication Server kann wahlweise auf einer beliebigen Linux-Distribution oder auf einem Univention Corporate Server installiert werden. privacyIDEA ist ebenfalls im Univention App Center enthalten, so dass auch privacyIDEA automatich gegen den LDAP-Server konfiguriert wird und lediglich den Benutzern die zweiten Faktoren in Form von Yubikeys, OTP-Token oder Smartphone-Apps zugewiesen werden müssen.

SuiteCRM wird schließlich derart umkonfiguriert, dass nicht mehr der UCS LDAP-Server sondern der LDAP-Proxy gefragt wird.

Bei Bedarf können mehrere der beteiligten Komponenten auf einem System installiert werden.


LDAP-Proxy installieren und konfigurieren

Der LDAP-Proxy ist in einer Beta-Version zur Zeit über Github erhältlich. Durch die Implementierung auf Basis von Python und Twisted ergibt sich eine Vielzahl von Möglichkeiten für das Deployment. Die nötigen Einstellungen werden in einer zentralen Konfigurationsdatei vorgenommen. Unter anderem muss dem LDAP-Proxy hier mitgeteilt werden, wo der UCS LDAP-Server und die privacyIDEA-Instanz zu finden sind. Außerdem wird ein Service Account auf dem UCS LDAP-Server benötigt, dessen Zugangsdaten in der Konfigurationsdatei hinterlegt werden.

Für genauere Informationen konsultieren Sie die Datei

Der LDAP-Proxy wird wie folgt gestartet

twistd -n ldap-proxy -c config.ini

Im produktiven Betrieb würden Sie den LDAP-Proxy später automatisch als Service über systemd starten. Die Konfigurationsdatei config.ini kann entsprechend an beliebiger Stelle liegen. Die Datei example-proxy.ini enthält entsprechende ausführliche Kommentare, so dass schnell ersichtlich sein sollte, welche Konfigurationen vorzunehmen sind.

Die Konfigurationsdatei

Entscheidend sind die folgenden Konfigurationen:

In der Sektion privacyidea geben Sie mit dem Parameter instance an, wo der LDAP-Proxy den privacyIDEA Server erreicht.

In der Sektion ldap-backend geben Sie an, wo der originale LDAP-Server steht und ob die Verbindung über LDAP oder LDAPS oder LDAP+STARTTLS durchgeführt wird.

Auf welchem Port der LDAP-Proxy selber lauscht können Sie in der Sektion ldap-proxy mit dem Parameter endpoint angeben.

Schließlich müssen Sie noch definieren, welches LDAP-Attribut als Loginname verwendet wird. Dies geschieht im Parameter attribute in der Sektion user-mapping.

Der Service-Account ermöglicht allgemeines Suchen

Für einfache Applikationen, die lediglich den Benutzer mittels eines Binds überprüfen, reicht dies bereits aus. SuiteCRM nutzt allerdings für allgemeine Suchanfragen zusätzlich einen Service-Account. Dieser muss in der Sektion ldap-proxy bei passthrough-binds und in der Sektion service-account eingetragen werden.

SuiteCRM konfigurieren

In SuiteCRM muss der Administrator lediglich den zu kontaktierenden LDAP-Server ändern. Dazu geht er ins Administrations-Menü, das man oben rechts erreicht.

Dort wählt er den Punkt „Passwordmanagement“.

Dort erreicht man schließlich die Konfigurationsmöglichkeiten für den LDAP-Server. Der dort eingetragene LDAP-Server muss nun auf den FQDN bzw. IP des LDAP-Proxies abgeändert werden.


Der Benutzer im SuiteCRM wird nun über den LDAP-Proxy in Zukunft gegen privacyIDEA authentifiziert. Das komplette Passwort-Feld bei der Anmeldung an SuiteCRM wird an privacyIDEA gesendet. Wie ansonsten auch muss der Benutzer also sein statisches Passwort und einen OTP-Wert eingeben.

Die konkrete Art des verwendeten zweiten Faktors kann über privacyIDEA individuell für jeden Benutzer geregelt werden. Denkbar sind wie bereits erwähnt Yubikey, OTP-Token und OTP-Karten, Smartphone-Apps wie Google Authenticator aber auch der Versand eines Einmalpasswortes per SMS oder Email.

Der LDAP-Proxy wird weiter ausgebaut und wir freuen uns über jegliches Feedback. Wollen Sie auf dem laufenden bleiben, so beobachten Sie das Github Repository oder abonnieren Sie unseren Newsletter.

Neue Version 2.14 von privacyIDEA bringt verbessertes Event-Handling und Performance-Optimierungen

Das Open Source Mehr-Faktor-Authentifizierungssystem privacyIDEA ist in der Version 2.14 verfügbar.

PGP verschlüsselte Seed Dateien

Die Seed-Dateien der OTP-Token können nun PGP-verschlüsselt importiert werden. Das erleichtert den sicheren Transport der Dateien zwischen Tokenlieferant und privacyIDEA-Installation. Wenn Sie Hardware-Token über die NetKnights GmbH beziehen, so wird der Workflow in Zukunft wesentlich einfacher. Sie erstellen einmalig für Ihre privacyIDEA-Installation ein PGP-Schlüsselpaar und übergeben uns den Public Key. Die verschlüsselte Datei kann nun importiert werden, ohne vorher entschlüsselt werden zu müssen.

Event-Handler für Benutzer und weitere Funktionalitäten

Außerdem wurde das Event-Handler-Framework erweitert. So können nun nicht nur Administratoren sondern auch Benutzer benachrichtigt werden. Bei welchen Aktionen und auf welche Art und Weise die Benachrichtigung erfolgt, kann der Systemadministrator fein granuliert definieren. Das Event-Handler-Framework gestattet nun außerdem, den Benutzer im Falle eines gesperrten Tokens zu benachrichtigen. Normalerweise bekommt
ein Benutzer nichts davon mit, wenn ein Angreifer versucht, seinen Account zu kapern und dabei der Token aufgrund vieler falscher Anmeldeversuche gesperrt wird. Ab Version 2.14 wird der Benutzer automatisch vom System darüber informiert und der Benutzer kann entsprechend reagieren, bevor er sich das nächste Mal anmelden muss.

Bessere Performance für große Benutzerzahlen oder langsame Netzwerke

Weiterhin wurde die Performance bei der Auflösung von Benutzern im LDAP-Verzeichnis signifikant verbessert. Auch die Anmeldegeschwindigkeit
bei komplexen Benutzersituationen wurde erhöht. Ein komplettes Changelog findet sich auf Github.

Das privacyIDEA Update steht zum Download über Github, den Python Package Index oder das Ubuntu Repository bereit. Das Update für privacyIDEA auf dem Univention Corporate Server wird in wenigen Tagen folgen.

Beratung und Support durch die NetKnights GmbH

Die NetKnights GmbH bietet Beratung für Zwei-Faktor-Authentifizierung und Support für privacyIDEA an.

Event Handler und zeitbasierte Richtlinien erhöhen die administrative Sicherheit

Mit Hilfe des Event Handler Frameworks lassen sich innerhalb des Zwei-Faktor-Authentifizierungs-Systems privacyIDEA nun ganz neue Abläufe abbilden. Der Administrator kann an beliebige Ereignisse wie das Ausrollen eines Tokens, das Löschen eines Tokens, das Anlegen eines Benutzers oder das Ändern der Token-PIN eine völlig neue Aktion anknüpfen. Das Ereignis selber wird dabei nicht verändert.

So können im ersten Schritt Benutzerbenachrichtigungen mit den entsprechenden Ereignissen verbunden werden. Wird für einen Benutzer vom Administrator oder dem Helpdesk ein neuer Token ausgerollt, so wird der Benutzer per Email darüber informiert. Dies hilft gerade bei sensiblen Benutzerkonten das Vertrauen zu erhöhen und verhindert, dass ein Support-Mitarbeiter unkontrolliert die Identität eines beliebigen Benutzers annimmt.


Nitrokey HSM

Zusätzlich wurden in der Version 2.12 die bestehenden Richtlinien derart erweitert, dass sie nun auch zeitabhängig definiert werden können. Hierdurch lassen sich bspw. zeitabhängige Login-Bedingungen definieren. Aber so kann bspw. auch die Administration von sensiblen Accounts nicht nur auf bestimmte Orte (Client-IP) sondern auch auf bestimmte Zeiträume beschränkt werden.

Bessere Zertifikatsverwaltung und HSM-Unterstützung

privacyIDEA hat sich schon lange vom reinen OTP-System weiterentwickelt, hin zu einem System zur Verwaltung von Authentifizierungs- und Identitäts-Informationen. In der Version 2.12 wurde die Verwaltung  und das Ausstellen von Benutzerzertifikaten verbessert. RSA-Schlüsselpaare können nun nicht nur im Browser sondern auch von privacyIDEA erzeugt werden. Der Benutzer oder Administrator kann dann die PKCS12-Dateien herunterladen. Dies ist in bestimmten Szenarien wie bspw. VPN-Clients, die ein lokales Clientzertifikate mittels PKCS12/PFX importieren müssen, interessant.

privacyIDEA legt jeher alle sensiblen Informationen verschlüsselt in der Datenbank ab. Die Verschlüsselung kann nun auch durch ein HSM wie dem Nitrokey HSM durchgeführt werden. Der private Schlüssel, der zum Entschlüsseln der sensiblen Daten verwendet wird, verlässt dabei die Hardware nicht.

Über privacyIDEA

privacyIDEA ist ein Open Source Projekt zur Zwei-Faktor-Authentifizierung für das die NetKnights GmbH Service Level Agreements für Unternehmen anbietet. Mit der Version 2.12 wurde privacyIDEA erneut um interessante Funktionen erweitert, die die Nutzung im Unternehmensumfeld ausgesprochen attraktiv machen.

Alle Änderungen


  • Event Handler Framework.
  • Der lokale CA Konnektor kann Zertifikate für Benutzer erzeugen. Die Zertifikate können als PKCS12 heruntergeladen werden.
  • Benutzer in LDAP Verzeichnissen können aus privacyIDEA heraus angelegt und bearbeitet werden.
  • Untersützung für Hardware-Sicherheits-Module.
  • Zeitabhängige Richtlinien.


  • UI: Richtlinie für den Enrollment-Wizard hinzugefügt.
  • UI: Auswahlbox für den Realm beim Login.
  • TOTP QR Code verbessert.
  • Enrollment-Wizard dokumentiert.
  • pi-manage backup Skript unterstützt nun pymysql.
  • X-Forwarded-For HTTP header wird als Client IP verwendet.
  • Meta-Paket privacyidea-mysql erlaubt flexiblere Installation.


  • Adduser beachtet nun die Resolver-Einstellung in Richtlinien #403.
  • Dokumentation zum SPASS token #399.
  • Enrollment Menü wird nicht angezeigt, wenn Benutzer keine Token ausrollen dürfen #398.
  • Fehler getSerial für TOTP Token behoben #393.
  • Verhalten der System-Konfiguration Checkboxen korrigiert #378.
  • Manage Tokenrealms: Ein Realm kann nun von einem Token entfernt werden #363.
  • Bessere Datumsanzeige in Emails #352.
  • Versandt von Test-Emails verbessert #350.
  • Authentisierung mit einem aktiven Token ist nun möglich, wenn der Benutzer einen deaktivierten Token hat #339.

Leichte Migration eines bestehenden OTP-Systems zu privacyIDEA

Oftmals entscheiden sich Kunden, ihr bestehendes, proprietäre OTP-System zur Zwei-Faktor-Authentifizierung abzulösen. Dies hat verschiedene Gründe. Das bestehende System ist zu alt und es gibt keine Updates mehr. Gleichzeitig wird es zu unflexibel. Die für das System verfügbaren Token erfüllen nicht mehr die Anforderungen der heutigen Zeit. Unternehmen wachsen zusammen und jedes Unternehmen bringt seine eigene, proprietäre Lösung mit. Manchmal ist das bestehende System auch einfach zu teuer oder im Zuge der Vertrauens- und Überwachungsthematik möchte man lieber ein Open Source System einsetzen.

Dies sind Gründe, wieso sich Kunden für die Nutzung von privacyIDEA entscheiden.

privacyIDEA bietet schon heute verschiedene Möglichkeiten — bspw. mit den RADIUS Token, eine solche Migration sanft durchzuführen. Doch mit der Version 2.11 wird eine solche Migration nochmal leichter. privacyIDEA 2.11 wird am 18. März veröffentlicht. Wenn Sie auf dem Laufenden bleiben wollen, abonnieren Sie bitte hier unseren Newsletter.

Zentral definierte RADIUS-Server

In privacyIDEA 2.11 ist es möglich, an zentraler Stelle mehrere RADIUS-Sever zu konfigurieren. Dies ist vergleichbar mit der letztens eingeführten Möglichkeit, zentral SMTP-Server zu konfigurieren.

Zentral definierte RADIUS-Server

Zentral definierte RADIUS-Server „RSA SecurID“.

Diese RADIUS-Server können für den RADIUS-Token oder auch in den Richtlinien verwendet werden.

Bisher (bis einschließlich privacyIDEA 2.10) muss für jeden Benutzer in privacyIDEA ein RADIUS-Token ausgestellt werden. Dieser RADIUS-Token verweist auf den alten RADIUS-Server des abzulösenden OTP-Systems. Solange der Benutzer also noch keinen OTP-Token innerhalb von privacyIDEA hat, kann er sich noch immer mit dem alten Token authentisieren.

Eine Richtlinie für alle Benutzer

Ab Version 2.11 können die zentral definierten RADIUS-Server in den privacyIDEA-Richtlinien verwendet werden.


Der zentral definierte RADIUS-Server „RSA SecurID“ wird in der passthru-Policy verwendet.

Hierzu wurde die bereits existierende passthru-Richtlinie erweitert. Die passthru-Richtlinie greift, wenn ein Benutzer innerhalb von privacyIDEA noch keinen Token zugewiesen bekommt. Die Authentifizierungsanfrage wird dann an das LDAP oder AD weitergereicht oder – nun neu in 2.11 – an einen konfigurierten RADIUS-Server.

Das bedeutet, dass in einem sanften Migrationsszenario von Ihrem alten OTP-System hin zu privacyIDEA nur noch eine einzige Richtlinie zu definieren ist, und Sie nach und nach allen Benutzern einen neuen Token innerhalb von privacyIDEA ausstellen können!


Das hier beschriebene Szenario funktioniert problemlos für alle Systeme, die einen RADIUS-Server bereitstellen. Darunter Systeme wie Kobil, RSA SecurID, SafeNet, Vasco (in alphabetischer Reihenfolge).

Sprechen Sie uns an!

Cornelius Kölbel wird am Donnerstag, 17.032016 um 14:45 auf der Cebit einen Vortrag zur sicheren und bequemen Zwei-Faktor-Authentifizierung mit Open Source halten. Dabei geht es um die Kombination von Zwei-Faktor-Authentifizierung und Single Sign-On, um somit das Leben für die Benutzer einfacher zu gestalten und dennoch die Sicherheit zu erhöhen. Kommen Sie in Halle 12, B81 zum Stacking IT Stage bei DatacenterDynamics.

Sicherheit und Benutzerfreundlichkeit mit Open Source

Die Bequemlichkeit von Single Sign-On kombiniert mit der Sicherheit eines zweiten Faktors

Keiner merkt sich gerne die Unmengen an Passwörtern, denen wir heute ausgeliefert sind. Passwort-Manager – offline und online – sollen hier helfen.

Doch kein Unternehmen lässt seine Mitarbeiter gerne Passwörter von Unternehmensaccounts online bei Drittanbietern speichern. Als Unternehmen brauchen Sie die Kontrolle über den Authentifzierungs-Prozess. Single Sign-On kann hier Abhilfe schaffen. Auf dem Unternehmensdesktop sind dazu Schlagworte wie Kerberos und Active Directory bekannt. Aber das Leben und die Arbeit ist schon längst online ins Web gewandert. Immer mehr Aufgaben werden auch beruflich bei Diensten wie denen von Google oder Salesforce erledigt. An dieser Stelle kommt das Web Single Sign-On Protokoll SAML (Security Assertion Markup Language) ins Spiel. Das Unternehmen kann die Hoheit über die Benutzer-Authentifizierung behalten und der Anwender muss sich nicht nochmals anmelden um einen solchen Dienst zu nutzen. Mit Hilfe eines zweiten Besitz-Faktors kann die Anmeldesicherheit entscheidend erhöht werden. Der Benutzer erhält nur noch Zugriff, wenn er sein einziges Passwort kennt und einen konkreten Besitz vorweisen kann. Damit sind die Angriffsszenarien für Cracker und Industriespione erheblich aufwändiger geworden und Ihre Unternehmensdaten bleiben dort, wo sie sein sollen. In Ihrem Unternehmen.

Dieser Vortrag zeigt, dass sich ein solches Szenario flexibel, investitionssicher und backdoor-frei auch und vor allem mit Open Source umsetzen lässt.

privacyIDEA 2.10 ist nun auch auf dem Univention Corporate Server verfügbar.

Enrollment-Wizard, Benutzer-Registrierung, Email-Handling

Ab gestern Abend stehen die neuen Funktionen Enrollment-Wizard, Benutzer-Registrierung und das verbesserte Management der SMTP-Server mit privacyIDEA 2.10 auch auf dem Univention Corporate Server zur Verfügung. privacyIDEA kann aus dem Univention App Center heraus leicht installiert und aktualisiert werden.


privacyIDEA Token Enrollment Wizard

Für Ihr individuelles Projekt im Rahmen Zwei-Faktor-Authentifizierung stehen wir Ihnen beratend in der Planung und Durchführung zur Seite. Sprechen Sie uns einfach an.

Veränderte Subscription auf dem Univention Corporate Server

Bisher erhielten Sie die Möglichkeit privacyIDEA mit bis zu 10 Benutzern auf dem Univention Corporate Server zu testen. Zwei-Faktor-Authentifizierung ist ein Thema das heute fast in aller Munde ist. Doch dadurch ist das Thema nicht einfacher geworden. Die Überlegungen, wie und wo sie eingesetzt werden soll, welche Authentisierungs-Devices verwendet werden und wie der Rollout an die Benutzer erfolgt stellen viele IT-Abteilungen vor bisher unbekannte Aufgaben.

Daher will die NetKnights GmbH Sie bei der Evaluierung von privacyIDEA auf dem Univention Corporate Server nicht im Regen stehen lassen. Um privacyIDEA zu evaluieren, können Sie sich im Subscription-Formular Ihre individuelle Evaluations-Subscription erstellen, so dass Sie privacyIDEA mit bis zu 20 Benutzern und bis zu 3 Monaten kostenfrei testen können. Gleichzeitig erhalten Sie eine halbe Stunde Standard-Support, so dass Sie sowohl die Software als auch den Support testen können.

Wir wollen, dass Sie ein zügiges, freudvolles und erfolgreiches Zwei-Faktor-Authentifizierungs-Projekt durchführen können!

Univention Corporate Server

privacyIDEA ist seit Anfang 2015 auf dem Univention Corporate Server verfügbar. Durch die einfache Installation von privacyIDEA auf Univention, die sicheren Updates und das zuverlässige Basisbetriebssystem UCS eignet sich diese Kombination hervorragend für den Unternehmenseinsatz.


Wenn Sie die Neuerungen in privacyIDEA 2.10 kennenlernen wollen, so sind Sie herzlich zum Webcast am Freitag, 26.02.2016 eingeladen.


Cornelius Kölbel wird am Montag, 14.03.2016 um 10 Uhr auf der Cebit einen Vortrag zu Zwei-Faktor-Authentifizierung mit Open Source halten. Kommen Sie in Halle 3, D35 (Open Source Forum) und erfahren Sie, wie Sie mit Open Source Ihre Zugänge besser absichern können.

Das Thema Zwei-Faktor-Authentifizierung scheint inzwischen bei allen angekommenzu sein. Doch worauf ist beim Einsatz einer Zwei-Faktor-Authentifizierungs-Lösung zu achten und wie sind die verschiedenen Technologien zu bewerten? In diesem Vortrag wird gezeigt, worauf es ankommt, um Daten, Code und Schlüsselmaterial unter der eigenen Kontrolle zu behalten.