A Windows világ annyira nem barátom, de most meg kellene oldanom egy Windows kliens érintő VPN problémát, de nem találom a megoldást, és a Google sem a barátom már. Az összes felmerülő oldal elolvasása után még mindig nem működik, és nem jövők rá miért, vagy, hogy egyáltalán lehet-e ilyent.
A feladat egyszerűnek tűnik: Windows 11 Pro laptop, tartományba léptetve. Szeretném beállítani, hogy a bejelentkezési képernyőn tudjon a user VPN kapcsolatot létesíteni, majd élő VPN-en át hitelesíteni magát az AD-ban. A VPN hitelesítési adatok és az AD hitelesítési adatok nem azonosak.
A gond az, hogy a felvett VPN kapcsolat ("minden user láthatja" típusú) megjelenik ugyan a login képernyőn, rákattintva kér is név/jelszó párost, de a VPN-hez is és az AD hitelesítéshez is ugyan azt akarja használni a Windows. Ha VPN acc-ot adok meg, akkor csatlakozik sikeresen, de nem sikerül az AD hitelesítés, és bontja is a VPN-t (nem kér újra jelszót, ahol lenne esélyem az AD-s adatokat megadni). Ha meg az AD acc-ot adom meg, akkor nyilván a VPN nem kapcsolódik és ahhoz sem kér másik hitelesítő adatot.
A legközelebbi amit találtam, hogy a rasphone.pbk-ban átállítottam az UseRasCredentials-t nullára, de nem segített.
A VPN szerver egy Mikrotik router (L2TP/IPsec), de a router márkája talán nem is lényeges, csak annyi, hogy nem Windows RRAS VPN szerver van, és nem AD-ből hitelesít a VPN szerver, viszont kliens oldalon a Windows 11 beépített VPN kliensét használnánk praktikusságból.
Bármi ötlet bárkinek? Az is segítene, ha tudnám, így biztosn nem megoldható, és akkor más megoldást keresek.
Hozzászólások
Service-kent futtatni a vpn kapcsolatot?
Domain, tárhely és webes megoldások: aWh
Ok, de a user-t nem könnyű megtanítani, hogy állítson le egy szolgáltatást (pláne sima user jogkörrel...), ha épp bent van a cégnél a helyi hálózaton, és nem kell VPN a melóhoz.
Én több helyen úgy oldom meg, hogy a munkahelyen is megy a VPN és a laptopok a guest wifi-t használják, mert csak az van :)
A laptopok 99%-ban amúgy is wifi-t használnak az irodában is, a login előtti VPN-t meg egy service-ként futtatott wireguard megoldja.
Úgy tudom, hogy a Windows ezeket a VPN kapcsolatokat, attól függően, hogy rendszer szintű, vagy user szintű, itt tárolja:
vagy
Ha ott van egy rasphone.pbk fájl, elvileg abban lehet megadni, hogy mivel próbáljon a VPN hitelesíteni.
Nagy Péter
Igen is meg nem is.
Igen, a tárolási hely stimmel. A felhasználói mappán belüli csak azé a felhasználóé. Amikor azt mondom egy kapcsolatra, hogy bármelyik user használhatja, akkor kerül át a C:\ProgramData alá és mindenki látja.
Viszont a hitelesítő adatokat mindig user szinten tárolja, szóval a megosztott VPN kapcsolatokhoz is minden azt használó user-nek meg kell adni a hitelesítő adatát.
Ráadásul tök érthető, hogy a login képernyőn nem enged elmentett hitelesítő adatokkal csatlakozni, mivel még az bárki is lehet, aki a login felületet látja, miért is engedné egyel közelebb a belső hálózathoz hitelesítés nélkü. Viszont az jó lenne, ha lehetne külön a VPN-re hitelesíteni, majd ha csatlakozott, akkor a tartományba.
https://windowsreport.com/windows-10-connect-vpn-before-login/
Nem lenne célszerűbb klienstanúsítvánnyal intézni a VPN-t?
Userek számától függő méretű szívás a certek kiosztása, frissítése, pláne ha nem minden user jogosult VPN-re.
AD-s környezetben azért nincs ezzel probléma, megoldható automatikusan. Alapból mindenki kap cert-t, és az auth során dől el, hogy jogosult vagy használni a szolgáltatást (VPN) vagy nem (sec. group-pal meghatározva).
De ahhoz normális CA-infrastruktúrát kell összerakni (ezt nem szokás...)...
Hat amikor tizeneve lattam ADt belulrol az tenyleg par kattintas volt es lett CA-d.
Ami mindent is aláíró root-CA a céges hálózatban...
az nem jön az AD-val?
Domain, tárhely és webes megoldások: aWh
A van benne CA meg a normális CA-infrastruktúra elég messze van egymástól...
Egy-két észrevétel:
Nem világos a koncepció. Miért van külön választva a VPN auth.-hoz használt user name és a felhasználói név a login-hoz a gépbe. A felhasználókat egy helyre authentikáltatjuk be, és törekszünk arra, hogy mindenhol ugyan azt a felhasználói nevet (általánosságba ez a felhasználó email címe) és jelszót használja. Ha IT biztonsági kérdés (legyen külön választva a két login), akkor meg tanúsítvány alapú hitelesítést kell használni.
Ha elvárás az, hogy a felhasználó a kliens gépen keresztül mindig az AD-hoz authentikáljon, akkor nem a felhasználói interakcióra bízom azt, hogy ő építse ki a vpn kapcsolatot a cég felé, hanem ez történjen meg automatikusan, hogy ez ne legyen megkerülhető.
Léteznek olyan VPN kliensek (Cisco AnyConnect, de lehet, hogy a Windows található SSP vagy IKEv2 kliens is képes rá) ami képes a háttérbe kiépíteni a céges hálózat felé automatikusan a vpn kapcsolatot, amikor Internetre kerül a gép.
Ha létezik Azure AD a cégnél, akkor azon keresztül a felhasználók nem tudnak belépni a számítógépbe? Így nem lenne szükség a VPN kapcsolatra a bejelentkezés elött, de a felhasználó mindenképp AD-hoz authentikál be.
Szóval átgondolnám a koncepciót első körben, és lehet hogy nem tennék bele több időt olyan hibakeresésbe, ami lehet, hogy vakvágány.
Ez egy megörökölt rendszer az előző üzemeltetőtől, külső szolgáltatóként léptünk be az IT-be a cégnél. Most felmerült, hogy jó lenne pár laptop user-nek távolról is dolgozni olykor, így jött elő a feladat.
Kb 10 user, ebből 3-4 VPN-ezik olykor, egy Windows szerver, Mikrotik router a felállásuk.
A koncepcióm az volt, hogy elsőre a legegyszerűbben gondoltam megoldani, azért kerestem a vázolt problémámra megoldást.
Nem szeretnék tanúsítványozni, mert senki nem ért hozzá az adott cégnél (meg, khm... nálunk a kollégák közül is kevesen), így olyan megoldás kellene, ami könnyebben "javítható" nélkülem is. Jó pár helyen tanúsítvánnyal mennek a VPN-ek az ügyfél cégeknél, de látom a korlátot, hogy ha bármi van, én kellek hozzá, és egyre kevésbé fekszik a 24/365 rendelkezésre állás. Így kerülök minden olyan megoldást, amit a környezetemben más nem ismer (ilyen sajna sok van, és nem azért, mert én akkora zseni lennék...).
Most úgy gondolom, felteszem az NPS szerepkört a szerverre, és beállítom, hogy RADIUS-ból hitelesítsen a Mikrotik sima név/jelszó párossan. Így ugyan nem lesz különválasztva a két hitelesítés, de legalább egy belépéssel le lesz tudva a VPN és az AD hitelesítés is.
Egy következő lépés lehet, ha kiderül, hogy mégis sokat használják házon kívül a gépeket, hogy tanúsítvánnyal VPN-ezve működhessen a Windows-os always-on VPN. Ott még el kell olvasnom, hogy mi a teendő (lehet-e deaktiválni), ha a céges vezetékes hálózatra csatlakozik a gép (ez lesz a jellemzőbb ugyanis, nem a VPN és a wifi).
És kell az auth résznél egyáltalán a VPN? Régebben volt ilyen, hogy egy honapon belül, meg talán 10-15 login ment offline is, aztán akkor belép, és elég csak utána csattognia fel a vpn-re.
Domain, tárhely és webes megoldások: aWh
Azt tapasztaltam, hogy a GPO-ból jövő hálózati meghajtó map-ek nem feltétlen jelennek meg, ha csak belépés után kapcsolódik a VPN-re. Pláne, ha ritkán használt gép és a ticket-ek lejárnak időközben. Ráadásul ha ott a hálózati meghajtó, de piros X van rajta, akkor előbb hívja a support-ot, hogy baj van, minthogy eszébe jusson, hogy VPN-ezni kellene.
Jobb élmény a user-nek, ha kapásból minden működik úgy, ahogy megszokta. Ezért gondoltam a belépés előtti VPN kapcsolódást fontosnak.
Ezek alapján én átraknám azt a pár felhasználót Wireguard alá, és automatikus kapcsolódásra állítanám be. Ez gyorsan beállítható, nem kell NPS-sel és a Radius+Mikrotik-kal szórakozni.
Mikrotikon lehet csinálni 5000 napos tanusítványt is. :)
A windows nekem sem barátom, meg segíteni sem fogok tudni.
A céges gépen win10 van, a Cisco AnyConnect certivel authentikál, akár a logon screenen is ha rányomok (nem szokott kelleni).
Ha már egyszer beléptem, bárhol/bármilyen net ha van/cserélődik, másodperceken belül automatikusan csatlakozik a vpn.
Az
OS-bewin10-re net/vpn nélkül is be tudok lépni. De minek :Pecho crash > /dev/kmem