Doména FJFI

From NMS
Revision as of 15:09, 8 September 2007 by Vokac (Talk | contribs) (Firewall)

Jump to: navigation, search

Servery

Doménové servery
jméno umístění funkce / poznámka
 ??? Břehová hlavní DC, fileserver
 ??? Břehová Exchange
 ??? Trojanova DC, fileserver
trk Trojanova Exchange
 ??? Trója DC, fileserver
 ??? Trója Exchange

Kromě těchto doménových jmen bude na každý server směřovat několik aliasů pro zjednodušení a zobecnění konfigurace dalších služeb (Kerberos, LDAP, ...). Konfigurace ostatních strojů tak bude nezávislá na konkrétním jméně DC a v případě vypadku/zrušení některého DC se pouze alias nasměruje na některý funkční DC.

  • Servery - aliasy pro doménové kontrolery (hlavní wc), wc1, wc2, ...
  • Kerberos - aliasy krb (musí na něm běžet krb-admin), krb1, krb2, krb3, ...
  • LDAP - aliasy ldap (alias na vždy dostupný LDAP server), ldap1, ldap2, ldap3, ...
  • NTP - alias ntp (nutné zajistit, aby zde vždy běžel synchronizovaný NTP server)

Firewall

Firewall
protokol port rozsah
DNS 53 TCP+UDP 0.0.0.0/0
LDAP 389 TCP+UDP 0.0.0.0/0
LDAPs 636 TCP 0.0.0.0/0
Kerberos 88 TCP+UDP 0.0.0.0/0
Kerberos Admin 749 TCP 0.0.0.0/0
NTP Time Service 123 TCP+UDP 0.0.0.0/0
SNMP 161 TCP+UDP pro management stroje (nms.fjfi.cvut.cz)
Samba 137,138,139,445 TCP+UDP minimálně rozsah FJFI (ČVUT?)
RPC 135 TCP rozsah FJFI(?) (ČVUT?) - nutné pro připojení počítače do domény

Konfigurace DNS

Primární DNS server pro doménu FJFI běží stále na ISC Bind. Je to jak z bezpečnostních důvodů (oddělení služeb/uživatelů Windows Serverů od správy DNS) tak i s ohledem na jednodušší rozšiřitelnost (v roce 2008 bude pravděpodobně zprovozněn DNSSEC). Pro potřeby doménových kontrolerů je potřeba zavést některé specielní záznamy. Detaily lze nalézt v dokumentu Configuring Non-Windows 2000 DNS Servers to Support Active Directory nebo také v DNS & Bind Cookbook.

Zatím bude "nejlepší" provádět ruční synchronizace při změně doménových serverů. S možnosti DDNS bude lepší počkat až na vydání BIND 9.5, který už podporuje i GSS-TSIG šifrování DDNS dat.

Pro naše potřeby bylo nejvhodnější přídat doménovým kontrolerům práva na správu specielních záznamů, ale nepovolit jim změny přímo v doméně fjfi.cvut.cz. Uvedené nastavení je dostatečné pro bezproblémový provoz Windows Domény bez nutnosti manuálnich zásahů do DNS v případě rekonfigurace domény (např. přidání/odebrání/přejmenování domain kontroleru). Všechny(?) doménové kontrolery mohou provádět změny v následujících zónách:

_tcp.fjfi.cvut.cz
_udp.fjfi.cvut.cz
_msdcs.fjfi.cvut.cz
_sites.fjfi.cvut.cz
DomainDnsZones.fjfi.cvut.cz
ForestDnsZones.fjfi.cvut.cz

Pokud je potřeba znovu provést DDNS update těchto specielních záznamů na primárním DNS serveru, je potřeba provést následující příkazy:

net stop netlogon
ipconfig /flushdns
[restart DNS server]
net start netlogon
ipconfig /registerdns
dcdiag/netdig # to check the server.

Vzhledem k významu DNS záznamů pro tyto delegované zóny je nutné zajistit jejich replikaci na sekundární DNS (tyto záznamy se totiž nereplikují na ns.cvut.cz). Zatím zprovozněno na mailgw1/2.

NTP - synchronizace času

Pro správnou funkci Kerbera je nutná synchronizace času mezi autentizovaným systémem a KDC serverem. Z tohoto důvodu je nutné zajistit, aby se Windows Servery synchronizovali proti nějakému spolehlivému zdroji času a navíc poskytovali NTP službu pro klienty. Aktuální NTP server musí být dostupný na adrese ntp.fjfi.cvut.cz. Ve standardní konfiguraci w2k3 serveru je tolerance v nastavení času mezi serverem a klientem 5 minut. Pokud nebude čas správně synchronizován, pak přestane fungovat nejen přímá autentizace uživatelů, ale i ověřování služeb. Přesný čas na serverech (i klientech) je tedy kritický a je tedy nutné zajistit jeho monitorování (TODO).

Rozšíření schemat Active Directory

Aby mohli být v Active Directory uloženy všechny informace pro každého uživatele je potřeba rozšířit schémata o potřebné třídy a atributy. Většinu operací se schématy není možné vrátit zpět a proto je potřeba se nad tím pořadně zamyslet. Jedinnou možností je v podstatě přeinstalovaní celé domény (možná by to mohlo jit z ntbackupu???).

Active Directory umožňuje přidavat vlastní atributy, ale není možné je v budoucnu odstranit ani není možné měnit některé jejich parametry (např. datový typ). Také lze přidávat vlastní třídy všech typů, ale opět se jich už nikdy nezbavíme. Je také možné přidávat atributy do již existujících tříd, opět neexistuje možnost jejich odstranění.

Nejrozumnější způsob jak přidat vlastní atributy k existujícím objektům je vytvoření vlastní auxiliary class s požadovanými položkami. Pokud je totiž doména i forest nastaven v nativním windows 2003 módu, potom lze používat "dynamic linked auxiliary classes". To znamené, ze k libovolnému objektu lze tuto třídu přidat, ale lze ji také v budoucnu odebrat, pokud by nastaly nějaké problémy s kompatibilitou.

Všechny názvy přidaných atributů a tříd musí mít takový nazev, aby nebyl v konfliktu s existujícími (a to i v budoucnu). Z toho důvodu budou mít jedinečný přefix (ctu resp. fnspe resp. amavis). Kazdý objekt navíc můsí mit jedinečný identifikátor OID z rozsahu přileného VIC ČVUT.

V současnosti je pořeba do Active Directory potřeba přidat následující schemata:

  • fnspeAccount - uživatelské informace (osobní číslo, Eduroam účet, zpracování mailů, ...) - FIXME: toto není finální verze!, ale pro testování synchronizací je plně dostačující
  • amavisAccount - nastavení filtrování spamů/virů/... na mailgw

Uživatelské účty

  • veškeré organizační jednotky s účty budou pod ou=People,dc=fjfi,dc=cvut,dc=cz
  • ou=Auto - automaticky synchronizované učty proti stavu v Usermapu (vytváření i rušení)
  • ou=Trash - automaticky rušené účty - sem budou přesunuty účty z ou=Auto a budou zde čekat na potvrzení zrušení (tyto účty budou zablokované)
  • ou="Department"? - manuálně spravované učty (převážně zaměstnanci)
    • stačila by jedna organizační jednotka pro zaměstnance, ale z důvodu přehlednosti je lepší mít zvlášť "každou" katedru
    • příslušnost ke katedře je relace 1:N a bude dána zařazením uživatele do odpovídajících skupin (zařazení do nějaké OU "domovské" katedry je nepovinné/nezávislé)
    • jména budou obsahovat zkratky kateder (Dekanat, KDAIZ, KF, KFE, KIPL, KJ, KJCH, KJR, KM, KMAT, KSE, Tereza)
  • ou=Guest - povinná doba expirace
  • ou=Special - učty se specálními přístupovými právy
Speciální účty
jméno využití a práva
Proxy Eduroam read pro sAMAccountName, fnspeEduroam*; omezení na IP Radius serverů a NMS
Proxy Mailgw read pro fnspeMail*, amavis*; omezení na IP Radius serverů a NMS
Proxy NMS read/write konfigurace účtu fnspe*, amavis*, targetAddress, read proxyAddress; omezení na IP NMS
Proxy Host účet pro Kerberos host ticket host/hostname@FJFI.CVUT.CZ (FIXME: práva?); omezení na IP FJFI (CVUT?)
Proxy Service účet pro Kerberos service ticket service/hostname@FJFI.CVUT.CZ (FIXME: práva? jednotlivé služby?); omezení na IP FJFI (CVUT?)
 ? test001 testovací uživatelský účet monitoring LDAP, nulová práva krom autentizovaného LDAP bind
 ? test003 testovací uživatelský účet pro Eduroam pro CESNETí monitoring, nulová práva, nutné vyplnit Eduroam heslo (promyslet - založit tento účet jen na RADIUS serveru?)


Typy účtů

  • konto (objectClass=user)
  • kontakt (objectClass=contact)
  • unix (objectClass=posixAccount)
  • eduroam (objectClass=fnspeEduroamAccount)
  • fnspeAccount (objectClass=fnspeAccount)
  • fjfi konto (objectClass=fnspeAccount) FIXME: záklaní atributy OK, ale není to finální verze
  • amavis (objectClass=amavisAccount)

Mohou existovat následující kombinace (v závorce volitelné položky)

  • konto+[unix+fnspeAccount+amavisAccount] - klasické uživatelské konto
  • kontakt+[fnspeAccount+amavisAccount] - mail kontakt nebo samotné eduroam konto

FIXME: promyslet využití jedné nebo více tříd pro informace v AD (fnspeAccount x fnspeAccount+fnspeEduroamAccount+...) - zatím použít jednu třídu fnspeAccount pro vše + amavisAccount

FIXME: funkce pro konverzi konto<->kontakt? funkce pro přidání/odebrání učtu např. eduroam ke kontaktu, fnspeAccount ke kontu, ... - tohle zatim neřešit

Synchronizace s Userermapem

Usermap slouží jako primární zdroj pro automatické zakládání a rušení účtů. Každému studentovi/zaměstnaneci/spolupracovníkovi FJFI se automaticky vytvoří účet v ou=Auto se standardními přístupovými právy. Pokud bude uživatel potřebovat nějaké individuální nastavení účtu v AD, měl by být přesunut do příslušné organizační jednotky. Účty v ou=Auto budou také automaticky rušeny resp. přesunuty od ou=Trash a zablokovány (podle stavu účtu v Usermapu). Po jednom roce od přesunu do ou=Trash budou účty automaticky odstraněny včetně uživatelských dat (domovské adresáře, maily, databáze, ...) - vytvořit rozhraní pro volání externích skriptů. Pokud se změní stav v Usermapu na zombie (oUser.status - viz. dále) nebo učet z Usermapu úplně zmizí, potom se lokální stav nastaví "kill". V tomto stavu účet setrvá konfigurovatelnou dobu (jeden měsíc?, kdy si uživatel bude moci stáhnout svoje data nebo zařidit si přesunutí do organizační jednotky, kde nebude jeho účet automaticky rušen) než přejde i na FJFI do stavu "zombie". Takový účet bude zablokován a přesunut do ou=Trash. O přechodu účtu do stavu "kill" bude uživatel informován mailem. Stav bude uchováván v atributech fnspeStatus, fnspeStatusTimestamp.

životní cyklus uživatelského účtu

  • vznik na základě synchronizace učtů s Usermapem nebo commandline
  • automaticky synchronizován dle informaci v Usermapu (spojeno přes uživatelské osobní číslo)
  • účty v ou=Auto automaticky rušeny pokud zmizí z Usermapu nebo oUser.status bude zombie
    • nastavit lokální status "kill" a poznamenat si timestamp
    • poslat info uživateli o rušení jeho účtu
    • za měsíc učet přesunout do ou=Trash a zablokovat
  • účty v ou=Trash automaticky rušit po uplynutí jednoho roku

Atributy

  • z důvodů lepší kompatibility a podpory FJFI specifických atributů je potřeba do objectClass přidat následující auxiliary classes: inetOrgPerson, posixAccount, fnspeAccount, amavisAccount - poslední dvě (tři) jen pokud jsou aktuálně potřeba (amavisAccount bude potřeba až když uživatel provede vlastní konfiguraci spamového filtru)
  • vytvořit speciální účet v AD s minimálními právy a možnosti nastavovat atributy z fnspeAccount a amavisAccount
  • uživatel nesmí mít právo měnit (některé) svoje atributy (např. ctuPersonalId, fnspeEduroamDisabled, ...)
  • objekt oUser se odkazuje na objekt ze skriptu pro import dat z Usermapu viz. [1]
Atributy v AD
atribut typ popis
Uživatelské jméno
sAMAccountName C uživatelské jméno - pro studenty Usermap username, pro zaměstnance příjmení(?); pro případ konfliktu mít algoritmus pro automatické řešení - musí brát v úvahu již existující jména, mailové adresy (musí existovat možnost vytvořit adresu "sAMAccountName"@fjfi.cvut.cz), jména v Usermapu?, jména za seznamu rezervovaných jmen (z externího souboru); uživatelská jména bez návaznosti na Usermap musí být kratší než 8 znaků nebo musí mít nějaký prefix (poslední bod se týká pouze naší vnitřní politiky a ne kontrol potřebných provádět během synchronizace), pro první import použít informace z dokumentu o migraci uživatelských účtů
cn C nastavit na stejnou hodnotu jako sAMAccountName
uid C nastavit na stejnou hodnotu jako sAMAccountName
msSFU30Name C nastavit na stejnou hodnotu jako sAMAccountName
posixAccount
uidNumber C vyplnit jen při vytváření účtu, jedinečné číslo v intervalu <1000,30000), pro první import použít informace z dokumentu o migraci uživatelských účtů
gidNumber C vyplnit jen při vytváření účtu číslem 1000
homeDirectory C vyplnit jen při vytváření účtu stringem /home/"sAMAccountName"
loginShell C vyplnit jen při vytváření účtu stringem /bin/bash
gecos A synchronizovat vždy stringem vytvořeným z "givenName sn", bez diakritiky
mail FIXME: atributy vyplnit až při první změně hesla (do té doby mail nefunkční)? - zatím vytvořit schránku hned při zakládání uživatele
mail A pro zaměstnance Jméno.Příjmení@fjfi.cvut.cz pro studenty "sAMAccountName"@fjfi.cvut.cz (pozor na jména/příjmení, které se skládají z více části oddělených mezerami), pro první import použít informace z dokumentu o migraci uživatelských účtů; v případě konfliktu zaměstnanecké adresy Jméno.Příjmení@fjfi.cvut.cz tuto adresu nevytvářet, ale poslat mail správci
proxyAddresses AA pro všechny "sAMAccountName"@fjfi.cvut.cz, zaměstnanci navíc Jméno.Příjmení@fjfi.cvut.cz (v případě konfliktu informovat správce mailem nebo lépe rozmyslet algoritmus pro automatické řešení těchto případů), nastavit defaultni adresu na tu "nejhezčí" (pokud existuje např. Jméno.Přijmení@fjfi.cvut.cz) - prefix SMTP:, ostatní mají prefix smtp:
fnspeMailAddresses AA budou sem přidávány všechny automaticky vytvářené adresy
uživatelské informace
displayName A kvůli hledání synchronizovat plně jméno (včetně titulů) s diakritikou a bez diakritiky (do atributů displayName, displayName;lang-cs, displayName;lang-en), displayName vyplnit prozatím bez diakritiky, FIXME: (ne)uvádět tituly?
name A to samé co do displayName (?) - nyní jen jméno bez diakritiky a bez titulů
wWWHomePage A synchronizovat oUser.privateWeb
facsimileTelephoneNumber A synchronizovat oUser.fax
telephoneNumber A synchronizovat oUser.phone
mobile A synchronizvat oUser.mobilePhone
otherPhone A synchronizovat oUser.privatePhone
 ??? A synchronizovat oUser.privateMail (existuje nějaký vhodný standardní atribut? pokud ano, tak ho použít.
department A synchronizovat vše z oUser.departmentName
departmentNumber A synchronizovat vše z oUser.departmentNumber
fnspeStatus A synchronizovat oUser.status ("new", "active", "kill", "zombie", "dead", "unknown")
fnspeStatusTimestamp  ? časová značka změny fnspeStatus, měnit pouze v případě, že se mění také fnspeStatus
c C nastavit při vytváření na "CZ"
co C nastavit při vytváření na "Czech Republic"
l A synchronizovat oUser.address(0).city
street A synchronizovat oUser.address(0).street
postalCode A synchronizovat oUser.address(0).zip
title C nastavit na "CTU FNSPE"
další zajímavé atributy
memberOf AP podle skupin existujících v AD a v oUser.groups, podrobné vysvětlení dále u popisu skupin
profilePath C vybrat server podle místa katedry phd studenta či zaměstnance
scriptPath  ?
userAccountControl  ? pro blokování účtu(?)

Legenda:

  • C - vyplnit při vytváření nového účtu
  • A - synchronizovat vždy podle aktuálních údajů (z Usermapu)
  • AA - pouze přidávat aktuální údaje (zachovat všechny stávající hodnoty atributu)
  • AP - zachovat "neznámé" hodnoty a synchronizovat ostatní dle definovaného seznamu

Konfigurace synchronizace

Synchronizační skript si bude načítat externí soubor s konfiguracemi. Zde budou uloženy informace potřebné pro přístup k informačním systémům (jména/hesla) a také seznam cvutPersonalId, které se nemájí importovat z Usermapu. Také zde bude seznam uživatelských jmen, které nelze použít pro hodnotu atributu sAMAccountName (např. root, abuse, mail, ...)

API synchronizačního skriptu

FIXME: tohle není finální verze, je potřeba detailně promyslet - no snad už to je trošku kompletní

Synchronizační skript by měl poskytnout přehledné API k následujícím operacím:

sync()
synchronizuj s Usermapem - smaž/přesuň/updatuj/vytvoř účty (vrátí mailem informace o konfliktech, nekonzistencích, ...)
sync(cvutPersonalId)
synchronizuj jednoho konkrétního uživatele
createUser(type, cvutPersonalId, username, ou, dictionary)
vytvoř uživatele - obecná funkce (nebude volána přímo, ale přes specializovanější fce), parametry nemusí mít nastavenou hodnotu, je-li nastaveno
  • type - typ účtu ("user", "mail") - asi udělat jako bitovou mapu
    • user - standardní účet
    • mail - vytvořit také mailstore
  • cvutPersonalId, dotáhne informace z Usermapu
  • username - je preferováno před tím případně dotaženým z Usermapu
  • ou - vytvoří uživatele v příslušné ou (jinak standardně v ou=Auto)
  • dictionary - vše se zkopíruje do hodnot atributů vytvářeného uživatele
createUsermapUser(...)
stejné parametry jako předchozí fce mimo typu, který bude nastaven na "user"+"mail", cvutPersonalId je povinný
createFnspeUser(...)
stejné parametry jako předchozí fce mimo typu a cvutPersonalId (nastaveno automaticky na "user"+"mail" resp. prázdná hodnota), username je povinný
createGuestUser(...)
stejné jako createFnspeUser, ale typ jen "user" (tj. vytvořit bez mailstore), před username přidá prefix "guest_", založí v ou=Guest
trashUser(dn)
přesune uživatele s DN do ou=Trash a disabluje přístup
removeUser(dn)
úplně odstraní uživatele s DN včetně mailstore a dat(?)
  • změň charakter účtu - povinné parametry: operace (add|remove), charakter (user|contact|mail|eduroam|fnspe|...)
  • samostatná konfigurace způsobu synchronizace pro všechny atributy (full|add|add+remove_list|one_time|...) - FIXME: promyslet
createOfficialAddresses(dn)
pokud je vyplněn atribut targetAddress nebo homeMDB (prostě má nastaven forward nebo existuje účet na Exchange) tak přidá do atributů proxyAddresses adresu username@fjfi.cvut.cz a pro zaměstnance navíc jméno.příjmení@fjfi.cvut.cz (zas v případě konfliktu s existující adresou ji nepřidá a pošle mail správci), nastaví atribut mail na jméno.příjmení@fjfi.cvut.cz - pro ty, co tuto adresu mají - pro ostatní na username@fjfi.cvut.cz
createMailstore(dn)
vytvoří mail účet na Exchange
removeMailstore(dn)
zruší účet na Exchange

Motivace je pro poslední tři funkce je taková, že se při synchronizaci _nebude_ automaticky vytvářet účet na Exchange (kvůli externím spolupracovníkům, kteří by ji stejně nepoužívali - pár se mi jich totiž teď ozvalo) a vytvoří se až v okamžiku, kdy si uživatel bude "aktivovat účet" (bude si nastavovat heslo) - v tom okamžiku budeme potřebovat funkci, která pro daného uživatele založí mail účet na správném Exchange serverů a pak přidá správné mailove adresy (formulář pro "aktivaci účtu" si tu vytvoříme sami).


  • bylo by dobré, aby existoval nějaký "verbose" mód, který by na stdout nebo stderr vypisoval hlášky o průběhu synchronizace
  • bylo by dobré mít nějaké jednoduché commandline rozhraní k uvedeným funkcím

Uživatelská jména

Pro studenty standardně ve formatů KOS/Usermap jména. Toto jméno je rezervováno po celou dobu působení na ČVUT + 1 rok a pak může být recyklováno (narozdíl od osobního čísla, které by mělo být jedno pro danou osobu navěky). VIC také umožňuje změny uživatelských jmen, což ale na FJFI nebude podporováno viz. dále.

V případě, že uživatel nebude mít jméno z KOS/Usermapu, nesmí toto jméno být v konfliktu s některým již existujícím účtem. Z toho důvodu je žádoucí vytvářet "lokální" jména jiným způsobem než to dělají na VICu (5 písmen ze jména, 3 z příjmení které v případě konfliktu nahrazují čísly) - nejvhodnější jsou pravděpodobně jména kratší než 8 znaků nebo zavedení určitého prefixu (např. guest_username). Doporuční osmi maximální délky osm znaků má dva důvody, historické (některé systémy nemusí podporovat dlouhá uživatelská jména) a praktické (např. formátování výstupů v unixových systémech).

Uživatelské jméno nesmí obsahovat mezery a musí se skládat z malých písmen, číslic, pomlčky a podtržítka ([a-z0-9_-]). Využití podtržítka je navíc limitováno na předem definované speciální prefixy (např. guest_, ???).

Nesmí existovat žádné univerzální účty (ani pro hosty!), každý musí být jednoznačně svázán s jedním uživatelem (vyjímku mohou tvořit maximálně specielní účty v ou=Special, které mají omezená práva).


Změna uživatelského jména

FIXME: a co s případem, že vytvořím uživateli účet dříve než bude v Usermapu a tím pádem se mi po jeho zavedení vytvoří účet druhý? Když mu budu chtít zachovat jméno, které jsem mu ručně přiřadil, tak je to prakticky ekvivalentní změně uživatelského jména.

Vzhledem k návaznostem na další systémy není změna jména podporována. Správce ho v žádném případě nesmí změnit. Jedinnou možností jak dosáhnout změny jména je odstranění uživatelského účtu z Windows AD, dále je nutno počkat až se tato změna projeví ve všech navazujících systémech (FIXME: minimálně týden?) a poté založit nového uživatele (je tedy potřeba také zabránit automatickému vytvoření příslušného účtu podle údajů z Usermapu). I v tomto případě je však nutné upozornít všechny ostatní správce a to nejlépe mailem do "comp" konference.

FIXME: co s doručováním mailu pro uživatele, kterému "měním" jméno?


Rezervovaná jména

Bude existovat centrálně spravovaný seznam rezervovaných jmen, které nesmí být použity jako název účtu v AD (např. root, ...). Tento seznam musí být brán v úvahu při automatickém zakládání účtů.


Jména se speciálními právy

Normální uživatel by neměl mít žádná administrátorská práva. Pokud je potřebuje, měl by k tomu sloužit jiný účet, který bude mít tvar username-admin.

Eduroam jméno

Jméno pro Eduroam se musí skládat z uživatelského jména a realm, který slouží jako identifikátor domovské instituce. Vlasní autentizace uživatele tak může být delegována na domácí RADIUS servery. Uživatelské jméno na FJFI bude mít tvar "sAMAccountName"@fjfi.cvut.cz. Bylo by dobré, aby toto jméno bylo zároveň platnou mailovou adresou uživatele. Pomocí eduroam atributů v AD bude možné zablokovat samostatně přístup k Eduroam účtu bez blokace vlastního AD účtu.

FIXME: zajištění přístupu hostů k WiFi bude tedy na správcích Windows

Mailové adresy

Všichni uživatelé budou mít adresu ve tvaru "sAMAccountName"@fjfi.cvut.cz (tedy stejnou jako "Eduroam jméno"), zaměstnancům bude navíc automaticky generována adresa ve tvaru Jméno.Příjmení@fjfi.cvut.cz. V případě konfliktu nebude adresa automaticky vytvořena, ale o vzniklé situaci bude ihned informován správce mailem. Uživatelům Terezy může být ručně přidána ještě adresa ve tvaru Jméno.Příjmení@tereza.fjfi.cvut.cz.

Historické oficiální adresy user@km1.fjfi.cvut.cz a user@troja.fjfi.cvut.cz budou zachovány jen na požádání (stejně jako tomu bylo/je pro user@br.fjfi.cvut.cz). Příjem bude zajištěn přímo na Exchange, nebude docházet k žádnému přepisování příchozích ani odchozích neoficiálních adres. Adresy user@kmk.km.fjfi.cvut.cz budou zrušeny, jelikož existovali jen z důvodu interního směrování mailů.

U nově automaticky vytvářených adres je potřeba zkontrolovat, jestli obsahují jen povolené znaky [a-zA-Z0-9_.-] (hlavně při generování adres Jméno.Příjmení@fjfi.cvut.cz, protože to občas obsahuje speciální jinde neošetřené znaky). Pokud nová adresa nesplňuje tyto požadavky, bude o tom správce informován mailem.

Heslo

Uživatelská hesla musí mít definovanou minimální složitost, aby se zabránilo slovníkovým útokům. Heslo musí být minimálně 8 znaků dlouhé a musí obsahovat alespoň dvě skupiny znaků (písmena malá/velká, číslice, speciální znaky). FIXME: Je potřeba každé heslo zkontrolovat proti slovníku. Pro host/service kerberos účty mohou být hesla úplně neznámé náhodně generované znaky. Je potřebné/vhodné mít různé reálné účty pro různé hosty?

Platnost hesla není omezena, ale pokud to bude situace v budoucnu vyžadovat, může být zavedena povinnost pravidelné změny hesla.

Pro přihlašování je nutné vždy používat zabezpečené spojení (TLS/SSL nebo nějaký ekvivalent). Služby u nichž nelze zajistit vyzrazení hesla po nezabezpečeném kanále nesmí být vůbec provozovány (např. IMAP, HTTP, ...). U ostatních musí dojít k odmítnutí spojení před vlastním přenosem hesla.

Skupiny

Skupiny by měli obsahovat stejně jako uživatelská jména znaky [a-z0-9_-] (malá písmena, číslice, podtržítko a pomlčka). Dále je vhodné, aby délka názvu skupiny nepřevyšovala 8 znaků. Důvodem je maximální možná kompatibilita s Unix systémy. Kvůli unixovým resp. POSIX compatible systémům musí každá skupina obsahovat posixGroup třídu. Skupinové ID třídy musí být jedinečné >= 1000.

Každý uživatel bude dle informací v Usermapu automaticky zařazen do skupin zaměstnanec/doktorand na příslušné katedře (existence všech skupin není povinná, neexistence těchto skupin nebude brána jako chyba při synchronizaci účtů). Navíc bude možné ručně přidat každého uživatele do skupiny vyhrazené každé katedře. Poslední možností je přidaní nazvu skupiny do atributu fnspeForceGroup a to při synchronizaci způsobí, že uživatel bude přidán jako memberOf odpovídající skupiny. Mohou existovat následující standardní skupiny:

Skupiny
název GID využití
1000-1099 vyhrazeno pro potřeby fakulty (1000-1010 vyhrazeno pro automaticky spravované skupiny)
users 1000 standardní skupina pro všechny uživatelské účty
emp 1001 skupina pro všechny zaměstnance
phd 1002 skupina pro všechny phd studenty
1X00-1X99 vyhrazeno pro potřeby katedry (1X00-1X10 vyhrazeno pro standardní automaticky spravované skupiny)
"depName" 1X00 ručně spravovaný seznam lidí na dané katedře
"depName"_emp 1X01 zaměstnanec katedry (automaticky synchronizováno dle Usermapu)
"depName"_phd 1X02 phd student katedry (automaticky synchronizováno dle Usermapu)
"depName"_all 1X03 "depName"+"depName"_emp+"depName"_phd

Pokud bude nějaká katedra (organizační jednotka) potřebovat další skupiny pro svoji vlastní potřebu, potom by měli mít jako prefix název katedry, aby se jména skupin nemohli v budoucnu dostat do konfliktu mezi různými katedrami. Skupinové GID si katedra bude volit z přiděleného rozsahu.

Rozsahy GID pro katedry
skupina rozsahy GID
users 1000
km 1100-1199
kf 1200-1299
kj 1300-1399
kipl 1400-1499
kfe 1500-1599
kmat 1600-1699
kjch 1700-1799
kdaiz 1800-1899
kjr 1900-1999
kse 2000-2099
dekanat 2100-2199
tereza 2200-2299

Diskové služby

Rozdělení písmen pro disky
písmeno funkce / poznámka
A-L vyhrazeno pro lokální zařízení (disky, cdrom, uživatelské síťové disky, ...)
M-P vyhrazeno pro potřeby fakulty
M: sdílená složka v rámci katedry
N: síťový domovský adresář
O: síťový adresář s aplikacemi (replikovaný mezi všemi fileservery?)
P: veřejně přístupná složka (FIXME: práva rozdělená na adresáře po katedrách?)
Q-Z vyhrazeno pro potřeby administrátorů (globální, v rámci kateder, ...) - informace o využití těchto písmen je nutné uvést do této tabulky!
 ?-? vyhrazeno pro potřeby lokálního uživatele
 ?: síťový adresář se sdílenými složkami (globalní, katedry, skupiny, ...)
 ?: síťový adresář s aplikacemi, dokumentacemi, ...

FIXME: odkud budou exportovány sdílené disky (Břehovka x Trojanka x Trója)

FIXME: využití DFS? využití replikace?

Konfigurace Linuxu/Unixu

Pro jednoduchost není dobré vytvářet více domén. Uživatelé by pak museli používat jméno včetně jména domény, což by bylo dost nepohodlné a některé aplikace by asi špatně rozdýchávali uživatelská jména ve tvaru DOMAIN\username.

Různé možnosti integrace Windows s Unixy jsou docela podrobně popsány v dokumentu Windows Security and Directory Services for UNIX v1.0. Dále bude popsán jen jeden ze způsobu, který je vhodné použít u nás.


Konfigurace účtu v AD

Pro rozumnou funkci AD pro unixová prostředí je potřeba mit doménu a forest nastaven na nativní windows 2003 mód, protože jinak AD nemá podporu po "dynamic linked auxiliary classes". Vzhledem ke kopatibilitě je vhodné k uživatelskému účtu v AD přidat následující auxiliary classes: inetOrgPerson, posixAccount. Dále je potřeba udržovat některé atributy synchronizované, protože různé aplikace mohou využívat buď jeden nebo druhý: uid = msSFU30Name = sAMAccountName

Uživatel musí mít vyplněny následující atributy posixAccountu:

  • uid = msSFU30Name = sAMAccountName
  • uidNumber - jedinečné číslo z intervalu [1000-30000)
  • gidNumber - zatím jedna skupina "users" s gidNumber = 1000
  • loginShell - /bin/bash
  • unixHomeDirectory - /home/"sAMAccountName"
  • gecos - ASCII "givenName sn"

Synchronizace času

Pro správnou funkci Kerbera je nutná synchronizace času mezi autentizovaným systémem a KDC serverem (tolerance 5 minut). Je potřeba, aby se klienti synchronizovali proti nějakému přesnému časovému zdroji. Pro tyto účely zde běží NTP server na adrese ntp.fjfi.cvut.cz. Pokud nebude čas správně synchronizován, pak přestane fungovat nejen přímá autentizace uživatelů, ale také další služby jako např. adresáře sdílené přes sambu.


Uživatelské informace

Získávají se pomocí NSS a v případě Windows AD domény k nim lze přistupovat několika různými způsoby (export do "passwd", LDAP, winbind). Kvůli zachování stejných UID na všech stanicích nelze (jednoduše) použít winbind. LDAP přístup je asi "nejčistší" řešení, ale bude se muset vyzkoušet jestli je výkonostně přijatelný (jinak lze provádět exporty z LDAP do standardních souborů jako tomu je/bylo u Novell NDS). V případě problémů s výkonem LDAPu by stálo za zvážení použít nscd daemona pro cachování získaných informací (potřeba otestovat, protože před pár lety docela zlobil při použití proti Novell LDAP).

Pro zpřístupnění informací přes LDAP je potřeba nainstalovat "nss_ldap" a upravit konfigurace /etc/nsswitch.conf a /etc/ldap.conf (pro práci s LDAP nástroji je ještě vhodné upravit /etc/openldap/ldap.conf).

  • /etc/nsswitch.conf
...
passwd:     files ldap
shadow:     files ldap
group:      files ldap

hosts:      files dns wins
...
  • /etc/ldap.conf
host ldap1.fjfi.cvut.cz ldap2.fjfi.cvut.cz ldap3.fjfi.cvut.cz ldap4.fjfi.cvut.cz
base dc=fjfi,dc=cvut,dc=cz
ldap_version 3
# In case AD doesn't allow anonymous binds
# binddn cn=proxy nss,ou=special,dc=fjfi,dc=cvut,dc=cz
# bindpw secret
pam_min_uid 1000
# RFC 2307 (AD) mappings
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member
pam_login_attribute sAMAccountName
pam_filter objectclass=User
pam_password ad
# Disable SASL security layers. This is needed for AD.
sasl_secprops maxssf=0
  • /etc/openldap/ldap.conf
BASE   dc=fjfi,dc=cvut,dc=cz
URI    ldaps://ldap1.fjfi.cvut.cz ldaps://ldap2.fjfi.cvut.cz ...
TLS_CACERTDIR /etc/openldap/cacerts

Pro přístup přes LDAP rozhraní k Windows AD je potřeba na firewallu povolit porty 389 TCP, 389 UDP, 636 TCP (z celého internetu). Pro zabezpečený přístup přes LDAP se používají x509 certifikáty. Klient musí důvěřovat certifikační autoritě, která podepsala certifikáty používané pro zabezpečenou LDAP komunikaci. Z tohoto důvodu je nutné, aby všechny Windows AD stroje měli platné certifikáty vydané Cesnet CA nebo SureServer EDU.

Autentizace

Existuje více způsobů jak autentizovat uživatele z Windows AD (Kerberos, LDAP, winbind, RADIUS, ...). Nejrozumnější vlastnosti má Kerberos, který je přímo navržen pro bezpečnou autentizaci uživatelů. Navíc uživatel získá Kerberos ticket, který může dále používat pro autentizaci k dalším službám (SSO).

Na linuxu je potřeba naintalovat balík "krb5-workstation" a "pam_krb5", je potřeba mít povolen přístup na KDC (Key Distribution Center) na portech 88 TCP, 88 UDP, 749 TCP (z celého internetu). Konfigurační soubor /etc/krb5.conf by mít např. následující obsah

...

[libdefaults]
default_realm = FJFI.CVUT.CZ
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 14d
forwardable = yes

[realms]
FJFI.CVUT.CZ = {
 kdc = krb1.fjfi.cvut.cz:88
 kdc = krb2.fjfi.cvut.cz:88
 kdc = krb3.fjfi.cvut.cz:88
 kdc = krb4.fjfi.cvut.cz:88
 admin_server = krb.fjfi.cvut.cz:749
 default_domain = fjfi.cvut.cz
}

[domain_realm]
.fjfi.cvut.cz = FJFI.CVUT.CZ
fjfi.cvut.cz = FJFI.CVUT.CZ

...

Pro autentizaci na stanici je potřeba ještě zkonfigurovat PAM moduly. Na RedHatu (RHEL5) stačí upravit soubor /etc/pam.d/system-auth (FIXME: test this config)

#%PAM-1.0
auth        required      pam_env.so
auth        sufficient    pam_krb5.so minimum_uid=1000
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore]  pam_krb5.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_krb5.so  minimum_uid=1000 use_authok debug
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_krb5.so
#session     required      pam_mkhomedir.so umask=0022 skel=/etc/skel

Pro otestování autentizace lze použít následující příkaz:

kinit username

Host Kerberos Key

Pokud bude mít systém/služba vlastní Kerberos klíč, potom je možné s platným uživatelským Kerberos ticketem přistupovat na tyto systémy/služby bez dalšího zadávání hesla.

# Na windows vytvořit hostkey
# - account je účet v AD pro host/hostname
C:> Ktpass princ host/hostname@FJFI.CVUT.CZ mapuser account -pass password out unixmachine.keytab
# V linuxu importovat
ktutil
ktutil: rkt unixmachine.keytab
ktutil: list
ktutil: wkt /etc/krb5.keytab
ktutil: q

Je také možné vytvářet tyto klíče přímo na unix systémech, jak je popsáno na Interoperability with Microsoft Windows 2000 Active Directory and Kerberos Services.

Samba

Samba 3.x umožňuje uživatelům Windows používat vysdílené disky včetně všech přístupových práv. Aby to fungovalo, je potřeba zkonfigurovat /etc/samba/smb.conf a zaregistrovat daný systém v AD.

workgroup = FJFI # nebo název katedry
server string = Samba Server %h (%v)
security = ADS
realm = FJFI.CVUT.CZ
preferred master = no
# tohle není (asi) potřeba, když se nepoužívá winbind
#winbind enum users = Yes
#winbind enum groups = Yes
#winbind use default domain = Yes
#idmap uid = 10000-20000
#idmap gid = 10000-20000

Registrace se provádí příkazem (musí fungovat překlad přidělené hostname <-> IP, jinak nebylo možné úspěsně donkončit registraci):

net ads join -UAdministrator%password

Opět je nutné povolit na firewallu Windows Serveru porty 137 TCP/UDP, 138 TCP/UDP, 139 TCP/UDP, 445 TCP/UDP, 389 TCP/UDP, 636 TCP. Vzhledem k použítí Kerbera pro autentizaci je nutné mít synchronizovaný čas.