Microsoft Office Outlook Autodiscover

Benutzer sind, wie der Name schon treffend beschreibt, Menschen welche etwas benutzen. Dieses bedeutet nicht dass sie es verstehen oder gar „montieren“ können. Sie möchten es einfach nur benutzen und dieses sollen sie auch.

Betreibt man einen Mailserver und verteilt Postfächer an seine Benutzer, kommt man extrem schnell an den Punkt dass die Benutzer ihre Postfächer nutzen wollen :-P Sie möchten ihr neues Postfach in ihren E-Mail Client (wir sagen MUA) einbinden. Nur wie?!?

 

Ja klar nun kann man bebilderte Anleitungen oder besser noch Anleitungsvideos anfertigen und diese seinen Benutzer zugänglich machen. Sehr oft muss denn noch am Ende jemand das Postfach einbinden oder es wird nach einer Fehlerdiagnose festgestellt dass der Benutzer keine E-Mails versenden kann, weil er sich nicht am Postausgangsserver anmeldet. Einfacher wäre es doch, wenn sich der MUA selbst konfigurieren würde, oder? ADS Mitglieder welche von einem Exchangeserver bedient werden, kennen die Luxusversion... Kunden der großen Freemailer wie GMX, Google, Yahoo usw. kennen es ebenso. Diese geben in ihrem MUA nämlich maximal 3 Dinge an. Ihren Namen, E-Mail Adresse und das Kennwort. Also alles Dinge die ein normaler Benutzer angeben können sollte.

 

Wie läuft diese automatische Konfiguration nun bei Microsoft Outlook ab? Nun, da es eine ganze Latte an Möglichkeiten gibt Outlook die Konfiguration unter zu schieben, fragt Outlook diese ganz brav der Reihe nach ab. Bekommt er von einer der Stellen eine Konfiguration probiert Outlook diese aus. Klappt alles, ist die Einrichtung fertig, klappt etwas nicht, geht es in der Liste weiter. Ich fasse mal kurz zusammen:

 

1 – Ist der Computer Mitglied einer Domäne, wird die E-Mail Adresse vom Active Directory abgerufen.

2 – Der DNS Name des Exchangeservers wird abgerufen.

3 – SCP (Service Connection Point) Suche und Suche nach dem passenden AutoConfig Servers. Dann mit diesen Daten eine Verbindung herstellen. Fertig....

4 – Klappt dieses nicht, wird versucht im DNS einige Domainnamen aufzulösen und dort nach einer autodiscover.xml XML-Datei gesucht.
Gesucht wird dabei hier:
a. https://ads-domäne/autodiscover/autodiscover.xml
b. https://autodiscover.example.org/autodiscover/autodiscover.xml
c. http://autodiscover.ads-domäne/autodiscover.xml
d. DNS SRV-RECORD: _autodiscover._tcp.ads-domäne/examle.org

5 – Klappt dieses auch nicht, wird versucht auf dem Rechner eine XML Datei zu finden.

6 – Klappt dieses wieder nicht, es aber ein Exchange Server (Punkt 2) gefunden wurde, wird der manuelle Konfigurations-Wizard  für Exchangeserver aufgerufen.

7 – Wurde kein Exchange Server gefunden dann wir der einfache Konfigurations-Wizard aufgerufen.

 

 

Möchte man nun seinen Outlook Client automatisch alle nötigen Einstellungen für die Konfiguration seines Postfix / Dovecot-IMAP Servers finden lassen, klappt dieses wie folgt:

Wir haken einfach an punkt 4-b. ein. Wir sorgen also dafür dass es den Domainnamen autodiscover.example.org gibt oder halt ein passender SRV-RECORD vorhanden ist und dass dieser auf einen Webserver zeigt, welcher sich zuständig fühlt. Wenn wir nun noch dafür sorgen dass Outlook dort auch die XML-Datei autodiscover/autodiscover.xml abrufen kann sind wir schon ganz weit vorne :-)

 

Zu beachten ist aber dass Outlook die Konfigurationsdatei nur dann abruft, wenn diese per https (SSL) zugänglich ist. Beim SRV-RECORD muss man wissen dass Outlook es als „Umleitung“ behandelt. Beim SRV-RECORD und bei allen anderen Umleitungen wird Outlook also ein kleines Fenster öffnen und den Benutzer fragen ob er wirklich dieser Umleitung zur Konfiguration folgen will oder nicht. Ist das SSL-Zertifikat für Outlook nicht gültig, wirft Outlook natürlich ebenfalls Meldungen raus.

 

Angenommen wir haben also die E-Mail Adresse: test@example.org

Outlook wird geöffnet, der Wizard geht auf und Fragt was für ein Konto wir einrichten wollen. Dann würfelt der Benutzer seinen Namen, seine E-Mail Adresse (test@example.org) und sein Kennwort in den Wizard. Nun geht Outlook seine Testliste durch und sieht das es die Domain: autodiscover.example.org (japp hier greift Outlook immer auf den Domainteil der E-Mail Adresse zurück) gibt. Nun macht Outlook einen HTTP/HTTPS-POST an die Adresse https://autodiscover.example.org/autodiscover/autodiscover.xml in diesem Post übermittelt Outlook unter anderem die vom Benutzer eingegebene E-Mail Adresse (das wird uns später noch helfen!). Als HTTPS Antwort erwartet Outlook nun die autodiscover.xml mit der zu nutzenden Konfiguration.

 

Alles geil, oder? Na ja fast... Outlook wird nämlich als Anmeldename per Default den Teil der E-Mail Adresse vor dem @ nutzen. In diesem Fall also test. Müssen sich Benutzer mit der kompletten E-Mail Adresse anmelden, hat man nun ein Problem. Es gibt in der XML Beschreibung zwar die Möglichkeit einen <LoginName> zu setzten. Dieser wäre aber statisch. Sprich man kann hier nicht einfach eine Variable wie %e-mailadresse% einsetzten. Nun können wir uns denn noch den POST zunutze machen. Denn hier wird dem Webserver ja die E-Mailadresse (also der Benutzername) mitgeteilt. Ein php://input könnte also die Welt retten.

 

Jaaaa nun klingelt es schon bei einigen, richtig? Genau... Die Datei: autodiscover/autodiscover.xml ist in Wirklichkeit die Datei: autodiscover/autodiscover.xml.php. In der Konfiguration des VirtualHosts im Apache wird nur ein Alias gesetzt: Alias /autodiscover/autodiscover.xml /var/www/autodiscover/htdocs/autodiscover.php Damit unser Apache bei der Outlookfrage nach autodiscover.xml bei einem PHP-Script landet. Dieses fischt alle nötigen Informationen ab und bereitet sie entsprechend für Outlook auf.

 

Perfekte Arbeit für dieses Script hat bereits David Ramsden geleistet. Sein Original ist hier zu finden: http://0wned.it/geek-bits/scripts/open-source-autodiscover-implementation-in-php/

Ich habe sein Script nur für meine Zwecke etwas angepasst.

>>Meine XML-Autodiscover Konfigurationsdatei<<

Ich hoffe dieses kann dem einen oder anderen etwas helfen diesen AutoErmittlungsdienst zu verstehen. Bei Fragen, einfach eine E-Mail schicken :-)

 


 

So nebenbei... Der Microsoft Lync 2013 Client sammelt über den A-RECORD autodiscover.example.org den Weg zum Exchangeserver ein. So kommt dieser auch an die Interne EWS-URL und die Externe EWS-URL.

Der Lync Client benötigt also für jede SMTP-Domäne zwei DNS RECORDS:

autodiscover IN CNAME exchangeserver.example.org.
_autodiscover._tcp IN SRV 0 0 443 exchangeserver.example.org.

 

 

Ich muss beim Thema Microsoft Lync aber die Hände heben. Ich kenne hier aber jemanden an den ich Anfragen weiterleiten könnte :-)


 

Mangels freier IPv4 Adressen, ist https://autodiscover.kernel-error.de/autodiscover/autodiscover.xml aktuell nur per IPv6 erreichbar. Sicher kein Problem für euch, oder? :-D

Zertifikat angepasst und per SNI passen eingebunden. So alte Clients haben dann also Pech! :-D Als kleine Tipp für die eigenen Tests, ein kleines Tool von Microsoft selbst:

https://testconnectivity.microsoft.com/

Dort müsste der Exchange ActiveSync Autodiscover alle eure Wünsche erfüllen können!


 

Auf mehrfachen Wunsch, hier nun noch einmal die autodiscover.php als copy & paste Version:

<?
/*
 Open Source Autodiscover implementation in PHP.
 
 Version: 1.0
 Tested with:
        - Microsoft Exchange Remote Connectivity Analyzer (1.3)
        - iOS 4.3.5
        - Outlook 2010 (SP0)
        - Android 2.3.3
 
 Allows auto configuration of ActiveSync and Outlook (or any other MUA that has
 autodiscover support).
 
 Example Apache vhost configuration (SSL is required for Autodiscover):
 
        <VirtualHost 1.2.3.4:443>
                ServerName autodiscover.domain.com
                ServerAdmin webmaster@domain.com
 
                SSLEngine on
                SSLCertificateFile      /etc/apache/ssl/certs/apache.domain.com.crt
                SSLCertificateKeyFile   /etc/apache/ssl/private/apache.domain.com.key
 
                # Force all requests to lowercase. Different MUAs, mobile devices etc
                # request the Autodiscover URL in different cases.
                RewriteEngine On
                RewriteMap lc int:tolower
                RewriteCond %{REQUEST_URI} [A-Z]
                RewriteRule (.*) ${lc:$1} [R=301,L]
 
                DocumentRoot /var/www/autodiscover/htdocs
                <Directory />
                        Options +FollowSymLinks -Indexes
                        AllowOverride Options Indexes Limit FileInfo AuthConfig
                </Directory>
 
                 Alias /autodiscover/autodiscover.xml /var/www/autodiscover/htdocs/autodiscover.php
 
                ErrorLog /var/www/autodiscover/logs/error.log
                CustomLog /var/www/autodiscover/logs/access.log combined
        </VirtualHost>
 
 
------------------------------------------------------------------------------
  Copyright (C) 2011 David Ramsden
 
  This software is provided 'as-is', without any express or implied
  warranty.  In no event will the authors be held liable for any damages
  arising from the use of this software.
 
  Permission is granted to anyone to use this software for any purpose,
  including commercial applications, and to alter it and redistribute it
  freely, subject to the following restrictions:
 
  1. The origin of this software must not be misrepresented; you must not
     claim that you wrote the original software. If you use this software
     in a product, an acknowledgment in the product documentation would be
     appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not be
     misrepresented as being the original software.
  3. This notice may not be removed or altered from any source distribution.
 
  David Ramsden david {at} 0wned {dot} it
------------------------------------------------------------------------------
*/
// For other supported protocols and more protocol settings, see:
//  http://technet.microsoft.com/en-us/library/cc511507.aspx
 
// Get contents of request made to Autodiscover.
$request = file_get_contents("php://input");
preg_match("/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $request, $email_address);



 
/*** Begin Configuration ***/
// ActiveSync URL.
$_CONFIG['MobileSync']['Url'] = "https://www.kernel-error.de/Microsoft-Server-ActiveSync";


 
// IMAP configuration settings.
$_CONFIG['IMAP']['Server'] = "imap.kernel-error.de";
$_CONFIG['IMAP']['Port'] = "993";
$_CONFIG['IMAP']['SSL'] = "on";
$_CONFIG['IMAP']['SPA'] = "off";
$_CONFIG['IMAP']['AuthRequired'] = "on";
$_CONFIG['IMAP']['LoginName'] = $email_address[1];
 
// SMTP configuration settings.
$_CONFIG['SMTP']['Server'] = "smtp.kernel-error.de";
$_CONFIG['SMTP']['Port'] = "465";
$_CONFIG['SMTP']['SSL'] = "on";
$_CONFIG['SMTP']['SPA'] = "off";
$_CONFIG['SMTP']['AuthRequired'] = "on";
$_CONFIG['SMTP']['LoginName'] = $email_address[1];
/*** End Configuration ***/
 

 
// XML document heading.
header("Content-Type: text/xml");
echo "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n";
 
// Get the schema from the request.
preg_match("/\<AcceptableResponseSchema\>(.*?)\<\/AcceptableResponseSchema\>/", $request, $schema);
// Determine the type of device requesting Autodiscover.
if (preg_match("/\/mobilesync\//", $schema[1]))
{
        // Mobile device.
        preg_match("/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $request, $email_address);
        ?>
                <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
                        <Response xmlns="<? echo $schema[1]; ?>">
                                <Culture>en:en</Culture>
                                <User>
                                        <DisplayName><? echo $email_address[1]; ?></DisplayName>
                                        <EMailAddress><? echo $email_address[1]; ?></EMailAddress>
                                </User>
                                <Action>
                                        <Settings>
                                                <Server>
                                                        <Type>MobileSync</Type>
                                                        <Url><? echo $_CONFIG['MobileSync']['Url']; ?></Url>
                                                        <Name><? echo $_CONFIG['MobileSync']['Url']; ?></Name>
                                                </Server>
                                        </Settings>
                                </Action>
                        </Response>
                </Autodiscover>
        <?
}
else if (preg_match("/\/outlook\//", $schema[1]))
{
        // MUA (mail client).
        ?>
                <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
                        <Response xmlns="<? echo $schema[1]; ?>">
                                <Account>
                                        <AccountType>email</AccountType>
                                        <Action>settings</Action>
                                <?
                                        // Loop through each configured protocol.
                                        while(list($protocol, $settings) = each($_CONFIG))
                                        {
                                                // Skip ActiveSync protocol.
                                                if ($protocol == "MobileSync") continue;
                                        ?>
                                                <Protocol>
                                                        <Type><? echo $protocol; ?></Type>
                                        <?
                                                // Loop through each setting for this protocol.
                                                while(list($setting, $value) = each($settings))
                                                {
                                                        echo "\t\t\t\t\t\t\t<$setting>$value</$setting>\n";
                                                }
                                        ?>
                                                </Protocol>
                                        <?
                                        }
                                ?>
                                </Account>
                        </Response>
                </Autodiscover>
        <?
}
else
{
        // Unknown.
        list($usec, $sec) = explode(' ', microtime());
        ?>
                <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
                        <Response>
                                <Error Time="<? echo date('H:i:s', $sec) . substr($usec, 0, strlen($usec) - 2); ?>" Id="2477272013">
                                        <ErrorCode>600</ErrorCode>
                                        <Message>Invalid Request</Message>
                                        <DebugData />
                                </Error>
                        </Response>
                </Autodiscover>
        <?
}
?>

 

Mozilla Thunderbird Autoconfig

Benutzer sind, wie der Name schon treffend beschreibt, Menschen welche etwas benutzen. Dieses bedeutet nicht dass sie es verstehen oder gar „montieren“ können. Sie möchten es einfach nur benutzen und dieses sollen sie auch.

Betreibt man einen Mailserver und verteilt Postfächer an seine Benutzer, kommt man extrem schnell an den Punkt dass die Benutzer ihre Postfächer nutzen wollen :-P Sie möchten ihr neues Postfach in ihren E-Mail Client (wir sagen MUA) einbinden. Nur wie?!?

Ja klar nun kann man bebilderte Anleitungen oder besser noch Anleitungsvideos anfertigen und diese seinen Benutzer zugänglich machen. Sehr oft muss denn noch am Ende jemand das Postfach einbinden oder es wird nach einer Fehlerdiagnose festgestellt dass der Benutzer keine E-Mails versenden kann, weil er sich nicht am Postausgangsserver anmeldet. Einfacher wäre es doch, wenn sich der MUA selbst konfigurieren würde, oder? ADS Mitglieder welche von einem Exchangeserver bedient werden, kennen die Luxusversion... Kunden der großen Freemailer wie GMX, Google, Yahoo usw. kennen es ebenso. Diese geben in ihrem MUA nämlich maximal 3 Dinge an. Ihren Namen, E-Mail Adresse und das Kennwort. Also alles Dinge die ein normaler Benutzer angeben können sollte.

 

>>Meine XML-Konfigutationsdatei<<

 

DU

Hinzufügen der GPG Keys zum DNS

Hinzufügen der GPG Keys zum DNS

GnuPG bietet seit längerem verschiedene Möglichkeiten DNS Server nach gpg/pgp Schlüsseln zu fragen. Die aus meiner Sicht einfachste und schnellste ist PKA.

Kann der GPG Client den Schlüssel selbstständig aus dem Internet laden muss ich mich nicht mehr darum kümmern meinen aktuellen öffentlichen Schlüssel auf allen möglichen Key-Servern zu verteilen. Kommt der Schlüssel oder die Information zum Schlüssel und dessen Fingerprint noch von dem DNS Server, welcher für die Domain/Zone zuständig ist, kann man sich noch etwas sicherer sein. Ist diese Zone dann noch per DNSsec (http://www.kernel-error.de/dnssec) geschützt... Ja dann kann man noch etwas sicherer sein! 100%tige Sicherheit gibt es nicht, ich kann mich nur den 100% annähern. Um so besser mir dieses gelingt um so sicher kann ich mir sein :-)

Wie geht es nun? Recht einfach. Ich exportiere meinen public key und sorge dafür das http clients (https ist nicht wirklich nötig, da der Schlüssel am Ende eh mit dem Fingerprint verglichen wird) diesen herunterladen können. Dann erstelle ich einen Fingerprint meines Schlüssels und veröffentliche beide Informationen zusammen mit der/den E-Mail Adressen in der DNS Zone.


OK los geht es. Zuerst besorge ich mir die Key-ID meines GPG-Keys:

$ gpg --list-keys kernel-error@kernel-error.com

 

Nun exportiere ich den öffentlichen Teil meines GPG-Keys, den public Key:

$ gpg --export --armor 0F9874D8 > kernel-error.asc

 

Jetzt brauche ich noch den Fingerprint meines GPG-Keys:

$ gpg --list-keys --fingerprint 0F9874D8

 

Nun beginne ich die records für meine DNS Zonen zu bauen. Diese sehen wie folgt aus:

E-Mail Adresse (das @ wird zu ._) gefolgt vom record Type TXT sowie dem Fingerprint ohne Leerzeichen und der HTTP-Adresse des öffentlichen Schlüssels.

Für mich schaut es so aus:

Zone kernel-error.com:

kernel-error._pka.kernel-error.com.  TXT         "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

Zone kernel-error.de:

kernel._pka.jabber.kernel-error.de.  TXT         "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"
kernel-error._pka.kernel-error.de.  TXT         "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

 

Zone vandemeer.de:

sebastian._pka.vandemeer.de.  TXT         "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

 

Ob sich die records abrufen lassen teste ich mit dig:

dig +short kernel-error._pka.kernel-error.com. TXT

 

Klappt dieses probiere ich ob gpg auch alles findet. Da ich den Schlüssel natürlich bereits in meinem Keyring habe, sage ich gpg dass es einen neuen Keyring unter /tmp/ anlegen soll. In diesen wird dann auch der Public Key importiert, wenn alles funktioniert :-) Das echo "foo" | ist nur damit gpg auch Daten hat die es anfassen soll!



Es ist NICHT sicher, daß der Schlüssel zu dem in der User-ID
Genannten gehört. Wenn Sie *wirklich* wissen, was Sie tun,
können Sie die nächste Frage mit ja beantworten

Diesen Schlüssel trotzdem benutzen? (j/N) j
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.10 (GNU/Linux)

hQIMAyLQ0wrCELyPAQ//SaagWN6N57qIN1s0IksGwbXpchBTTW4FWZVotKUeHeHv
6LQ2abOL3ulRbzIHOmYINT3CUJ3Pf0DmFm44UqXP0Ay/R0PpANNqumshP8J+0aBY
YyhImPEk4s6qK8rJqD0+0F5sWrX7A2bPbmBHmp6BDQSpIUKxTXFTChJ0Hx7n/ntn
X3iLIpl3NYzvWd78Q+7lFcH9TDL+tLb655lwbZ4HcaQOT6NAkHAL76Td8CDQdbUM
Iu7UcZrpVebAaT7dL0HcifpNy+Vfo3xzq7b/MQsHxYASgafwtuOLCJr7Mi1bJqsk
eLZgxtLsflhgnkK/4Yj/zz7TosvUKb6ZemMxok6B95tmIMmBzJt9QPtBhuF6Uhgc
Vr6E6YSM3dKOy3e2N2YEYS/eXUk68S/2B+PtSBRxMuwMB9qIfLxqZPDrMgSoSOOz
7IaBqAy+HZ7JQdYDBg+6uLrf17+hjiX9g3X/sJB002lTqEJ5aIz+fe1QBXwqM97b
7hcOQCbEm1XQOFJmJWPsgROvpQhMZvd8ylLSIKtIKHqWgn0CkobABQ5Y9HJVkpO2
+DID8yT4Iy/be/YfCzU56i2AnswduZpK3bc2DLEPORVRp6PloNOmNhTXtf6IsN1X
mZfGr3sycFq7XNY9M5nha6Jco2ZdBSgebcKNZlkPF7f1GMDfnAAJgwUcX0QMSp7S
PwFvh2D0NqPcl1Rb7ManjL5tpR0NCjnxVEPNRv0j+2Ejr7LGKH/yqZVbnr+eiSRX
FPSvDQJVgT65sPIyn0k6tg==
=k7cd
-----END PGP MESSAGE-----

 



Tja, damit sollte wohl nun jeder meinen GPG-Key über meinen per DNSsec geschützten DNS Server besorgen können.

 

Citrix XenServer local storage größer >2TB

Hat man in seinem Citrix XenServer eine Festplatte welche größer ist als 2 Terabyte, egal ob logisch durch RAID oder physikalisch als echte Hardware. So wird diese vom XenServer nicht vollständig genutzt. Das liegt daran, dass der XenServer noch aufs alte Pferd MBR setzt.
Der eingesetzte Kernel kann aber bereits mit GUID Partition Table (GPT) partitionierten Speichern umgehen. Alleine die mitgelieferten Boardmittel (fdisk….) können es auch nicht.
Zusammengefasst bedeutet es:
-    Ich kann am Citrix XenServer einen lokalen Speicher der größer ist als 2TB einbinden und benutzen.
-    Ich kann diesen Speicher aber nicht anlegen :-(

 

Damit wäre also nur das Problem des Anlegens zu lösen!

 

Voraussetzung ist dass es sich dabei um eine weitere HDD handelt, also nicht die Platte auf welcher das eigentliche Hostsystem Dom0 installiert wurde. Diesen weitern Speicher schraubt man nun also in seinen XenServer. Nun bootet man diesen mit der Hilfe von Parted Magic. Dieses Livesystem ist darauf ausgelegt mit Platten und Partitionen umzugehen. Daher ist es selbst kein Problem auf ein bereits eingerichtetes Linux Sofwareraid zuzugreifen und es bringt das Programm gparted mit.
Gparted wird nun die Hauptarbeit übernehmen, denn es ist schon länger in der Lage GUID Partition Tables (GPT) anzulegen.

 

Festhalten, es geht los…
-    gparted öffnen
-    den >2TB Datenspeicher auswählen

Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT

-    über den Menüpunkt Device den Unterpunkt Create Partition Table auswählen 

Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT

-    unter Advanced den Type der neuen Partitionstabelle auf gpt setzten und (Warnung beachten) anwenden

-    den neuen unallocated Speicher markieren

Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT

-    über den Menüpunkt Partition den Unterpunkt New auswählen

Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT
-    nun den File system Type auf lvm2 pv setzten und Hinzufügen

Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT
-    Abschließend noch diese Änderungen anwenden über den Button Apply


Jetzt haben wir eine GUID Partitionstabelle auf der großen Festplatte mit einer Partition größer 2TB und diese bereits mit dem Dateisystem Logical Volume Manager (LVM). Nun können wir wieder den Citrix XenServer booten und ihn mit seinem neuen 3TB oder 4TB oder was weiß ich Storage bekannt machen.

Nachdem der XenServer hochgefahren ist melden wir uns als Root auf der Shell an. Um den Speicher nutzbar zu machen genügen nun zwei kleine Befehle:

$ pvcreate /dev/sda1
$ xe sr-create type=lvm content-type=user device-config:device=/dev/sda1 name-label="4TB-SPEICHER"

 Ab jetzt ist der Store wie jeder andere nutzbar.


* U-P-D-A-T-E *

Zusammen mit gdisk lassen sich nun auch GPT Partitionen anlegen :-)

 

 

SSH Host Keys in DNS Zone - sshfp und ggf. DNSSEC

OpenSSH bietet die Möglichkeit die Fingerprints der Host Keys in einer DNS Zone als SSHFP-RECORD zu speichern. Dieses ermöglicht bei einem Verbindungsaufbau, die Fingerprints gegenn welche in der DNS Zone zu validieren. Es kann daher helfen, sich z.B. gegen man in the middle Angriffe zu schützen. Ist die Zone zusätzlich noch per DNSSEC (http://www.kernel-error.de/dnssec) geschützt, hat man schon eine recht hohe Sicherheit gegen solche Angriffe. Dieses zielt hauptsächlich darauf ab, Zugriffe per Kennwort zu sichern. Basiert das Login auf SSH Schlüssel, kann ein Angreifer im seltensten Fall etwas mit den Daten anfangen, dennoch hilft jedes Stückchen mehr Sicherheit! OK, es steht und fällt alles wieder beim Thema DNS, daher bitte auf DNSSEC achten.

Damit SSH auch prüft ob es im DNS einen passenden RECORD gibt muss folgendes in die Konfigurationsdatei /etc/ssh/ssh_config eingetragen werden, sofern man es global für alle Benutzer auf seinem Client aktivieren möchte:

$ echo "VerifyHostKeyDNS yes" >> /etc/ssh/ssh_config

Soll es für die eigene Benutzerumgebung geschehen liegt diese Konfigurationsdatei natürlich unter: ~/.ssh/ssh_config Soll es nur für die aktuelle Sitzung aktiviert werden, lässt es sich als Option einfach mitgeben:

$ ssh -o "VerifyHostKeyDNS=yes" www.kernel-error.de

Baut man nun eine Verbindung auf, fragt OpenSSH den DNS Server ob dieser Informationen zum erwarteten Fingerprint liefern kann. Sind keine Einträge in der DNS Zone vorhanden schaut der Verbindungsaufbau wie folgt aus:

$ ssh -v www.kernel-error.de
OpenSSH_5.5p1 Debian-6+squeeze2, OpenSSL 0.9.8o 01 Jun 2010
.....
DNS lookup error: data does not exist
The authenticity of host 'www.kernel-error.de (2001:7d8:8001:100::dead:beef)' can't be established.
RSA key fingerprint is fc:aa:73:17:bc:6a:0a:4f:af:3a:98:9e:73:b8:c4:68.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Um dieses zu "verbessern", gibt mehrere Möglichkeiten die SSHFP RR für seine Zone zu erstellen. Es gibt das Programm sshfp...

$ sshfp www.kernel-error.de
www.kernel-error.de IN SSHFP 1 1 f9dfcb6311e31da8c267ae53a5830887bd2bb3b3
www.kernel-error.de IN SSHFP 2 1 97179afabaaf9b68b05dbf1357cffe3de6ce76fe

Dann gibt es unter anderem noch die, von mir präferierte Lösung, direkt per ssh-keygen auf dem Zielhost (Server):

$ ssh-keygen -f /etc/ssh/ssh_host_rsa_key.pub -r www.kernel-error.de.
www.kernel-error.de. IN SSHFP 1 1 47890eecc9a2893061734b07b8f60caa1a856148
www.kernel-error.de. IN SSHFP 1 2 b2518ad49cc2adf517d3f6a9faaf4017abc2c3e33dae0a29c46226e9ff691cd2
$ ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -r www.kernel-error.de.
www.kernel-error.de. IN SSHFP 3 1 3dd9de0dcf1523341b45a53f1d57043609e26c62
www.kernel-error.de. IN SSHFP 3 2 e1c76bd66b5a0641789b0b37be5b80ae3f6395c1cd2b73cca532a8111c9515b4

Dabei ist der SSHFP-RECORD wie folgt aufgebaut:

Zielhost  ==>  Protrokollart  ==>  RR-Typ  ==> Host-Key Algorithmus ==> Hash-Art des FP ==> Fingerprint

 

Folgende Host-Key-Algorithmen sind bisher definiert:

  1.  1 ssh-rsa
  2.  2 ssh-dss
  3.  3 ecdsa
  4.  4 ed25519

Hash-Arten des FP sind dabei SHA1 und SHA2(56).  1 wäre dabei SHA1 und 2 logischerweise SHA2

Diese fertigen RECORDS kann man nun in seiner DNS-Zone veröffentlichen, dass die Zone zum Host zu passen hat, muss ich ja sicher nicht mehr erwähnen, oder?


Baut man nun die Verbindung erneut auf, findet OpenSSH auch etwas.

$ ssh -v www.kernel-error.de
OpenSSH_5.5p1 Debian-6+squeeze2, OpenSSL 0.9.8o 01 Jun 2010
.....
debug1: found 2 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
The authenticity of host 'www.kernel-error.de (2001:7d8:8001:100::dead:beef)' can't be established.
RSA key fingerprint is fc:aa:73:17:bc:6a:0a:4f:af:3a:98:9e:73:b8:c4:68.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Natürlich lassen sich die Einträge auch mit dig abrufen:

$ dig +short www.kernel-error.de IN SSHFP
3 1 3DD9DE0DCF1523341B45A53F1D57043609E26C62
3 2 E1C76BD66B5A0641789B0B37BE5B80AE3F6395C1CD2B73CCA532A811 1C9515B4
1 1 47890EECC9A2893061734B07B8F60CAA1A856148
1 2 B2518AD49CC2ADF517D3F6A9FAAF4017ABC2C3E33DAE0A29C46226E9 FF691CD2
SSHFP 7 3 86400 20160307114536 20150313114536 13952 kernel-error.de. hib4uoiPCBlAXytsVHsqvGdGDRPdec42nA2J7IW8mQVV/o7fb5kPfV6J ZIp4D6O0RsSWW++9QzvCd0gHiTQcQLXdpypCoSBbLYGpWnBl3zCk9zFS iLhawl79VFun7xccZU9UjWoHRyrEo5pDfN3heBgT4ycjlB2m0i40D5WQ 25pCh95yAnSB/wchW4MwffDgc+10GrRcpxWL662k6pFRpLFHsDZ2YS6c zYEK2u1nAc0hI0XqtJrXxDxZZ9reHWvmk5wAK3LHcoWOv5DFP6LyIzY8 omhm+zF9KzIt8V0PuzMD9rUfeZAZjjCsllxv39bx+UHcS0ZsKxpCV4Ny c2OSCOCyHjtc1+qgYuZlkL5rej7wOVvCTB5Jym4B0vTO7ct22/VoqEdh zLjiWXSDW87qkNnImGU1EXHMqOXU5qzxgKgRjMu6AfJYB+zRP2B2P5eJ I9sGWOWJIV24ot1dWisWeSvItXNHW84mzFVgqUUuMKZ5uQGocpWjMc7c b0h0o4P4D0HtarBuRV7Z6QsJjEy0zMst2PChi3y+WFP4ar7Tl59K3ePN 7Qw/695jjA2YitpUYWBZL052r5d2u9hBTZGPvxvJRjFfvNcdy7Sv3ii1 sl6dTp/XIlJ82xsVEwNEYqgSQVJwNEzIcH+doUF4pGKnFmOWG/NlXfYJ 9Kx2Xon6c7Y=
SSHFP 10 3 86400 20160307114536 20150313114536 12698 kernel-error.de. dbv2KMbxb4Vd+kLz86hGjdc12b3/8THtIfThd8kjm5ik9Yxo3njcw60/ sJ9wvJ4/2AiBNoEebh3wUxnoJprqsjyEdIq+7mPggVhs6VV5Sl9GZoNM 1bzkq85xjHt9/KVzLwou9/s0t9PgZ3vl2wU6MMl5MvleGumw+w6DnZpz NXzX57IpMs3TCMHPVhpYglGjtRcDPnfFSqbLLwnM5rbidp80iEob/d3J Xm6lSPBuwrry4aAYErWMxxsDJBosXKGC2EQNKK5PrkVF9JbWwXUFXowU H9m1iNsDaRBP6xqKoa+I4efR9GNojb55s2Nh1b6T+9zVyjcclp2rYbt/ QL6l6GSTHvoP6L7o3H3heg1Q4uUu+mj7a8lEHfuF2jbp6afjrL17hR/b v7ArzP7PpV6KOmx15pBLH3V0GoEle7WKon65+6mNaDDvs5yh7LSd1Im3 zAi1C0TUkf4VN4MU+FhDh+r6KKsqh0WvP0hc7UaTcpEIH3ox7QbHGvf7 zxiBypRVfrrW3OQhQvRk6U4wIIx1XicaYRfkPmEL/OtYTc9B81dGe3ci JLZLedMCWifPtsO+B3ml5apH8+MTu7fyWEpf4NPz2egWzFkHYsl8Out8 2z7jzhPwgAfyZ2qr0z1SZWSpxvZ/P7LqNaauoFQxpyZT6/qFXA8M1quf Tornope2Y4E=

Wie immer bei DNSSEC zur Sicherheit prüfen ob die Antwort "sauber" ist:

$ dig +dnssec www.kernel-error.de IN SSHFP |grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags:; MBZ: 7e06 , udp: 512

In der Antwort muss das ad flag gesetzt sein!!!

Nach all dieser Arbeit könnte man nun noch OpenSSH anweisen, die Verbindung nur aufzubauen, wenn der Host-Key erfolgreich validiert werden konnte. Dieses wieder, wie oben beschrieben, in der /etc/ssh/ssh_config oder den anderen Stellen:

Host *
    StrictHostKeyChecking yes

Ich mag solche Dinge sehr :-) Sehr kleiner Aufwand und schon ist es um einiges sicherer...


Kleines Update 16.02.2015

ed25519 erst richtig ab OpenSSH Version 6.7, ecdsa fragwürdig sicher und dss bitte NICHT! Ich will sagen >= OpenSSH 6.6 4096bit RSA bitte :)

Der Verbindungsaufbau sieht in der aktuellen OpenSSH Version etwas anders aus. Erfolgreich sollte es so aussehen:

debug1: found 4 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS

Inzwischen arbeitet OpenSSH direkt mit DNSSEC, wenn möglich. Solltet ihr also der Meinung sein, Fingerprints und Zone korrekt konfiguriert zu haben, OpenSSH wird aber einfach nicht "glücklich"... Dann prüft doch mal bitte auf Extension mechanisms for DNS (http://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS)! Aktiviert sich normalerweise mit folgender Zeile in der /etc/resolv.conf

options edns0