Díl, který by měl být tím závěrečným. Povíme si v něm o tom, co se úplně běžně nenastavuje a mnohdy je to trochu škoda – aneb jak se snadno spojit s jinou organizací, která také používá Domino. Na první pohled není nejmenší důvod – pošta chodí přes internet, tak si všechno pošleme. Ale přitom by bylo krásné, kdyby pošta chodila po speciální Lotus cestě s možností šifrování, kdyby bylo možné replikovat diskuzní databáze pro výměnu dokumentů nebo se podívat panu řediteli se spolupracující firmy do kalendáře při plánování schůzky. To všechno jde a docela snadno.

První věc, kterou pro to musíme udělat, je cross-certifikaci neboli výměna veřejných klíčů. Pokud to neuděláme, tak server druhé organizace nám nebude důvěřovat a nepustí nás k sobě. Takže jak na to? Cesty jsou dvě – buď jim pošleme safe.id a oni ho ocertifikují, nebo si administrátor na každé straně otevře server té druhé strany a udělá certifikaci tím.

Nejdříve to zkusíme pomocí safe.id. Postup je jednoduchý – z menu FileSecurityUser security zvolíme Your Identity a Your certificates a zde tlačítko Other actions a Export Notes ID (Safe copy). Tím dojde k uložení ID, které neobsahuje veřejné privátní klíče a je nepoužitelné, můžeme ho tedy klidně poslat administrátorům druhé strany.

Administrátor zase v administračním klientovi na poslední záložce zvolí CertificationCross certify, vybere certifikát se kterým chce certifikovat na svojí straně (pokud zvolí certifikát serveru tak tím umožní přístup druhé straně pouze na konkrétní server, pokud zvolí organizační certifikát tak kamkoliv v jeho úrovni), potom zvolí safe.id protistrany a v následujícím dialogu ještě jednou vše zkontroluje. Při vší té kontrole hlavně kontroluje registrační server, aby to udělal na tom správném a né na svém lokálním. V poli Subject name může vybrat, zda dovolí přístup celé protistraně nebo jenom ID, ze kterého bylo safe.id vytvořeno (tedy třeba jenom konkrétnímu serveru). Potvrdit a první krok je hotov.

Druhá varianta je bez posílání safe.id. V tom případě si každý administrátor otevře server protistrany a v okamžiku kdy se server otevírá tak vyskočí okno s dotazem na cross-certifikaci. Zde se zvolí tlačítko Advanced a vyskočí stejná tabulka jako před chvílí, ve které se musí změnit registrační server, ID se kterým se bude cross certifikovat a pak už jenom potvrdit.

Tím jsme provedli cross-certifikaci serverů, nyní je potřeba upravit přístupová práva. Takže buď zasáhnout do příslušných server dokumentů nebo skupin a přidat tam, koho je třeba. Server druhé firmy (asi nejlepší řešení), případně i osoby, ale to už pak spíš umožňujeme práci na svém serveru, než že bychom je spojovali na serverové úrovni.

Dalším krokem je nastavení posílání pošty a replikace (udělat to jde totiž najednou). Otevřeme si pohled na dokumenty spojení, vytvoříme nový dokument a když vyplňujeme jméno zdrojového a cílového serveru tak si dáme pozor, abychom pod jmény serveru vyplnili správně i jména domén (ty samozřejmě nemohou být stejné). Nastavíme co vše se má replikovat a kolik mailů se má naráz poslat a je to, počkáme až si server uvědomí novou konfiguraci a pak už můžeme psát email ve tvaru Administrator@Domena2, který půjde na druhou stranu po Lotusové cestě. Přirozeně to vyžaduje otevřený port 1352 na firewallu, ale to je asi jasné.

Teď nastavení toho pohledu do kalendáře lidem z druhé firmy. Vytvoříme nový dokument domény, jako typ vybereme Adjanced domain. Zadáme správné jméno domény druhé firmy a na záložce Calendar information zadáme jméno serveru, se kterým jsme spojeni. Zase chvíli počkáme, než si server uvědomí změnu a když pozvete osobu z druhé firmy na schůzku, tak rovnou při plánování schůzky vidíte, zda má čas.

Chybí poslední věc – nějak nastavit, aby si člověk nemusel pamatovat jména osob z druhé firmy. To vyřeší pomocí Directory Assistance, což je skvělá věc, která bohužel není legálně povolená při používání Express licencí (což jako administrátor musíte vědět, nikde vás to neupozorní :-(().

Cesta je snadná, na serveru se vytvoří nová databáze, která jako šablonu použije šablonu Directory Assistance (která je vidět po zaškrtnutí Show advanced templates). V té vytvoříme nový dokument, vyplníme Domain Name, název firmy a na poslední záložce jméno serveru s Domino Directory a jméno souboru Domino Directory. Nezapomeňte daný řádek povolit v posledním sloupci přepnutím na Yes. Při tvorbě dokumentu je zapotřebí se zamyslet, zda zde zadat jméno serveru druhé firmy, nebo spíš si udělat repliku jejich adresní knihy na vlastní server a uvést zde cestu k „lokální“ replice. Výhoda je jasná – adresace bude rychlejší a bude fungovat i při výpadku internetu nebo druhého serveru.

Zbývá poslední krok, aby Directory Assistance fungovala – v server dokumentu na první záložce je nutné do pole Directory Assistance database name zadat jméno databáze, kterou jsme před chvíli založili a restartovat server (bohužel, poprvé po zadání jména je to nutné, potom při zadávání dalších dokumentů do databáze je to již zbytečné).

A je to – pošta nám chodí Lotus cestou (bez konverze na SMTP poštu), můžeme si navzájem koukat do kalendářů a máme k dispozici adresy všech pracovníků druhé firmy a konečně se nám replikují společné databáze. No není to krása? A pokud jsme správně nastavili bezpečnost, aby k nám mohl pouze druhý server, tak jsme ani nepokazili bezpečnost našeho bezpečného prostředí.

Napiš komentář, díky!

Původně jsem do plánu o čem psát zahrnul i návrh implementace a jaké to může mít výhody a nevýhody a teď, když mě čeká to napsat, tak přemýšlím, co vlastně psát. Tak se necháme překvapit, co z toho vyjde 🙂

Pokud máte jeden server tak je všechno (skoro) jasné. Prostě na něj připojíte uživatele, rozmyslet můžete jedině strukturu certifikátů (osobně jsem pro plochou, tedy Jméno/Organizace, pokud hierarchická nebude mít nějaký zvláštní smysl), vymyslet jak odesílat poštu do internetu (přímo nebo přes relay, kde relay odlehčí serveru, ale při posílání napřímo vidíte, kde jsou problémy s odesíláním) a jak ji přijímat (zase přes nějakou relay nebo přímo, tady je ta relay u providera asi příjemnější, protože firewall stačí otevřít na konkrétní externí adresu a hlavně už tam mohou vyřešit antivir a antispam). Víc rozhodování asi u jednoho serveru není.

Dva servery už přinášejí něco navíc. Za prvé je otázkou, proč jsou dva a jestli by třeba uživatelé na každém z nich nemohli mít vlastní OU v certifikátu. Pak je otázka jak odesílat poštu ven – buď oba budou komunikovat přes relay (což je asi dost pravděpodobné), nebo se vše bude routovat na jeden z nich a ten to bude předávat dál. Zatímco případ první – oba jedou přes relay – nastavíte snadno zadáním adresy relay serveru v konfiguračním dokumentu; u případu druhého musíte jít cestou doménových dokumentů a dokumentů spojení. Příjem pošty je pak skoro jasný – půjde primárně na jeden ze serverů, pokud to síť umožní tak by bylo hezké mít druhý server zadaný pro příjem s vyšším MX, aby fungoval jako záloha.

Druhé použití dvou serverů může být v rozdělení jejich rolí – jeden bude fungovat pro poštu a druhý pro aplikace. Smysl to dává v jejich vytížení, poštu používá každý a aktivně, takže bude celkem zatížený, na aplikační zase dáte veškeré aplikace a třeba Sametime pro instant messaging (na to snad rozumný překlad ani neexistuje). Podle zkušeností je tohle rozdělení celkem standardní a dělá to dost firem.

Tři a více serverů už konečně přinášejí to správné vzrušení, jak to nakonfigurovat. Zní to krásně, ve finále ale stejně všichni skončíme u hvězdy, protože dělat spojení každý s každým, když máte 50 serverů je trochu makačka (přestože jsem to už viděl), a liniové (tedy každý ví o svém sousedovi) je zase hrozně zdlouhavé, než všechny servery spolu proreplikují. Takže hvězda nám vychází jako nejlepší, při větším počtu serverů se vyplatí jeden z nich dedikovat jenom pro serverovou komunikaci a vůbec tam uživatele nepustit.

Schéma nakresleno pomocí kreslítka Gliffy.com – aneb Visio přes internet a zdarma

Nastavení je jasné – jeden server má dokumenty spojení na všechny ostatní, každý další jenom na ten hlavní server. Každý server navíc bude mít v server dokumentu nastavenou jinou NNN/DNN (Notes/Domino Named Network, podle toho co kdo preferuje), aby pošta chodila také hezky přes centrální server a nezkoušela se spojit napřímo. Díky centrálnímu serveru, přes který poběží veškerá pošta a replikace, tak máte i jedno místo, kde stojí za to nainstalovat antivir. Asi to bude levnější než to mít všude a hlavně tím šetříte síly těm dalším serverům (ano, emaily poslané v rámci jednoho serveru nepůjdou přes hlavní server a nebudou tedy skenované, to je trochu nevýhoda – ale udělejte na tom hlavním repliky všech mailových databází a máte také jedno místo pro zálohování a viry zjistíte také, byť se zpožděním).

Nastavení do hvězdy může mít (tedy má, ale otázkou je, zda se vám to projeví) nevýhodu při tvorbě replik nebo přesouvání uživatelů na jiný server. Díky tomu, že neexistuje přímé spojení mezi podřízenými servery, tak při přesunu uživatele z jednoho serveru na druhý nedojde k automatickému vytvoření jeho poštovní schránky. Řešení jsou dvě – vytvořit dočasný dokument spojení nebo uživatele přesunout na dvakrát – nejdřív na hlavní server a pak už na ten cílový.

Více serverů také umožňuje bezpečný přístup z internetu do vnitřní sítě pomocí takzvaného průchozího serveru (passthru server). Server umístíte do DMZ, ze které necháte do vnitřní sítě přístupný pouze port 1352. Poté trochu poladíte bezpečnost v server dokumentu, konkrétně na záložce Security sekci Passthru access. U serveru, který je umístěn v DMZ vyplníte do pole Route through jména, která mají právo připojit se přes internet na vnitřní servery (tedy klidně to můžete umožnit jenom vedoucím pracovníkům). U serverů v interní síti zase naopak naplníte pole Access this server (ve stejné sekci) jmény lidí, kteří mají právo přistupovat zvenku na daný server. Díky tomu jste schopni některým lidem umožnit používání serverů pouze z vnitřní sítě, některým plné používání i z internetu a dalším něco mezi – tedy s poštovním serverem by třeba replikovat mohli, s aplikačním nikoliv.

Co dál k implementaci, člověk by řekl, že už asi nic. Samozřejmě jsou další zkušenosti, jak si usnadnit práci s konfigurací (důsledně používat skupiny, aby se do server dokumentu nemuselo vůbec zasahovat, v konfiguračním dokumentu pro všechny servery nastavit maximum společných věcí a pak udělat konfigurační dokumenty pro konkrétní server, který potřebuje něco málo jinak – a zdokumentovat, proč je jich víc, to je asi úplně nejdůležitější). Určitě používat CA, která usnadní práci při registraci lidí (jak jsem ji začal používat, tak jsem okamžitě zapomněl heslo k certifikátu, naštěstí to nevadilo). A to je asi opravdu vše.

Ještě přemýšlím, zda pro ten demo příklad, který jsem nakreslil výše, sem hodit jak by vypadalo nastavení Domino Directory s komentářem, co vše je tam nastaveno a proč, ale to je otázka na vás – má něco takového smysl, nebo je to zbytečné?

Napiš komentář, díky!