Doména FJFI
Contents
Servery
jméno | umístění | funkce / poznámka |
---|---|---|
??? | Břehová | hlavní DC, fileserver |
??? | Břehová | Exchange |
??? | Trojanova | DC, fileserver |
??? | 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.
- 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, ...
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 |
SNMP | 161 TCP+UDP | pro management stroje (nms.fjfi.cvut.cz) |
Samba | 137,138,139,445 TCP+UDP | minimálně rozsah FJFI (ČVUT?) |
Uživatelské účty
- ou=Auto - automaticky synchronizované učty proti stavu v Usermapu
- ou="Department"? - manuálně spravované učty (převážně zaměstnanci)
- ou=Guest - povinná doba expirace
- ou=Special - učty se specálními přístupovými právy
jméno | využití a práva |
---|---|
Proxy Eduroam | read pro sAMAccountName, fnspeEduroam* |
Proxy Mailgw | read pro fnspeMail*, amavis* |
Proxy NMS | read/write konfigurace účtu fnspe*, amavis*, targetAddress, read proxyAddress |
Proxy Host | účet pro Kerberos host ticket host/hostname@FJFI.CVUT.CZ (FIXME: práva?) |
Proxy Service | účet pro Kerberos service ticket service/hostname@FJFI.CVUT.CZ (FIXME: práva? jednotlivé služby?) |
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?) |
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 a to rok po opuštění FJFI (FIXME: přístup k většině služeb bude blokován ihned?).
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.
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.
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 bude také vygenerována druhá adresa a to standardně 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í.
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.
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 - příslušný rozah nám přidělí VIC ČVUT.
V současnosti je pořeba do Active Directory potřeba přidat následující schemata:
- fnspeUser - uživatelské informace (osobní číslo, Eduroam účet, zpracování mailů, ...) - FIXME: toto není finální verze!
- amavisAccount - nastavení filtrování spamů/virů/... na mailgw
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.
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"
NTP - synchronizace času
Pro správnou funkci Kerbera je nutná synchronizace času mezi autentizovaným systémem a KDC serverem. Ve standardní konfiguraci w2k3 serveru je tolerance 5 minut. 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 dc1.fjfi.cvut.cz dc2.fjfi.cvut.cz dc3.fjfi.cvut.cz dc4.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://dc1.fjfi.cvut.cz ldaps://dc2.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 = krb-fjfi-1.fjfi.cvut.cz:88 kdc = krb-fjfi-2.fjfi.cvut.cz:88 kdc = krb-fjfi-3.fjfi.cvut.cz:88 kdc = krb-fjfi-4.fjfi.cvut.cz:88 admin_server = krb-fjfi-admin.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
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.