Category Archives: Technik

Bring your own Device – Samsung Knox macht es möglich

IMG_1849

Marius Hertz / Samsung
© phoeney.de

Auf dem Mobile World Congress (MWC) in Barcelona wurde Samsung Knox bereits vorgestellt, heute konnte ich auf der CeBIT einen ersten Einblick in den neuen „Bring your Own Device“ –Lösungsansatz von Samsung erhalten.

Das Konzept basiert auf der Sandbox Technologie, welche eine einfache Verwaltung von mehreren abgekapselten Instanzen des Android Betriebssystems auf einem Gerät ermöglicht.

Wie mir Marius Hertz von Samsung erzählte, ist die Verwaltung der einzelnen Container über ein Mobile Device Management System und die von Samsung zu Verfügung gestellten Schnittstellen (APIs) möglich. Ein Mitarbeiter kann nun also sein privates mobiles Samsung Gerät mit in das Unternehmensnetzwerk bringen und dabei im „Geschäftlichen Modus“ alle Dienste und Anwendungen wie auf einem Firmengerät nutzen. Dazu zählen beispielsweise Wireless Verbindungen im Unternehmensnetzwerk oder der gesicherte Zugriff auf Exchange Dienste mittels ActiveSync. Dabei können innerhalb dieser Sandbox auch Unternehmensrichtlinien durchgesetzt werden um den Sicherheitsstandards des Unternehmens zu entsprechen.

BYOD Übersicht

Geplant ist das Rollout von Samsung Knox für das Quartal 2/2013 und soll für alle Samsung Top-Modelle zur Verfügung stehen. Mobile Device Management Partner von Samsung, wie bspw. Mobile IRON, sollen bereits zum Release, eine vollständige Unterstützung von Samsung Knox beherrschen.

Outlook 2010 hängt sich beim Versenden von S/MIME signierten E-Mails auf

Angetrieben von einem Arbeitskollegen, habe ich mich in letzter Zeit ein wenig mit S/MIME Verschlüsselung von E-Mail beschäftigt. Für Privatanwender bieten viele Zertifizierungsstellen kostenlose Identitätszertifikate an, ich hab meines bei Comodo bestellt, aber darum soll es hier nicht gehen. Da bei Hosted Exchange Provider aktuell keine Möglichkeit zur Serverseitigen Signierung bietet, muss diese lokal an den jeweiligen Endgeräten stattfinden, sprich direkt im Outlook Client.

Um kurz meine Umgebung zu beschreiben: Ich nutze Windows 8 Pro, habe Outlook 2010 welches von einem Windows 7 zu Windows 8 Upgrade übernommen wurden (ich kann nicht genau sagen ob das im beschriebenen Fall eine Rolle spielt). Nun habe ich mein Signiertes Zertifikat samt private Key über den Zertifizierungsmanager (certmgr.msc) importiert und konnte dieses auch im Sicherheitscenter von Outlook auswählen um E-Mails zu signieren bzw. zu verschlüsseln. Um das ganze einfach zu halten wollte ich zunächst jedoch nur signieren. Nachdem alles erfolgreich konfiguriert worden ist, wollte ich gleich überprüfen, ob ausgehende E-Mails auch sauber signiert werden, jedoch hing sich Outlook 2010 beim Versenden einer E-Mail ab sofort auf und lässt nur noch über den Task-Manager beenden.

Das Ganze hat ein ein wenig Recherchezeit gekostet, bis ich auf das eigentliche Problem gestoßen bin. Seit Windows Vista existiert die so genannte Benutzerkontensteuerung (kurz UAC – für User Account Control). Outlook 2010 muss, um auf den Zertifikats Store zugreifen zu können, eine temporäre administrative Berechtigung erhalten um das Zertifikat laden und die E-Mail signieren zu können. Und hier liegt das Problem, Outlook erhält diese Rechte unter Windows 8 nicht, was zur Folge hat, dass es einfach abstürzt.

Bei Microsoft ist dieses Problem Mittlerweile bekannt und ein Hotfix ist bereits in Testumgebungen ausgerollt. Der Hotfix selbst soll im März veröffentlicht werden.

Jedoch gibt es einen Workaround. Sobald Outlook 2010 mit administrativen Berechtigungen gestartet wird und eine signierte E-Mail versendet werden soll, erhält man zunächst eine Abfrage, ob Outlook auf den Zertifikats-Store zugreifen kann. Sobald diese Anfrage bestätigt wurde, wird die signierte E-Mail problemlos verschickt.

Outlook_certificate_store

 

ESX(i) 5 in Active Directory Domäne integrieren

Aufgrund der Vorbereitungen für den Relaunch von phoeney.de gibt es auch einige infrastrukturelle Veränderungen. Ohne jetzt zu weit ausschweifen zu wollen, phoeney.de wird sich auf einem ESX(i) 5 Host befinden und um das Ganze ein wenig einfacher zu managen, ist eine Benutzerkontensteuerung über das Active Directory doch recht nett.

Kurz zu den Vorbereitungen:

Ich habe bereits ein bestehendes Windows Server 2008 R2 Active Directory als virtuellen Host auf meinem ESX Server. Über einen vKernel Adapter habe ich das interne Management Netzwerk für den ESX Server zugänglich gemacht. Dabei sind die DNS Server Einstellungen von großer Bedeutung, da mittels Domain-Name in die Domäne betreten werden muss.

Wenn wir so weit sind, können wir mittel vSphere Client unter dem Punkt Konfiguration -> Authentifizierungsdienste die Domänenintegration starten. Unter dem Punkt Eigenschaften können wir nun den Verzeichnisdiensttyp wählen, also Active Directory und unsere Domäne angeben, in meinem Fall „phoeney.int“. Anschließend werden wir nach Benutzerdaten von einem Domänen-Administrator gefragt.

bild1

Ob die Domänenintegration erfolgreich abgeschlossen wurde, können wir an zwei Stellen überprüfen. Zum einen direkt bei den Authentifizierungsdiensten, welche nun auf Active Directory gestellt sein sollte.

bild2

Zum anderen können wir im Active Directory selbst unter Computer sehen, dass ein neuer Host hinzugefügt wurde.

bild3

Um nun Benutzer oder Benutzergruppen zu Berechtigen. Dies können wir im vSphere Client unter dem Punkt Berechtigung tun. Hier fügen wir lediglich eine neue Berechtigung hinzu und wählen den gewünschten User bzw. Gruppe und die Rolle. Ich nehme in meinem Fall die Gruppe Domänen-Admins und weise die Rolle Administrator zu.

bild4

 

Nun können wir uns mit einem Benutzer, welcher in der AD-Gruppe Domänen-Admins Mitglied ist über den vSphere Client an unserem ESX Server anmelden. Unten rechts können wir übrigens den Benutzer sehen, mit welchem wir eingeloggt sind.

bild5

VPN Problem unter iOS 6

Ein Kunde hat mich heute auf ein Interessante Problem im VPN Client bei Apples Betriebssystem iOS 6 aufmerksam gemacht. Wie auch viele Nutzer im Apple Forum berichten, kann der Cisco IPSec Client nach dem Update keine Verbindung mehr zu VPN Servern aufbauen wenn Clientseitig Zertifikate zur Authentifizierung verwendet werden.

Zunächst handelt das IKE Protokoll richtig und fragmentiert die Authentifizierungsanforderung in kleinere Teile, welche selbst noch nicht verschlüsselt sind und sendet diese an das VPN Gateway. Leider wird dabei auch das ISAKMP-Verschlüsselungs-Flag gesetzt obwohl Authentifizierungsanforderung nicht verschlüsselt sein darf. Wenn das VPN-Gateway das ISAKMP-Flag ignoriert, wird die Verbindung ganz normal etabliert, falls nicht schlägt die Verbindung fehl.

Im Klartext heißt das, dass der Cisco IPSec VPN Client unter iOS 6 ein Verschlüsselungs-Flag an eine Stelle setzt, wo niemals eins hingehört.

Einen Workaround gibt es nicht wirklich, ohne das Änderungen am VPN-Gateway vorgenommen werden müssen (Umgang mit dem ISAKMP Flag oder ggf. Umstellung auf PreShared-Key). Von daher empfiehlt sich, mit dem Update auf iOS 6 zu warten, oder die VPN-Verbindung vorher mit einem Testgerät zu überprüfen.