,

privacyIDEA Enterprise Edition und Appliance

Als neue Leistungen der privacyIDEA Enterprise Edition bietet die NetKnights nun ein eigenes Enterprise-Repository mit stabilen Enterprise-Paketen an. Diese werden kurz auf das eigentliche Feature-Release als ein Bug-Release veröffentlicht. So wird bspw. nach dem allgemeinen Release 2.19 ein Enterprise Release 2.191. veröffentlicht.

Das Enterprise-Repository enthält lediglich die Version 2.19.1, nicht die allgemeine Version 2.19. Der Vorteil ist, dass ein Kunde sich nicht mehr überlegen muss, ob er ein Update installieren soll oder nicht. Er kann automatisch von 2.18.1 auf 2.19.1 aktualisieren und hat dabei die Gewissheit, auf eine noch stabilere Version zu aktualisieren.

Weiterhin ist in dem Enterprise-Repository die neue privacyIDEA Appliance enthalten, über die wir bereits berichteten.

Das Enterprise-Repository ist für Ubuntu 16.04LTS verfügbar.

Enterprise Repository einbinden

Erstellen Sie eine Datei /etc/apt/sources.list.d/privacyidea-enterprise.list mit dem folgenden Inhalt.

deb https://yourname:yourpassword@lancelot.netknights.it/apt/stable xenial main

Die NetKnights GmbH weist Ihnen als Kunde Ihre eigenen Zugangsdaten zu, die Sie entsprechend bei yourname und yourpassword angeben.

Die Software-Pakete sind signiert. Um die Signatur überprüfen zu können, laden Sie sich den public Key herunter:

wget https://lancelot.netknights.it/NetKnights-Release.asc

Überprüfen Sie den Fingerabduck (0940 4ABB EDB3 586D EDE4 AD22 00F7 0D62 AE25 0082) des Schlüssels

gpg --with-fingerprint NetKnights-Release.asc

Fügen Sie den Schlüssel nun zum Schlüsselbund hinzu:

apt-key add NetKnights-Release.asc

Nun können Sie die Paketlisten aktualisieren und die privacyIDEA Appliance installieren:

apt update
apt install pi-appliance

Durch Aufruf des Tools pi-appliance können Sie nun

das erste Admin-Passwort setzen, mit dem Sie sich am WebUI anmelden,

alle RADIUS Clients konfigurieren oder

bspw. eine MySQL Master-Master-Replikation herstellen.

Sichern Sie sich die Appliance!

 

,

Einfache Unternehmens-2FA für ownCloud X

Vor wenigen Tagen hat ownCloud seinen Marketplace gestartet. Dieser gestattet die einfache und schnelle Installation von ownCloud Apps in ownCloud. Die privacyIDEA ownCloud App der NetKnights GmbH war eine der ersten verfügbaren Apps im Marketplace. Mit der privacyIDEA ownCloud App kann der Zugang zu einer ownCloud Installation um eine zentral verwaltete Mehr-Faktor-Authentifizierung erweitert werden. Die Authentisierungsgeräte der Mitarbeiter werden dabei im privacyIDEA Authentication Server verwaltet.

Installation der privacyIDEA ownCloud App

In ownCloud X erreicht der Administrator den integrierten Marketplace über der obere linke Menü.

In den Kategorien kann er nach „Security“ filtern. Über den Vorteil einer zentralen 2FA-Verwaltung gegenüber der integrierten TOTP-App schrieb ich bereits im Security Insider.

Ein Klick auf den Titel der privacyIDEA ownCloud App bzw. „privacyIDEA Two Factor Authentication“ zeigt die Details der App im Marketplace.

Der Administrator installiert mit Klick auf den blauen Knopf „Install“ die App. Dies geht sehr schnell. Danach ist der blaue Knopf grau.

privacyIDEA ownCloud App konfigurieren

Nun muss die privacyIDEA ownCloud App noch konfiguriert werden.

Dazu geht der Administrator im rechten Menü auf Settings-> Additional  und kann nun im Bereich privacyIDEA 2FA angeben, wo der privacyIDEA Server zu finden ist. Dazu gibt er die URL des privacyIDEA Servers an.

Achtung: Eventuell ist beim ersten Test der Haken bei „SSL Zertifikat überprüfen“ zu entfernen. Natürlich sollte in einem produktiven Setup die SSL Zertifikate immer überprüft werden!

Dies ist nun schon alles, was der Administrator innerhalb von ownCloud tun muss.

Konfiguration in privacyIDEA

Wir gehen davon aus, dass Sie privacyIDEA entsprechend einer möglichen Installationsvariante bereits installiert haben. Im Folgenden binden wir die Benutzerverwaltung von ownCloud an privacyIDEA an, so dass der Administrator innerhalb von privacyIDEA allen Benutzern einen Token zuweisen kann.

Benutzerquelle definieren

Als erstes definiert der Administrator die ownCloud-Datenbank als Benutzerquelle. Dies macht er in Konfiguration->Benutzer.

Benutzer-Realm anlegen

Danach wird unter Konfiguration->Realm mit dieser Benutzerquelle ein Realm erzeugt. In unserem Beispiel heißt dieser „oc“.

Wenn der Administrator nun das Benutzer-Tab aufruft, sind die Benutzer aus ownCloud innerhalb von privacyIDEA sichtbar.

Token ausrollen

Nun kann der Administrator einen Benutzer auswählen, und diesem einen Token – bspw. einen TOTP/Smartphone-App – ausstellen. Alternativ können sich die Benutzer selber innerhalb von privacyIDEA anmelden und sich selber einen Token ausrollen.

privacyIDEA unterstützt viele unterschiedliche Tokentypen, so dass hier genau definiert werden kann, welchen Token jeweils ein Benutzer hat.

So kann der Administrator bzw. die IT-Abteilung an zentraler Stelle regeln, dass Benutzer für ownCloud einen zweiten Faktor verwenden müssen und welcher Faktor dies sein soll. Verloren gegangene Authentisierungs-Geräte sind ebenfalls kein Problem. privacyIDEA unterstützt viele verschiedene Möglichkeiten und Workflows, solche Szenarien abzubilden.

Anmeldung

Nun kann sich der Benutzer im ersten Schritt mit seinem ownCloud-Passwort und im zweiten Schritt mit dem von privacyIDEA verwalteten Authentisierungs-Gerät an ownCloud anmelden.

Für den produktiven Betrieb von privacyIDEA und der privacyIDEA ownCloud App benötigen Sie eine Subskriptions-Datei.

Viel Erfolg beim sicheren Anmelden!

, ,

Zwei-Faktor-Anmeldung überall mittels privacyIDEA LDAP-Proxy

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.

Integration

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 README.md.

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.

Fazit

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.

,

privacyIDEA Ausroll-Station für Yubikey und Nitrokey

In der neuen Integrationsanleitung wird gezeigt, wie Sie eine dedizierte Ausroll-Station erstellen. Diese hilft dabei schnell und einfach initialisierbare Token wie den Yubikey und den Nitrokey mit eigenem Schlüsselmaterial zu versehen.

,

Zwei-Faktor-Authentifizierung für ownCloud

In dieser Integrationsanleitung wird gezeigt, wie Sie mit der privacyIDEA App unternehmenstaugliche Zwei-Faktor-Authentifizierung für ownCloud einrichten können.

,

LinOTP nach privacyIDEA migrieren

So migrieren Sie LinOTP schnell nach privacyIDEA. Dabei bleiben all Ihre ausgerollten Token und die Benutzerzuordnungen erhalten.

,

NPS 2012 für Zwei-Faktor-Authentifizierung mit privacyIDEA

Es gibt einen neuen Integration-Guide, wie privacyIDEA mit dem Microsoft Network Protection Server (NPS) betrieben werden kann.

 

, ,

Migration einer proprietären OTP / Zwei-Faktor-Lösung

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.

policy-radius-passthru

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!

Migrieren!

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!

,

Zusätzliche Leistungen für privacyIDEA Support-Kunden: CentOS Repository

Wir bauen unsere Leistungen in den Supportstufen für privacyIDEA aus.

Leistungen für Support-Kunden

privacyIDEA-200pxAbhängig von der Support-Stufe beziehen Support-Kunden bereits interessant Leistungen, die privacyIDEA tauglich für den Unternehmenseinsatz machen. Die NetKnights GmbH garantiert die Funktionalität der Software, so dass ein Support-Kunde keine Bedenken wegen des Open Source „No-Warranty“-Disclaimers zu haben braucht. In laut den SLAs definierten Reaktionszeiten bearbeiten wir etwaige Probleme und lösen diese schnell und unkompliziert. Support-Kunden werden außerdem zeitnah über Bugs und Sicherheitsprobleme informiert. In den höheren Support-Stufen Gold und Platin sind zusätzlich weitere Leistungen wie Beratungstage, gezielte Update-Unterstützung oder Feature-Priorisierung enthalten.

Im Zuge des Ausbaus der Leistungen ist nun das Ziel, die Installation und das Update von privacyIDEA für Support-Kunden noch einfacher, zuverlässiger und damit robuster zu machen. Dazu bieten wir für Support-Kunden nun ein Repository for CentOS 7.

privacyIDEA CentOS 7 Repository

centos-logo-lightVor allem auch in den U.S.A. setzen viele Unternehmen CentOS oder Red Hat als Linux-Distribution ein. Daher bieten wir nun ein Repository für CentOS 7 (bzw. RHEL 7) an. Aus diesem Repository kann privacyIDEA schnell und einfach installiert und genauso leicht aktualisiert werden.

Support-Kunden erhalten hierzu Zugangsdaten zu diesem Repository, so dass sie während der Laufzeit des Support-Vertrags privacyIDEA einfach installieren und automatisch Updates beziehen können.

Konfiguration und Installation

Hierzu ist auf dem CentOS 7 System die Datei /etc/yum.repos.d/privacyidea.repo mit dem folgenden Inhalt anzulegen:

[privacyidea]
name=privacyidea
baseurl=https://user:password@lancelot.netknights.it/rpmrepo/centos/7/x86_64/
enabled=1
gpgcheck=0

Danach sind die folgenden Befehle auszuführen:

yum update
yum install privacyidea-server

privacyidea-server ist ein Meta-Paket, das den privacyIDEA Programm-Code, den Apache2 Webserver und eine MariaDB installiert und konfiguriert. Danach muss lediglich ein Administrator angelegt werden und das privacyIDEA System ist einsatzbereit.

Die üblichen Installations- und Konfigurationsanweisungen finden sich in der Online-Dokumentation.

Updates

Updates bezieht der Support-Kunde nun jeweils über den normalen Update-Mechanismus mittels yum.

Ihr Support-Vertrag

Möchten auch Sie von den erweiterten Leistungen Gebrauch machen? Schließen Sie noch heute Ihren Support-Vertrag ab und stellen Sie so sicher, dass Ihre Zugänge mit einem zweiten Faktor stark abgesichert sind und Sie immer auf dem neusten Softwarestand.

OTP Anmeldung an Windows mit dem privacyIDEA Credential Provider

Um die Anmeldung an einem Windows-Desktop besser abzusichern, kann auch dort ein zweiter Faktor eingesetzt werden.

In diesem Beispiel wird der privacyIDEA Credential Provider verwendet, um die Anmeldung an einem Windows 8 Desktop nur zuzulassen, wenn der Benutzer im Besitz einer Smartdisplayer OTP-Karte ist.

Domänen-Setup mit Univention Corporate Server

In diesem Video wird ein Setup mit einem Univention Corporate Server genutzt. Der privacyIDEA Credential Provider kann natürlich genauso in einer nativen Windows-Domäne verwendet werden. Die OTP-Karte wird im privacyIDEA, das ebenfalls auf dem Univention Corporate Server läuft, verwaltet. Genauso können dort auch beliebige andere Authentifizierungs-Devices wie bspw. Yubikeys oder Google Authenticator verwaltet werden und somit zur Anmeldung am Windows Desktop genutzt werden.