Říká se, že administrátoři mají nejraději servery bez uživatelů a vývojářů, aby na nich nedocházelo k žádným změnám a v klidu a pohodě běžely. Potkat takový server se ovšem nedaří moc často, většina z nás na něm chtě nechtě musí trpět uživatele. Otázkou je, jak jim zakládat a rušit účty a vůbec dělat všechny věci, na které si mohou vzpomenout.
V Dominu si nejdříve musíme povědět něco o struktuře certifikátů. O těch jsme si už něco řekli a skončili u toho, že jejich správné vymyšlení může být půlkou úspěchu. Uživatele lze totiž pomocí certifikátů rozdělit do několika různých větví v organizaci, což zní lákavě, ale otázkou zní – podle čeho dělit? Mám uživatele dělit podle pobočky ve které pracují (co když přejíždějí z místa na místo), podle jejich oddělení (co když ho změní) nebo ještě dle něčeho jiného. Osobně si myslím, že u menších organizací moc nemá smysl uživatele dělit do různých certifikátů. Dělení podle poboček může pomoci, pokud pro každou pobočku budete chtít zpřístupnit nějakou sadu dokumentů, ale stejně tak se to dá řešit skupinami. Podle oddělení je to snad ještě horší, vzpomínám na klienta, u kterého HR měnilo názvy oddělení jednou měsíčně a administrátoři tyto změny s několika měsíčními zpožděními byli nuceni následovat. Nezáviděl jsem jim to tehdy.
Pro jednoduchost tedy zůstaňme s jedním certifikátem, který už máme vytvořen od instalace serveru. Soubor, ve kterém je na serveru uložen, má jméno cert.id. S tímto certifikátem lze dělat spoustu věcí, ale my začneme jeho zmigrováním do Certifikační autority. V administračním klientovi se přepneme na poslední záložku Configuration, zkontrolujeme, že máme vpravo rozbalenou lištu s nástroji a zvolíme CertificationMigrate certifier. Vyberete soubor s certifikátem, stisknete OK, zadáte heslo a je tu krásná, na druhý pohled jednoduchá, obrazovka.
Server a jméno souboru můžete nechat beze změny, v poli Encrypt certifier ID with zvolte Server ID. Toto určuje, čím bude certifikát v databázi zašifrován, možnost vytvoření dalšího ID souboru a šifrování jím je samozřejmě dodatečným zabezpečním, které ovšem může přinést i zbytečnou vícepráci. V poli Require password to activate můžete zadat heslo, které bude nutné zadat na konzoli serveru před možností registrace lidí, osobně tato pole nevyplňuji. V dalším poli s administrátory zadáte seznam všech lidí, kteří budou mít právo upravovat nastavení certifikátu (sloupeček CAA), a lidé, kteří budou mít právo registrovat pomocí certifikátu (RA). Pokud chcete registrovat lidi pomocí webového administrátora, tak do seznamu musíte přidat i jméno serveru (což ve verzi 8 jde pouze pomocí jeho ručního napsání). Na druhé záložce je nastavení doby, po kterou budou certifikáty standardně platné, toto nastavení změnit můžete, ale současně to není nutné. Dialog potvrďte a na konzoli serveru spusťte úlohu certifikační autority (příkazem load ca). Současně tuto úlohu musíte přidat i do notes.ini, aby docházelo k jejímu spouštění po každém startu serveru (řádek ServerTasks).
S certifikáty jdou dělat další kouzla – přidat do něj další jazyk, který bude možné používat pro pojmenovávání lidí (typicky se používá třeba pro japonské či ruské zapsání jména, stejně tak jde využít pro češtinu, ale po zkušenostech úplně nedoporučuji, lidé se potom při výběru nabízí dvakrát – jednou se jménem bez diakritiky – tím anglickým – a jednou jméno s diakritikou – to české. Problém je, že anglické jméno je pak ve formátu Prijmeni, Jmeno a to české naopak Jméno Příjmení); nebo u něj zapnout podporu obnovy hesel – a to dělat budeme.
Opět začneme na poslední záložce v administrátorovi a zvolíme CertificationEdit recovery information. Výběr certifikátu a je před námi další dialog.
Ten je relativně jednoduchý – vybere se počet osob, které se musí sejít pro obnovu hesla (čím více tím sice lépe, ale současně pracněji), může se vybrat délka hesla (i když delší je lepší) a vyberete seznam lidí, kteří budou mít možnost heslo obnovit. Pod seznamem osob vyberete mail-in databázi, do které budou posílány zašifrované ID soubory (nebo vytvořit novou) a upravit hlášku, kterou uživatel při obnově hesla dostane. Celou operaci je vhodné provést před zakládáním uživatelů, ale pokud už jste je založili tak tlačítkem Export provede jejich „obeslání“ se žádostí o zaslání obnovovacích informací (což jednoduše udělají stiskem tlačítka). Opět potvrdit dialog a je hotovo.
Skupiny
Skupiny jsou jednodušší, stačí se v administrátorovi přepnout na první záložku, otevřít pohled na skupiny a začít. Skupina má jméno, typ a členy. Typů je několik a mají svůj smysl – Deny List Only slouží pro omezení přístupu k serveru (a nezobrazují se po uložení mezi ostatními skupinami, ale až dole v pohledu Deny Access Groups; Servers Only může obsahovat jenom servery a můžete ji používat s některými příkazy na serveru; Mail Only pouze pro zasílání emailů; Access Control List Only pro nastavování přístupových práv (a nemělo by na ně jít posílat poštu) a Mixed pro vše ostatní. Jako členy můžete zadávat konkrétní jména (doporučení je používat plné jméno ve tvaru Jméno Příjmení/Organizace) nebo ve formě certifikátů (*/Organizace). A skupiny je samozřejmě možné navzájem vnořovat.
Pokud chcete skupinu přejmenovat (a je někde použitá) tak se doporučuje využít akci z menu ActionsRename Group, která zajistí i přejmenování ve všech ACL či seznamu jmen.
Uživatelé
Práce s uživateli (většinou) není příliš složitá, ale věcí s nimi jde dělat výrazně víc než se skupinami. V první řadě je třeba je založit. Začínáme opět na první záložce, zvolíme PeopleRegister v pravém pruhu nástrojů (což je něco jiného než tlačítko Add Person v pohledu), vybereme certifikační autoritu, stiskneme OK a je před námi tabulka, u které v první řadě zaškrtneme Advanced v levé spodní části.
První políčka jsou jednoduchá – jméno, příjmení (doporučuji nepoužívat diakritiku, jakkoliv většina lidí říká, že vše funguje, tak problémy být mohou), výchozí heslo (navíc stiskneme tlačítko Password Options a v dialogu zaškrtneme nastavit internetové heslo) a přecházíme na záložku Mail. Tam je vše předvyplněno – jméno souboru, šablona, zkontrolujte jméno poštovního serveru, můžete zadat servery, kde se má rovnou vytvořit replika, nastavit práva uživatele ke schránce (Editor je tak akorát), nastavte, aby se soubor vytvořil na pozadí (ušetří vám to spoustu času), můžete nastavit omezení velikosti souboru. A další záložka.
Tam se nastaví „jenom“ internetová adresa člověka (respektive se zkontroluje, zda je správně) a hurá dál. Na další záložce je důležité skoro vše – zkontrolovat jméno certifikátu, zda nepoužíváte jiný, zadáte datum, do kdy bude ID platné, jaká bude použitá délka klíče (delší je lepší, ale pozor na zpětnou kompatibilitu), nestaráte se o typ licence a zastavíte se až u pole, kam se má ID uložit. Do Domino Directory je pohodlné, ale nebezpečné, k souboru se mohou dostat další lidé a pokud znají heslo (používáte jedno standardní) tak ho mohou zneužít. Pokud uložíte do souboru tak při instalaci klienta musíte zajistit, že ho máte k dispozici.
Na záložce Groups vyberete skupiny, kam chcete člověka rovnou zařadit a přejdete až na záložku Other, kde můžete zadat organizační jednotku (pokud máte dva Pavly Nováky a chcete je rozlišit), zadat alternativní jméno (pokud to ovšem certifikát umožňuje, což jsme nezapínali) nebo vybrat preferovaný jazyk (pokud jste na server instalovali Language pack, což jsme nedělali).
Pak už stačí zmáčknout zelenou fajfku, která údaje přesune do spodního okna a můžete zadat údaje o další osobě nebo stisknout tlačítko Register All a počkat, až se lidé zaregistrují. Samozřejmá je podpora účtů z jiných systémů nebo import dat z textového souboru (popis v nápovědě), čímž vytvoříte účty pro spoustu lidí snadno a rychle.
Když už máte uživatele vytvořeny, tak s nimi můžete dělat dvě základní věci – zrušit je nebo přejmenovat. Korektní zrušení je jednoduché – vyberete záznam osoby a stisknete tlačítko Delete Person, dialog se zeptá, zda chcete smazat i poštovní schránku a přidat skupinu do Terminate skupiny (samozřejmě) a pak už udělá vše sám.
Přejmenování je také jednoduché. Vyberete záznam osoby a vyberete akci PeopleRename, v dialogu, který se objeví, vyberete Change Common Name, potvrdíte certifikát, platnost uživatelského ID a v dialogu přepíšete všechna jména, která potřebujete. Pak už jenom OK a zkontrolovat, že klient nahlásí, že vše je OK.
Administrační proces
Pokud máte při některých z výše uvedených akcí pocit, že to nic neudělalo, tak můžete mít pravdu. Většina operací totiž neprobíhá okamžitě, ale předávají se ke zpracování administračnímu procesu, který je v daných intervalech zpracovává. Zkontrolovat jak průběh konkrétní akce dopadl můžete zkontrolovat v databázi Admin4.nsf na serveru, pokud chcete vše popohnat tak na serveru zadáte příkaz tell adminp process new. Spousta administrátorů má pocit, že vše může udělat ručně výrazně rychleji než server, což sice může být pravda, ale server narozdíl od nich na nic nezapomene a nás to stojí míň práce. Takže se administračního procesu nebojte a koukejte ho využívat.
Politiky
S uživateli souvisí ještě jedna věc – jejich řízení pomocí politik. Ty se nastavují opět na první záložce v administrátorovi a sestávají ze dvou částí – politik a nastavení. Politika určuje, které nastavení se použije pro kterou skupinu uživatelů, a nastavení určuje, co se vlastně nastaví.
Politiky jsou dvou typů – organizační, které se nastavují na určitý certifikát (díky tomu by se mohlo vyplatit těch certifikátů udělat víc), a explicitní, které se ručně přidělí konkrétním uživatelům pomocí příslušné akce.
Nastavení jsou dvou druhů – ta, která se nastaví jen jednou (Registration, Setup) a ta zbývající, která se nastavují opakovaně. Pomocí různých typů nastavení můžete nastavit takřka cokoliv na dálku, já bych zmínil jenom pár věcí.
Security settings, které slouží k nastavení bezpečnosti, a v něm záložku Execution Control List, která nastavuje, kdo bude mít právo provádět jednotlivé akce. Když to nastavíte na začátku tak jste v pořádku, když si vzpomenete v půlce instalací, tak uživatelé budou muset potvrzovat, že souhlasí se změnu ECL, což je může trochu zmást.
Registration settings vám pro změnu přednastaví všechny věci, které musíte nastavit při registraci lidí, což vám může pár minut poté ušetřit. A v Desktop settings nastavíte veškeré předvolby, které byste uživatelům rádi změnili (stejně jako mnozí další doporučuji nastavit zavírání oken dvojklikem pravého tlačítka).
Při nastavování si dejte pozor na jednu věc – nastavení ve finále probíhá hrozně rychle, takže vše pečlivě odzkoušejte, ať uživatelům něco nenastavíte a oni nejsou zmateni. Skvělá je k tomu právě explicitní politika, kterou danému uživateli přiřadíte pomocí akce PeopleAssing Policy v okamžiku, kdy stojíte na záznamu člověka.
Pokud se při registraci uživatele zapíše ručně organizační jednotka (OU), která nebyla předtím registrována, takto vygenerované ID má problémy při přístupu na server. Pokud je OU zaregistrována, pak má vlastní certifikační ID, které by se mělo používat při registraci uživatelů do této OU. Při použití certifikačního ID OU při registraci uživatele je na záložce „Other“ organizační jednotka již předvyplněna.
Název skupiny může být také v hierachickém tvaru (skupina/OU/O), což se pozitivně projeví např. v dialogu při výběru adresy po přepnutí „View by“ z „List by Name“ na „Notes name hierarchy“ (zejména u rozsáhlejších struktur je to takový dobrý základ před doplňováním dalšího zatřídění podle „Corporate hierarchy“). Skupiny se neregistrují, takže to stačí zapsat přímo do názvu skupiny.
Při mazání uživatele se dříve automaticky přidávalo do „Deny Access Group“ (dále jen DAG), v R8 už se ta skupina jmenuje „Terminate“?
Osobu (resp. její person dokument) před smazáním z names.nsf bývá dobré odzálohovat (aspoň zkopírováním přes clipboard do jiné DB). Do DAG od jisté doby raději přidávám ručně a píšu si na záložku „Comments“ kdy, kdo a koho (případně proč) tam přidal. On se pak třeba šéf diví, proč se mu nabízí v adresním dialogu v nějaké skupině jméno osoby, která je už půl roku pryč a proč ještě není ze skupiny smazaná? Samozřejmě smazaná už je (víme kdy, kdo, atd. – mazání ze skupin a přidávání osoby do skupiny je lepší také okomentovat přímo ve skupině, což automatika bohužel nezajistí) a obvykle má skupinu na lokální replice, kterou dlouho nereplikoval. Kromě toho bývá osoba nějakou dobu ještě v provozu i po odchodu (např. pokud někdo přebírá její práci, pak kontroluje nové maily v její schránce a upozorňuje odesílatele na změnu osoby), takže v DAG se osoba ocitá ihned, ale k jejímu smazání dochází později.