Na školeních a seminářích týkajících se administrace IBM Lotus Domino serverů je jednou z častých otázek zda existují doporučení pro pojmenovávání skupin, systémových účtů, nastavení zabezpečení serverů, … . Rovnou říkám, že nic takového jsem nikdy nikde neviděl a tak se s vámi podělím o to jak to dělám já.

Níže uvedené řádky neberte jako dogma, které je potřeba dodržet, ale pouze jako vodítko, tak jak to dělám já a upravte si to k obrazu svému.

Jmenná konvence

Jak říkám na školeních a seminářích. Jmenná konvence není nic složitého, ale je potřeba v ní mít jasno hned na začátku, protože některé položky se zpětně mění jen obtížně.

Zkratka státu

Byť se nejedná o povinnou položku, tak já ji rozhodně doporučuji. Název je potom jakový ucelenější a v případě, že se jedná o nadnárodní organizaci, tak je to dokonce nezbytnost aby bylo rozlišené o jaký stát se jedná. Zejména pokud má organizace ve všech státech stejnou zkratku. Z pohledu umístění v LN jméně se jedná o poslední položku formátu LN jména.

… …/…/CZ 

Organizace

V případě že organizace používá nějakou oficiální zkratku, tak je vhodné ji použít pro označení organizace. Pokud nice takového firmy nemá a název není příliš dlouhý použijte název firmy, ale vyvarujte se použití mezer. Při mích školeních seminářích se můžete setkat s tím že používám zkratku MaHa.

… …/MaHa/CZ

Organizační jednotky

Použití organizačních jednotek může minimalizovat pravděpodobnost výskytu duplicit stejného jména, ale také může dobře posloužit pokud chcete rozlišit na jakém oddělení nebo např. pracovišti je uživatel zařazen. Organizační jednotky nejsou povinné a jejich použití záleží zcela na správci prostředí Lotus Domino serverů.

Jména serverů

Za sebe se držím následujících pravidla. Jméno serveru by mělo být odvozeno z účelu kterému server slouží a případně z jeho geografického umístění. V každém případě by název Domino serveru měl být zanesen v DNS a při použití jména serveru by měl být Domino serveru síťově dosažitelný. Jednoduše řečeno pokud dám PING na jméno serveru měl by mi server odpovídat. Pokud se jedná např. o emailový server který je v Brně může být jeho název BRNMAIL01 nebo pokud se jedná o aplikační server, tak může být názeb BRNAPP01. Proč tam dávat 01? V případě že budete mít v budoucnu Domino cluster, bude jednodušší rozlišení při zachování stejného počtu znaků.

Jména uživatelských účtů

V případě uživatelských účtů je to jasné, formát uživatelského jména budete mít pravděpodobně vždy ve tvaru Jméno Příjmení, ale co s diakritikou. používat nebo ne? Já osobně jsem zastáncem diakritiku ve jménech nepoužívat. Vyhnete se tím případným problémům.

Jména privilegovaných účtů

Jména privilegovaných účtů využijete zejména pro správce Lotus Domino serverů a vývojáře Lotus Domino databází. Osobně totiž zastávám názor, že každý správce a vývojář by měl mít dva účty. Jeden účet na jméno ke kterému jsou přiřazena oprávnění vztahující se k jeho pracovní pozici, organizační jednotce, pracovišti, projektům, … a druhý který má oprávnění pro vývoj Lotus Domino databází nebo správu Lotus Domino serverů a služeb.

Účty pro administrátory pojmenovávám ve tvaru AdminAaBb, kde Aa jsou první dvě písmena křestního jména a Bb první dvě písmena příjmení. S ohledem na výše uvedený by tedy účet pro mne vypadal následovně

AdminMaHa/MaHa/CZ

Účty pro vývojáře pojmenovávám ve tvaru DevAaBb, kde opět Aa jsou první dvě písmena křestního jména a Bb první dvě písmena příjmení. S ohledem na výše uvedený by tedy účet pro mne vypadal následovně

DevMaHa/MaHa/CZ

Privilegovaný účet je vytvořen i pro podpis designu Domino databází, které jsou umístěné na serveru. Tento účet má v držení vždy správce Lotus Domino serveru a tímto účtem podepisuje databáze které jsou umístěné na serveru. Výhodou je že může tento podpis nastaven jako důvěryhodný na Lotus Notes klientech, při změně vývojáře nedojde k jeho změně a Správce serveru má pod kontrolou co má na serveru nasazeno. Účet pro podpsi designu databází vytvářím ve formátu ZkrOrganizace Development. S ohledem na výše uvedený by tedy vypadal následovně

MaHa Developmnet/MaHa/CZ

Jména účtů pro programy a služby

Toto je „kapitola sama pro sebe“. Já vytvářím pro každou službu nebo externí aplikaci samostatný účet, tak aby bylo zřejmé kdo danný účet používá. Všechny tyto účty začínají písmenem „x“.

Jména skupin

Jmenná konvence pro skupiny bude trochu obsáhlejší a hlavně pro se bude lišit podle toho jaké oblasti bude správce Lotus Domino serveru chtít pomocí skupin řešit. Já používám skupiny pro pokrytí následujících oblastí:

• Skupina pro všechny zaměstnance
• Skupina pro externí uživatele
• Skupina pro všechny uživatele
• Skupiny dle pracovišť
• Skupiny dle organizačních jednotek
• Skupiny dle pracovní pozice
• Emailové skupiny pro aplikace
• Skupiny pro přístupy k databázím
• Skupiny se zakázaným přístupem
• Skupiny pro záložku security v server dokumentu
• Administrační (privilegované) skupiny

Skupina pro všechny zaměstnance

Již z názvu je patrné pro koho by skupina měla být určena. Jejími členy by měli být všichni zaměstnanci dané organice. Takovou skupinu je potom možné s výhodou použít pokud potřebujete k nějaké databázi nastavit přístup pro všechny zaměstnance. Nebo pokud potřebujete všem zaměstnancům poslat nějaké informace. Formát jména pro tuto skupinu volím tak aby o v případě více adresních knih bylo zřejmé o koho se jedná. Pokud se jedná o organizaci MaHa, která je v ČR, tak název skupiny volím následovně

MaHaCZ_All v případě emailové adresy něco jako MaHaCZ_All@firma.cz

Skupina pro externí uživatele

Záleží zda máte na serveru nějaké externí uživatele tzn. uživatele kteří nejsou zaměstnanci organizace. Mohou to být např. zaměstnanci firem které Vám dělají podporu, zaměstnanci externích firem ,které pro Vás dělají nějaké činnosti a je žádoucí aby měli přístup k některým datům nebo mohli využívat interní emailovou komunikaci, … Skupiny pro tyto uživatele vždy začínají prefixem EXT, EXTERNAL nebo EXTERN, záleží co Vám vyhovuje a následované zkratkou firmy. Např tedy

EXT_FIRMA, EXT_FIRMA_All, EXT_Marketing, EXT_Audit, …

Pokud je výše uvedené Váš případ, tak opět mám skupinu EXT_All, která obsahuje všechny externí uživatele.

Skupina pro všechny uživatele

Opět z důvodu možného hromadné zaslání informací nebo přidělování přístupu k databázím nebo serverům se může hodit skupina která bude obsahovat všechny uživatele. Pro tento případ používám název skupiny ve tvaru

User_All

Skupiny dle pracovišť

Vetšinou jsem si vystačil pokud tyto skupiny byly pouze pro zaměstnance. Název jsem volil ve tvaru Firma_Pracoviště.

MaHaCZ_Brno

Tyto skupiny jsou potom členy výše uvedené skupiny všech zaměstnanců. V našem případě tedy skupiny MaHaCZ_All.

Skupiny dle organizačních jednotek (oddělení)

Pokud jste firma, která je členěna na organizační jednotky, může být vhodné mít i skupiny pro jednotlivé organizační jednotky. Jednak to uživatelům ulehčí případné adresování emailů na oddělení pokud to je potřeba, ale stejně tak je možné tyto skupiny využít pro přidělování oprávnění k databázím, dokumentům, pohledům, … Název takové skupiny je tvořen prefixem OE (aby skupiny byly pohromadě) a dále zkratkou oddělení. Pro náš příklad můžeme použít jako skupiny IT která má název Středisko Informačních technologií se zkratkou SIT. Název skupiny by potom byl

OE_SIT

Skupiny dle pracovní pozice

Opodstatněnost skupin je zřejmá, ale jmenná konvence může být složitější, protože pracovní pozice pravděpodobně nebudou mít zkratky podobně jako tomu je u organizačních jednotek. Možná tak budete muset improvizovat. Navíc může nastat situace, že jedna pracovní pozice bude na více odděleních. V každém případě jako prefix používám OF a následně bud definice pracovní pozice, pokud se jedná o všechny stejné pracovní pozice v rámci firmy nebo OF_ZkrOE a definice pozice. Pokud tedy např. vezmu že vedoucí oddělení bude Department Manager mohly by skupiny vypadat následovně

OF_DepMgr nebo OF_SIT_DepMgr, případně OF_DepMgr_All

Emailové skupiny

Asi jediný typ skupiny u které se těžko dělá nějaká jmenná konvence. Pokud to není úplně nevhodné, tak se snažím vyhovět žadateli. Vždy se ale snažím vyvarovat mezerám v názvu skupin místo kterých volím podtržítko.

Emailové skupiny pro aplikace případně servery

Může se stát, že některé aplikace nebo servery budou posílat notifikace na určité uživatele. Pokud je adresa příjemce „zadrátována“ přímo v kódu, tak je vhodné vytvořit skupinu na kterou budou emaily adresovány a příjemce uvádět jako členy této skupiny. Případná změna příjemců tak je možná bez zásahu do kódu aplikace. Těmto skupinám dávám jako prefix EML který je následován označením aplikace nebo serveru a rozlišením pro příjemce. Příklad může vypadat následovně

EML_<Aplikace>_IT

EML_<Server>_Notifikace

Přístupové skupiny k databázím

Přístupová práva k databázím je sice možné nastavovat přímo v ACL dané databáze. Ale já osobně spíše preferuji mít v ACL nadefinovanou sadu skupin kde jednotlivé skupiny mají nastavena příslušná oprávnění a následně měnit pouze obsah těchto skupin v adresní knize. Všechny skupiny pro ACL k databázím mají jasnou jmennou konvenci prefi DB následované označením databáze za kterým následuje rozlišení přístupu

DB_<Databaze>_RozliseniPristupu

Mimo to všechny databáze obsahují v ACL minimálně následující skupiny

DB_<Databaze>_BO nebo DB_<Databaze>_BusinessOwner

DB_<Databaze>_TO nebo DB_<Databaze>_TechOwner

Skupiny se zakázaným přístupem

Skupiny kterou jsou typu Deny List Only s výhodu využijete pro smazané uživatelské účty. Pokud uživatele smažete z Domino directory, tak je při běhu administračního procesu odebrán i ze skupin s výjimkou skupin které jsou typu Deny List Only. Můžete sem tak zařadit smazané uživatele a máte jistotu že pokud si ponechají ID, tak jim bude odepřen přístup k Domino serveru. Pokud je ve firmě velká fluktuace lidí, tak se může stát, že narazíte na limit kolik účtů do skupiny zařadíte. Já vytvářím skupinu pro každá rok a tuto skupinu potom přidávám do „centrální skupiny“.

• $AccessDeny_<Rok> skupina pro konkrétní rok zrušení uživatelského účtu
• $AccessDeny centrální skupina obsahující všechny skupiny za konkrétní roky

Skupiny pro security záložku v server dokumentu

Security záložka server dokumentu umožňuje nastavit kdo na serveru budu moci co dělat. Z pohledu administrace a rozdělení pravomocí se mi zdá vhodnější a pro správu jednodušší mít zde nastaveny pouze skupiny do kterých následně mohu přidávat nebo odebírat účty. Jmennou konvenci používám následující s tím že do položky description dávám celý název položky tak jak je uvedený v server dokumentu:

$Sec_<ServerName>_Sekce_PoleSereverDoc