Revision as of 16:21, 7 September 2024

Servery

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)
• Webmail - alias webmail, mail

Sites

V doméně jsou definovany nasledující sites:

FJFI-Centrum (obsahuje DC ARK1, ARK2)

FJFI-Troja (nalezi do ni DC Troja1)

FJFI-Decin (nalezi do ni DC DRK)

Replikace probihaji v hvezdicove topologii.

1. Inter-site-transport: type=IP, cn=Centrum-to-Troja, repllinterval=15 (min.), siteList= Centrum, Troja)

2. Inter-site-transport: type=IP, cn=Centrum-to-Decin, repllinterval=15 (min.), siteList= Centrum, Decin)

Server DRK (Decin) je pripojen pomoci VPN (IPvSec-RRAS) prostrednictvím serveru MRK2

Parametry pripojeni:

- IPv4 RAS

- Windows Authentication

- WAN Miniport FJFI-Trojanka (PPTP)

Firewall

Obecné nastavení firewallu lze nalézt v dokumentu Active Directory Replication Over Firewalls

Další informace lze nalézt v KB 555381, 179442, 832017

Aktuální konfiguraci firewallu si lze zjistit následujícími příkazy:

# z registrů
reg.exe query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile /s
# nebo přes netsh (bohužel nefunguje dumpnutí konfigurace...)
netsh firewall show config verbose = ENABLE

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.

Microsoft si bohužel pro DDNS update vytvořil vlastní zabezpečený protokol GSS-TSIG, který je podporován až v ISC BIND 9.5 (jejich DNS server totiž původně vychází z ISC BIND 4, ale neimplementovaly RFC standardy pro zabězpečení). Aby fungovala Kerberizovaná komunikace s Windows Servery, je navíc potřeba mít v ISC BINDu zakompilovanou podporu "spnego" (upozornění: RedHat nyní standardně kompiluje binárky BINDu 9.6 s volbou --disable-isc-spnego takže bez rekompilace nelze použít standardní rpm balíčky). V konfiguraci named.conf je potřeba přidat:

options {
  ...
  tkey-gssapi-credential "DNS/ns.fjfi.cvut.cz";
  # tkey-domain "FJFI.CVUT.CZ";
  ...
}

...
zone "fjfi.cvut.cz" {
  type master;
  file  "data/fjfi.cvut.cz.zone";
  check-names ignore;
  ...
  update-policy {
    // grant FJFI.CVUT.CZ ms-self fjfi.cvut.cz. ANY
    // grant FJFI.CVUT.CZ ms-subdomain fjfi.cvut.cz. ANY
    // grant DCX$@FJFI.CVUT.CZ self fjfi.cvut.cz. ANY
    grant DCX$@FJFI.CVUT.CZ name dcX.fjfi.cvut.cz. ANY;
    grant DCX$@FJFI.CVUT.CZ subdomain _tcp.fjfi.cvut.cz. ANY;
    grant DCX$@FJFI.CVUT.CZ subdomain _udp.fjfi.cvut.cz. ANY;
    grant DCX$@FJFI.CVUT.CZ subdomain _msdcs.fjfi.cvut.cz. ANY;
    grant DCX$@FJFI.CVUT.CZ subdomain _sites.fjfi.cvut.cz. ANY;
    grant DCX$@FJFI.CVUT.CZ subdomain DomainDnsZones.fjfi.cvut.cz. ANY;
    grant DCX$@FJFI.CVUT.CZ subdomain ForestDnsZones.fjfi.cvut.cz. ANY;
  };
};
...

Dále je potřeba vygenerovat pro DNS server příslušný keytab, ktery bude sloužit k zabězpečení DDNS mezi ISC BIND a Windows DNS klientem právě pomocí GSS-TSIG. Pokud se bind spouští v chrootu, musí být správný krb5.conf a named.keytab v konfiguračním adresáři /var/named/chroot/etc. K vygenerování keytabu na windows lze použít příkaz (nezapomenout, že uvedené doménové jméno musí být na linuxovém stroji uvedeno v /etc/hosts, jinak nefunguje kerberos autentizace)

# smazání/vytvoření computer accountu NS-SVC-DNS$ v AD
dsrm -noprompt "CN=NS-SVC-DNS,CN=Computers,DC=fjfi,DC=cvut,DC=cz"
dsadd computer "CN=NS-SVC-DNS,CN=Computers,DC=fjfi,DC=cvut,DC=cz"
# vytvoření keytabu (nutné použít novější verzi ktpass.exe, která se pro w2k3 dost špatně hledá)
ktpass -ptype KRB5_NT_PRINCIPAL -princ DNS/ns.fjfi.cvut.cz@FJFI.CVUT.CZ -mapuser FJFI\NS-SVC-DNS$ -pass +rndPass +Answer -out named.keytab

Kerberos na unix systémech je case-sensitive pro "uživatelský" (service) principal, tj. je nutné použít přesný tvar, který byl zadán při generování principalu DNS/ns.fjfi.cvut.cz@FJFI.CVUT.CZ. Odpovídající text musí být vyplněn i v named.conf ve položkách tkey-gssapi-credential a tkey-domain. Pokud nejsou tyto hodnoty správně vyplněny, pak daemon buď vůbec nenastartuje (s nepříliš srozumitelnou chybovou hláškou) a nebo není schopen ověřit kerberizované spojení.

Novější verze MIT Kerbera navíc standardně nepodporují starší/slabé šifry. Aktuálně máme otestováno pouze používání těchto starých šifer (konkrétně arcfour-hmac, což je dáno historickými důvody, kdy první konfigurace byla prováděna ještě proti w2k3 serveru) a v takovém případě je nutné MIT Kerberu povolit používání starých šifrovacích algoritmů pomocí volby allow_weak_crypto = true.

Windows DNS klient je standardně nakonfigurován tak, že se nejprve pokouší o DDNS update bez zabezpečení a teprve v případě chyby zkusí GSS-TSIG zabezpečení. Toto chování se dá upravit nastavením registrů.

reg.exe add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v UpdateSecurityLevel /t REG_DWORD /d 0x100 /f

Na Windows 2008 R2 je navíc potřeba aplikovat následující hotfix, protože jinak registrace záznamů pomocí DDNS do ISC Bind skončí chybou (detaily).

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

Mám takový pocit, že standardně se tímto způsobem neupdatují záznamy pro různé AD site. Ty jsou vytvořeny/updatovány jen v okamžiku jejich konfigurace. Pokud se tedy informace o AD site nevytvoří musí se daná AD site zrušit a vytvořit znova (což není moc přijatelné řešení) nebo použít skript DnsAD.py, který vytvoří/smaže všechny potřebné záznamy podle aktuálního stavu v AD.

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.

# pro test DDNS by mělo stačit zadat
dcdiag /test:RegisterInDNS /DnsDomain:dc.fjfi.cvut.cz

# pro testy a opravu by mohl posloužit příkaz
# NOTE: tento příkaz není podporován na nových w2k8
netdiag /test:dns /fix

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

Property Sets GUIDs

Slouží k definování standardních přístupových práv na skupiny atributů. Ve schématu tomu odpovídá atribut attributeSecurityGUID. Více infromací zde, zde, zde a zde

General-Information: 59ba2f42-79a2-11d0-9020-00c04fc2d3cf
Public-Information: e48d0154-bcf8-11d1-8702-00c04fb96050
Private-Information: 91e647de-d96f-4b70-9557-d63ff4f3ccd8
Personal-Information: 77b5b886-944a-11d1-aebd-0000f80367c1
Email-Information: e45795b2-9455-11d1-aebd-0000f80367c1
Web-Information: e45795b3-9455-11d1-aebd-0000f80367c1
Membership: bc0ac240-79a9-11d0-9020-00c04fc2d4cf
User-Logon: 5f202010-79a5-11d0-9020-00c04fc2d4cf
User-Account-Restrictions: 4c164200-20c0-11d0-a768-00aa006e0529
Exchange-Information: ???

Bohužel všechny objekty dědí navíc read práva na všechny atributy od kořene domény přes uživatele Everyone - opravdu netuším, co tímhle nastavením v Microsoftu sledují...

Exchange-Information property set je přidán po instalaci Exchange 2007 resp. Exchange 2010. Malinko nepříjemné je to, že do tohoto property setu jsou přesunuty některé atributy, které dříve byly v Public resp. Personal property setu a tím pádem "veřejně" přístupné pro čtení. Aplikace které atributy přesunuté do Exchange-Information property setu používají k nim tedy mohou ztratit přístup a je potřeba příslušným způsobem upravit přístupová práva.

Pro naše učely bude nejvhodnějsí přidat všechny atributy ze třídy amavisAccount do Public-Information property setu (logicky by asi patřili spíš mezi Email-Information, ale proxyAddresses a targetAddress jsou také součástí toho Public setu). Atributy z třídy fnspeAccount vesměs do Public-Information property setu, protože ho uživatel nemá právo přímo modifikovat (možná by bylo vhodnější pro některé atributy použít property set Private-Information, ale ten je až standardní součástí Windows 2008 serveru - backport tohoto property setu bych raději neriskoval s ohledem na nejasný upgrade domény). Je také dobré mít na paměti, že některé aplikace mohou (při instalaci) přesunout atributy do jeného přoperty setu, na který nebudou nastavany správně "naše" přístupová práva (např. Exchange 2007 přesouvá svoje atřibuty z Public-Information do Exchange-Information property setu)

Některé atributy fnspeAccount nejen, že nesmí být možné měnit, ale ani je číst. Týká se to hlavně hesel (fnspeEduroamPassword, fnspeWifiPassword). Pro ty je asi nejvhodnější použít vlastnosti LDAP schematu "Confidentiality Bit" (více zde, zde. Takto označený atribut nemají právo číst žádní uživatelé s vyjímkou administrátorů.

Uživatelské účty

• veškeré organizační jednotky s běžnými uživatelskými účty budou pod ou=People,dc=fjfi,dc=cvut,dc=cz - nesmí zde být vytvářeni uživatelé s nějakou formou admin práv (kvůli zabezpečení)
• 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
• zvláštní postavení bude mít skupina ou=Specials pro učty se specálními přístupovými právy - ta musí být přímo pod dc=fjfi,dc=cvut,dc=cz (z hlediska bezpečnosti)

Práva v Active Directory

U uživatelů (ou=People,dc=fjfi,dc=cvut,dc=cz) zachovat standardní nastavení s následujícími vyjímkami:

• nesmí mít přístup k atributům ve třídě fnspeAccount, amavisAccount u ostatních uživatelů
• nesmí mít právo read/search ani vlastní atribut fnspeEduroamPassword, fnspeWifiPassword
• vlastník má právo nastavovat fnspeEduroamPassword, fnspeWifiPassword (tohle není nezbytně nutné)
• vlastník si může libovolně měnit atributy amavisAccount (tohle není nezbytně nutné)
• ani vlastník nemá právo nastavovat žádné další ctu*, fnspe* atributy
• shrnuto - jestli je to jednodušší pro realizaci, tak bych (zatím) první bod rozšířil i na samotného vlastníka

Nastavit práva specielním účtům podle níže uvedené tabulky. Uvedeno je jen kam a na co má mít daný účet přístup - to znamená, že k ostatním položkám nesmí mít přístup.

Typy účtů

• konto (objectClass=user)
• kontakt (objectClass=contact)
• unix (objectClass=posixAccount)
• eduroam (objectClass=fnspeEduroamAccount)
• fnspeAccount (objectClass=fnspeAccount)
• fjfi konto (objectClass=fnspeAccount)
• 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ěstnanci/spolupracovníkovi FJFI se automaticky vytvoří účet v ou=People se standardními přístupovými právy. Další umístění závisí na personálním zařazení konkrétní osoby. Náleží k určité organizační jednotce (katedra, děkanát...), je zaměstnanec a nepatří k žádné organizační jednotce (Auto_emp) nebo je student a nepatří k žádné organizační jednotce (Auto). Umístění je průběžně editováno v souladu s údaji v Usermapu. Pokud bude uživatel potřebovat nějaké individuální nastavení účtu v AD, může být přesunut do příslušné organizační jednotky (podsložka "Manual", která nepodléhá automatické správě). Účty zrušené v Usermapu budou s odstupem 30 dnů přesunuty do ou=Trash a zablokovány. 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í na "kill" a uživatel je o chystaném zrušení jeho účtu informován emailem. V tomto stavu účet setrvá konfigurovatelnou dobu 30 dnů, kdy si uživatel bude moci stáhnout svá data nebo si zařídit přesunutí do organizační jednotky ou=Outliving nebo jiné, kde nebude jeho účet automaticky rušen. Za normálních okolností přejde účet i na FJFI do stavu "zombie". Takový účet bude zablokován a přesunut do ou=Trash. Po 14 měsících od přesunu do ou=Trash budou účty automaticky odstraněny včetně uživatelských dat (domovské adresáře, maily, databáze, ...) Stav je uchováván v atributech fnspeStatus, fnspeStatusTimestamp.

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

• vzniká na základě synchronizace učtů s Usermapem nebo ručně,
  • staus je nastaven na hodnotu "init"
  • aktivací účtu uživatelem s ověřením proti účtu v Usermapu se status mění na "active"
    • všechny důležité informace obdrží uživatel v emailové zprávě po aktivaci
  • je automaticky synchronizován dle informaci v Usermapu (spojeno přes uživatelské osobní číslo)
• je automaticky zrušen, pokud zmizí z Usermapu nebo oUser.status bude "zombie"
  • lokální status je nastaven na "kill" a poznamená se timestamp
  • účet typu stu
    • uživatel obdrží info o chystaném zablokování jeho účtu emailem
    • po 30 dnech je odebrán z organizačních jednotek a skupin
    • přesunut do ou=Trash a zablokován, status nastaven na "zombie" a poznamená se timestamp
    • po dalších 90 dnech je odstraněn včetně dat
  • účet typu emp
    • uživatel obdrží emailem info o zachování účtu včetně emailu, pokud to výslovně nežádá opak
    • po 30 dnech je odebrán z organizačních jednotek a skupin
    • přesunut do ou=katedra\emerit, status nastaven na "emerit" a poznamená se timestamp

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]

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

Deprecated!

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

Synchronizační skripty

svn co https://comp.fjfi.cvut.cz/repos/umapsync umapsync

FnspeCmdService

Toto je služba, která poslouchá na definovaném portu a umožňuje spustit lokání skript s parametry, které přijdou ze sítě. V tuto chvíli slouží k vytváření uživatelských mailboxů při aktivaci konta a nastavení přesměrování FJFI www stránek. Aktuální verzi je možné stáhnout na:

svn co https://comp.fjfi.cvut.cz/repos/cmd_service cmd_service

installutil.exe "c:\cesta\k\binarce\FnspeCmdWindowsService.exe"
# pro odinstalaci lze použít příkaz:
# installutil.exe /u "c:\cesta\k\binarce\FnspeCmdWindowsService.exe"

HKEY_LOCAL_MACHINE\SOFTWARE\FnspeCmdService
port - číslo portu, kde služba poslouchá (3210)
script - skript, který má spustít (cmd.vbs)

HKEY_LOCAL_MACHINE\SOFTWARE\FnspeCmdService\config
# mapování předaných dat na parametry příkazové rádky
# key ..... příkaz cmd_service
# value ... parametry výše uvedeného skriptu

# výpis aktuální konfigurace
reg.exe query HKEY_LOCAL_MACHINE\SOFTWARE\FnspeCmdService
reg.exe query HKEY_LOCAL_MACHINE\SOFTWARE\FnspeCmdService\config

[HKEY_LOCAL_MACHINE\SOFTWARE\FnspeCmdService]
"port"=dword:00000c8a
"script"="c:\\scripts\\umapsync\\umapsync.vbs"
"timeout"=dword:00007530

[HKEY_LOCAL_MACHINE\SOFTWARE\FnspeCmdService\config]
"mail"="mailbox create"
"web"="web redirect"
"test"="/quiet test log"

telnet jmeno.stroje.s.bezici.sluzbou port
mail username
OK/FAIL

telnet jmeno.stroje.s.bezici.sluzbou port
web username http://nejaka.domena.cz/adresa
OK/FAIL

Návratová hodnota OK/FAIL je nastavena podle toho, jestli byl skript uspěšně vykonán a skončil s exit kódem 0. Je-li navrácena chybová hodnota FAIL, bude v application event logu poznamenáno, kde nastala chyba. Pokud došlo k chybě při vykonávání skriptu, budou podrobnosti v log souborech vykonávaného skriptu.

FnspeLibrary - synchronizace 2010

Vzhledem k horší resp. žádné podpoře vbscriptu (resp. lepší podpoře powershell) v novějších verzích w2k8 serverů a Exchange2010 budou synchronizační skripty přepsány do C# a powershellu. Původní idee zmíněné výše zůstávají nadále platné, pouze se mění prostředky resp. konkrétní jazyk implementace (navíc dojde pouze k pročištění rozhraní objektů potřebných pro správu uživatelských účtů).

Aby vše fungovalo, je potřeba provést následující instalace / konfigurace:

ADScripts - synchronizace 2014

Přepis FnspeLibrary přímo do powershellu z důvodu malé flexibility v úpravě a kompilaci C# DLL knihovny. Rozhraní pro přístup k uživatelským datům zůstalo stejné jako v případě FnspeLibrary, rozdíl je pouze v několika řádcích inicializace a ta je demonstrována v example-usermap.ps1. Nové powershell rozhraní navíc přistupuje přímo k datům v usermap LDAPu a databázi Oracle obsahující číselníky (telefony, adresy, funkce ...).

# zdrojové soubory powershell skriptů
# (nejprve je nutné požádat správce gitlab o přidaní do skupiny comp)
git clone https://gitlab.fjfi.cvut.cz/comp/adscripts.git

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).

Všechna uživatelská jména musí být přebírána z ČVUTího IdM (aktuálně se přebírají stále z Usermapu), kde by měli být zavedeni všichni uživatelé a to buď jako klasičtí studenti/zaměstnanci nebo hosté ČVUT (do budoucna bude existovat aplikace na zakládání ČVUTích host účtů).

ČVUT uživatelská jména jsou maximálně 8 znaků dlouhá a standardně se vytváří z pěti písmen příjmení a třech písmen z křestního jména. Pokud by nastal konflikt s existujícím jménem, je konec jména změněn na číslo, které se inkrementuje (např. novakj35). Uživatelská jména jsou neměnná (ani v případě, že se někdo vdá, rozvede, ...) a nebudou nikdy recyklována.

Speciální účty

Pokud je potřeba založit nějaký speciální účet, který nemá odpovídající záznam v ČVUT IdM, musí být použité jméno zavedeno na blacklist, aby takový účet nemohl v IdM v budoucnu nikdy vzniknout. Takové uživatelské jméno by nemělo obsahovat mezery a mělo by 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_, ???). Jedná se např. o standardní Windows/Linuxové účty (admin, root, http, guest, ...). Navíc speciální účty ve Windows AD by měli být v samostatném kontejneru ou=Special,dc=fjfi,dc=cvut,dc=cz.

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. Takový účet ale nesmí být založen v ou=People,dc=fjfi,dc=cvut,dc=cz, protože by zde mohla vzniknout možnost privilege escalation některého ze speciálních účtů.

Pokud je/byl uživatel někdy členem skupiny administratorů, potom si tuto informaci AD poznamená do atributu adminCount, který podle dokumentace znamená: "Indicates that a given object has had its ACLs changed to a more secure value by the system because it was a member of one of the administrative groups (directly or transitively)". Účty, které mají nastaven "adminCount" příznak může modifikovat jen administrátor (vlastnost AD) - speciální uživatel používaný přes rozhraní na NMS není admin a proto např. nastavováni hesel pro wireless sítě nebude z rozhraní na NMS fungovat. Toto je další důvod proč by běžné uživatelské účty neměli být v admin skupinách.

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é >= 2000 a < 4000.

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:

Rozsahy gidNumber pro různé součásti

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 UID/GID

Export

ldifde.exe -d OU=People,DC=fjfi,DC=cvut,DC=cz -f people.ldif
ldifde.exe -d OU=Groups,DC=fjfi,DC=cvut,DC=cz -f groups.ldif

Diskové služby

Rozložení a organizace dat:

• Fileservery ARK1 (Břehová), ARK2 (Trojanova), ARK3 (Děčín), Troja1 (Troja)
• Centrální datové úložiště (DFS)
  • servery AR1, ARK2
  • Replicated folders:
    • Home (osobní síťové adresáře)
    • Profile (roaming profiles pro účely učeben)
    • Share (obsahuje sdílené složky organizačních jednotek a jiné)
    • WWW (webhosting zaměstnanců)
    • WW2 (webhosting pro studenty)
  • Published to Namespace: FRK (Servers ARK1, ARK2)
• Lokální datové úložiště Děčín (SMB 2.1)
• server ARK3
  • Shared folders: Home, Profile, WWW, WWW2, Share
  • data jsou zde umístěna na základě pracovního/studijního zařazení

Kerberos

Nastavit následující konfigurace:

Maximum lifetime for user ticket: 26 hours

LDAP

Je potřeba upravit limity pro přístup k datům v Active Directory přes standardní LDAP rozhraní. Vcelku zajímavé informace jsou v KB 315071

• MaxPageSize "musí" být nastaveno minimálně na počet uživatelů+skupin - tedy 5000(?)

Pro korektní fungování SASL autentizace pomocí GSSAPI je navíc potřeba, aby LDAP servery měli korektní záznamy v DNS a to včetně odpovídajících jednoznačných reverzních záznamů (simple autentizace funguje i když nejsou DNS záznamy v pořádku, ale na druhou stranu vyžaduje přihlášení přes SSL zabezpečené platnými certifikáty).

Jednoduchý test přístupu k datům v AD se simple autentizací

# klasické SSL spojení
ldapsearch -H ldaps://ldap.fjfi.cvut.cz -b 'dc=fjfi,dc=cvut,dc=cz' -D 'FJFI\username' -W cn=username
# STARTTLS negotiation po navázání spojení
ldapsearch -ZZ -H ldap://ldap.fjfi.cvut.cz -b 'dc=fjfi,dc=cvut,dc=cz' -D 'FJFI\username' -W cn=username

Jednoduchý test přístupu k datům v AD s kerberos autentizací

# získání kerberos ticketu pro autentizaci LDAP spojení
kinit username@FJFI.CVUT.CZ 
# klasické SSL spojení
ldapsearch -O minssf=0,maxssf=0 -H ldaps://ldap.fjfi.cvut.cz -b 'dc=fjfi,dc=cvut,dc=cz' cn=username
# STARTTLS negotiation po navázání spojení
ldapsearch -O minssf=0,maxssf=0 -ZZ -H ldap://ldap.fjfi.cvut.cz -b 'dc=fjfi,dc=cvut,dc=cz' cn=username

Příklad simple autentizace v pythonu:

import ldap
# Set LDAP options, e.g.:
# ldap.set_option(ldap.OPT_X_TLS_CACERTDIR, '/etc/pki/tls/certs')
# ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,, '/etc/pki/tls/certs/ca-bundle.crt')
# ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER)
conn = ldap.initialize("ldaps://ldap1.fjfi.cvut.cz,ldaps://ldap2.fjfi.cvut.cz")
# Now try StartTLS extended operation
# conn.set_option(ldap.OPT_X_TLS, ldap.OPT_X_TLS_DEMAND)
# conn.start_tls_s()
conn.simple_bind_s('FJFI\username', 'secret')
# print user data from AD
for dn, attrs in conn.search_s('OU=People,DC=fjfi,DC=cvut,DC=cz', \
                               ldap.SCOPE_SUBTREE, '(cn=username)'):
    print "%s: %s" % (dn, attrs)

Příklad SASL GSSAPI autentizace (s využítím keytabu) v pythonu:

import ldap, ldap.sasl, krbV
# use SASL GSS authentication using Kerberos keytab
conn = ldap.initialize("ldap://ldap1.fjfi.cvut.cz,ldap://ldap2.fjfi.cvut.cz")
# Now try StartTLS extended operation
#conn.set_option(ldap.OPT_X_TLS, ldap.OPT_X_TLS_DEMAND)
#conn.set_option(ldap.OPT_X_SASL_SSF_MIN, 0)
#conn.set_option(ldap.OPT_X_SASL_SSF_MAX, 0)
#conn.start_tls_s()
context = krbV.default_context()
principal = krbV.Principal(name='host/name.fjfi.cvut.cz@FJFI.CVUT.CZ', context=context)
keytab = krbV.Keytab(name='/etc/krb5.keytab', context=context)
ccache = context.default_ccache(primary_principal=principal)
#ccache.init(principal)
ccache.init_creds_keytab(keytab=keytab, principal=principal)
sasl_auth = ldap.sasl.sasl({},'GSSAPI')
conn.sasl_interactive_bind_s("", sasl_auth)
# print user data from AD
for dn, attrs in conn.search_s('OU=People,DC=fjfi,DC=cvut,DC=cz', \
                               ldap.SCOPE_SUBTREE, '(cn=username)'):
    print "%s: %s" % (dn, attrs)

Při použití SASL (GSSAPI) autentizace a zabezpečeného přenostu dat přes STARTTLS (port 389) nebo SSL (port 636) je navíc potřeba OpenLDAP knihovně vysvětlit, aby nepoužívala "SASL privacy layers", které LDAP rozhraní AD nepodporuje (z hlediska zabezpečení je to pořád OK). V takovém případě je potřeba přidat do /etc/openldap/ldap.conf řádek s sasl_secprops minssf=0,maxssf=0 nebo přímo v kódu nastavit tyto parametry např. pomoci

conn.set_option(ldap.OPT_X_SASL_SSF_MIN, 0)
conn.set_option(ldap.OPT_X_SASL_SSF_MAX, 0)

Certifikáty

Naimportovat do domény kořenový certifikát a CRL CESNET CA, naimportovat intermediate CA a CRL pro aktuální serverové certifikáty.

Pro LDAP rozhraní AD je potřeba restart serveru po instalaci certifikátu do ??? certificate store (možná stačí restart příslušné služby - netestováno). Pro ostatní služby (např. IIS) je potřeba v příslušných konfiguračních nástrojích vybrat, který certifikát se má používat.

Exchange

Je nutné zrušit automatické generovaní emailových adres pomocí RUS (Recipient Update Service). Zkonfigurovat to lze přes Exchange System Manager -> Recipients -> Recipient Update Service. U všeho je potřeba nastavit update interval na "Never run".

Je nutné zkonfigurovat generovaní emailových adres pomocí RUS (Recipient Update Service) přes Exchange System Manager -> Recipients -> Recipient Update Service. Pro správné fungovaní všech požadovaných mailových adres nezavisle na vytvoření / zrušení mailstore na Exchange je potřeba zrušit přidávání a odstraňování "internetových" mailových adres (ty co jsou v atributu proxyAddresses s prefixem "smtp:" resp. "SMTP:".

Také je potřeba nastavit (při změnách je občas nutné restartovat příslušnou službu):

• zabránit příjmu mailů z jiných adres než je mailgw (nebo IP rozsah FJFI / ČVUT?) - nastavit přímo na firewallu
• limity na velikost přijímaných / odesílaných mailů kompatibilní s mailgw Exchange System Manager -> Global Settings -> Message Delivery -> Properties -> Recipient Filtering
• odmítání pošty pro neexistující uživatele Exchange System Manager -> Global Settings -> Message Delivery -> Properties -> Defaults a dále je potřeba nastavit Exchange System Manager -> Servers -> jméno serveru -> Protocols -> SMTP -> Default -> Properties -> General -> Advanced -> Filter Enabled
• nastavit odesílání pošty přes mailgw Exchange System Manager -> Servers -> jméno serveru -> Protocols -> SMTP -> Default -> Properties -> Delivery -> Advanced Delivery -> Smart host

Pro zjednodušení konfigurace Outlooku je možné navíc přiat do DNS záznamy pro autodiscovery Exchange > 2007 serveru.

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 [4000-30000)
• gidNumber - zatím jedna skupina "users" s gidNumber = 2000
• 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 (spuštěno hlavně pro účely monitoringu správného času na serverech, uživatelé by měli používat nějaké spolehlivé NTP servery, viz. dále). 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.

Pro synchronizaci času lze využít oficiální servery CESNETu:

tik.cesnet.cz
tak.cesnet.cz

• Synchronizace času v doméně
  • PDC emulator (ARK2) je manuálně nastaven na synchronizaci s externím zdrojem (tik.cesnet.cz,tak.cesnet.cz).
    • w32tm /config /syncfromflags:MANUAL /manualpeerlist:tik.cesnet.cz,tak.cesnet.cz /reliable:yes /update
    • Net stop w32time && net start w32time
  • Ostatní DC se synchronizují z domény.
    • w32tm /config /syncfromflags:DOMHIER /update
    • w32tm /resync /rediscover

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 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.

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
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 4000
# 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 ldaps://ldap3.fjfi.cvut.cz
TLS_CACERTDIR /etc/openldap/cacerts

Soubory

Aby fungovaní unixu/linuxu nebylo v neustále závislé na korektní funkci LDAP serveru, je možná vhodnější exportovat (v pravidelných intervalech) aktuální informace do standardních souborů. K tomu slouží následující skript napsaný v pythonu (nutné doplnit správné heslo pro proxy_posix účet případně upravit některé cesty dle lokálních potřeb):

svn co https://comp.fjfi.cvut.cz/repos/scripts/LdapAccount.py

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).

SSSD

Je řešení RedHatu pro autentizace (pam) a zpřístupnění informací o uživatelských učtech (nss). Má hromadu konfiguračních možností a obecně vypadá jako robustnějši řešení než např. samotný pam_ldap+nss_ldap (např. umožňuje cachování informací a "offline režim"). V principu lze použít dvě různé konfigurace pro lokální prostředí s AD. První řešení je na míru šité pro AD a vyžaduje, aby daný počítač byl joinutý do domény, druhé řešení používa klasickým způsobem LDAP a Kerberos rozhraní AD a nevyžaduje joinutí do domény.

Aby systém vůbec začal využívat služby SSSD daemona, můsí se požadavky na autentizaci přesměrovat na pam_sss modul a uživatelské učty musí využívat nss_sss. Je potřeba upravit (zkontrolovat) následující konfigurační soubory:

# /etc/nsswitch.conf
...
passwd:     files sss
shadow:     files sss
group:      files sss
...

# /etc/pam.d/password-auth resp. /etc/pam.d/system-auth

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so 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_sss.so

Na RedHat 6.x jsou tyto soubory automaticky správně modifikovány po instalaci SSSD. Tu lze provést následujícím příkazem:

# důležité je nainstalovat i 32bit verzi jinak nebudou běhat
# žádné aplikace zkompilované 32bit
yum install sssd sssd-tools sssd-client sssd-client.i686

Případně lze provést všechny potřebné modifikace PAM a NSS jedním příkazem

authconfig --update --enablesssd --enablesssdauth

SSSD AD

Relativně minimální konfigurace SSSD proti FJFI AD může vypadat následujícím způsobem. Aby níže uvedená konfigurace fungovala, musí být splněny následující požadavky

• počítač musí být zařazen v AD doméně (viz. Host/Service Kerberos Key)
  • musí existovat /etc/krb5.keytab
  • musí být zkonfigurován kerberos v /etc/krb5.conf (viz. např. ukázka konfigurace)
  • musí fungovat ověření pomocí keytabu kinit -k -t /etc/krb5.keytab host/name.fjfi.cvut.cz@FJFI.CVUT.CZ
• uživatelské účty musí mit posixAccount atributy (viz. Konfigurace účtu v AD)
• pam_sssd v konfiguraci /etc/pam.d/system-auth a /etc/pam.d/password-auth (viz. SSSD)
• sssd pro příslušné položky (passwd, shadow, group) v /etc/nsswitch.conf (viz. SSSD)
• zkonfigurovat sssd daemona
  • použitelné konfigurace sssd uložené v /etc/sssd/sssd.conf jsou uvedeny níže
  • konfigurační soubor musí mít nastavena práva: chmod 600 /etc/sssd/sssd.conf
  • při použití SELinuxu je potřeba mít správné securitz labely na konfiguracích: restorecon -R -v /etc
  • nutné povolit a nastartovat sssd daemona

# základní minimální konfigurace /etc/sssd/sssd.conf pro FJFI AD
[sssd]
domains = fjfi.cvut.cz
services = nss, pam
config_file_version = 2
# requires sssd >= 1.11.7 - RHEL6.6, RHEL7.1 (similar to samba option "winbind normalize names")
# (be aware that SSSD always maps given character back to space and that means it should not be used anywhere in the user/group name)
#override_space = _

[nss]

[pam]
# caching credentials for offline logging
#offline_credentials_expiration = 3
#offline_failed_login_attempts = 3

[domain/fjfi.cvut.cz]
id_provider = ad
access_provider = ad
ad_server = ldap1.fjfi.cvut.cz,ldap2.fjfi.cvut.cz,ldap3.fjfi.cvut.cz
# ad_hostname is necessary only if hostname can't be matched with entries in keytab
#ad_hostname = host.fjfi.cvut.cz
#ad_access_filter = (memberOf=cn=skupina,ou=Groups,dc=fjfi,dc=cvut,dc=cz)
dyndns_update = false
ldap_schema = ad
ldap_id_mapping = false
ldap_referrals = false
# global
min_id = 2000
#max_id = 29999 # nutné zakomentovat kvůli přechodu na osobní čísla
cache_credentials = true

Pokud chceme omezit skupinu lidí, kteří budou mít přístup k linuxovému stroji se zkonfigurovaným SSSD AD, potom musíme zvolit access_provider = ldap, jelikož výše uvedený ad provider nemá (v aktuální verzi na RHEL6.5) žádné další možnosti konfigurace. Konfigurace vlastního service by pak mohla vypadat např. následovně:

# část konfigurace /etc/sssd/sssd.conf omezující přístup pro členy dané skupiny (RHEL6.x resp. sssd < 1.11)
[domain/AD]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ldap
ad_domain = fjfi.cvut.cz
ad_server = ldap1.fjfi.cvut.cz,ldap2.fjfi.cvut.cz,ldap3.fjfi.cvut.cz
# folloving name is necessary only if local hostname doesn't correspond entries in keytab file
#ad_hostname = host.fjfi.cvut.cz
# defines user/group schema type
ldap_schema = ad
# using explicit POSIX attributes in the Windows entries (default is false)
ldap_id_mapping = false
# ldap access controls - requires access_provider set to ldap
ldap_sasl_mech = GSSAPI
ldap_access_filter = memberOf=cn=skupina,ou=Groups,dc=fjfi,dc=cvut,dc=cz
ldap_access_order = filter,expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
# performance
ldap_referrals = false
# global
min_id = 2000
#max_id = 29999 # nutné zakomentovat kvůli přechodu na osobní čísla
cache_credentials = true
enumerate = true

V budoucnu bude možné využít ad_access_filter, který je ale až v novější verzi SSSD 1.11 (RHEL7)

Po vytvoření požadované konfigurace je potřeba zajistit, aby se při startu systému spustil také sssd daemon

# povolení spuštění sssd při startu + okamžitý start sssd služby na RHEL 6.x (init skripty)
chkconfig sssd on
service sssd start
# povolení spuštění sssd při startu + okamžitý start sssd služby na RHEL 7.x (systemd)
systemctl enable sssd
systemctl start sssd

SSSD LDAP+Kerberos

[sssd]
domains = LOCAL,LDAP
services = nss, pam
config_file_version = 2

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
entry_cache_timeout = 300
entry_cache_nowait_percentage = 75

[pam]
reconnection_retries = 3
offline_credentials_expiration = 3
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
pam_pwd_expiration_warning = 3

[domain/LOCAL]
id_provider = local
auth_provider = local
access_provider = permit

[domain/LDAP]
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
access_provider = ldap
ldap_uri = ldap://ldap1.fjfi.cvut.cz,ldap://ldap2.fjfi.cvut.cz,ldap://ldap3.fjfi.cvut.cz
ldap_search_base = dc=fjfi,dc=cvut,dc=cz
#ldap_id_use_start_tls = true
#ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
# simple autentizace uživatele pro přístup k LDAP informacím
# (při této konfiguraci je nutné použít TLS resp. ldap_id_use_start_tls,
# jinak budou přenášená data nešifrovaná a existuje možnost jejich změny
# na cestě což pro uidNumber představuje bezpečnostní hrozbu)
#ldap_default_bind_dn = CN=proxy_posix,OU=Specials,DC=fjfi,DC=cvut,DC=cz
#ldap_default_authtok_type = password
#ldap_default_authtok = secret
# kerberos autentizace uživatele pro přístup k LDAP informacím
# (data jsou také šifrována kerberem a TLS tak není nezbytně nutné)
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/hostname.fjfi.cvut.cz@FJFI.CVUT.CZ
ldap_referrals = false
ldap_schema = rfc2307bis
ldap_user_search_base = ou=People,dc=fjfi,dc=cvut,dc=cz
ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_user_name = sAMAccountName
ldap_group_search_base = ou=groups,dc=fjfi,dc=cvut,dc=cz
ldap_group_object_class = group
#ldap_search_timeout = ??? # switch to offline mode after this timeout
#ldap_network_timeout = 6
#ldap_opt_timeout = 5
#ldap_access_filter = memberOf=cn=emp,ou=Groups,dc=fjfi,dc=cvut,dc=cz
#ldap_access_order = filter,expire
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
# kerberos configuration
krb5_server = krb1.fjfi.cvut.cz,krb2.fjfi.cvut.cz,krb3.fjfi.cvut.cz
krb5_realm = FJFI.CVUT.CZ
krb5_canonicalize = false
#min_id = 4000
#max_id = 29999
cache_credentials = true
#account_cache_expiration = 7
#entry_cache_timeout = 14400
#enumerate = true

Při použití výše uvedené konfigurace proti AD (tj. kerberos autentizace + TLS zabezpečený přenos dat) je potřeba na RHEL 6.x do /etc/openldap/ldap.conf přídat řádek

# Active Directory not supporting nested security or privacy layers
sasl_secprops minssf=0,maxssf=0

Kerberos

Toto je starší způsob z doby, kdy ještě neexistovala možnost použít sssd. Navíc lze tento starší návod aplikovat na platformách, které nepodporují sssd.

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
 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 otestování kerberos autentizace, vypsání a zrušení získaného ticketu lze použít následující příkazy:

kinit username
klist
kdestroy

Pro autentizaci na stanici je potřeba ještě zkonfigurovat PAM moduly. Na RedHatu 5.x (RHEL5) stačí upravit soubor /etc/pam.d/system-auth, na RedHatu 6.x (RHEL6) je to samé potřeba provést ještě v /etc/pam.d/password-auth

#%PAM-1.0
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 4000 quiet
auth        [authinfo_unavail=ignore success=1 default=2] pam_krb5.so minimum_uid=4000 use_first_pass
auth        [default=done] pam_ccreds.so action=validate use_first_pass
auth        [default=done] pam_ccreds.so action=store
auth        [default=bad] pam_ccreds.so action=update
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
#account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 4000 quiet
account     [authinfo_unavail=ignore default=done] pam_krb5.so minimum_uid=4000
account     required       pam_permit.so

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

#session     optional       pam_mkhomedir.so skel=/etc/skel/ umask=0022
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 minimum_uid=4000

Tato konfigurace PAMu je napsána s ohledem na to, že uživatelé budou v /etc/passwd. Při použití přímého přístupu k informacím v LDAP přes nss_ldap by bylo vhodné tam udělat ještě pár drobných ůprav s ohledem na možnou (ne)dostupnost LDAP (v podstatě jde o přidání user_unknown=ignore k řádkům, kde je authinfo_unavail=ignore) - více informcí.

Také je na zvážení (z hlediska bezpečnosti/dostupnosti), jestli použvat pam_ccred. To se uvidí časem a bude to záviset na(ne)fungovaní nových windows serverů.

Debian

Na Debianu 12 stačí pro zprovoznění samotného přihlašování

apt-get install krb5-config krb5-user libpam-krb5
perl -p -i -e 's/default_realm *=.*/default_realm = MS.CVUT.CZ/' /etc/krb5.conf

a přidání příslušných ČVUT uživatelských účtů do /etc/passwd a /etc/shadow.

Pro bezpečné přihlašování je také potřeba přidat odpovídající computer account v /etc/krb5.keytab.

Host/Service 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. Základní informace lze nalézt v KB 324144. Mapování služby na uživatelský učet je N:1. Nejvhodnější bude přidávat tyto účty k "objektu počítače", které vznikají přídáním stroje do AD a mají tvar jméno$ (tyto účty by měli být automaticky na globalním ČVUT IdM blacklistu). Preferovaný způsob přidání stroje do AD z linuxu je pomocí samby a jejího příkazu net ads [join|leave|keytab add].

Níže jsou uvedeny různé způsoby vygenerování keytabu. Tady jsou moje doporučení:

• nejpohodlnější je vytvoření pomocí samby
• bez instalace samby se lze obejít při vytvoření keytabu ve windows
  • nutné zkopírovat vygenerovaný keytab na cílový stroj nebo předat správci použité heslo, které lze použít k ručnímu vytvoření keytabu
  • některé net ads příkazy nemusí po tomto joinutí fungovat (vyžadují heslo v plaintextu v secrets.tdb)
    • známe-li heslo použité ke generování keytabu je možné secrets.tdb dodatečně vytvořit

Vytvoření keytabu ve windows

K vytvoření kerberos keytabu je nejprve potřeba vytvořit computer account v AD. Následující příkaz pak vytvoří keytab a asociuje příslušné autentizační údaje s účtem v AD.

# smazání/vytvoření computer accountu HOSTNAME$ v AD
# (lze také naklikat v admin mmc User and Computer consoli)
C:> dsrm -noprompt "CN=HOSTNAME,CN=Computers,DC=fjfi,DC=cvut,DC=cz"
C:> dsadd computer "CN=HOSTNAME,CN=Computers,DC=fjfi,DC=cvut,DC=cz"
# vytvoření/asociace host kerberos principálu (na w2k8 by měl být ktpass.exe součástí default instalace)
C:> ktpass -ptype KRB5_NT_PRINCIPAL -princ host/hostname.fjfi.cvut.cz@FJFI.CVUT.CZ -mapuser FJFI\HOSTNAME$ -pass +rndPass +Answer -out c:\hostname.keytab -crypto all -mapOp set [-kvno 1]
# vytvoření služby ftp pro hosta hostname.fjfi.cvut.cz (pouze pokud na "hostname" provozujeme službu FTP)
C:> ktpass -ptype KRB5_NT_PRINCIPAL -princ ftp/hostname.fjfi.cvut.cz@FJFI.CVUT.CZ -mapuser FJFI\HOSTNAME$ -pass +rndPass +Answer -SetUpn -out hostname.keytab [ -mapOp set -kvno 1 ]
# pro lepší kompatibilitu s MIT kerberem se prý hodí parametr -crypto DES-CBC-MD5 (asi historicke a zbytečné)

Z neznámého důvodu mě na linuxu nefungovalo získávání ticketu pres kinit -k -t file.keytab, když jsem v ktpass použil -crypto DES-CBC-MD5. Nejsem si také jist jaký je rozdíl ve vygenerovaném souboru při použití různých ptype (KRB5_NT_PRINCIPAL, KRB5_NT_SRV_HST, KRB5_NT_SRV_INST).

Pokud jsou potřeba různé host principaly, které budou mít možnost přímo získat ticket (např. samba potřebuje v ideálním případě host/hostname.fjfi.cvut.cz@FJFI.CVUT.CZ, host/hostname@FJFI.CVUT.CZ a HOSTNAME$@FJFI.CVUT.CZ), potom je možné další záznamy přidávat do již existujícího keytabu při zachování originálního hesla a kvno:

dsrm -noprompt "CN=HOSTNAME,CN=Computers,DC=fjfi,DC=cvut,DC=cz"
dsadd computer "CN=HOSTNAME,CN=Computers,DC=fjfi,DC=cvut,DC=cz"
ktpass.exe /princ host/hostname.fjfi.cvut.cz@FJFI.CVUT.CZ /out hostname.keytab /crypto All /ptype KRB5_NT_PRINCIPAL -desonly /mapuser FJFI\HOSTNAME$ +setupn +rndPass +setpass +answer
#ktpass.exe /princ host/hostname.fjfi.cvut.cz@FJFI.CVUT.CZ /in hostname.keytab /out hostname.keytab /crypto All /ptype KRB5_NT_PRINCIPAL -desonly /mapuser FJFI\HOSTNAME$ -setupn +rndPass -setpass +answer
ktpass.exe /princ host/HOSTNAME$@FJFI.CVUT.CZ /in hostname.keytab /out hostname.keytab /crypto All /ptype KRB5_NT_PRINCIPAL -desonly /mapuser FJFI\HOSTNAME$ -setupn +rndPass -setpass +answer
ktpass.exe /princ HTTP/hostname.fjfi.cvut.cz@FJFI.CVUT.CZ /in hostname.keytab /out hostname.keytab /crypto All /ptype KRB5_NT_PRINCIPAL -desonly /mapuser FJFI\HOSTNAME$ -setupn +rndPass -setpass +answer
# k přidávání SPN záznamů lze také použít setspn.exe nebo adsiedit.msc
#setspn -A other/hostname.fjfi.cvut.cz@FJFI.CVUT.CZ hostname

powershell skript

# Allow to run unsigned powershell code.
# set-executionpolicy unrestricted
 
# enable the AD module
Import-Module ActiveDirectory
 
# get domain info
$domain = Get-ADDomain
$domain_short = $domain.Name
$domain_suffix = $domain.DNSRoot
$domain_realm = $domain.DNSRoot.ToUpper()
 
Write-Host -nonewline "Please enter system name (e.g. kmlinux): "
$cname = Read-Host
$cname_upper = $cname.ToUpper()
$cname_fqdn = "$cname.$domain_suffix"
 
# check for existing computer account or keytab file
$cname_object = Get-ADComputer -Filter { Name -eq $cname }
if( $cname_object -ne $null ) {
    #Remove-ADComputer -Identity "$cname" -Confirm:$false
    Write-Host "Computer account $cname already exists, remove using cmd or powershell:"
    Write-Host "  cmd: dsrm -noprompt '$cname_object'"
    Write-Host "  power: Remove-ADComputer -Identity '$cname' -Confirm:$false"
    Exit
}
 
If (Test-Path "$cname.keytab") {
    Write-Host "Keytab file $cname.keytab already exists"
    Write-Host "Remove using: rm $cname.keytab"
    Exit
}
 
# create new computer account and keytab file
Write-Host "Create $cname.keytab for host/$cname_fqdn@$domain_realm"
$cname_object = Get-ADComputer -Filter { Name -eq $cname }
if( $cname_object -eq $null ) {
    New-ADComputer $cname_upper
    # setspn -A host/$cname_fqdn@$domain_realm $cname
    $ktpass_options = "/out $cname.keytab /crypto All /ptype KRB5_NT_PRINCIPAL -desonly /mapuser $domain_short\$cname_upper$"
    $ktpass_options_first = "$ktpass_options +setupn +rndPass +setpass +answer"
    $ktpass_options_next = "/in $cname.keytab $ktpass_options -setupn +rndPass -setpass +answer"
    cmd /c "ktpass.exe /princ host/$cname_fqdn@$domain_realm $ktpass_options_first"
    cmd /c "ktpass.exe /princ host/$cname@$domain_realm $ktpass_options_next"
    cmd /c "ktpass.exe /princ $cname_upper$@$domain_realm $ktpass_options_next"
    cmd /c "ktpass.exe /princ cifs/$cname_fqdn@$domain_realm $ktpass_options_next"
    cmd /c "ktpass.exe /princ cifs/$cname@$domain_realm $ktpass_options_next"
    cmd /c "ktpass.exe /princ nfs/$cname_fqdn@$domain_realm $ktpass_options_next"
    cmd /c "ktpass.exe /princ nfs/$cname@$domain_realm $ktpass_options_next"
    cmd /c "ktpass.exe /princ HTTP/$cname_fqdn@$domain_realm $ktpass_options_next"
    cmd /c "ktpass.exe /princ HTTP/$cname@$domain_realm $ktpass_options_next"
}

Vytvoření keytabu v linuxu pomocí samby

V novějších verzích samby lze vcelku konfortně vytvářet účty počítačů (zařazovat počítače do domény) a spravovat keytab soubory. Pro korektní chování je potřeba správná konfigurace v smb.conf a default realm v krb5.conf nastavená na doménu DC. Dále je potřeba provádět (většinu) příkazů pod účtem roota, protože k některým souborům nemá běžný uživatel přístup a nelze měnit jejich umístění v konfiguračním souboru.

[global]
  workgroup = FJFI
  security = ads
  realm = FJFI.CVUT.CZ
  #samba 3.3: use kerberos keytab = True
  #samba 3.5: kerberos method = system keytab|dedicated keytab|secrets and keytab
  kerberos method = secrets and keytab
  #private dir = .

Také je potřeba na firewallu doménového kontroleru povolit přístup k LDAPu (TCP i UDP) na portu 389 a "samba" porty (445, 139 a možná ještě další z rozsahu 136-139). Výše uvedený kousek smb.conf konfigurace neobsahuje všechny změny nutné pro plnohodnotný provoz samba služeb a detailněji je to popsáné v další sekci.

# získání kerberos ticketu, abychom pro některé z následujících příkazu nemuseli zadávat heslo
# (na RHEL7 je potřeba uložit ticket do souboru pomocí export KRB5CCNAME=/tmp/krb5cc_0)
kinit admin # nutný pro join/leave operace
#kinit host/test1234.fjfi.cvut.cz # má +/- dostačující práva pro "keytab" operace

# odstranění záznamu o počítači TEST1234 z AD
net -k [ -n TEST1234 ] ads leave
# přidání záznamu o počítači TEST1234 do AD 
net -k [ -n TEST1234 ] ads join createupn=host/test1234.fjfi.cvut.cz@FJFI.CVUT.CZ [ osName=Linux osVer=5 ]
# přidání záznamu o počítači TEST1234 do AD bez nutnosti konfigurovat /etc/samba/smb.conf
# net ads join -U administrator -n test1234 \
#         --option='workgroup = FJFI' --option='security = domain' \
#         --option='realm = FJFI.CVUT.CZ' --option='kerberos method = secrets and keytab' \
#         createupn=host/test1234.fjfi.cvut.cz@FJFI.CVUT.CZ osName=CentOS osVer=7.x createcomputer=Computers
# vypsání informací o počítači TEST1234 z AD
net -k [ -n TEST1234 ] ads status

# _kompletní_ vyčístění keytabu (případně lze smazat/přesunout /etc/krb5.keytab)
net -k [ -n TEST1234 ] ads keytab flush
# vytvoření keytabu (tento příkaz funguje jen když je host heslo v secrets.tdb)
net -k [ -n TEST1234 ] ads keytab create
# pokud předchozí příkaz nic neprovede můžete ještě vyzkoušet
net -U host/test1234.fjfi.cvut.cz [ -n TEST1234 ] ads keytab create
# vypsání informací z keytabu
net -k [ -n TEST1234 ] ads keytab list
# přidání služby do keytabu (tento příkaz funguje jen když je host heslo v secrets.tdb)
net -k [ -n TEST1234 ] ads keytab add HTTP
net -k [ -n TEST1234 ] ads keytab add ldap
net -k [ -n TEST1234 ] ads keytab add DNS
...

# změna hesla pro machine account, provede modifikaci
# /etc/krb5.keytab i /var/lib/samba/private/secrets.tdb
net -k ads changetrustpw

Pokud použijete tento způsob připojení počítače do domény (net ads join), vytvoří samba mimo jiné soubor /var/lib/samba/private/secrets.tdb (při použití "kerberos method = secrets and keytab"), který bude v plain textu obsahovat náhodné heslo vygenerované pro nový computer account v AD. Existence tohoto souboru je podmínkou pro další fungovaní příkazů net ads keytab create a net ads keytab add SERVICE, které ve svém důsledku musí mít nějaký přístup k plain text heslu, když přidávají další principaly do keytabu. Zatím mi není známo, jestli je secrets.tdb využíván i přímo daemony, které zprostředkovávájí samba služby.

Ruční vytvoření keytabu

Pokud znáte heslo k odpovídajícímu computer accountu v AD, můžete si keytab vytvořit sami ručně. V podstatě jde o tu samou operaci, která je ve svém důsledku realizována po zavolání net -U host/hostname.fjfi.cvut.cz ads keytab create, která ale fungoje jen pokud již máte vygenerován správný secrets.tdb s uloženým plain text heslem pro computer account (tento soubor není složité ručně vygenerovat).

# zjištění aktualního kvno pro computer account
kinit host/hostname.fjfi.cvut.cz
kvno host/hostname.fjfi.cvut.cz
# nebo přímo dotazem do LDAPu pomocí
ldapsearch -LLL -H ldap://ldap.fjfi.cvut.cz -b 'dc=fjfi,dc=cvut,dc=cz' 'sAMAccountName=HOSTNAME$' userPrincipalName servicePrincipalName msDS-KeyVersionNumber
kdestroy
# vytvoření nového keytabu pro computer account "hostname"
# heslo "secret" nahraďte platným heslem pro computer account
# výraz "kvno" musíte nahradit číslem, které vrátí výše uvedený příkaz
[root@host ~]# ktutil
ktutil: addent -password -p host/hostname.fjfi.cvut.cz -k kvno -e des-cbc-crc
ktutil: addent -password -p host/hostname.fjfi.cvut.cz -k kvno -e des-cbc-md5
ktutil: addent -password -p host/hostname.fjfi.cvut.cz -k kvno -e aes128-cts-hmac-sha1-96
ktutil: addent -password -p host/hostname.fjfi.cvut.cz -k kvno -e aes256-cts-hmac-sha1-96
ktutil: addent -password -p host/hostname.fjfi.cvut.cz -k kvno -e arcfour-hmac
ktutil: addent -password -p host/hostname ...
ktutil: addent -password -p HOSTNAME$ ...
ktutil: ...
ktutil: wkt /etc/krb5.keytab

Z nějakého důvodu tohle nefungovalo pro HOSTNAME$ principal (pokud nechcete používat přímo sambu/cifs, tak tento principal není potřeba), takže bylo nakonec nejjednodušší použít opět sambu (bez kerbera), ale nejdříve je nutné mít správné heslo v /var/lib/samba/private/secrets.tdb u položky SECRETS/MACHINE_PASSWORD/FJFI (secrets.tdb je možné vygenerovat pomocí toho skriptu):

# vytvoření keytabu při znalosti hesla a správným secrets.tdb
net -U host/hostname.fjfi.cvut.cz@FJFI.CVUT.CZ ads keytab create
# změna hesla pro computer account včetně update krb5.keytab a secrets.tdb
kinit -k
net -k ads changetrustpw

Tímto příkazem se také aktualizuje seznam všech podporovaných šifer uloženích v nově updatovaném keytabu. Pro detailní debugovaní problémů s vytvořeným keytabem lze nastavit enviromentovou proměnou KRB5_TRACE na soubor, který bude obsahovat debug informace. Bohužel příkaz ktutil neumí zatím pracovat s ničím jiným než default saltováním hesla, takže některé keytaby pomocí něj "nelze" vytvořit (mělo by fungovat vytváření pomoci ktpass.exe, msktutil implementace zatím také nepodporuje spolehlivé nastavení saltu, protože se snaží pouze odhadnout jak by mohl v AD vypadat). Pokud přeci jen nemáte jinou možnost po ruce, tak keytab s nedefault saltem lze vytvořit následujícím postupem:

• nastavte KRB5_TRACE=/tmp/krb5trace
• získejte požadovaný ticket kinit username@REALM
• podívejte se do /etc/krb5trace jaký se používá salt (uveden ve formátu REALMname)
• vytvořte keytab s uvedením name@REALM jako principalu s heslem pro požadovaný principal username@REALM
• vypište si obsah klíčů ve vytvořeném keytabu klist -k -t my_keytab -e -K
• vytvořte si keytab se správným principalem username@REALME s využitím hex hodnot vypsaných klíčů

Pokud používáte MIT Kerberos alespoň 1.16, potom je možné salt zadat přímo =ktutil= např. následujícím způsobem:

[root@host ~]$ ldapsearch -Q -LLL cn=username msDS-KeyVersionNumber
dn: CN=username,OU=Users,OU=Organic Units,DC=example,DC=com
msDS-KeyVersionNumber: 18
[root@host ~]$ ktutil
ktutil:  addent -password -p username@REALM -k 18 -e aes256-cts -s REALMname
ktutil:  wkt username.keytab
ktutil:  q
# nebo pro pridání všech sifrování:
[root@host ~]$ for ENC in des-cbc-crc des-cbc-md5 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96 arcfour-hmac; do printf "%b" "addent -password -p username@REALM -k 3 -e ${ENC} -s REALMname\nsecret\nwrite_kt username.keytab\nq" | ktutil; done

V principu lze použít i náhodné heslo při generování keytabu pomoci ktpass.exe, ale pak budeme navíc potřebovat výpis standardního outputu tohoto přikazu, kde jsou uvedeny informace potřebné pro úspěšný import dat pomoci ktutil

# na windows si vytvoříme hostname.keytab + hostname.out
C:> ktpass -ptype KRB5_NT_PRINCIPAL -princ host/hostname.fjfi.cvut.cz@FJFI.CVUT.CZ -mapuser FJFI\HOSTNAME$ -pass +rndPass +Answer -out c:\hostname.keytab -crypto all -mapOp set > c:\hostname.out
# v ktutil pak přidáme požadované principaly s využitím informací z hostname.out
[root@host ~]# ktutil
ktutil: addent -key "hex číslo z hostname.out" -p host/hostname.fjfi.cvut.cz -k "kvno z hostname.out" -e "encryption z hostname.out
ktutil: ...

S computer account credentials lze měnit i některé atributy jemu odpovídajícímu objektu, např. můžeme přidat další SPN pomocí následujícich ldap příkazů:

# HOSTNAME.ldif
dn: CN=HOSTNAME,CN=Computers,DC=fjfi,DC=cvut,DC=cz
changetype: modify
add: servicePrincipalName
servicePrincipalName: host/hostname

# update dat v AD
kinit -k
ldapmodify -H ldap://ldap.fjfi.cvut.cz -f HOSTNAME.ldif

Změna hesla (nejen) pro computer account

# echo -n "\"secret\"" | iconv -f UTF8 -t UTF16LE | base64 -w 0
# kinit username@MS.CVUT.CZ
# ldapmodify -H ldap://hades.ms.cvut.cz -f mpwd.ldif
dn: CN=14000-nms-tr,OU=computers,OU=14000,OU=00000,DC=ms,DC=cvut,DC=cz
changetype: modify
replace: unicodePwd
unicodePwd::IgBzAGUAYwByAGUAdAAiAA==

Vygenerování náhodného hesla pro LDIF

python - <<EOF
import base64
import random, string
chars = string.ascii_letters + string.digits + '!#%^&*()-_=+[];:,<>./?'
rnd = random.SystemRandom()
password = "".join(rnd.choice(chars) for i in range(16))
upassword = unicode("\"%s\"" % password).encode("utf-16-le")
bpassword = base64.standard_b64encode(upassword)
print "# password: %s" % password
print "unicodePwd::%s" % bpassword
EOF

Kompletní ruční vytvoření computer accountu

# kinit username@MS.CVUT.CZ
# ldapadd -H ldap://hades.ms.cvut.cz -f 14000-kmlinux.ldif
# ldapdelete -H ldap://hades.ms.cvut.cz "CN=14000-kmlinux,OU=computers,OU=14101,OU=14000,OU=00000,DC=ms,DC=cvut,DC=cz"
dn: CN=14000-kmlinux,OU=computers,OU=14101,OU=14000,OU=00000,DC=ms,DC=cvut,DC=cz
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectClass: computer
cn: 14101-kmlinux
description: FJFI KM Computer kmlinux.fjfi.cvut.cz
name: 14101-kmlinux
userAccountControl: 4096
instanceType: 4
codePage: 0
countryCode: 0
accountExpires: 0
sAMAccountName: 14101-kmlinux$
unicodePwd::IgBzAGUAYwByAGUAdAAiAA==
dNSHostName: kmlinux.fjfi.cvut.cz
userPrincipalName: host/kmlinux.fjfi.cvut.cz@MS.CVUT.CZ
servicePrincipalName: host/14101-KMLINUX
servicePrincipalName: host/kmlinux.fjfi.cvut.cz
servicePrincipalName: http/14101-KMLINUX
servicePrincipalName: http/kmlinux.fjfi.cvut.cz
#servicePrincipalName: NFS/14101-KMLINUX
#servicePrincipalName: NFS/kmlinux.fjfi.cvut.cz
#servicePrincipalName: FTP/14101-KMLINUX
#servicePrincipalName: FTP/kmlinux.fjfi.cvut.cz

Ruční vytvoření keytabu včetně odlišného saltu

#!/bin/sh
# ldapsearch -LLL -H ldap://ldap.ms.cvut.cz -b 'dc=ms,dc=cvut,dc=cz' 'sAMAccountName=FJFI-PCLABS-VIRT$' userPrincipalName servicePrincipalName msDS-KeyVersionNumber
KVNO=1
OU='FJFI'
HNAME="pclabs-virt"
REALM="MS.CVUT.CZ"
PASSWD='secret'
KEYTAB="${HNAME}.keytab"
ENCS=(
#  'des-cbc-crc'
#  'des-cbc-md5'
  'aes128-cts-hmac-sha1-96'
  'aes256-cts-hmac-sha1-96'
#  'arcfour-hmac'
)
OUL=$(echo "$OU" | tr 'A-Z' 'a-z')
HNAMEU=$(echo "$HNAME" | tr 'a-z' 'A-Z')
HNAMEL=$(echo "$HNAME" | tr 'A-Z' 'a-z')
PRINCS=(
  "host/${HNAME}.fjfi.cvut.cz@${REALM}"
  "host/${OU}-${HNAMEU}\$@${REALM}"
#  "HOST/${HNAME}.fjfi.cvut.cz@${REALM}"
#  "HOST/${OU}-${HNAMEU}\$@${REALM}"
#  "HTTP/${HNAME}.fjfi.cvut.cz@${REALM}"
#  "HTTP/${OU}-${HNAMEU}@${REALM}"
)
SALT="${REALM}host${OUL}-${HNAMEL}.ms.cvut.cz"
 
[ -f "${KEYTAB}" ] && mv "${KEYTAB}" "${KEYTAB}.$(date +%Y%m%d%H%M%S)"
 
{
  for PRINC in ${PRINCS[@]}; do
    for ENC in ${ENCS[@]}; do
      echo "addent -password -p ${PRINC} -k ${KVNO} -e ${ENC} -s ${SALT}"
      echo "${PASSWD}"
    done
  done
  echo "wkt ${KEYTAB}"
  echo "quit"
} | ktutil > /dev/null
 
exit
 
# Get hashed kerberos keys for given salt.
# MIT kerberos by default use user principal as salt, but AD can use
# arbitrary salt. Salt can be found in kinit debug info that is stored
# in a file defined in KRB5TRACE environment variable
KEYS=$({
  for ENC in ${ENCS[@]}; do
    echo "addent -password -p ${SALT} -k ${KVNO} -e ${ENC}"
    #sleep 1
    echo "${PASSWD}"
    #sleep 1
  done
  echo "list -k -e"
} | ktutil 2> /dev/null | grep '^ ')
 
# debug
echo "${KEYS}"
for ENC in ${ENCS[@]}; do
  echo "${ENC}"
  echo "${KEYS}" | grep "${ENC}" | sed 's/.*(0x//;s/).*//'
done
 
# Create keytab
{
  for PRINC in ${PRINCS[@]}; do
    for ENC in ${ENCS[@]}; do
      echo "addent -key -p ${PRINC} -k ${KVNO} -e ${ENC}"
      #sleep 1
      usleep 10000
      echo "${KEYS}" | grep "${ENC}" | sed 's/.*(0x//;s/).*//'
      #sleep 1
    done
  done
  echo "wkt ${KEYTAB}"
  echo "quit"
} | ktutil > /dev/null
echo "new keytab in ${KEYTAB}"

Vytvoření keytabu v linuxu pomocí msktutil

Na linuxu je potreba nainstalovat msktutil (pr RHEL/CentOS existují balíčky v EPEL), který umožňuje přidání computer account do Active Direcotry, manipulaci s hesly a získání keytabu pro daného hosta resp. službu. Je potřeba mít korektně vytvořený konfigurační soubor Kerbera /etc/krb5.conf a pro některé operace platný ticket administrátora AD. Dále je potřeba mít na paměti, že msktutil pracuje pouze s globální "default_realm" z konfiguračního souboru a v některých případech záleží na pořadí v němž jsou uvedeny parametry na příkazovém řadku. Pokud dojde k nějakým problémům, potom je vhodné použít parametr --verbose. Příkaz se používá následujícím způsobem:

# vytvoř computer account v AD pro aktuálního hosta a přidej do /etc/krb5.keytab
msktutil -c
# to samé, ale výsledek uloží do souboru test.keytab
msktutil -c -k test.keytab
# to samé, ale pro stoj se jménem test (automaticky přidá doménu ke jménu záznamu v AD, např. test-fjfi-cvut-cz$)
msktutil -h test -c -k test.keytab
# to samé, ale pro stoj se jménem test a jméno v AD bude TEST$
msktutil --computer-name TEST -h test -c -k test.keytab
# to samé, ale stoj bude zařazen CN=Unix,CN=Computers,DC=fjfi,DC=cvut,DC=cz
msktutil --computer-name TEST -h test -b CN=Unix,CN=Computers -c -k test.keytab
# přidej službu ldap k computer accountu TEST$ a exportuj do test.keytab
msktutil --computer-name TEST -h test -s ldap -k test.keytab
# update kerberos credentials ... msDS-KeyVersionNumber
# (pravděpodobně nutné po ručním zásahu do atributu servicePrincipalName)
msktutil --computer-name TEST -h test -u -k test.keytab

Je také potřeba si uvědomit, že kerberos ticket je platný jen pro správné (doménové) jméno. Pokud chceme, aby bez problémů fungoval přístup jak k test.fjfi.cvut.cz tak i test, potom bude nutné vytvořit pro každou variantu jeden záznam. Jako dobrý příklad mohou sloužit záznamy u doménového kontroleru, které lze zjistit např. LDAP dotazem:

# získání kerberos ticketu, který umožní autentizovaný dotaz do LDAPu Active Directory
kinit
# dotaz na computer account TEST
ldapsearch -H ldap://ldap.fjfi.cvut.cz -b 'dc=fjfi,dc=cvut,dc=cz' 'sAMAccountName=TEST$' userPrincipalName servicePrincipalName msDS-KeyVersionNumber

Kombinace windows + linux

Vzhledem k chování programů ktpass.exe (pro w2k3 je součástí "Support Tools") a msktutil je "nejlepší" pro složitější služby použít oba...

# ve windows spustit
dsrm -noprompt "CN=TEST,CN=Computers,DC=fjfi,DC=cvut,DC=cz"
dsadd computer "CN=TEST,CN=Computers,DC=fjfi,DC=cvut,DC=cz"
ktpass -ptype KRB5_NT_PRINCIPAL -princ HOST/test.fjfi.cvut.cz@FJFI.CVUT.CZ -mapuser FJFI\TEST$ -pass +rndPass +Answer -SetUpn
ktpass -ptype KRB5_NT_PRINCIPAL -princ ftp/test.fjfi.cvut.cz@FJFI.CVUT.CZ -mapuser FJFI\TEST$ -pass +rndPass +Answer -SetUpn
ktpass -ptype KRB5_NT_PRINCIPAL -princ http/test.fjfi.cvut.cz@FJFI.CVUT.CZ -mapuser FJFI\TEST$ -pass +rndPass +Answer -SetUpn
# v linuxu pak vygenerovat jeden keytab
msktutil --computer-name TEST -h TEST -u --upn 'host/test.fjfi.cvut.cz@FJFI.CVUT.CZ' -k test.keytab

Použití nástroje realm

S CentOS7 je zde nový způsob připojení počítače do domény, který navíc krom kerbera zkonfiguruje i sssd daemon. Stačí jako privilegovaný root uživatel zadat

#realm leave --verbose --user=admin MS.CVUT.CZ
realm join --verbose --user=admin \
  --computer-name=14101-hostname \
  --computer-ou=OU=computers,OU=14xxx,OU=14000,OU=00000 \
  --automatic-id-mapping=no \
  MS.CVUT.CZ

Po použití tohoto nástroje bude stejně nutné doplnit konfiguraci sssd, jelikož ČVUT AD zatím neobsahuje všechny informace o posix accountu (např. čísla skupin gidNumber). Výsledná konfigurace pak může vypadat následovně:

Použití nástroje adcli

Tento nástroj je nakonec použit i při volání =realm join= a navíc má tu výhodu, že má daleko méně závislostí na dalších balíčcích (např. nepotřebuje Sambu). Jeho základní volání v našich podmínkách může vypadat následovně:

adcli join --domain=MS.CVUT.CZ --login-user=svc-14000-write \
  --computer-name=FJFI-HOME --host-fqdn=home.fjfi.cvut.cz \
  --user-principal=host/home.fjfi.cvut.cz@MS.CVUT.CZ \
  --service-name=host --service-name=nfs \
  --domain-ou=OU=Computers,OU=14000,OU=00000,DC=MS,DC=CVUT,DC=CZ

adcli delete-computer --domain=MS.CVUT.CZ --login-user=svc-14000-write fjfi-home

Import dat z keytabu

# Vytvořený keytab se importuje např.
ktutil
ktutil: rkt krb-hostname-host.keytab
ktutil: rkt krb-hostname-ftp.keytab
ktutil: l
ktutil: wkt /etc/krb5.keytab
ktutil: q

# Ověření funkčnosti lze povést příkazem kinit
kinit -k [ -t /etc/krb5.keytab ]

# zjištění informací z keytabu
klist -e -k [ -t /etc/krb5.keytab ]

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.

Použití kerbera pro SSO v browserech

Firefox for Windows

• nutné zkonfigurovat domény pro něž se bude používat kerberos SSO

network.negotiate-auth.delegation-uris = .fjfi.cvut.cz
network.negotiate-auth.trusted-uris = .fjfi.cvut.cz

• pokud nejste součástí windows domény resp. používáte "MIT Kerberos for Windows" potom musíte ještě nastavit

network.auth.use-sspi = false

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. Podrobnější dokumentace je v oficiálním HOWTO

workgroup = FJFI # nebo název katedry
server string = %h
security = ADS
realm = FJFI.CVUT.CZ
#samba 3.3: use kerberos keytab = True
#samba 3.5: kerberos method = system keytab|dedicated keytab|secrets and keytab
kerberos method = secrets and keytab
preferred master = no

# konfigurace winbind (bez běžícího winbindd používá samba "starší"
# autentizační mechachanizmus ntdomain z "auth methods")
idmap config * : backend = tdb
idmap config * : range = 1000000-1999999
idmap config FJFI : backend = ad
idmap config FJFI : range = 4000-29999
winbind nss info = rfc2307
# allow enumeration of winbind users and groups
;winbind enum users = yes
;winbind enum groups = yes
# Winbind usernames without DOMAIN prefix
# (this should be probably set to "no" for huge domains)
winbind use default domain = yes
# Replace whitespace in user and group names with an underscore
winbind normalize names = yes

# úplné disablovaní exportu tiskových služeb přes sambu
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes

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

# připojení stroje test.fjfi.cvut.cz do FJFI domény
net -UAdministrator%password ads join createupn=host/test.fjfi.cvut.cz@FJFI.CVUT.CZ createcomputer=Computers/Servers/Unix
# přidání dalších kerberizovaných služeb na stanici
net -UAdministrator%password ads keytab add HTTP

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.

Pro správné fungování autentizace musejí být doménový uživatelé uvedeni v /etc/passwd resp. musí být dostupní přes getent passwd. Toho lze dosáhnout i tak, že do /etc/nsswitch.conf přidáte resolvování passwd resp. group přes winbind.

passwd:     files winbind
group:      files winbind

ASUSTOR ADM

Webové rozhraní tohoto NASu neumožňuje při připojování tohoto zařízení specifikovat, kde se má v Active Directory vytvořit computer account. To komplikuje připojení do AD v nichž máme práva pouze na specifické části podstromu. Naštěstí ma toto zařízení příkazovou řádku, kde lze použít přímo net příkaz z aplikace samba.

# konfigurace jsou uložené v /volume0/usr/builtin/etc/samba
# připojení NASu do domény je potřeba provést pod uživatelem root
sudo su -
# pokud není aktuálně zařízení zapojeno v doméně, je potřeba upravit konfiguraci samby
#vi /volume0/usr/builtin/etc/samba/smb.conf
#workgroup = MS
#realm = MS.CVUT.CZ
#netbios name = 14102-VANESSA
#security = ads
# připojení počítače KF do ČVUT domény (práva mají i členové skupiny 14102-Administrators)
/usr/builtin/bin/net --configfile=/volume0/usr/builtin/etc/samba/smb.conf --user='MS\svc-14000-write' --myname=14102-TEST ads join createupn=host/test.fjfi.cvut.cz@MS.CVUT.CZ createcomputer=/00000/14000/14102/computers
# odpojení od domény lze provést buď přímo z konfiguračního web rozhraní nebo z příkazové řádky
# (tento příkaz pouze disabluje příslušný computer account, ale odpovídající objekt zůstane i nadále v AD)
/usr/builtin/bin/net --configfile=/volume0/usr/builtin/etc/samba/smb.conf --user='MS\svc-14000-write' ads leave

# odstranění existující computer accountu lze provést příkazy
#ldapsearch -H ldap://ldap.cvut.cz -Z -D 'MS\svc-14000-read' -b dc=ms,dc=cvut,dc=cz -W 'cn=test' 
#ldapdelete -H ldap://ldap.cvut.cz -Z -D 'MS\svc-14000-write' -W 'CN=test,CN=Computers,DC=ms,DC=cvut,DC=cz'
# změna umístění computer account objektu
#ldapmodify -H ldap://ldap.cvut.cz -Z -D 'MS\svc-14000-write' -W -f move.ldif
#cat > move.ldif <<EOF
#dn: CN=test,CN=Computers,DC=ms,DC=cvut,DC=cz
#changetype: modrdn
#newrdn: CN=test
#deleteoldrdn: 0
#newsuperior: OU=Computers,OU=14102,OU=14000,OU=00000,DC=ms,DC=cvut,DC=cz
#EOF

Dalším problémem je nízský výkon tdb storage backendu, který samba používá pro cachování informací z Active Directory. To dohromady s nízským výkonem Atom CPU v tomto NASu a velkém množství (100k+) uživatelských objektů v AD vede k timeoutům při snaze vylistovat seznam všech uživatelů / skupin (použito např. ve webovém rozhraní pro management doménových uživatelů / skupin). Z toho důvodu je nutné provést další úpravy konfiguračního souboru samby v /volume0/usr/builtin/etc/samba/smb.conf:

# rozšířit rozsah povolených UID pokud je v AD hodně uživatelů
idmap config * : range = 66000-960000
# zvětšit platnost nacachovaných dat pro omezení častých updatů (default: 300)
winbind cache time = 3600
# zvětšit timeout který je aplikován na projití všech uživatelských záznamů (default: 60)
winbind request timeout = 900

I po těchto upravách některé operace ve webovém rozhraní mohou trvat (timeoutovat) dlouho, například nastavování přístupových práv k samba sdíleným složkám. V principu lze vše ručně zkonfigurovat přímo z příkazové řádky ve výše uvedeném konfiguračním souboru samby.

Kerberized NFSv4

Informace ohledně konfigurace linuxů byly čerpány primárně z Fedora Magazine.

NFSv4.1 Windows Server

• podporováno od w2k12
• nutné přidat roli NFS server
• nutné povolit POSIX compatible case-sensitive práci se složkami/soubory (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive = 0)
• nutná existence Kerberos service principalu na NFS serveru
  • pro NFS server přidat do servicePrincipalName službu nfs/NAME resp. nfs/name.fjfi.cvut.cz }nutné pro každý computer account NFS serveru)
  • alterantivou je atribut sPNMappings obsahující globální nastavení standardního mapování různých služeb (cifs, snmp, ...) na "host" službu (viz. CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=fjfi,DC=cvut,DC=cz) + restart serveru
• na složce pro nastavit NFS sdílení s krb5,krb5i,krb5p security (resp. odstranit "Auth_SYS" neposkytující dostatečné zabezpečení pro uživatelská data)
  • krb5 - Kerberem ověřená uživatelská identita využitá pro kontrolu přístupových práv k souborům na serveru
  • krb5i - všechna data (tj. nejen metadata) posílaná mezi klientem a serverem jsou podepsána, aby je nebylo možné na cestě změnit (minimální vliv na výkon NFS)
  • krb5p - všechna data jsou navíc zašifrována a není je možné odposlechnout (na moderních strojích s hw podporou šifrování snížení výkonu NFS do +/- 20%)
• mapování unixových práv (u+rwx,g+rwx,o+rwx) je prováděno následujícím způsobem
  • u - CREATOR OWNER (uživatel vlastnící daný objekt a jeho uidNumber)
    • r - read data (list folder)/attributes/extended attributes, write attributes/extended attributes, delete, read/change premissions, take ownership
    • w - read attributes/extended attributes, write (create file)/append (create folder) data, write attributes/extended attributes, delete, read/change premissions, take ownership
    • x - execute file (traverse folder), read attributes/extended attributes, write attributes/extended attributes, delete, read/change premissions, take ownership
  • g - primary group pro uživatele CREATOR OWNER ("Domain Users" s gidNumber = 2001)
  • o - Everyone
  • -
  • unixová práva rwx jsou namapována na "full control" na NTFS
  • nemá-li group/other žádná unixová práva, stejně jsou na NTFS nastaveny práva (pro čtení metadat): read attributes/extended attributes, read premissions
  • nemá-li uživatel žádná unixová práva je to na NTFS implementováno přes "Deny ACL"
• problémy
  • RHEL7.1 klient nezapisuje data do vytvořených souborů (pouze vytváří soubory nulové delky)
  • RHEL7.1 a Fedora21 klient se kousne po restartu w2k12 NFS Serveru (resp. čeká na nějaký timeout +/- minutu a pak zas začne fungovat)

NFSv4.x Linux Server

• kerberizovaný NFS server vyžaduje keytab s "nfs" service

adcli join --domain=MS.CVUT.CZ --login-user=svc-14000-write \
  --computer-name=FJFI-HOME --host-fqdn=home.fjfi.cvut.cz \
  --user-principal=host/home.fjfi.cvut.cz@MS.CVUT.CZ \
  --service-name=host --service-name=nfs \
  --domain-ou=OU=Computers,OU=14000,OU=00000,DC=MS,DC=CVUT,DC=CZ

• exportované svazky připojit do /export adresáře (např. přes bind mount)

mkdir /export/home
echo '/mnt/nvme/home /export/home none bind 0 0' >> /etc/fstab
mount /export/home

• vytvořit konfigurace v /etc/exports, např.

/export         147.32.0.0/16(ro,sync,wdelay,fsid=0,sec=sys:krb5:krb5i:krb5p,no_subtree_check,secure,root_squash) 2001:718:2::/48(ro,sync,wdelay,fsid=0,sec=sys:krb5:krb5i:krb5p,no_subtree_check,secure,root_squash)
/export/home    147.32.0.0/16(rw,sync,wdelay,sec=krb5:krb5i:krb5p,secure,no_subtree_check,root_squash) 2001:718:2::/48(rw,sync,wdelay,sec=krb5:krb5i:krb5p,secure,no_subtree_check,root_squash)

• konfigurace mapování identit

perl -p -i -e 's/^#Domain = .*/Domain = MS.CVUT.CZ/' /etc/idmapd.conf
#perl -p -i -e 's/^#Nobody-User = nobody/Nobody-User = nfsnobody/' /etc/idmapd.conf
#perl -p -i -e 's/^#Nobody-Group = nobody/Nobody-Group = nfsnobody/' /etc/idmapd.conf

• konfigurace identit

dnf install -y sssd
cat << END > /etc/sssd/sssd.conf
[sssd]
  services = nss
  config_file_version = 2
  domains = MS.CVUT.CZ

[domain/MS.CVUT.CZ]
  id_provider = ad
  ldap_idmap_range_min = 100000000
  ldap_idmap_range_max = 2100000000
  ldap_idmap_range_size = 100000000
  ldap_idmap_default_domain_sid = S-1-5-21-3790076472-805733362-72324250
  krb5_store_password_if_offline = true
  cache_credentials = true
  ignore_group_members = true
  override_gid = 100
  override_shell = /bin/bash
  override_homedir = /home/%u
  dyndns_update = false
  ad_enabled_domains = MS.CVUT.CZ
  ad_gpo_access_control = disabled
END
chmod 600 /etc/sssd/sssd.conf
systemctl start sssd.service
authselect select sssd with-silent-lastlog --force

• spustit potřebné daemony

systemctl enable --now nfs-server.service

• zkonfigurovat firewall

firewall-cmd --add-service nfs --permanent
#firewall-cmd --add-service mountd --permanent # ???
firewall-cmd --reload

• na klientovi připojit příkazem

mount -t nfs -o vers=4.2,sec=krb5p home.fjfi.cvut.cz:/home /home

NFSv4.x Linux Client

• pro kerberizované spojení je nutné na klientu mít k dispozici keytab z =host= službou pro lokální jméno počítače (nemusí odpovídat jménu v DNS)

hostnamectl set-hostname t105-01l.fjfi.cvut.cz
adcli join --domain=MS.CVUT.CZ --login-user=svc-14000-write \
  --computer-name=FJFI-t105-01l --host-fqdn=t105-01l.fjfi.cvut.cz \
  --user-principal=host/t105-01l.fjfi.cvut.cz@MS.CVUT.CZ \
  --service-name=host --domain-ou=OU=Computers,OU=14000,OU=00000,DC=MS,DC=CVUT,DC=CZ

• běžná konfigurace sssd v /etc/sssd/sssd.conf

[sssd]
  services = nss, pam
  config_file_version = 2
  domains = MS.CVUT.CZ

[domain/MS.CVUT.CZ]
  id_provider = ad
  auth_provider = ad
  access_provider = ad
  chpass_provider = ad
  ldap_idmap_range_min = 100000000
  ldap_idmap_range_max = 2100000000
  ldap_idmap_range_size = 100000000
  ldap_idmap_default_domain_sid = S-1-5-21-3790076472-805733362-72324250
# chcete-li používat osobní číslo jako uživatelské uid pak je potřeba předchozí ldap_
# řádky zakomentovat a odkomentovat následující konfigurační volby
#  ldap_id_mapping = false
#  ldap_user_gid_number = uidNumber
  krb5_store_password_if_offline = true
  cache_credentials = true
  ignore_group_members = true
  override_gid = 100
  override_shell = /bin/bash
  override_homedir = /home/%u
  dyndns_update = false
  ad_enabled_domains = MS.CVUT.CZ
  ad_gpo_access_control = disabled
  ad_access_filter = (|(memberOf=CN=14000-SUMA-OSOBA-CVUT,OU=GROUPS,OU=IDM,DC=ms,DC=cvut,DC=cz))
# pokud potřebujete používat specifický keytab, tak jsou užitečné následující konfigurační volby
#  ldap_krb5_keytab = /etc/krb5.keytab.custom
#  krb5_keytab = /etc/krb5.keytab.custom
#  ad_hostname = keytabhostname.fjfi.cvut.cz
#  ad_maximum_machine_account_password_age = 0

• konfigurace mapování NFS identit

perl -p -i -e 's/^#Domain = .*/Domain = MS.CVUT.CZ/' /etc/idmapd.conf

• automatické připojení NFS svazku při startu systému

echo 'home.fjfi.cvut.cz:/home                   /home                   nfs4    defaults,nfsvers=4.2,sec=krb5p 0 0' >> /etc/fstab

• debug

# nastavit -vvvv parametr v /etc/sysconfig/nfs pro RPCGSSDARGS
echo 32767 > /proc/sys/sunrpc/rpc_debug
echo 65535 > /proc/sys/sunrpc/nfs_debug

• stejným způsobem lze připojit i data windows serverů exportovaná přes NFS

Skupiny

Správa členů AD skupiny pomocí adcli

Asi nejjednodušší způsob práce s Windows skupinami v linuxu, kdy pro přidání resp. odebrání uživatele ze skupiny 14101-ROC stačí zadat

adcli add-member --domain=MS.CVUT.CZ --login-user=svc-14000-write 14101-ROC vokacpet
adcli remove-member --domain=MS.CVUT.CZ --login-user=svc-14000-write 14101-ROC vokacpet

Balíček adcli má navíc velku minimální závislosti (narozdíl např. od samby)

Správa členů AD skupiny pomocí samby

Pro editování je nutné použít účet, který má oprávnění přidávat a odebírat členy požadovaných skupin. K modifikacím je pak možné použít příkaz net rpc group s vhodnými parametry.

• přímé ověření uživatelského jména a hesla privilegovaného uživatele

net -S hades.ms.cvut.cz -W MS.CVUT.CZ -U username rpc group members 14102-B13
net -S hades.ms.cvut.cz -W MS.CVUT.CZ -U username rpc group addmem 14102-B13 vokacpet
net -S hades.ms.cvut.cz -W MS.CVUT.CZ -U username rpc group delmem 14102-B13 vokacpet

• použití kerberos ticketu privilegovaného uživatele

# nejprve je potřeba získat kerberos ticket pro účet,
# který má práva přidávat / odebírat členy dané skupiny
kinit username@MS.CVUT.CZ
# k managování skupin slouží příkaz "net rpc group"
net -S hades16.ms.cvut.cz -W MS.CVUT.CZ -k rpc group members 14102-B13
net -S hades16.ms.cvut.cz -W MS.CVUT.CZ -k rpc group addmem 14102-B13 vokacpet
net -S hades16.ms.cvut.cz -W MS.CVUT.CZ -k rpc group delmem 14102-B13 vokacpet
# aktuálně tento způsob nefunguje při použití aliasu
# hades.ms.cvut.cz a musí se vybrat konkrétní KDC, viz.
dig @hades.ms.cvut.cz +short _kerberos._udp.ms.cvut.cz SRV

Manuální modifikace pomocí ldapmodify

• přidání uživatele do skupiny v ČVUT AD

# kinit username@MS.CVUT.CZ
# ldapmodify -H ldap://hades.ms.cvut.cz -f madd.ldif
dn: CN=14102-B13,OU=groups,OU=14102,OU=14000,OU=00000,DC=ms,DC=cvut,DC=cz
changetype: modify
add: member
member: CN=vokacpet,OU=V,OU=IDM,DC=ms,DC=cvut,DC=cz

• odstranění uživatele ze skupiny v ČVUT AD

# kinit username@MS.CVUT.CZ
# ldapmodify -H ldap://hades.ms.cvut.cz -f mdel.ldif
dn: CN=14102-B13,OU=groups,OU=14102,OU=14000,OU=00000,DC=ms,DC=cvut,DC=cz
changetype: modify
delete: member
member: CN=vokacpet,OU=V,OU=IDM,DC=ms,DC=cvut,DC=cz

Editování skupin v AD z Windows stanice

• nainstalovat management nástroje (moduly pro mmc)
• enablovat nainstalované moduly mmc

 # Windows 7
 Control Panel -> Programs and Features -> Turn Windows features on or off -> Remote Server Administration Tools -> AD DS and AD LDS Tools
 # windows 10
 Install "Remote Server Administration Tools for Windows 10"
 # windows 11
 Settings -> Apps -> Optional features -> View features -> RSAT*

• spustit příkazovou řádku cmd.exe s právy administrátora
• spustit mmc pod doménovým uživatelem

runas /netonly /noprofile /user:username@MS.CVUT.CZ mmc

• přidat modul pro management doménových uživatelů

File -> Add/remove Snap-in -> Active Directory Users and Computers

• nastavit správnou doménu nově přidanému modulu

pravá myš -> Change Domain... -> MS.CVUT.CZ