Portál AbcLinuxu, 8. června 2024 02:57
Nejprve musím osvětlit, co stojí za tím, že použijeme Linuxový server a integrujeme jej do domény s Windows Server 2003.
V roce 2001 jsme přešli z Windows NT 4.0 server na Sambu 2.2. Důvodem pro tento přechod byla havárie serveru a také to, že Samba 2.2 začala spolupracovat s věcmi jako jsou ACL. Předpokladem pro správnou funkčnost ACL pod Sambou byla správná implementace ACL souborovým systémem. Jediným v té době vhodným souborovým systémem bylo v té době XFS.
V roce 2005 jsme přešli ze Samby 2.2 na Windows Server 2003. Důvodem pro tento přechod byla nutnost jemnějšího nastavování práv jednotlivých uživatelů. Systém GPO integrovaný do ActiveDirectory byl pro tuto úlohu prakticky jediným řešením. Další možností by bylo zakoupit NDS a instalovat klienty NDS. Pro vysvětlení, ActiveDirectory opravdu není jen o LDAP. ActiveDirectory nelze v Linuxu plně nahradit OpenLDAPem, protože OpenLDAP je v takovém případě pouze úložištěm a Linux sám o sobě nemá mechanismy na nahrazení věcí jako je systém GPO.
Potřebujeme vytvořit zálohovací server, na který si budou uživatelé odkládat svá data. Velikost sdíleného disku bude limitována pomocí kvót a také zajistit úložiště pro zálohovaná data z produkčních serverů, odkud budou tato data dále zálohována na zálohovací zařízení.
Jako operační systém jsme vybrali OpenSUSE 10.0, tato distribuce byla před nedávnem vypuštěna do světa.
Vzhledem k tomu, že se jedná o serverovou instalaci a neplánujeme instalovat věci jako Oracle a podobně, provedeme instalaci pouze základního systému, neboli textový režim. Pro správnou funkčnost celého systému můžeme již při instalaci vybrat následující balíky.
MC je takovou třešničkou na dortu, která není povinná, ale mc je pro mne osobně dobrým pomocníkem.
Jednou z veledůležitých částí, při integraci Linuxu do domény Windows Server 2003 je existence NTP časového serveru. Bez časové synchronizace dojde k tomu, že Linux se nebude moci v doméně ověřit. Toto vyplývá z chování autentikačního systému Kerberos. Dobrou variantou je vytvořit z doménového serveru zároveň NTP server a Linux synchronizovat právě s tímto časovým serverem.
Následuje nutnost konfigurace Kerbera, tak aby Linux mohl být ověřen na Windows Server 2003 a počítač směl být přidán do domény. V případě využívání Samby totiž platí stejná pravidla jako pro stanice s OS Windows 2000 a vyšším. Je tedy nutno provádět autentikaci pomocí systému Kerberos.
Co tedy budeme potřebovat. Správně nastaveného DNS klienta. Tedy v souboru /etc/resolv.conf zadán server s AD a prohledávání domény AD.
Dále jméno serveru s AD zapsané v /etc/hosts.
A nastavený krb5.conf
[libdefaults]
default_realm = JMENO.AD_DOMENY
clockskew = 300
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
JMENO.AD_DOMENY = {
kdc = ip_adresa_AD
default_domain = jmeno.domeny
admin_server = ip_adresa_AD
}
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log
[domain_realm]
.jmeno.ad_domeny = JMENO.AD_DOMENY
jmeno.ad_domeny = JMENO.AD_DOMENY
[appdefaults]
pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
retain_after_close = false
minimum_uid = 0
try_first_pass = true
krb4_convert = false
}
Doporučuji u kdc a admin serveru psát přímo IP adresy a téměř nutností je zákaz dns_lookupů v sekci libdefaults. Dojde k tím neskutečnému zrychlení práce Kerbera, řádově z desítek minut na sekundy.
Dalším upozorněním je to, že v konfiguračním souboru musí být jména domén a realmů uvedena s ohledem na velikost písmen. Tedy Kerberos vyžaduje realmy zapsány velkými písmeny, zatímco DNS názvy bývají většinou malými písmeny. Pozor tedy na tuto skutečnost, jinak se vám Linux nepodaří připojit do domény.
Po nakonfigurování Kerbera musíme přihlásit systém do ověřovacího procesu. Příkazem:
kinit Administrator@JMENO.AD_DOMENY
Nyní můžeme přistoupit k samotné konfiguraci Samby.
Nakonfigurujeme tedy soubor smb.conf
[global]
workgroup = JMENO_DOMENY
realm = JMENO.AD_DOMENY
preferred master = no
security = ADS
encrypt passwords = yes
log level = 3
log file = /var/log/samba/%m.log
max log size = 50
printing = cups
printcap name = cups
idmap uid = 10000-20000
idmap gid = 10000-20000
[users]
path = /home/%U
valid users = @"JMENO_DOMENY\Domain Users"
read only = no
directory mask = 2777
create mask = 2666
Nyní máme nakonfigurovánu Sambu. Provedeme test konfigurace příkazem testparm.
Pokud je vše v pořádku spustíme Sambu příkazem rcnmb a rcsmb.
Nyní připojíme server do domény příkazem net ads join -U Administrator.
Ovšem pro správnou funkčnost celého systému potřebujeme, aby Linux přebíral informace o uživatelích přímo ze systému Windows Server 2003. K tomu nám slouží winbind. Musíme nakonfigurovat soubor /etc/nsswitch.conf tak, aby bral nastavení winbindu. A to následujícím způsobem:
passwd: compat winbind
group: compat winbind
shadow: compat
hosts: files dns wins
Test správnosti běhu winbindu otestujeme příkazem wbinfo –u. Tento příkaz musí vypsat uživatele zavedené v AD. Nyní nám k úspěšnému provozu stačí pouze jeden krok a to je nastavení samby jakožto služby, která se spouští při zapnutí počítače. Pro správný běh musí být spuštěny služby smb, nmb a winbind. Doporučuji vypnout vše, co se týká NFS, obzvlášť službu nscd.
Doufám, že tento postup pomůže k dalšímu rozmachu Linuxových serverů i v rámci sítí založených na Windows Server 2003.
Tiskni
Sdílej:
Ten zakládá samba příkazem net ads join -U Administrator.
Pokud bude potřeba zaregistrovat v AD i jiné služby, pak se to děje následujícím způsobem.
ktpass -princ pop3/nazev_stroje@JMENO.AD_DOMENY -mapuser jmeno_vytvoreneho uzivatele -user Administrator@JMENO.AD_DOMENY -pass -out jmeno_stroje.key
Pak se to přes kinit namapuje. Zatím jsem to ale moc nepotřeboval.
net) jsem v tvem postupu nenasel, kde se bezpecne prenasi keytab s credentials z KDC (AD) na klienta (Samba server).
Aha. Program net je zmíněn až v sekci přidání do domény. Prakticky jsem si ověřil, že pro sambu nebyl potřeba importovat keytab. Pouze pomocí kinit se napojit na kerberový server "kinit Administrator@JMENO.AD_DOMENY"
Já jsem dělal u zákazníka přechod na Windows server proto, že bylo potřeba jemněji nastavovat práva. GPO je něco ve stylu RSBAC (abych to přiblížil), jenže se to nastavuje na serveru a tyto nastavení se přenášejí pomocí ActiveDirectory na ostatní členy domény. GPO mají zatím kolem 400 položek, které jdou nastavit. Prosím nezaměňovat s ACL a EA.
Samba verze 3 je skvělý nástroj, dá se využít tam, kde plně postačuje doménový styl ve stylu Windows NT 4.0. Má pár vychytávek navíc, které nemá ani Windows Server 2003. Např. to co jde vyvádět se sdílenými složkami u Samby, to nejde ani s nejnovějším systémem. Ani Win2k3 nezvládne vytvořit sdílení typu /home/%U. Jde to obejít při mapování, ale to správně funguje jen na Win2000 a vyšších. :) (net use \\sdileni\%username%).
Kupodivu třeba AD jde vytvořit i takovým způsobem, že uložiště bude tvořeno na Linuxovém serveru, kde běží OpenLDAP a s MIT implementací Kerbera 5. Je to sice hooodně složitá procedura, ale jde to uchodit. :) Jediné k čemu je právě potřeba ten W2k3 server je interpretace GPO a tak dále. :)
, hledam ruzny reference o tom, co to vlastne GPO (Group Policies Objects) jsou a jak fungujou. Jeden znamy mi povidal, ze to je snad jenom proste kus registru, ktery si stanice po prihlaseni do domeny nactou z profilu. Je to pravda (a tim padem (ale jako naprosty newbe) nevidim duvod nedistribuovat soubor(y) s dotycnym kusem registru Sambou) a nebo se pletu?
Není důvod proč soubory nedistribuovat přes Sambu. :) Je to pořád jen jedna služba, kterou poskytuje MS síť. :) A Samba umí tuto službu naprosto skvěle.
Problém s GPO je ten, že Win2k3 si informace o GPO uchovávají právě v LDAPové struktuře AD.
GPO si je možno představit jako části registrů, ale problém je v tom, že GPO fungují globálně. Ve struktuře AD si vytvořím nějakou OU a té přiřadím nějaké politky z GPO (Group Policy Objects). Valná většina věcí, co jsou v GPO jde nastavit v registrech, rozdíl mezi registry a GPO je podobný, jako udržovat uživatele v NIS anebo ručně udržovat passwd soubory na všech počítačích ve firmě.
GPO jsem začal využívat ve firmách, kde potřebuji jemnější přístup k právům než je rozdělení "User/PowerUser/DomainAdmin"
Jinak to co lze nastavit v GPO lze nalézt na stanici s Windows XP v "Ovládacích panelech/Nástroje pro správu/Místní zásady zabezpečení" omlouvám se za ten registr, ale ono je to částečně uchováno i v něm.
Abych uvedl nějaký příklad.
Vezměme si, že ve firmě máme starý DOSový program, který pro určité funkce vyžaduje, aby uživatel mohl měnit systémový čas.
Standardně máme 2 možnosti jak to vyřešit. První možností je dát lokálně jednotlivým uživatelům práva PowerUser na stanici. Druhou možností je v Místních zásadách zabezpečení změnit danému uživateli právo na Změnu systémového času.
V případě využívání GPO v rámci W2k3 AD vytvoříme nějakou OU (organizační jednotku) do které přiřadíme dané uživatele nebo počítače. Nad touto OU vytvoříme GPO, kde změníme právo na Změnu systémového času. a máme vystaráno. Nemusíme si pamatovat, kde a komu jsme to právo přidělili a jestli náhodou někdo nemá zbytečně zvýšené práva.
ní jednotku) do které přiřadíme dané uživatele nebo počítače. Nad touto OU vytvoříme GPO, kde změníme právo na Změnu systémového času. a máme vystaráno. Nemusíme si pamatovat, kde a komu jsme to právo přidělili a jestli náhodou někdo nemá zbytečně zvýšené práva.
Jasne, tohle +/- chapu. Ale kde se tohle "GPO nad OU" uchovava? LDAP? Nejaky soubor?
Ono v nejhorsim si dokazu predstavit to, ze by se GPO musely vytvaret z nejakeho win stroje a ne primo nejakym Samba-toolem na serveru...
O tyhle oblasti ale skoro nic nevim, a tak si rad necham poradit.
Uchovává se to v LDAPu, ale problém je v tom, že správně interpretovat to dokáže jen W2k nebo W2k3 server, stanice to nezvládne. :( Stanice neumí posílat informace o GPO dalším stanicím. :(
Samba-tng to neumí také. Obávám se, že na to, aby Samba komplet nahradila AD, tak by bylo potřeba hodně dlouhého reverse-engineeringu. A pokud se nepletu, tak myslím, že toto není plánováno ani pro Sambu 4.
Nebo spis "co vsechno umi AD a jak to dela"...
Samba umí sdílení a ověřování stylu Windows NT domény. Tím její schopnosti končí. Je to na strašně dlouhé popisování. Samba prostě neumí emulovat ActiveDirectory a dle hlavních vývojářů to ani není jejím cílem.
Bohužel stále panuje přesvědčení, že Windows umí akorát sdílení z dob Win9x a za těch x let vývoje se nikam nedohrabaly.
Odpovím na tuto otázku jinou otázkou. Co umí NDS oproti Mars-NWE? Odpověď je úplně podobná jako na otázku "Co umí ADS oproti Sambě".
AD se dá porovnávat s NDS. :)
Kdybych to převedl do řeči Linuxové, tak AD je asi následující:
Je toho hodně, co umí ActiveDirectory. Bohužel se to neustále smrskává jen na porovnávání Samba s OpenLDAPem.
(tedy samozřejmě až přijdu na něco co bych takto nastavit potřeboval).
Petr
P.S. Našel jste někde rozumně popsané jak to bude s AD v Sambě 4? Já jsem z nějakého textu měl dojem, že AD je to co se v nějaké formě chystá do Samby 4, ale fakt to byl možná dojem - neuvědomuji si jak důvěryhodný byl ten zdroj. Sice AD zatím nepotřebuji, ale kdyby náhodou, tak by bylo dobré mít to v Sambě.
P.P.S. Pevně doufám, že než budu potřebovat AD, tak bude zrušení Win na desktopu přijatelné i pro velké konzervativce.
Přímo dle vývojářů Samby, co je to Samba 3:
In more recent times, and particularly with Samba 3.0, it has taken on new roles in running networks, as a ’Domain Controller’, compatible with the protocols used in NT4.
A co se týče Samby 4:
Samba version 4 is already a massive leap forward in the way Samba
is designed, and built. This thesis attempts to take that further, but examining
the protocol basis and implementation details adding support for
hosting the Kerberos network authentication system into Samba4’s partial
implementation of an Active Directory Domain controller.
Mne přechod na Win2k3 stál jedno školení a víkend v práci. Což je mnohem levnější než brigádník. :)
Já jsem nepotřeboval AD kvůli velikosti firmy (síť je o kapánek větší než ta vaše, nyní asi 150 stanic, ale rozrůstá se to o další pobočky), ale kvůli tomu, že dělám externího správce ve firmě a tato firma má ještě dalšího interního pracovníka, kterému jsem nemohl dát práva Doménového, či lokálního Admina. Tak jsem tomuto pracovníkovi zvedl práva přes GPO. (Jako je např. povolování některých instalací, práva na změny systémového času a x dalších věcí). V současné době je zde totiž nasazeno cca 15 různorodých informačních systémů a já mám za úkol udržovat síť a tyto informační systémy propojené a funkční. Ještě pobíhat kolem stanic a nastavovat každou stanici samostatně, tak se uběhám. (Bohužel vedení firmy toho s tím stavem kolem IS nechce moc měnit) :)
Největším problémem v rámci firem není to, že by byl odpor k Linuxu, ale české softwarové firmy jaksi na vývoj pod Linuxem zvysoka kašlou. Nejsou tedy k dispozici základní věci jako informační systémy a podobně. Do té doby nemohu nasadit plně Linuxové řešení.
U tohoto zákazníka, kde mám implementovaný Win2k3 jako doménu, mi také běží SLES8 se 4 instancemi Oracle jako backend pro informační systémy a tak podobně. Snažím se vybírat tu nejvhodnější technologii pro tu danou úlohu a je mi srdečně jedno, jestli danou úlohu zvládne líp Linux/Windows/BSD/Solaris/QNX či něco jiného.
Exchange se nevyužívá. Ano, je jednoduchší, ale potřebuji nějaké věci, které mi Linux a Samba zvládne se sdílením lépe. Kvóty přidělované podle uživatelů, dále vytvoření přiřazení jednotně jednoho disku uživatelům včetně klientů na Win98. A další podmínkou je minimální cena. :)
Zde je skvělý článek přímo od vývojářů Samby, v čem je rozdíl a čeho chtějí dosáhnout v Samba 4. Samba 4 a ActiveDirectory
Proč se teda u vás plánuje ten přechod? Pokud půjde udělat ten wrapper, tak by všechno mohlo chodit i bez těch Windows, nebo se pletu?Planuje se proto, ze ja jsem sice pres Linux a sit, ale ne pres rozhodovani. Kdyby bylo po mem, nekricelo by 40 lidi s pentiama 75 jak je to poamle, ale spokojene by si chroustaly s XDMCP klientem atd..... Bohuzel to neni na me. Vlastne je moznost kazdou Linuxovou stanici napojit na Win server, ale pokud napojim jeden server a dal to rozvedu pomoci NFS, NIS, XDMCP,.... bude to lepsi a hlavne to ukaze jak jsou ty wokna zbytecny. Zdenek
Proč se teda u vás plánuje ten přechod? Pokud půjde udělat ten wrapper, tak by všechno mohlo chodit i bez těch Windows, nebo se pletu?Planuje se proto, ze ja jsem sice pres Linux a sit, ale ne pres rozhodovani. Kdyby bylo po mem, nekricelo by 40 lidi s pentiama 75 jak je to poamle, ale spokojene by si chroustaly s XDMCP klientem atd..... Bohuzel to neni na me. Vlastne je moznost kazdou Linuxovou stanici napojit na Win server, ale pokud napojim jeden server a dal to rozvedu pomoci NFS, NIS, XDMCP,.... bude to lepsi a hlavne to ukaze jak jsou ty wokna zbytecny. Zdenek
Existuje více možností, jak propojit Windows Server a Linux. Winbind ze Samby je jednou z těchto možností.
Může se použít SFU (Services for UNIX), kde Windows Server dělá server pro SSO (Single SignOn) a přes Pam a sso driver se uživatelé ověřují na Linuxu. SFU zároveň s tím zvládne vytvořit NFS server a kompletní NIS doménu.
Další možností je pro pam využít ldap driver a namapovat uživatele přes LDAP bindy a dotazy. Win2k3 umí interpretovat základní LDAP dotazy.
Pravdou ovšem zůstává, že Winbind ze Samby je nejpoužívanější ze všech těchto možností.
host:~# kinit username username@DOMENA.CZ's Password: kinit: krb5_get_init_creds: Reserved krb5 error (68)A nikde nemohu najit, v cem by mohl byt problem. AD je 2003 verze... pro jistotu pridavam krb5.conf:
[libdefaults]
default_realm = DOMENA.CZ
clockskew = 300
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
DOMENA.CZ = {
kdc = 10.42.64.143
default_domain = DOMENA.CZ
admin_server = 10.42.64.143
}
[domain_realm]
.domena.cz = DOMENA.CZ
domena.cz = DOMENA.CZ
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.