Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > Posts > Zážitky s uživatelským 802.1x
srpen 23
Zážitky s uživatelským 802.1x

Sice už jsem několikrát 802.1x implementoval, ale vždycky to bylo jen za pomoci certifikátů počítačů. Vždycky jsem ověřoval jen identitu počítače. Nikdy jsem neověřoval uživatele, protože to s Windows XP fungovalo podivně, chovalo se to nestabilně, občas se to odpojovalo a většinou to děsně dlouho trvalo, než se síťovka "chytla".

Takže jsem byl moc rád, když jsem byl požádán o implementaci 802.1x pro čistě Windows 7 prostředí a mohl si vyzkoušet, jak to funguje při ověřování obojího, počítače i uživatelů. A nikdy jsem si vlastně ani neuvědomil, jak je to uživatelské ověřování pěkné :-) Hlavně to s Windows 7 funguje hladce! Následují detaily a fakta, která jsem ověřil že fungují, takže to třeba někomu pomůže rychle s tím začít, aniž by musel procházet tím, čím já, protože s nějakými výchozími parametry rozhodně nepočítejte :-)

Co je vlastně 802.1x

Nebudeme se tu zabývat příliš vysvětlováním funkce, jen detaily potřebné pro implementaci ve Windows. Jedná se o technologii, která omezuje přístup neznámých počítačů, případně uživatelů, do sítě. Jednoduše řečeno, síťové switche (Ethernet, WiFi) vypnou daný port, pakliže připojený počítač nedokáže prokázat svoji identitu. Znamená to, že se vám do sítě nemůže připojit cizí počítač. Ověření identity se provádí ve Windows pomocí loginu a hesla uživatele nebo počítače do domény, nebo pomocí SSL klientského certifikátu (SSL Clien Certificate, Client Authentication).

Ověřovat tedy můžete buď počítač, bez ohledu kdo je na něm přihlášen. Buď to jsou všechno vaše doménové počítače a používá se prostě jejich heslo, nebo jim vydáváte certifikáty. Ověřovat můžete ale i jednotlivé uživatele. To by znamenalo, se se síťová karta odpojuje a připojuje až v okamžiku, kdy je někdo přihlášen.

Jak to funguje

Potřebujete switche, nebo WiFi AP, které tenhle protokol umí. V případě switchů to znamená, že musí být spravovatelné, tedy dražší. Je to o to horší, že každý kabel musí být připojen do spravovatelného switche. Jakmile k nějaké spravované zásuvce připojíte nespravovatelný switch (který tedy zřejmě neumí 802.1x), přes tento switch se nebudou počítače ani uživatelů už dále ověřovat. Zřejmě tedy budete muset mít všechny switche spravovatelné.

Dále potřebujete RADIUS server, který bude ve skutečnosti uživatele ověřovat. Switch ani AP sám tohle nedělá, jen přeposílá ověřovací komunikaci mezi uživatelem a RADIUS serverem. V případě Microsoft implementace budeme mít buď IAS (Internet Authentication Service), nebo novější NPS (Network Policy Server).

Jakmile se zastrčí kabel do switche, prvek si sám řekne klientskému počítači, že požaduje ověření. Počítač mu pošle ověřovací informace, které daný prvek přeposílá s RADIUS serverem. Pokud RADIUS řekne, že je to v pořádku, switch povolí další komunikace na dané zásuvce.

Výhoda je, že RADIUS server může switchi říct nejenom "ok, pusť ho", ale může mu také přidělit číslo VLAN, do které má být daný port přehozen. Můžete tedy mít více různých politik. Například určitá skupina počítačů může být pouze ve VLAN s lokálním přístupem, jiné stroje s přístupem do internetu, nebo někdo třeba jen s velmi omezeným přístupem. Upozorňuju, že VLAN znamená samostatný IP rozsah!

Výhody počítačového ověření

Ověřování počítačů je jasné. Pokud se nejedná o autorizovaný stroj, prostě se do sítě nedostane. Případně můžete mít třeba více skupin počítačů, které rozhazujete do různých VLAN, podle různých požadavků. Třeba obyčejné klientské stroje vs. notebooky správců vs. neověřené počítače, které se musí nějak nainstalovat apod.

Pro ověření si vyberete jen účet a heslo stroje do domény, pokud jsou všechny počítače v doméně. Jinak byste zřejmě použili certifikáty. Ty vyžadují určitou, i když jen velmi jednoduchou správu, takže je to nejspíš až druhé řešení. Ale pro stroje, které nejsou v doméně, to jinak nepůjde.

Uživatelské ověření

Proč bych ověřoval uživatele? Jsou různé důvody, které se někdy hodí a někdy ne, podle toho co přesně chcete:

  • Ne-doménové počítače - budu ověřovat uživatele pomocí jejich loginu a hesla do domény. Každý si bude moci donést i třeba svůj domácí počítač, ale když zadá svoje doménové heslo, do sítě se dostane.
  • Individuální VLAN podle uživatelských skupin - chtěl bych dávat počítače do různých VLAN podle toho, kdo je tam zrovna přihlášen. Možná se vám to nezdá úplně potřebné. Ale představte si například scénář - skupina správců sítě s maximálně neomezeným přístupem vs. ostatní doménoví uživatelé vs. lokální uživatelé.

Vyberete si ověření heslem, nebo certifikátem? Heslo ti lidé znají a mohou ho zadávat i na počítačích, které nejsou v doméně. Jde o to, jestli tohle chcete, nebo nechcete. Sice možná nebudu vědět co to je za počítač, ale možná mi to také nevadí, protože vím, že tam pracuje uživatel se "zodpovědností".

S certifikátem to bude možné více navázat na doménové počítače. Certifikáty se normálně ukládají v profilu uživatele (pokud nepoužívají čipové karty). Profily máte jen na doménových počítačích. Certifikáty mohou být označeny jako ne-exportovatelné. Tím se dá poměrně pohodlně uživatelům ztížit připojování z cizích strojů (říkám ztížit, protože to půjde nějak komplikovaně obějít, ale může to být nad schopnosti normálních lidí).

Ověření uživatelů i počítačů

Klient 802.1x ve Windows bohužel neumí současné ověření obojího. To znamená, že buď je na kabelu ověřen uživatel, nebo počítač. Můžete si zapnout "oboje", ale bude to fungovat tak, že při startu stroje se ověří počítač a jakmile se někdo přihlásí, ověří se to podle toho uživatele. Je také možné, že když se náhodou přihlásí uživatel, který nelze ověřit (například lokální uživatel), tak bude stroj bez konektivity.

Tuhle poslední možnost jsme použili my. Požadavkem zákazníka bylo, aby doménoví uživatelé mohli všude, zatímco lokání nemohli vůbec nikam.

Ještě jedním faktem je, že pokud se použije tato "přepínaná kombinace", bude nutné ověřovat všechny identity (počítače i uživatele) stejným typem, tzn. oba buď certifikátem, nebo oba jen heslem. Nelze to kombinovat, protože Windows klient má pouze jednu nastavení, kde se to musí vybrat natvrdo.

Náš složitý a ověřený scénář

Požadavkem bylo zařídit, aby:

  • ne-doménové stroje se do sítě nedostaly - z toho plyne, že musíme ověřovat počítače, ale můžeme prozatím použít buď certifikáty nebo loginy.
  • ne-doménové stroje se musí nějak nainstalovat a připojit - pokud se stroj neověří, bude muset být v nějaké, byť velmi omezené, VLAN s přístupem alespoň na jedno DCčko (Domain Controller)
  • doménové počítače musí mít přistup do lokální sítě - okej, po ověření budou v nějaké méně omezené VLAN.
  • doménoví uživatelé musí mít přístup i do internetu, lokální nesmí nikam - to znamená, že musíme ověřovat i uživatele. Bude to znamenat také další VLAN s přístupem do internetu. Aby byla splněna podmínka "jen doménové stroje", budeme potřebovat certifikáty (ne-exportovatelné). Hesla nemůžeme nechat lidi zadávat, protože by si je mohli zadávat i na libovolných přinesených počítačích.
  • pokud mají uživatelé na počítači jeden cizí certifikát, musí je ověřit jiný RADIUS server, než ten náš. Pozná se to tak, že v tom jejich certifikátu je jiné jméno uživatele, tedy přesněji řečeno jiná doména za zavináčem @.

Výsledný systém je tedy:

  • Ověřování certifikáty
  • Ověřování obojího, počítačů i uživatelů
  • Certifikáty se vydávají automaticky (autoenrollment) doménovým počítačům i uživatelům
  • Certifikáty jsou ne-exportovatelné (pozor, tohle je jen slabé omezení, ale aby to někdo obešel, musel by být dost zkušený a my to ještě navíc můžeme sledovat)
  • Tři VLANy. Když se nikdo neověří, je v "instalační VLAN" s přístupem na jediné DC a AD CS (Active Directory Certificate Services), tedy certifikační autoritu. Když se ověří počítač, hned po svém startu je v "doménové VLAN", tedy s přístupem do intranetu. Jakmile se později přihlásí nějaký doménový uživatel, stroj se přepne do "internetové VLAN" s plným přístupem i ven. Pokud by se přihlásil lokální uživatel, neověří se, takže to zase spadne do té původní "instalační VLAN".

Certifikáty

Certifikáty vydáváme automaticky pomocí technologie autoenrollment. Když to budete implementovat, dávejte pozor na toto:

  • certifikační autorita, která vydává certifikáty musí být v NTAuth store v Active Directory.
  • chceme autoenrollment, takže potřebujeme, aby ta autorita byla nainstalována tzv. v režimu Enterprise. Nemusíte mít Enterprise Edition operačního systému, jen musíte tu autoritu nainstalovat do "režimu" Enterprise.
  • ideálně si vytvořte na to novou CA, protože ji potom velmi jednoduše omezíte v politice pro uživatelské počítače (chápu, že to není jen tak, klidně použijte stávající :-))
  • pokud použijete AD CS na Windows Server 2008 R2, tak můžete používat šablony certifikátů (Certificate Template) i když máte jen Standard Edition.
  • musíte použít dvě šablony (Certificate Template). Udělejte si kopii výchozí User šablony pro uživatele a Computer šablony pro počítač. Pokud uděláte jenom jednu šablonu, buď počítač, nebo uživatel si ji sám nevydá - šablony jsou vždy typu buď User nebo Computer a ten druhý si ji nemůže vyžádat.
  • kopii vytvořte pouze Windows Server 2003 a nikoliv 2008. Starší verze produkuje certifikáty do CSP, zatímco novější do CNG úložiště. Klient 802.1x (konkrétně obecně EAP klient) ale CNG nepodporuje ani na Windows 7, takže musíte použít starší CSP.
  • v obou šablonách chcete, aby to nebylo exportovatelné, Subject vytvářet automaticky podle obsahu Active Directory. Dávat tam email nemá smysl a ani by to nemuselo někdy fungovat, pokud uživatel email nemá vůbec definován. Ujistěte se, že CSP je vybráno RSA and AES Cryptographic Services Provider. Tím zajistíte, že se to nebude dát vydat do čipové karty, kterou by si uživatel mohl přenášet.
  • Application Policies, neboli EKU (Enhanced Key Usage) si nastavte na Client Authentication (1.3.6.1.5.5.7.3.2), ale můžete tam přidat i libovolné další OIDy. Tyto další OID čísla by bylo možné vynutit v politice na RADIUS serveru a omezit tak množství použitelných certifikátů.
  • na záložce Security si nastavte pro příslušnou skupinu uživatelů nebo počítačů oprávnění Read, Enroll a Autoenroll.

S klientskými certifikáty je trošku problém, protože klient si musí vybrat certifikát ještě předtím, než se začne ověřovat vůči RADIUS serveru. Musí mu totiž poslat svoji identifikaci, tedy jméno toho certifikátu, podle které se RADIUS může například rozhodnout jestli ho bude vůbec ověřovat, nebo ten požadavek třeba přeposle apod. Znamená to, že jestliže má klient více možných certifikátů (prakticky rozlišuje pouze podle Client Authentication EKU), je nepříjemné, že si možná vybere nějaký nesprávný.

Dále potřebujete certifikát pro RADIUS server. Stačí libovolný SSL serverový certifikát (Server Authentication, OID 1.3.6.1.5.5.7.3.1). Dá se zase vydávat pomocí technologie autoenrollment. V konfiguraci IAS/NPS serveru musíte vybrat nějaký konkrétní certifikát, ale jakmile ten vyexpiruje a je k dispozici novější, IAS/NPS si ho sám nahradí. Blbé na tom je, že nahrazuje libovolným novějším, který má stejný Subject (bez ohledu třeba i na CA). Tzn. opět platí, že jestliže na RADIUS serveru máte více platných certifikátů, můžete mít problémy.

Ideální je dávat pozor a mít jak na klientovi tak serveru vždy jen jeden platný certifikát.

Nastavení IAS/NPS serveru

Prostě vytvoříte příslušné RADIUS politiky. Na nich není nic speciálního. Uvedu jen několik ověřených faktů:

  • lze použít PEAP s ověřováním pomocí Smart card or other certificate a to bez ohledu na to, jestli ověřujete počítač, uživatele, nebo oboje (jak někdo vyhrožoval na různých konferencích).
  • měli byste vypnout b>Fast Reconnect.. Nevím sice proč přesně, ale dělalo mi to dříve problémy i s ověřováním počítačů, ale když to používáte při ověřování uživatelů, chová se to úplně divně - někdy se to neodpojí, někdy se to nepřipojí apod.
  • pokud chcete přidělovat čísla VLAN, udělejte si více různých Network Access Policies a do nich dejte RADIUS atributy:
    • Tunnel Type = VLAN
    • Tunnel Medium Type = 802
    • Tunnel Private Group ID = konkrétní VLAN ID ddd
  • pokud chcete limitovat přijatelné klientské certifikáty pomocí jejich OID, můžete použít podmínku Allowed-Certificate-OID. Nicméně tohle bohužel neovlivní klienta, pokud by měl více certifikátů. Bohužel, pokud si vybere z více možných ten, který nemá zrovna příslušný OID, prostě se neověří.

Pokud chcete sledovat nějaké logy na Windows 2008/R2 NPS serveru, zapněte si buď celé auditování kategorie Logon/Logoff a události uvidíte v Security logu, Event Source je Microsoft Windows Security Auditing a Task Cateogry je Network Policy Server. V událostech jsou krásně vidět všechny důvody, proč to nefunguje, jakou politiku to případně použilo a který uživatel se to vlastně ověřil. Můžete si ale zapnout i jen auditovací podkategorii Network Policy Server, což je super novinka na Windows 2008 a Windows 2008 R2. Buď pomocí GPO, nebo rovnou z příkazové řádky:

auditpol /set /subcategory:"network policy server" /success:enable /failure:enable

Nastavení klienta

Klienty nastavujte pomocí Group Policy, můžete samozřejmě ručně, ale přes GPO je to jednodušší a automatičtější. A nastavení (i když se jmenuje Windows Vista Policy) funguje i pro Windows XP SP3.

Takže stačí nový Group Policy Object (GPO), v jeho počítačové části je Windows Settings, Security Settings, Wired Network Policies. Vytvoříte novou Windows Vista Policy a nemusíte se bát, opravdu funguje i pro Windows XP. A do ní zopakujte to stejné, co jste zadali do pravidel v NPS. Takže rekapitulace:

  • Authenticate User and Computer, bude se používat buď počítačova identity, dokud nebude nikdo přihlášen.
  • PEAP, Smart card or other certificate
  • Verify server identity - tady je zajímavé že mi to funguje, pokud to zapnu pouze na té první záložce (PEAP obal), ale nesmím to zapnout na té další, to už potom nefunguje. Netuším.
  • vypnout Fast Reconnect
  • zapnout Single-sign-on - zrychlíte přihlašování a přepínání uživatelů

A je to :-) Kdybyste s tím měli nějaké problémy, klidně napište :-)

 

Comments

doplnění

Pěkný článek, s dovolením jen doplnění. Na klientech můžete využít Network Access Protection (NAP) - ověřuje například stav aktualizací a antiviru, pak musíte zapnout na klientovi službu "napagent" a pro autentizaci 802.1X zapnout službu "dot3svc".
David Tourek on 1.3.2012 14:16

Re: Zážitky s uživatelským 802.1x

Diky za doplneni. Ještě bych zmínil, že GUIčko NPS serveru vyžaduje, aby certifikát pro EAP/TLS měl v políčku Subject alespoň nějakou hodnotu. Pokud to tam nemá (výzhocí u mnoha šablon certifikátů), tak se vám nebude zobrazovat v konzoli jako nabídka ve výběru (je jedno, jestli má nějaký SAN, musí mít Subject). Teď mě jenom napadlo, co takhle mu zadat Friendly Name? To jsem nezkoušel.
ondas on 2.3.2012 8:23

Smart Card

Snazil som sa nakonfigurovat 2 roky dozadu 802.1x pri prihlasovani smart kartou + overenie pocitaca, voci AD. Radius server Cisco SE ACS 5.x. Pomocou nativneho klienta vo Win XP overenie pouzivatela a pocitaca "no chance"! Overenie len pouzivatela alebo len pocitaca voci AD nebol problem. Skusal som potom asi 5 dostupnych dot1x klientov a ziadny korektne nefungoval pod XP. Windows 7 vsetko vyriesil :)
Jo a este dodam. Overovanie pouzivatela + PC na WinXP fungovalo (ako tak) ale len pri MS-CHAPv2. EAP/TLS nie.
Tomas Kukan on 11.10.2012 9:26

Re: Zážitky s uživatelským 802.1x

děkuju za další zážitek :-) Ano já taky nemám vůbec dobré zkušenosti s 802.1x s XP obecně. S certifikáty počítače to jede, řekl bych nejlépe. Díky.
ondass on 16.10.2012 6:57

IP telefon

Pekny clanek, vse fungluje tak jak ma pouze resime situaci kdy pocitac je zapojen do site prez Cisco IP telefon. Existuje varianta i pro tento provoz? Pocitac a telefon jsou samozrejmne v jine wlan.
Jaroslav Dolezal on 2.1.2013 11:35

IP telefon

Pekny clanek, vse fungluje tak jak ma pouze resime situaci kdy pocitac je zapojen do site prez Cisco IP telefon. Existuje varianta i pro tento provoz? Pocitac a telefon jsou samozrejmne v jine wlan.
Jaroslav Dolezal on 2.1.2013 11:44

IP telefon

Pekny clanek, vse fungluje tak jak ma pouze resime situaci kdy pocitac je zapojen do site prez Cisco IP telefon. Existuje varianta i pro tento provoz? Pocitac a telefon jsou samozrejmne v jine wlan.
Jaroslav Dolezal on 2.1.2013 11:58

IP telefon

Pekny clanek, vse fungluje tak jak ma pouze resime situaci kdy pocitac je zapojen do site prez Cisco IP telefon. Existuje varianta i pro tento provoz? Pocitac a telefon jsou samozrejmne v jine wlan.
Jaroslav Dolezal on 2.1.2013 12:36

IP telefon

Pekny clanek, vse fungluje tak jak ma pouze resime situaci kdy pocitac je zapojen do site prez Cisco IP telefon. Existuje varianta i pro tento provoz? Pocitac a telefon jsou samozrejmne v jine wlan.
Jaroslav Dolezal on 2.1.2013 13:50

Re: Zážitky s uživatelským 802.1x

pokud to mate v izolovane VLAN, tak je to od ostatnich siti oddeleno minimalne routerem, nebo nejspis i nejakym firewallem. tudiz tam proste 802.1x ani nepotrebujete. staci, kdyz si na tom firewallu nastavite takova omezeni, ze pres to bude fungovat pouze ta telefonie a je to.

jedine, co by mohlo "neautorizovane" zarizeni, ktere by nekdo pripojil do te VoIP VLAN udelat je, ze by odposlouchavalo telefonaty.
ondass on 2.1.2013 14:47

IP telefon

Pekny clanek, vse fungluje tak jak ma pouze resime situaci kdy pocitac je zapojen do site prez Cisco IP telefon. Existuje varianta i pro tento provoz? Pocitac a telefon jsou samozrejmne v jine wlan.
Jaroslav Dolezal on 2.1.2013 15:16

Re: Zážitky s uživatelským 802.1x

Dekuji a omlouvam se za nekolikanasobny post. Kolega problem telefonu vyresil na sitovem prvku tudiz neni treba resit zadny MAC bypass pro telefon ktery je mezi pocitacem a sit. prvkem.
Jaroslav Dolezal on 4.1.2013 18:47

Non Domain Boxes

ja by som iba doplnil, ze ked testujete pripajanie non domain joned machines na zaklade computer certifikatu, tak je nutne:
- pre kazdy computer certifikat s unikatnym menom vytvorit AD computer object
- pre kazdy takyto novy komputer object nastavit SPN v tvare host/computer.domain.com

v opacnom pripade pri zapnutom audite bude vidno hlasky failed audit, kde reason bude non existing user.
Martin Matuska on 22.4.2016 9:00

Získání user certifikátu při prvním přihlášení.

Dobrý den, Váš článek mi pomohl k nastavení ověření 802.1x. Funguje mi to dle mých představ.

Ale chtěl bych Vám popsat situaci, se kterou si zatím nevím rady.
Ověřování mám nastavené na user or computer.

PC/NB je členem domény a mám ho ověřovaný jako stanici vůči serveru. Když ho tedy spustím dostane ze switche na základě ověření přiřazenou VLAN 60. Když se přihlásím jako uživatel, který již byl alespoň jednou přihlášen (dostal tedy certifikát na USER), tak se po přihlášení dostane VLAN 20 (dle skupiny která má 20). Problém nastává když se přihlásí uživatel poprvé na PC který je členem domény. V mmc nevidím jeho USER certifikát a v eventlogu píše, že když chce získat certifikát, tak RPC je nedostupný.

Chápu správně že:
1. při zapnutí PC se ověří certifikátem pro stanici (dostane IP s přístupem na AD)
2. při přihlášení uživatele (který se už přihlásil na nekontrolovaném portu a korektně si "stáhl" certifikát) se ověří certifikátem pro uživatele
3. při přihlášení uživatele "poprvé" se mu spojení přes port switche blokne -> vytvoří se sice profil -> ale "nestihne" stáhnout certifikát pro uživatele a tudíž ho nemá jak ověřit


Jiří Tománek on 12.1.2017 13:06

Získání user certifikátu při prvním přihlášení.

Dobrý den, Váš článek mi pomohl k nastavení ověření 802.1x. Funguje mi to dle mých představ.

Ale chtěl bych Vám popsat situaci, se kterou si zatím nevím rady.
Ověřování mám nastavené na user or computer.

PC/NB je členem domény a mám ho ověřovaný jako stanici vůči serveru. Když ho tedy spustím dostane ze switche na základě ověření přiřazenou VLAN 60. Když se přihlásím jako uživatel, který již byl alespoň jednou přihlášen (dostal tedy certifikát na USER), tak se po přihlášení dostane VLAN 20 (dle skupiny která má 20). Problém nastává když se přihlásí uživatel poprvé na PC který je členem domény. V mmc nevidím jeho USER certifikát a v eventlogu píše, že když chce získat certifikát, tak RPC je nedostupný.

Chápu správně že:
1. při zapnutí PC se ověří certifikátem pro stanici (dostane IP s přístupem na AD)
2. při přihlášení uživatele (který se už přihlásil na nekontrolovaném portu a korektně si "stáhl" certifikát) se ověří certifikátem pro uživatele
3. při přihlášení uživatele "poprvé" se mu spojení přes port switche blokne -> vytvoří se sice profil -> ale "nestihne" stáhnout certifikát pro uživatele a tudíž ho nemá jak ověřit


Jiří Tománek on 12.1.2017 16:17

switch

Píšete, že všechny switche musí být spravovatelné, jinak nedojde k ověření. Takže pokud si někdo přinese obyčejný switch a připojí se přes něj, tak se pak dostane všude?
Daniel Bičík on 22.5.2018 20:19

Re: Zážitky s uživatelským 802.1x

nene, pokud je port na spravovaném označen, že vyžaduje ověrení, tak se do něho nedá připojit něco, co ověření neumí. takže do ověřovaného portu obyčejný switch nedáte. to co jsem myslel je připad, když tam máte vlastní neomenedžované swiště a na nich to prostě musíte povolit bez ověření.
ondass on 22.5.2018 20:28

Add Comment

Title


Pole Title nemusíte vyplňovat, doplní se to samo na stejnou hodnotu jako je nadpis článku.

Author *


Pole Author nesmí být stejné jako pole Title! Mám to tu jako ochranu proti spamu. Roboti to nevyplní dobře :-)

Body *


Type number two as digit *


Semhle vyplňte číslici dvě. Předchozí antispemové pole nefunguje úplně dokonale, zdá se, že jsou i spamery, které pochopily, že je občas potřeba vyplnit autora :-)

Email


Emailová adresa, pokud na ni chcete ode mě dostat odpověď. Nikdo jiný než já vaši emailovou adresu neuvidí.

Attachments