Hlavní navigace

Ubuntu 20.10 nabídne podporu Active Directory během instalace

Sdílet

David Ježek 8. 9. 2020
Lenovo Ubuntu Autor: Lenovo

Instalátor Ubiquity čeká pro nadcházející Ubuntu 20.10 poměrně významná novinka. Míří do něj úprava, která přidá podporu zprovoznění (integrace do) Active Directory již během instalace systému.

Pokud uživatel při instalaci tuto volbu vybere, bude proveden procesem zprovoznění loginu do Active Directory, zatímco nadále bude vytvořen i lokální účet pro potřeby administrátora systému. V GUI bude množné nastavit doménu, administrátora i heslo a také vše otestovat.

Úprava instalátoru byla tak trochu na poslední chvíli schválena a míří do Ubuntu 20.10, které vyjde již příští měsíc. Vedle toho čekejme například Linux 5.8, GNOME 3.38 či novější verzi OpenZFS a mnohé další novinky.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 8. 9. 2020 10:56

    BobTheBuilder

    To jsem teda zvědav. Apple to už udělal před nějakou dobou, $HOME se bere z AD a tam taky ukládá Desktop apod.
    Tak je otázka, jestli to taky bude dělat takové věci, a jestli se to v takovém případě nebude hádat třeba s RedirectFiles z GPO pro Windows (třeba si navzájem přepisovat nějaké speciální soubory v $HOME/Desktop).

  • 8. 9. 2020 11:41

    bez přezdívky

    Ono to robia iné distribuúcie už roky, napr. Fedora má v OOBE sprievodcovi pri vytváraní prvotného účtu dole tlačidlo Enterprise Login, čo robí presne toto. Navyše Fedora, na rozdiel od Ubuntu, nepotrebuje žiadny lokálny účet. S Ubuntu je treba vždy mať nejaký lokálny.

    A čo to vlastne robí? Je to GUI pre `realm join $nazov-domeny` - nakonfiguruje sssd (kde má hľadať databázu používateľov a skupín), nss, pam a oddjob (zapne mkhomedir pre doménových používateľov; a práve toto blbne v Ubuntu 20.04 na ZFS, nevytvorí subvolume pre doménových používateľov ako to robí pre lokálnych).

    Pozor: Domain admins ani Enterprise admins nie sú automaticky sudoers, ani adnimi pre PolKit. Tieto veci treba nakonfigurovať manuálne.

    Presmerovanie $HOME na smb share je možné, ale je treba ho urobiť ručne. GPO je ignorované (rovnako ako na macOS).

  • 8. 9. 2020 11:56

    BobTheBuilder

    To předpokládám, že s GPO to nebude kamarádit.
    Ta moje poznámka o GPO souvisela s přesměrováním souborů na síť (home, desktop, documents, ...) via GPO - aby buď tohle nebylo v roaming profiles, nebo při lokálních profilech, aby to bylo na síti. Tohle od *nix řešení nečekám, jde spíš o eventuelní konflikty. macOS u síťových uživatelů použije $HOME z AD a umístí tam i Desktop, Documents, Downloads, ...
    V macOS jediné, co v systému o síťových uživatelích je, jsou práva (zařazení mezi administrátory nebo tak). Zbytek je dynamický, řízený AD.
    No co, až to vyjde, vyzkouším to.
    Stejně je v Linuxu sranda, že mám $HOME\Dokumenty a jakmile přepnu na angličtinu, mám vedle $HOME\Documents (a podobně další, downloads, ....) - to ovšem nemá s AD nic společného, jen takový povzdech.

  • 9. 9. 2020 8:23

    bez přezdívky

    [...] Stejně je v Linuxu sranda, že mám $HOME\Dokumenty a jakmile přepnu na angličtinu, mám vedle $HOME\Documents (a podobně další, downloads, ....) - to ovšem nemá s AD nic společného, jen takový povzdech.

    I toto je jeden z několika důvodů, proč mám svoje soubory ve speciální složce Data s vlastní hierarchií a ~\Dokumenty, ~\Obrázky, konfigurace, které chci zachovat mezi instalacemi, apod. jsou jen symlinky (na jejichž tvorbu mám skript). Takže když zjistím, že si systém z jakéhokoliv důvodu usmyslel začít používat jinou složku třeba pro downloads, stačí jen rozšířit seznam symlinků a jede se v klidu dál.

  • 9. 9. 2020 10:27

    bez přezdívky

    ale tohle resi promenne XDG, to nemusite lepit :)

    Netuším, jak je to konkrétně s těmito proměnnými, ale obecně mám zkušenosti, že jsou věci, na které se v průběhu let dá spolehnout a jsou věci, které se mění. Moje řešení vnímám jako časově stabilnější a to mj. nejen proto, že řeší tyto složky, ale i další problémy, jako je např. to, že ve složce home v průběhu času vzniká balast, např. kvůli programům, které zkouším a odinstaluji a nemám vždy náladu zjišťovat, zda má konfiguraci v „~/.<app>“, „~/.<vendor>“, „~/.config/<app>“, „~/.config/<ven­dor>/<app>“, či úplně jinde (např. gconf) a zda nezanechává zbytky na vícero místech. Takže si symlinkuji i konfigurace, na kterých mi záleží, a při reinstalaci OS si pročistím home a jen spustím onen skript, který nachystá odkazy na vše, co potřebuji.

    Pozn. ohledně reinstalace OS: používám Ubuntu a ačkoliv vím, že lze aktualizovat místo čisté instalace, moje zkušenosti jsou, že pak systém startuje výrazně pomaleji (a s každou další aktualizací se to sčítá). Možná je ta zkušenost zastaralá (myslím, že naposledy jsem to zkoušel okolo 12.04), ale nemám chuť experimentovat, zda to platí nadále či ne.

    No a dalším důvodem, proč používám tento přístup, je, že jsem relativně donedávna jel na dual-boot Win 7. Složku Data jsem měl na NTFS oddílu a tak byla přístupná pro oba systémy, nalinkováno v obou případech, kde bylo potřeba. (Nicméně co mi (na rozdíl od Ubuntu, kde stačila malinká úprava v fstab) Win 7 nerozdýchal smrt disku Data, jsem se již jaksi k obnově Win nedostal a mezitím už vypršela i podpora.) Vlastně ten symlinkový systém jsem zavedl v době Win XP a nutnosti čas-od-času reinstalovat kvůli degradující rychlosti systému v průběhu času (tou dobou bylo Ubuntu pro mne dost nepoužitelné, z mnoha důvodů).

  • 8. 9. 2020 12:26

    Miroslav Šilhavý

    Mě spíš trápí zatím nevyřešené mapování UID na Windows SID. V rámci sítě je potřeba, aby se to mapovalo jednotně (např. kvůli NFS). Jenže na to je 32bitový UID identifikátor malý. Některé linuxy mají 64bitové UID, tam už to s jakous takous mírou jistoty jde. Sssd není cesta pro sambu, ta potřebuje s AD komunikovat víc. A tak se ještě řeší nesoulad v generování UID přes sssd a sambu.

    Tohle by určitě potřebovalo učesat, a třeba čím dál větší možnosti integrace k tomu povedou.

  • 8. 9. 2020 12:29

    bez přezdívky

    Neskúšal som premiestnenie profilu, používatelia majú lokálny a ten sa im len zálohuje na server. Popravde, nevidím dôvod, prečo ich týrať presmerovaním priečinkov na server ;).

    Čo sa týka vytvorenia (ne)lokalizovaných adresárov, za to môže xdg-user-dirs-update/xdg-user-dirs-gtk-update, resp. vo vašom prípade nejaký bug. Vytvárať by ich mal, iba ak neexistujú adresáre nastavené XDG_*_DIRS (čo vy v prípade existencie lokalizovaných budete mať, pozri ~/.config/user-dirs.dirs) - teda v prípade nového profilu. Pri zmene jazyka (= aktuálny jazyk je iný ako ~/.config/user-dirs.locale) by sa vás mal spýtať, či ich chcete premenovať do nového jazyka. Keď nie, tak to ďalej ignorovať.

  • 8. 9. 2020 12:37

    volani.webnode.cz

    Já sev tom moc nevyznám. AD řeší Tonze se že serveru tahají data která jsou potřeba a pak se provádí synchronizace? Když se uživatel odpojí tak data zůstanou? Šifruje to ta data? Řeší se při střídání uživatelů mazání starých dát automaticky? Dá se místo kvót a limitu nastavit možnost třeba využít disku v %? Linux to umí také ale řeší to přes NFS? Umí Windows NFS?
    Umí už NTFS v Linuxu ukládat data s kompresí?
    Já nikdy moc AD nevyužíval. Ale sdílel jsem data přes sambu a paralelně třeba přes FTP. A teď je hrozně možnosti jak synchronizovat data.
    Já většinou používal jeden účet pro víc uživatelů. Většinou i zaměstnání občas někdo potřeboval využívat účet někoho jiného. Je pak hrozně práce s nastavením sw a instalaci různých věcí. Připadá mi že když sdílí jeden PC víc lidí tak je to lepší pod jedním účtem. Ale láká mě využívat třeba multiseat.

  • 8. 9. 2020 12:56

    Miroslav Šilhavý

    Ptáte se na to, co umí AD a Windows? Pak zní odpověď, že prakticky všechno, co jste vyjmenoval. Pokud se ptáte, co umí Linux, tak jen minimum z toho (a rozhodně ne automaticky).

    Připadá mi že když sdílí jeden PC víc lidí tak je to lepší pod jedním účtem.

    Heh?

  • 8. 9. 2020 14:04

    bez přezdívky

    Windows niektoré veci vie a niektoré veci tiež nevie.

    Napríklad Windows musí byť pripojený do presne jednej domény, ani menej, ani viac a používateľ, pokiaľ chce pristupovať k zdrojom v ďalšom realme, ktorý nemá trust s jeho domovským realmom, tak má dosť smolu (typický prípad: jedna doména u zamestnávateľa a druhá u zákazníka). Ďalšia chuťovka je Kerberos z počítača bez joinutia do domény. Oba prípady sú v Linuxe a MacOS len ďalší kinit (alebo naklikanie v Linuxe cez Gnome Online Accounts, resp. v macOS cez Ticker Viewer / auth-sso).

    Celé to má praktický dôsledok že tí, čo používajú Linux a MacOS majú funkčný Kerberos všade a tí, čo používaju Windows, sú trénovaní v neustálom vyťukávaní hesla.

  • 8. 9. 2020 15:22

    Miroslav Šilhavý

    Z pohledu správy domény a její bezpečnosti přesně to, co vyjmenováváte dává smysl. Pokud nedůvěřuji (já, jako správce) jinému realmu, proč bych povoloval trust?

    Jinak z pohledu uživatele v tom moc rozdíl nevidím. K zákazníkům si připojím VPN a pracuji s jejich vzdálenými prostředky, aniž bych heslo vyťukával, pověření je uložené. U připojení VPN se musí nastavit UseRasCredenti­als=0.

  • 8. 9. 2020 16:54

    bez přezdívky

    Však nikto po vás ako po správcovi nechce, aby ste povoľovali trust (osobne som ho ešte nevidel nikde, okrem prípadov majetkovo prepojených spoločností). Keďže však trust poväčšinou neexistuje, tak používatelia nafasujú viacero credentials z viacero realmov, dostali ich za nejakým účelom a ten účel majú napĺňať.

    Credentials nie sú len za účelom pripojenia k VPN; používateľ si otvorí nejakú webovú aplikáciu na intranete na opačnej strane alebo pristupuje k fileserveru a hneď ťuká heslo. Teda pokiaľ jeho klientsky systém nevie pracovať s viacerými credentials, ako bolo uvedené vyššie.

    UseRasCredentials=0 mu v tom nepomôže, to rieši iný problém. Niektoré VPN majú ambíciu to riešiť (Fortigate SSO), je to stále narovnávak na ohýbak. Znovu sa vraciam k tomu, že systémy ktoré vedia spracovať viacero realmov, takýto problém vôbec nemajú.