Windows 9x >< Windows 2000 tartomány
Mivel a Windows 2000 családban szintén van kliens és szerver változat is, ezért nyilvánvalóan ezek úgy készültek, hogy együtt legyenek a leghatékonyabbak, és persze elsősorban egy tartományban. Persze ez nem azt jelenti, hogy az újabb IHOR-ral (lásd előző rész), azaz a 2001-ben kijött Windows XP Professional változatával nem lenne legalabb ilyen jó kapcsolata a Windows 2000 Servernek, hanem inkább azt, hogy a korábbi klienseket (NT4 és Windows 9x) is lehetséges azért illeszteni egy Windows 2000 tartományhoz, azonban csak bizonyos kompromisszumokkal és némi utókezeléssel.
Az első probléma a Windows 2000 névfeloldásának gyökeres átalakítása miatt jöhet elő, ugyanis egy Windows 2000 tartományban a NetBIOS alapú névfeloldás helyett immár a helyi hálózatban (is) egy vagy több DNS szerver intézi ezt a feladatot. Ez gyakorlatilag azt jelenti, hogy egy tisztán Windows 2000/XP kliensekkel rendelkező hálózatban nincs is szükség a max. 15 karakteres NetBIOS nevekre, a NetBIOS over TCP/IP szolgáltatásra az lmhosts állományokra és pl. a WINS szerverre (Windows Internet Name Service = a NetBIOS nevek és IP címek összerendelését végzi automatikusan) sem, hiszen a DNS mindent lekezel. A helyzet tényleg az, hogy működő Windows 2000 alapú tartományt nem is lehet legalább egy - kifejezetten csak a belső hálózatunkban működő - DNS szerver nélkül üzemeltetni, viszont az üzemeltetést egyszerűvé és automatikussá tevő DDNS szolgáltatást (dinamikus DNS, azaz a kliensek maguk jegyzik be az meg az IP címüket és nevüket a zónába, valamint szükség esetén meg is változtatják ezeket, gondoljunk bele, nem nekünk kell kézzel konfigurálni mondjuk 100 nevet/címet, hanem ez a folyamat automatikus) a Windows 9x-ek és az NT-k nem ismerik, erre a feladatra nem képesek. Szerencsére van itt is megoldás, mégpedig a DHCP Server! Ez ugyanis képes arra, hogy miután kiosztotta a kliensnek a TCP/IP konfigurációt, bejegyezze/törölje/átírja a kliens aktuális adatat a DNS zónába. Persze nem ez az alapbeállítás, hanem az alábbi panelen vadul pipálgatnunk kell, hogy ez a folyamat megtörténhessen.
DDNS kivitelezése DHCP szerverrel
A másik megoldás egy vegyes környezetben az az, hogy továbbra is alkalmazzuk a WINS szervert. A WINS egyebként is egy kedvenc rendszergazdai "jószág", ugyanis egyszerű, alig "fogyaszt" valamit az erőforrásokból és amennyiben nem több ezer kliensgépünk van, nem is kell vele a telepítés után abszolút foglalkozni. Ezek ellenére mégis komoly hasznot hajt, mert segítségével a Windows 9x-ek és az NT-k is gyorsan megtalálják egymást és a Windows 2000/XP gépeket is, ráadásul minimális hálózati plusz forgalom generálása mellett. Természetesen azt, hogy van a hálózatban WINS szerver, valahogy tudatnunk kell a kliensekkel (és a szerverekkel is!), ezt vagy manuális bejegyzéssel vagy pl. a DHCP segítségével közölnünk kell a hálózatban működő gépekkel.
A következő probléma alapja egy - sajnos alaposan elterjedt - félreértés lehet. A helyzet az, hogy a Windows 2000 tartományoknak kétféle üzemmódja van: mixed (kevert) és natív. Az első az alapértelmezés akár egy új telepítést akár egy frissítést végzünk el. Kevert üzemmódban még lehetőségünk van mazochista módon pl. NT4 BDC-ket csatlakoztatni a tartományhoz, a natív mód viszont kizárta ezt a lehetőséget, hozott viszont egy-két plusz opciót, pl. az univerzális csoportokat, a csoportok típusainak megváltoztatását és egymásba ágyazhatóságát, a RAS házirendeket és pl. a méretezési problémákkal sem lehet több gondunk :D, ti. kevert módban az NT4-hez hasonlóan maximum 40.000 objektumot (azaz fiókokat, megosztásokat, csoportokat, szervezeti egységeket, stb.) tartalmazhat "csak" a címtár. A félreértés abból adódik, hogy sokan (pl. a levelezőlistákon) azt sugallták, hogy a natív módra való áttéréskor a kapcsolat a régebbi operációs rendszerekkel megszűnik illetve csak az előző cikkben említett dsclient.exe használatával tartható meg. De ez nem igaz, kliensoldalon semmilyen változást nem okoz a tartomány üzemmódjának megváltoztatása.
A Csoportházirenddel (amelyet Windows 2000 környezetben már valóban így hívunk, ellentétben az előző cikkben említettekkel, amikor is az NT4-es Rendszerházirend helyett szintén Csoportházirendet írtam, és amire egy Kedves Olvasó fel is hivta a figyelmemet, igaza is van, mentségemre szolgáljon, hogy hálistennek már hosszú évek óta nem láttam NT4-et :D) kapcsolatos probléma ugyanaz, mint amelyről már szó esett, sőt a probléma megoldása is teljesen ugyanaz, gyakorlatilag gondunk csak a config.pol (vagy NT esetén ntconfig.pol) elhelyezésére is szolgáló NETLOGON megosztás más mappába helyezése miatt van, ugyanis az Active Directory alkalmazása miatt az összes, a replikációban érintett mappa és állomány egy helyen, a SYSVOL mappában található, így az említett NETLOGON mappa is. De ezt a problémat könnyedén megoldhatjuk a "net share" parancs begépelésével egy parancssori ablakba, ez ugyanis pontosan el fogja árulni, hová került egy Windows 2000 Serveren ez a megosztás.Egy másik területen is korrekcióra szorul a Windows 9x (igaz az NT4-ek is, de azok legalább az SP4-gyel "megjavulnak"), mert alapból a hálózati bejelentkezéssel gondok vannak, ugyanis csak egy olyan titkositás nélküli kódolást használ az autentikációs eljárás (NTLM = NT Lan Manager), amely a hálózati forgalom "sniffelése" esetén másodperceken belül dekódolható megfelelő eszközökkel. Ez azt jelenti, hogyha a rendszergazda belép egy Windows 9x-en és ekkor valaki el tudja kapni a hálózati forgalom idevágó részét, akkor pl. a jelszavunk nem lesz titok többé előtte. Van persze megoldás erre a problémára is, úgy hívják, hogy NTLMv2. Kicsit fárasztó beállítani, de ha a körülmények indokolják, érdemes, mert ehhez passzoló törőprogram elvileg még nem született (vagy legalábbis nem ismert).
Terjedelmi okokból az NTLMv2 alkalmazásáról ebben a cikkben nem esik szó, viszont az alkalmazás részletes leírását és a probléma körbejárását megtaláljuk az alábbi dokumentumban:
http://www.netacademia.net/secu/cikk/doc/0011secu.doc
A szükséges házirend sablonállományokat pedig a Sulinet FTP szerveréről törlthetjük le:
ftp://ftp.sulinet.hu/Windows/opsys/win9x/ntlmv2_ADM.zip
A következő (befejező) részben a Windows Server 2003 és a Windows 9x-ek kapcsolatáról lesz szó.
Gál Tamás
gtamas@tjszki.hu
