Samba AD 2024-ben otthonra?

Hálózatok általános

Mint "házi rendszergazda" a család nagyobb részének én adminisztrálom a többnyire windows-os gépeit, már többször felmerült bennem, hogy beletanulok az AD-be.

De aztán ezt soha nem léptem meg. Mindig találtam valami kibúvót, elvoltam a sima file sharing-el, LDAP-ot végül csináltam pár éve (openldap-al), meg egyesével beállítgattam a gépeket, helyi userekkel.

Gépből viszont egyre több van, igazából userből is szerencsére :D, időből viszont egyre kevesebb. Illetve a windows egyre nagyobb kontrollmániáját némileg lehet ellensúlyozni azzal, ha beléptetném domain-be őket, pl. használhatnék domain account-okat cloud account helyett.

 

Tehát a dilemma, amivel gondolom nem vagyok egyedül:

Érdemes-e 2024-ben beletanulni a Samba AD-be? Vagy az egész technológia úgy halott, ahogy van? Fogadjam el, hogy minden megy a felhőbe?

 

Ennek megválaszolásához a következő tapasztalatok megosztására számítanék azoktól, akiknek van:

Tud egyáltalán rendesen együttműködni a Win 11 a Samba AD-vel? Azt is olvastam, hogy ebben az esetben a domain controller lehetőleg ne legyen fájl szerver is. Hát most ezért két gépet nem fogok beállítani, de virtualizálgatni sincs nagyon kedvem, bár abból már fut kb. 5 virtuális szerverem.

Normális dokumentációt hol találok hozzá?

Win 9x idejében még klasszik sambával volt roaming profile is, de aztán azt kb. az XP korszakban ki kellett kapcsolni, mert egyszerűen annyi adatot szinkronizált egy-egy ki-belépéskor. Nem tudom, hogy ezen a téren javult-e a helyzet.

Mi a helyzet a linuxos kliensekkel? Azokkal mennyire tud együttműködni? Gondolok itt is valami osztott home directory-kra, és központi belépésre.

  • 2970 megtekintés

( hnsz2002 v | 2024. 07. 30., k – 20:42 )

Szerkesztve: 2024. 07. 30., k – 20:46

- Ha érdekel érdemes. Miért lenne halott? Nem megy minden a felhőbe

- Persze, megy win11-el

- A samba ajánlás szerint ne legyen file share a dc-n (mint ahogy ne 1 dc legyen, hanem legalább 2), a gyakorlatban ezzel nem lesz problémád

- samba doksi jó, de igazából nem sok mindenre van szükséged, az alap telepítés és domain provision után a windows-os toolokkal kezelhető kb. minden, és ugyanúgy működik

- sssd-vel megy a linux is szépen

"Sose a gép a hülye."

Célszerű azért belepiszkálni itt-ott szerintem (a services sor OS/sssd verziótól függ, hogy kell-e, illetve hogy oda mik kellenek):
 

[sssd]
  domains = home.domain

  config_file_version = 2
  services = nss, pam, ssh
[domain/home.domain]
  ad_domain = home.domain
  ad_server = dc1.home.domain, dc2.home.domain
  ldap_user_extra_attrs = altSecurityIdentities
  ldap_user_ssh_public_key = altSecurityIdentities
  krb5_realm = HOME.DOMAIN
  realmd_tags = manages-system joined-with-adcli
  cache_credentials = True
  dyndns_update = false
  id_provider = ad
  krb5_store_password_if_offline = True
  default_shell = /bin/bash
  ldap_id_mapping = True
  use_fully_qualified_names = False
  fallback_homedir = /home/%u
  access_provider = simple
  simple_allow_groups = az_a_group_ami_belephet_ide

Ebből az ldap_user* paraméterek az érdekesek: a megadott AD-s attributumba felveszed az user publikus ssh kulcsát, és az sshd_config-ba meg berakod, hogy:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

Akkor az user a kulcsával tud authentikálni, nem jelszóval.

Ami nekem viszont kérdéses, az az, hogy egy ilyen környezetben ha Linuxon csinálok egy share-t (nem a DC), akkor azon hogyan tudok AD-s userrel jogot osztani? Mert nekem az még nem jött össze - anno pbis-sel simán ment :-(

 

( talisker | 2024. 07. 30., k – 20:46 )

subs.

Talisker Single Malt Scotch Whisky aged 10 years - o.k. Yamazaki is playing as well :)

( mukk | 2024. 07. 30., k – 21:49 )

Szerkesztve: 2024. 07. 30., k – 21:51

Új AD létrehozása akár debiannal is lehetséges, előző azon futott. Aztán amikor migrálni kellett az új szerverre (virtualizálva régóta) akkor az már nem ment. Varázskalap, gentoo elő, annak ment. Igazából lusta voltam doksit olvasni, windowsos

módszerrel próbáltam, második AD server, szinkron, majd csere. Lehet doksival ment volna debiannal is... 4 felhasználóval használjuk, szerintem jó

...

( Proci85 v | 2024. 07. 30., k – 23:04 )

Ha van Synology, az is tud AD-t biztosítani.

( derWRK | 2024. 07. 31., sze – 01:24 )

Egész normálisan tud menni, de a roaming profile az még mindig nem az igazi, sok másolgatás + megtart korábbi verziókat is a profilból helyben, sok user kevés gép esetén rendesen tele tudja szemetelni a klienseket.

Megjegyzés: a synology is samba-val csinálja, akkor már egyszerűbb felsetupolni egy saját samba-t, ott legalább lehet majd játszani policykkel is meg bármivel. Nálam is van, és persze fájlszerver is, és egyedül is van, nem okoz gondot. Nyilván az ajánlás az egy magasabb biztonsági szintet/rendelkezésre állást feltételez. Linuxokon cifs jól működik, de használj legalább 3.0-s protokollt, különben byterange locking meg hasonló okosságok nem mennek ( és akkor minden szépen megy, amíg nem indítasz egy chrome-ot vagy egy openoffice base-t pl.),  direkt AD-s belépésem most nincs linuxon, de ha jól rémlik van hozzá pam_winbind.

Alternatíva: W10-eseket még be lehetett erőltetni nt4 pdc alá, pár registry kulccsal, meg egyébként protokoll szinten elég friss sambával, lehet hogy windows 11-el is menne még? Bár gondolom nemsokára elvágja az MS az ilyen megoldások nyakát... szóval ha valami, akkor az NT style domain a halott, nem az AD :)

Köszönöm a tapasztalatokat!

Azért szomorú hogy a roaming profile így ~20 év elteltével sem lett használható :( Pedig azt akkoriban tényleg szerettem.

A lényeg az lenne, hogy akkor legyen már AD, nem maradnék az NT4 domain-nél. Így akkor tudok GPO-t is állítani, szintén egy fontos elem lenne.

Már nem tudod a win10-et sem nt4 samba alá benyomni, valamikor tavalytól az új gépekkel olyan elotelepiwtt win jön ami alatt nem lehet. A régi még korábban belokdosott gépeken még működik ha a problémás frissitéseket leszeded, de azért az nem az igazi. Szóval el kell engedni a 3-as sambákat végleg.

Ok, ma kipróbáltam, telepítettem, ment W10-el. Az ugye világos, hogy a samba4 is tud NT4 pdc módban működni, és ott akkor van smb3.2 protokoll és azzal megy a win10 - valóban 3-as sambával nem megy, de ezt nem is állítottam. Persze ettől még deprecated, golyót a hasába, szóval továbbra sem ajánlott ma ilyen megoldással elkezdeni valamit, max. ha nagyon legacy módban folytatni kéne valamit...

Oké, az lehet, nekem az NT4 domain az Samba3 a fejemben, mivel utoljára azzal csináltam NT4 domaint, ahol már négyes van, ott sehol nem NT4 domain van. Szóval én automatikusan a hármas sambára asszociáltam és erre értettem a kommentemet. ...és pont a jövő héten lesz az utolsó samba3->samba4 migrációm, szóval végleg elengedem mindenhol az NT4 domaint.

( Caro | 2024. 07. 31., sze – 06:06 )

Pár dolog, hogy világossá tegyem, miért gondolom ezt halott technológiának:

1) nem nagyon fejlesztik... lásd: https://www.reddit.com/r/sysadmin/comments/99etbt/whats_new_in_active_d… És ez már egy 5 éves poszt

2) (részben) vannak jobb, modernebb megoldások. Pl. a file sharing helyett MS oldalon ott a Onedrive, ami amúgy (technológiailag) tényleg jó cucc, open source vonalon pedig pl. a Nextcloud. Ezek verzióznak, és az offline elérés is megoldott. Ezt a Onedrive nagyon jól csinálja, ha valaki tud hasonlót, ami Linuxon is megy, szívesen fogadnám. Értem ez alatt, hogy csak azt tölti le a gépre, amit meg is nyitsz.

3) központosított azonosításra elég a mostani openLDAP szerver is.

Amit nem nagyon lehet mással kiváltani, az a GPO, illetve hogy a third party megoldások azért elég változó minőségű kódok. Nekem az is probléma, hogy nem csak a Samba AD-be, hanem úgy az AD-be egyáltalán bele kell tanulni, mert eddig ez kimaradt az életemből. Tehát azt elfogadom, hogy egy Windows szerver AD-s rendszergazdai háttérrel nem olyan nagy ugrás már egy Samba AD, de nekem itt két lépcsőt kellene egyszerre megugranom...

Illetve másik ellenérzésem oka még, ha ezt meglépem, akkor búcsú az openLDAP-tól és az eddig működő központi azonosítási rendszertől, és akkor a Samba alá fog tartozni minden. Kicsit fázok ettől, de lehet hogy ok nélkül.

> akkor búcsú az openLDAP-tól és az eddig működő központi azonosítási rendszertől

az AD is csak egy LDAP ha szigoruan nezzuk. a GPO is ugy mukodik hogy a win kliens X idonkent (90 perc?) lekerdezi az AD ldap-jabol milyen profilok vonatkoznak ra aztan azokat leszedi a fileserverrol es futtatja. az ms exchange is az ad ldap-jaban tarol minden beallitast stb. en kicsit parasztvakitasnak tartom az egeszet emiatt, de wines kornyezteben nincs mas...

amit eddig openldap-al tudtal integralni azt ugyanugy lehet az AD ldap-javal is. legfeljebb par attributum neve mas lesz, vagy kell schemat boviteni.

de ugye pont nem LDAP-on illik szólongatni

Akkor milyen protokollal kérdezed le a directory részét? LDAP + Kerberos az egész, némileg szabvány-inkompatibilis sémával. Amikor ADUC-cal csinálsz valamit, szerinted olyankor valami titkos proprietary protokollon történnek a dolgok?

( gdavid v | 2024. 07. 31., sze – 08:36 )

Próbálkoztam vele és egy ideig ment is, de aztán több lett vele a melóm semhogy megérte volna. Baromi macerás a restore (backup könnyű) úgyhogy valami más megoldás után néztem, ami végül is freeipa lett.

Nálam az egyik ipa szerver virtuálisban fut (pve), (de tud futni conténerizálva is), a másik pedig egy dedikált rpi4 -en.

samba share-el integrálható szépen, roaming profile is megoldható, nextcloud-ra is beköthető mint auth, windows-al is tud működni, bár itthon nem használunk mást, csak linux-ot.

( Caro | 2024. 08. 03., szo – 16:28 )

Hát ma nekiálltam, de kapásból belefutottam pár orbitális szívásba...

Kezdődik a domain név kiválasztásánál. Sajnos nincs regisztrált domain nevem, úgyhogy lett egy .lan végű. Ilyesmit nem ajánlanak, de túlélem.

Aztán jött a többi. Tekintve hogy elég kis rendszer lesz, gondoltam bekapcsolom az internal DNS szervert, nem szenvedek a BIND-el. Viszont egy beállított működő BIND van már a rendszerben, és ugye két DNS szerver nem mehet egyszerre.

Akkor mégis bekonfigoltam a BIND-et. Elsőre persze el sem indult, mert hiányolta a samba konfig fájlt. De aztán ezen túllendültem. Végül is elindult.

De a samba nem... ugyanis (természetesen) az LDAP szervert nem tudja elindítani, mert a slapd már ül a porton. Ha meg azt kilövöm, akkor minden borul, összes login meg hálózati szolgáltatás.

Úgyhogy végül úgy döntöttem hogy mégis csinálok neki egy virtuális gépet. Ezt így nem lehet egyik percről a másikra átállítani.

azt mar nem tudom hol de 10 eve is azt mondtak tanfolyamon hogy a .local-t mar az MS sem ajanlja...

sambanak lan-ra mind1 vegulis, de ms szervereknel celszeru a valos domain, mert arra tudsz rendes certet venni/csinalni, es akkor se szopod szejjel magad ha ossze kell kotni o365-el vagy exchange-t kell felrakni...

A .local amiatt nem ajánlott, mert az Apple mDNS-t meghülyítheti (állítólag), mert az fixen ezt a TLD-t használja. Nekem nincs ilyen tapasztalatom Apple eszköz hiányában, de tuti ami biztos, mi is .lan TLD-t használunk ahol más kívánság nincs.

Ezen kívül tetszés szerinti TLD lehet belső hálózaton, műszakilag teljesen mindegy.

( Caro | 2024. 08. 05., h – 21:29 )

Haladok. Meglepően simán ment eddig a samba wiki-t követve. Persze így, hogy külön virtuális gépre delegáltam a domain kontrollert, de azt hiszem jó lesz így végülis.

Sőt, még a fáljszerver is fog valószínűleg kapni egy külön virtuális gépet.

 

Legnagyobb elakadásom az volt, hogy az eddigi .lan domain kiegészült egy ad.lan-ra, ami az AD tartománya. Aminek a samba lett a DNS szervere, ezt meg kellett etetnem a BIND-el.

Egyszer majd lerajzolom, hogy néz ki, de a lényeg az, hogy a hálózati alapszolgáltatásokat akkor is szeretném működni látni, ha ez a windows-os rész lehal. Tehát a host gépen marad a BIND.

Ezek után viszont minden ment, GPO-t is tudok állítani.

Következő a roaming profile lesz, de ahhoz a fájl szervert is fel kell húznom.

Úgy döntöttem hogy a slapd is marad, de a "mezei" userek átköltöznek majd a samba LDAP-jára. Be fogok számolni a fejleményekről.

( Caro | 2024. 08. 08., cs – 16:54 )

Szerkesztve: 2024. 08. 08., cs – 17:08

Na, a fájl szerver jobban megszivatott.

Először is tisztáznám, hogy jelenleg hogy néz ki a hálózat.

Legyen a host gép neve "master",a dc "dc", a fájlszerver pedig "fs".

Mint azt leírtam a hálózat alapinfrája (DNS, DHCP) marad a "master"-en, nem fogom feltúrni a windows kedvéért. Az egész hálózat így a .lan domain-t használja, ezt osztja a DHCP szerver.

Az AD kedvéért viszont létrehoztam egy subdomaint, .ad.lan néven. A DC azt hiszi hogy ez neki az elsődleges domain, és ez van beállítva samba-nak is.

Ezen a domain-en ő a DNS szerver úgy, hogy a master-en lévő BIND az ad.lan-ra érkező kéréseket ide továbbítja.

Reverse DNS így nyilván nincs, de az elvileg nem is létszükséglet.

A DC beállítása OK, windows gép tud csatlakozni, működik.

A "fs" beállításhoz kellene, hogy ő is az ad.lan részének gondolja magát. Én feltételeztem, hogy ehhez az kell, hogy a resolv.conf-ban a

domain ad.lan

sor szerepeljen.

Némi dhclient.conf túrással ezt el is tudtam érni, de amikor csatlakozni akarok az AD domain-hez, akkor továbbra is fs.lan, és nem fs.ad.lan néven akar. Ennek megfelelően persze hibát is dob.

Jó, akkor a hosts-ba beírtam a saját IP címével:

192.168.1.3 fs.ad.lan fs

És így be tudott lépni a domain-be! Yess! Gondoltam én...

 

De pl. windows alatt nem látszik a gép.

Ha meg akarom pingelni fs.ad.lan címen, az nem megy, nem oldja fel. Pedig biztosan jó a DNS, mert a dc.ad.lan-t pedig feloldja, illetve a windowsos gépet is. (Aztán egy idő után elkezdett működni, bár a gépek között azóta sem mutatja)

Nem baj, lépjünk be IP címmel. Kéri a felhasználó/jelszót. Akármit adok be, nem fogadja el.

Akkor megpróbáltam helyben, smbclient-el. -U paraméter nélkül az admin jelszóval OK! Haladunk.

De ha bármilyen user-t megadok kézzel (akár az admin-t), akkor már nem megy.

Ami még fontos: egyelőre a winbind-nss-t nem állítottam be a fs-en. Nem akarom, hogy az AD userei a linuxos fájl szerveren létezzenek, arra be tudjanak lépni. Annyit akarok, hogy a samba szolgálja ki nekik a fájlokat.

Sajnos a leírás nem részletezi, hogy ez így működhet-e, vagy mindenképp szükség van az nss-re.

Így aztán beállítottam az nss-t is és láss csodát: működik.

De nekem nem tetszik, hogy így a linuxos szerver gépen az ad userek valid usernek számítanak. Ez így biztosan jó security-nek számít?

"De nekem nem tetszik, hogy így a linuxos szerver gépen az ad userek valid usernek számítanak. Ez így biztosan jó security-nek számít?"

Hát pont ez a lényege a tartományba léptetésnek.

De ha nem akarod hogy belépjenek, akkor pam-mal meg lehet oldani.

"Sose a gép a hülye."

Ha ez egy linux kliens gép lenne, akkor igen, akkor tudjanak belépni.

De ezt csak egy fájlszervernek használom, gondoltam a samba van annyira okos, hogy a jogosultságokat bekéri a DC-től, és megoldja magától, de úgy tűnik nem. Persze a shell így is /bin/false, de ha valid a user, akkor akár SCP-zhet, stb. Ezt nem szeretném.

fentebb írtam, sssd.conf -ban:

access_provider = simple
  simple_allow_groups = az_a_group_ami_belephet_ide

illetve pam-auth-update, és beállítani, hogy sssd, illetve célszerűen a  "create homedir" (vagy micsoda) is legyen.

Ekkor akik PAM-ból authentikálhatnak, azokat felveszed a megadott csoportba, és onnantól a pam "rendezi a dolgot" az sssd-vel.

( Caro | 2024. 08. 09., p – 05:33 )

A fájl szerveren még ezekkel szívtam:

Pl. user home directory-knál nem említi, de a megosztás opciók közé fel kell venni (vagy globlálisan):

vfs objects = acl_xattr

Különben nem lehet állítani a jogosultsáokat úgy, ahogy leírja. Access denied.

Bár sírok, hogy minek nekem ennyire bonyolult jogosultságkezelés, amikor eddig tök jól elvoltam a unix jogosultságokkal, de hát ez a fejlődés ára.

 

A másik, hogy amikor létrehozom a könyvtárat, és a kezdeti jogosultságokat beállítom (linux alatt), akkor a leírás szerint ilyen formátumban kellene működnie:

chown root:"Domain Admins" <útvonal>

De nekem csak a domain megadásával eszi meg:

chown root:"AD\Domain Admins" <útvonal>

Lehet valamilyen beállítás még nem tökéletes?

 

Ezen kívül a többi működött, nem volt elakadás. GPO-ból beállítottam a mappákat, home directory-t, roaming profile-t is bekapcsoltam

 

Csináltam egy új usert. ~10 mega körül volt így az adminnak és a usernek együtt.

Aztán elindítottam egy firefox-ot, és beléptem a gmail-be, majd kiléptem. 47 megára hízott ettől...

Kicsit utánaolvastam még ennek, valószínűleg ki fogom kapcsolni a roaming profile-t, mert leírások szerint olyan banális dolgok okozhatnak meglepetéseket, mint hogy valaki egyszerre két gépre is bejelentkezik (és akkor a későbbi logout adatai írnak felül mindent). Bár azon még gondolkozok, hogy az "elsődleges gépre" korlátozom a roaming profile-t, és akkor legalább lesz róla backup a szerveren.

 

Akartam pár könyvtárat, amit el lehet érni login nélkül is. Ez nem tudom hogy egy AD-s gépen mennyire számít szép gyakorlatnak, de ezekkel az opciókkal végül is működött:

[global]
    map to guest = Bad User
    usershare allow guests = Yes

[share]
    guest ok = yes

 

Még észrevettem, hogy egyes esetekben sokat gondolkodik a gép. Pl. amikor jogosultságokat állítok egy share-en, de most vettem észre, hogy akkor is ha csak be akarok ssh-zni a fájl szerverre. A winbind-re gyanakszom, pedig nem azzal lépek be, mint azt korábban leírtam.

 

Aztán teszt közben telepítettem egy win10-et, és akkor gondoltam milyen jó lesz majd kapásból telepítésnél domain-be léptetni. De egy katasztrófa ez a rendszer.

Egyrészt ha az install legelején nem töltötted be a hálózati drivert, akkor itt már nincs esélyed (legalábbis a GUI-ból). XP ezt még simán tudta.

Másrészt bár a domain join gomb ott van eldugva, de nem működik :D Lásd: https://answers.microsoft.com/en-us/windows/forum/all/windows-10-setup-…

Legújabb win10 ISO természetesen (22H2). Hát ennyi, ennyire foglalkozik még a MS az AD-vel. De egyelőre működik, és azért most hogy be van már állítva, kényelmesebb a 3rd party megoldásoknál.

"Egyrészt ha az install legelején nem töltötted be a hálózati drivert, akkor itt már nincs esélyed (legalábbis a GUI-ból)."

Hogy mi?

"AD\Domain Admins"

/etc/krb5.conf-ban fel kell venni default-nak, és akkor nem kell.

"Sose a gép a hülye."

Első: a windows 10 setupról beszélek. Drivert akkor tudsz betölteni, amikor partícionálsz. Ha végigmegy a telepítő, és létre kellene hozni az account-ot, akkor már nem tudsz drivert betölteni*. Nyilván ha létrehozol egy lokális usert, belépsz, akkor minden beállítható utólag, de épp ezt a lépést akartam megspórolni.

*persze shift+f10 meg egyéb parancssori trükkökkel biztosan megoldható.

Második: köszi, ki fogom próbálni.

A másodikon ez a sor segített (smb.conf):

winbind use default domain = yes

Következő elakadás: nyomtatás. Eddig nem használtam nyomtatószervert. 2024-ben minek, minden nyomtató tud nyomtatni közvetlenül.

Ámde úgy látom, hogy bár elvileg fel lehet venni így is GPO-val, de valahogy a fórumokon konszenzus van abban, hogy ez rögös út, és nem javasolt.

Melyiket válasszam? Nyomtatószerver esetén vannak aggályaim, hogy a linuxos driver vajon a nyomtató minden funkcióját tudja-e, illetve mivel multifunkciós, nem tudom a scan-re hogy reagálna.

Persze el is engedhetném ezt, egy 5-8 gépes környezetben, de ha már itt tartok, akkor érdekel :)

> driver vajon a nyomtató minden funkcióját tudja-e

nem

> a scan-re hogy reagálna

hat sehogy. azt ugy szokas hogy a samban csinalsz egy scanner konyvtarat es az mfp-n beallitod hogy oda scanneljen, de ez igy gany es a juzerek latjak egymas scanjeit, amig ki nem torlik (bar allitolag letezik olyan mfp ami tud scan-to-home-t is)

Érdemes átengedni a nyers nyomtatást és a winen driverezni, legalábbis mikor utoljára ilyet csináltam 20 éve, akkor ez volt a megoldás.
A scan megosztást én úgy csináltam, hogy minden usernek van egy külön mappája a scan mappa alatt és a nyomtatónál azt az útvonalat adom meg, ACL-el pedig a nyomtató felhasználójának adok mindegyik mappára jogot, azon túl pedig mindegyik júzernek csak a sajátjára, így nem látják egymásét.

( Caro | 2024. 09. 02., h – 09:28 )

Tegnap élesbe ment a rendszer. Eddig nem panaszkodtak, hála az égnek.

Egy kicsit mellékszálként kérdeznék még:

Az otthoni weboldalak le vannak védve basic auth-al, anélkül senki nem néz meg semmit sem. Egy-két kivétel meg van engedve (pl. nextcloud), de az a kivétel.

Tök jó lenne, ha már úgyis be vannak jelentkezve, akkor ne kelljen beírogatni vagy böngészőbe mentegetni a belépési adatokat. Régen az IE tudott valami ilyet, de ha jól sejtem az akkor nem basic auth-al ment.

Jó a tippem, hogy ehhez kerberos auth-ra kell átállni? Apache-nál mod_auth_gssapi? Sajnos alig találok erről leírást.

Illetve a firefox-nál van valami windows SSO opció, de önmagában az nem segít. Gondolom mindkettő kellene hozzá.

A másik nyűgöm a nextcloud drive felcsatolása webdav-al GPO-ból, de az egy másik történet. Még egyelőre nem volt időm kidebugolni, meg amúgy is lehet hogy jobb ötlet a kliens használata.

hasznalok ilyet egy helyen, samba-ad-apache-nextcloud kozos auth, nem volt eppen trivialis osszerakni plane 10 eve

asszem az auth_kerb kell hozza (gssapi nalam nincs is), es a site konfjaba pedig:

<Location />

  AuthType Kerberos
  AuthName "Kerberos AD Login"
  KrbMethodNegotiate on
  KrbMethodK5Passwd off
  KrbAuthRealms TK.MTA.LOCAL
  Krb5KeyTab /etc/krb5.keytab
#  KrbVerifyKDC off
  KrbLocalUserMapping On
#  KrbServiceName http
  require valid-user

</Location>

meg ugye a keytabban benne kene legyen a domain service auth kulcs, amit valami windoz varazslassal generaltam anno, de sambaval is lehet elvileg. meg szopkodni lehet a keytab jogokkal es a chroot-al is ;)

a gond az hogy manapsag egyik bongeszoben sincs by default engedelyezve a kerberos, szoval mindegyikbe fel kell venni a szervere(i)d cimeit ahova kuldhet authot igy. GPO-bol is meg lehet oldani, de azt nem en csinaltam.

nextcloud webdav auth az mar erdekesebb kerdes, mi meg az owncloud 5.x idejen belefejlesztettuk es azota is patchelgetem, de mintha mar egy ideje lenne benne gyari modul is sso-hoz, de azt nem probaltam.

Tök mindegy hogy virtuális van fizikai, a lényeg hogy külön gép.

Szóval akkor nyilván a webszervert be kell léptetni a tartományba...

Nálunk IPA van, gssapi-val és ldap-pal van megoldva: a gssapi authentikál, az ldap ellenőrzi a csoporttagságot. Ha az neked nem kell, akkor nyilván kihagyod.

yum install mod_auth_gssapi mod_ldap mod_session

cat > /etc/httpd/conf.d/ldap.conf << EOF
LDAPCacheEntries 128
LDAPCacheTTL 300
LDAPOpCacheEntries 128
LDAPOpCacheTTL 300
#LDAPLibraryDebug 7
EOF

Kell egy keytab, amivel az apache authentikálja magát.

Ez pedig a site-nál a konfig:

SSLRequireSSL
AuthType GSSAPI
AuthName "Login"
GssapiAcceptorName HTTP@site.domain.hu
GssapiBasicAuth On
GssapiCredStore keytab:/etc/http.keytab
GssapiUseSessions On
Session On
SessionCookieName gssapi_session path=/;httponly;secure;
SessionMaxAge 300
BrowserMatch Windows gssapi-no-negotiate
BrowserMatch Firefox !gssapi-no-negotiate

AuthLDAPUrl "ldap://ipa.domain.hu/cn=users,cn=accounts,dc=ipa,dc=domain,dc=hu?krbPrincipalName?sub?(&(objectClass=*)(!(nsAccountLock=TRUE)))" TLS
AuthLDAPBindDN uid=srv_account_site,cn=users,cn=accounts,dc=ipa,dc=domain,dc=hu
AuthLDAPBindPassword xxxxxxxxxxxxxxxxxxxxxxxxxx
Require ldap-group cn=site_access,cn=groups,cn=accounts,dc=ipa,dc=domain,dc=hu

 

szerk.: Hogy ebbe a pudvás drupalban sose tudom, hogy hogy kell normálisan kódot betenni és mindig 10 percet kell szopni, az hihetetlen.

"Sose a gép a hülye."

Sejthettem volna, megint úgy tűnik, hogy darázsfészekbe nyúltam.

Gondoltam kezdjük az egyszerűvel, csatlakozzunk LDAP-on. Ez slapd-nél eddig simán működött anonymous bind-el, titkosítás nélkül. Mivel egy gépen belül közlekedett az adat, nem zavart túlzottan a történet.

Hát a samba kicsit jobban odafigyel a security-re, szóval saját CA létesítés, CA cert szétosztás, samba TLS engedélyezés, stb.

Mondjuk én soha a büdös életbe nem értettem meg, hogy az anonymous bind, amivel kb. semmit se lehet kezdeni, mitől kevésbé biztonságos, mint random gépeken a plaintext-ben letárolt jelszó, de ezt hagyjuk. Irritál, de együtt tudok vele élni.

Na, ezzel a nextcloud-al végre össze tudtam kötni. Van egy gomb arra amúgy, hogy "trust cert", de természetesen nem működik. Ha mindent jól beállítottam akkor OK.

Most jött a második kör szívás, LDAP-al összekötöttem, csak ez a nyomorult a userekhez csinált UUID-t. User migration gyakorlatilag nincs, van egy plugin, de mindenki szidja. Végül kézzel mozgattam át a fájlokat, amit kb. egy óra alatt be is indexelt. Eddig más funkciót nem nagyon használtunk benne, most azért odafigyeltem arra, hogy a UUID legyen csak szépen a user név, ha esetleg másik auth-ra akarnék áttérni.

Harmadik: drive felcsatolása. Először is köszönjük meg a microsoft bölcsességét: tavaly ősszel deprecated lett a webdav! Yess! Egyelőre még azért működik, de nem sok jót vetít előre.

Úgy látom hogy azért nem bírom GPO-ból felcsatolni, mert itt is talán kerberos auth kellene. Kézzel persze megy, csak kéri a user/pass-t.

Ok, akkor használjuk a klienst. Szépen GPO-val fel is tudom telepíteni, hála az égnek eljutottak oda, hogy pár éve már van msi installer.

Gondoltam akkor ezt is bekonfigurálom GPO-ból. Dobpergés: nincs rá lehetőség. Helyesebben egy thread-et találtam, ahol kerülőúton, scripttel előállították a konfig fájlt hozzá: https://help.nextcloud.com/t/preconfigure-desktop-client/5916/20

Egyelőre itt tartok, de azért elég nevetségesnek tartom, hogy ezt nem lehet normálisabban megoldani.

Apache-ig még nem jutottam el, de végül lehet hogy el is engedem, inkább LAN-ban letiltom a basic auth-ot, az egyszerűbbnek tűnik.

> anonymous bind

AD-nal nincs olyan, csinalj egy service usert es azzal bindolj. TLS nem szokott kelleni.

> Először is köszönjük meg a microsoft bölcsességét: tavaly ősszel deprecated lett a webdav! Yess!

wtf? azert erdekes mert a sharepoint is azt hasznalja...  forrast linkelsz? nagy szivas lesz ha tenyleg kivezetik.

mondjuk az is vicces a windozban hogy van egy minimal webdav implementacio meg van egy rendes ami egy kulon service de az nem indul el magatol. asszem a minimal nem mukodott nalunk, ezret gpo-bol be van inditva a service minden gepen...

> mert itt is talán kerberos auth kellene

igen. eleinte en is kuzodttem basic auth-al, de nem ment, ha fel is csatolta, de megnyitottal a driverol egy pdf-et vagy doc-ot akkor kerte ujra a jelszot, mivel a tarsitott appok (acrobat/office) nem fertek hozza a path-hoz, mivel a jelszot nem kaptak meg hozza.

> Egyelőre itt tartok, de azért elég nevetségesnek tartom, hogy ezt nem lehet normálisabban megoldani.

allitolag meg lehet, ugy hivjak: MS Sharepoint :)

Pontosan azt csináltam, de TLS nélkül nem akart működni.

Samba wiki-n is fent van a kapott hiba: https://wiki.samba.org/index.php/Updating_Samba#New_Default_for_LDAP_Co…

 

A webdav-ra a nextcloud fórumokon találtam itt: https://help.nextcloud.com/t/end-of-microsoft-support-for-its-webclient…

Ez pedig a MS oldalán: https://learn.microsoft.com/en-us/windows/whats-new/deprecated-features

Én nem tudtam, hogy kettő volt, ezek szerint az egyiket vezetik ki.

( msandor v | 2024. 09. 09., h – 11:24 )

Futtat valaki sambát dockerben? Ha igen, tudna adni image nevet? Kicsit sokan töltöttek fel a docker hubra, nincs kedvem mind kipróbálni.