Sicherer Zugriff auf Unternehmensressourcen mit dem F5 Access Policy Manager
Heute möchte ich mit dem ersten technischen Beitrag in meinem Blog über den Access Policy Manager (APM) berichten und diesen mit seinen Vorzügen vorstellen. Zugegeben das ganze erstmal High-Level. Ans „Eingemachte“ machen wir uns dann später. Das APM-Modul gibt es als Standalone-Lösung auf der 1600'er Platform oder als so genanntes Edge-Gateway in der Kombination mit dem WAN-Optimisation Modul (WOM) und dem Webacceleration-Modul (WAM) und als klassisches Add-On Modul zum Local Traffic Manager (LTM). Eine oft gewählte Variante ist das Tripplet bestehend aus LTM/APM/ASM. ASM (Application Security Modul) ist die WebApplication Firewall (WAF) von F5. Wofür verwendet man nun aber das APM-Modul? APM kümmert sich um die Zugangskontrolle zu Ressourcen, wie Applikationen oder Netzbereiche. Hierbei ist es wichtig zu erwähnen, dass dies enorm flexibel in Abhängigkeit unterschiedlichster Kriterien erfolgen kann. Einige Beispiele sind hierbei sicher die Client-IP-Adresse, User-Zertifikat, Gruppenzugehörigkeit des Users, Antivirus-Status des sich verbindenden Rechners, Betriebssystem, Browser usw. . Aus diesen und weiteren Kriterien kann entschieden werden, auf welche Ressourcen ein Nutzer zugreifen darf. Also welche Applikationen ihm zur Verfügung stehen oder vielleicht auf welche URLs einer Applikation er unter diesen Bedingungen zugreifen darf oder eben nicht. Es kann aber auch bestimmt werden, welche Anwendungen dem Nutzer in seiner Citrix-VDI Umgebung angezeigt werden sollen. APM kann somit auch als ICA-Proxy arbeiten. Für Nutzer von Applikationen ist es wichtig, dass diese sich idealerweise nur einmal an einem System anmelden und anschliessend, mit Hilfe von Single-Sign-On Mechanismen des Authentifizierungsgateways, dies nicht mehr tun müssen, wenn Sie auf weitere Applikationen zugreifen. Auch darum kümmert sich das APM-Modul. Hier können die Authentisierungsmethoden auf der Clientseite auch durchaus anders sein, als auf der Serverseite. Methoden wie HTTP Basic, HTTP Form, HTTP Header, NTLM (v1,v2), Kerberos, OAM, Cookie, SAML, RSA Token, Zertifikat,... werden dabei unterstützt. Hilft APM nur bei HTTP-Anwendungen? Nein, natürlich nicht. Auch wenn man sagen kann, dass etwa 80% aller Netzwerk-Applikationen inzwischen auf HTTP(S)basieren, gibt es eine Menge weitere Protokolle, die ebenfalls Verwendung finden und APM seine Flexibilität dabei nutzen kann. Vorhin habe ich das Beispiel Citrix in VDI-Umgebungen (Xenapp/Desktop) genannt. Ebenso kann APM aber auch mit Microsoft RDP oder VMware View umgehen. Oder denken wir an ActiveSync oder Outlook Anywhere. Hier kann man eine Menge weitere Beispiele anfügen, aber gerne möchte ich noch ein weiteres Aufgabenfeld des Access Policy Managers ansprechen. Remote Access (SSL-VPN) Der Zugang zu Netzwerkressourcen kann ebenfalls konfiguiert werden. Hierbei wird ein Layer 3 Tunnel über ein SSL-VPN genutzt. Über diesen kann dann der Client auf das interne Netzwerk zugreifen. Selbstverständlich können auch hier wieder die unterschiedlichen Authentifizierungsmethoden zum Einsatz kommen. Natürlich auch mehrmals, um eine sogenannte Mehrfachauthentifierung zu realisieren. Ein einfaches Beispiel dazu: Der Client verbindet sich mit dem APM über den sogenannten Edge-Client. Das ist ein Stück Software zum Errichten des VPN Tunnels. Dieses Tool ist, nebenbei erwähnt, keine zwingende Vorraussetzung. Dazu aber in späteren Artikeln mehr. Nun, zunächst wird der Rechner des Users überprüft, ob eine aktive Firewall sowie ein aktueller Virenschutz vorhanden ist. Das ist in unserem Beispiel eine zwingende Voraussetzung, um überhaupt in unser Netzwerk zu dürfen. Aber natürlich ist dies nicht ausreichend, schliesslich wollen wir sicher gehen, dass der Nutzer entsprechende Credentials (Username, Passwort) hat, mit denen er sich gegenüber dem Active Directory (AD) authentifizieren muss. Sind diese valide, befragen wir das AD noch nach den Gruppenzugehörigkeiten, um eine entsprechende Authorisation durchzuführen. Ist der User in der Administratorengruppe, darf er nämlich auf ganz andere Netzwerkbereiche zugreifen als der „normale“ Nutzer. Anschliessend wird der Tunnel in das Firmennetz errichtet und der User kann von remote auf die Applikationen oder Netzwerke zugreifen. Dies ist natürlich nur ein einfaches Bespiel, gibt vielleicht aber schon eine Idee, wie flexibel das APM-Modul ist. Insbesondere, wenn man weiss, dass solche Regelwerke sehr schön graphisch über einen sogenannten Visual Policy Editor (VPE) erstellt werden können. Ich hoffe, ich konnte Ihnen einen ersten Überblick über den F5 Access Policy Manager (APM) Modul geben. In den nächsten Beiträgen möchte ich dann beginnen einige Konfigurationen zu besprechen.Single-Sign-On mit Kerberos Constrained Delegation, Teil 2 - Debugging
Hallo liebe Leser, in meinem letzten Beitrag bin ich auf die Kerberos Constrained Delegation Konfiguration eingegangen und hatte darin bereits versprochen, in diesem Beitrag das Debugging als Thema zu wählen. Dadurch, dass wir Abhängigkeiten mit anderen Komponenten haben, wird das Debuggen sicher nicht einfacher. Grundsätzlich sollte im Fehlerfall aber überprüft werden, ob die BIG-IP denn die Active Directory (AD) Infrastruktur erfolgreich erreichen kann und ob die Zeit der BIG-IP auch gleich der des Key Distribution Center (KDC) ist. Hier hilft auf dem Command Line Interface (CLI) der Befehl „ntpq –pn“ um zu überprüfen, ob die Zeit richtig ist: Die Namensauflösung ist enorm wichtig bei Kerberos, da es davon abhängig ist. Ebenso auch die Reverse-DNS Auflösung, da dies auch verwendet wird um den SPN (Service Principal Name) für jeden Server nach der Loadbalancing Entscheidung zu bestimmen. Sollten die Namen nicht richtig im DNS eingetragen sein, so kann man diese auch auf der BIG-IP statisch hinterlegen. Das ist aber nur ein Workaround und sollte eigentlich vermieden werden. Hier ein Beispiel um einen Eintrag zu setzen: # tmsh sys global-settings remote-host add { server1 { addr 1.1.1.1 hostname sven } } Natürlich ist das auch über die GUI möglich. Hier nun ein paar Beispiele, wie man die Namensauflösung überprüfen kann. Der Befehl „nslookup“ hilft einem dabei: [root@bigip1-ve:Active] config # nslookup www.example.com Server: 10.0.0.25 Address: 10.0.0.25#53 Name: www.example.com Address: 10.0.0.250 [root@bigip1-ve:Active] config # nslookup 10.0.0.250 Server: 10.0.0.25 Address: 10.0.0.25#53 250.0.0.10.in-addr.arpa name = www.example.com. [root@bigip1-ve:Active] config # nslookup w2008r2.example.com Server: 10.0.0.25 Address: 10.0.0.25#53 ** server can't find w2008r2.example.com: NXDOMAIN [root@bigip1-ve:Active] config # nslookup 10.0.0.26 Server: 10.0.0.25 Address: 10.0.0.25#53 26.0.0.10.in-addr.arpa name = win2008r2.example.com. Da Kerberos SSO sich für die KDC-Ermittlung auf DNS verlässt (sofern hier keine Adresse in der SSO Konfiguration eingetragen wurde), sollte der DNS-Server auch SRV-Records haben, die auf den KDC-Server für den Realm der Domain zeigen. Wir erinnern uns hier, dass ich dies in der Konfiguration des letzten Blogs eingetragen habe. Die Begründung war, dass es dann schneller geht: Schließlich erspart man sich genau diese Auflöse-Prozedur an der Stelle. [root@bigip1-ve:Active] config # nslookup -type=srv _kerberos._tcp.example.com Server: 10.0.0.25 Address: 10.0.0.25#53 _kerberos._tcp.example.com service = 0 100 88 win2008r2.example.com. [root@bigip1-ve:Active] config # nslookup -type=srv _kerberos._udp.example.com Server: 10.0.0.25 Address: 10.0.0.25#53 _kerberos._udp.example.com service = 0 100 88 win2008r2.example.com. Sind diese grundlegenden Konfigurationen nun überprüft und korrekt, aber es funktioniert noch nicht, hilft ein Blick in das APM Logfile. Vorher sollte aber der Debug-Level höher eingestellt werden. Dies bitte nur während des debuggens machen und anschließend wieder zurück stellen. Im Menü kann man unter System/Logs/Configuration/Options den Level einstellen. „Informational“ ist hier ein guter Start. „Debug“ kann man sicher auch verwenden, aber der Level ist schon extrem gesprächig und in der Regel reicht „Informational“ vollkommen. Schauen wir uns doch mal einen Ausschnitt eines Anmeldeprozesses an. Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:862 Initialized UCC:user1@EXAMPLE.COM@EXAMPLE.COM, lifetime:36000 kcc:0x8ac52f0 Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:867 UCCmap.size = 1, UCClist.size = 1 Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1058 S4U ======> - NO cached S4U2Proxy ticket for user: user1@EXAMPLE.COM server: HTTP/win 2008r2.example.com@EXAMPLE.COM - trying to fetch Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1072 S4U ======> - NO cached S4U2Self ticket for user: user1@EXAMPLE.COM - trying to fetch Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1082 S4U ======> - fetched S4U2Self ticket for user: user1@EXAMPLE.COM Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1104 S4U ======> trying to fetch S4U2Proxy ticket for user: user1@EXAMPLE.COM server: HTTP/win2008r2.example.com@EXAMPLE.COM Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1112 S4U ======> fetched S4U2Proxy ticket for user: user1@EXAMPLE.COM server: HTTP/win2008r2.example.com@EXAMPLE.COM Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1215 S4U ======> OK! Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:236 GSSAPI: Server: HTTP/win2008r2.example.com@EXAMPLE.COM, User: user1@EXAMPLE.COM Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:278 GSSAPI Init_sec_context returned code 0 Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:316 GSSAPI token of length 1451 bytes will be sent back Hilfreich ist es natürlich auch die Logfiles des IIS anzuschen. Hier kann man sich auch den Usernamen anzeigen lassen (C:\inetpub\logs\LogFiles\W3SVC1): #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken 2011-10-27 21:29:23 10.0.0.25 GET / - 80 EXAMPLE\user2 10.0.0.28 Mozilla/5.0+(compatible;+MSIE+9.0;+Windows+NT+6.1;+Trident/5.0) 200 0 0 15 Eine weitere Fehleranalysemöglichkeit ist natürlich sich anzuschauen, was denn für Daten über die Leitung gehen. Tcpdump und Wireshark sind hierbei unsere Freunde, # tcpdump –i internal –s0 –n–w /tmp/kerberos.pcap host 10.0.0.25 -i: das VLAN, die es zu belauschen gilt. Wählt man hier „0.0“ wird auf allen Schnittstellen gesniffert und man sieht die Pakete entsprechend oft. bzw. auch die Veränderungen, die ein Paket ggf. beim Durchlaufen der BIG-IP erfährt. -s0: bedeutet, dass das gesamte Paket aufgezeichnet werden soll -n: keine Namensauflösung -w /tmp/kerberos.pcap: Die Aufzeichnungen in die Datei /tmp/kerberos.cap speichern host 10.0.0.25: nur Pakete mit der Quell- oder Ziel-IP 10.0.0.25 aufzeichnen. Im Wireshark sieht eine Aufzeichnung dann etwa so aus: Wireshark versteht das Kerberos Protokoll und gibt somit gute Hinweise auf mögliche Probleme. Da APM die Kerberos Tickets cached, kann dies natürlich beim Testen zu unerwünschten Effekten führen. Das bedeutet es macht durchaus Sinn, während der Tests die Ticket Lifetime von standardmässig 600 Minuten runter zu setzen. Zudem kann man auch den Cache mit folgenden Befehl leeren: # bigstart restart websso Zum guten Schluß möchte ich dann noch ein paar Fehlermeldungen erläutern, die man im Log bei Problemen finden kann: Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - Cannot find KDC for requested realm (-1765328230) – Hier sollte man überprüfen ob DNS funktioniert und der DNS Server alle SRV/A/PTR Records der involvierten Realms hat. In der Datei /etc/krb5.conf auch bitte überprüfen, ob dns_lookup_kdc auf True gesetzt ist. Den Eintrag findet man in dem Bereich [libdefaults]. Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - Preauthentication failed (-1765328360) – Das Delegation Account Passwort ist falsch. Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - Client not found in Kerberos database (-1765328378) – Der Delegation Account existiert nicht im AD. Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - Clients credentials have been revoked (-1765328366) – Der Delegation Account ist im AD abgeschaltet. Kerberos: can't get TGT for host/apm.realm.com@realm.com - KDC reply did not match expectations (-1765328237) – Der Realm Name in der SSO Konfiguration muss groß geschrieben sein. Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - A service is not available that is required to process the request (-1765328355) – Die Verbindung mit dem KDC ist nicht möglich. Gründe können z.B. sein: Firewall, TGS Service auf dem KDC läuft nicht oder es ist der falsche KDC angegeben… Kerberos: can't get S4U2Self ticket for user a@REALM.COM - Client not found in Kerberos database (-1765328378) – Es gibt den User 'a' nicht in der Domain REALM.COM. Kerberos: can't get S4U2Self ticket for user qq@REALM.COM - Ticket/authenticator don't match (-1765328348) – Der Delegation Account hat die Form UPN/SPN und entspricht nicht der verwendeten REALM Domain. Achtung, wenn man hier mit Cross-Realms arbeitet! Kerberos: can't get S4U2Self ticket for user aa@realm.com - Realm not local to KDC (-1765328316) – Das KDC Feld muss leer gelassen werden in der SSO Konfiguration, wenn man mit Cross-Realm SSO arbeitet. Also wenn ein User einen Server in einem anderen Realm erreichen muss. Kerberos: can't get S4U2Proxy ticket for server HTTP/webserver.realm.com@REALM.COM - Requesting ticket can't get forwardable tickets (-1765328163) – Der Delegation Account ist nicht für Constrained Delegation und/oder Protocol Transition konfiguriert. Kerberos: can't get S4U2Proxy ticket for server HTTP/webserver.realm.com@REALM.COM - KDC can't fulfill requested option (-1765328371) – Der Delegation Account in REALM.COM hat keinen Service für webserver.real.com in seiner Konfiguration. Damit Sie Kerberos auf der Windows Seite debuggen können, hilft vielleicht dieser Artikel: • http://www.microsoft.com/downloads/details.aspx?FamilyID=7DFEB015-6043-47DB-8238-DC7AF89C93F1&displaylang=en So, ich hoffe natürlich, dass Sie keine Probleme bei der Konfiguration des SSO mit Constrained Delegation haben, aber falls doch, hilft Ihnen hoffentlich dieser Blog-Beitrag, um dem Problem schneller auf die Spur zukommen. Ihr F5-Blogger, Sven MüllerSingle-Sign-On mit Kerberos Constrained Delegation
Hallo liebe Leser, als heutiges Thema möchte ich über ein weiteres Single-Sign-On Verfahren sprechen: Kerberos Constrained Delegation. Was bedeutet das? Nun was hier passiert, ist dass der User sich am Access Policy Manager (APM) anmeldet. Hier können natürlich verschiedene Verfahren verwendet werden, wie z.B. Client-zertifikatsbasierte Anmeldung, oder Username/Passwort, die Kombination aus beiden oder eben auch andere Methoden. Entscheidend jedenfalls ist, dass sich der User authentifiziert und der Access Policy Manager (APM) anschließend ein Ticket für den User vom Key Distribution Center (KDC) erhält. Dieses Ticket wird dann dem User-Request hinzugefügt, damit am Backend-Server die entsprechende Authentifizierung mittels Kerberos erfolgreich verläuft. Anwendung findet dieses Verfahren häufig, wenn User aus dem „externen“ Netz zugreifen und somit keine Möglichkeit haben, selber ein Ticket vom KDC zu erhalten. Damit die BIG-IP aber überhaupt ein Ticket für den User bekommt, muss ein entsprechender Delegation-Account auf dem Domain Controller (DC) angelegt sein. Windows Administratoren fühlen sich hier vermutlich zu Hause. Für alle anderen ein paar Screenshots, die bei dieser Konfiguration hoffentlich helfen: Der „Advanced View“ im „Active Directory Users and Computers“ ermöglicht es den Attribute Editor unter User Properties auszuwählen. Nun legen wir einen User-Account an: User logon name = host/apm.example.com User logon name pre Windows 2000 = apm.example Der servicePrincipial Name muss dem DC hinzugefügt werden, bevor man in den Delegation Reiter des User wechselt. Dies kann mit dem Tool „setspn“ oder „adsiedit“ durchgeführt werden: run adsiedit.msc Nun den Usernamen auswählen, Properties wählen, und den Eintrag servicePrincipalName auswählen und „host/apm.example.com“ hinzufügen. Oder man fügt den Principial Name über den Attribute-Editor in den User Eigenschaften hinzu: Schließt man nun das Property Fenster und öffnet es wieder, hat man Zugriff auf den Delegation Tab. Hier kann man nun die Delegationsrechte für den User auf einen bestimmten Service freigeben. In meinem Beispiel ist es „WIN2008R2.example.com“. Übrigens das ist der Name meines Backend-Servers. Hat man mehrere müssen diese ebenfalls hinzugefügt werden. Unter den Account Options sollte man nun nochmal überprüfen, dass keine Account Optionen gesetzt sind. Der Delegation User brauch nur Mitglied der „Domain User“ zu sein. Um zu überprüfen, dass es keine Konflikte in der Kerberos Konfiguration gibt, kann man „setspn –x“ aufrufen: Wichtig bei dem Thema Kerberos ist, dass man alle DNS Einträge richtig gesetzt hat. Hier bitte alle Adressen und Namen die in dem Zusammenhang verwendet werden in beide Richtungen auflösen. Das kann einem so manches Debugging ersparen. Ganz wichtig auch: die Zeit! NTP sollte auf der BIG-IP auf jeden Fall eingestellt sein und synchron zum DC sein! DNS sollte natürlich auch funktionieren. Fassen wir kurz zusammen: Wir haben nun also einen User im DC konfiguriert, der für einen bestimmten Service im Namen eines anderen Nutzers ein Kerberos Ticket erstellen darf. Das ist noch nicht viel, kommen wir nun also zur Konfiguration der BIG-IP. Übrigens die Kerberos Konfiguration des IIS überlasse ich erstmal komplett dem Windows-Admin ;-). Als erstes richten wir auf der BIG-IP eine Kerberos SSO-Konfiguration ein: Unter „SSO Configurations“ findet man auch schon die passende Option. Was gibt es hier zu beachten? Ich habe bei mir den KDC eingetragen, das muss nicht sein. Ist in der Praxis aber etwas schneller, da der KDC nicht erst discovered werden muss. Namen können hier natürlich auch eingesetzt werden. Spannend ist immer der SPN Pattern. Per default, also wenn nichts eingetragen ist, wird hier HTTP/%s@REALM verwendet. Wobei das %s für den Namen des ausgewählten Backend-Server steht. Kurz zusammengefasst: Der Request trifft bei der BIG-IP ein, es wird die Authentifizierung durchgeführt und bevor der Request an den Backend-Server weitergereicht wird, muss dieser über das Balancing-Verfahren ausgewählt werden. Die IP-Adresse des Ziel-Servers wird über DNS Reverse-Lookup aufgelöst und der Name wird als SPN verwendet. Das bedeutet natürlich auch, dass für den Delegation-Account auch die entsprechenden Namen hinzugefügt werden müssen (s.o.). Alternativ kann man auch statt mit „Host-based“ mit „Domain Account-based“ Zugriff arbeiten und würde unter dem SPN Pattern einen Eintrag der Form „http/www.example.com“ vornehmen. Natürlich muss die Konfiguration der IIS-Server auch entsprechend angepasst werden. Als Credential Source müssen die Variablen genommen werden, in denen nachher auch die entsprechenden Informationen enthalten sind. Kommen wir zum nächsten Schritt. Dem Anlegen einer Access-Policy: Hier wählen wir das übliche Vorgehen. Unter Access Profiles klicken wir auf das „Plus-Zeichen“, geben der Policy einen Namen, fügen eine Sprache hinzu und vergessen nicht unter „SSO Configuration“ unser eben angelegtes Kerberos-SSO Objekt auszuwählen. Für den ersten Test sollte das reichen, Timeout-Werte etc. können später noch entsprechend angepasst werden, falls notwendig. Öffnen wir nun der „Visual Policy Editor“ (VPE). Eine User Authentifizierung gegen das AD habe ich in einem vorigen BLOG-Beitrag schon gezeigt, daher denke ich, lassen wir den User sich diesmal mittels Client Zertifikat ausweisen. Damit das auch funktioniert, müssen wir unserem Client-SSL-Profil noch eine Eigenschaft hinzufügen. Nämlich, dass ein Client-Zertifikat benötigt oder wie in diesem Screenshot zu sehen angefragt (request) wird. Geprüft wird es dann gegen die entsprechende CA. Die Frage lautet nun sicher, warum ich das vorhanden sein eines validen Client Zertifikat, nicht auf „require“ gesetzt habe. Nun, da spricht nichts gegen, aber ich will die Kontrolle dessen, in der Access-Policy abfangen und genau da hin kommen wir jetzt. In meiner Policy füge ich als erstes nun das „On-Demand-Cert-Auth“ Objekt ein. Hier muss das Client-Zertifikat nun auch vorhanden sein. Übrigens wird hier ein SSL-Rehandshake durchgeführt. Ist das Client-Zertifikat nun valide, ist der User autorisiert, auf den Backend-Server zuzugreifen. Vorher brauchen wir aber noch ein Kerberos-Ticket für ihn. Das bedeutet aus dem Zertifikat müssen wir den Usernamen extrahieren. Dieser kann in verschiedenen Feldern des Zertifikates stehen. Mit Hilfe des „Variable Assigns“ und ein wenig TCL können wir aber ziemlich flexibel auf alles eingehen. Fügen wir als erstes also das Objekt „Variable Assign“ in unseren „Successful“-Branch ein. Mit Hilfe des Variable Assign können wir neue Variablen erstellen, oder bestehende verändern. Wir erinnern uns an unsere Kerberos-SSO Konfiguration. Dort haben wir angegeben, dass der Username aus der Variablen session.logon.last.username genommen werden soll und die Domain aus session.logon.last.domain. Das bedeutet, wir müssen nun dafür sorgen, dass diese Variablen auch entsprechend gefüllt sind. Ein Blick in die bereits existierenden Session Variablen nach einem ersten Einloggen verrät, dass in meinem Fall der Username in der Variablen session.ssl.cert.x509extension gespeichert ist und er dort nun aus der recht langen Zeile extrahiert werden muss. Was es angenehm macht, mein Username ist in meiner Mail-Adresse enthalten und steht begrenzt von den Zeichen UPN<sven.mueller@example.com> Also kann ich die Mailadresse mit ein wenig Regular Expression schnell rausfiltern. Zur Erklärung: set f1 [mcget {session.ssl.cert.x509extension}] Speichert den Inhalt der Session Variablen in die temporäre Variable f1, mit der im Folgenden gearbeitet wird. regexp {(.*)UPN<(.*)>(.*)} $f1 matched sub1 sub2 sub3 Verwende Regular Expression und speichere alles was in der ersten runden Klammer matched, in die Variable sub1. Das sind alle Zeichen (.*) bis zur Zeichenfolge „UPN<“. Alles was dann an Zeichen kommt, bis zum Zeichen „>“ (und das ist die Mailadresse) speichere in die Variable sub2. Der Rest soll in die Variable sub3 gespeichert werden. Das Ganze soll angewendet werden, auf den Inhalt der Variablen f1, also session.ssl.cert.x509extension. return $sub2 Weist den Inhalt der Variablen sub2 (also die Mailadresse) und die Session Variable session.logon.custom.username zu. Soweit so gut. Nun muss der Username, also der Teil vor dem „@“ Zeichen noch extrahiert werden und der Domain Teil muss auch noch in eine Session-Variable geschrieben werden. Also fügen wir dem Variablen Assign noch zwei Einträge hinzu: session.logon.last.username expr {[lindex [split [mcget {session.logon.custom.username}] "@"] 0]} Hier zerlegen wir den Inhalt der Variablen session.logon.last.username in ein Array und als Trenner soll das „@“ Zeichen dienen. Somit steht im 0-ten Feld des Array unser Unsername. session.logon.last.domain expr {[lindex [split [mcget {session.logon.custom.username}] "@"] 1]} Im 1-ten Feld des Array steht die Domain und die weisen wir nun auch einer Session Variablen zu. Perfekt! Schon ist alles fertig. Policy applyen, dem entsprechenden virtuellen Server zufügen und testen. J Falls es nun doch noch nicht auf Anhieb funktioniert, so werde ich in meinem nächsten Beitrag auf das Debuggen eingehen. Bis dahin aber erstmal viel Erfolg und Spaß bei der Konfiguration. Ihr F5-Blogger, Sven Müller
Ziehen Sie die richtigen Lehren aus den Spamhaus-Attacken?
Unsere Infosecurity Umfrage 2013 enthüllte eine besorgniserregende Tendenz: Viele Organisationen haben Probleme, mit den sich ständig weiterentwickelnden Sicherheitsbedrohungen Schritt zu halten. Ein großer Teil der Befragten gab auf der Infosecurity Europe 2013 Ende April in London zu, dass es ihnen schwerfällt, DNS-Verstärkungsangriffe (Reflection Attacks) zu verstehen. Und das, obwohl sich die größten Angriffe dieser Art erst kurz zuvor ereigneten. Nur 10 Prozent der Befragten Sicherheitsexperten waren überzeugt, dass sie die Funktionsweise der DNS-Verstärkungsangriffe verstehen und erklären können. Nur elf Prozent waren sich vollständig sicher, dass die normalen Abläufe nicht unterbrochen werden, falls eine derartige Attacke ihr Unternehmen treffen sollte. Die Vielzahl der modernen Sicherheitsbedrohungen sorgt für große Verunsicherung unter den Befragten. 87 Prozent sind überzeugt, dass die Bedrohungen durch Cyber-Kriminelle, Hacktivisten und Hacker ihr Business stärker als je zuvor gefährden. Fast jeder Vierte nennt den BYOD-Trend als Hauptursache, warum seine Organisation anfälliger ist als zuvor. Auch die zunehmende Komplexität der Sicherheitsbedrohungen und ein Wechsel der „Bad Guys“ sorgen für Kopfzerbrechen: Anstatt mit Hackern sehen sich die Experten zunehmend mit Spionage und politisch motivierten Angriffen konfrontiert. In unserer Umfrage kamen auch weitere Bedenken hinsichtlich des Schutzes der Infrastruktur und von Applikationen ans Tageslicht. So waren 83 Prozent der Befragten nicht überzeugt, dass die IT-Infrastruktur ihrer Organisation über konsistente Regeln in den Aufgabenfeldern „Sicherheit und Verfügbarkeit von Anwendungen“ verfügt. „Die Größe und die Methode der Spamhaus-Attacken haben Weckruf-Charakter. Aber die Wahrheit ist, dass viele Sicherheitsexperten immer noch unzureichend auf diese neue Art von DDoS-Attacken vorbereitet sind und sich Sorgen über die potenziellen Auswirkungen eines derartigen Angriffs auf ihre Organisation machen“, ist demensprechend das Fazit von Joakim Sundberg, Worldwide Security Solution Architect hier bei F5. Unternehmen möchten von den Vorteilen der erhöhten Agilität der Infrastruktur und den reduzierten Kosten profitieren, die aus einem Umzug in die Cloud resultieren. Gleichzeitig ist für sie sehr wichtig, alle Hintertüren für potenzielle Angreifer zu schließen. Konventionelle Firewalls sind dazu leider nicht geeignet, sie versagen im Zuge der Migration von Applikationen in die Cloud. F5 rät Ihnen daher dringend zu einer Application Delivery Firewall. Wir bei F5 beobachten die Thematik und haben bereits dazu Stellung bezogen. Unsere Blogbeiträge zum Angriff auf die Süddeutsche Zeitung, zu den Attacken auf die Großbank JPMorgan Chase und zum Spamhaus-Angriff geben wertvolle Infos zum technologischen Hintergrund sowie erste Tipps und Hinweise, wie man sich erfolgreich schützen kann. In einem zweiten Schritt stehen Ihnen unsere Sicherheits-Experten gerne für weitere Fragen zur Verfügung. Sprechen Sie uns an!
Einladung zum eSeminar: Migrating App Delivery Infrastructure to F5 Networks Guru Panel - Live Q &A
Sind Sie auf der Suche nach einem neuen Ass im Ärmel? Sind Sie von Ihrem Händler im Stich gelassen worden oder waren Sie bereits auf der Suche nach einem Switch für Ihre Application Delivery Plattformen? Möchten Sie wissen, wie sich Ihre Welt mit F5 ändern könnte? Wir haben die Antworten! Wir laden Sie hiermit ein, sich zu unserem eSeminar am 12. Dezember 2012 von 10.00 bis 11.00 Uhr PST anzumelden und mit unseren F5 Gurus zu unterhalten und zu lernen, welche technologischen Möglichkeiten mit den F5-Plattformen bestehen. Das eSeminar wird in Englischer Sprache abgehalten. Wann: 12. Dezember 2012 von 10.00 – 11.00 PST Wo: Die Veranstaltung wird live in DevCentral – unserer online Community übertragen. Klicken Sie am Tag der Veranstaltung hier: https://devcentral.f5.com/s/Live Für Ihre Registrierung, melden Sie sich bitte hier an! Wir freuen uns auf Ihre Teilnahme!
Mehrwert durch strategische Partnerschaften
In unserer heutigen vernetzten und globalisierten Welt ist es wichtiger denn je, dass Zusammenspiel der IT-Infrastrukturkomponenten im Rechenzentrum zu optimieren. Dafür gibt es gute Gründe, senkt es doch sowohl die Anschaffungs- als auch die Betriebskosten. Wie wir alle wissen, ist das Motto vieler CIOs „do more with less“. Somit sehen sich viele Manager der Chefetage vor die Herausforderung gestellt, kreative und neue Wege mit den selben oder sogar weniger Ressourcen zu gehen. Was also tun? Es gibt hier sicherlich viele Wege, die zum Ziel führen. Es ist jedoch offensichtlich, daß es darum geht, bestehende Systeme zu optimieren oder zu ersetzen, um zum Einen die Kosten beizubehalten oder gar zu senken und zum Anderen sich für die Zukunft zu rüsten. Ein Ansatz kann also sein, sich eine IT-Infrastruktur zu schaffen, deren Verwaltbarkeit einfach ist, die ein hohes Maß an Sicherheit bietet und eine erfolgreiche und schnelle Implementierung gewährleistet. Wir von F5 kooperieren mit den weltweit führenden Technologie-Unternehmen, um unseren Kunden genau solche Gesamtkonzepte anbieten zu können. Kunden profitieren von der Integration und der Interoperabilität, die sich aus dieser engen Zusammenarbeit ergibt. Als ein Beispiel unserer Kooperationen möchte ich Ihnen einen sogenannten „Tech Fact“ in Bezug auf Microsoft-Umgebungen darlegen. 62% der befragten Unternehmen (die gesamte Umfrage umfasst 364 F5 Kunden) bestätigen darin, daß sie ihre Investitionskosten um 10% oder mehr mit F5-Lösungen senken konnten. Werfen Sie einen Blick darauf, wie wir Sie mit unseren strategischen Technologie-Allianzen bei der Erreichung Ihrer Ziele unterstützen können.Interview zum Thema Marktentwicklung PCs vs. Tablets mit Ralf Sydekum
Ralf Sydekum, Manager Field Systems Engineering erklärt in einem Interview auf www.sysbus.eu, was die letzten Marktzahlen besagen, warum die Verkäufe von PCs immer mehr in den Keller gehen, während gleichzeitig die Verkaufszahlen im Tablet-Bereich – vor allem bei den Android-Tablets – neue Rekordmarken erreichen. Welche Auswirkungen hat dieser Trend auf Unternehmensumgebungen?” Das komplette Interview finden Sie hier.Single Sign On bei Outlook Web Access – Sicherheit- und Performancesteigerung inklusive
Hallo liebe Leser, heute möchte ich gerne einen ersten typischen APM-Anwendungsfall vorstellen und konfigurieren. Hierbei handelt es sich um ein Reverse-Proxy Szenario, dass man in sehr vielen Datacenters vorfindet. Der Zugriff von extern (typischerweise Internet) auf Outlook-Web-Access. Zunächst einmal stellt sich die Frage, wieso sollte ich einen Reverse-Proxy davor stellen? Die Antwort ist recht einfach: Sicherheit! Aber auch Performance! Wann immer ich einen Dienst zur Verfügung stelle und das gilt insbesondere, wenn über das Internet auf diesen zugegriffen werden kann, ist dieser potentiell gefährdet. Die Motive der Angreifer können dabei ganz unterschiedlicher Natur sein. Für den Administrator gilt jedenfalls die Aufgabe, den Zugriff so sicher wie möglich zu gestalten. Erfolgt der Zugriff auf die Applikation personalisiert, dass heisst der Nutzer muss sich authentifizieren, so wird genau das, auf einem ReverseProxy durchgeführt. Schliesslich will man den Angreifer so früh wie möglich abfangen und dies eben auf einem entsprechenden gehärteten und dafür konzipierten „Box“. APM (Access Policy Manager) bietet uns sehr elegant eben genau die Möglichkeiten. Bevor ich nun aber mit der Erstellung einer APM-Policy beginne, möchte ich eine ganz kurze Erläuterung des Prinzips der Konfiguration einer BIG-IP vorschieben. Typischerweise konfiguriert man einen so genannten virtuellen Server (VS). Das ist im Grunde nichts spektakuläres, da er im einfachsten Fall nur aus einer IP-Adresse und einen Port besteht. Damit das Konstrukt auch überhaupt einen Sinn ergibt, zeigt dieser letztendlich auf eine Ressource, also z.B. einen Pool, indem sich die Backend-Server befinden. Der Pool definiert sich zumeist noch aus einem Verteil- und einem Persistenzverfahren, sowie einem Monitor zum Überwachen der Appliaktion auf den Servern. Damit haben wir eine wirklich einfache Konfiguration, die nicht viel mit Security und Performance zu tun hat. Eher entspricht es, ich wage es mal zu sagen, dem „alten, klassischen“ Loadbalancing. Heute wollen wir aber viel mehr: Applikationen müssen vor Angriffen geschützt werden und schnell Ihre Daten zum Client ausliefern. Damit wir diese Anforderungen erfüllen können, haben wir die Möglichkeit entsprechende Profile, die die unterschiedlichsten Themen adressieren, einem virtuellen Server zuzuweisen. So wird aus dem einfachen Konstrukt ein intelligenter und mächtiger Dienst. Hier ein Bild, dass den Aufbau vielleicht ein wenig verständlicher macht. Aus der Sicht von F5 konfigurieren wir übrigens auch keine virtuellen Server sondern Applikationen. Das soll bedeuten, dass wir die Sicht von weiter „oben“ haben. Natürlich sind es letztendlich die virtuellen Server mit deren Profilen, die verwendet werden. Aber heutzutage sind Applikationen oft so komplex, dass es hier nicht mit einem VS getan ist, sondern es gehören viele VS mit unterschiedlichen Eigenschaften zu einer Applikation und das ist ein ganz wichtiger Aspekt. Sehr deutlich wird dies beispielsweise, wenn man Applikationen mit Hilfe von iApps anlegt. Hier bekommt man anschließend die Hierarchie mit all ihren Ebenen angezeigt und in der Wurzel befindet sich der Applikationsname. Zusammengefasst bedeutet dies nun für unseren Fall, in dem wir unseren OWA Zugriff durch eine vorgeschaltete Authentifizierung schützen wollen, eine APM-Policy erstellen, die anschließend dem virtuellen Server, als „Eigenschaft“, zugewiesen wird. Was benötigen wir nun für diese Policy? Damit eine Authentifizierung gegen das Active Directory funktioniert, müssen wir dieses natürlich als Objekt anlegen. Im Menü „Access Policy“ wählen wir hierfür unter „AAA Servers“ den Punkt „Active Directory“ aus. Hier ist vor allem der Domain-Name wichtig, der bei Anfragen an das AD als Default-Realm immer an den Benutzernamen angehängt wird. Also z.B. sven.mueller@mydomain.de Eine Frage, die ich immer wieder gestellt bekomme ist, ob man den Admin Name und das Passwort auch ausfüllen muss. Nein, wenn man nur überprüfen möchte, ob der User und das Passwort gültig ist, dann nicht. Möchte man aber Attribute, Gruppenrechte,... des Users abfragen, so benötigt man einen User, der berechtigt ist, diese Informationen abzufragen und genau den würde man in diese Feldern eintragen. In unserem Beispiel nun, wollen wir nur eine Authentifizierung durchführen. Also reicht uns diese einfache Einstellung. Natürlich wollen wir nicht, dass der Nutzer, wenn er sich erfolgreich authentifiziert hat und dann auf unseren OWA-Server zugreift, dort nocheinmal seine Credentials in das Webinterface eingeben muss. Um das zu verhindern, konfigurieren wir noch ein Single-Sign-On Objekt. Ein „Klick“ auf Access Policy/SSO Configurations/Forms ermöglicht uns ein Form-Based SSO anzulegen: Im Falle von OWA ist es sogar sehr einfach, die Konfiguration vorzunehmen, da sie bereits als Template abgelegt ist und man nur noch den Namen und das Ziel, also den OWA-Server eintragen muss. Was aber, wenn es für die eigene Applikation kein Template gibt. Wie finde ich heraus, welche Felder und Parameter ich in die SSO-Konfiguration eintragen muss? Nun, ganz einfach, man weiss es ;-) oder man findet es heraus: Die BIG-IP macht ja nichts anderes als den gleichen Aufruf wie ein Benutzer. Das bedeutet, man schaut sich einfach an, was denn der Client zu dem Server schickt, wenn kein APM davor geschaltet ist. Hierfür gibt es eine Reihe von nützlichen Tools, oder Browser-Plugins, die einem das schön darstellen. Ein Beispiel-Werkzeug ist HTTP-Watch. Diese starte ich einfach und melde mich an meiner Applikation an. Okay und schon kann ich alles ausfüllen. Ich gehe mal kurz auf die Felder und deren Bedeutung ein. Die Credentials Source: Alle Informationen, über den Client, Eingaben,.... werden beim APM in Variablen abgespeichert. Das macht es sehr flexibel, da man immer auf diese zugreifen, oder diese auch ändern kann, so wie man es eben benötigt. Genauso kann man sich aber auch eigene neue Variablen anlegen.. Hat man sich an einer Logon-Maske angemeldet, so steht in der Variablen „session.logon.last.username“ der eingegeben Username und in „session.logon.last.password“ das Passwort. Apropos Passwort, dieses kann man sich nicht anzeigen lassen. Es wird AES verschlüsselt mit einem Key der nicht auf der Box abgespeichert ist. Aber das nur am Rande, ohne weiter darauf einzugehen. Jetzt könnten wir hier eben diese beiden Variablen einfach eingeben. Lassen wir die Default-Einstellung also „session.sso.token.last.username“ und „session.sso.token.last.password“, dann müssten wir diese vorher noch mit Inhalten füllen. Dafür verwenden wir im VPE (Visual Policy Editor) nachher das Objekt „SSO Credential Mapping“. Start URI: Hier tragen wir die URI ein, die unser APM dazu veranlassen soll, dass der SSO-Prozess gestartet wird. HTTP-Watch sagt uns, dass es sich um eine POST-Request handelt. Naja und der richtet sich an: /owa/auth/owaauth.dll. Als Parameter werden „username“ und „passwort“ mit übertragen. Deren Werte werden aus unseren im „Credentials Source“ angegeben Variablen genommen. Aber dann sehen wir, dass ja noch eine Reihe weitere Parameter übertragen werden. Diese fügen wir einfach unter Hidden Form Parameters/Values hinzu. Hierbei bitte beachten, dass Parameter und Wert von einem Leerzeichen getrennt sind! Hier kann man natürlich auch die Werte aus Variablen nehmen. Also könnte man z.B. schreiben: „domain %session.logon.last.domain“. Das bedeutet, dass dem POST der Parameter „domain“ mit dem Wert des Inhaltes aus der Variablen „session.logon.last.domain“ angefügt wird. Unter Successful Logon Detection Match Type und Value teilen wir unserem APM mit, woran es erkennen soll, dass die Authentifizierung am Server erfolgreich war. Also z.B. durch eine Recirect URL auf https://owa.mydomain.de/owa/ …und Fertig ist schon unsere SSO-Form. Nun setzen wir unsere Objekte mal in einer Access-Policy zusammen: Dafür erstellen wir unter Access Profiles eine neue Policy mit z.B. dem Namen „OWA“. Wenn wir das Formular ausfüllen, dürfen wir nicht vergessen unter „SSO Configuration“ unser SSO-Objekt auszuwählen. Dann fehlt noch die Sprache und für einen ersten Test soll das auch schon reichen. Die Timeout-Werte kann man nachher noch individuell anpassen. Da wir mit HTTPS auf unseren virtuellen Server zugreifen werden, muss unter Cookie Options der Hacken „Secure“ ebenfalls gesetzt bleiben. Unter „Logout URI“ tragen wir die URI ein, die APM veranlassen würde die Session zu löschen, wenn diese aufgerufen wird. Fertig ist die Policy! Aber im Moment würde sie niemanden auf den Backend-Server lassen, denn wenn wir nun den Visual Policy Editor (VPE) aufrufen, sehen wir, dass jeder Aufruf in ein „Deny“ läuft. Also erweitern wir die Policy ein wenig. Als erstes soll ein nicht angemeldeter User eine Logon Page bekommen. Durch ein „klick“ auf das Plus-Zeichen können wir eine Logon Page hinzufügen. Für unseren Fall reichen die „default“-Einstellungen. Eine Bemerkung aber noch zu den „Post“ und „Session“- Variable Name. Hier kann man bestimmen, wie die Variablen heissen sollten, also was vom Browser gesendet (Post) werden soll und unter welchem Variablen Namen die Information auf dem APM abgespeichert werden sollen. Natürlich kann man auch weitere Felder hinzufügen. Sehr oft sieht man hier dann noch das Feld „Token“ für ein OneTimePasswort oder ähnliches. Zurück zur unserer Policy....Wenn wir nun also die Logon-Page hinzugefügt haben, müssen wir die vom User beim Aufruf der Seite eingegeben Credentials von unserem AD überprüfen lassen. Also nach der Logon-Page wieder ein „klick“ auf das Plus-Zeichen und „AD Auth“ unter Authentication auswählen. Unter Server nehmen wir nun unser zu Beginn angelegten Active-Directory Server. Alle anderen Optionen lassen wir so. Jetzt sehen wir zwei „Endings“. Im Moment stehen beide noch auf „Deny“. Für den oberen Zweig ändern wir dies nun auf „Allow“, schließlich kommt der User ja nur dort hin, wenn unser AD „sagt“, dass die Eingabe von Username und Passwort richtig war. Also klicken wir auf „Deny“ und ändern es auf „Allow“. Jetzt sind wir fast fertig, dürfen aber nicht vergessen, dass unser „SSO Credential Mapping“ noch fehlt, denn schließlich haben wir in unserer SSO-Konfiguration die „default“-Werte gelassen. Also entsprechendes Objekt mit „Plus“ hinzufügen und fertig. Hier sehen wir auch schön, dass mit „mcget {session.logon.last.username}“ der Inhalt an unser SSO Token Username übergeben wird. Hier könnten wir auch auf beliebige andere Variablen zugreifen. So sieht nun unsere Policy aus: Jetzt dürfen wir nur nicht vergessen, diese zu „applyen“. Dafür klicken wir einfach auf den oben links, gelb leuchtende „Apply Access Policy“ Schriftzug. Das muss man übrigens immer machen, wenn man etwas an der Policy ändert. Vergisst man gerne mal.... die Änderungen gelten natürlich immer nur für neue Sessions. Das heisst manchmal ist es hilfreich unter „Manage Sessions“ im APM Menü die entsprechende Session zu löschen. Damit die Policy aber überhaupt Verwendung findet, müssen wir diese natürlich noch dem virtuellen Server für unser OWA hinzufügen. Fertig! Jetzt haben wir unsere erste APM-Policy erstellt, die User über eine Login-Seite nach den Credentials fragt und die eingegebenen Daten an ein Active Directory zur Überprüfung weiterreicht. Sofern diese korrekt sind, wird ein SSO an die Backend-Server durchgeführt, damit der User hier nicht ein weiteres Mal seine Daten eingeben muss. Ich hoffe das Beispiel hilft Ihnen, auch bei anderen Applikationen, eine Policy mit Form-based SSO durchzuführen. Ihr F5-Blogger, Sven Müller
Mit über 60.000 unterwegs für Charity
Wer sagt, Vetrieb bewegt nichts , den möchte ich heute eines Besseren belehren! Zusammen mit über 60.000 Läufern von anderen Firmen waren wir beim J.P. Morgan Lauf 2012 in Frankfurt mit 4 Mann am Start. Der J.P. Morgan Corporate Challenge ist ein Lauf über eine Strecke von 5,6 Kilometern (3,5 Meilen), an dem fest angestellte Mitarbeiter (Arbeitszeit mindestens 20 Stunden pro Woche) aus Firmen unterschiedlicher Branchen teilnehmen können. Teilnahmeberechtigt sind Beschäftigte bei Firmen, Behörden und Finanzinstituten. Bei diesem Lauf geht es erst in zweiter Linie um Sport, wichtiger sind Werte, die von den Unternehmen als erstrebenswert betrachtet werden: Team-Geist, Kommunikation, Kollegialität, Fairness und Gesundheit. Was für eine Energie, was für eine friedliche und positive Stimmung. Beim Start hätten wir gerne „Loadbalancer“ eingesetzt, um die Läufer schneller auf die Strecke zu bekommen. Als es dann lief, freuten wir uns über die grandiose Stimmung an der Strecke und liefen an unseren Kunden vorbei durchs Frankfurter Bankenviertel. Besonderer Dank an das Dimension Data Team, dass uns nach dem Lauf mit köstlicher Bratwurst und isotonischen Getränken wieder in Form gebracht hat. Keep on running, Jochen Liebrich
Kommunikation nach Außen und Innen
Mit potentiellen Kunden kommunizieren, das machen wir! Anzeigen, Internetseiten, Social Media Aktivitäten und noch vieles mehr wird für Kunden, egal ob B2B oder B2C, angeboten. Aber wer dabei die Kommunikation mit den Mitarbeitern und Partner vergisst, wird sich bald mit Missverständnissen und einem uneinheitlichen Außenbild konfrontiert sehen. Damit das nicht passiert, hat F5 einen Leitfaden mit dem Titel „F5-Soundbites – Schlagende Argumente für Partner“ entwickelt, der allen F5-Fans dabei helfen soll, die selbe Botschaft zu transportieren. Diese UNITY-Partneranleitung soll die Mitarbeiter und Partner dabei unterstützen auf wichtige Kundeninitiativen und Herausforderungen richtig zu reagieren. Um unseren Partnern auch wirklich eine hilfreiche Lektüre an die Hand zu geben, werden die Informationen nicht nur in einem reinen Text sondern auch anhand von Kurzpräsentationen, Eignungsfragen und Infrastrukturdiagrammen herausgearbeitet, ebenso wie die Vorteile der F5-Lösungen und übersichtliche Verweise zu weiteren Materialien und relevanten Kontakten. Auf diese Weise erhalten unsere Mitarbeiter und Partner die nötigen Werkzeuge, mit denen Sie die verschiedenen Kundenanforderungen mit dem Lösungsportfolio von F5 in Einklang bringen können. Diese Broschüre ist aber natürlich auch für Kunden nützlich, die sich näher mit den F5-Lösungen beschäftigen möchten und Details erfahren wollen, wie Sie Ihre IT-Infrastruktur optimieren können.
