Difference between revisions of "Doména FJFI"
(→Autentizace) |
(→SSSD AD) |
||
Line 894: | Line 894: | ||
====SSSD AD==== | ====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. [[Doména FJFI#Host/Service Kerberos Key]]) | ||
+ | ** musí existovat <tt>/etc/krb5.keytab</tt> | ||
+ | ** musí fungovat ověření pomocí keytabu <tt>kinit -k -t /etc/krb5.keytab host/name.fjfi.cvut.cz@FJFI.CVUT.CZ</tt> | ||
+ | * uživatelské účty musí mit posixAccount atributy (viz. [[Doména FJFI#Konfigurace účtu v AD]]) | ||
[sssd] | [sssd] | ||
Line 927: | Line 932: | ||
ad_domain = fjfi.cvut.cz | ad_domain = fjfi.cvut.cz | ||
ad_server = ldap1.fjfi.cvut.cz,ldap2.fjfi.cvut.cz,ldap3.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 | |
− | # | + | # global |
− | + | min_id = 1000 | |
− | + | max_id = 30000 | |
cache_credentials = true | cache_credentials = true | ||
− | # access controls | + | |
− | ldap_access_order = expire | + | Pokud chceme omezit skupinu lidí, kteří budou mít přístup k linuxovému stroji se zkonfigurovaným SSSD AD, potom musíme zvolit <tt>access_provider = ldap</tt>, jelikož výše uvedený <tt>ad</tt> nemá žádné možnosti konfigurace (možná je v takovém případě přístup řízen přímo nějakou group policy v AD). Konfigurace vlastního service by pak mohla vypadat např. následovně: |
− | ldap_account_expire_policy = ad | + | |
− | ldap_force_upper_case_realm = true | + | [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 | ||
+ | # access controls - requires access_provider set to ldap | ||
+ | # (not necessary if you don't need e.g. group membership filtering) | ||
+ | '''ldap_access_filter = memberOf=cn=skupina,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''' | ||
# performance | # performance | ||
ldap_disable_referrals = true | ldap_disable_referrals = true | ||
Line 943: | Line 967: | ||
max_id = 30000 | max_id = 30000 | ||
cache_credentials = true | cache_credentials = true | ||
+ | enumerate = true | ||
====SSSD LDAP+Kerberos==== | ====SSSD LDAP+Kerberos==== |
Revision as of 22:16, 28 March 2014
Servery / Služby |
Přístupné komukoliv |
Omezený/individuální účet |
Služby |
backup · DHCP · DNS · doména FJFI · eduroam · fileserver · IdM · forum · gitlab · lists · moodle · indico · mailgw · K4 · mailserver · NMS · openvpn · skolniftp · ssh · videokonference · VoIP · video · VPN · wififjfi · wiki · www |
Učebny |
e-sklipek · KFE unixlab · KFE pclab · PD1 · KM 105 · KM 115 |
Ostatní |
Network · Blokované porty |
[edit] · [view] |
Contents
- 1 Servery
- 2 Sites
- 3 Firewall
- 4 Konfigurace DNS
- 5 NTP - synchronizace času
- 6 Rozšíření schemat Active Directory
- 7 Uživatelské účty
- 8 Diskové služby
- 9 Kerberos
- 10 LDAP
- 11 Certifikáty
- 12 Exchange
- 13 Konfigurace Linuxu/Unixu
Servery
jméno (aliasy) | umístění | funkce / poznámka |
---|---|---|
ARK1 | Břehová | DC, LDAP, fileserver (Home, Shareds), uživatelský IIS |
MRK1 | Břehová | Exchange, Hub-Transport, Client-Access, Mailbox |
BRK1 | Břehová | Exchange Edge, ForeFront |
ARK2 | Trojanova | DC, LDAP, fileserver (Home, Shareds), uživatelský IIS |
MRK2 | Trojanova | Exchange, Hub-Transport, Client-Access, Mailbox |
BRK2 | Trojanova | Exchange Edge, ForeFront |
SRK | Trojanova | terminal server Windows |
VRK2 | Trojanova | virtualizační server |
Troja1 | Trója | DC, fileserver |
DRK | Děčín | DC, LDAP |
ARK3 | Děčín | Fileserver |
jméno (aliasy) | umístění | funkce / poznámka |
---|---|---|
KMK | VRK2 | antivir (NOD32) aktualizační server, remote management |
Print2 | VRK2 | printserver Trojanova |
IT | VRK2 | IIS pro účely infrastruktury |
SCP | VRK2 | SSH remote access pro namespace FRK |
Witness | VRK2 | Exchange cluster witness |
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
protokol | port | rozsah |
---|---|---|
echo | ICMP | 147.32.0.0/16 (resp. rozsah FJFI), pro servery s veřejnými službami by bylo vhodné 0.0.0.0/0 |
SMTP | 25 TCP | 147.32.5.45, 147.32.9.3 (mailgw) - pouze pro exchange servery |
DNS | 53 TCP+UDP | 147.32.0.0/16, 2001:718:2::/48 (tam kde je potřeba z důvodu provozu rekurzivního DNS) |
LDAP | 389 TCP+UDP | 0.0.0.0/0 |
LDAPs | 636 TCP | 0.0.0.0/0 (stačí na strojích s důvěryhodnými certifikáty) |
LDAP GC | 3268 TCP | ?.?.?.? (global catalog), minimálně pro FJFI (ČVUT) |
Kerberos | 88 TCP+UDP | 0.0.0.0/0 |
Kerberos kpasswd | 464 TCP+UDP | 0.0.0.0/0 |
|
|
|
NTP Time Service | 123 TCP+UDP | 0.0.0.0/0? minimálně pro FJFI (ČVUT) |
SNMP | 161 TCP+UDP | pro management stroje (nms.fjfi.cvut.cz) |
Samba | 137,138,139,445 TCP+UDP | minimálně rozsah FJFI (ČVUT?) |
RPC | 135 TCP | rozsah FJFI(?) (ČVUT?) - nutné pro připojení počítače do domény |
RPC(?) | 2235 TCP | mezi doménovými kontrolery(?) - nutné WMI(?) |
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í.
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: ???
Prop.Set | SELF | AUTH |
---|---|---|
General | r | |
Public | r | |
Private | ||
Personal | rw | r |
rw | ||
Web | rw | r |
Membership | ||
User-Logon | ||
User-Account | ||
Exchange |
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.
jméno | využití a práva |
---|---|
proxy_posix | pro ou=People - read/search pro posixAccount atributy; omezení na IP rozsah FJFI (ČVUT?) |
proxy_wifi | pro ou=People - read/search pro sAMAccountName, fnspeEduroam*, fnspeWifi*; omezení na IP Radius serverů a NMS |
proxy_mailgw | pro ou=People - read/search pro proxyAddresses, targetAddress, amavis*; omezení na IP mailgw serverů a NMS |
proxy_nms | pro ou=People - read/search/write konfigurace účtu fnspe*, amavis*, targetAddress, read/search proxyAddress, write(reset) unicodePwd; omezení na IP NMS write práva na "Reset Password" pro objekty User, inetOrgPerson; write práva na atribut pwdLastSet pro objekty User, inetOrgPerson (atribut je součástí property setu User-Account-Restrictions); write práva na Public-Information property set pro objekty User, inetOrgPerson; |
proxy_usermap | pro ou=People - read/search mail, read/search ctuPersonaId; omezení na IP ČVUT(?) |
proxy_host proxy_service |
účet pro Kerberos host/service ticket host/hostname@FJFI.CVUT.CZ resp. service/hostname@FJFI.CVUT.CZ, více informací na #Host/Service Kerberos Key a v KB 324144 |
proxy_bind | testovací uživatelský účet monitoring LDAP, nulová práva krom autentizovaného LDAP bind |
|
|
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
- uživatel obdrží info chystaném zablokování jeho účtu emailem
- po 30 dnech je účet přesunut do ou=Trash a zablokován, status nastaven na "zombie" a poznamená se timestamp
- účty v ou=Trash jsou automaticky označeny na zrušení po uplynutí 14 měsíců
- účet bude po uplynutí 14 měsíční lhůty zapsán do souboru accounts_to_remove.xml
- výmaz účtů bude proveden ručně pro účty, zapsané v souboru accounts_to_remove.xml
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]
atribut | typ | popis |
---|---|---|
Uživatelské jméno | ||
sAMAccountName | C | uživatelské jméno - pro studenty Usermap username, pro zaměstnance příjmení(?); pro případ konfliktu mít algoritmus pro automatické řešení - musí brát v úvahu již existující jména, mailové adresy (musí existovat možnost vytvořit adresu "sAMAccountName"@fjfi.cvut.cz), |
cn | C | nastavit na stejnou hodnotu jako sAMAccountName |
uid | C | nastavit na stejnou hodnotu jako sAMAccountName |
msSFU30Name | C | nastavit na stejnou hodnotu jako sAMAccountName |
posixAccount | ||
uidNumber | C | vyplnit jen při vytváření účtu, jedinečné číslo v intervalu <1000,30000), pro první import použít informace z dokumentu o migraci uživatelských účtů |
gidNumber | C | vyplnit jen při vytváření účtu číslem 1000 |
homeDirectory | C | vyplnit jen při vytváření účtu stringem /home/"sAMAccountName" |
loginShell | C | vyplnit jen při vytváření účtu stringem /bin/bash |
gecos | A | synchronizovat vždy stringem vytvořeným z "givenName sn", bez diakritiky |
| ||
A | pro zaměstnance Jméno.Příjmení@fjfi.cvut.cz pro studenty "sAMAccountName"@fjfi.cvut.cz (pozor na jména/příjmení, které se skládají z více části oddělených mezerami), pro první import použít informace z dokumentu o migraci uživatelských účtů; v případě konfliktu zaměstnanecké adresy Jméno.Příjmení@fjfi.cvut.cz tuto adresu nevytvářet, ale poslat mail správci | |
proxyAddresses | AA | pro všechny "sAMAccountName"@fjfi.cvut.cz, zaměstnanci navíc Jméno.Příjmení@fjfi.cvut.cz (v případě konfliktu informovat správce mailem nebo lépe rozmyslet algoritmus pro automatické řešení těchto případů), nastavit defaultni adresu na tu "nejhezčí" (pokud existuje např. Jméno.Přijmení@fjfi.cvut.cz) - prefix SMTP:, ostatní mají prefix smtp: |
|
|
|
uživatelské informace | ||
displayName | A | kvůli hledání synchronizovat plně jméno (včetně titulů) s diakritikou a bez diakritiky (do atributů displayName, displayName;lang-cs, displayName;lang-en), displayName vyplnit prozatím bez diakritiky, |
name | A | to samé co do displayName (?) - nyní jen jméno bez diakritiky a bez titulů |
wWWHomePage | A | synchronizovat oUser.privateWeb |
facsimileTelephoneNumber | A | synchronizovat oUser.fax |
telephoneNumber | A | synchronizovat oUser.phone |
mobile | A | synchronizvat oUser.mobilePhone |
otherPhone | A | synchronizovat oUser.privatePhone |
??? | A | synchronizovat oUser.privateMail (existuje nějaký vhodný standardní atribut? pokud ano, tak ho použít. |
department | A | synchronizovat vše z oUser.departmentName |
departmentNumber | A | synchronizovat vše z oUser.departmentNumber |
fnspeStatus | A | synchronizovat oUser.status ("new", "active", "kill", "zombie", "dead", "unknown") |
fnspeStatusTimestamp | ? | časová značka změny fnspeStatus, měnit pouze v případě, že se mění také fnspeStatus |
c | C | nastavit při vytváření na "CZ" |
co | C | nastavit při vytváření na "Czech Republic" |
l | A | synchronizovat oUser.address(0).city |
street | A | synchronizovat oUser.address(0).street |
postalCode | A | synchronizovat oUser.address(0).zip |
title | C | nastavit na "CTU FNSPE" |
další zajímavé atributy | ||
memberOf | AP | podle skupin existujících v AD a v oUser.groups, podrobné vysvětlení dále u popisu skupin |
profilePath | C | vybrat server podle místa katedry phd studenta či zaměstnance |
scriptPath | ? | |
userAccountControl | ? | pro blokování účtu(?) |
Legenda:
- C - vyplnit při vytváření nového účtu
- A - synchronizovat vždy podle aktuálních údajů (z Usermapu)
- AA - pouze přidávat aktuální údaje (zachovat všechny stávající hodnoty atributu)
- AP - zachovat "neznámé" hodnoty a synchronizovat ostatní dle definovaného seznamu
Konfigurace synchronizace
Synchronizační skript si bude načítat externí soubor s konfiguracemi. Zde budou uloženy informace potřebné pro přístup k informačním systémům (jména/hesla) a také seznam cvutPersonalId, které se nemájí importovat z Usermapu. Také zde bude seznam uživatelských jmen, které nelze použít pro hodnotu atributu sAMAccountName (např. root, abuse, mail, ...)
API synchronizačního skriptu
FIXME: tohle není finální verze, je potřeba detailně promyslet - no snad už to je trošku kompletní
Synchronizační skript by měl poskytnout přehledné API k následujícím operacím:
- fnspeSync()
- synchronizuj s Usermapem - smaž/přesuň/updatuj/vytvoř účty (vrátí mailem informace o konfliktech, nekonzistencích, ...)
- fnspeSync(cvutPersonalId)
- synchronizuj jednoho konkrétního uživatele
- fnspeCreateUser(type, cvutPersonalId, username, ou, dictionary)
- vytvoř uživatele - obecná funkce (nebude volána přímo, ale přes specializovanější fce), parametry nemusí mít nastavenou hodnotu, je-li nastaveno
- type - typ účtu ("user", "mail") - asi udělat jako bitovou mapu
- user - standardní účet
- mail - vytvořit také mailstore
- cvutPersonalId, dotáhne informace z Usermapu
- username - je preferováno před tím případně dotaženým z Usermapu
- ou - vytvoří uživatele v příslušné ou (jinak standardně v ou=Auto)
- dictionary - vše se zkopíruje do hodnot atributů vytvářeného uživatele
- fnspeCreateUsermapUser(...)
- stejné parametry jako předchozí fce mimo typu, který bude nastaven na "user"+"mail", cvutPersonalId je povinný
- fnspeCreateFnspeUser(...)
- stejné parametry jako předchozí fce mimo typu a cvutPersonalId (nastaveno automaticky na "user"+"mail" resp. prázdná hodnota), username je povinný
- fnspeCreateGuestUser(...)
- stejné jako createFnspeUser, ale typ jen "user" (tj. vytvořit bez mailstore), před username přidá prefix "guest_", založí v ou=Guest
- fnspeTrashUser(dn)
- přesune uživatele s DN do ou=Trash a disabluje přístup
- fnspeRemoveUser(dn)
- úplně odstraní uživatele s DN včetně mailstore a dat(?)
změň charakter účtu - povinné parametry: operace (add|remove), charakter (user|contact|mail|eduroam|fnspe|...)samostatná konfigurace způsobu synchronizace pro všechny atributy (full|add|add+remove_list|one_time|...) - FIXME: promyslet
- fnspeCreateOfficialAddresses(dn)
- pokud je vyplněn atribut targetAddress nebo homeMDB (prostě má nastaven forward nebo existuje účet na Exchange) tak přidá do atributů proxyAddresses adresu username@fjfi.cvut.cz a pro zaměstnance navíc jméno.příjmení@fjfi.cvut.cz (zas v případě konfliktu s existující adresou ji nepřidá a pošle mail správci), nastaví atribut mail na jméno.příjmení@fjfi.cvut.cz - pro ty, co tuto adresu mají - pro ostatní na username@fjfi.cvut.cz
- fnspeCreateMailstore(dn)
- vytvoří mail účet na Exchange
- fnspeRemoveMailstore(dn)
- zruší účet na Exchange
Motivace je pro poslední tři funkce je taková, že se při synchronizaci _nebude_ automaticky vytvářet účet na Exchange (kvůli externím spolupracovníkům, kteří by ji stejně nepoužívali - pár se mi jich totiž teď ozvalo) a vytvoří se až v okamžiku, kdy si uživatel bude "aktivovat účet" (bude si nastavovat heslo) - v tom okamžiku budeme potřebovat funkci, která pro daného uživatele založí mail účet na správném Exchange serverů a pak přidá správné mailove adresy (formulář pro "aktivaci účtu" si tu vytvoříme sami).
- bylo by dobré, aby existoval nějaký "verbose" mód, který by na stdout nebo stderr vypisoval hlášky o průběhu synchronizace
- bylo by dobré mít nějaké jednoduché commandline rozhraní k uvedeným funkcím
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
Instaluje/registruje se příkazem (z .NET frameworku, měl by být někde v c:\windows\Microsoft.NET\Framework):
installutil.exe "c:\cesta\k\binarce\FnspeCmdWindowsService.exe" # pro odinstalaci lze použít příkaz: # installutil.exe /u "c:\cesta\k\binarce\FnspeCmdWindowsService.exe"
Poté je možné tuto službu spouštět/zastavovat standardním souborem přes mmc (je potřeba nastavit, aby se spouštěla automaticky při startu systému). Na firewallu je nutné povolit přístup na port, na kterém bude služba poslouchat. Z hlediska bezpečnosti je vhodné povolit přístup pouze z IP adres, které tuto službu nezbytně potřebují.
Po prvním spuštění vytvoří v registrech klíč s konfigurací, kterou je pak možné upravit:
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
Příklad záznamů v registrech:
[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"
Otestovat se dá nejlépe nějakým rozumným telnet klientem (ten ve woknech nepatří mezi ty rozumné)
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:
- instalace kořenové CA, která podepsala LDAP rozhraní Usermapu (aktuálně CESNET CA)
- ODBC driver pro MySQL
- starší verzi 3.51 (5.1 není aktuálně podporovaná DB na Usermapu)
- pro skripty je potřeba nainstalovat 32bit verzi i na 64bit systému
- pro C# je (asi) potřeba 32bit i 64bit verze (instalováno/registrováno ručně z admin shellu pomocí "install.bat 0")
- korektní konfigurace v FnspeLibrary.config
- WMI přístup k ostatním serverům (fileserver, IIS, ...) - firewall na TCP port 135, 2235
- // copy xcacls.exe in the SCRIPT_PATH (no longer required, using default icacls.exe)
- naimportovaná AD schemata (amavisAccount, fnspeAccount)
- minimálně w2k3 nativní mód domény i forestu (support for auxial classes)
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ů.
Eduroam jméno
Jméno pro Eduroam se musí skládat z uživatelského jména a realm, který slouží jako identifikátor domovské instituce. Vlasní autentizace uživatele tak může být delegována na domácí RADIUS servery. Uživatelské jméno na FJFI bude mít tvar "sAMAccountName"@fjfi.cvut.cz. Bylo by dobré, aby toto jméno bylo zároveň platnou mailovou adresou uživatele. Pomocí eduroam atributů v AD bude možné zablokovat samostatně přístup k Eduroam účtu bez blokace vlastního AD účtu.
FIXME: zajištění přístupu hostů k WiFi bude tedy na správcích Windows
Mailové adresy
Všichni uživatelé budou mít adresu ve tvaru "sAMAccountName"@fjfi.cvut.cz (tedy stejnou jako "Eduroam jméno"), zaměstnancům bude navíc automaticky generována adresa ve tvaru Jméno.Příjmení@fjfi.cvut.cz. V případě konfliktu nebude adresa automaticky vytvořena, ale o vzniklé situaci bude ihned informován správce mailem. Uživatelům Terezy může být ručně přidána ještě adresa ve tvaru Jméno.Příjmení@tereza.fjfi.cvut.cz.
Historické oficiální adresy user@km1.fjfi.cvut.cz a user@troja.fjfi.cvut.cz budou zachovány jen na požádání (stejně jako tomu bylo/je pro user@br.fjfi.cvut.cz). Příjem bude zajištěn přímo na Exchange, nebude docházet k žádnému přepisování příchozích ani odchozích neoficiálních adres. Adresy user@kmk.km.fjfi.cvut.cz budou zrušeny, jelikož existovali jen z důvodu interního směrování mailů.
U nově automaticky vytvářených adres je potřeba zkontrolovat, jestli obsahují jen povolené znaky [a-zA-Z0-9_.-] (hlavně při generování adres Jméno.Příjmení@fjfi.cvut.cz, protože to občas obsahuje speciální jinde neošetřené znaky). Pokud nová adresa nesplňuje tyto požadavky, bude o tom správce informován mailem.
Heslo
Uživatelská hesla musí mít definovanou minimální složitost, aby se zabránilo slovníkovým útokům. Heslo musí být minimálně 8 znaků dlouhé a musí obsahovat alespoň dvě skupiny znaků (písmena malá/velká, číslice, speciální znaky). FIXME: Je potřeba každé heslo zkontrolovat proti slovníku. Pro host/service kerberos účty mohou být hesla úplně neznámé náhodně generované znaky. Je potřebné/vhodné mít různé reálné účty pro různé hosty?
Platnost hesla není omezena, ale pokud to bude situace v budoucnu vyžadovat, může být zavedena povinnost pravidelné změny hesla.
Pro přihlašování je nutné vždy používat zabezpečené spojení (TLS/SSL nebo nějaký ekvivalent). Služby u nichž nelze zajistit vyzrazení hesla po nezabezpečeném kanále nesmí být vůbec provozovány (např. IMAP, HTTP, ...). U ostatních musí dojít k odmítnutí spojení před vlastním přenosem hesla.
Skupiny
Skupiny by měli obsahovat stejně jako uživatelská jména znaky [a-z0-9_-] (malá písmena, číslice, podtržítko a pomlčka). Dále je vhodné, aby délka názvu skupiny nepřevyšovala 8 znaků. Důvodem je maximální možná kompatibilita s Unix systémy. Kvůli unixovým resp. POSIX compatible systémům musí každá skupina obsahovat posixGroup třídu. Skupinové ID třídy musí být jedinečné >= 1000.
Každý uživatel bude dle informací v Usermapu automaticky zařazen do skupin zaměstnanec/doktorand na příslušné katedře (existence všech skupin není povinná, neexistence těchto skupin nebude brána jako chyba při synchronizaci účtů). Navíc bude možné ručně přidat každého uživatele do skupiny vyhrazené každé katedře. Poslední možností je přidaní nazvu skupiny do atributu fnspeForceGroup a to při synchronizaci způsobí, že uživatel bude přidán jako memberOf odpovídající skupiny. Mohou existovat následující standardní skupiny:
název | GID | využití |
---|---|---|
1000-1099 | vyhrazeno pro potřeby fakulty (1000-1010 vyhrazeno pro automaticky spravované skupiny, 1011-1049 rezervováno pro budoucí využití) | |
users | 1000 | standardní skupina pro všechny uživatelské účty |
1001 | unassigned | |
emp | 1002 | skupina pro všechny zaměstnance |
phd | 1003 | skupina pro všechny phd studenty |
stu | 1004 | skupina pro všechny studenty (mimo PhD) |
decin | 1006 | skupina pro uživatele v Děčíně |
troja | 1007 | skupina pro uživatele v Troji |
external | 1010 | skupina pro externisty |
1X00-1X99 | vyhrazeno pro potřeby katedry (1X00-1X10 vyhrazeno pro standardní automaticky spravované skupiny, 1X11-1X49 rezervováno pro budoucí využití) | |
"depName" | 1X00 | ručně spravovaný seznam lidí na dané katedře |
"depName"_all | 1X01 | "depName"+"depName"_emp+"depName"_phd |
"depName"_emp | 1X02 | zaměstnanec katedry (automaticky synchronizováno dle Usermapu) |
"depName"_phd | 1X03 | phd student katedry (automaticky synchronizováno dle Usermapu) |
"depName"_stu | 1X04 | student katedry, mimo PhD (zatím používá KMAT, ruční zadávání) |
"depName"_staff | 1X05 | učitel na katedře (automaticky synchronizováno dle Usermapu) |
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.
skupina | rozsahy GID |
---|---|
users | 1000 |
km | 1100-1199 |
kf | 1200-1299 |
kj | 1300-1399 |
kipl | 1400-1499 |
kfe | 1500-1599 |
kmat | 1600-1699 |
kjch | 1700-1799 |
kdaiz | 1800-1899 |
kjr | 1900-1999 |
kse | 2000-2099 |
dekanat | 2100-2199 |
tereza | 2200-2299 |
crrc | 2300-2399 |
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
písmeno | funkce / poznámka |
---|---|
A-L | vyhrazeno pro lokální zařízení (disky, cdrom, uživatelské síťové disky, ...) |
M-S | vyhrazeno pro potřeby fakulty (globálních a lokálních správců - využití nutno uvést do této tabulky!) |
M: | síťový domovský adresář |
N: | sdílená složka v rámci katedry (organizační jednotky) |
O: | veřejně přístupná složka napříč všemi částmi fakulty |
P: | osobní webová prezentace (Public HTML) |
S: | síťový adresář s instalačními zdroji (admins/rw, users/ro) |
T-Z | vyhrazeno pro potřeby lokálního uživatele |
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).
Příklad simple autentizace:
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):
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") 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)
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 [1000-30000)
- gidNumber - zatím jedna skupina "users" s gidNumber = 1000
- loginShell - /bin/bash
- unixHomeDirectory - /home/"sAMAccountName"
- gecos - ASCII "givenName sn"
Synchronizace času
Pro správnou funkci Kerbera je nutná synchronizace času mezi autentizovaným systémem a KDC serverem (tolerance 5 minut). Je potřeba, aby se klienti synchronizovali proti nějakému přesnému časovému zdroji. Pro tyto účely zde běží NTP server na adrese ntp.fjfi.cvut.cz (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
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 1000 # RFC 2307 (AD) mappings nss_map_objectclass posixAccount user nss_map_objectclass shadowAccount user nss_map_attribute uid sAMAccountName nss_map_attribute homeDirectory unixHomeDirectory nss_map_attribute shadowLastChange pwdLastSet nss_map_objectclass posixGroup group nss_map_attribute uniqueMember member pam_login_attribute sAMAccountName pam_filter objectclass=User pam_password ad # Disable SASL security layers. This is needed for AD. sasl_secprops maxssf=0
- /etc/openldap/ldap.conf
BASE dc=fjfi,dc=cvut,dc=cz URI ldaps://ldap1.fjfi.cvut.cz ldaps://ldap2.fjfi.cvut.cz 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.
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. Doména FJFI#Host/Service Kerberos Key)
- musí existovat /etc/krb5.keytab
- 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. Doména FJFI#Konfigurace účtu v AD)
[sssd] domains = LOCAL,AD 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/AD] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad 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 # global min_id = 1000 max_id = 30000 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 nemá žádné možnosti konfigurace (možná je v takovém případě přístup řízen přímo nějakou group policy v AD). Konfigurace vlastního service by pak mohla vypadat např. následovně:
[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 # access controls - requires access_provider set to ldap # (not necessary if you don't need e.g. group membership filtering) ldap_access_filter = memberOf=cn=skupina,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 # performance ldap_disable_referrals = true # global min_id = 1000 max_id = 30000 cache_credentials = true enumerate = true
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 min_id = 1000 max_id = 30000 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 ldap_default_bind_dn = CN=proxy_posix,OU=Specials,DC=fjfi,DC=cvut,DC=cz ldap_default_authtok_type = password ldap_default_authtok = secret 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 ldap_disable_referrals = 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 = 1000 max_id = 30000 cache_credentials = true account_cache_expiration = 7 entry_cache_timeout = 14400 enumerate = true
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 >= 1000 quiet auth [authinfo_unavail=ignore success=1 default=2] pam_krb5.so minimum_uid=1000 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 < 1000 quiet account [authinfo_unavail=ignore default=done] pam_krb5.so minimum_uid=1000 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=1000 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=1000
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ů.
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].
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 TEST$ v AD dsrm -noprompt "CN=TEST,CN=Computers,DC=fjfi,DC=cvut,DC=cz" dsadd computer "CN=TEST,CN=Computers,DC=fjfi,DC=cvut,DC=cz" # vytvoření/asociace host kerberos principálu C:> ktpass -ptype KRB5_NT_PRINCIPAL -princ host/test.fjfi.cvut.cz@FJFI.CVUT.CZ -mapuser TEST$ -pass +rndPass +Answer -out test.keytab [ -mapOp set -kvno 1 ] # vytvoření služby ftp pro hosta test.fjfi.cvut.cz C:> ktpass -ptype KRB5_NT_PRINCIPAL -princ ftp/test.fjfi.cvut.cz@FJFI.CVUT.CZ -mapuser TEST$ -pass +rndPass +Answer -SetUpn -out test.keytab [ -mapOp set -kvno 1 ] # pro lepší kompatibilitu s MIT kerberem se prý hodí parametr -crypto DES-CBC-MD5
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).
Vytvoření keytabu v linuxu pomocí msktutil
Na linuxu je potreba nainstalovat msktutil, 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 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 # 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
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).
# získání kerberos ticketu (abychom pro některé z následujících příkazu nemuseli zadávat heslo) kinit admin # odstranění záznamu o počítači TEST1234 z AD net -U admin -n TEST1234 ads leave # přidání záznamu o počítači TEST1234 do AD net -U admin -n TEST1234 ads join createupn=host/test1234.fjfi.cvut.cz@FJFI.CVUT.CZ [ osName=Linux osVer=5 ] # vypsání informací o počítači TEST1234 z AD net -n TEST1234 ads status # _kompletní_ vyčístění keytabu net -n TEST1234 ads keytab flush # vytvoření keytabu net -n TEST1234 ads keytab create # vypsání informací z keytabu net -n TEST1234 ads keytab list # přidání služby do keytabu net -n TEST1234 ads keytab add ldap net -n TEST1234 ads keytab add DNS ...
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 TEST$ -pass +rndPass +Answer -SetUpn ktpass -ptype KRB5_NT_PRINCIPAL -princ ftp/test.fjfi.cvut.cz@FJFI.CVUT.CZ -mapuser TEST$ -pass +rndPass +Answer -SetUpn ktpass -ptype KRB5_NT_PRINCIPAL -princ http/test.fjfi.cvut.cz@FJFI.CVUT.CZ -mapuser 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
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.
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") ;winbind separator = \\ idmap backend = tdb idmap uid = 1000000-1999999 idmap gid = 1000000-1999999 idmap config FJFI : backend = ad idmap config FJFI : range = 1000-29999 winbind nss info = rfc2307 # allow enumeration of winbind users and groups # (this should be probably set to "no" for huge domains) winbind enum users = yes winbind enum groups = yes # give winbind users a real shell (only needed if they have telnet access) ;template homedir = /home/%D/%U ;template shell = /bin/bash # Winbind usernames without DOMAIN prefix winbind use default domain = 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