Win AD kliens csatlakoztatása sima Samba szerverhez

 ( Darkfish | 2019. szeptember 30., hétfő - 10:44 )

Feladat: Egy AD-s munkahelyi környezetben, sima (tehát AD nélküli) Samba szerver beüzemelése, azon megosztás létrehozása és egy-egy felhasználónak read-only megosztás létrehozása.

A gond: a win-es felhasználók, mintha nem a megadott username-mel próbálnának loginolni, hanem [domain]/[getpnev]-vel, ami nyilván nem így szerepel a samba configjában.

A kérdés: lehetséges-e egyáltalán a kitűzött feladat? Egy AD-ben lévő win kliens csatlakozhat-e egy az ADtől eltérő authentikációjú samba szerverhez?

A google sajnos nem volt barátom, de lehet, hogy nem találtam el a keresőszavak megfelelő kombóját...

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Én úgy csinálnám, hogy a Wines AD szerveren állítanám be az autetikációkat, meg a samba szerveren való mappák olvasási korlátozását. Esetleg lehet írni egy net use-os batch szkriptet, amit adott felhasználóknál lefuttat a szerver loginoláskor.
Ez is az AD előnye. Nem értem mi értelme ezt máshogy csinálni, vagy nem értettem meg a feladatot.

Az hogy van egy bugosan működő tizenvalahány éves több cég és telephely és automata szolgáltatás által használt AD, amit már senki nem mer piszkálni, mert annyira kaotikus.
Ezért a feladat egy tőle független rendszer létrehozása a párhuzamos működés mellett.

Miért nem csinálsz akkor egy Samba ADDC-t? Megcsinálod második dc-nek, majd előlépteted elsővé.
/SZERK: A régit meg lekapcsolod miután kiléptetted./
Ha meg már annyira szar állapotban van a win szerver Active Directory adatbázisa (is), hogy nem érdemes, akkor igaz melósabb, mert újra fel kell venni minden felhasználót meg gépet és minden klienst újra be kell léptetni, de hosszú távon ez a legjobb megoldás, mint foltozgatni a szart.

Én tuti így csinálnám, mert magammal sem baszok ki szívesen, meg tanáraim, szüleim alaposan belém nevelték, hogy a jó munkához idő kell, a szarhoz meg még több.
Persze nem tudom, hogy alkalmazott vagy, vagy megbízott, vagy egy megbízott cég/vállalkozás alkalmazottja.
Én alkalmazottként egy percig sem gondolkodnék ezen. Amikor én a jelenlegi munkahelyemre kerültem, nem győztem lapátolni a szart, olyan kaotikus állapotok voltak, most meg simán van időm még a trollkodásra is.

Mivel őskövület (tizenvalahány éves) Win szerver, az azt jelenti, hogy max 2008R2-es szerver, ezt már tudja Samba is egy ideje. Szóval azt javaslom, hajrá, de majd pár nálam okosabb talán megmondja a tutit, ha egyáltalán méltatnak rá. Ha én össze tudtam kalapálni egy Samba ADDC-t, nem hinném, hogy nehézséget okozna Neked vagy bárkinek, pedig állítólag nem értek semmihez a trollkodáson kívül.. Szóval majd Celtic úr talán méltoztatik kijavítani, kiegészíteni. Esetleg Mr. Gelei, hogy nem csak a beszólogatáshoz meg az it-s szlenghez ért. Várom mindkettejük korszakalkotó javaslatát.

Most, hogy kijött a nyolcas Centos, amiben már Heimdal Kerberos van és nem kell drótozni, tehát a Centos gyári repójából telepíthető és szakszerűen frissíthető.

Samba ADDC ügyben SzBlackY-t keresd. Biztos szívesen segít. Kifejezetten Samba ADDC guru. Szerintem nem is hajlandó Sambát beállítani ADDC-nélkül.

Bocsánat a fröcsögésért, de gondolom tudod, hogy itt egyre nagyobb divat az offolás, meg mások becsmérlése. Én próbálok segíteni, ha normálisan kérdeznek, segítséget meg egyre kevésbé remélek.

Köszönöm a hozzászólásodat, de miután a több cégből aki le akar válni az kb 5 fős ezért én overkillnek érzem ide az AD-t.

Meg most már, lassan tényleg kezd érdekelni az eredeti kérdés, lehet egy ADhez tartozó kliensek csatlakoznia sima samba share-ez? (Nyilván a kilépek-lokális-userral-visszalépek technikán túl)

net use /user ... csak azt használja, amit megadsz neki, nem?

Pont az a vicces, hogy úgy tűnik nem. Ezért lettem volna kíváncsi hozzáértőbb véleményére.

Plusz ugye az a kérdés továbbra is lóg, hogyha mégis csinálok új AD-t, és újra felveszek mindenkit, akkor hogyan tud a két rendszer egymás mellett élni egy ideig?
Szerintem még kevésbé mint az eredeti elképzelés.

> Esetleg Mr. Gelei, hogy nem csak a beszólogatáshoz meg az it-s szlenghez ért. Várom mindkettejük korszakalkotó javaslatát.

Nagyon beletapostam a kis lelkedbe? :'(

Amugy varhatod sokaig, eletemben nem konfiguraltam meg Sambat. Nem is tudom, honnan jott az otlet, hogy en adjak benne tanacsot.

"Nagyon beletapostam a kis lelkedbe? :'("

Nem. Csak pusztán irritálsz. Kb. ugyanannyira, mint ahogy én a lábléces linkjeimmel tettem.

"eletemben nem konfiguraltam meg Sambat"

Ja, akkor biztos fejlesztői vonalon mozogsz.

Ha már meg lettem említve :)

Milyen verziójúak a kliensek és milyen verzió a Samba?
Az smb.conf-ban milyen direktívák vannak, első körben mondjuk a security? (de egy teljes smb.conf is jöhet)
Hogy próbálod felcsatolni/elérni a megosztást?
Ha GPO-ból, ellenőrizd, hogy ne a gépre vonatkozzon.
Az OP-ban a [domain] az a tartomány, amiben a gépek vannak, vagy a workgroup, aminek a szerver a tagja?
Volt-e valaha ilyen nevű (akár csak ilyen címkéjű) fájlszerver a rendszerben és benn van-e még a fiókja az AD-ban?
Akár egy live linuxról a cifs-el fel tudod csatolni azzal a workgrouppal/usernévvel/jelszóval

Idézet:
lehetséges-e egyáltalán a kitűzött feladat? Egy AD-ben lévő win kliens csatlakozhat-e egy az ADtől eltérő authentikációjú samba szerverhez?

Semmi akadálya nincs (*), bár tényleg speciális körülményektől eltekintve nem javasolt (én pl. használok local usereknek [egy rw és egy ro] kiosztott megosztást, mert így rsync-kel könnyen áthúzható egy másik szerverre, ahol ugyanazokat az adatokat, ugyanúgy ki akarom osztani egy másik hálózatban és így nem kell az össze-vissza mappelt NTFS/SMB jogosultságokat bántani mindent rsync után).

(*): +/- persze a Windows időnként hihetetlenül ostoba implementációja (pl. "az egy szerverhez egy azonosító jegy / user, függetlenül a megosztástól" című marhaság, a "biztos, ami biztos végigpróbáljuk az összes olyan azonosítóval, amit ismerünk, mielőtt rákérdezünk a usernév" c. marhaság stb.)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Most nem tudom becsatolni a configot, de fejből válaszolok:

A kliensek Win10 és Win7, a security paraméter nincs beállítva tehát az az alapértelmezett "user".
Felcsatolni a wines rendszergazda próbálta, és én a logokból azt láttam, hogy a nem a srác által kézzel megadott username/pass páros ér a szerverhez hanem a domainnek megfelelő domain//gépnév vagy valami ilyesmi.
Ilyen nevű gép nem hiszem hogy volt, bár a hely 10éves története alatt bármi előfordulhatott.
Linuxról a bejelentkezés smbclienttel rendben volt.

"én pl. használok local usereknek"

OK, de feltétlenül local user kell hozzá vagy menne domain userrel is? Egyáltalán miért nem mindegy a win-nek, hogy milyen usernevet dob át?

+ ui:

hajlok rá, hogy az új szervert előbb csatlakoztassam a régi domainhez, majd később egy új frissen létrehozott "tiszta" AD-hez. Kérdés, hogy így nem okozok-e nagyobb galibát (gondolok itt arra, hogy mi lesz a régi wines attribútumokkal a váltás után)?

Idézet:
Felcsatolni a wines rendszergazda próbálta, és én a logokból azt láttam, hogy a nem a srác által kézzel megadott username/pass páros ér a szerverhez hanem a domainnek megfelelő domain//gépnév vagy valami ilyesmi.

Idézet:
Ilyen nevű gép nem hiszem hogy volt, bár a hely 10éves története alatt bármi előfordulhatott.

A volt igazából nem annyira lényeges, mint a van (mármint a DC-ben hozzátartozó computer fiók).

Idézet:
Linuxról a bejelentkezés smbclienttel rendben volt.

Na, ez bíztató.

Idézet:
"én pl. használok local usereknek"

OK, de feltétlenül local user kell hozzá vagy menne domain userrel is?

Local usert itt úgy értettem, hogy a fájlszerveren van helyileg mentve (passwd fájlban és persze smbpasswd jelszó hozzárendelve).

Idézet:
Egyáltalán miért nem mindegy a win-nek, hogy milyen usernevet dob át?

Mert Windows :) Az a gond, hogy próbál marha felhasználóbarát lenni, úgyhogy egy raklap dolgot fog kipróbálni (Kerberos, ha az nincs, akkor a belépett user + NLTM, ha az nem sikerül, akkor _általában_ jön a loginnév-jelszó ablak, kivéve, ha az adott szerveren egy másik share-hez már csatlakozva van a user egy másik usernévvel [ja, igen, ezt fogja legelőször kipróbálni]).

Próbáld ki, hogy feltolod a log levelt a samba-ban mondjuk 5 körülre, aztán sorban:
* csatlakozz hozzá linuxról smbclient-tel
* csatlakozz hozzá net use-al valamelyik Windows-os gépről
* net use * /delete vagy reboot után csatlakozz simán explorerben \\gépnév\megosztás és \\ipcím\megosztás formában
Az utóbbi kettő előtt/után kérj a gépen klist-tel egy listát a Kerberos ticketekről, abból kiderül, hogy akar-e (és elvileg tudott-e) ticketet kérni a géphez, amiről nem kéne tudnia a DC-nek

Aztán nézegesd (vagy anonimizáld és dobd fel pastebinre) a logokat. _Elvileg_ azt kéne látnod, hogy az első és második esetben azonnal sikeres auth, a harmadiknál egy kisebb raklapnyi sikertelen auth után a bekért felhasználónévvel és jelszóval sikeresen authol.

Idézet:
+ ui:
hajlok rá, hogy az új szervert előbb csatlakoztassam a régi domainhez, majd később egy új frissen létrehozott "tiszta" AD-hez. Kérdés, hogy így nem okozok-e nagyobb galibát (gondolok itt arra, hogy mi lesz a régi wines attribútumokkal a váltás után)?

Itt-ott lábon tudod lőni magad vele (az említett jogosultságok, a mappelt uid/gid-ek), szépen scriptelhető és javítható az átállás után, de nem javasolnám.

Szerk.: ill. kérdezd meg a Wines kollégát, hogy hogyan próbálja felcsatolni és ugye nem a gépfiók nevében kísérletezik (az a domain//gépnév még mindig gyanús, azzal nem kéne a kliensnek bepróbálkoznia)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

net use X: \\server\share /user:\nem_AD_user password /P:yes

Szia!

Ha csak fájlmegosztás kell:
https://nextcloud.org/