Szervusztok! Először is azzal kezdeném, hogy Fehér Sanyinak adósa vagyok egy válasszal a már jócskán több mint 2 hete írt privát levelére, amit ezúton megköszönök, ha késve is, és ezt az eszmefuttatást inkább a levlistára küldöm. Szerettem volna valami érdemi előrelépést felmutatni az érintett témában (a "topológia" topic, DirectAccess, DeviceTunnel, Always on VPN és társai), de nagyon szűkös eredményre jutottam. Közbe jött a 30 db tablet beüzemelése is, így kevés időt tudtam szánni a kísérletezgetésre. Végső tanácstalanságomban még a KIFÜnél is égettem magam, mert írtam nekik egy segélykérő levelet, a választ persze ők sem kapkodják el...
Hogy a legelejéről érthető legyen: szerettem volna (ill. továbbra is szeretném) megspórolni azt a nem triviális hakkolást, hogy egy megörökölt windows tartományvezérlőt (DHCP, DNS, NPS, stb), meg a hálózati nyomtató(ka)t, scannert, a scannerhez tartozó FTP hostot, a swith-ek mgmt. címeit, továbbá egy tanteremnyi, fix IP-vel a tanári VNC viewerhez belőtt gépet, a másodlagos net szolgáltató failover beállításait, a napelemes épületfűtés hőszivattyújában (távellenőrzéshez) a PLC-knek kiosztott IP címeket, meg még akármit, amire eddig nem gondoltam, szükségképpen át kelljen konfigolni a 192.168-ról az új 10.128-as subnetbe, ahogyan azt a KIFÜ egy csettintéssel elintézettnek tételezi. (Itt most a két iskolában esedékes teendőimet jól összekombináltam, de a lényeg a lényeg... Ugyebár a lustaság rendszergazdai erény ;) Mivel wifi gyanánt már kizárólag az eduroam adott, arrafelé indulnék, hogy a tanári laptopokat egy automatizált, (szkriptelt) SSID detektálás + eduroam konnektálás + VPN indítási folyamattal küldöm be a régi subnetben, változatlan eredeti felállásban maradó windows tartományba. A "fuckup with marmalade" ott van, hogy a user logon előtt egyszerűen nem lehet 802.1x wifi autentikációt kipaszírozni a win10-ből. De csak a domainbe léptetett windowsok viselkednek így és azok is csak az enterprise wifihez való kapcsolódás irányában. Munkacsoportos gépekkel és/vagy WPA2-personallal nincs ilyen mizéria. Végül annyit sikerült elérnem, és talán ez sem jelentéktelen, hogy a win10 logon képernyőn a jobb alsó térfélen a wifi ikonra kattintva, bejelentkezés előtt a felhasználó tud hálózati kapcsolódást kezdeményezni az eduroammal. Tehát ha nem is automatikusan, de egyszerű rásegítéssel. És ha már egyszer be van cache-elve, akkor az eduroam credentials ismételt megadása nélkül is sikerrel járhat. Ezután - (ugyan az összjátékot nem tudtam még kipróbálni, de külön-külön működőképesnek tűnik) - egy openVPN kliens, windows service módban beállítva már beavatkozás nélkül föl tudná építeni a tunnelt, amit a későbbiekben szándékozom beüzemelni egy publikus IP és a régi LAN közé. Az eduroam hálózatból kifelé indított openvpn kliens viselkedését egyelőre vpnbook-os configgal teszteltem, az OK. (Mellesleg - content filter bypassra: használható a vpnbook.) A felhasználókat tehát tájékoztatni kell: ha az iskolai belső hálózatra akarnak megérkezni, (helyi mappa megosztásokat fölcsatolva látni, nyomtatót használni, stb.), akkor feltétlenül még login előtt bökjenek rá a wifire. Passz, egyelőre ennyi. És hogy miért nem volt olyan egyszerű eljutni ide? Mert feltelepítettem ugyan az eduroam CAT-ot minden gond nélkül, ami a felhasználó asztaláról működött is jól. De a logon előtti fázisban nem volt hajlandó konnektálni. Feldobta ugyan az account bekérő popupot, de aztán úgy tett, mintha elhibáztam volna a jelszót, pedig nem. Ezerszer is végigzongoráztam és nem ment. "Nem lehet csatlakozni ehhez a hálózathoz", gondolom ismerős. Akkor az első ötletem az volt, hogy minekutána ilyenkor még system user jogaival futnak a folyamatok, hátha az eduroam CAT-ot be kellene telepíteni a local system profilba is, vagy mi. Akkor lefuttattam a CAT telepítőt "psexec -s -i" segítségével indítva, tehát NTauthority/system felhasználóval. Nem lett jó. Rengeteg fórumot végigtúrtam, így találtam rá, hogy hogyan lehet utólag editálni azokat a paramétereket, amiket a CAT telepítő egy húzással föltesz. A win10 sajátos, faramuci tréfája az, hogy GUI alól ezek a beállítások csak akkor hozzáférhetőek, ha már él az eduroam kapcsolat. T.i. a control panel applettől kiindulva kontextus függő módon nyithatók csak meg a beállítások. Tehát nulladik lépésben kapcsolódni kell az eduroam hálózathoz és azt követően: - először start ncpa.cpl, - aztán a wifi interfész ikonjára bal egérrel duplakatt, - utána középtájon jobbra: a "vezeték nélküli tulajdonságok", - folytatva a megnyíló panel "Biztonság" fülén, - és megint középtájon, a PEAP listaelem melletti "Beállítások" gombbal, - és ott a legfelső pipát kivenni!! (kiszolgáló identitásának ellenőrzése a tanusítvány érvényesítésével) Ennek az az értelme, hogy ne validálja a radius servert, a hozzáadott certificate alapján. Ez szerény meglátásom szerint is security downgrade, tehát útközben egy fake radius MITM ellen védtelenné tettem a klienst. (Elenyésző kockázat, vagy mégsem?) De tapasztalat szerint ez volt az ára annak, hogy a prelogon credentials-t elfogadja! T.i. valószínű, hogy kimarad az a szükséges, kikényszerített lépés, hogy authentikáció előtt server validálás is legyen. (És hogy ezt miért nem teszi meg egyébként, az számomra rejtély. A system nem fér hozzá a cert-hez? Valószínűtlen.) Utólag már nem tudom egyértelműsíteni, hogy a kapcsolati profilhoz tartozó wifi paraméterek eleve felhasználófüggetlenül globálisak-e, vagy csak az egyszer elkövetett "netsh wlan add profile filename=Wi-Fi-eduroam.xml user=all" miatt vált azzá. De ezek után úgy tűnik, bármelyik felhasználó alatt változtatok is valamit, az megjelenik ugyanúgy minden usernél. Ha pedig valamit elcseszek úgy, hogy nem lehet konnektálni, akkor az életbe nem tudom többet korrigálni, mert a GUI csak egy élő kapcsolathoz ad fel beállító paneleket, helyzetérzékeny módon. Ha nem tudok csatlakozni, nincs mit konfigolni. Ötletes, win10 újítás... (Persze létezik workaround a "netsh wlan set profileparameter ..." útján, de az elég rágós.) Mi több, a dolog pikantériája, hogy ilyenkor a "netsh wlan connect name=eduroam" parancs végrehajtása után pofátlanul visszaadja a konzol, hogy "connection request completed successfully", a GUI viszont a képembe tolja azt a hallatlanul adekvát hibaüzenetet, hogy "nem lehet csatlakozni ehhez a hálózathoz". De még cifrább a helyzet azzal, hogy minden jel arra utal, hogy a kapcsolati paraméterektől teljesen függetlenül kezeli (és cache-eli) az OS a profilhoz tartozó login credentials-t. Vagyis az előbbit a ProgramData alatti útvonalon található xml-ekben, utóbbit pedig WlanSvc regisrty kulcs alatt, cryptelve. Így tehát egyrészt elég nehéz eldönteni, hogy adott esetben felhasználó hitelesítési, vagy profil beállítási probléma áll-e fenn. Másrészt pedig ha az eduroamot úgy használnák, ahogy az elvi elvárás, azaz (egy közös használatú gépen) személyenkénti, saját accounttal, akkor ott nem működhet a cache-elés. Az meg hihetetlen macera és kitolás mindenkivel. Ráadásul esetünkben a SingleSignOn sem játszik (amire egyébként lehetőséget adna a 802.1x profil), mert különböző forrásokból és helyekről történik a hitelesítés. Vagy hogyan lehetne replikálni a dashboardon adminisztrált radius usereket egy lokális AD-ba, vagy rosszul gondolom, hogy ez lenne az SSO? Végül pedig csak ezek átgondolása után vetődött föl az a kérdés, lehet-e egyáltalán eduroamra alapozva korrektül helyi domaint üzemeltetni, (még ha az új privát szegmensben lenne is a DC, vagy az eduroam kedvéért a nulláról építenénk újra a tartományt)? Azt nem tehetem meg, hogy a wifi kapcsolat ne a VLAN3-ról jövő DHCP szolgáltatást használja. Ám a DHCP-nek a tartományi DNS szerver címét kellene szórnia, nem? Akkor megint csak hakkolás, hogy az összes gépnél fixen fölülbírált DNS beállítást kell alkalmazni. És akkor még ott van az is, hogy az eduroamos kliensek hogyan regisztrálják magukat a dinamikus DNS-be, ha nem a tartományi DHCP-vel működnek együtt? (Avagy mindezt értsük úgy, hogy a lokális AD-k ideje lejárt, és csak a felhő fölött süt a nap? ;-) Üdvözlettel, Apapirra Sokatir
_______________________________________________ Techinfo mailing list [email protected] Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo Illemtan: http://www.szag.hu/illemtan.html Ügyfélszolgálat FAQ: http://sulinet.niif.hu/
