⭐Microsoft Network Access Protection
Download "Microsoft Network Access Protection"
1 Microsoft Network Access Protection A technológia bemutatása A Microsoft a hálózat hozzáférés védelmi technológiáját a Windows Server 2008 kiszolgáló oldali operációs rendszerében mutatta be először. Ez a funkció a kor elvárásainak kíván megfelelni, hiszen ma már fontos igény, hogy csak ellenőrzött körülmények között kerülhessenek be számítógépek egy vállalati infrastruktúrába. A megoldás nem csak az ellenőrzés mechanizmusát tartalmazza, hanem emellett kitér a karantén vezérlés és az automatikus javítás folyamataira is. Azonban ez a platform is hordoz magában néhány korlátot, melyek alapján ez elsősorban a vállalathoz tartozó mobil munkaállomások ellenőrzésére került kifejlesztésre. Nagyon fontos azonban azt is kiemelni, hogy a Microsoft NAP technológiája az operációs rendszer és a kapcsolódó szerverszerepek alap képességeinek a része, így külön szoftvervásárlásra, ezáltal többletberuházásra nincs szükség! A technológiával kapcsolatos aktualitások az alábbi weboldalon olvashatóak: NAP főbb képességei Ahhoz, hogy a technológiát megértsük, először sorra kell venni azokat a lehetőségeket, hogy milyen módon lehet egy vállalati infrastruktúrához kapcsolódni. A Microsoft 5 kapcsolódási lehetőséget definiált, ahol a NAP képes vizsgálni a számítógépeket. Ezek a területek a következők: 1. DHCP kiszolgálótól kért IP cím és további IP opciók 2. IEEE 802.1x Vezetékes (Wired) és vezeték nélküli (Wireless) kapcsolódások 3. VPN alapú hálózati hozzáférés 4. RDP over HTTPS Terminal Server Gateway szerepkörrel felépített terminál kapcsolat 5. HRA IPSec alapú védett hálózati forgalom2 NAP egy nagyon fontos rendszereleme az előírt egészségi állapot. Ez egy általunk sablonokból összeállítható szabálycsomag, melyben előírhatjuk például különböző programok jelenlétét a kapcsolódó gépen, programok speciális paramétereit, vagy akár a frissítések naprakészen tartását. A gyártó már a technológia korai stádiumától kezdődően azon dolgozott, hogy minél több hardver és szoftver gyártóval közösen kifejlesszen előre definiált szabály csomagokat (System Health Validators), melyeket az adott gyártó oldaláról letöltve és a rendszerbe importálva könnyedén használatba vehetünk. Jelenleg több, mint 100 gyártó rendelkezik a NAP-hoz szükséges ellenőrző csomaggal (SHV), melyet a legtöbb esetben ingyenesen elérhetővé tettek. Ahhoz, hogy a kapcsolódó számítógép képes legyen fogadni az előírt egészségi állapot feltételéhez kötődő szabályokat, azokat saját magán le tudja ellenőrizni és az eredményt vissza tudja küldeni, szükséges egy kliens oldali ügynökalkalmazás. Az ügynök komponens a Vista, Windows 7, és a Windows Server 2008 operációs rendszerekben alapértelmezett, az XP kliensben az SP33 telepítésével válik elérhetővé. Korábbi, vagy más operációs rendszerek nem támogatottak, így nem létezik hozzájuk ügynök komponens. A fent felsorolt 5 kapcsolódási területből négynél működik a karantén vezérlés (az RDP over HTTPS alapú kapcsolódásánál nincs karantén logika). Bár a karantén a kapcsolódó számítógép számára a belső hálózat védett erőforrásainak elérését nem engedélyezi, de biztosítja a szintre hozatalhoz szükséges szerverszerepek és erőforrások elérését. Korlátozhatjuk, hogy egy gép maximálisan mennyi időt tölthet el a karanténban, így ha záros határidőn belül nem képes magát megjavítani, akkor megszüntethetjük vele a kapcsolatot. Mindez persze akkor igazán érdekes, ha a javítási folyamat automatikusan történik (Auto Remediation). És végül, de nem utolsó sorban, a rendszer képes folyamatosan figyelni a kapcsolódó gép egészségállapot változásait. Ez a gyakorlatban annyit jelent, ha a gép a számára előírt állapottól eltér, akkor automatizált folyamatok szerint azonnal kikerül a karantén hálózatba, ahonnan csak akkor kerülhet vissza a belső hálózatba, ha maximálisan teljesíti az előírt feltételeket. NAP architektúra felépítése A rendszer három fő kategóriára osztható: Áll egyrészt a kapcsolódó számítógépből, a rajta futó Network Access Protection Agent (napagent) szolgáltatásból, illetve az ehhez tartozó Enforcement Client komponensekből. Másrész a kliensek kapcsolódását fogadó komponensekből (5 különböző kapcsolódási terület). Harmadrészt pedig a háttér infrastruktúrából, ahol előírjuk az egészségi állapotot, azt publikáljuk az Active Directory-ba, és szükség esetén megjavíthatjuk a nem megfelelő szinten lévő számítógépet.4 A kapcsolódó géppel szembeni elvárások Fontos tudnunk, hogy nem minden operációs rendszer verzió támogatott a NAP-ban! Ez a megoldás nem kezeli az a helyzetet, ha egy gépen nincs ügynök, illetve ha az nem került megfelelő bekonfigurálásra. Ez mindenképpen erősen lekorlátozza a lehetőségeinket. Az állítás első részével nem sokat kezdhetünk, meg kell oldanunk, hogy legyen napagent a gépen! Ha valaki Vista, vagy Windows 7 kliens operációs rendszerrel dolgozik, akkor nem lesz ezzel külön teendője, XP esetében azonban csak a Service Pack 3 csomag telepítésével kerül be ez a funkció. Szerver oldalon még korlátozottabbak a lehetőségek, mivel csak a Windows Server 2008 része az említett ügynök. A 2003 szerverekhez a Microsoft nem tervezi az ügynök kiadását. De hiába van fent az ügynök, mivel az alapértelmezett beállítás szerint az nem fut. Ennek viszonylag egyszerű az oka: a Secure by Default szemlélet szerint minden felesleges szolgáltatást ki kell kapcsolni. És mivel egyáltalán nem biztos, hogy be akarja mindenki alapértelmezettként vezetni a NAP-ot, ezért inkább kikapcsolták ezt a szolgáltatást. Ha azonban nem fut a szolgáltatás, akkor nem lesz semmilyen egészségállapot vizsgálat, így az ilyen gépek valószínűleg még a karanténba sem fognak bekerülni, a rendszer nem fog velük szóba állni. Bár ez az állítás csak akkor igaz, ha ilyen szabályokat készítünk, de nagy valószínűséggel így fogunk eljárni.5 És ha esetleg fut is a szolgáltatás, az sem fog sokat számítani abban az esetben, ha nem konfiguráltuk megfelelően a részterületi ügynököket (Enforcement Client). De mivel alapértelmezettként az előbb említett szolgáltatás sem fut, így az EC-k sincsenek engedélyezve. Ahhoz, hogy az egészségállapot ellenőrzés folyamata rendkívül gyors legyen, minden ügynök a saját cache-ében tartja a gép aktuális állapotát, amit a kapcsolódáskor azonnal el is tud küldeni az ellenőrzést végző NPS kiszolgáló felé. Minden kapcsolódási területnek megvan a maga részterületi ügynöke, hiszen más-más formátumban kell küldeni az egészségi állapotot, illetve a karantén vezérlés logikája is máshogy működik. Itt csupán annyi a teendőnk, hogy bekapcsoljuk azt az EC komponenst, amelyen keresztül a kliensünk képes lesz kommunikálni az ellenőrzést végző szerverszereppel. Tehát, ha DHCP kiszolgálón keresztül kér a kliens IP címet, akkor a DHCP Quarantine Enforcement Client komponensre lesz szükségünk. Természetesen Active Directoryval felügyelt rendszer esetében lehetőség van ezen beállítások házirenden keresztüli szabályozására is. Akár testreszabott üzenetek formájában tájékoztathatjuk a felhasználókat arról, hogy mit kell tenniük abban az esetben, ha az ellenőrzés szerint nem megfelelő a számítógépük. Ez főleg akkor igazán hasznos, ha egy külsős felhasználó gépét kellene az előírt egészségi szintre hozni, de itt nem alkalmazható az automatikus javítás folyamata.6 Talán a NAP platform legfőbb korlátját éppen az jelenti, hogy a külsősök gépére nem fog érvényre jutni az a házirend, ami bekapcsolná az említett komponenseket, és mivel a rendszernek nincs joga az automatikus javításhoz sem, ezért a felhasználó képességein múlik az, hogy megtud-e birkózni a különböző beállításokkal. Az is gondot okoz, ha a külsős felhasználó nem rendelkezik adminisztrációs jogokkal a gépén, mivel ebben az esetben nem állíthat szolgáltatásokat, nem telepíthet programokat. De ha esetleg ezek a jogosultságok adottak is, akkor hamar egy másik problémával találjuk szemben magunkat: előírtuk a Forefront Client Security programot, illetve annak definíciós frissítéseinek naprakészen tartását, de a kapcsolódó gépen nincs telepítve az alkalmazás. Ha ez egy vállalati számítógép, akkor egy központi szoftvertelepítési módszer alkalmazásával (pl.: SCCM) könnyedén orvosolhatjuk ezt a problémát. De mi a helyzet egy külsős gép esetén? Arra nem akarjuk feltelepíteni a vállalati alkalmazásainkat, hiszen ez licencelési problémákhoz vezetne. Így viszont nem tud kapcsolódni az ilyen számítógép a védett rendszerhez. És ezzel el is érkeztünk a termék legfontosabb bevezetési korlátjához! Mivel ez a technológia nem képes kivételek kezelésére (de ennek nem is lenne túl sok értelme), ezért ha megfogalmazzuk az előírt egészségi állapot feltételrendszerét, illetve megadjuk, hogy mi legyen azokkal a gépekkel, melyek ezt nem teljesítik, akkor az minden a rendszerhez kapcsolódó gépre egységesen vonatkozni fog. A bevezetés előfeltételeként szükséges egy olyan felsővezetői szabályozás, hogy a külsős gépek nem érhetnek el védett, belső erőforrásokat. Tehát ki kell alakítani egy olyan hálózatot, ahol a külsős gépről csak például Internet hozzáférést biztosítunk. A fogadó komponensek A kliensek kapcsolódását fogadó komponensek nem közvetlenül döntenek arról, hogy a hozzáférést kérő gép állapota megfelelő-e vagy sem, ezt az információt az NPS kiszolgáló adja meg számukra. A fogadó komponensekkel kapcsolatos általános elvárás az, hogy mielőtt befogadnának egy hozzáférési kérést, továbbítsák a kliens egészségi állapotát az ellenőrzést végző NPS felé, aki azt visszaigazolva megmondja az adott kiszolgálónak, hogyan járjon el a kapcsolódó géppel szemben. Az NPS három féle választ adhat: a kapcsolódó gépet fogadd be, helyezd őt a belső, védett hálózatba,7 a kapcsolódó gép nem teljesítette az előírt egészségi állapotot, ezért helyezd őt a karanténba, a kapcsolódó gép nem teljesítette az előírt egészségi állapotot, ezért utasítsd vissza a hozzáférési kérését. Nézzük ezeket a komponenseket részletesebben: DHCP szerver A dhcp alapú kapcsolódáskor a kliens IP címet és további IP opciókat kér a DHCP kiszolgálótól. A Windows Server 2008 (és csak ez a verzió) felkészített a NAP technológia támogatására, így képes eltérő IP opciókat adni a nem megfelelő gépeknek. Ehhez szükség van a standard IP opciók mellé alternatív paramétereket is definiálni Scope, vagy akár szerver szinten. Természetesen a kliensnek átadott IP cím nem változik a karanténból a belső hálózatba való bekerüléskor, vagy akár fordítva, mivel ez szakadást okozna a folyamatos kommunikációban, viszont a háttérben egy IPconfig /renew parancsnak megfelelő IP opciók megújításával járó folyamat zajlik le. Ennek eredményeképpen a kliens az állapotának megfelelő User Classhoz definiált opciókat fogja megkapni. Bár látszólag bármilyen IP opciót definiálhatunk a NAP Classhoz is, de valójában korlátozott, hogy mit fog ténylegesen megkapni a kapcsolódó gép, például átadhatjuk a DNS szerver címét (006- os opció), vagy a DNS tartományi utótagot (015-ös paraméter), de az átjáró címét (003-as opció) nem fogja megkapni, ha nem teljesíti az előírt feltételeket. Tehát itt a karantén vezérlés az alternatív IP opciók kiadásával került megoldásra, ami csak akkor lesz igazán hasznos, ha a kliensek által elérhető hálózatot és a szerverinfrastruktúra hálózatát fizikailag is kettéválasztjuk egymástól. Ezzel el tudjuk rejteni a felhasználók elől a belső hálózatban használt névteret, a névfeloldásért felelős kiszolgálókat és egyéb fontosabb információkat. IEEE 802.1x Ebben a komponensben található a vezetékes és vezeték nélküli hálózati kapcsolódást fogadó eszközök halmaza. Ezeknek az eszközöknek képesnek kell lenniük a kliensektől érkező egészségi8 állapotot befogadni, és azt továbbítani az NPS kiszolgáló felé. Az NPS válaszának függvényében a kapcsolódó gépet vagy a rendes VLAN hálózatba, vagy egy izolált VLAN-ba kell helyezniük. Ez utóbbi a karantén vezérlés logikája. A kapcsolódó gép és az aktív eszköz között EAP (Extensible Authentication Protocol) vagy PEAP (Protected Extensible Authentication Protocol) alapú kommunikáció zajlik le. Ebből kiderül, hogy az eszközzel szemben is van elvárás: támogatnia kell a NAP technológiát. A Microsoft éppen emiatt kötött egy megállapodást a Ciscoval, hogy legalább egy gyártó legyen, aki az eszközeit felkészíti a NAP-pal való együttműködésre. Persze sok más hardvergyártó is elkészítette az eszközeihez az újabb firmware-t, hogy versenyben maradjanak. Javasolt úgy konfigurálni az eszközt, hogy az izolált VLAN-ban legyen olyan szerverszerep, melyen keresztül a kliens képes magát megjavítani. VPN A VPN karantén vezérlés logikája nem új elem a Microsoft védelmi megoldásaiban, hiszen ennek az első verziója a Windows Server 2003 Routing and Remote Access szerverszerepben megtalálható volt. A működési folyamat gerince nem változott, viszont számos új képességgel bővült a kínálat. Ahhoz, hogy lássuk az új verzió előnyeit, meg kell ismernünk a korábbi megoldás képességeit. Az előző verzióban nekünk kellett mindenféle ügyes ellenőrző scriptet és exe-t fejlesztetnünk, amiben leírtuk, hogy mit akarunk ellenőrizni. Bár a Microsoft készített ehhez néhány minta scriptet, de a valóságban igen komoly kihívást jelentett ilyen ellenőrző csomagokat készíteni. Az ellenőrzést végző scriptet közvetlenül a VPN kapcsolat felépítése után kellett lefuttatni, és záros határidőn belül (pl.: 1 perc) elküldeni a VPN gatewaynek. Ha ez nem történt meg, akkor a VPN Gateway a megadott idő elteltével bontotta a kapcsolatot a géppel. További probléma volt, ha a gép nem teljesítette az előírt feltételeket, mivel ilyenkor a felhasználónak kellett megjavítania a gépét. És végül a gép ellenőrzése csak a kapcsolat felépítésekor történt meg. Miután a gépet beengedtük a VPN hálózatba és a felhasználó úgy döntött, hogy kikapcsolja a gépén lévő tűzfalat, akkor már semmi nem vizsgálta a gépet, hogy még mindig teljesíti-e az előírt állapotot. Sajnos ezzel előállhatott az a helyzet, hogy egyik interfészével védtelenül és közvetlenül kint lógott az Interneten, míg a létrejött PPP adapterével pedig a belső hálózaton figyelt a gép.9 A NAP-ban lévő VPN támogatás a fent leírt összes problémára megoldást ad. Könnyedén előírhatjuk az egészségi állapotot, amit a kapcsolódó kliensen lévő ügynök folyamatosan figyel. Ha tartományi gép kapcsolódik, akkor az automatikus javítás sem lehet probléma, és a kapcsolódás ideje alatt folyamatosan ellenőrzés alatt marad a kliens. A Windows 7-el és a Windows Server 2008 R2-vel megjelenő DirectAccess alapú hálózati elérés esetén is folyamatosan ellenőrzés alatt marad a kapcsolódó munkaállomás. RDP over HTTPS A terminál alapú kapcsolódás egy új megoldása a Windows Server 2008-ban megjelenő Terminal Server Gatewayen keresztül folytatott RDP over HTTPS kommunikáció. A megoldás lényege, hogy a felhasználó képes Interneten keresztül HTTPS-be ágyazott RDP protokollon keresztül elérni a vállalati szervereket. Ezzel a megközelítéssel a felhasználó ugyanazon a teljes értékű felületen dolgozhat vállalaton belül, mint bárhol máshol, hiszen a jól megszokott terminál kiszolgáló felületét éri el bárhonnan. A megoldás tovább kombinálható a szintén Windows Server 2008-al megjelenő RemoteApp alapú alkalmazások használatával is. Ilyenkor a felhasználó a terminál kiszolgálóra telepített alkalmazás paraméterezett RDP kapcsolati ikonját kapja meg a saját gépének asztalára, de amikor elindítja az alkalmazást, akkor a rendszer detektálja, hogy a vállalati hálózaton belül vagy kívül tartózkodik a számítógép. Ennek függvényében próbálkozik közvetlenül az RDP vagy a HTTPS-be ágyazott RDP hívással. Ahhoz, hogy ez a technológia használható legyen a kliens oldallal kapcsolatosan is van elvárás, mégpedig az RDP 6.1-es kliens program. A NAP ebben az egy kapcsolódási területben nem képes karantén vezérlésre. Tehát megvizsgálhatjuk a kapcsolódó gép egészségi állapotát, azonban ha az nem teljesíti az előírt feltételeket, akkor itt nem létesül karantén hálózat, ahonnan képes megjavítani magát a gép. Ez persze érthető, ha megvizsgáljuk a TSGateway architekturális felépítését.10 HRA IPSec védett hálózati kommunikáció Talán a legbiztosabb védelmet ez a megoldás képes nyújtani a nem megfelelően konfigurált gépekkel szemben. A megfelelő rendszer felépítéséhez alkalmaznunk kell a domain izoláció fogalmát, melynek lényege, hogy a belső hálózatban futó szenzitív információkat tartalmazó kiszolgálónkhoz IPSec alapú szabályokat hozunk létre. Az IPSec alkalmazásával nem csupán a hálózati forgalom titkosítását és az adatintegritás védelmet nyerjük, de egyúttal azt is szabályozhatjuk, hogy csak azok a kliensek legyenek képesek kommunikálni a kiszolgálói rendszerrel, akik teljesítik az előírt egészségállapot feltételrendszert. Az IPSec alapú kommunikációs csatorna kiépítésének első lépése a két fél kölcsönös hitelesítése. A hagyományos IPSec esetében a hitelesítéshez alkalmazható a megosztott titok (preshared key), a Kerberos alapú jegyrendszer és a megbízható, CA által kibocsátott tanúsítvány. A NAP esetében viszont kicsit tekertek a fejlesztők az alap logikán. Itt mindkét félnek egy speciális OID (Object Identifier) mezővel ellátott tanúsítvány sablonból kiállított tanúsítványra van szüksége, amit nem igényelhetnek közvetlenül. Ilyen tanúsítványt a Health Registration Authority (HRA) Windows Server 2008-as szerepkört ellátó kiszolgáló állít ki az előírt egészségi állapotot teljesítő gépek számára. Ha egy gép nem teljesíti az előírt feltételeket, akkor nem kaphat ilyen tanúsítványt, ha pedig korábban teljesítette azt, de valamilyen oknál fogva menet közben attól elért, akkor a korábban kibocsátott tanúsítványt a kliensen futó nap ügynök eldobja, ezzel megszakad a védett kiszolgálóval felépített IPSec csatorna.11 A háttér infrastruktúra komponensek A háttérben lévő szerverszerepek és szolgáltatások működése rendkívül fontos, hiszen ezek nélkül nincs egészségállapot ellenőrzés, sem javítás. A rendszer lelke, mint sok más alkalmazásnál, itt is az Active Directory. Ide publikálódik az előírt egészségi állapot információ. Az egészségi állapot előírásokat SHV ellenőrző csomagok formájában telepíthetjük az NPS (Network Policy Server) kiszolgáló alá, ami a Windows Server 2003-ban lévő IAS (Internet Authentication Server) utódja. Az NPS kiszolgáló tartalmaz egy Connection Policy, és egy Network Policy ágat. Ezekben a konténerekben kell szabályokká formálnunk azt, hogy mely gépek kapcsolódhatnak a rendszerünkhöz, és azt milyen feltételek mellett tehetik meg. Rendkívül sok paramétert lehet definiálni kapcsolódási feltételként, beleértve azt is, hogy mit csináljon a rendszer akkor, ha egy egészséges gép érkezik, illetve ha egy nem megfelelő gép küld kapcsolódási kérést. Ha a cégnek több belépési pontja van (például egy több telephelyes rendszer esetében), vagy ha redundánssá szeretnénk tenni az NPS infrastruktúránkat, akkor érdemes lehet egy központi NPS kiszolgálót üzembe állítani, melyen megfogalmazzuk az említett szabályrendszert. Ezt gyakran Central Policy Storage kiszolgálónak is nevezik. Az NPS kiszolgálók között, illetve a fogadó komponensek és az NPS kiszolgáló között egyaránt RADIUS kommunikáció zajlik. Az architektúrában ki kell neveznünk az12 egészségi állapotot küldő kiszolgálót RADIUS kliensnek, míg az NPS szervert (vagy a központi NPS szervert) pedig RADIUS szerverként szükséges konfigurálnunk. Összefoglalás Ez is egy olyan újítás a Windows Server 2008-ra épülő infrastruktúrában, ami miatt érdemes lehet átállni a Windows 2003-as rendszerről. A NAP bevezetése előtt mérlegelnünk kell, hogy valóban szükséges-e ez a fajta kontroll a vállalati gépek felett, mivel nincs kivételkezelés. Fontos a management egyértelmű és folyamatos támogatása, mivel ennek hiányában kudarcra van ítélve a projekt. Tartsuk szem előtt tartani azokat a korlátokat, melyek az operációsrendszerre, a fogadó komponensekre és a vállalaton kívüli gépekre vonatkoznak. Dolgozzunk ki automatizmusokat arra az esetre, ha egy vállalati gép ellenőrzésekor nem megfelelő egészségi állapot eredmény születik. Erre jó megoldás lehet a System Center Confguration Manager szoftvertelepítési és konfiguráció beállítási képessége. Persze ennek előfeltétele, hogy bevezessük az SCCM-et, és a kapcsolódó gépen legyen megfelelően konfigurált SCCM ügynök. A külső gyártók által elkészített ellenőrző csomagok (SHV-k) sokat segítenek abban, hogy megfelelően testre szabhassuk az egészségi állapot feltételrendszerét. És végül egy gondolat: használhatjuk akár mind az 5 kapcsolódási terület esetén a NAP platformot, de a felesleges átfedéseket kerüljük, pl.: IEEE 802.1x beállítása a switchen, majd ugyanazon a hálózaton DHCP ellenőrzés együttes használata teljesen felesleges, és ráadásul igen komoly fennforgásokat is okozhat. Hasonló dokumentumok
DEBRECENI EGYETEM INFORMATIKAI KAR WINDOWS SZERVER 2008 ÚJDONSÁGAI ÉS HÁLÓZATI MEGOLDÁSAI Diplomamunka Konzulens: Dr. Krausz Tamás Egyetemi adjunktus Készítette: Pálóczi Árpád Programtervező matematikus Részletesebben Modern vállalati informatika
Modern vállalati informatika 2012 Microsoft Corporation. Minden jog fenntartva. A jelen dokumentum kizárólag tájékoztatásul szolgál. A MICROSOFT NEM VÁLLAL SEMMIFÉLE KIFEJEZETT VAGY KÖVETKEZMÉNYES GARANCIÁT Részletesebben A Windows 7 hálózati újításai
Debreceni Egyetem Informatika Kar A Windows 7 hálózati újításai Témavezető: dr. Krausz Tamás Egyetemi adjunktus Készítette: Berna Tibor Mérnök Informatikus Debrecen 2010 Tartalomjegyzék I. Bevezető... Részletesebben Szakdolgozat. Bundik Sándor
Szakdolgozat Bundik Sándor Debrecen 2009 Debreceni Egyetem Informatikai Kar A Windows Server 2008 újdonságai Témavezetı: Dr. Krausz Tamás Egyetemi adjunktus Készítette: Bundik Sándor Programtervezı informatikus Részletesebben Hálózati operációs rendszerek. Kerecsendi András
Hálózati operációs rendszerek Kerecsendi András MÉDIAINFORMATIKAI KIADVÁNYOK Hálózati operációs rendszerek Kerecsendi András Eger, 2013 Korszerű információtechnológiai szakok magyarországi adaptációja Részletesebben Debreceni Egyetem Informatikai Kar A WINDOWS SERVER 2003 HÁLÓZATI MEGOLDÁSAI
Debreceni Egyetem Informatikai Kar A WINDOWS SERVER 2003 HÁLÓZATI MEGOLDÁSAI Témavezető: Dr. Krausz Tamás Számítástechnikai munkatárs Készítette: Lakatos Csaba Programozó matematikus Debrecen 2006 Tartalomjegyzék Részletesebben Publikus felhő szolgáltatások igény szerint. Systemfarmer Kft. 2014.10.01
Publikus felhő szolgáltatások igény szerint Systemfarmer Kft. 2014.10.01 Bevezetés A Microsoft szerverek százezreit üzemelteti saját adatközpontjaiban, és ezek elérhető kapacitását bocsátja ügyfelei és Részletesebben Hivatalos Jogszabálytár Prémium telepítési segédlet
Hivatalos Jogszabálytár Prémium telepítési segédlet Intézmények részére Jelen dokumentációt főként azon intézményeknek készítettük, ahol szolgáltatásunk korlátlan számú felhasználói változata kerül telepítésre. Részletesebben Informatikai technológiák laboratórium II.
Informatikai technológiák laboratórium II. Mérési útmutató Írták: Huszerl Gábor Paljak Gergely Pásztor Péter László Tóth Dániel Verzió: 4 2011. augusztus Budapesti Műszaki és Gazdaságtudományi Egyetem Részletesebben WINDOWS SERVER 2003 END OF SUPPORT
WINDOWS SERVER 2003 END OF SUPPORT Rövid útmutató az áttéréshez Gál Tamás Datacenter Technical Specialist Microsoft Magyarország v-tgal@microsoft.com Tartalom Bevezetés... 3 Támogatással és nélküle... Részletesebben Virtualizáció Linux kiszolgálón
Debreceni Egyetem Informatika kar Virtualizáció Linux kiszolgálón Témavezető: Dr. Krausz Tamás Egyetemi Adjunktus Készítette: Vasvári Zoltán Mérnök Informatikus Debrecen 2008 A munka oroszlánrészét akkor Részletesebben Szabadon választott hálózati J2ME/MIDP alkalmazás fejlesztése
Szabadon választott hálózati J2ME/MIDP alkalmazás fejlesztése Készítette: Novák György Témavezető: Bátfai Norbert Debreceni Egyetem Informatikai Intézet Debrecen 2004. Tartalomjegyzék 1. Bevezető...3 2. Részletesebben Váltani könnyű! Útmutató a Windows XP és az Office 2003 utáni váltáshoz
Váltani könnyű! Útmutató a Windows XP és az Office 2003 utáni váltáshoz Vezetőknek, döntéshozóknak 2014. április 8. 3 Mit jelent a Windows XP és az Office 2003 támogatásának megszűnése? 4 Mi lesz az eszközeinkkel? Részletesebben Készült a Microsoft Magyarország Kft megbízásából. A könyv nyomtatott verziója megvásárolható a http://joskiado.hu címen lévő webáruházban.
Készült a Microsoft Magyarország Kft megbízásából A könyv nyomtatott verziója megvásárolható a http://joskiado.hu címen lévő webáruházban. Gál Tamás Windows Server 2008 R2 A kihívás állandó Jedlik Oktatási Részletesebben A TÁVOLI MUNKAVÉGZÉS BIZTONSÁGI KÉRDÉSEI, MEGOLDÁSI LEHETŐSEK WINDOWS SZERVEREK ESETÉN BEVEZETÉS
Póserné Oláh Valéria Budapesti Műszaki Főiskola NIK, poserne.valeria@nik.bmf.hu A TÁVOLI MUNKAVÉGZÉS BIZTONSÁGI KÉRDÉSEI, MEGOLDÁSI LEHETŐSEK WINDOWS SZERVEREK ESETÉN Absztrakt A szervezetek hatékony működtetéséhez Részletesebben Tartalomjegyzék. Hálózati beállítások...24
Tartalomjegyzék A készülék tulajdonságai... 4 A csomag tartalma... 4 Rendszer követelmények... 4 Bevezetés... 5 Tulajdonságok... 5 Hardware tulajdonságok... 7 Elülső oldal... 7 Hátulsó oldal... 8 Technológiák Részletesebben KözHáló Önkormányzati Biztonsági Központ. Felhasználói leírás. 1.0 verzió. Budapest, 2009. devember 28. A dokumentumot késztette a NETvisor Zrt.
KözHáló Önkormányzati Biztonsági Központ Felhasználói leírás 1.0 verzió Budapest, 2009. devember 28. A dokumentumot késztette a Copyright Jelen dokumentumhoz fűződő valamennyi jog a tulajdonát képezi. Részletesebben A DHCP rejtett szépségei I.
A DHCP rejtett szépségei I. Szinte minden TCP/IP hálózat rendelkezik DHCP szolgáltatással. Ez az alkalmazás háttérbe húzódik, a felhasználók sohasem találkoznak vele, és ha jól működik, a rendszergazdák Részletesebben Vezeték nélküli technológiák. 4.előadás
Vezeték nélküli technológiák 4.előadás A WLAN hálózatok előnyei - gyors telepítés WLAN hálózatok - (részben) kábelmentes környezet - mobilitás vezetékes hálózati szolgáltatások tűrhető sebesség (újabb Részletesebben TÜZETES ELLENÔRZÉSEK Közvetlen védelem az internetes kellemetlenségek és fenyegetések ellen
2006. DECEMBER 2007. JANUÁR TÜZETES ELLENÔRZÉSEK Közvetlen védelem az internetes kellemetlenségek és fenyegetések ellen POWERSHELL- SCRIPTEK A GYAKORLATBAN Az objektumok feldolgozásának kilenc fontos parancsa Részletesebben Pannon Egyetem, Veszprém. Műszaki Informatikai Kar Matematika Tanszék
Pannon Egyetem, Veszprém Műszaki Informatikai Kar Matematika Tanszék Tanári mesterképzési szak Informatikatanári szakképzettségi terület Windows 7 iskolai alkalmazása Kiss Sándor Témavezető: Lipovits Ágnes Részletesebben A Windows Server 2008 felügyeletének áttekintése
E LSŐ FEJEZET A Windows Server 2008 felügyeletének áttekintése A fejezet tartalma: A Windows Server 2008 és a Windows Vista... 4 Bemutatkozik a Windows Server 2008... 6 Hálózati eszközök és protokollok... Részletesebben 2008. MÁJUS JÚNIUS. System Center
2008. MÁJUS JÚNIUS System Center IAG 2007 Távoli elérés egy igazi nagyvaddal, SSL VPN alapon SQL SERVER 2008: ADATTÁRHÁZ- ÚJDONSÁGOK Hatalmas mennyiségû adatokkal operáló adattárházakat tölthetünk fel Részletesebben DIPLOMAMUNKA. Soltész Dániel. Debrecen
DIPLOMAMUNKA Soltész Dániel Debrecen 2010 DEBRECENI EGYETEM INFORMATIKA KAR INFORMÁCIÓ TECHNOLÓGIA TANSZÉK Virtualizációs technológiák összehasonlítása Témavezető: Dr. Krausz Tamás Egyetemi adjunktus Készítette: Részletesebben Microsoft: System Center Essetials 2007
Microsoft: System Center Essetials 2007 Készítette: Szirtes István szakmai igazgató MCT,MCSE+S+M, MCTS,MCITP A mai program A rendszerfelügyelet aktuális kérdései Hol tart ma a technológia? System Center Részletesebben Esettanulmány. Pénzintézet 14 telephelyének összekötése IKEv2 IPSec VPN-nel, redundáns központtal 1.1 verzió 2012.11.10.
Esettanulmány Pénzintézet 14 telephelyének összekötése IKEv2 IPSec VPN-nel, redundáns központtal 1.1 verzió 2012.11.10. Készítette Tel.: 23/889-107 Fax: 23/889-108 E-mail: telvice@telvice.hu Web: http://www.telvice.hu/ Részletesebben Mintacím szerkesztése
Szirtes István Szakmai igazgató (MCT, MCSE+S+M, MCTS, MCITP) SZIRTES TECHNOLOGIES Kft. www.szirtes.com 2009.03.31. 1 Hol tart ma a technológia Mintacím szerkesztése A Forefront termékek licenc konstrukciói Részletesebben U.S. Robotics 802.11g 54Mbps Router
U.S. Robotics 802.11g 54Mbps Router FELHASZNÁLÓI ÚTMUTATÓ rev 1.0 9-04 R24.0778.00 Védjegyek: A többi termék és cégnév az adott nevek tulajdonosainak bejegyzett védjegyei. TARTALOMJEGYZÉK A 802,11g 54Mbps Részletesebben MUNKAANYAG. Horváth Imre. Számítógép hálózatok kiépítése - Kommunikációs protokollok. A követelménymodul megnevezése: Számítógép összeszerelése
Horváth Imre Számítógép hálózatok kiépítése - Kommunikációs protokollok A követelménymodul megnevezése: Számítógép összeszerelése A követelménymodul száma: 1173-06 A tartalomelem azonosító száma és célcsoportja: Részletesebben 2016 © DocPlayer.hu Adatvédelmi irányelvek | Szolgáltatási feltételek | Visszajelzés