ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE

Transkript

1 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická Bakalářská práce Jednotný elektronický podpis v u pro Microsoft SMTP server Jan Salajka Vedoucí práce: Ing Daniel Staněk Studijní program: Elektrotechnika a informatika strukturovaný Obor: Výpočetní technika Leden 2009

2

3 název práce Jednotný elektronický podpis v u pro Microsoft SMTP server. Unified signature for Microsoft SMTP server. katedra obhajoby Katedra počítačů obor Výpočetní technika (bakalářský) studijní program Bakalářský vedoucí Staněk Daniel Ing. Katedra počítačů (13136) externista, AUTOCONT CZ a.s. daniel.stanek@autocont.cz oponent Ballner Radim Ing. externista, Iterity s.r.o. xballner@fel.cvut.cz student Salajka Jan studuje zadáno salajj1@fel.cvut.cz literatura Dodá vedoucí práce pokyny Navrhněte řešení jednotného firemního podpisu, který je automaticky doplněn do každé odcházející poštovní zprávy pomocí Microsoft SMTP serveru (Microsoft Exchange 2003 na platformě Windows 2003 server). Firemní podpis má obsahovat stálý text a personifikované údaje o odesilateli získané z Active Directory (oddělení, telefon apod.). Navrhněte rozhraní pro konfiguraci a změnu elektronického podpisu. Proveďte analýzu vhodných programových nástrojů se zřetelem na jednotlivé dílčí vazby a chování systému. Navržené řešení ověřte pilotní implementací. zadavatel Autocont CZ a.s. ii

4

5 PROHLÁŠENÍ Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady v přiloženém seznamu. Nemám závažný důvod proti užití toho školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Duchově dne.. ii

6 PODĚKOVÁNÍ Děkuji Ing. Danielu Staňkovi za vedení mé bakalářské práce a za podnětné ná- vrhy, které ji obohatily. iii

7 Název práce: Jednotný elektronický podpis v u pro Microsoft SMTP server. Autor: Obor: Druh práce: Vedoucí Abstrakt: Klíčová slova: Salajka Jan Výpočetní technika (bakalářský) Bakalářská práce Staněk Daniel Ing. Katedra počítačů (13136) externista, AUTOCONT CZ a.s. Tato bakalářská práce se zabývá návrhem a implementací aplikace pro řešení jednotného firemního podpisu v odchozích ech v prostředí operačního systému Microsoft Windows a Microsoft Exchange serveru. Navrhovaná aplikace doplňuje automaticky jednotný podpis do všech odchozích ů s personifikovanými údaji odesílatele na základě konfigurace. Personifikované údaje jsou vyhledávány v Active directory dle ové adresy odesílatele. Součástí práce je návrh uživatelského rozhraní pro konfiguraci systému. smtp, podpis, exchange, Title: Unified signature for Microsoft SMTP server. Author: Abstract Key words: Salajka Jan This bachelor thesis deals with a design and implementation of the application for unified corporate signature solution in outgoing s within the operation system Microsoft Windows and Microsoft Exchange server. The proposed application on the basis of configuration automatically complements the unified signature in all outgoing s with personified data of a sender. The personified data are searched out in the Active directory according to the sender s address. A proposal of user interface for system configuration is also included in the thesis. smtp, signature, exchange, iv

8 OBSAH Seznam obrázků Úvod Deklarace záměru Analýza a návrh řešení Návrh typu aplikace Vývojové prostředí a programovací jazyk Problémy a omezení návrhu Problém duplicitního podepisování Kryptování u, případně elektronický podpis šifrovacím klíčem Formát u a kódování u Schéma navrhované aplikace Úložiště konfigurace a konfigurační soubory NÁvrh Uživatelského rozhraní pro administraci a konfiguraci Realizace Popis implementovaných tříd Class Sink Class Sign Class ADConnector Class RegConfig Class Log Poznámky k překladu aplikace Vývojové prostředí a překlad aplikace Ladění aplikace Testování Konfigurace testovacího prostředí Instalace Microsoft Windows2003 serveru standard edition Instalace Active directory a DNS služeb Instalace IIS Instalace Microsoft Exchange 2003 serveru standard edition Instalace a konfigurace Microsoft Outlook Konfigurace SMTP v testovacím prostředí Instalace aplikace MailSign v testovacím prostředí Způsob, průběh a výsledky testování Finální testování Výsledky testu Srovnání s existujícími řešeními, pokud jsou známy Aplikační dokumentace Instalace Systémové požadavky Konfigurace SMTP Instalace aplikace Aktivace Event Sink Příklad dávkového souboru pro registraci a aktivování knihovny MailSign Příklad dávkového souboru pro deaktivování a odregistraci knihovny MailSign

9 5.2 parametry aplikace Popis parametrů Příklad REG souboru Utilita Cryptpassword Vzory podpisů Příklad vzoru podpisu ve formátu prostý text Příklad vzoru podpisu ve formátu HTML Příklad podepsané zprávy Atributy Active directory(13) Logování aplikace Závěr Zhodnocení splnění cílů BP Diskuse dalšího možného pokračování práce Bibliografie... i Příloha A - Obsah přiložého CD... ii 2

10 SEZNAM OBRÁZKŮ Číslo Strana Obrázek 1 konceptuální schéma aplikace... 8 Obrázek 2 uživatelské rozraní editace vzorů Obrázek 3 Uživatelské rozraní editace parametrů Obrázek 4 Deklarace třídy Sink Obrázek 5 Deklarace třídy Sign Obrázek 6 Deklarace třídy ADConnector Obrázek 7 Deklarace třídy RegConfig Obrázek 8 Deklarace třídy Log Obrázek 9 Schéma SMTP konfigurace Obrázek 10 Graf zatížení serveru při odesílání cca ů bez použití aplikace MailSign 23 Obrázek 11 Graf zatížení serveru při odesílání cca ů s použitím aplikace MailSign. 24 Obrázek 12 Původní zpráva ve formátu prostý text Obrázek 13 Podepsaná zpráva ve formátu prostý text Obrázek 14 podepsaná zpráva ve formátu HTML

11 Úvod 1 Ú v o d Zadání bakalářské práce vychází z konkrétního požadavku mého zaměstnavatele společnosti Autocont CZ a.s, kde pracuji na pozici systémového specialisty pro serverové systémy Microsoft. Ze základní analýzy zadání a možných způsobu řešení problému vyplývá rozdělení projektu na dvě části. Jedna část obsahuje funkční program, který realizuje vlastní elektronický podpis odchozích ů na základě konfiguračních souborů a komunikace s adresářovou službou Active directory. Tato funkční část bude ověřena v laboratorním prostředí testovacím provozem. Součástí je také popis struktury konfiguračních prvků, který bude poskytovat potřebné zadání pro druhou část. Tato je tvořena návrhem uživatelského rozhraní pro správu systému, které umožní administrátorům modifikovat konfiguraci a měnit tak vlastnosti a chování systému. Implementace uživatelského rozhraní není součástí této bakalářské práce a bude možné jí v budoucnu o tuto doplnit. Systém jednotného firemního podpisu je požadován pro konkrétní softwarovou platformu Microsoft Exchange serveru 2003 provozovaného na operačním systému Microsoft Windows 2003 server. Toto prostředí předurčuje návrh a umožňuje využít možností konkrétních systémových prostředků. Platforma také vymezuje rozsah práce, který se nemusí řešit v obecné rovině, ale zahrne pouze ty části, které jsou v tomto prostředí potřeba. 1.1 DEKLARACE ZÁMĚRU Systém umožní automaticky vkládat předepsaný firemní podpis do ů odeslaných uživateli pomocí Microsoft exchange serveru nezávisle na klientském prostředí. Tento podpis musí umět vkládat do elektronického podpisu kromě statického také text dynamický, který je modifikován na základě údajů uživatele z Active directory. Primární využití je určeno pro údaje typu telefonních čísel, názvu oddělení a podobně, které jsou v AD udržovány. Tyto údaje se budou nahrazovat automaticky na základě ové adresy odesílatele, která je jednoznačným identifikátorem v adresářové službě Active directory. 4

12 Analýza a návrh řešení 2 A n a l ý z a a n á v r h ř e š e n í 2.1 NÁVRH TYPU APLIKACE Při návrhu bylo potřeba udělat několik základních rozhodnutí. Základní otázkou bylo kam umístit vlastní výkonnou část systému. Podpis je možné doplnit přímo při vytváření u na straně ového klienta. Tato varianta je poměrně náročná a to hned ze dvou důvodů. V prvé řadě je problém s vlastní distribucí konfigurace a výkonné klientské části systému. Druhým problémem je variabilita klientského prostředí. Proto, aby byl systém funkční, bychom museli určit pouze určité typy a verze podporovaných poštovních klientských aplikací. Pro každou takovou aplikaci bychom museli vyvinout a otestovat samostatnou část řešení. Druhá varianta je založena na doplňování podpisu do u na serverové straně, což je podstatně jednodušší na realizaci. To je dáno zejména snadnější údržbou serverové konfigurace a také je řešení tvořeno pouze jednou komponentou a administrátorským rozhraním. Zpracování odchozích ů na straně serveru je možné realizovat několika způsoby. Vytvořením plnohodnotného SMTP serveru, který by sloužil jako takzvaný SMART HOST 1. Na tento SMTP server by byl nasměrován veškerý odchozí ový provoz stejným způsobem, jakým fungují různé antispamové a antivirové systémy nezávislé na platformě vlastního poštovního systému. Vzhledem k jasné specifikaci prostředí, pro které je produkt určen je možné využít vlastností a programového rozhraní Microsoft Exchange serveru a využít takzvané jímky událostí (event sink), která umožňuje programově zachytit a případně modifikovat odchozí i příchozí y. Tato poslední varianta byla zvolena jako nejvhodnější a v dané situaci nejefektivnější pro vlastní realizaci projektu. 2.2 VÝVOJOVÉ PROSTŘEDÍ A PROGRAMOVACÍ JAZYK Pro vývoj aplikací je v dnešní době na výběr velké množství vývojových nástrojů a programovacích jazyků. Dle návrhu projektu je možné jej realizovat pomocí skriptovacího prostředí operačního systému Microsoft Windows server v programovacím jazyku Visual basic script nebo Java script. Toto skriptovací prostředí umožňuje realizovat velké množství úloh, ale jeho hlavní zaměření je na realizaci jednoduchých, převážně administrativních úkonů v prostředí Microsoft Windows. Výsledný produkt bude zpracovávat veškerý odchozí ový provoz, který bude generován Exchange serverem a uživateli. Dá se odhadnout, že pro malou organizaci (do 50 uživatelů) se bude množství ů pohybovat v řádech stovek a tisíc denně. Pro řešení úlohy 1 smart host je typ relay serveru, který vystupuje jako prostředník a umožňuje směrovat y mezi serverem odesílatele a příjemce. 5

13 Analýza a návrh řešení takovéhoto rozsahu 2 není skriptovací prostředí vhodné. Bylo použito pouze pro ověření možného napojení naší komponenty na Exchange server. Pro vlastní vývoj a finální aplikaci je vhodné použít vývojové prostředí, které je schopné vytvořit komponentovou aplikaci na bázi COM nebo COM+ 3 kterou jsme také schopni napojit na programové rozhraní Exchange serveru. V mém případě padla volba na vývojové prostředí Microsoft Visual studio 2008 a programovací jazyk C PROBLÉMY A OMEZENÍ NÁVRHU Návrh systému automatického podpisu, který je zpracováván na straně serveru, bez vazby na poštovního klienta, který vytváří , trpí několika typy problémů, na které je nutné se zaměřit a pokusit se je eliminovat nebo alespoň zmírnit jejich dopad. Jedním z nejproblematičtějších je duplicitní podepisování, případně zařazení podpisu do špatného místa u Problém duplicitního podepisování K této situaci dochází zejména při odpovídání nebo při předávání u dalším adresátům. Tuto zprávu generuje poštovní klient na základě původní zprávy bez jednoznačného rozlišení nového a původního obsahu. Z pohledu komunikačního protokolu a vnitřní reprezentace zprávy je takto vytvořená zpráva opět novou plnohodnotnou zprávou. Zde dochází k výše uvedenému problému, jelikož server, který tuto zprávu doručuje, není schopen rozeznat již jednou podepsaný a nemůže s určitostí zajistit, aby podpis nebyl do zprávy začleněn znovu duplicitně. Tento problém je možné částečně vyřešit rozeznáváním určitých formátovacích znaků ve zprávě a na základě těchto znaků se rozhodnout, jestli podpis ke zprávě připojit či nikoli. Jeden ze znaků jak poznat předávanou případně odpovědní zprávu je na základě předmětu zprávy, kde je většinou přidán prefix Re: v případě odpovědi nebo Fw: v případě předání zprávy. Toto nejjednodušší rozlišení je možné použít, a tyto typy zpráv nepodepisovat automatickým podpisem. Tím je možné zabránit hromadění podpisů při poštovní konverzaci mezi dvěma poštovními adresami. Problém jsme tímto však neodstranili úplně, jelikož používané prefixy v předmětu nejsou zakotveny v žádném standardu a jsou závislé pouze na poštovním klientu, který takovouto zprávu vytváří. V praxi se můžeme setkat s jinou modifikací prefixů, zejména v německy mluvících zemích. Například pro identifikaci odpovědi je použit prefix Antwort:. Pro zkvalitnění rozpoznávání takových to zpráv je možné tyto varianty začlenit do konfigurace aplikace. Toto řešení umožní administrátoru automatického podpisu nastavit případné odlišnosti na základě aktuálně používaných prefixů, případně doplnit některé zvláštní prefixy, které se běžně nevyskytují. 2 Zadání nespecifikuje výkonové požadavky ani množství zpracovaných ů, takže předpokládáme střední zatížení. 3 COM, COM+ (component object model) je standardní rozhraní vyvinuté společnosti Microsoft v roce 1993, umožňující komunikaci mezi procesy a dynamické vytváření objektů v libovolném programovacím jazyku, který tuto technologii podporuje. 4 C++ je objektově orientovaný programovací jazyk, který vyvinul Bjarne Stroustrup a další v Bellových laboratořích AT&T rozšířením jazyka C 6

14 Analýza a návrh řešení Další možností je si při podpisu tvořit jakýsi otisk (hash), který začleníme do zprávy jako takové. Tento hash by byl vyhledáván při rozhodování, jestli zpráva již neobsahuje jeden automaticky vytvořený podpis. Při tomto řešení je největším problémem jak takový to hash začlenit do zprávy, aniž bychom nějakým způsobem ovlivnili vlastní obsah zprávy nebo formátování. Při základní analýze bylo rozhodnuto, že tento druh označení podpisu ve zprávě nebude realizován z důvodů technické náročnosti řešení a také možných problémů s antispamovými systémy. Tyto systémy jsou v poštovních cestách využívány a zajišťují ochranu proti nevyžádané poště (spamu), které provádějí rozsáhlé sady testů a heuristické analýzy pro rozeznání běžných zpráv od nevyžádané pošty a každý nestandardní nebo neobvyklý obsah v poštovní zprávě zvyšuje bodové ohodnocení, které může mít za následek zařazení běžných ů podepsaných automatickým podpisem s hashem zařazení do spamu a zabránit tak běžnému doručení Kryptování u, případně elektronický podpis šifrovacím klíčem Kryptování, nebo podpis u šifrovacím klíčem je také pro zpracování automatického podpisu na serverové straně problém, jelikož obě metody mají ochránit před modifikací cizí osobou takzvaného muže uprostřed (Man in the middle). Což se přesně snaží udělat aplikace pro automatický podpis. Z tohoto důvodu je nutné y chráněné šifrováním nebo podepsané šifrovacím klíčem identifikovat a nechat je nezměněny. Pokud by takováto zpráva měla být opatřena automatickým podpisem, musel by mít systém přístup k šifrovacím klíčům odesílatelů zpráv a při podepisování by zpráva musela být rozšifrována, přidán podpis a opět zašifrována patřičnými klíči. Toto řešení je velice omezující, jelikož by bylo závislé na komunikaci s PKI 5 infrastrukturou a také na přístupu k tajným klíčům odesílatele, což by mohlo být v rozporu s bezpečnostní politikou organizací využívající tento systém. Z těchto důvodů není toto řešení do navrhovaného systému zapracováno a takovéto y budou procházet beze změn Formát u a kódování u Formát ové zprávy je doporučen v RFC a navazujících RFC, které definují potřebné vlastnosti jednotlivých částí zprávy. Pro zpracování ů jsou používány COM rozhraní Microsoft Exchange serveru a operační systémy, které výrazně zjednodušují práci s em. Díky těmto rozhraním není potřeba zpracovávat kompletní implementaci podle výše uvedených RFC. K problému s kódováním znakové sady u může dojít v případě, že použitá znaková sada původního u neumožňuje používání speciálních znaků a podpis je naopak vyžaduje. V tuto chvíli bude znaková sada původního u změněna na rozšířenou dle konfigurace aplikace. Bude možné také tuto změnu potlačit a naopak přidávaný podpis bude překódován do standardní znakové sady USASCII. 5 PKI je Public Key Infrastructure je prostředí, které umožňuje ochranu informačních systémů, elektronických transakcí a komunikace. Zahrnuje veškerý software, technologie a služby, které umožňují využití šifrování s veřejným a privátním klíčem. 6 RFC je zkratka anglického výrazu request for comments (žádost o komentáře), která se používá pro označení řady standardů a dalších dokumentů popisujících Internetové protokoly, systémy apod 7

15 Analýza a návrh řešení 2.4 SCHÉMA NAVRHOVANÉ APLIKACE Aplikace je rozdělena do dvou základních částí, které dohromady zajišťují potřebnou funkčnost celého systému. Výsledná aplikace je tvořena dynamicky linkovanou knihovnou 7 (DLL), která poskytuje předepsané rozhraní pro zpracování u při průchodu službou SMTP serveru. Dále systém obsahuje konfigurační soubory (vzory podpisů) a konfiguraci tvořenou administračním rozhraním (součástí této práce je pouze návrh uživatelského rozhraní pro administrační aplikaci). Obrázek 1 konceptuální schéma aplikace 2.5 ÚLOŽIŠTĚ KONFIGURACE A KONFIGURAČNÍ SOUBORY Návrh konfiguračního úložiště vychází ze standardního prostředí Microsoft Windows a potřeb aplikace. Konfigurace aplikace obsahuje dvě části rozdílné svou povahou, proto tuto situaci návrh respektuje a využívá dvě odlišné metody pro uložení jednotlivých částí konfigurace. 7 DLL funkční logický celek, který poskytuje služby pro programy. Většinou se jedná o sbírku procedur, funkcí a datových typů, či při objektově orientovaném přístupu o sadu tříd, uložených v jednom diskovém souboru. Knihovna poskytuje aplikační programátorské rozhraní (zvané API), které umožňuje programu volat funkce poskytované touto knihovnou. 8

16 Analýza a návrh řešení Pro uložení konfiguračních parametrů je použit systémový registr 8, kde jsou jednotlivé parametry uloženy a čteny pomocí systémových volání operačního systému. Dále je zde využito možnosti kontroly změny konfigurace za běhu programu, aby nebylo nutné při každé změně konfigurace administrátorem restartovat služby poštovního systému a nebyla změna konfigurace vázána na množství administrativních úkonů případně odstávek systému. Tato kontrola se děje také pomocí registrace k odběru události o změně patřičného klíče v systémovém registru. V případě, že k takovéto změně dojde, aplikace si sama přečte novou konfiguraci a provede potřebné inicializace. Toto řešení je využito zejména pro jeho malou náročnost na zatížení systému oproti běžnému řešení, kde je konfigurace načítána pokaždé před jejím použitím. Druhou částí jsou vzory pro podpis ve dvou základních formátech. Pro tyto vzory jsou využity konfigurační soubory, které se při spuštění aplikace načtou do vnitřních struktur aplikace operační paměti. Tato je zejména kvůli rychlejšímu přístupu k informacím a nižší zátěži diskového subsystému poštovního serveru. Při inicializaci se také vytvoří seznam dynamických atributů, které představují doplňované informace z Active directrory. Tyto vzory je možné aktualizovat za běhu aplikace bez nutnosti restartu poštovního systému, k tomu je využito hlídání událostí v klíčích aplikace v systémovém registru. Pro správnou funkčnost je nutné, aby při změně vzoru podpisu došlo ke změněně některého z klíčů aplikace v systémovém registru. Toto musí zajistit konfigurační aplikace, která bude udržovat číslování verzí konfigurace a při změně vzoru upraví verzi souboru v registru. V případě provozu bez konfigurační aplikace musí tento krok provést administrátor a verzi konfigurace změnit v systémovém registru ručně. 2.6 NÁVRH UŽIVATELSKÉHO ROZHRANÍ PRO ADMINISTRACI A KONFIGURACI Nástroj pro konfiguraci aplikace MailSign bude sloužit administrátorům pro změnu a nastavení všech modifikovatelných parametrů aplikace. Dále by měl umožňovat vytvářet a editovat vzory podpisů v obou používaných formátech. Na základě těchto požadavků byl vytvořen návrh grafického rozhraní, zpracovaný v Microsoft Office Visio 2007 uvedený v následujících screenshotech.potom bude potřeba implementovat zápisy konfiguračních parametrů do systémového registru, registraci knihovny MailSign a registraci do jímky událostí. 8 Systémový registr 9

17 Analýza a návrh řešení Obrázek 2 uživatelské rozraní editace vzorů Obrázek 3 Uživatelské rozraní editace parametrů 10

18 Realizace 3 R e a l i z a c e Funkčnost vytvářené aplikace byla rozdělena na 5 částí, kde každá zajišťuje specifické funkce. Základní částí je vlastní dll knihovna (MailSign), která aplikaci zapouzdřuje a poskytuje operačnímu systému dvě procedury na registraci a odregistraci knihovny dll. Také obsahuje rozhraní pro třídu Sink, která je použita při vlastní komunikaci s Exchange (SMTP) serverem. Tato používá knihovnu Active Template Library 9, která je součástí vývojového prostředí Microsoft Visual Studio 2008 professional a výrazně zjednodušuje práci s COM objekty. Při komunikaci s Exchange serverem je ještě využívána sada objektů CDO 10. Jelikož aplikace pouze doplňuje funkci poštovního sytému, byl při vývoji dáván důraz na ošetření chybových stavů, aby nedocházelo k pádům celého poštovního sytému. Aplikace se dá změnou konfigurace jednoduše testovat a také rychlým zásahem vypnout či pozastavit její činnost, tak aby ový provoz nebyl ohrožen. Byla snaha co nejvíce ošetřit vnitřní chybové stavy tak, aby v případě vzniku kritické chyby, která by mohla způsobit pád systému (např. nefunkční konfigurace), je tato chyba pouze zapsána do logu a vlastní podepisovaný je propuštěn beze změn. Aplikace je kompilována pro jedno vláknové zpracování s předpokladem, že v budoucí verzi bude plně doplněna o synchronizační mechanizmy a Exchange server mohl plně využít paralelní zpracování odchozích ů. Některé části kódu již mají implementovány synchronizační mechanizmy pomocí kritických sekcí. 9 ATL - The Active Template Library je sada vzorů založena na C++ třídách vyvinuta společností Microsoft, která zjednodušuje programování Component Object Model (COM) objektů. 10 CDO - Collaboration Data Objects pro Microsoft Windows 2000 (Cdosys.dll) implementuje verzi 2.0 Collaboration Data Objects API specifikace, je to Component Object Model (COM) pro jednoduchý vývoj programů, které vytváření, nebo manipulují s y 11

19 Realizace 3.1 POPIS IMPLEMENTOVANÝCH TŘÍD Class Sink Obrázek 4 Deklarace třídy Sink Třída Sink je klíčovou třídou při komunikaci se SMTP serverem. Jelikož implementuje předepsané rozhraní, obsahuje potřebné funkce, které toto rozhraní vyžaduje. Z pohledu vývoje aplikace jsou klíčové dvě funkce. Jednou z nich je Load, která je volána při zavedení knihovny do paměti. Tato funkce inicializuje všechny potřebné objekty. Hlavní funkcí třídy sink je implementace funkce OnArrival, která je volána dispečerem exchange serveru na základě registrace knihovny v jímce událostí. Při návrhu jsem volil mezi implementací již zmíněné funkce OnArrival a nebo funkce OnMessageSubmission. Obě mají v serveru Exchange 2003 stejný význam. Mnou vybraná má výhodu v možnosti širšího využití, jelikož je také využívána smtp serverem integrovaným přímo v operačním systému Windows XP, Windows 2000 a také v Exchange serveru 2000, takže aplikace je funkční i na těchto platformách a nevyžaduje přímo Exchange server Nicméně na základě zadání proběhlo ladění a testování na požadované platformě Exchange server Kompletní funkčnost aplikace bez otestování na ostatních platformách není možné garantovat. 12

20 Realizace Funkce OnArrival analyzuje a dle konfiguračních parametrů jej doplní podpisem, který jí poskytuje třída sing. Pro kontrolu předmětu z důvodů duplicitních podpisů uvedených v části návrhu je využívána pomocná funkce TestSubjOk Class Sign Obrázek 5 Deklarace třídy Sign V této třídě je zahrnuta logika související se získáním podpisů na základě vzorů podpisu. Opět se dají funkce této třídy rozdělit do dvou kategorií. První část se stará o vytvoření všech potřebných objektů, načtení konfigurace a vzorů podpisu ve dvou, v tuto chvíli implementovaných, formátech (HTML, TXT). Z důvodů snížení provozní zátěže diskového subsystému se konfigurace včetně vzorů načte do paměti, kde zůstává po celou dobu života třídy. Před použitím podpisu se pouze testuje verze konfigurace a při její změně se provede reinicializace všech proměnných. Toto řešení umožňuje měnit chování aplikace za chodu a nevyžaduje při těchto změnách restarty příslušných služeb poštovního systému. Vzory podpisů jsou načteny jako dva oddělené spojové seznamy. Vzorový soubor je rozdělen na části oddělovačem atributů (zvojené %%), kde obsah je uložen v jednom spojovém seznamu a zástupné identifikátory v seznamu atributů. Do provozní části spadá funkce GetSign, která zajišťuje vytvoření personifikovaného podpisu na základě ové adresy a dotazu do Active Directory, který vrací do třídy sink. Celý proces sestavování podpisu probíhá procházením obou spojových seznamů, přičemž jednotlivé zástupné identifikátory jsou nahrazovány dle získaných informací z Active Directory 13

21 Realizace Class ADConnector Obrázek 6 Deklarace třídy ADConnector Pro komunikaci s Active Directory.se využívá třída ADConnector Obsahuje pouze konstruktor, destruktor, funkci pro získání vlastních informací z AD a pomocnou funkci pro ošetření chybových stavů. Funkce GetAttrSet obsahuje vstupně-výstupní parametr, třídu map ze standard template library. Tato mapa obsahuje seznam jmen jednotlivých atributů, které je potřeba doplnit hodnotou na základě ové adresy. Při zpracování se nejprve funkce připojí do AD, vytvoří si LDAP dotaz na základě seznamu požadovaných atributů a nechá dotaz vyhodnotit. Výsledek dotazu je zpracován a hodnoty atributů jsou přidány do mapy, která je vrácena, resp. její ukazatel, volající části. 14

22 Realizace Class RegConfig Obrázek 7 Deklarace třídy RegConfig Třída RegConfig je využívána ve všech ostatních částech aplikace. Slouží jako vnitřní rozhraní pro získání konfigurace ze systémového registru. Kromě funkcí pro získání jednotlivých konfiguračních parametrů obsahuje také funkci pro kontrolu změny parametrů. 15

23 Realizace Tato funkce je důležitá pří změně konfigurace, aby aplikace byla schopná za běhu měnit své chování dle změn administrátora a nebyl vyžadován restart celého poštovního systému. Pro tuto kontrolu využívá zaregistrování události změny patřičného klíče systémového registru v operačním systému. Je testován pouze zaregistrovaný objekt a nemusí se cyklickými dotazy do systémového registru při každém čtení některého z parametrů zatěžovat celý systém Class Log Obrázek 8 Deklarace třídy Log Třída Log je pomocnou třídou a také se používá v celé aplikaci. Jejím jediným posláním je zápis událostí a chyb do systémového a souborového logu. Obsahuje jednu funkci a pro svou činnost vyžaduje instanci třídy RegConfig, pomocí které získává parametry logování (rozsah a umístění log souboru). 3.2 POZNÁMKY K PŘEKLADU APLIKACE Vývojové prostředí a překlad aplikace Jako vývojové prostředí bylo využíváno Microsoft Visual Studio 2008 Professional, které poskytuje všechny potřebné nástroje pro vývoj tohoto typu aplikace. Aplikace využívá několik třídy z Microsoft Foundation Class Library 11, Active Template Library a.net. Dále jsou využívané některé systémové volání operačního systému. Všechny tyto knihovny jsou dostupné v distribuci vývojového prostředí a Windows SDK 12 verze 6A. Pro vytvoření ATL projektu v Microsoft Visual Studiu byly využity informace z webu Microsoft MSDN(1) Pro překlad knihovny MailSign byla zvolena znaková sada Unicode a také použití ATL se statickým linkováním a používání STL. Statické linkování knihoven je produkuje větší výslednou knihovnu MailSign, ale zajišťuje nezávislost na ostatních částech operačního systému. 11 MFC - Microsoft Foundation Class Library (také Microsoft Foundation Classes) je knihovna, která zabaluje část Windows API v C++ třídách, zahrnující funkcionalitu umožňující používat výchozí aplikační framework. 12 SDK - software development kit je typicky sada vývojových nástrojů, která umožňuje softwarovým inženýrům vytvářet aplikace, softwarové balíčky, softwarové frameworky, hardwarové platformy, počítačové systémy, herní konsole, operační systémy, nebo podobné platformy. 16

24 3.2.2 Ladění aplikace Realizace Ladění aplikace probíhalo na dálku pomocí Remote debuggeru, který je součástí vývojového prostředí Visual Studio Pro tento způsob je nutné na serveru, kde běží aplikace MailSign spustit Visual Studio Remote Debugging Monitor a nastavit režim ověřování. V mém testovacím prostředí jsem používal režim bez ověřování. Jelikož není aplikace MailSign samostatně spustitelná je nutné se při ladění kódu vzdáleně připojit na proces Internet Information Serveru, který se jmenuje inetinfo.exe. Po připojení k tomuto procesu je možné postupovat běžným způsobem. Po nastavení breakpointů v našem kódu a vyvolání události onarrival posláním u přes SMTP server. 17

25 Testování 4 T e s t o v á n í 4.1 KONFIGURACE TESTOVACÍHO PROSTŘEDÍ Pro testování a vývoj bylo využito Virtuální prostředí společnosti VMware Workstation Vlastní provoz však není na tomto prostředí závislý. Systém je možné provozovat jak ve fyzické tak v jiné virtualizační platformě, která umožňuje provoz operačního serveru Microsoft Windows 2003 server Instalace Microsoft Windows2003 serveru standard edition Pro instalaci a provoz operačního systému Windows 2003 serveru je vyžadován hardware specifikovaný v následující tabulce. Tabulka 1 Systémové požadavky(2) Hodnota Mimimální Doporučená Požadavek Rychlost procesoru 133 MHz 550 MHz Velikost paměti RAM 128 MB 256 MB Volné místo na disku 1,5 GB 10 GB Pro testovací provoz a ladění aplikace byl virtuální server nakonfigurován tímto způsobem: 512 GB RAM 8 GB disk 1 procesor Intel Core 2 duo T9300, 2.5 GHz Operační systém byl instalován v anglické jazykové mutaci standardním způsobem. Během instalace bylo navíc zvoleno české národní prostředí, aby bylo možné otestovat správnost aplikace včetně českých znaků. Dále byl nainstalován servisní balíček service pack 2 a provedena kompletní aktualizace systému pomocí Windows update k Instalace Active directory a DNS služeb Pro provoz Exchange serveru je nutný řadič Active directory a DNS server. V našem případě jsou všechny tyto role na jednom serveru spolu s Exchange. Tato instalace byla provedena pomocí průvodce konfigurací serveru a přidáním patřičných rolí.(3) 18

26 Testování Název domény AD pro testování byl zvolen salajka.local Instalace IIS Chod Exchange serveru dále vyžaduje některé z komponent Internet Information serveru. Pomocí průvodce konfigurací serveru byla doplněna role aplikačního serveru s těmito komponentami operačního systému(4):.net Framework ASP.NET Internet Information Services (IIS) World Wide Web Publishing Service Simple Mail Transfer Protocol (SMTP) service Network News Transfer Protocol (NNTP) service Instalace Microsoft Exchange 2003 serveru standard edition Exchange server 2003 má také definovány minimální a doporučené požadavky na hardware, které jsou shrnuty v následující tabulce. Tabulka 2 Systémové požadavky(5) Hodnota Mimimální Doporučená Požadavek Rychlost procesoru 133 MHz 550 MHz Velikost paměti RAM 128 MB 512 MB Volné místo na disku (závislé dle množství dat) 700 MB 2 GB Instalace Exchange serveru 2003 se skládá z několika základních kroků: 1. Příprava lesa Active directory pomocí programu setup.exe /forestprep z instalačního CD Exchange serveru(6) 2. Příprava domény Active directory pomocí programu setup.exe /domainprep z instalačního CD Exchange serveru(7) 3. Instalace vlastního exchange serveru a vytvoření nové Exchange organizace(8) 4. Instalace servisního balíčku Service pack 2(9) 5. Instalace dalších dostupných aktualizací pomocí služby Microsoft update 19

27 4.1.5 Instalace a konfigurace Microsoft Outlook 2003 Testování Pro testování byla nainstalována a nakonfigurována aplikace Microsoft Outlook 2003, která je součástí Microsoft Exchange server Pro testovací účely byla zvolena česká jazyková mutace, aby se testovací prostředí nejvíce blížilo budoucímu nasazení. Opět byl nainstalován poslední dostupný servisní balíček Service pack 3 a další aktualizace vydané společností Microsoft k V poslední fázi byl nastaven profil outlooku tak, aby používal připravený exchange server a byla otestována komunikace s exchange serverem pomocí testovacích ů Konfigurace SMTP v testovacím prostředí Po instalaci Exchange serveru je vytvořen jeden základní virtuální SMTP server pomocí kterého Exchange komunikuje s ostatními poštovními systémy. Tento SMTP server je používán jak pro odchozí tak pro příchozí poštu. Pro základní funkci aplikace je možné použít tento jeden smtp server, který již vytvořila instalace Exchange serveru. Při testech aplikace bylo zjištěno, že přes událost onarrival neprochází všechny odesílané y. y zaslané pomocí OWA 13 (Outlook Web Acces interface) nejsou v jímce událostí zachyceny a y zaslané pomocí MAPI 14 rozhraní nemohou být při události onarrival modifikovány. Toto zjištění bylo následně potvrzeno v dokumentech popsaných společností Microsoft(10). Na základě tohoto zjištění byl upraven původní návrh a pro odchozí y je vytvořen druhý SMTP server ve funkci tzv. SMART hosta. V původním návrhu aplikace byla tato varianta zmíněna z důvodů možného oddělení exchange serveru a serveru pro podepisování. Na základě výše uvedených zjištění je toto oddělení SMTP serverů pro správnou funkci aplikace nutné. Jelikož Microsoft Windows umožňuje provozovat více virtuálních SMTP serverů v jednom operačním systému, je využito této konfigurace, aniž by byla potřeba dalšího operačního systému. 13 OWA Outlook Web Access, původně nazýván Exchange Web Connect (EWC), je a webová poštovní služba Microsoft Exchange Server 5.0 a novějších. 14 MAPI - Messaging Application Programming Interface (MAPI) je poštovní architektura a COM rozhraní založené na aplikačním programovém rozhraní pro Microsoft Windows 20

28 Testování Obrázek 9 Schéma SMTP konfigurace Tento druhý pomocný SMTP server je nakonfigurován pomocí Microsoft Exchange system manageru ve větvi Organization\Servers\Myserver\Protocols\SMTP, kde je přidán další virtuální SMTP server. Je potřeba změnit standardní TCP port 25 na jiný volný port (např. 26), povolíme relay pro sama sebe. V dalším kroku je nutné nastavit port pro odchozí provoz základního virtuálního smtp serveru na port 26 a také IP adresu smart hosta. Pro inicializaci všech provedených změn je nutné restartovat SMTP službu příkazem iisreset z příkazového řádku a otestovat konfiguraci zasláním testovacího u Instalace aplikace MailSign v testovacím prostředí Instalace a konfigurace je popsána v kapitole 5 aplikační dokumentace s těmito konfiguračními parametry uvedenými ve formátu reg souboru: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Autocont] [HKEY_LOCAL_MACHINE\SOFTWARE\Autocont\MailSign] "Enabled"=dword: "LdapContainer"="DC=salajka,DC=local" "LdapUser"="administrator@salajka.local" "HtmlFileName"="C:\\mailsign\\sign.htm" "TextFileName"="C:\\mailsign\\sign.txt" "Test "="administrator@salajka.local" "LdapSubTree"=dword:

29 Testování "LogFile"="" "LdapPassword"=hex:c0,44,41,57,62,38,36,38,68,65,55,3e,73,7d,47,2e,6c,39,3c,68,\ 5c,40,33,79,6f,5e,6c,3a,4f,4f,58,28,69,4c,40,00 "EventLogLevel"=dword: "FileLogLevel"=dword: "Testing"=dword: "ConfigSerialNumb"=dword: "ConvCharSet"="iso " "ConvertUSACIICharSet"=dword: "ExcudedSubject"="RE:;FW:" Pozn: Aplikace vyžaduje nainstalovaný.net Framework 1.x. Tento framework je vyžadován již k instalaci Exchange server, takže není potřeba ho instalovat samostatně 4.2 ZPŮSOB, PRŮBĚH A VÝSLEDKY TESTOVÁNÍ Základní testování probíhalo přímo při vývoji jednotlivých částí aplikace. Pro testování a ladění částí týkajících se konfiguračních parametrů a komunikace s active directory byla vytvořena jednoduchá pomocná aplikace AdReader, která umožňuje využít pro ladění většinu funkcí programu bez potřeby využívat Exchange server. Tímto se vývoj a ladění zjednodušilo a umožnilo zpracovávat projekt postupně ve dvou na sobě nezávislých částech. Jedna zabývající se vytvořením podpisu na základě vzorů a dotazů do Active directory a druhá týkající se implementace rozhraní komunikující s Exchange serverem. V závěru byly pak tyto části spojeny a testovány společně. Před finalizací práce bylo provedeno testování podepisování ů různých typů formátů a kódování, aby se prověřila nezávislost na typu obsahu. Také bylo použito několik druhů podpisu využití zástupných znaků v různých částech podpisu včetně nesprávných identifikátorů a podobně. Na závěr byl udělán výkonový test se zaznamenáváním vytížení paměti a procesorů, který by měl prověřit zpracování větším objemu ů a dopad aplikace na zatížení procesoru. Reálné testování proběhne před nasazením do ostrého provozu. Aplikace umožňuje přepnutí do testovacího režimu z důvodů kontroly vzorů podpisu a také pro kontrolu funkčnosti. Tímto způsobem je možné nechat si doručovat kopii ů do testovací schránky a kontrolovat dopad na výslednou zprávu. V tomto režimu je dobré aktivovat jímku událostí pouze na část odchozích ů pomocí omezující podmínky, kterou jímka událostí obsahuje. Tato podmínka sníží v testovacím provozu riziko, v případě poruchy či nefunkčnosti aplikace a jejího negativního dopadu na chod zavádějící organizace Finální testování Pro tento účel bylo použito několik vzorových ů, které byly použity jako základ pro generování do celkového počtu Tyto y byly odeslány pomocí SMTP serveru dvakrát, jednou bez aktivované aplikace MailSign, při zaznamenávání zátěže procesoru a paměti a diskové fronty. Podruhé byla při odesílání stejného množství ů aktivována 22

30 Testování aplikace MailSign a opět byla zaznamenávána zátěž. Tento test je pouze orientační, jelikož neproběhl na vyhrazených hw strojích s konstantními parametry (byl proveden ve virtuálním prostředí), mohl být ovlivněn aktuální rychlostí připojení do internetu při odesílání ů a také možným rozdílem požadavků hostujícího operačního systému a jeho běžících aplikací při jednotlivých testech Výsledky testu V testu byla ověřena funkčnost aplikace při větším zatížení a také byly zaznamenány výkonové požadavky na vlastní proces podepisování ů. Z analýzy následujících grafů se potvrdily předpoklady o vyšším zatížení procesoru oproti zpracování stejného objemu zpráv bez podepisování. Tato zátěž je vidět na začátku druhého grafu, kde se zvýšilo okamžité vytížení procesoru o zhruba 20%, a prodloužila se úvodní doba zpracování ové fronty ze 45 sekund na 1 minutu 20 sekund 15. Zbývající část grafu se v obou případech neodlišuje a je dána odesíláním již připravených zpráv ve frontě na cílový SMTP server. Na základě tohoto testu je možné konstatovat, že nasazením aplikace MailSign neomezíme celkový provoz poštovního serveru při běžném zatížení v malé a střední organizaci a je možné ho provozovat i v organizaci s větším poštovním provozem. Obrázek 10 Graf zatížení serveru při odesílání cca ů bez použití aplikace MailSign 15 Uvedené grafy neobsahují přesné časové měřítko, časové údaje byly zjištěny z grafického rozhraní Microsoft Management Console pro sledování výkonu. 23

31 Testování Obrázek 11 Graf zatížení serveru při odesílání cca ů s použitím aplikace MailSign 4.3 SROVNÁNÍ S EXISTUJÍCÍMI ŘEŠENÍMI, POKUD JSOU ZNÁMY Na trhu byl nalezen komerční produkt Mail Signature Manager(11) společnosti Symprex sídlící v Londýně. Řešení této společnosti nabízí uživatelům a administrátorům komfortní komplexní řešení jednotných podpisů v ech. Díky zpracování podpisu již v klientské ové aplikaci nabízí vetší funkčnost, ale také náročnější údržbu celého systému. Pro distribuci vzorů podpisů je nutné zajistit pravidelné spouštění úlohy replikující konfiguraci na všech klientských počítačích, což je v dnešní době díky stále se zvětšujícím možnostem mobilních zařízení problematičtější. Protikladem takovému robustnímu řešení je implementace realizovaná v této bakalářské práci, které je jednoduchá na údržbu i kontrolu bez rizika množení problémů způsobovaných rozmanitostí náročnou údržbou koncových zařízení s poštovními klientskými aplikacemi. Vzhledem k jednoduchosti aplikace MailSign je možné předpokládat, že i náklady na následný support dané životním cyklem aplikace budou oproti řešení společnosti Symprex nižší a tím i případná cena řešení a podpory MailSign může být pro případné zákazníky nižší. 24

32 Aplikační dokumentace 5 A p l i k a č n í d o k u m e n t a c e Aplikace slouží pro doplňování podpisů a případných právních omezení do odchozích ů pro Exchange server Doplňované informace mohou být dynamicky modifikovány na základě informací z Active directory dle ové adresy odesílatele. 5.1 INSTALACE Instalace aplikace spočívá ve třech krocích. Zápis konfiguračních parametrů do registru, registrace knihovny mailsign.dll a aktivace jímky událostí. Aplikace se instaluje na funkční SMTP server, který je používán pro odchozí ovou komunikaci Exchange Serveru Systémové požadavky Aplikace pro svůj běh vyžaduje knihovny.net framework 16 verze 1.x. Za předpokladu, že je na serveru nainstalován Exchange Server 2003 včetně OWA je již toto zajištěno Konfigurace SMTP Pro správný chod aplikace je potřeba zajistit tok všech ů přes jeden smtp server. Tohoto lze nejsnáze dosáhnout pomocí konfigurace tzv. smart hosta a nasměrovat na něj všechen odchozí provoz z Exchange serveru. Tato konfigurace má také výhodu v možnosti oddělení zátěže produkované vlastním podepisováním a provozu Exchange serveru. Pro organizaci s menším ovým provozem je možné konfigurovat takovýto smtp server na stejném serveru, jen na jiném TCP portu Instalace aplikace Pro aplikaci doporučuji vytvořit samostatný adresář např. C:\Program files\mailsign, do něj nakopírovat knihovnu mailsign.dll a podpůrné soubory. Pro soubory s předlohami podpisu a log soubor je vhodné vytvořit podadresář z důvodu oddělení uživatelských oprávnění. Import konfiguračních parametrů do registru pomocí systémové utility regedit. Tato je součástí operačního systému a nachází se v adresáři %SystemRoot%\system32\ (zpravidla C:\widows\system32\). Jako parametr se dává název souboru typu reg, kde jsou vypsány všechny konfigurační parametry aplikace. Tyto parametry je možné do systémového registru zadat ručně pomocí grafického rozhraní utility regedit. Všechny parametry jsou podrobně popsány v kapitole Příklad zapsání parametrů do registru 16 Microsoft.NET Framework je softwarový framework který je dostupný s některými verzemi operačních systémů Microsoft Windows 25

33 Aplikační dokumentace %SystemRoot%\regedit.exe c:\mailsign\mailsign.reg Zaregistrování aplikace (dll knihovna) v operačním systému se provede pomocí utility regsrv32.exe. Tato je součástí operačního systému a nachází se v adresáři %SystemRoot%\system32\ (zpravidla C:\widows\system32\). Jako parametr se dává název knihovny dll včetně cesty k ní. Registrace: %SystemRoot%\system32\regsrv32.exe c:\mailsign\mailsign.dll Odregistrování (před odregistrováním je potřeba aplikaci deaktivovat zrušit aktivaci jímky událostí): %SystemRoot%\system32\regsrv32.exe u c:\mailsign\mailsign.dll Aktivace Event Sink Pro aktivaci jímky událostí a registraci odběru je využíván skript smtpreg.vbs společnosti Microsoft. Je k dispozici na www stránkách společnosti microsoft: Tento skript má několik parametrů, pro registraci je potřeba specifikovat id virtuálního SMTP serveru, dále typ události (v našem případě onarrival) dále textový název konkrétní registrace události a název události třídy sink v knihovně dll. Také je potřeba specifikovat podmínku, na které y se má tato událost aplikovat (pro naše využití je požadavek aplikovat podpis na všechny odchozí y). Tuto podmínku je možné změnit před nasazením do ostrého provozu na specifikaci pouze určitých testovacích zpráv, aby nedošlo při špatné konfiguraci k ohrožení provozu organizace. Aktivace: %SystemRoot%\system32\cscript.exe c:\mailsign\smtpreg.vbs /add 2 onarrival AC_MailSign mailsign.sink mail from=* Deaktivace (po deaktivaci je vhodné provést restart SMTP služeb pro uvolnění systémových prostředků např. příkazem IISRESET): %SystemRoot%\system32\cscript.exe c:\mailsign\smtpreg.vbs /remove 2 OnArrival AC_MailSign Příklad dávkového souboru pro registraci a aktivování knihovny off If "%1"=="/?" goto help If "%1"=="" goto help %SystemRoot%\regedit.exe /s %1\mailsign.reg %SystemRoot%\system32\regsvr32.exe -s %1\mailsign.dll %SystemRoot%\system32\cscript.exe %1\smtpreg.vbs /add %2 onarrival AC_MailSign mailsign.sink "mail from=*" goto end :help echo davka registruje knihovnu MailSign.dll a aktivuje jimku udalosti 26

34 echo pouziti: echo %0 'adresar s instalovanou aplikaci MailSign' 'cislo virtualniho SMTP serveru' :end Aplikační dokumentace Příklad dávkového souboru pro deaktivování a odregistraci knihovny off If "%1"=="/?" goto help If "%1"=="" goto help %SystemRoot%\system32\cscript.exe %1\smtpreg.vbs /remove %2 OnArrival SignSink %SystemRoot%\system32\regsvr32.exe -s -u %1\mailsign.dll goto end :help echo davka registruje knihovnu MailSign.dll a aktivuje jimku udalosti echo pouziti: echo %0 'adresar s instalovanou aplikaci MailSign' 'cislo virtualniho SMTP serveru' :end 5.2 PARAMETRY APLIKACE Pro správný chod aplikace je potřeba nastavit několik parametrů v systémovém registru. Parametry musejí být umístěny v klíči "HKLM\Software\Autocont\MailSign\" Popis parametrů Všechny parametry v následující tabulce Tabulka 3 Popis parametrů Název klíče Typ klíče Výchozí hodnota (je použita v případě, že klíč neexistuje) Popis "Testing" REG_DWORD 0 Zakazuje/Povoluje zasílání kopie modifikovaného u pro testování vzorů podpisu. "Enabled" REG_DWORD 0 Zakazuje/Povoluje podepisování ů. "LdapSubTree" REG_DWORD 1 Zakazuje/Povoluje prohledávání AD (LDAP) adresáře do hloubky. 27

35 Aplikační dokumentace Název klíče Typ klíče Výchozí hodnota (je použita v případě, že klíč neexistuje) Popis "LdapContainer" REG_SZ "" Název kontejneru v AD, kde bude probíhat hledání objektu, např. DC=autocont,DC=cz. "LdapUser" REG_SZ "" Uživatelské jméno pro přístup do AD adresáře, např. user@autocont.cz. "LdapPassword" REG_BINARY "" Heslo uživatele pro přístup do AD v kryptované podobě 17. "HtmlFileName" REG_SZ "" Jméno souboru se vzorem html podpisu včetně plné cesty 18. "TextFileName" REG_SZ "" Jméno souboru se vzorem textového podpisu včetně plné cesty. "Test " REG_SZ "" ová adresa uživatele pro testování na kterou je možné doručovat kopie podepsaných ů. Adresa může být pouze jedna. "LogFile" REG_SZ "" Jméno log souboru včetně plné cesty, kde systém zapisuje události a případné chyby aplikace. "FileLogLevel" REG_DWORD 0 Úroveň logování do souboru v rozmezí 0-6 (0 minimální, 6 detailní) Pro získání kryptovaného hesla slouží pomocná řádková utilita dodávaná spolu s aplikací 18 Soubory jsou kódovány ve znakové sadě nastavené v operačním systému. 19 Maximální logování může degradovat výkon poštovního serveru 28

36 Aplikační dokumentace Název klíče Typ klíče Výchozí hodnota (je použita v případě, že klíč neexistuje) Popis "EventLogLevel" REG_DWORD 0 Úroveň logování do aplikačního event logu operačního systému v rozmezí 0-6 (0 minimální, 6 detailní). "ConvertUSACIICharSet" REG_DWORD 0 Povolí v případě potřeby konverzi znakové sady podepisovaného u "ConvCharSet" REG_SZ "iso " Znakové sada použitá v případě nutnosti konverze podepisovaného u 20 "ExcudedSubject" "" Seznam prefixů předmětu ů, které budou vyloučeny z podepisování oddělené středníkem (velká malá písmena nerozhodují). Např. RE:;FW: "ConfigSerialNumb" REG_DWORD 0 Sériové číslo verze konfigurace. V případě změny této položky se provede aktualizace konfigurace v paměti (pro změnu konfigurace není třeba restart SMTP serveru) Příklad REG souboru Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Autocont] [HKEY_LOCAL_MACHINE\SOFTWARE\Autocont\MailSign] "Enabled"=dword: "LdapContainer"="DC=autocont,DC=cz" "LdapSubTree"=dword: Nastává v případě, že podepisovaný je formátován ve znakové sadě US ASCII a podpis vyžaduje znaky, které tato sada neobsahuje 29

37 Aplikační dokumentace "LdapPassword"=hex:4d,2d,41,6a,62,72,43,66,61,6f,6b,61,61,2b,48,31,77,3f,33,63,64,38,61,73, 66,62,79,79,5c,3b,72,5c,61,32,95,50 "HtmlFileName"="C:\\MailSign\\data\\sign.htm" "TextFileName"="C:\\MailSign\\data\\sign.txt" "Testing"=dword: "EventLogLevel"=dword: "LogFile"=" C:\\MailSign\\data\\mailsign.log" "FileLogLevel"=dword: "ConvertUSACIICharSet"=dword: "ConvCharSet"="iso " "ExcudedSubject"="FW:;RE:" "ConfigSerialNumb"=dword: UTILITA CRYPTPASSWORD Pro zvýšení bezpečnosti není uloženo heslo uživatele pro přístup do active directory v systémovém registru jako čitelný text. Pro vygenerování zakódovaného hesla se používá řádková utilita CryptPassword.exe jež je součástí celé aplikace. Jako parametr se vkládá reálné heslo (délka hesla je omezena na 24 znaků) a výstupem je série hexadecimálních číslic oddělených čárkou, které je potřeba uložit do registru. Pro zápis do registru je možné použít reg soubor, kde se heslo vyskytuje ve stejném formátu. Zvolená šifra je reverzibilní a slouží pouze k znesnadnění přečtení hesla běžným uživatelem. Z těchto důvodů je doporučeno vytvořit pro tyto účely dedikovaný účet s omezenými oprávněními, které umožní pouze prohledávání a čtení potřebných atributů z AD. 5.4 VZORY PODPISŮ Aplikace zpracovává dva různé soubory vzorů podpisů, jeden pro y ve formátu prostého textu a druhý pro y formátu html. y ve formátu rtf (rich text format) jsou implicitně přeformátovávány do formátu html. Pro dynamické nahrazení textu dle údajů v active directory se do vzoru podpisu umístí název atributu uzavřený do dvojitých %% (například. %%company%%). Při podepisování zprávy formátu HTML je vkládána do zprávy pouze část <body> HTML kódu. Na toto omezení je potřeba pamatovat při vytváření podpisu, na druhou stranu toto řešení umožňuje používat pro editaci vzorů podpisu běžné HTML editory. Dále není možné používat vložené obrázky, které by měli být přímo součástí zprávy. Tyto obrázky nejsou do zprávy načítány. Pro kódování souborů vzorů podpisu je nutné využít znakové sady nastavené v operačním systému. Znaková sada uvedená v hlavičce HTML se nebere v potaz. 30

38 Aplikační dokumentace Příklad vzoru podpisu ve formátu prostý text %%title%% %%givenname%% %%sn%% Oddělení: %%department%% Telefon: %%telephonenumber%% %%company%% %%co%% Příklad vzoru podpisu ve formátu HTML <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " <html xmlns=" <head> <meta http-equiv="content-language" content="cs" /> <meta http-equiv="content-type" content="text/html; charset=windows-1250" /> <title>untitled 1</title> </head> <body> <FONT size=2> <p>%%title%% %%givenname%% %%sn%%</p> Oddělení: %%department%%<br> Telefon: %%telephonenumber%%<br> %%company%%<br> %%co%%<br> </FONT> </body> </html> Příklad podepsané zprávy V následujících screen shotech je vidět jakým způsobem ovlivňuje aplikace zaslanou zprávu a doplní podpis v obou používaných formátech. 31

39 Aplikační dokumentace Obrázek 12 Původní zpráva ve formátu prostý text Obrázek 13 Podepsaná zpráva ve formátu prostý text 32

40 Aplikační dokumentace Obrázek 14 podepsaná zpráva ve formátu HTML Atributy Active directory(13) V následující tabulce je výběr atributů objektu uživatel z Active Directory, které je možné použít do vzorů podpisu. Tabulka 4 Používané atributy uživatele Jméno atributu AD Význam Zástupný text do souborů vzoru podpisu Additional-Information další %%notes%% informace Address-Home adresa %%homepostaladdress%% domů Assistant Asistent %%assistant%% Comment komentář %%info%% Company společnost %%company%% Country-Name Země %%c%% Department oddělení %%department%% Description popis %%description%% Display-Name-Printable jméno %%displaynameprintable%% Division Divize %%division%% -Addresses %%mail%% Facsimile-Telephone-Number Fax %%facsimiletelephonenumber%% 33