Kerberos, část 2 – popis metody SSO a protokolu Kerberos

Vítejte u druhé části seriálu, který se věnuje protokolu Kerberos se zaměřením na Single Sign-On (SSO) v prostředí Microsoft Active Directory.

V minulém díle jsme si popsali Microsoft prostředí a termíny, které budeme využívat při popisu protokolu Kerberos a jeho navázání na Active Directory Domain Services. Dnes začneme tím, že se pokusíme objasnit, co znamená termín Single Sign-On. Dále si obecně popíšeme Kerberos a jeho vlastnosti a budeme se věnovat všem hlavním prvkům a termínům, z kterých se Kerberos protokol skládá.

Koho zajímá pouze hrubý princip Kerberos autentizace (SSO), tak může počkat na příští díl, kde si jej popíšeme zjednodušeně i detailně. Ale pokud chceme hlubší porozumění, tak je potřeba rozumět jednotlivým detailům, kterým se věnujeme dnes.

Co je to SSO?

Běžně užívaná zkratka SSO pochází z názvu Single Sign-On, česky se používá označení jednotné přihlašování, ale já preferuji anglický termín. Jde o metodu, kdy zadáme svoje přihlašovací údaje pouze jednou, a autentizace k dalším službám proběhne bez našeho zásahu (a zadání přihlašovacích dat). Správa našich údajů se provádí na centrálním místě (serveru) a na něm se autentizujeme. Často je SSO spojováno s centrální správou uživatelských údajů (Identity Management), což nám zajistí společné uživatelské jméno, heslo (či alternativní autentizaci jako je certifikát) a další údaje (třeba email a adresu) pro různé služby. Pokud dojde ke změně nějakého údaje, tak je měníme na jednom místě a projeví se to pro všechny služby, které využíváme.

Nejen, že jde o pohodlné řešení, ale také zvyšuje bezpečnost. Přihlašovací údaje se vůbec nedostanou na službu, ověřujeme se na centrálním místě a službě pouze předáme důvěryhodnou informaci. Takže také pro aplikaci není důležité, jakou metodou došlo k autentizaci uživatele. Nemusí docházet k přímé komunikaci mezi službou a autentizačním serverem, s tím komunikuje klient. Samozřejmě to znamená i nebezpečí, pokud by bylo napadeno centrální místo, tak získá útočník přístup k různým systémům.

SSO se dá prakticky realizovat různým způsobem. Každá metoda přináší určité výhody i nevýhody.

Kerberos SSO

V tomto seriálu se budeme věnovat rozšířené metodě SSO a to využití protokolu Kerberos. Naše zaměření bude speciálně na Kerberos v podání firmy Microsoft, což znamená doménové prostředí. V tomto případě provádí autentizaci služba KDC, která běží na všech doménových řadičích (DC). Klient tedy při využití SSO musí mít dostupný DC. Tuto službu asi nebudeme publikovat do internetu, takže je SSO omezeno na využití v interní síti. Na druhou stranu je možno nastavit důvěryhodnost s jinými doménami (pokud máme zajištěnu síťovou komunikaci, třeba pomocí VPN) a pak SSO funguje i mezi doménami.

Služba, ke které se chceme připojit, může běžet na Windows serveru/stanici, který je i není zařazen do domény. Stejně tak může být na Linuxu. Není ani nutné, aby se služba nacházela v lokální síti, může být v rámci internetu či jiné sítě.

Pokud jsme členem domény, tak si možná ani neuvědomujeme, že k SSO dochází velice často. Na začátku se přihlásíme do domény (při autentizaci do počítače) a při přístupu k dalším službám (které mají SSO nastavené) dojde automaticky k přihlášení. To nastává pokaždé, když použijeme síťovou tiskárnu, sdílený disk, připojíme se Outlookem k Exchange serveru či řadě dalších síťových služeb. Aniž bychom něco zaznamenali, tak na pozadí dojde k naší autentizace (a následně autorizaci) pomocí SSO. Většinou pokud neprojde autorizace (nemáme práva k dané službě), tak se zobrazí přihlašovací dialog a můžeme použít jiný účet.

Kerberos autentizace využívá vždy přihlášení k nějaké službě a v takovém případě se vždy využívá princip Single Sign-On.

SSO pro web

V internetu se SSO nejvíce využívá pro webové aplikace. V rámci interní sítě nám pro webové servery funguje Kerberos SSO, ale klient se musí nacházet uvnitř interní sítě. To se nehodí pro domácí uživatele, kteří nejsou součástí domény. A je to často problém i pro firemní použití.

Proto existují dva způsoby řešení. Ve firemním prostředí se využije speciální server Identity Provider, který nabízí služby prokázání identity do internetu. Interně provádí autentizaci uživatele vůči adresářové službě (třeba Active Directory). Znamená to tedy, že můžeme doménové účty využít k autentizaci ke službám v internetu (používá se třeba u hybridních cloudů). Často se využívá otevřený standard Security Assertion Markup Language (SAML a novější SAML2).

Druhá možnost je služba v internetu, která spravuje uživatelské účty a provádí autentizaci. Můžeme se tak do různých webů přihlásit jedním účtem (a v ideálním případě pomocí SSO). Něco takového využíváme například u Google, Facebooku či Microsoftu. Některé systémy z této oblasti jsou OpenAM (dříve OpenSSO) či WebAuth. Jednotná správa identit je OpenID nebo český projekt mojeID.

Praktické použití je takové, že při prvním přístupu k webové službě, která využívá jednotný účet, zadáme přihlašovací údaje. Získáme šifrovanou identitu a při přístupu k další službě již není třeba údaje zadat. Na počátku se ale musíme přihlásit k počítači, kde se využívá jiný účet.

Když jsme zmínili Cloud, tak pro firemní prostředí se využívá ještě jedna možnost. Účty z interního Active Directory se synchronizují (třeba MS DirSync) do Cloudového adresáře nebo se provádí federace (třeba MS Active Directory Federation Services). Uživatelské účty pak fungují v rámci daných Cloudových služeb. Příkladem je třeba Microsoft Office 365.

Protokol Kerberos

Kerberos je síťový autentizační protokol, který pracuje na základě tiketů (Tickets), aby umožnil komunikujícím stranám v nezabezpečené síti bezpečně prokázat svoji identitu. Na začátku zadáme svoje přihlašovací údaje a veškeré další ověřování funguje na principu SSO.

Protokol Kerberos vznikl již v osmdesátých letech dvacátého století na univerzitě Massachusetts Institute of Technology (MIT). Dodnes používaná verze 5 je zde od roku 1993, kdy byla definována v RFC 1510 - The Kerberos Network Authentication Service (V5). Tato norma byla v roce 2005 upravena a specifikována v RFC 4120 - The Kerberos Network Authentication Service (V5). V Microsoftím doménovém prostředí je Kerberos v5 výchozí autentizační protokol. Jako alternativa, či ve starších Windows (NT 4.0), se používá protokol NTLM (NT LAN Manager). Věci související s Kerberos protokolem jsou definovány v řadě dalších RFC norem.

Standardní Kerberos se využívá pro autentizaci, Microsoft jej rozšířil o autorizační údaje (posílá seznam skupin, kterých je uživatel členem, a případně další informace) pomocí Kerberos Protocol Extensions [MS-KILE]. Tyto údaje jsou uloženy v Privilege Attribute Certificate (PAC) Data Structure [MS-PAC].

Kerberos je hojně využíván (nejen v MS světě) díky svým vlastnostem:

  • uživatelské heslo ani jeho hash se nikdy nepřenáší v síti – vyměňují se šifrované tikety
  • využívá se symetrická kryptografie – jsou podporování různé šifry (jako DES, RC4, AES)
  • architektura je rozšiřitelná – umožňuje použít další či alternativní bezpečnostní metody (šifry, hashe)
  • podporuje vzájemnou autentizaci (mutual authentication) – volitelně se nemusí pouze autentizovat klient u služby, ale i služba klientovi
  • chrání proti odposlechu (eavesdropping) či opakovanému použití stejných rámců (replay attacks, ochrana pomocí časových známek)
  • umožňuje uživatelům přistupovat k různým službám bez zadání hesla = Single Sign-On
  • zjednodušuje administraci – účty jsou spravovány centrálně pro různé aplikace
  • funguje v modelu klient server a vyžaduje důvěryhodnou třetí stranu (KDC) – to je zároveň slabina, KDC musí stále běžet a musí být dobře zabezpečené
  • klient se neověřuje na serveru, ten vůbec nedostane uživatelovy credentials, ověření provádí KDC a odesílá šifrovaně uživatelovo jméno (to může rozšifrovat jen server)
  • podporuje impersonation – uživatel přímo nepřistupuje ke zdrojům, místo něj přistupuje systém
  • podporuje delegation of authentication (pomocí proxy ticket, forwarded ticket, protocol transition a constrained delegation) – umožňuje službě běžící pod nějakým účtem převzít uživatelovu identitu a přihlásit se k jiné službě (například uživatel se přihlásí k aplikačnímu serveru, ten se musí přihlásit k DB, ale potřebuje to provést pod oprávněním uživatele)

Kerberos protokol je považován za bezpečný, chrání proti řadě různých útoků či zneužití. Ze svého principu (jako je používání dočasných tiketů a šifrování různými klíči) a účelu (umožnit bezpečné ověření v nezabezpečené síti) jde o ochranu při komunikaci v síti. Zůstávají tedy místa, kde může dojít k zneužití. Jedním bodem je uživatelské heslo, pokud je zvoleno slabé heslo a útočník jej může odhadnout/získat, tak bezpečnost vlastního protokolu nezabrání zneužití účtu. Pro zvýšení bezpečnosti je možné použít čipovou kartu a autentizaci certifikátem. Druhé nebezpečí je napadení stanice, z které se uživatel přihlašuje. V paměti je dočasně uložen Secret Key, což je vlastně heslo uživatele.

Jméno protokolu vzniklo podle řecké mytologie, kde Kerberos je tříhlavý pes chránící vchod do podsvětí. To proto, že komunikace se účastní tři strany:

  • uživatel – klient, který chce přistoupit k nějaké síťové službě
  • server – přesněji řečeno služba, na kterou chce uživatel přistoupit
  • Key Distribution Center (KDC) – důvěryhodná třetí strana, která provádí ověřování, je součástí doménového řadiče (DC) a obsahuje dvě nezávislé služby - Authentication Service (AS) a Ticket-Granting Service (TGS).
Klepněte pro větší obrázek

Kerberos V5 standardně využívá TCP(/UDP) port 88. Je plně integrován v Active Directory, serverovém i klientském OS od Windows 2000, a řadě síťových protokolů, jako je CIFS/SMB, HTTP, RPC, tiskové služby, DFS, IPsec, apod. Kerberos je závislý na řadě služeb, jde o Active Directory Domain (nefunguje pro lokální účty), TCP/IP síť, DNS (Domain Name System), časové synchronizaci (Time Service) a SPN (Service Principal Names).

Hlavní termíny Kerberos protokolu

Nejprve si vysvětlíme důležité pojmy a používané principy, které hrají roli u Kerberos autentizace. Pomocí nich si následně popíšeme princip ověřování.

Cryptography (kryptografie - šifrování)

Kerberos protokol je postaven na šifrování, proto si na začátku velmi stručně zmíníme hlavní termíny. Kryptografie se používá pro dosažení různých cílů. Jde o Confidentiality (důvěrnost, ochrana proti čtení dat), Data integrity (ochrana dat před změnou), Authentication (ověření, že data pochází od dané strany), Non-repudiation (neodmítnutelnost).

  • Encryption (šifrování) – transformace dat (plaintext) za účelem jejich zabezpečení (ciphertext), takže pouze ten, kdo zná klíč, je může rozšifrovat, existuje šifrování se symetrickým klíčem, kde je stejný klíč pro šifrování i dešifrování, a šifrování s veřejným klíčem, kde šifrovací klíč je veřejně známý, takže každý může data zašifrovat, ale dešifrovat je může pouze majitel privátního klíče, příklad šifer je SSL, PGP, AES, DES, 3DES
  • Hashing (hašování) – funkce, která z různě dlouhých vstupních dat vytváří kratší výstup pevné délky (hash), stejný vstup má vždy stejný hash, různé vstupy mají různý výstup, z výstupu nelze získat vstupní data, pokud dojde ke změně vstupu, tak se výrazně změní hash (využívá se pro zajištění integrity dat, kdy se k datům vytvoří kontrolní součet), příklad Hash funkcí MD5, SHA, SHA2
  • Encoding (kódování) – transformace dat do jiného formátu (aby se mohli lépe zpracovávat), proces je veřejně známý a může být obrácen, příklad kódování je Base64

Key Distribution Center (KDC)

KDC je server, který autentizuje klienta a vystavuje tikety. Jde o centralizovanou důvěryhodnou třetí stranu v Kerberos komunikaci. U MS je součástí každého doménového řadiče (DC) a obsahuje dvě nezávislé služby (které se obě nachází na DC):

  • Authentication Service (AS) – provádí autentizaci uživatele a odesílá mu TGT
  • Ticket-Granting Service (TGS) – na základě TGT ověří uživatele a odesílá Service Ticket pro požadovanou službu

KDC přistupuje k Active Directory informacím o účtech, včetně hesel (hashů). Pro ověření se uživatelské heslo využívá pouze k získání TGT, a ani v této fázi se neposílá po síti, dále se již využívá TGT.

Secret Key – tajný klíč

Tajný klíč slouží k ověření uživatele pomocí šifrování/dešifrování komunikace, sdílí jej mezi sebou Principal (klient či služba) a KDC. Používá se několik označení, asi nejčastější je Secret Key, další je Shared Secret Key (sdílený tajný klíč) či obecně Encryption Key (šifrovací klíč). Secret Key vznikne z textového hesla, ke kterému se přidá sůl (Salt), což je Principal Name včetně Realmu (to zajistí, aby ani uživatelé se stejným heslem, neměli stejný klíč). Tento řetězec zpracuje funkce string-to-key (string2Key), která provede jednosměrnou hashovací funkci (nelze zpět získat heslo), a výsledkem je klíč.

Princip ověření je takový, že tajemství je známo pouze dvěma stranám (uživatel a KDC). Každá strana může ověřit tu druhou tak, že druhá strana zná stejné tajemství. Aby se ověřilo, že druhá strana zná tajemství, tak Kerberos využívá Secret Key Cryptography (šifrování pomocí klíče). Jedna strana zašifruje zprávu pomocí klíče, pokud ji druhá dokáže rozšifrovat, tak musí znát klíč (tajemství). Využívá se symetrické šifrování (stejný klíč dokáže data zašifrovat i rozšifrovat).

Termín Secret Key nejčastěji používáme pro klíč uživatele, ale šifrovacích klíčů se používá více:

  • dlouhodobé symetrické klíče (Long-Term Symmetric Keys) – vytváří se z hesla, textové heslo se pomocí šifrovací funkce (například DES-CBC-MD5) transformuje na klíč. Patří sem User key (uživatel, heslo je zadáno v AD a na stanici se zadá při přihlášení), System key (když se počítač zařadí do domény, tak dostane heslo, z něj se vytvoří klíč), Service key (služby získají klíč z hesla účtu, který používají pro přihlášení), Inter-realm keys (pro autentizaci mezi doménami - cross-realm authentication, kde je vytvořen vztah důvěry)
  • dlouhodobé asymetrické klíče (Long-Term Asymmetric Keys) – veřejný klíč pro autentizaci certifikátem ze Smartcard
  • krátkodobé symetrické klíče (Short-Term Symmetric Keys) - Session Key pro šifrování komunikace mezi KDC a klientem nebo službou a klientem, KDC si jej neukládá, protože klient jej vždy pošle v šifrovaném tiketu

Tiket (ticket)

Tiket představuje Kerberos credentials, jde o záznam (uložený v paměti či v souboru na disku), který může být použit pro ověření identity. Tickety jsou základem autentizace v Kerberosu, kdy se po síti neposílají hesla, ale pouze šifrované tickety. Obsahuje identitu klienta, Session Key, časovou známku a další informace. Šifruje se pomocí serverového Secret Key.

Pro žádost a doručení tiketů se používají Kerberos zprávy (pakety). V žádosti (request) se posílá požadovaná (podporovaná) šifrovací metoda a požadované vlastnosti (flags). Na klientovi se tikety ukládají do vyrovnávací paměti (volatile memory space, ne na disk), takže se mohou použít opakovaně. Mají určitou dobu platnosti. Používáme dva typy tiketů:

  • Ticket-Granting Ticket (TGT) – jde o speciální Service Ticket pro službu KDC (krbtgt), zařizuje bezpečné předání uživatelových credentials z AS na TGS, můžeme říci, že slouží k autentizaci uživatele, je šifrovaný pomocí KDC Secret Key (klient nemůže rozšifrovat), obsahuje údaje o klientovi, příznaky (flags), časové razítko, případné další údaje a Session Key (při použití TGT nemusí KDC hledat Secret Key klienta, ale rozšifruje si Session Key a ten použije), defaultní platnost je 10 hodin, může se provádět obnova (renew) bez potřeby zadat heslo, Microsoft rozšířil standardní tiket o autorizační data, takže je zde také SID uživatele a SIDy bezpečnostních skupin, kterých je členem
  • Service Ticket – zařídí, aby se uživatelovy credentials bezpečně dostaly z TGS ke službě, slouží tedy k autentizaci uživatele u služby, obsahuje nešifrovaně SPN služby a šifrovaně pomocí Secret Key služby (takže klient nemůže rozšifrovat) údaje o klientovi (může zde být i adresa), dobu platnosti a Session Key pro komunikaci klienta a služby, Microsoft rozšířil standardní tiket o autorizační data, takže je zde také SID uživatele a SIDy bezpečnostních skupin, kterých je členem

Níže je příklad Service Ticketu, jak si jej můžeme vypsat na klientovi.

C:\>klist
Current LogonId is 0:0x4c2b5
Cached Tickets: (10)

#2> Client: bouska @ FIRMA.LOCAL
Server: HTTP/www.firma.local @ FIRMA.LOCAL
KrbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
Start Time: 4/25/2014 12:53:44 (local)
End Time: 4/25/2014 22:18:52 (local)
Renew Time: 5/2/2014 12:18:52 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Cache Flags: 0
Kdc Called: dc.firma.local

Authenticator

Spolu s tiketem klient posílá i čerstvě generovaný Authenticator šifrovaný pomocí Session Key (ten je obsažen v tiketu). Služba může věřit, že tiket není podvržený, protože je šifrovaný jejím klíčem (který zná pouze KDC a ona). Nemá ale ověřeného odesílatele (protože vlastní tiket může být ukraden), proto se používá Authenticator.

Authenticator je šifrovaný klíčem (Session Key), který zná pouze správný klient a server. Obsahuje časovou známku, která se ověřuje, jestli není rovna nebo menší, než naposled přijatá časová známka od klienta (tím se zajistí, že authenticator není možno použít opakovaně). Také se kontroluje časová známka s časem na serveru a nesmí se lišit o víc než 5 minut (klient a server musí mít synchronizovaný čas). Dále obsahuje jméno a Realm klienta, kontrolní součet aplikačních dat a může zde být šifrovací klíč (který by se použil místo Session Key).

Pre-authentication

Použití před-autentizace zvyšuje bezpečnost přihlašovacího procesu. Při normálním průběhu klient žádá o TGT a v žádosti (KRG-AS-REQ) odesílá pouze svoje jméno a doménu. KDC nalezne uživatele a pomocí jeho Secret Key zašifruje Session Key, který mu pošle (spolu s TGT). Když klient nezná heslo (Secret Key), tak si nemůže rozšifrovat Session Key a tudíž dále komunikovat s KDC. Útočník by ale mohl poslat požadavek za jiného uživatele. A pak se pokusit provádět nějaké útoky hrubou silou na šifrovaný Session Key a tím by mohl zjistit heslo uživatele.

Proto se při Pre-authentication na požadavek KRG-AS-REQ odešle KRB-ERROR s hodnotou KRB5KDC_ERR_PREAUTH_REQUIRED. Na to klient odpoví novým KRG-AS-REQ paketem, kde do oblasti PADATA přidá časovou známku zašifrovanou pomocí uživatelova Secret Key. KDC rozšifruje časovou známku (tím ověřil uživatele) a ještě zkontroluje, jestli je čas v pořádku (stejně jako u Authenticator). Dále pokračuje běžným způsobem.

Pozn.: V Kerberos v5 je Pre-authentication volitelná, ale v Active Directory je defaultně vyžadována.

Realm - doména

Každá organizace, která chce provozovat Kerberos, si definuje svůj vlastní Realm. Jméno Realmu, v které je uživatel registrován, je součástí uživatelského jména. Může se navazovat vztah mezi Realmy, mohou být hierarchicky organizovány a nejčastěji se používá DNS zápis. V Microsoft prostředí je Kerberos Realm ekvivalentem pro Active Directory doménu. Kerberos Realm je závislý na velikosti znaků a standardně se používají velká písmena. KDC může vydávat tikety pouze pro svůj Realm. Příkladem Realmu je FIRMA.LOCAL.

Principal Name

Principal je unikátní identita (pojmenovaná entita klienta nebo serveru), které může Kerberos přiřadit tiket. Kerberos slouží k prokázání, že komunikující objekt byl u KDC registrován pod identitou, za kterou se vydává. Principal může mít řadu komponent, které se oddělují lomítkem /, ale nejčastější tvar je primary@REALM nebo primary/instance@REALM. Souvisí to s dříve popsanými UPN a SPN v Active Directory. Příkladem uživatelského Principal je bouska@FIRMA.LOCAL a Principal služby je HTTP/www.firma.local@FIRMA.LOCAL.

Pozn.: Principal se většinou používá včetně uvedení Realmu, ale není to podmínka.

Secure Channel

Je používán ve Windows, když se přenáší Secret Key (třeba když vytvoříme uživatele a zadáme jeho heslo), tak je přenos zabezpečen jiným Secret Key.

Kerberos zprávy (packety)

Kerberos protokol standardně komunikuje na TCP portu 88. Používá několik typů zpráv (Message Type), některé mohou být zabaleny v jiném protokolu. Podrobné informace o zprávách, tiketech, jejich obsahu a datových typech nalezneme ve specifikaci RFC 4120 - 5.Message Specifications.

Nejčastější zprávy spočívají ve výměně požadavku (Request) a odpovědi (Reply). První komunikace je mezi klientem a Kerberos serverem (tedy KDC). Pro získání TGT se komunikuje s Authentication Service (AS) a posílá se KRB-AS-REQ (10) a KRB-AS-REP (11). Pro získání Service Ticket se komunikuje s Ticket-Granting Service (TGS) a posílá se KRB-TGS-REQ (12) a KRB-TGS-REP (13).

Když se podíváme na obsah zpráv, tak požadavky mají dvě hlavní části. padata, což je zkratka pre-authentication data, zde mohou být informace potřebné pro zpracování nebo dešifrování. Třeba u KRB-TGS-REQ je zde Authentication Header (Ticket-Granting Ticket a Authenticator). A KDC-REQ-BODY, kde jsou vlastní data požadavku, třeba Client Name, Realm, Server Name (SPN). Odpověď může mít více částí, je zde třeba Client Name, Client Realm a Ticket, což je vlastní vystavený Ticket, v něm vidíme Server Name (SPN), Realm a šifrovanou část.

Klepněte pro větší obrázek

Pro autentizaci uživatele k aplikačnímu serveru komunikuje klient a server. Posílá se KRB-AP-REQ (14), který obsahuje hlavně tiket (Service Ticket) a authenticator. V ap-options může být příznak mutual-required a pak musí server odpovědět zprávou KRB-AP-REP (15) čímž autentizuje sebe u klienta. Objevit se může také zpráva KRB-ERROR (30) s nějakou chybovou informací. Existuje ještě několik dalších typů zpráv, ale ty se používají pro speciální případy.

Klepněte pro větší obrázek

Odkazy

Autor: Petr Bouška


 

 

Články ze série Microsoft TechNet nevytváří redakce Živě.cz, ale partneři programu Microsoft TechNet. Jsou publikovány v rámci mediálního partnerství Živě.cz a společnosti Microsoft.

Témata článku: Microsoft, MD5, SE, Strong, Kerberos, Ticket, Secret, Proto, Active, Single, Tools, Term, Five, Microsoft Office 365, Busy

Nejnovější komentáře

Můj názor
Určitě si přečtěte

Monitory do 10 tisíc: poradíme, jaké jsou teď nejlepší

Monitory do 10 tisíc: poradíme, jaké jsou teď nejlepší

** Dobrý monitor s kvalitním panelem lze pořídit pod tři tisíce korun ** Pod deset tisíc si můžete koupit pracovní 27" monitor nebo nejlevnější použitelné 4K ** Vybrali jsme také ideální model pro vícemonitorovou konfiguraci

27.  11.  2016 | Stanislav Janů | 13

Sbíječky vyměnili za klávesnice. Nový projekt má za cíl přeučit horníky na programátory

Sbíječky vyměnili za klávesnice. Nový projekt má za cíl přeučit horníky na programátory

** Programátorů je málo a horníků bez práce po uzavření dolu Paskov bude moc ** Problém řeší unikátní projekt ** Pilotní kurz dává naději, že by z horníků mohli být použitelní kodéři

28.  11.  2016 | David Polesný | 76