MOLEHAND Solutions

 
Print  
By Szeifert Gergő on 2014. 10. 21. 13:29

Amikor a Windows 7 lokális belépési jelszavunkat elfelejtettük, és nincsen másik adminisztratív felhasználó akivel resetelni tudnánk akkor egy igen komoly bajba kerülhetünk. Erre van egy alternatív megoldás, amikor a beépített Rendszergazda felhasználóval lépünk be és azon keresztül módosítjuk a jelszavunkat. Azonban ha ez a beépített felhasználó előzetesen nem lett engedélyezve akkor már komolyabb problémával állunk szemben. Viszont erre is van egy áthidaló megoldás, mégpedig hogy utólag tudjuk engedélyezni ezt a felhasználót. Ehhez az alábbi lépéseket kell megtennünk:
 
  1. Bootoljunk be egy Windows 7 lemezről.
  2. Miután megkaptuk a lemez képernyőjét az első Next után kattintsunk a Repair your computer lehetőségre.
  3. Válasszuk ki, hogy melyik operációs rendszert szeretnénk visszaállítani, majd Next.
  4. Válasszuk ki a System Recovery Oprions / Recovery Tools lehetőséget.
  5. Majd indítsuk el a Command Prompt-ot.
  6. Az alábbi parancsokat írjuk bele:
    1. c:
    2. CD Windows\system32
    3. ren magnify.exe cmd.exe
    4. ren cmd.old magnify.exe
  7. Indítsuk újra a számítógépet.
  8. Amikor betölt a Windows logon képernyő akkor a bal alsó sarokban a kisegítő eszközökre kattintsunk.
  9. Indítsuk el a Magnifier-t (Nagyító). Ekkor megjelenik a command prompt ablak.
  10. írjuk be az aláppi parancsot: net user administrator /active:yes Majd nyomjunk entert.
  11. Indítsuk újra a számítógépet.
  12. Lépjünk be a Rendszergazda felhasználóval és módosítsuk a kívánt felhasználónk jelszavát.
  13. Írjuk be a start menübe a magnify.exe-t majd nyomjunk entert.
  14. Az ablakba írjuk beaz alábbit: net user administrator /active:no
  15. Indítsuk újra a számítógépet.
  16. Ismételjük meg az 1-5 lépést.
  17. írjuk be az alábbi parancsokat:
    1. C:
    2. CD Windows\system32
    3. ren magnify.exe cmd.old
    4. ren cmd.exe magnify.exe
    5. ren cmd.old cmd.exe
    6. exit
  18. Indítsuk újra a számítógépet és lépjünk be a megváltoztatott jelszóval és a saját felhasználói nevünkkel.

By Halász István on 2014. 10. 09. 6:41

  1. Töltsük le a programot innen, és installáljuk fel a szerverre úgy, hogy bepipáljuk az OpenSSL Utilities-t és a Certificate Management Scripts-et is.

  2. Indítsunk egy rendszergazdai parancssort és navigáljunk a C:\Program Files\OpenVPN\easy-rsa mappába. (A kiadandó parancsokat félkövérrel írom.)

  3. init-config
  4. notepad vars.bat

  5. Állítsuk át az elérési utat rövidnevesre. Előtte teszteljük, hogy jó helyre mutat-e:
    HOME=c:\Progra~1\OpenVPN\easy-rsa

  6. Állítsuk át 2048 bitre a kulcsméretet
    set KEY_SIZE=2048

  7. Szerkesszük az alábbi sorokat értelemszerűen:
    set KEY_COUNTRY=US
    set KEY_PROVINCE=CA
    set KEY_CITY=SanFrancisco
    set KEY_ORG=OpenVPN
    set
    KEY_EMAIL=mail@host.domain

  8. Mentsük a fájlt, és lépjünk ki a notepadből. Már backupolhatjuk is ezt a fájlt, hogy véletlen törlés esetén ne kelljen újra belőni.

  9. vars
  10. clean-all

  11. Ezután akár érdemes is átnevezni a clean-all.bat-ot pl. clean-all.ba_-ra, hogy ne tudjuk véletlenül kitörölni a tanúsítványokat egy mozdulattal.

  12. build-ca
    Amikor bekéri a script, adjuk be a paramétereket. A default praméterek szögletes zárójelben vannak.
    Ha a default paraméter megfelel, csak Entert kell nyomni.
    Üres stringet úgy tudunk megadni, ha egy pontot írunk, és utána Entert nyomunk. Az OU és a Name nyugodtan lehet üres string, a Common Name az igazán fontos, annak kell egyedinek lennie.
    Ebben a lépésben érdemes Common Namenek "Cégnév-CA"-t megadni.

  13. build-key-server
    Ezzel a paranccsal hozzuk létre a szerver tanúsítványát.
    A build-key parancsok paramétere lesz a fájl neve (jelen esetben .crt, .key, stb.)
    A Common Name nyugodtan lehet szintén .
    A sign the certificate? kérdésnél y és enter
    A commit? kérdésnél y és enter

  14. build-key-pass mike-laptop
    Ezzel a paranccsal hozzuk létre a kliens tanúsítványokat. Ebben a példában Mike laptopjához csinálunk egy tanúsítványt, méghozzá egy jelszóval titkosítottat, mely jelszót az első lépésben be fog kérni a script.
    Lehetőség van rá, hogy jelszó nélküli tanúsítványt hozzunk létre, ekkor az adott gépen nem lesz szükség jelszó megadására a VPN-hez való csatlakozáshoz, szimplán a tanúsítvány szolgál majd azonosításra. Ehhez a build-key mike-laptop parancsot kell használjuk.

  15. build-dh
    Generáljuk le a Diffie Hellman paramétereket.

  16. cd C:\Program Files\OpenVPN\bin
  17. openvpn --genkey --secret ta.key

  18. Másoljuk a létrejött ta.key-t a keys mappába (hogy később meglegyen), valamint tegyük a Config mappába a másik négy konfigurációs fájllal (ca.crt, .crt, .key, dh2048.pem) együtt.

  19. Keressük meg a minta config fájlokat. A következő lépésekben ezeket editáljuk majd.
    Start Menu -> All Programs -> OpenVPN -> OpenVPN Sample Configuration Files
    A parancsok előtti ; szintén "kommentet" jelöl, azaz ezeket a sorokat nem veszi figyelembe a program!

  20. Nyissuk meg a server.ovpn-t, és állítsuk be az alábbi sorokban az elérési utakat az alábbiakhoz hasonlóan, majd mentsük el a Config mappába a végeredményt.

    ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
    cert "C:\\Program Files\\OpenVPN\\config\\hspsrv.crt"
    key "C:\\Program Files\\OpenVPN\\config\\hspsrv.key"
    dh "C:\\Program Files\\OpenVPN\\config\\dh2048.pem"
    tls-auth "C:\\Program Files\\OpenVPN\\config\\ta.key" 0

    A tls-auth direktíva használata nem kötelező, de érdemes használni. Segítségével az összes SSL/TLS handshake csomag integritását ellőrzi a program kapcsolódáskor. Azaz titkosítja ezzel a kulccsal, és ha a másik oldalon nem stimmel a kicsomagolás, akkor eldobálja a csomagokat. (Csak egy példa: amelyik szerver esetén ez be volt kapcsolva, ott nem lehetett a Heartbleed hibát kihasználni...)

  21. Figyelembe ajánlott, opcionális szerver konfigurációs parancsok (a használatukhoz kommenteljük ki őket):

    push "route 172.20.20.0 255.255.255.0"
    A szerver LAN ip tartományáról szerezhetnek így tudomást a kliensek.

    push "redirect-gateway def1 bypass-dhcp"
    Azt mondjuk ezzel a kliensnek, hogy minden internetnek szánt csomagot a VPN kapcsolaton keresztül küldjön. Ahhoz, hogy ki is lásson a kliens az internetre a VPN szerveren keresztül, extra konfigurációra van szükség a szerver oldalon, amelynek utána kell nézni.

    push "dhcp-option DNS 208.67.222.222"
    push "dhcp-option DNS 208.67.220.220"
    push "dhcp-option WINS 10.0.0.100"
    No comment. :)

    duplicate-cn
    Ha egy tanúsítvánnyal többszörös párhuzamos kapcsolódást is szeretnénk engedélyezni, ezt a direktívát kell használjuk.

  22. A client.ovpn-nnel hasonlóképp járhatunk el, azonban macerás elmagyarázni az ügyfélnek, hogy ezt a sok fájlt másolja be ide, ha 64bites a gép, akkor meg oda. Szerenécsere van egy szebb megoldás, be lehet az ovp fájlokba építeni a cert-eket/kulcsokat, így egy db fájlunk lesz kliensenként. Ekkor töröljük ki az elérésí utas sorokat, és az alábbi struktúrába másoljuk bele a notepaddel megnyitott fájlokból a megfelelő részeket:


    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----


    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----


    -----BEGIN ENCRYPTED PRIVATE KEY-----
    ...
    -----END ENCRYPTED PRIVATE KEY-----


    -----BEGIN OpenVPN Static key V1-----
    ...
    -----END OpenVPN Static key V1-----


  1. Ha az elérési utas megoldást választottuk, akkor a kliens konfigokban a tls-auth direktíva 1-esre végződik (ezzel jelezzük, hogy ez a kliens oldal):
    tls-auth "C:\\Program Files\\OpenVPN\\config\\ta.key" 1

    ha pedig a kulcs "beépítést", akkor a következő sort kell hozzáadnunk a konfighoz:
    key-direction 1

  2. Meg kell még adnunk a kliensnek, hogy hol találja a szervert, és melyik porton:
    remote molehand.eu 1194

  3. remote-cert-tls server
    Amennyiben egy rosszindulatú személy megszerezne egy kliens konfigot, akkor az ahhoz tartozó tanúsítványokat szerver üzemmódban is tudja futtatni, és így man-in-the-middle támadást tud létrehozni, amikor is azt hiszed, hogy a céges VPN szerverhez csatlakozol, miközben az ő szerverként futtatott kliens konfigjához. A build-key-server és build-key scriptek "megjelölik" a tanúsítványokat, hogy "kérem ez a tanúsítvány szervernek / kliensnek lett létrehozva". A fenti direktívával biztosra mehetünk, csak "szerver" azonosítójú tanúsítványhoz lesz hajlandó a kliens csatlakozni.

  4. Ezzel a konfig fájlokkal végeztünk, másoljuk be őket a config mappába. Ehhez a klienseken is telepítsük fel az OpenVPN-t (az OpenSSL Utilities és a Certificate Management Scripts ezeken nem fog kelleni). Ne lepődjünk meg, a kliens és a szerver telepítő teljesen ugyanaz, csak a konfig fájlok döntik el, hogy egy gép szerverként vagy kliensként viselkedik.

  5. Nyissuk ki a routeren az OpenVPN portot, ill. forwardoljuk.
    Alapból ez az UDP 1194-es port.

  6. Ha el kell érni a LAN-t a VPN-en keresztül, azaz használjuk az alábbi direktívát
    push "route 172.20.20.0 255.255.255.0"
    egy statikus útvonalat is fel kell venni a routerben, hogy a csomagok visszataláljanak:
    route add 10.8.0.0 mask 255.255.255.0  metric

    Ezen kívül szükség van még egy dologra: az OpenVPN szervernek is kell tudnia route-olnia, hogy a VPN hálózatból a LAN hálózatba átforgassa a csomagokat és vissza. Ezért amennyiben nem működik a kapcsolódás a LAN-ra a fenti beállítások elvégzése után, úgy a következő registry módosítást kell eszközöljük:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters

    Itt az IpEnableRouter bejegyzést állítsuk 1-re (ill. hozzuk létre, ha nincs).

  7. A szerveren a szolgáltatások között keressük meg az OpenVPN service-t, állítsuk Automatikus indulásúra, és indítsuk is el.

  8. A klienseken az OpenVPNGUI parancsikonnal tudjuk indítani.

    Abban az esetben, ha van a usernek rendszergazda joga, állítsuk be a parancsikont, hogy mindig rendszergazdaként indítsa a GUI-t. Erre azért van szükség, mert az útvonal hozzáadáshoz rendszergazda jogokra van szükség Windows alatt.

    Ha nincs, itt is a service-ként való futtatás jelenti a megoldást. A service-hez tudunk jogosultságot adni, így nem feltétlenül kell ilyen esetben feltétlenül folyamatos VPN kapcsolatot fenntartani.

A tanúsítványokat/kulcsokat őrizzük meg jól, érdemes a rendszeres mentésbe belevenni a keys mappát! Erre azért van szükség, mert nem szeretnénk MINDEN tanúsítványt újra elkészíteni, amennyiben egy eszközt ellopnak, rajta a VPN konfiggal. Ezt úgy tudjuk megspórolni, ha az adott tanúsítványt visszavonjuk, ezt azonban csak akkor tudjuk megtenni, ha megvan maga a tanúsítvány!

 

TANÚSÍTVÁNYOK VISSZAVONÁSA

  1. Tanúsítvány visszavonó lista létrehozása (Certificate Revoking List (CRL))

    revoke-full

    A parancs végrehajtása után az utolsó sorban ezt kell lássuk:
    error 23 at 0 depth lookup:certificate revoked

  2. Másoljuk a létrejött crl.pem fájlt a config mappába

  3. Ellenőrizhetjük a fájlt a következő paranccsal

    openssl crl -in "c:\program files\openvpn\config\crl.pem" -text

  4. Adjuk hozzá a következő direktívát a szerver konfigjához:

    crl-verify "C:\\Program Files\\OpenVPN\\config\\crl.pem"

  5. Indítsuk újra az OpenVPN szervert. (Volt, amikor 2x kellett megtenni, hogy a beállítás érvényre jusson.)

  6. Ha mindent jól csináltunk, minden, ezzel a tanúsítvánnyal történő csatlakozás innentől meg fog hiúsulni, és a következőhöz hasonló lesz látható a kliens logban:

    CRL CHECK FAILED: C=US, ST=CA, L=City, O=name, OU=name.example.org, CN=client, name=client, emailAddress=openvpn@example.org is REVOKED

 

HIBAKERESÉS

  1. Ha a tűzfal kikapcsolt állapotában minden oké, de bekapcsoltan nem működik, akkor valószínűleg a VPN hálózat azonosítatlan (Unidentified) besorolásával lesz a probléma. Erre szép megoldást még nem találtam*, de workaround van: át kell állítani a Local Security Policy-ben, hogy az Unidentified hálózatok alapértelmezés szerint ne Public, hanem Private besorolást kapjanak. Mivel wifi elvétve van a szerverekben, így ez nem tűnik annyira komoly biztonsági kockázatnak.

    *A kézi átállítást úgy tűnik nem jegyzi meg a Windows, újraindítás után újra Public lesz a VPN hálózat...

  2. Ne PowerShellt használjunk a beállításokhoz, azzal nem mennek a scriptek!

  3. Ha nem sikerül kapcsolódni a következőhöz hasonló hibával a logban
    SIGUSR1[soft,private-key-password-failure]

    akkor valószínűleg "beépítős" konfig fájlt használunk, és egy plusz sortörés karakter került a konfigba egy ------ -es sor és maga a cert/kulcs közé. Notepad++-al megnyitva a konfig fájlt, és bekapcsolva a speciális karakterek mutatását, ellenőrizzük le. Általában a [*]
    -vel jelölt helyen lévő sortörés szokott problémát okozni:

    CRLF
    -----BEGIN ENCRYPTED PRIVATE KEY-----LF
    [*]
    xxxxxxxxxxxxxxxxxxxxxxxxxxxLF
    xxxxxxxxxxxxxxxxxxxxxxxxxxxLF
    xxxxxxxxxxxxxxxxxxxxxxxxxxxLF
    -----END ENCRYPTED PRIVATE KEY-----LF
    CRLF



    Az is lehet a probléma gyökere, ha lusták voltunk, és nem egy-az-egyben másoltuk a kulcsot, hanem csak a ------- -ek közötti részt, ugyanis a fejlécek különbözőek jelszavas és jelszó nélküli esetben. Jelszó nélküli esetben ilyen a fejléc:
    -----BEGIN PRIVATE KEY-----
    -----END PRIVATE KEY-----

  4. Script futtatásakor (build-key például) az alábbi hibaüzenethez hasonlót látunk:
    STR_COPY:variable has no value

    Amennyiben a vars.bat-ban valamelyik paraméter default értékének üres stringet adtunk meg, akkor találkoztam vele, ekkor ugyanis nem fog létrejönni az adott környezeti változó!

  5. ERROR: Windows route add command failed: returned error code 1073807366 a kliens logban

    Győződjünk meg róla, hogy rendszergazdaként indítottuk az OpenVPNGUI-t. Ha nem ez a gond, akkor adjuk hozzá a következő direktívát a kliens konfighoz:
    ip-win32 ipapi

By Halász István on 2014. 10. 09. 3:48

Office365 Outlook hiba
 
Egy új gépen közvetlenül telepítés után csinálta ezt az Outlook elindulás helyett.
 
Megoldásképp először próbáljunk új Outlook profilt létrehozni.
 
Fontos tudnivaló: Office 365 esetén ne lepődjünk meg, ha a vezérlőpultban a Posta szóra rákeresve nincs találat, lehet, hogy Mail néven kell keressük!
 
Ha az új profil is ezt csinálja, akkor töröljük a Vezérlőpult -> Hitelesítő adatok kezelőjéből (Credential Manager) az Általános részen az elmentett Outlook/Office 365 credentialokat.
(Delete the Outlook/Office 365 credentials under the Generic Credential section in Control Panel > Credential Manager.)
 
 

By Halász István on 2014. 10. 08. 13:19

Kiszolgáló: smtp.office365.com

Felhasználónév / jelszó:

Port: 587

Titkosítás: kötelező, TLS

Megjegyzés: A 25-ös port is használható, de ezt általában engedélyeztetni kell az internetszolgáltatóknál.

 

 

Discount offer

 I’ve already tried several providers. Currently all of our projects are placed at MOLEHAND, because they provide real services not only a piece of a computer. Any kind of new problem crops up, I can always count on a fast and expert reaction.