Hallo, 16.30 Uhr, nur damit die Leute wissen, die sich das später auf YouTube angucken, quasi wie so. Hier manche so Dinge passieren, wie sie passieren. Also 16.30 Uhr, Frost naht sich dem Ende.

Wir wollen euch heute was zum Thema Zwei-Faktor-Authentifizierung erzählen für LDAP. Hab da drunter geschrieben, Privacy Idea für LDAP, Proxy. Das ist praktisch, das setzt sich zusammen aus zwei Begriffen. Privacy Idea und LDAP-Proxy.

Ich werde erst ein bisschen was zu Privacy Idea erzählen, dann wird der Friedrich was zum LDAP-Proxy erzählen. Mein Name ist Cornelius Köldl, das ist der Friedrich Weber. Wir kommen von der Firma NetNights, die ihr vielleicht auch schon irgendwo mal mit unserem Stand da im Eingangsbereich gesehen habt.

Ja, Zwei-Faktor-Authentifizierung für LDAP. Das ist ein bisschen technisch so, LDAP. Ich hätte es auch nennen können, Zwei-Faktor-Authentifizierung überall. Mit dem Untertitel, schau die neue, geile Software.

Und weil im Endeffekt geht es hier darum, heute irgendwo zu zeigen, wie ich sehr simpel Zwei-Faktor-Authentifizierung überall hoffentlich einsetzen kann. Ja, Zwei-Faktor-Authentifizierung. Zwei-Faktor-Authentifizierung ist ja glaube ich schon irgendwie so in aller Munde.

Das gehört irgendwie zum guten Ton. Heute würde wahrscheinlich Knigge die Zwei-Faktor-Authentifizierung mit aufnehmen, in den Kanon quasi dessen, wie man sich zu benehmen hat. Also wenn ich irgendwie eine Infrastruktur mache, Dienst anbiete, dann muss alles schön geordnet sein hier. Also Löffel für die Vorsuppe, irgendwie hier Wasserglas, Weinglas.

Zwei-Faktor-Authentifizierung gehört einfach dazu. Das muss man machen, das haben heute alle kapiert. Wer weiß nicht, was Zwei-Faktor-Authentifizierung ist? Gut, keine Meldung. Nichtsdestotrotz, Zwei-Faktor-Authentifizierung gehört also irgendwie zum guten Ton.

Und irgendwie angeblich macht es auch jeder schon so ein bisschen. Aber wenn wir da mal genau hinschauen, also wenn wir uns das genau anschauen, irgendwas ist da falsch. So, sieht irgendjemand, was da falsch ist? Wir denken, wir haben alles richtig gemacht, wir haben alles gelesen,

wir haben irgendwie hier diese Tischdecke gebügelt, irgendwie alles aufgetragen. Eine Sache ist falsch. Vielleicht noch mehr. Das ist nichts auf dem Teller, ja, das ist auch korrekt. Also hier, das Messer liegt falsch rum. Die Schneide vom Messer gehört natürlich nach innen. Und so ist es auch mit der Zwei-Faktor-Authentifizierung.

Man denkt da, boah, perfekt, hier quasi auf dem Papier alles erfüllt. Aber wenn man so genauer hinguckt, ist vielleicht nicht so alles Gold, was glänzt. Macht ihr schon Zwei-Faktor-Authentifizierung? Wer macht Zwei-Faktor-Authentifizierung irgendwo?

Okay, wer macht keine? Okay, die kleine Minderheit. Okay, aber ihr wisst, was Zwei-Faktor-Authentifizierung ist. Also im Prinzip setzt sich zusammen hier, ich weiß was, irgendwie ein Passwort. Und ein anderer Faktor wäre etwas, ich besitze etwas.

Nächster Faktor wäre, ich bin etwas. Also im Prinzip irgendwie eine Kombination aus diesen drei Aspekten. Jetzt frage ich mich aber, wie macht ihr Zwei-Faktor-Authentifizierung? Also was nutzt ihr denn zum Beispiel als, neben dem Passwort, als zweiten Faktor? Also, wer hat da sich gemeldet?

So ein Telefon, Google Authenticator? Wie bitte? Telefon, Token, was noch? Token, Hardware-Token, welchen? Also irgendwas, was die IT-Abteilung dir gegeben hat, alles klar.

Hardware-Token, Telefon, also wahrscheinlich hier so ein Hardware-Token, so was irgendwie. Ich habe hier ein paar zweite Faktoren mal mitgebracht hier. Kann man mal so ein bisschen angrappeln, bitte schön. Ja, Telefon ist auch verbreitet, Telefon.

Aber die Frage ist also, wodurch definiert sich also der Besitz? Das ist mein Telefon, klar habe ich irgendwann gekauft, habe vielleicht noch den Kaufvertrag, weiß ich nicht. Aber die Frage ist ja, es gibt also, wie wir schon gesehen haben, verschiedene Möglichkeiten. Also hier Token, sehr interessant.

Hier zum Beispiel Yubi-Keys, das Telefon, das ist ja so ein bisschen ins Abseits gerückt. Aber der Punkt ist, das Telefon, das ist im Prinzip vielleicht so ein bisschen so das Messer, was irgendwie nach Schneide rechts gerichtet liegt. Das Problem ist, die Zwei-Faktor-Authentifizierung, wenn ich sie vom Besitz her betrachte, funktioniert natürlich immer irgendwie über einen kryptographischen Aspekt.

Das heißt, auf diesem Gerät, ob das nun dieser Token ist oder auf meinem Telefon, liegt irgendwo kryptographisches Schlüsselmaterial. Und wie wir alle wissen, ist kryptographisches Schlüsselmaterial irgendwie so ein bisschen sensibel. Und gerade im Fall vom Telefon kann ich natürlich sagen,

mein Smartphone ist ja eigentlich nur irgendwie ein zu heiß gewaschener Computer. Und Computer wissen wir auch, es sind so ein bisschen problematisch. Und hier, da ist irgendwie Google Authenticator gefallen. Google Authenticator ist auch eine total praktische Sache, aber hat natürlich auch ein Problem.

Der Google Authenticator kam, nein andersrum, wann kam so ein Smartphone raus? Weiß jemand iPhone 1? Genau, 2007. Und was macht der Google Authenticator? Der macht einen TOTP-Algorithmus oder einen HOTP-Algorithmus, der in einem RFC spezifiziert ist.

Und weißt du vielleicht jemand, wann das RFC 4226 geschrieben wurde? Was quasi sagt, wie der Google Authenticator bitte rechnen soll? Also festgeschrieben wurde das RFC, das heißt der Draft ist schon ein bisschen älter, 2005.

Und wie wir das also merken, 2005 ist irgendwie kleiner als 2007. Das heißt also, dieses RFC kann eigentlich gar nicht für Smartphones bestimmt gewesen sein. Nichtsdestotrotz wird es also für Smartphones verwendet. Und das Problem, was wir da im Prinzip sehen, oder daraus ergibt sich halt auch das Problem, was wir da sehen,

nämlich Google hat sich da was ganz Bequemes ausgedacht, hat also gesagt, hey, wir zeigen diesen QR-Code an. Und diesen QR-Code kann ich scannen. Und wenn ich diesen QR-Code gescannt habe, super, dann ist mein Telefon ein Besitzfaktor.

So und wieso mache ich zwei Faktor-Authentifizierung? Mit einem Besitzfaktor als zweiten Faktor, weil ich als System halt genau feststellen möchte, ob dieser Benutzer tatsächlich diesen Besitz besitzt. Wenn ich jetzt aber quasi diesen QR-Code scanne, habe ich das Problem, dass in diesem QR-Code tatsächlich im Klartext der kryptographische Schlüssel drinsteht,

mit dem der später genutzt wird, um diesen zweiten Faktor zu repräsentieren. Das heißt, gerade wenn ich mich im Unternehmensumfeld bewege und zum Beispiel sage, ich habe so viele Benutzer, die sollen nicht alle zu mir kommen, die nerven nur.

Ich mache da irgendwie einen Self-Service. Die Benutzer sollen sich gefälligst ihren Google Authenticator selber ausrollen und den scannen. So und dann sitzt der Benutzer vor seinem Self-Service-Portal in seinem Arbeitsplatz, völlig ungestört,

nimmt sein, geht auf diese Self-Service-Portal-Seite, dann steht da dieser QR-Code. Dann zieht er sein Handy raus und scann diesen QR-Code, wo der Krypto-Schlüssel im Klartext drinsteht. Der IT-Leiter eines Kunden hat dann mal zu mir gesagt,

ja, wieso wollen wir eigentlich zwei Faktor-Authentizierung machen? Da sagte er, ey, die Benutzer, die sind total schrecklich, die tauschen immer die Passwörter untereinander aus. Wer kennt das? Benutzer tauschen Passwörter untereinander aus. Kennt man das? Kennt man. So. Und jetzt glaubt man also, ich kann dem Herr werden, indem ich sage, ich mache zwei Faktor-Authentizierung.

Na, Pustekuchen. Wenn die Benutzer in der Lage sind, Passwörter auszutauschen, dann sind sie auch in der Lage, ey, Meier, komm mal rüber, ich muss hier meinen zweiten Faktor ausholen, guck mal hier, scannen du auch mal. Das heißt, alle meine Arbeitskollegen, die diesen QR-Code scannen, haben eine 1 zu 1 Kopie meines Besitzfaktors.

Weil da im Prinzip das gleiche Kryptomaterial drin ist und ansonsten dieses Einmalpasswort nur noch auf Basis der Zeit berechnet wird. Die AMA-IT-Abteilung merkt niemals, dass die Leute im Prinzip diesen Besitzfaktor dupliziert haben.

Damit will ich nur sagen, es ist eben nicht alles Gold, was glänzt. Manchmal denke ich, oh, ich habe einen Haken gemacht bei zwei Faktoren. Aber so einfach ist die Sache eben nicht. Man muss sich irgendwo überlegen, okay, in welcher Form setze ich überhaupt meine zwei Faktor-Authentifizierung ein? Ist das ausreichend? Was bleiben für Restrisiken und so weiter?

Jetzt habe ich so einen zweiten Faktor ausgerollt. Was mache ich jetzt damit? Also was machten ihr damit? Was machten ihr mit eurem zweiten Faktor? Wo meldet ihr euch denn da an? Beim VPN. Okay. Und wo noch?

Keine Ahnung, vielleicht irgendeine Web-Applikation? Hat hier irgendjemand so eine XXX-Cloud, wo er sich anmeldet? Nein. Also ich halte fest, 70 Prozent des Auditoriums nutzen zwei Faktor-Authentifizierungen.

Und eine Person meldet sich am VPN damit an. Das ist interessant. Mit dem Google Authenticator?

Ja, aber dann wahrscheinlich mittels U2F. Das ist interessant. Aber das geht schon so ein bisschen in die richtige Richtung, weil

der arme Mann, der hat verschiedene Dienste, an denen er sich anmelden möchte. Das ist jetzt so ein bisschen, ja okay, das sind natürlich externe Dienste, da ist die Lage so ein bisschen anders. Aber wenn ich jetzt zum Beispiel hier das VPN nehme, melde ich mich am VPN an. Was mache ich aber, wenn irgendwie die IT-Abteilung oder die Geschäftsführung auf die Idee kommt,

VPN reicht nicht aus, die sollen sich noch am CRM anmelden oder wo auch immer. Ja, das Ergebnis ist, ich habe hier meinen VPN. War das ein, das war ein Token, gell? Ist vielleicht rein zufällig der richtige Token, keine Ahnung. Okay, es war ein Telefon. Aber ich habe im Zweifel noch irgendwie andere Applikationen, wo ich mich auch mit anmelden möchte.

WordPress, super Beispiel. Das ist, was den Plug-in-Reichtum betrifft, ist WordPress unschlagbar. Wenn ich so einen WordPress habe, habe ich eine Auswahl zwischen vielen Plug-ins, die mir ermöglichen, dass ich mich am WordPress mit einem zweiten Faktor anmelde.

Das Problem ist aber, ich kriege dann einen zweiten Faktor, der genau für WordPress funktioniert. Meine IT-Abteilung hat mir einen zweiten Faktor gegeben, der genau für das VPN funktioniert. Und jetzt setzt die IT-Abteilung vielleicht noch onCloud ein. Und prima, onCloud und Nextcloud können auch zwei Faktor. Und ja, genau, da hinten auch.

Und dann endet das genau quasi in diesem Bild. Der arme User hat nachher ein dickes Schlüsselbund oder ein Smartphone mit vielen Profilen für jede Applikation, wo er sich anmelden soll. Wer hat gerne viele Profile? Also ich nicht. Ja, dann weiß man nicht mehr, wo es langgeht.

Und deswegen macht man natürlich ein zentrales Management. Also wenn ich mich dann im Unternehmen befinde und sage, hey, ich habe irgendwann mit einem VPN angefangen, ich habe irgendwie noch ein Customer, so ein CRM-System, ich komme vielleicht auf die Idee,

ich will auch irgendwie meine SSR-Server mit einem zweiten Faktor ausstatten, weil auch Google Authenticator wieder super, die haben ein PAM-Modul, da kann ich mich ja auch direkt am Linux-Server anmelden. Das ist total cool, wenn ich ungefähr 128 Server habe, dann kann ich mir genau auf 128 Server das PAM-Modul installieren und mir 128 Profile in mein Google Authenticator einladen.

Da bin ich lange am scrollen. Und deswegen haben wir halt gedacht, okay, das ist nicht so schön. Und deswegen gibt es das zentrale Management-System Privacy Adzeer. Ich war ja letztes Jahr schon mal da. Hat jemand schon mal was von Privacy Adzeer gehört?

Okay, die verschwindende Minderheit. Die Idee ist, kurz zusammengefasst, ich habe prinzipiell meine Benutzer, die irgendwo schon in meinem Netzwerk rumschwirren, ich hole mir diese Benutzer

und kann diesen Benutzern beliebige Authentisierungs-Devices zuordnen. Und zwar ein Authentisierungs-Device, vielleicht aus manchen Gründen auch ein zweites, aber prinzipiell nicht 128. Dann habe ich an zentraler Stelle diese zweiten Faktoren von den Benutzern verwaltet und kann hingehen und viele verschiedene Applikationen gegen Privacy Adzeer konfigurieren.

Sodass, wenn sich der Benutzer zum Beispiel an seinem Desktop anmelden möchte, der PAM-Stack irgendwie sagt, hoppel, hoppel, hoppel, aha, ich muss jetzt die Credentials, die mir der User gegeben hat, gegen Privacy Adzeer validieren.

Privacy Adzeer weiß, wie das geht. Wenn ich irgendwie unterwegs bin und mich per Remote irgendwie einwählen möchte, per VPN, passiert genau das Gleiche mit genau dem gleichen Authentisierungs-Device. Das heißt, im Endeffekt habe ich ein Authentisierungs-Device, wo ich mich überall mit anmelden kann.

Trotzdem, ich habe ja schon gesagt, PAM-Stack, irgendwie muss ich dem PAM-Stack beibringen, wie es mit Privacy Adzeer kommuniziert. Genauso muss ich hier irgendwie dem, ach, greife vor, stopp.

Ich habe gehört, Privacy Adzeer, kann ich noch ein paar Sachen erzählen. Letztes Jahr war ich hier auf der FrostCon, haben wir sie zu Privacy Adzeer erzählt. Da gab es die Version 2.14, jetzt sind wir bei Version 2.19 angelangt. Und es gibt eine Reihe an Neuerungen.

Das Interessanteste ist wahrscheinlich hier sowas wie Event-Händler. Das heißt, da kann ich hingehen und auf beliebige Ereignisse, die im System passieren, reagieren mit neuen Aktionen. Das heißt, das einfachste Beispiel ist, das System kriegt eine Authentisierungs-Anfrage, die schlägt fehl.

Und weil die Authentisierungs-Anfrage fehlschlägt, benachrichtige ich den Benutzer, der sich versucht hat anzumelden. Weil vielleicht ist nicht der Benutzer, weil er sich anmelden wollte. Andere Möglichkeiten sind, wenn ein Ereignis eintritt, wie das zum Beispiel ein Administrator einen neuen Token ausrollt,

könnte ich auch den Benutzer benachrichtigen. Wieso rollt der Administrator für mich einen neuen Token aus? Keine Ahnung. Gleichzeitig könnte ich sagen, wenn der Administrator einen neuen Token ausrollt, will ich aber vielleicht andere Sachen machen. Oder sagen wir mal, der Helpdesk-Mitarbeiter rollt einen neuen Token aus.

Und ich möchte aber automatisch diesen Token deaktivieren. Vielleicht will ich einen Token auch deaktivieren, wenn sich ein Benutzer 25-mal falsch angemeldet hat. Also mit diesem Event-Handler-Framework kann ich halt all solche Szenarien abbilden. Und das hilft mir halt ausgesprochen dabei, Workflows zu automatisieren und erleichtert mir da so meine Arbeit.

Eine andere Sache, die dazugekommen ist, ist der Elderproxy.

Womit wir wieder beim Titel werden. Was macht der?

Hier können wir eigentlich wieder einen Schritt zurückgehen. Weil, wie sah es vorher aus in meinem Netzwerk? Zentral steht mein Privacy-ID und wartet darauf, dass es von Applikationen gefragt wird. Aber wie machen die Applikationen das? Die Applikationen reden prinzipiell mit Privacy-ID über eine Rest-API.

Und das heißt, okay, die können auch mit Radius oder Samel irgendwie kommunizieren, aber lassen wir das mal außen vor. Dann gibt es eine Rest-API. Die Applikation kann irgendwie so ein HTTP-Request irgendwo absenden, um Privacy-ID zu fragen,

ob das, was der User da gerade irgendwie eintippt und macht und tut, ob das valide ist, ob der Benutzer angemeldet werden darf. Das heißt aber, dummerweise können die Applikationen das nicht out of the box. Und deswegen brauche ich viele fleißige Entwickler, die mir für alle möglichen Applikationen Plugins schreiben.

Also wir haben ein On-Cloud-Plugin, ein Typo-3-Plugin, ein Doku-Wiki-Plugin. Ja, wir haben auch ein WordPress-Plugin. Wir haben ein Plugin für PAM. Also wir haben viele Plugins.

Aber wir haben eben nicht alle Plugins. Und neulich habe ich gehört, es gibt proprietäre Applikationen. Die sind auch noch closed source. Wie soll ich da für ein Plugin schreiben? No chance. Also die Frage ist, was machen wir? Und da kam eben die Idee mit dem LDAP-Proxy. Was macht der LDAP-Proxy?

Weil viele Applikationen sind trotzdem in der Lage, mit LDAP oder via LDAP zu kommunizieren, die Benutzer via LDAP zu authentifizieren. Das heißt, hier habe ich ein Protokoll, was eine weite Unterstützung hat. Ich müsste es bloß irgendwo schaffen, meine zwei-Faktor-Authentifizierung

irgendwie in dieses LDAP-Protokoll reinzubekommen. Und wie wir das gemacht haben, erzählt dann mal der Friedrich.

Ja, nach dem Cliffhanger mache ich dann mal weiter.

Um das nochmal hier kurz zu verdeutlichen. Bisher, wenn ich meine Applikationen habe, hier jetzt mal irgendwie so ganz beispielhaft, ich habe hier einen AD oder einen Open LDAP, in dem liegen alle meine Benutzer drin.

Und dann habe ich mir so einen Privacy ID aufgesetzt, was irgendwie mit diesem LDAP redet. Und dann habe ich hier zum Beispiel so einen Own Cloud und dann hier so einen CRM, Suite CRM zum Beispiel. Und dann habe ich hier meine User mit ihren Token. Was musste ich denn jetzt bisher machen, um das mit zwei-Faktor-Authentifizierung auszustatten?

Ich musste eben hier für jede Applikation mir entweder ein Plugin selber schreiben, mir das Plugin irgendwo herholen, das installieren, das einrichten und das auch warten. Und das ist natürlich irgendwie ziemlich aufwendig. Viel besser wäre es, wenn wir hier eben einfach so einen LDAP-Proxy benutzen.

Das würde eben bedeuten, unsere User liegen immer noch im LDAP bzw. im Active Directory. Das Privacy ID redet auch noch mit dem LDAP bzw. Active Directory. Aber eigentlich muss ich meine Apps überhaupt gar nicht anfassen. Die können nämlich meistens schon mit LDAP reden. Und dann konfigure ich die einfach so, dass sie nicht mehr hier mit dem Active Directory reden,

sondern mit meinem neuen LDAP-Proxy. Das heißt, ich schalte den einfach so dazwischen und habe dann sozusagen kostenlos, ohne dass die Apps eigentlich davon wissen, zwei-Faktor-Authentifizierung. Und jetzt sage ich euch, wie das funktioniert.

Zunächst vielleicht mal, wer weiß so gar nicht, was LDAP ist? Das ist gut. Ein bisschen was sage ich noch dazu. Also LDAP heißt hier Lightweight Directory Access Protocol. Und da geht es eben darum, auf so einen Verzeichnungsdienst zuzugreifen.

Also eine Protokollspezifikation, um auf solche Dienste zuzugreifen. Und dieser Verzeichnungsdienst speichert im Grunde irgendwelche Objekte. Das sind halt meistens User, Mitarbeiter oder irgendwelche Maschinen, die ich eben in meinem Netzwerk rumstehen habe. Und das Besondere ist, dass das eben so eine Baumstruktur ist.

Also ich habe oben irgendwie so einen Wurzelknoten und dann verästelt sich das immer weiter. Deswegen auch der Baum. Und wichtig ist, diese Objekte kann ich identifizieren durch so einen Distinguished Name. Also DN. Hier mal so ein Beispiel. Das wäre jetzt zum Beispiel ich.

Und da startet man eben hier von rechts. Das ist so der Wurzelknoten. Und dann kann man gucken, okay, dann geht es jetzt hier weiter zu dem Kindknoten CN gleich Users. Und dann irgendwie davon noch der Kindknoten UID ist Friedrich. Und so kann ich eben jedes Objekt in diesem Baum eindeutig identifizieren.

Und da kann man eine ganze Menge machen mit LDAP. Für uns sind so besonders zwei Operationen besonders wichtig. Zum einen ist das Bind. Was ist so ein LDAP Bind? Damit kann ich mich über LDAP authentifizieren oder authentisieren. Klassischerweise würde man denken, das funktioniert irgendwie mit Benutzernahme und Passwort.

Bei LDAP ist es eben so, ich gebe sozusagen keinen Benutzernamen an, sondern den Distinguished Name von dem User. Also der Benutzer, der sich authentisiert, liegt selber in diesem Verzeichnis drin. Und dann kann ich eben noch ein Passwort angeben. Das ist ein Bind. Den kann ein LDAP Client eben an einen LDAP Server schicken und dann ist er authentifiziert.

Und dann kann man eben danach zum Beispiel einen Search machen. Was ist ein Search? Da gebe ich eben einen Filter an, denn alle diese Objekte haben irgendwelche Attribute. Kann ich sagen, gib mir mal alle Objekte in meinem Baum, die irgendwie Personen beschreiben oder so.

Und dann kriege ich eben so eine Liste von Objekten, auf die dieser Filter passt, zurück. So, das reicht eigentlich auch schon für uns. Wie mache ich da jetzt zwei Faktor-Authentifizierung? Oder anders gefragt, was macht denn dieser LDAP Proxy jetzt eigentlich, von dem wir jetzt schon so oft gehört haben? Also eigentlich muss er gar nicht so viel machen.

Im Grunde muss er einfach nur Bind-Requests, die eben die Applikation schickt, entgegennehmen. Dann kriegt er eben sowas wie, ja, hier der User mit dem Distinguished Name, UID ist friedlich usw. usw. hat gerade versucht sich anzumelden und das Passwort ist hier irgendwie geheim 123456.

Und hier ist dann sozusagen geheim der statische Part, der Passwort-Part, sozusagen der Wissensfaktor. Und dieses 123456 ist dann dieses Einmal-Passwort, was von dem Token generiert wurde. Das schicken wir sozusagen einfach zusammen als Passwort rüber. Und was fängt der LDAP Proxy dann damit an?

Der muss jetzt tatsächlich erst mal rausfinden, okay, ich habe jetzt hier ein Distinguished Name von einem User, der versucht hat sich an meinem zum Beispiel OwnCloud anzumelden. Aber das Privacy-ID, das müsste eigentlich den Benutzernamen wissen, unter dem dieser User beim Privacy-ID bekannt ist. Das heißt, wir müssen den irgendwie rausfinden.

Und jetzt in dem Fall wäre das zum Beispiel Friedrich. Und was machen wir dann? Dann fragen wir beim Privacy-ID an. Und hier dieser Benutzername Friedrich und hier dieses Passwort bzw. PIN- und OTP-Teil geheim 123456. Stimmen die? Und dann sagt uns das Privacy-ID ja stimmt oder ne stimmt nicht.

Und dementsprechend beantwortet dann der LDAP Proxy diesen Bindrequest. Und eigentlich war es das auch schon. Einziges Problem, das noch bleibt, ist hier steht jetzt so unschuldig, findet Privacy-ID Benutzername raus. Wie machen wir das eigentlich? Also wenn wir so ein Distinguished Name von einem User reinkriegen, woher wissen wir, was der Benutzername von diesem User ist?

Und da gibt es mehrere Möglichkeiten. So eine ganz einfache Variante wäre, wir sagen einfach dieser Distinguished Name ist immer nach einem bestimmten Muster aufgebaut. Und wir ziehen einfach aus diesem Distinguished Name irgendwie den Benutzername raus. Wäre jetzt hier wahrscheinlich auch relativ einfach möglich. Wir gucken einfach da steht immer UID ist gleich irgendwas, wie jetzt zum Beispiel Friedrich.

Und dann ziehen wir da das Friedrich raus, das ist der Privacy-ID Benutzername, fertig. Ein bisschen netter ist es irgendwie, wenn wir den Benutzernamen tatsächlich aus dem LDAP bzw. der Active Directory rausziehen. Könnte zum Beispiel sein, dass wir sagen okay der User, der ist hier ein Objekt in meinem Baum und der hat irgendein Attribut.

Und das ist der Benutzername, unter dem dieser User beim Privacy-ID bekannt ist. Könnte man zum Beispiel dieses Some-Account-Name, Attribut nehmen, das heißt der LDAP-Proxy verbindet sich selber mit dem LDAP bzw. Active Directory, sucht nach diesem User mit dem Distinguished Name und dann liest er dieses Attribut,

merkt sich das und fragt dann eben beim Privacy-ID mit diesem Benutzernamen nach. Das hat natürlich einen Nebeneffekt, der LDAP-Proxy selbst muss auch mit dem Active Directory reden können. Das bedeutet der LDAP-Proxy selbst muss auch irgendeinen Account haben, damit er überhaupt mit dem LDAP reden darf.

Das macht die ganze Sache etwas komplizierter, deswegen haben wir jetzt mal so ein kleines Bild, das ist im Grunde auch nur das, was ich gerade gesagt habe. Also hier der User, der versucht sich bei irgendeiner App anzumelden. Diese App schickt so ein Bind-Request an den LDAP-Proxy, der schickt dann seinerseits ein Bind-Request an das Active Directory und danach ein Search um dieses User-Objekt zu finden, kriegt dann irgendwelche Ergebnisse

zurück oder halt auch keins, wenn es diesen User zum Beispiel gar nicht gibt. Findet dann irgendwie den Privacy-ID Benutzernamen raus, dann sendet er so ein HTTP-Request an das Privacy-ID, kriegt als Antwort zurück der OTP-Wert stimmt und die PIN auch oder eben nicht und dann beantwortet er den Bind-Request entsprechend.

Und das bedeutet halt, die App weiß im Grunde gar nichts davon, dass sie gerade zwei Fakta -Authentifizierung macht, denn die spricht einfach LDAP mit dem LDAP-Proxy, was dann natürlich sehr charmant ist. Das Problem ist, das klingt jetzt alles sehr einfach, so einfach ist es leider dann irgendwie doch nicht immer.

Es gibt zum Beispiel auch noch das Problem, dass die Apps selber eben auch noch irgendwie den, die müssen dann sozusagen genau das Gegenteil machen. Und die kriegen einen Benutzernamen rein, den der Benutzer eingibt, die müssen dann den DN rausfinden. Das heißt, die verbinden sich dann mit dem LDAP-Proxy mit einem eigenen Service-Account und versuchen über diesen Service-Account rauszufinden,

wie der Distinguished Name des Users ist, den sie dann gleich an den LDAP-Proxy weiter schicken. Und dafür, das Problem bei diesem Service-Account ist eben, den können wir natürlich nicht mit zwei Fakta-Authentifizierung absichern. Also das funktioniert hier irgendwie nicht so gut. Deswegen gibt es so Pass Through the Ends. Das bedeutet einfach, für bestimmte Distinguished Names machen wir keine zwei Fakta-Authentifizierung,

sondern schicken das einfach an das LDAP-Backend, an das Active Directory durch. Genau. Anderes Problem, was man durchaus haben kann, ist, dass Apps eben nicht nur ein Bind machen für jeden Benutzer, der sich anmeldet,

sondern dann auch noch irgendwelche Searches hinterher schicken, um zum Beispiel, weiß ich nicht, die E-Mail-Adresse des Benutzers zu lesen oder sowas. Da haben wir natürlich ein Problem, weil wir als LDAP-Proxy ja überhaupt gar nicht mit dem Active Directory gesprochen haben. Beziehungsweise wir haben keinen Bind im Kontext dieses Benutzers gemacht.

Das heißt, das Active Directory weiß irgendwie gar nicht, dass der Benutzer sich irgendwo angemeldet hat. Das bedeutet, man kann auch durchaus das so einstellen, dass man bei einer erfolgreichen Authentifizierung gegen das Privacy Adieu eben auch noch ein Bind an das Active Directory weiter schickt. Das aber nur am Rande. Ganz anderes Problem, einige Apps machen eben nicht nur ein Bind-Request pro Benutzer-Lock-In.

Das ist halt, wenn man nur Passwort-Authentifizierung macht, gar nicht so schlimm, ist zwar nicht schön, aber es ist im Grunde nicht weiter tragisch. Wenn wir halt zwei Faktor-Authentifizierungen machen, ist das nicht so schön, denn das bedeutet, dass der erste Bind-Request eben durchgeht.

Dann versucht die App noch mal dasselbe Passwort zu schicken. Das ist aber natürlich nicht mehr gültig, denn das ist ja ein Einmal-Passwort gewesen. Die Lösung, die wir dann da eingebaut haben, ist mehr so ein Workaround, ist eben so ein Bind-Cache. Das bedeutet, ich kann sagen, okay, für irgendwie drei Sekunden oder so ist jeder Bind-Request dann sozusagen noch gültig.

Also ich akzeptiere dann auch noch das alte Passwort für drei Sekunden oder so. Das war jetzt hier vor allem bei OnCloud hatten wir dieses Problem. Allerdings ist das Schöne, dass das auch schon ein bekanntes Problem war und dann haben wir eins, zwei Pull-Requests eben geschrieben.

Und in der neuen OnCloud 10er-Version schickt das Ganze jetzt tatsächlich auch nur noch ein Bind-Request pro Login. Was natürlich auch für die Performance nicht schlecht ist, denn ein Bind-Request geht halt schneller als drei Bind-Requests. Dann noch ein paar Worte zur Implementierung von diesem Elder Proxy. Der ist open source, AGP-LV3, ist auf GitHub, den könnt ihr euch also gerne anschauen.

Das Ganze basiert auf Python 2.7. Und wir benutzen dieses Twisted Framework mit einer LDAP Bibliothek, die auf diesem Twisted Framework aufbaut. Das hat so den Hintergedanken, dass dieses Twisted Framework eben so auf so asynchronen Netzwerk-Applikationen ausgerichtet ist.

Und wenn man mal überlegt, dann macht der Elder Proxy ja nicht so besonders viel eigentlich. Die meiste Zeit wartet der irgendwie, dass irgendjemand antwortet. Und währenddessen kann er ja durchaus auch andere Sachen machen. Und mit Twisted ist das eben relativ einfach möglich, da eben nicht allzu viel Zeit mit Warten zu verschwenden,

sondern dann eben gleich neue Requests abzuhandeln und so weiter. Genau, das Ganze ist auch gar nicht mal so viel Code. Das sind irgendwie nur so 500 Zeilen. Dann haben wir noch mal so 900 Zeintests dazu. Und auch das Privacy Idea, das jetzt an der Stelle auch, sind auch nicht mal so viele Zeilen Code.

Das sind auch nur hier so 20.000 Zeilen. Das heißt, wir achten schon darauf, dass das irgendwie verständlich ist, dass das irgendwie erweiterbar ist und dass man auch so ein bisschen Ahnung hat, was da überhaupt passiert. Genau, das hier ist ein QR-Code, der zu dem GitHub Repository führt, hoffentlich jedenfalls. Und dann würde ich auch schon wieder weitergeben hier an dich, wenn ich das hier hinkriege.

Gibt es denn irgendwelche Fragen soweit? Ja, richtig. Das wäre natürlich auch eine gute Sache. Ja, bitte. Das habe ich mich tatsächlich gerade heute auch noch gefragt. Ich glaube, das ist das alte Problem, dass irgendwelche... Ach so, Entschuldigung. Warum Python 2 und nicht Python 3, war die Frage.

Ich glaube, das Problem war einfach, dass wieder irgendwelche Abhängigkeiten, irgendeine Library, die wir benutzen, eben noch nicht ganz Python 3 safe ist. Also natürlich würde man lieber Python 3 benutzen. Aber gut, bei 500 Zeilen Code ist das auch nicht so der große Migrationsaufwand,

falls das dann irgendwann mal möglich ist. Für Privacy AD. Ob es RPM-Pakete für Privacy AD gibt, ist die Frage.

Ja, es gibt RPM-Pakete für RHEL 7 und CentOS, die wir aber, Drecksäcke wie wir sind, im Prinzip im Rahmen von Subscription anbieten. Aber prinzipiell ist jedem freigestellt,

der total viel Ahnung von Red Hat und SUSAT, RPM-Pakete zu bauen. Andere Fragen noch irgendwie zu dir.

Ob das Privacy AD irgendwie mit einer Software namens Lin OTP verwandt sei, so ist es. Privacy AD ist in der Tat ein Fork von Lin OTP. Privacy AD wurde 2014 geforkt und hat dann auch ein Rewrite erfahren,

also im Prinzip basiert jetzt auf einem anderen Python-Framework. Und ja, genau. Aber es stimmt, das kommt von daher. Viele Sachen sind noch kompatibel, wenn man irgendwann mal da die Frage aufgetaucht ist. Wenn ich also zum Beispiel von Lin OTP nach Privacy AD migrieren möchte,

ist das gar nicht so aufwendig, weil viele Datenbankobjekte noch sehr ähnlich sind. Andererseits haben wir in Privacy AD einfach sehr viele neue Funktionen und haben uns irgendwann entschieden, auch die Konfiguration auch irgendwo in der Datenbank abzubilden. Soll ich da weiter ins Detail gehen? Gut, okay.

Ja, sonst noch Fragen? Gut, vielleicht, ja.

Die Frage war, was man im Falle von einer Hochverfügbarkeit mit dem LDAP-Proxy macht,

ja, zwei installieren. Also da im Prinzip der LDAP-Proxy keinen Status hält, der hat kein State. Da kann ich im Prinzip zwei installieren auf zwei Maschinen und dann konfiguriere ich halt meine Client-Applikation, dass die halt irgendwie Client-Applikation seitlich halt zwei LDAP-Proxys fragt.

Genau, zwei LDAP-Proxys fragt. Also prinzipiell wird das so, wir haben da so ein Pilotprojekt, da wird das auch so implementiert. Also vielleicht noch mal kurz zusammengefasst.

Also eigentlich ist es eine coole Sache mit dem LDAP-Proxy. Und da fragt man sich, super, wieso mache ich dann nicht nur noch LDAP-Proxy? Der Witz ist, wenn ich einen Plugin für eine Applikation habe, bin ich einfach flexibler. Es gibt immer wieder Leute, die sagen, oh, ich möchte meinen zweiten Faktor in ein zusätzliches Feld eintragen.

Mit dem LDAP-Proxy modifiziere ich halt meine Applikation nicht, das heißt, ich habe nur Username und Passwortfeld und ich muss das Passwort beides reinschreiben. Oder wenn ich zum Beispiel sage, ich möchte Challenge-Response-Token verwenden. Wenn ich zum Beispiel sage, ich möchte eine SMS geschickt bekommen, obwohl ich schon letztes Jahr gesagt habe, dass man das nicht machen soll,

und es gibt ja unverbesserliche. Oder wenn ich zum Beispiel sage, hey, U2F-Token möchte ich verwenden. Das kriege ich halt mit dem LDAP-Proxy nicht abgebildet, weil für U2F muss ich tatsächlich die Applikation verändern, weil die irgendwie so ein bisschen JavaScript-Foo machen muss. Also im Prinzip muss man schauen und sich überlegen, was für Token will ich einsetzen,

weil, wie gesagt, manche Token kann ich mit dem LDAP-Proxy protokollbedingt nicht anbinden. Aber ich kann halt einen LDAP-Proxy hinsetzen und Applikationen anbinden, ohne die verändern zu müssen. Und das Ganze führt halt irgendwie dazu, hey, ich kann im Prinzip mein Netzwerk

viel schneller irgendwie auf zwei Faktor umstellen, weil ich nicht irgendwie komische Entwickler fragen muss, hey, schreibst du mir für meine Web-Applikation, da bin ich doch irgendwie ein mysteriöses Plugin. Wo geht die Reise hin?

Wir machen Open Source, und da sind wir auch so ein bisschen von der Philosophie beseelt. Release early and release often. Das heißt, wir sind auch wieder ganz fleißig an der Version 2.20 am Schrauben, die irgendwie für den 27. September terminiert ist.

Wir werden die Event-Händler weiter ausbauen, oder die sind zum großen Teil schon weiter ausgebaut. Wir haben so ein lustiges Feature implementiert, dass ich mich mit unterschiedlichen Anmeldennamen authentisieren kann. Also im Prinzip habe ich sonst so ein Mapping, wo ich sage,

hey, mein Login-Name ist halt mein Wing Cornelius, aber vielleicht möchte ich mich nicht immer mit diesem Namen anmelden, sondern vielleicht möchte ich mich auch mal mit meiner E-Mail-Adresse anmelden, oder mit meiner Telefonnummer, oder mit was auch immer. Und in der nächsten Version wird das halt möglich sein, dann kann ich das einfach konfigurieren, welche Attribute als Anmeldennamen akzeptiert werden,

da kann ich also eine Liste definieren. Dann haben wir sowas implementiert, eigentlich auch aus dieser Geschichte, mit diesem Elder Proxy heraus und diesen Unzulänglichkeiten, die wir gesehen haben, was verschiedene Applikationen, wir haben uns da so ein paar angeguckt, wie lustig die vielleicht irgendwie implementiert sind.

Dann haben wir gesagt, okay, es ist zwar völlig Gepumpt und hat mit Security nichts mehr zu tun, aber wir implementieren einen Authentisierungs-Cache. Das heißt, ich kann tatsächlich jetzt, ab der nächsten Version im Privacy-Ads sagen, hey, wenn sich ein Benutzer angemeldet hat, dann akzeptiere die Anmeldung einfach für die nächsten x Minuten, Stunden, Tage, wie auch immer.

Das wird natürlich das Konzept eines Einmal-Passworts ad absurdum, aber wer es will, kann es unter Warnhinweisen auch aktivieren.

Eine andere coole Sache, die wir da noch irgendwo in Planung haben, ist etwas, was wir Federations nennen, wo wir da auch so ein bisschen eine Weile drüber nachgedacht haben. Aber der Punkt ist, was eigentlich oft passiert, irgendwie, ich habe irgendwie ein größeres Unternehmen, Konzernen, wie auch immer,

und da sagt irgendwie die eine Abteilung, ach, ich muss mal schnell was machen, ich mache hier mal zwei Faktor. Und die implementiert also ein Privacy-Ads. So, und der Appetit kommt halt beim Essen, dann stellt plötzlich die andere Abteilung fest, ach, ihr macht da ja coole Sachen. Oder zum Beispiel sagt irgendwie der Mutterkonzern, ach, das ist ja interessant,

und da können wir doch so viel Geld sparen. Das heißt, aber jetzt steht hier irgendwie unten links, besteht da so ein Privacy-Ads-Server. Was mache ich jetzt? Blase ich den auf? Schmeiße ich den fort, weil ich oben wieder einen hinstelle? Nee, also die Idee ist, dass man im Prinzip sagt, ich kann Authentisierungsrequests delegieren.

Dann habe ich oben einen zentralen Privacy-Ads-Server, der dann im Prinzip auch noch ein Ruleset kriegt, so einer Motto, hier, wenn du den Benutzer nicht kennst, dann frag doch mal hier deine Tochter oder die Tochter. Und die Tochter könnte natürlich sagen, ja, ich kenne den Benutzer aber auch nicht, ich frage mal meine Tochter.

Also insofern kann man da über Generationen hinweg interessante Authentisierungskonzepte implementieren. Privacy-Ads ist open source. Wir sind ja auch auf einer Open-Source-Konferenz. Insofern lade ich herzlich ein, dass ihr vorbeischaut, mitmacht.

Wir haben da ganz klar irgendwie so eine Projektwebseite. Das eigentliche Leben findet irgendwie natürlich bei GitHub statt. Wir haben da so ein GitHub-Account, wo sich die ganzen Repositories drunter sammeln. Also im Prinzip, da gibt es den Server, dann gibt es da irgendwie die verschiedenen Authentisierungsmodule, sodass man da auch nicht irgendwie gleich komplett erschlagen wird.

Das Schöne ist, wir nutzen da auch existierende Services, weil wir halt auch sagen, hey, Transparenz ist auch noch super. Nach jedem Commit werden hier im Prinzip die 889 Tests durchlaufen und dann bei Travis CI.

Und da sieht man also auch gleich, wenn was bricht. Und wenn was bricht, kann man also den Entwickler fragen, hey, wieso hast du deine Tests nicht lokal durchgeführt? Code Coverage, wir waren mal besser, jetzt haben wir irgendwie nur noch 95% Code Coverage.

Gleichzeitig generieren wir die Dokumentation, die bei Read the Docs veröffentlicht ist und für alle, die sich nicht irgendwie entwicklungstechnisch einbringen wollen und den GitHub irgendwie so ein bisschen zu komisch ist oder so, oder die halt einfach keine Entwickler sind,

die sind herzlich eingeladen hier mal in dem Forum vorbei zu communityprivacyidea.org. Da kann man also auch gerne Sachen diskutieren. Wir haben da einfach mal todesmutig auch so Text definiert wie Konzeptdiskussionen und sowas.

Weil im Endeffekt, wir versuchen kreativ zu sein, aber wir müssen halt auch einfach auf die Anwender hören und die haben Anliegen und dann können wir halt irgendwo sehen, wie wir das irgendwo sinnvoll verwerten. Und damit haben wir eigentlich für heute auch schon alles erzählt, was wir so erzählen wollten.

Wir haben noch zwölf und halb Minuten Zeit, glaube ich. Also wenn noch irgendwelche Fragen bestehen. Ansonsten nutzt halt die Zeit, euch irgendwie noch einen Kaffee zu holen, bevor ihr nach Hause fahrt oder so. Habt ihr noch Fragen? Nein, zehn Minuten. Habt ihr noch Fragen? Ja.

Also die Frage war, oder die Frage war mit der Aussage quasi verbunden,

dass natürlich der Authentication-Cache total humbug ist. Und ob man das irgendwie so einstellen kann, dass er sich auf internen Netz anders verhält, als irgendwie vom externen Netz und so weiter und so fort. Natürlich. Also im Prinzip, wir haben hier, Privacyidea verhält sich entsprechend irgendwie recht komplexer Richtlinien.

Und im Endeffekt ist dieser Authentication-Cache auch eine Authentisierungsrichtlinie. Und jede Richtlinie, jede Authentisierungsrichtlinie kann ich verbinden mit Zeiten und mit Client-IPs.

Ich könnte zum Beispiel auch sagen, ne, den Authentication-Cache nutze ich bitte nur während der Arbeitszeiten und nicht außerhalb von den Arbeitszeiten. Oder halt von den und den Client-IPs. Genau, das kann ich machen. Ich kann auch das restriktieren auf bestimmte Benutzer, also dass nur merkwürdige Benutzer auch den Authentication-Cache kriegen.

Sonst noch weitere Fragen? Na wunderbar. Dann hoffe ich, das liegt daran, weil wir das irgendwie so verständlich rübergebracht haben. Falls es trotzdem noch, falls ihr es rausgeht und doch noch Fragen habt, also euch Fragen auffallen.

Wir sitzen da neben der runden Treppe, die da im ersten Stock führt, da vorne im Eingangsbereich. Und seid also auch noch herzlich willkommen für die restliche Zeit. Vielen Dank für eure Aufmerksamkeit und gute Frostkomm noch, ne Stunde und guten Heimweg. Danke.