Alebo na SyncThingu založený SysvolSync: https://samba.tranquil.it/doc/en/samba_advanced_methods/samba_tis_sysvolsync.html
Ono v princípe nie je problém synchronizovať SYSVOL, pokiaľ máte iba Sambu. Problém by bol synchronizácia medzi Windows a Sambou.
Výhodu to má asi jedinou: je to nenáročné na zdroje a s tímhle postupem si snadno vytvoříte doménu na doma i na raspberry (pokud seženete) nebo třeba v LXC kontejneru na routeru s OpenWRT (pokud to utáhne) či na NASu (pokud máte - a nemá vlastní řešení)..
Doména dost usnadní správu těch pár uživatelů na několika domácích strojích - synchronizace hesel, správa profilů, nastavení oprávnění.,,
Na provoz ve firmě (byť malé) bych to asi velmi nedoporučil
.
No, pokud jsi tak zarytý antimicrosoft, pak ano. Ale většina ostatních chápe, že prostě Windows server je někde úplně jinde.
Komu vadí prostředky, proč nenainstalovat verzi Core (bez GUI) a ovládat vzdáleně?
Licence? Malá firma určitě má nějakých 20000 na nový server a součástí pak může být Windows server Essential, kde není nutné platit CAL. A pokud firma nemá, pak nepotřeuje určitě doménu, ale stačí jí NASka.
A velká firma určitě má i na ty CALy, to je sice nákladově vyšší částka (jednorázově), ale jednou za cca 6-8 let (vždy ob jednu verzi WIndows srv stačí).
Ne, Samba skutečně není vhodná pro větší firmu jako PDC.
BTW: Linux jako člen AD a následně sdílení složek, to je jiná. Dokonce to lze ovládat konzolou Windows serveru. Jen to občas dělá "něco divného" a hledání je celkem peklo. Třeba, najednou špatně čte skupiny Windows ...
Resumé. Samba jako AD ve firmě za mě rozhodně ne.
Ehm... Nechci debatovat o smyslu volby mezi MS řešením a Sambou, ale vaše jistota, že velká "firma" má na CALy mě nutí zmínit, že třeba na naší škole s 80 kantory (nepočítaje v to administrativní pracovníky) a cca 850 žáky je cena za CALy dlouhodobý problém, který se lepí v každém projektu, kde na to vyzbyde nějaká použitelná částka. A těch cca 1000 uživatelů už imho není málo.
Jinak řečeno cena licencí může být velmi dobrou motivací a pokud se k tomu přidá HW náročnost a postupné vyhnívání instalace (zřetelné zpomalování výkonu) samotných Windows oproti výkonnostně stabilnímu Linuxu, myslím, že za odladěné a odzkoušené out-of-box řešení pro školy by celá řada škol byla vděčná. Byť to naráží na značnou nepružnost velké části pedagogů - např. minulý týden si kolega stěžoval, že ty "nové" Office 2013 nechce, že mu to špatně otevírá jeho připravené písemky do matematiky a že chce pátky Office 2003, kde mu ten 20 let starý editor rovnic fungoval...
Promiňte, ale školy můžou mít servery z programu Select, kde se žádné CALy neplatí. Jsou dnes dražší, licence bývala za ~5 tisíc, dnes asi za ~10, ale pořád, žádné CALy.
Pro výuku pak můžete mít Azure Dev (dříve MSDN Academic Alliance), bývalo to za ~700€, ak za $500 a teď už asi druhý rok je to zdarma. Tyto licence ale nelze použít pro infrastrukturu školy.
4. 4. 2022, 07:59 editováno autorem komentáře
No neznám detaily volby toho, proč nejsme v Select, ale každopádně "Tyto licence ale nelze použít pro infrastrukturu školy." asi vysvětluje, že taková licence ja prakticky nepoužitelná...
Jinak řečeno trvá můj argument, že třeba pro školství by alternativa domény přes Sambu mohla být zajímavá, pokud by existovalo odzkoušené a snadno nasaditelné řešení (což momentálně neexistuje).
Licence Azure Dev Tools for Teaching nelze použít pro infrastrukturu školy. Ty jsou pro výuku a nyní asi druhý rok už zcela zdarma.
Program MS Select je pro školy, státní správu a zdravotnictví (ceny se liší podle typu organizace) a ty licence samozřejmě pro infrastrukturu použitelné jsou.
Pro jistotu ještě jednou: Azure Dev Tools for Teaching (dříve MSDN Academic Alliance) je něco jiného, než MS Select.
Pro školu ale může mít význam obojí: to první pro výuku (systémy, servery, vývojové prostředí), to druhé pro infrastrukturu. To první zdarma, to druhé za peníze, ale dost nízké.
V tom případě nerozumím tomu, proč kupujete User CAL místo Device CAL...
Nebo snad máte víc zařízení, než uživatelů? Zrovna ve škole bych se tomu docela divil.
Zatím ve všech školách, kde jsem s tím licenčním humusem přišel do styku měli koupené Device CALy - naposledy škola 450 žáků, 30 učitelů a vše je pokryté 107 Device CALy, jeden tuším v SELECTu za 265 Kč
V praxi se obvykle neřeší otázka, jestli použít Windows nebo Linux server pro Active Directory. Řekl bych, že naprostá většina "větších" instalací používá Windows. Otázkou spíš bývá, zda v menších firmách pro tyto účely použít NAS. Tam tyto služby bývají integrovány do snadno použitelného balíku. Já mám zkušenosti se Synology NAS, ale jiní výrobci k tomu asi přistupují podobně. Základní idea je, že si koupíte NAS, zadáte tam pár základních údajů a máte plnohodnotnou podnikovou síť včetně cloudových řešení. V praxi to tak jednoduché není, ale vývoj tím směrem jde.
Abych nemátl čtenáře: Pokud máte zkušenosti s administrováním linuxových systémů jako root, pak použití NAS není tak přímočaré, jak by se mohlo zdát. Sice tam běží Linux, Samba, ... ale od administrátora se neočekává použití konta root. Je třeba se seznámit s všelijakými omezeními, jejichž smyslem je učinit ten systém alespoň částečně blbovzdorný.
Souhlasím, že pro nasazení v roli "vše v jednom" je NAS zavádějící název. Důležité vlastnosti pro nasazení v menších firmách ale byly implementovány před pár lety, tohle není záležitost dvaceti let. Mám na mysli zejména snapshoty v btrfs. Ve firmách a v domácnostech určitě stále převažuje nasazení v roli network attached storage.
Bezpečnostní expert nejsem. Můj laický názor dlouholetého administrátora unixových systémů je, že když se uživatel bude držet několika málo postupů doporučovaných Synology, tak ten systém poměrně bezpečný je. Pokud ale uživatel začne experimentovat se spouštění všelijakých služeb aniž by věděl, co vlastně dělají, a začne nastavovat oprávnění, aniž by měl přehled o celém bezpečnostním modelu, tak to skončí děravým systémem.
Synology má placený Security Bug Bounty Program. Ten se ale nevztahuje na chybná nastavení uživatelem.
A to je právě ten problém, sám řikáš, že se bezpečností nezabýváš a zároveň tvrdíš, že to je bezpečné. Není. Pár týdnů starý problém Synology, plně aktualizovaný bez doplňků a ve výchozím nastavení, CVE-2021-44142, stačí připojený disk přes Sambu a klient je schopný na tom získat roota, tj. stačí napadený jeden z počítačů v sítí, který má právo na zápis do NAS a útočník má plnou kontrolu nad NASem. Zachyceno v terénu, tj. už se to používalo a šířilo. Teď si představ, že takovýhle problémy mají několikrát do roka (2021 - CVE-2021-29089, 2020 - CVE-2020-1472).
Když už krabičku, tak třeba QNAP, který umí přistupovat k problémům odpovědně, ale zase tam nemá ty fancy nástroje.
Nepsal jsem, že je to bezpečné. Psal jsem, že je to poměrně bezpečné. Z pohledu administrátora se to chová, jak se to chovat má: updaty jsou Synology vydávány a uživatel od NASu dostává e-mail s upozorněním, že update je k dispozici a je třeba ho nainstalovat.
Pokud se vaše výtka týká toho, že mezi zveřejněním opravy a vydáním updatu proběhne delší doba než u jiných výrobců, tak to je možné, tohle nesleduji. Pokud takové přehledy máte, tak se s nimi podělte.
Já jsem našel srovnání mezi výrobci zde: https://nascompares.com/security-advisories/ . Tam se ale jen odkazují na https://www.synology.com/en-global/security/advisory a https://www.qnap.com/en-uk/security-advisories . Doba trvání opravy tam není.
Nemám důvod NAS od Synology nijak přikrášlovat. Nejsem jejich prodejcem. Píšu o tom NASu, protože ho mám doma několik let. Kdybych měl NAS od QNAPu, tak bych psal o něm.
Jinak z meho pohledu dve veci, co jsou v clanku podivne:
1]
Provedeme změnu jména počítače na plné jméno včetně domény. Nejdříve musíme zrušit ochranu změny hesla. V souboru /etc/cloud/cloud.cfg:
-> Co ma heslo spolecneho s jmenem stroje?
2]
Do souboru /etc/hostname zapíšeme celé jméno našeho serveru, nastavte podle vlastních údajů:
Domena.domov.test
--> je skutecne vhodne tam davat fqdn, kdyz je to primarne urcene pro hostname?
Nevim, jake problemy u bodu 2] mate, ale neni ten problem skutecne nekde jinde? Mam sambu na 3 serverech jako AD a nikdy jsem nemel problem s pripojovanim Win klientu (a to jsem to provozoval uz od debian8).
Jestli to nesouvisi treba s tim, ze v /etc/hosts pouzivate jen fqdn, ale neuvedete tam uz hostname. Nebo je to nejake specifikum ubuntu...kdovi.
Možná by mohl autor všechny věci ladit "ponovu" (tak jako třeba síť přes netplan), tedy ne např hostname přes editaci /etc/hostname (zkusit `hostnamectl`), to samé resolvconf.
Ano systemd je dle mě "zlo" (imho), ale tím, že si config rozehaharáte něčím mimo systemd si dobudnoucna zaděláváte na problémy.
Buď si zvolit systemd-less distro a dělat vše oldschoolově, nebo pak použít ubuntu a tedy doučit se systemd ekvivalenty.
Asi to funguje, ale tento setup zdá se mi krapet nešťastný.
IMHO to tak úplně vhodné není, ale v tom článku je to odladěná konfigurace. Pokud by to člověk chtěl mít podle zvyklostí, asi by byla potřeba ty konfiguráky trochu ohnout,
Už jsem takové řešení kdysi používal a moc dobře si pamatuji, že zdat FQDN do hostname bylo nejlevnější řešení a člověk se s tím tak nějak vnitřně smířil.
Sice to nemám nijak nastudované, ale tuším problém v tom, jak MS chápe jméno/"windows" doménu/"dns" doménu - v podstatě pozůstatky po hosts a lmhosts souborech už zdob Windows 3.11.. Tenkrát se ta řešení teprve utvářela a MS šel vlastní cestou; v AD na Windows NT se to nějak sjednotilo - pokud to šlo.
Ja myslim ze ten dotaz dava velkej smysl. Podle me mix OS velmi "hrozi", zejmena kdyz si lidi prinesou svoje zarizeni, coz se podle me stane. Tj. je tady najednou android (uz pry maji nejake firemni profily v posl. verzich), windows, linux, macOS, iOS. Tohle tema me hodne zajima, protoze me hrozi ze na gymplu budu potrebovat resit centralni spravu tech zarizeni. Windows Server to podle me nevyresi - jednak na nej skola nema penize, a jednak resi jen windows stanice. Takze jsem se dival po SW jako Puppet, Ansible ap. Nedava to vetsi smysl?
Ale tak se preci s AD nepracuje. Asi nebudete neci soukrome stroje a prostredky pripojovat do AD a nebudete tak umoznovat nezajistenym strojum pristup k firemnim prostredkum. To je zasadni nabourani bezpecnosti firmy. Tohle se resi jinak. Autorizace se udeli na zklade uzivatelske autentizace s pristupem k zprostredkovatelskym sluzbam v DMZ. Nikoli se vstupem primo do interni site. Zadny profil proto neni na zarizeni s jakymkoli OS potreba.
Co vim, tak android ma pracovni profil pouze ve spojeni s Google Workspace (drive Google Apps nebo G Suite). U BYOD si clovek v nastaveni proste prida dalsi Google profil. Spravce mu zarizeni schvali v admin konzoli a uzivateli se vytvorit tzv. "Pracovni profil" (pozor pracovni profil, je mozny az u vyssi verze MDM - ta jde zakoupit zvlast nebo je v ramci workspace planu Business Plus - u skolnich organizaci nevim jak to je). Tento pracovni profil je naprosto oddeleny od soukromeho a to az tak ze pokud chcete treba zalohovat fotky do firemniho Google Photos, tak je musite vyfotil aplikaci fotaku v pracovnim profilu. Vsechny aplikace ktere tedy chcete pouzivat jak v pracovnim tak v soukromem profilu mate zduplikovany, ale podle uloziste je APK sdilene, jen jejich ulozny prostor je oddeleny dle profilu.
Cele Google Workspace jde pak napojit na AD at uz MSAD nebo treba LDAP.
Nevidim v tom zadny problem. Google toto ma pekne podchycene a zarizeni se daji krasne omezit. Jako bonus jim muzete prednastavit SSID a hesla WiFi siti, predinstalovat aplikace nebo jim dovolit instalovat aplikace jen ze seznamu, tak aby si do pracovniho profilu nenainstalovali zavirovane hry apod. My konkretne fungujeme tak, ze ten kdo ma firemni telefon, tak ma jako hlavni G ucet prihlaseny ten firemni(vsichni pak maji druhy soukromy telefon). Ten kdo nema, tak jede v rezimu BYOD a ma pracovni profil.
Google Workspace MDM resp. zprava koncovych zarizeni navic podporuje i Windows, iOS a ChromeOS. Na windows muzete treba instalovat aplikace podobne jako u MSAD za pomoci Group policies - akorat teda dost nepohodlne. Nebo treba umoznit prihlaseni do windows pomoci google uctu. U iOS muzete vse spravovat prakticky skoro stejne jako u Androidu, akorat je potreba nejakej Appli certifikat pro spravu zarizeni(coz samozrejme stoji nemale penize), ale osobni zkusenost nemam protoze u nas ma iOS pouze jeden clovek a kvuli nemu do toho nebudeme investovat.
Spíš jsem ten dotaz myslel tak, jak funguje admin když má ve správě mix OS. Nemyslím tím cizí přístroje. Např. jak funguje sw firma když má různé programátory s různými OS na desktopu. To prostě funguje tak že nemá centrální správu a každý si zodpovídá za svoje PC ?
31. 3. 2022, 15:07 editováno autorem komentáře
> Podle me mix OS velmi "hrozi", zejmena kdyz si lidi prinesou
> svoje zarizeni, coz se podle me stane.
Tahle situace je běžná na univerzitách. Zkuste získat tipy od někoho, kdo tam do IT vidí.
Jako obyčejný uživatel, který si oprašuje vlastní linuxové pracovní stanice a PC clustery, jen uvedu, že svá zařízení smí studenti připojit jen přes Eduroam WiFi, kterou od interní unverzitní sítě odděluje firewall, který povoluje přístup jen k některým službám.
U zaměstnanců je to složitější. Pokud získáte důvěru lidí odpovědných za bezpečnost, tak můžete vlastní zařízení napojit na interní síť kabelem. Musíte se ale o to zařízení starat a v případě bezpečnostního incidentu si vás náležitě podají. Pro lidi z podnikové sféry to asi zní divně, ale bez tohoto přístupu by se těžko dělal vědecký výzkum.
Co se zařízení vlastněných univerzitou týče, tak podporovány jsou Windows, MacOS, iOS, Linux a Android. Software pro jejich centralizovanou správu neznám.
Re: "Pokud získáte důvěru lidí odpovědných za bezpečnost, tak můžete vlastní zařízení napojit na interní síť kabelem."
A není rozdělování zabezpečení přístupu k službám z LAN a WAN už trochu přežitek? Tím nemyslím vystavovat porty LAN služeb na veřejce, nebo jet na firewallu brány INPUT policy ACCEPT, ale spíš řešit zabezpečení každé služby bez ohledu na přístup z LAN / WAN.
Přijde mi že, omezovat připojení osobních zařízení uživatelů do sítě není efektivní, stejně jako není realistický předpoklad, že zařízení v LAN budou bezpečná.
Primárním cílem Eduroamu je poskytnout WiFi připojení uživatelům registrovaným v této celosvětové infrastruktuře. Například student nebo zaměstnanec ČVUT se může připojit na Eduroam WiFi na víceméně kterékoliv evropské univerzitě pod svým kontem z ČVUT. Přístup je možný i některých letištích, nádražích, ... Omezení přístupu z Eduroamu do lokální sítě se ze zřejmých důvodů používá, ale je to spíš vedlejší efekt než primární metoda řešení bezpečnosti.
Pokud povolíte připojení přinesených zařízení do interní sítě, tak budete dřív či později řešit problémy s útoky nebo spamováním z těchto zařízení kvůli malware.
Porty pro ssh (a řada dalších) jsou Eduroamem blokovány. Pokud se chcete na počítače v interní síti dostat přes Eduroam, tak se do té interní sítě napřed musíte přihlásit přes VPN klienta. (Používali jsme Cisco, ale nedávno jsme kvůli ceně přešli na FortiClient.)
Univerzitní sítě bývají poměrně otevřené. Já jsem se mohl na své počítače připojit z domova přes ssh bez použití VPN. Teď to kvůli válce na Ukrajině zablokovali, přístup do interní sítě je jen přes VPN.
Univerzity mívají desítky tisíc studentů a tisíce zaměstnanců. Nedivil bych se, kdyby IT oddělení muselo systémy na centralizovanou správu kupovat na základě výběrových řízení. (Nemám na mysli "Chceme tenhle produkt, kdo ho prodá nejlevněji", ale "Chceme takovou funkčnost, my si vybereme z nabídnutých produktů.")
Dobry den, Active directory server beha na RH linuxu jiz snad 20 let. Tehdy to jakysi smysl melo, ale o dnesnim vyznamu takoveho reseni bych vazne pochyboval. AD totiz neni jen o sprave uzivatelu, skupin, prihlasovani. AD je take uplatnovani politik, distribuovanych inastalaci ruznych produktu, distribuci nastaveni a konfigurace, sireni aktualizaci, mapovani sdilenych prostredku, accountingu, atd. Je toho velmi mnoho a vetsina i pokrocilych administraci lze pomoci politik provest. Dnes je to navic rozsiruje pokrocile scriptovani v powershellu, takze opravdu, snad neznam nic, co nelze politikou AD nastavit. Snad jen zmena hesla lokalniho spravce, coz je ale zalezitost systemova a pri trose snahy lze obejit (LAPS nebo zmineny powershell). Znovu tedy plati, co nelze naklikat, lze nakonfigurovat powershellem.
A AD na linuxu tuhle komplexnost neposkytuje. Spise si myslim, ze spravu malych siti naopak komplikuje.
31. 3. 2022, 13:33 editováno autorem komentáře
Je treba se rozhlednout hezky zesiroka. GPO je jedna z casti celeho systemu AD. Jak jsem psal vyse, AD nabizi mnoho dalsich sluzeb. Napr. vztahy duvery mezi domenami a to jak castecne, tak v ramci celych lesu, replikace se stanovenim cest i ruznych protokolu, spravu autorit, certifikatu, spravu overovani na urovni site s rozsirenim stromu a navazanymi sluzbami pro NAP, postotovni systemy (zejmena exchange, o365) a mnoho dalsiho.
Skutecne, nainstalujte si W2019 nebo 2022 server, namodelujte si standarni malou firmu se tremi, ctyrmi lokalitami, nejakym uctem nekde v cloudu s neuplnym prechodem, vyzadujici hybridni rezim, nejakou to akvizici a tedy jinou domenou s nutnosti definice samostatnych opravneni ale s globalni administraci apod.
A pak to premigrujte na linux AD
Az budete hotov, mozna poupravite svuj prispevek.
31. 3. 2022, 20:16 editováno autorem komentáře
Ze system nejake funkcionality nabizi neimplikuje, ze jsou skutecne v praxi potrebne. Zrovna treba vztahy duvery mezi forresty je funkce, kterou na spouste mist nevyuzijete. A roubovat to na Exchange/O365... proc proboha? Ja nemam problem s provozem on-premise mailoveho reseni. Vsak AD jsou technicky vzato jen LDAP, ktery propojit s mailserverem neni nikterak slozite.
Jiste, taky si umim vymyslet zcela nesmyslne podminky a pak se tvarit, ze neco nejde...
Zatím jsem pochopil z článku, že je to možné místo Windows.
No, popravdě radši zaplatím za licenci Windows serveru než abych platil někomu za rozběhnutí a správu.
Polopatě
Za licenci zaplatím 20 tis., obsluhovat to umí každý IT admin, řešit a vyřešit provozní umí také a umí to obnovovat a vracet do funkčního stavu.
Za licenci Linuxu zaplatím 0 korun, opravdu?! Není lepší a jistější vsadit na RedHat a zaplatit asi 800USD, protože CentOS už není co býval a další varianty jsou přinejlepším nestálé. Nicméně ušetřím tedy za licence, ale musím mít, a udržovat dlouhodobě dobré vztahy s člověk který mi to nainstaluje a bude udržovat. A takové vztahy nejsou zadarmo. A teď do toho přijde běžná správa a běžná funkcionalita která se bude muset docela pracně dodělávat. Nedejbože že přijde nějaká aktualizace která to totálně zmrší a proto se bude muset před nasazením vše testovat. A nejlepší bude až to jednou lehne, tak většina mne známých IT linux adminů vůbec není na takovouto variantu vůbec připravená.
Stačí si pouze třeba zkusit odkrokovat start Linuxu, nebo zkusit si odstranit banální sw problém s nefunkčním driverem klávesnice, která nebude detekována. Co s tím?!
Ve Windows vezmu CD/Flash, spustím Win a upravím registry, nebo tam dohraji a zaregistruji ručně driver, ale zvládne toto typický Linux IT admin?!
Na většině menších firem je AD stejně využíván jen jako centrální DB (LDAP), authentifikace (Kerberos), file sharing + GP Policy.
LDAP + Kerberos nejsou výhradní MS služby, lze je naprosto v klidu nahradit jinou bezplatnou variantou (openLDAP, Samba4, ...)
File sharing je již přežitá technologie:
- Krása roaming profilů je již pryč a nikdo je snad již nepoužívá.
- Programy instalované na síťové disky, katastrofa. Aplikace buď přešly na webové aplikace nebo na princip klient / server.
- Uživatelské disky, sdílené uložiště, opět již mrtvý koncept. Dnes uživatelé chtějí mít data dostupná z různých zařízení (Android, Apple, ...) a nejlépe i z domu. Takže toto nahrazuje MS 360 nebo Google.
S GP Policy si už taky nevystačíme, potřebujeme spravovat i jiné než Windows zařízení a to především i mimo naši síť.
I HW se změnil, stav kdy lidé migrovali z jednoho PC na druhý je již pryč. Dnes lidé pracují na noteboocích, tabletech, telefonech, ... -> jedno zařízení = jeden uživatel.
MS AD má mnohem větší nároky na HW, což znamená buď degradovat na stále aktuální a supportovaný systém (zůstat na Windows 2003, 2008 či na 2012) nebo nahrazovat každých pár let HW.
Z toho důvodu se domnívám, že pro menší organizace a firmy je MS AD zbytečný a drahý luxus, které jim nic navíc nepřináší jen stálé výdaje.
Souhlasím se vším až na to mrtvé sdílení souborů. I naše celá univerzita přešla z lokálně poskytovaného sdílení souborů na OneDrive od Microsoftu. Pro kancelářské soubory to stačí. Pro některá data se to ale nehodí (data z různých měření, počítačové simulace), protože OneDrive je pomalý a při kopírování velkého množství souborů nespolehlivý. Pro tyto specifické účely i nadále udržujeme klasické sdílení souborů.
Jinak ty komerční "NASy" poskytují podobné cloudové služby jako Microsoft a Google. Navíc se soustředí na sdílení souborů pomocí synchronizace, popsáno je to třeba zde: https://global.download.synology.com/download/Document/Software/WhitePaper/Package/SynologyDrive/All/enu/Synology_Drive_WP.pdf . Pro malé firmy to vypadá jako rozumné řešení.
Z mého pohledu Synology chybí nativní klient pro openSUSE, podporuje jen Ubuntu. Ale Syncthing je k dispozici jako image pro Docker (https://synocommunity.com/packages), takže se to dá obejít. Nebo se používá rsync. Ten ale není pro BFU.
Děkuji za článek. V předchozím zaměstnání se mi podařilo na Linuxu rozchodit spolehlivě přihlašování pomocí SSSD do Active Directory. Problém byl jen, ještě rozchodit automatické mountování HOME z file serveru přes CIFS/ Sambu. Nechtělo mi to chodit v závislosti na tom, který uživatel se zrovna přihlásil. Já si to samozřejmě uměl připojit ručně, ale pro nějaké serióznější použití i mezi kolegy to byl docela blok.
Máte nějaký tip?
Ten postup, kterým si to propojíte vy by nešel zabalit do logon scriptu, případně obalit nějakými timeouty a kontrolami, že k připojení skutečně došlo?
Kdysi jsem míval na připojení disku ikonu na ploše. Až když uživatel tuto oblast potřeboval, tak si ji kliknutím připojil a případně se při to i autentizoval. Další spuštění toho stejného zástupce oblast odpojilo.
Není to tak jednoduché. Myslete na lidi někde v produkci u linky při teplotách -20-50°C s blbou klávesnicí. Každé psaní je otrava. Když se na začátku směny připojí ke kompu pod svým účtem, mělo by se rovnou vše spojit.
-> Buď rovnou automaticky využít heslo na připojení disku někde v PAM nebo co já vím, nebo nějak využít Kerberos ticket. Asi tomu dostatečně nerozumím/ nenašel jsem fungující řešení, tak jsme to zavrhli. Jinak by dost možná běžel různě po těch halách už Linux.
Rád se poučím. Jak?
Koukám, že možná tohle už někdo od té doby vyřešil, snad. Zkoušel jsem toho poměrně dost, ale na toto si nevzpomínám.
https://wiki.debian.org/wiki/Debian9ADSharedDisks_Sssd_PamMount
Tehdy jsem se orientoval pro připojení k AD hlavně podle: https://alandmoore.com/blog/2015/05/06/joining-debian-8-to-active-directory/ a https://forums.servethehome.com/index.php?resources/joining-linux-to-active-directory-for-windows-admins.15/
Ten pam-mount vypadá slibně. Něco s PAM jsem zkoušel, ale nechodilo to. Skoro určitě jsem ale nepsal žádné XML, tak třeba ten pam-mount https://wiki.archlinux.org/title/pam_mount fungovat bude.
No keď sa používateľ prihlásil do domény, tak má TGT. Prečo sa neautorizuje kerberovým ticketom?
Mountovanie sa dá riešiť viacerými spôsobmi: keď ide o celý home, tak kľudne aj kanónon systemd-homed. Pokiaľ ide o nejaký podadresár, kľudne ako systemd mount unit v user scope (namountuje sa pri nalogovaní, odmountuje sa pri odlogovaní).
Jeden PAM modul už jsem psal, ale to byly dost specifické podmínky.
Vycházel jsem z:
http://www.linux-pam.org/Linux-PAM-html/Linux-PAM_MWG.html
S tím si pak můžete autentizovat uživatele podle libovolných parametrů. Např Username a IP., (nebo i podle počasí).
Ve vašem případě by mělo jít použít něco standardnějšího, nějaké ty níže zmiňované TGT nebo KCD (Kerberos Constrained Delegation).
Ještě tu pro budoucí generace odložím odkaz: https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Active_Directory