Megoldva: Zentyal, samba-ad-dc sebesség probléma

Web, mail, IRC, IM, hálózatok

Sziasztok!

 

Adott egy Ubuntu 20.04-re telepített Zentyal7. Ez domén kontrollerként működik, a realm-je IRODAHAZ.LOCAL, workgroup irodahaz és a netbios name az iroda.

 

A probléma az lenne, hogy a login-logout folyamatok nagyon lassúak egyes klienseken. A hálózatuk rendben van. A barangoló profilok aktívak. Ha belépve készítek új mappát az asztalon, kilépés után 10--15 percig is áll le a gép és csak utána jelenik meg a /home/samba/profiles/<fh.nev>/desktop helyen a fájl.

A kliensek Win 10 Pro gépek.

 

A nyomozgatásom során néhány érdekességbe botlottam, de nem tudom, van-e köze a problémámhoz.

 

A syslog-ban elég gyakoriak az ilyen jellegű hibák

smbd_audit:   chdir_current_service: vfs_ChDir(/home/samba/profiles) failed: Permission denied. Current token:...

A profiles mappán belül minden mappa megfelelően a felhasználók tulajdonában van, meg ahogy írtam, rendben megjelennek a fájlok, módosítások a profilokon.

 

A másik, hogy a samba-tool parancsnál pl. egy DNS query esetében ha az első paramétert, vagy is a server-t úgy adom meg, hogy IRODAHAZ.LOCAL akkor dob egy kerberos hibát:

Server host/IRODAHAZ.LOCAL@LOCAL is not registered with our KDC: Miscellaneous failure (see text): Server (krbtgt/LOCAL@IRODAHAZ.LOCAL) unknown

Ha viszont IRODA.IRODAHAZ.LOCAL formában teszem, akkor már nem dob hibát. Mindkét esetben lefut a dns query, vagy ha rekordot módosítok.

 

Nem tudom, merre tudnám tovább keresni a hibát. A gépet, Samba-t már számtalanszor indítottam újra, így most a közösség erejében bízom:D. Google sajnos nem segített és a Chat GPT sem.

 

A megoldás (május 5.):
Át kellett írni a stubs-ban a Samba konfigurációs fájlját, hogy csak az eth1 (belső) és lo interfészen hallgasson, az eth0-n ne. Ezt követően a host parancs már csak a belső címet adta az irodahaz.local-ra és iroda.irodahaz.local-ra is.
A tűzfalon nem engedte be az RPC porttartományát (49k valamennyitől 65000-ig). Megoldás a tűzfalon minden bejövő kapcsolat engedélyezése a belső hálóról, majd, mivel így megy, finomhangolás, hogy amire nincs szüksége mindenkinek, ne érje el.
Végül biztos ami biztos alapon azt a beállítást is engedélyeztük, ami azt teszi lehetővé, hogy a Zentyal a más DNS szerverekre irányuló kéréseit is a saját forwarderével kezelje le. Mivel csak AD-s gépeket szolgál ki, amiken a mi DNS-ünknek kell működnie, ez inkább fő a biztonság jellegű beállítás. Jelenleg úgy néz ki, működnek a barangoló profilok is.

 

Köszönöm mindenkinek a hozzászólásokat, ötleteket és segítséget!

  • 742 megtekintés

( n.balazs v | 2023. 04. 28., p – 18:31 )

1. lépés: A DNS legyen rendben. Az IRODAHAZ.LOCAL-nak feloldhatónak kell lenni mindenhol. A klienseken a diagnosztikai parancsoknak se szabad hibát adniuk.

2. lépés: Az a chdir_current_service elég csúnyának tűnik. Szerintem a könyvtárokon nincsenek rendben a jogosultságok. Pontosan milyen jogosultságok vannak a /home/samba/profiles könyvtáron?

Köszi a gyors választ!:)

 

1. kérdésre: Rendben visszaadják, de ezzel futunk még egy kört. Biztos, ami biztos:)

 

2. 
drwxrwx---+  4 root IRODA\domain users 4096 máj   24  2022 .
drwxrwx---  40 root IRODA\domain users 4096 ápr   28 16:22 profiles
drwxrwx---+ 20 root IRODA\domain users 4096 máj   24  2022 shares
Azaz a domén userek hozzáférnek.

TheAdam

2. IRODA \ domain users hozzáfér. De ott még azért hiányzik pár csoport szerintem. A profiles könyvtáron nem látok ACL-eket.

Lásd:
- https://learn.microsoft.com/en-us/windows-server/storage/folder-redirec…
- https://www.itpromentor.com/profile-permission/

Szerintem azzal a részével nincsen probléma. Ez nálam is pontosan így néz ki...

-rwxrwx---+  1 VEHICULUM\vehihazdolg VEHICULUM\domain users   236060 szept 29  2021  doksi.pdf

A plusz jel mögött vannak a samba-s ACL-ek. A plusz előtti szakaszt csak a Linux használja.

Viszont:
A barangoló profilokkal személy szerint nincsenek jó tapasztalataim még Windows szerver környezetben sem. Azt a részt én ki is kapcsoltam a Zentyal-ban.
A másik ami megkapta a szemem, a .LOCAL . Ne használd a LOCAL-t Linux tartományvezérlők esetén! Ez egy Microsoft-os baromság, és tud problémákat okozni ebben a környezetben! Ezt valószínűleg csak azért találták ki, hogy nehogy már azt alkalmazzák, mint mindenki más. Használd a .LAN-t. Tisztább szárazabb érzés.

Köszi!

 

Barangoló profilok: Sajnos ezt nem biztos, hogy ki tudjuk vezetni a felhasználói igények miatt, de mindenesetre futok vele egy kört.

 

A meglévő AD-t vajon tudom fájdalommentes (vagy legalább relatív fájdalommentes) módon módosítani, hogy .LAN legyen? A konfigban át tudom írni, de ez nem fog egyéb gondot okozni azon túl, hogy rejoin-olni kell majd a klienseknek?

TheAdam

Biztos meg lehet oldani, bevallom még nem próbáltam soha. Ha csinálnám, biztos hogy egy virtuális környezetben próbálnám ki először. De biztos lesz itt valaki, aki megnyugtatóbb választ tud neked adni erre a kérdésre.

Viszont ennek a LOCAL-os dolognak nemigen van köze az eredeti problémához, ezt csak nem tudtam nem észrevenni.

"Barangoló profilok: Sajnos ezt nem biztos, hogy ki tudjuk vezetni a felhasználói igények miatt, de mindenesetre futok vele egy kört."

Tényleg annyira fontos, hogy minden bejelentkezési helyen ugyanaz az asztal fogadja őket?
Alapból van a felhasználóknak egy saját hálózati helyük (Zentyal-ban (is) a /home mappa alatt, ami elérhető akár intézőből is. Tedd ki nekik parancsikonként az asztalra, aztán csak megbeszélés kérdése, hogy amit abba tesznek, azt minden munkaállomásról elérhetik.

Kérdés: milyen felhasználói igény igényli a barangoló profil használatát?

A tartományt nem tudod módosítani. Windows-on sem, Samba esetén sem. Ki lehet dobni, lehet új tartományt csinálni, és vannan tool-ok melyekkel a klienseket át lehet "léptetni" az új tartományba a felhasználói profil tényleges mozgatása nélkül. Csak ilyen szépség-ügyileg én nem javasolnám ezt a lépést.

A barangoló profilnál nagyon nem mindegy, hogy a felhasználó adatokat is tart benne, vagy csak "beállításokat". Tehát hogy kerül-e bele adatállomány levelezés, ilyesmi, vagy csak a ProgramData tartalma van a barangoló profilban, maguk az állományok pedig a felhasználó privát megosztásán pl. Ahogy más is írta, a barangoló profil tisztán Windows környezetben sem fáklyás menet. Akinek ilyen igénye van, az inkább áttért Terminal Services-re, akinek meg nem olyan fondos, az nem használja.

Egyébként miért kell a barangoló profil? Olyan jellemző, hogy a felhasználók mindig más gép elé ülnek le? Mert ugy értelme csak akkor van, ha "közös" PC-k vannak, amit össze-vissza használnak.

Köszi! Igen, közösek a gépek, van amit többen használnak. Igaz, azügyben közben egyeztettünk, hogy a barangoló profil kikapcsolása mekkora problémát okozna, ideiglenesen meg fogjuk próbálni.

@ggallo Köszönöm!:) csak Windows-ok vannak, Apple maximum saját eszközként, de az úgy is külön hálózat.

Arra én is gondoltam, hogy zűr lehet a kliensek AD-vel való kapcsolatában, de őszintén tippem sincs, hogy pontosan mi. Csekkoltam rpcclient-tel linux-on localhost-ról, működik rendben. Megnéztem az ACL-eket, azok is rendben vannak. Ami érthetetlen számomra, hogy a Zentyal-ban az eth1-es interfész meg van jelölve belsőnek, ezen van az AD és az eth0 külsőnek, ezen jön be a net, DHCP-vel. Viszont a host parancs és úgy általában a nslookup-ok következetesen úgy adják vissza, hogy két címet küldenek. Egy az AD belső címe és egy a külső, netszolgáltatós cím. Ha kézzel kitörlöm a samba-ból, akkor szorgalmasan visszaírja, gondolom a Zentyal. Valahogy tehát azt kéne elkerülni szerintem, hogy bekerüljön A rekordnak a gép külső IP-címe, mert azon valóban nincs AD, bár arra még nem jöttem rá, hogy ha belső hálóról próbálja a külső címet, az okozza-e a problémát, de jelenleg erre kutakodok, hogy miként tudnám Zentyal-specifikusan kidobni a külső címet az AD-ból. A Samba konfig smb.conf módosításán már gondolkodtam, de azzal az a gondom, hogy a Zentyal vajon mikor fogja felülírni, jobb lenne valamilyen Zentyal-féle módszer, viszont a Samba konfig módosítása a webgui-ról csak commercial kiadásban lehetséges:(

Ja igen, ma egy zsír új telepítésű gépet beléptettünk. Marha lassan lépett be, jelzett, hogy RPC-t nem éri el, utána pedig irgalmatlan lassan lépett be a felhasználói fiókba, legalább fél órát vacakolt, de lehet, több is volt az. A DNS probléma okozhat vajon ilyet, hogy ha nem megy az egyik IP, mondjuk a külső, akkor több, mint 10 perc kell, hogy a másikkal próbálkozzon? Nagyon fura...

TheAdam

A Zentyal nem teszi be a saját (AD) DNS-ébe a külső (pláne dinamikus) címét az AD-s nevéhez. nem tudom, hogyan kaphatos meg nslookep-al az iroda.irodahaz.local névre a gép külső címét.

Biztosan csak az AD szerver belső címét kapják a kliensek DNS szervernek a DHCP-től?

Milyen verziójú a Windows 10? 22H2 esetén gond lehet a nem-friss Samba-val (a Zentyal-é pedig nem friss sajna...), mert komolyan változtatott a Microsoft a (hitelesítésen? használt algoritmuson? már nem emléxem), ami aztán a nem-Windows AD szerverek esetében gondot okoz (meg a nem frissített régebbi eredeti Windows Server-nél is). Ezt úgy kerülték meg sokan, hogy 22H2-nél régebbi Win10-et telepítettek, AD-be léptették, majd utána frissítették. Ha már belépett, akkor nem csinál gondot az új verzió. Emlékeim szerint Windows 11 22H2-nél viszont csak a frissíttett 4.16+ Samba verziók lesznek jók (ami pl. Univention szerverebn elérhető).

A Windows kliensekről futtasd azokat a parancsokat, amiket írtam AD tesztre példának. Az, hogy a Zentyal szerveren az rpc teszek sikeresek, nagyjából annyit mutat, hogy a Samba fut...

Igen, a gépek csak az AD szerver belső címét kapják DNS-nek a DHCP-től. Az ad szerverről

host irodahaz.local localhost

irodahaz.local has address 80.xxx.xxx.xxx
irodahaz.local has address 10.2.2.254

Ugyanez arra is, ha iroda.irodahaz.local-t kérem le.

 

Ez az Univention milyen a Zentyal-hoz képest, van vele gyakorlati tapasztalatod? Ha van, mi a véleményed róla?

 

Hűha, na ez a Windows 10 jó kérdés. A mai teszt 22h2-es gépen történt, de ezt akkor megnézzük, hogy ahol probléma tapasztalható, milyen a Win10 verziója és ahol mostanáig semmi gond, ott milyen.

 

Köszi a parancsokat, lefuttatjuk, meg fogjuk nézni és visszajelzek!

TheAdam

Ebbe én is belefutottam. A megoldás: készíts egy stub fájlt amiből a samba konfig generálódik, és csak a belső hálózati interfész legyen a samba-nak kijelölve. A stub fájlokkal szépen kézben tudod tartani, nem törik meg semmi, erre való.

 

https://doc.zentyal.org/en/appendix-c.html#stubs

Köszi!

Átmásoltam a /usr/share/zentyal/stubs/samba/smb.conf.mas fájlt a /etc/zentyal/stubs/samba mappába és átírtam az interfaces = <% $ifaces %> sort arra, hogy interfaces = eth1 (eth1 a belső hálózati if).

 

Innen nyomjak rá a mentésre a webgui-n, az majd újraépíti a DNS-t is? Hogyan tudnám ezt a rebuild dolgot megcsinálni a parancssorból, hogy ne kelljen a webgui-val maszatolni?

 

Estig csak elméleti okfejtés, most dolgoznak rajta, így addig igyekszem körbejárni, hogy akkor már csak élesíteni kelljen:)

TheAdam

A DNS-ből kézzel kell kitörölni (tapasztalataim szerint). Parancssorból kb így:

sudo zs zentyal-samba restart

A "zentyal-samba" az a modul neve (lehet simán samba). Észre fogod venni ez után ha elkészült az új konfig fájl, mert aktuális lesz a timestamp-je, plusz abban a sorban az általad módosított adatnak kell lennie.

Én többnyire Windows Server mellett használom "másodlagos" DC-nek a Zentyal-t, ott futottam bele ebbe.

+ ezen kívül milyen a hálózat sebessége (megvan-e a gigabit mindenhol vagy van valahol 100-as switch is közben) illetve mekkora a profilok mérete? Nálam is sokáig volt roamin profile és bizony telihányták az asztalt 10-20 gigákkal és bizony idő volt a kilépés. (mondjuk nem 10-15 perc, de 2-3 perc igen)

A .local valójában nem okoz gondot tisztán Windows szemszögből nézve.

Azt mondja az álmoskönyv, hogy amennyiben Apple termék is van a hálózaton, azoknak okozhat kellemetlenséget a .local végű Windows domain, mert az Apple cuccai ezt a tartományt használják mDNS vagy hasonló (nem ismerem pontosan) célokra.

( theadam | 2023. 04. 30., v – 09:05 )

@PeterX: Nem IT-sok használják a rendszert, emiatt ragaszkodnak hozzá. De futunk vele egy kört, hátha meg lehet válni a témától. Csak így a saját beállításaikat, alkalmazásaikat (pl. levelező, böngésző előzményekkel) bukják el, amit nem biztos, hogy olyan egyszerűen lenyelnek:D

 

@muszashi: Apró szöveges fájlok vannak az asztalon, szóval semmi extra. Az egyetlen nagy profil az 30 GB, de a vicc, hogy az pont lépked ki-be mint a villám.

 

Megpróbáltuk kiléptetni majd újra be az egyik gépet a domain-be, ott végre kibökött annyit, hogy gondja van az RPC szerverrel. Mindazonáltal gond nélkül megjelent, belépett és be lehet jelentkezni, lehet dolgozni. Csak piszok mód lassú. Doménen kívül pörög rendesen a gép. Amikor be van léptetve, néha még a Windows 10-es login képernyő is lassan jön be, ahol meg kell nyomni valami gombot a billentyűn vagy kattintani kell az egérrel, hogy bejöjjön a jelszó ablak. Lövésem sincs már tényleg, hogy mi lehet, hogy egyáltalán a Samba-Zentyal AD oldalán, vagy a Windows-én keresendő a gond? De ha a Windows-én, miért csak random néhány gépen jött ki és számos másik gépen meg nem? Még a havi PatchKedd-en érkezett frissítésre tudok gondolni, mint hibás tényező, de megint kérdés, hogy az ugyanúgy telepített gépeknek miért csak egy része érintett...

TheAdam

( theadam | 2023. 05. 03., sze – 16:07 )

Hali!

 

Történt némi előrelépés. Azt már sikerült behatárolni, hogy látszólag az AD és a Windows-ok is rendben vannak. HA csekkolom a getfacl paranccsal a jogosultságokat, az is rendbenlévőnek tűnik.

 

A problémám viszont az, hogy Windows-ról nézve a mappák tulajdonjogainál is csak egy s betűt és sok számot mutat. Ez elvileg a security ID-k.

 

Mi okozhatja, hogy bár a szerveren látszólag rendben van ez a rész, de a Windows-okon security ID-k látszanak és instabil az egész AD, leginkább lassú?

TheAdam

Az okozza az S-* kiírást, ha a kliens nem tud a DC-vel beszélni, és így nem tudja lekérni, hogy a SID-ek milyen ember számára néven futnak. Tehát az AD kapcsolat valószínű nincs rendben.

Azt sem tartom kizártnak, hogy valójában local cache-ből lépnek be a gépek nem a DC hitelesíti őket. Az összes AD tesztet megnézném a kliensekről (pl. nltest /sc_query:irodahaz.local, nltest /dsgetdc:irodahaz.local, gpresult /r)

( theadam | 2023. 05. 04., cs – 20:06 )

Helyreraktam a DNS-eket, módosítottam a template-t. Így most az smb.conf csak a lo-ra és az eth1-re bind-olja a Samba-t. A host irodahaz.local is rendben visszaadja az egyetlen IP-címet, ami a belső hálón a gépé.

 

Viszont, ha megosztást nyitok meg távolról, VPN-en át, egy másik subnetből felcsatolva a meghajtót, továbbra is ez a hiba elég gyakran megjelenik, meg még sok más hasonló a fájlokra vonatkozóan.

May  4 19:55:05 iroda smbd_audit: IRODAHAZ\felhasznalonev|192.168.161.25|freaddir_attr|fail (Operation not supported)|/home/felhasznalonevem/teszt.txt
May  4 19:55:05 iroda smbd_audit: IRODAHAZ\felhasznalonev|192.168.161.25|freaddir_attr|fail (No data available)|/home/felhasznalonevem/teszt.txt

A helyi subnetből már csak holnap lesz lehetőség tesztelni. A DNS át lett lőve itt a gépemen a teszt idejére, nslookup feloldotta rendben a címeket, viszont a tudomány továbbra is ott van megrekedve, hogy jön a fentebbi hiba és s-sokszám jelenik meg a biztonság fülön.

 

Csekkoltam azt is, hogy mi történik egy másik samba megosztáson. Van egy háziszerverem, ezen faék egyszerűre van fellőve a samba. APT-vel felraktam (Debian 11), felraktam egy share-t és a smbpasswd -a-val hozzáadtam magam.

Itt a DNS sincs beállítva, wireguard-on érem el, szóval semmi szabványos nincs benne, de még is működik. HA megnyitom egy fájl biztonság fülét, egy darabig az ID-ket látom, de utána kitölti unixgroup\felhasznalo formátummal, ami végül is jó.

 

Ilyen formán még esetleg valakinek van valami ötlete? A tesztelős parancsokat amiket ggallo írt, még nem futtattuk, de folyamatban:)

TheAdam