Samba AD, több hálózaton át.

Fórumok

A tervezett hálózat a következő:

- Adott egy iroda, két hálózattal. Az external az lát nagyjából mindenfelé, az internal csak saját magán belül (az externalt sem látja). A külvilágot csak proxykon (vagy vpn-en) át érik el.
- Van egy teszt AD, két DC-vel (Version 4.8.5-Debian), sdc0 és sdc1. Mindkettőnek két-két IP címe, az internal és external hálózatokba lógatva. Ezekben az internal/external hálózatokban jobbára win10 van.
- Van egy külső hálózat, oda is kellene legalább egy, de inkább két DC (sdc2, sdc3) amik viszont elsősorban linux gépeket authentikálnának (ldap helyett), ezeknek a gépeknek csak egy-egy címük van, viszont látják mind az external, mind az internal hálózatot.

https://www.dropbox.com/s/refr69xlv20b6e6/pas.png

Egyelőre ott tartok, hogy az sdc0 - sdc1 összeállt, a samba-tool drs showrepl nem jelez hibát, a samba-tool dns query sdc0 IRODA.EXAMPLE.COM @ ALL -U administrator szépen listázza a tartományt, benne van az sdc0, sdc1 mindkét címével. Szóval alapvetően nem tűnik lehetetlennek.
A kinit administrator hihető időn belül (pár másodperc) lefut, van ticket.
Az órák szinkronban vannak.

De.

A samba-tool dns query sdc0 IRODA.EXAMPLE.COM @ ALL -U administrator bő húsz másodpercig fut.
A smbclient -L localhost -U% a https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Director… oldallal ellentétben nem írja hogy 'Domain=[IRODA] OS=[Unix]...'


# smbclient -L localhost -U%

        Sharename       Type      Comment
        ---------       ----      -------
        netlogon        Disk      
        sysvol          Disk      
        IPC$            IPC       IPC Service (Samba 4.8.5-Debian)
Reconnecting with SMB1 for workgroup listing.

        Server               Comment
        ---------            -------

        Workgroup            Master
        ---------            -------
        WORKGROUP            

A /etc/resolv.conf-ba az sdc0 címeit írtam mint nameservert. A journalct, logok nem írnak semmi gyanúsat.


# Global parameters
[global]
        netbios name = SDC1
        realm = IRODA.EXAMPLE.COM
        server role = active directory domain controller
        workgroup = IRODA

[netlogon]
        path = /var/lib/samba/sysvol/iroda.example.com/scripts
        read only = No

[sysvol]
        path = /var/lib/samba/sysvol
        read only = No

Szóval a kérdések:

- Amit tervezek az oké, vagy eleve hülyeség?
- A kliensek - w10 - mennyire lesznek betegek a szerteszét IP tartományokban lévő, esetleg elérhetetlen DC-k miatt? (Valahol rémlik, hogy el lehet magyarázni nekik, hogy mégis, melyikeket akarják használni)
- Miért ilyen lassú a dns lekérdezése? Gond ez?

Hozzászólások

(Valahol rémlik, hogy el lehet magyarázni nekik, hogy mégis, melyikeket akarják használni)

Site-okat tudsz csinálni (Active Directory Sites and akármi az ADUC-ban), azokkal subnethez tudod kötni a DC-ket. Innentől kezdve a site aware kliensek (gyakorlatilag kb. a Win ill. Linux alatt az SSSD) azzal kezdenek (egyébként is azzal kezdenek, de így van értelme :) ), hogy csinálnak egy kérést a tartomány címére (iroda.example.com), fognak egy random (vagy korábbról cache-lt...) dc-t, próbálnak hozzá csatlakozni (ha nem sikerül, goto next), attól lekérik a site-ok listáját, megnézi, hogy a subnete szerint ő melyik site-hoz tartozik és onnantól kezdve az ahhoz a site-hoz tartozó DC-vel fognak előbb beszélgetni (fallbackelnek más site-ra, ha a saját site-jukhoz rendelt DC-k közül egy sem érhető el).

- A kliensek - w10 - mennyire lesznek betegek a szerteszét IP tartományokban lévő, esetleg elérhetetlen DC-k miatt?
- Amit tervezek az oké, vagy eleve hülyeség?

Én beraknám egy külön VLAN-ba a négy DC-t és a tűzfalon szűrném feléjük a forgalmat, de működhet. Arra figyelj, hogy bármelyik hálózatból bármelyik DC bármelyik címére (!) indított kapcsolat/csomag vagy sikerüljön, vagy a kliens értesüljön arról, hogy márpedig ez így nem fog menni, különben mindig TCP meg UDP timeoutokra fogsz várni.

- Miért ilyen lassú a dns lekérdezése? Gond ez?

Ha tippelnem kéne az elején az auth miatt várakozik ennyit, valahol megvár egy timeout-ot, erre utal a "hihető időn belül (pár másodperc)" is. Nem kéne annyinak lennie.

nem írja hogy 'Domain=[IRODA] OS=[Unix]...'

Az smbclient 4.7-ben megváltozott a kimenete, úgyhogy ez teljesen ok (https://www.samba.org/samba/history/samba-4.7.0.html)

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

Én beraknám egy külön VLAN-ba a négy DC-t és a tűzfalon szűrném feléjük a forgalmat

Az a gond, hogy az "internal" hálóból csak http(s) jön ki. A tűzfalat se látja. Nincs kifelé route. Se. A "remote" meg viszonylag messze van (persze ettől még lehetne ugyanabban a vlanban, de nem látom értelmét).

"Ha tippelnem kéne az elején az auth miatt várakozik ennyit, valahol megvár egy timeout-ot, erre utal a "hihető időn belül (pár másodperc)" is. Nem kéne annyinak lennie."

Igen, gyanús volt nekem, hogy ez így nem ideális. Végigzongorázom a fellelhető diagnosztikákat, hátha kiderül valami sumákság.

Az smbclient 4.7-ben megváltozott a kimenete
Áh, hurrá. Köszi.

Pedig én is afelé mennék, hogy a DC-knek 1-1 IP-je legyen 1 adott hálózatban (gyakorlatilag mindegy melyikben, különbözőekben is lehetnek) és a router-eket, tűzfalakat kell megfelelően beállítani, hogy legalább a DC-k elérjék egymást szinkronizáláshoz, illetve minden kliens elérjen min. 1 DC-t.
Nem férsz hozzá a tűzfalakhoz? Ha így van, más manageli a védelmet, akkor azt tulajdonképpen jól megfarkalod azzal, hogy a DC-ket (vagy bármilyen más gépet) belógatod mindkét hálózatba :/

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Én is afelé mennék, ha lehetne. De az internalban lévő gépek nem látnak ki a saját hálózatukból, ami némiképp problémássá teszi pl. a szinkronizálást a DC-k között.
Miért baj az, ha a DC mindkét hálózatot látja?
Miért baj az, ha bármilyen másik gép belát a két hálózatba? Ha más nem, akkor a proxy szervernek muszáj, teljesen fekete lyukban nem tudnak dolgozni az emberek.

Miért baj az, ha bármilyen másik gép belát a két hálózatba?

Azért, mert a router/tűzfal való arra, hogy megfelelően szabályozva, biztonságosan összekössön 2 (vagy több) alhálózatot és ellenőrizze, szabályozza az átmenő forgalmat. Bármi más eszköz, ami fizikailag belóg mindkét hálózatba, egy potenciális veszélyforrás, ami alkalmas lehet arra, hogy kontrollálatlanul megkerüld a tűzfalat.

A megoldás nem az, hogy belógatod mindkét hálóba, hanem hogy a megfelelő IP-k között megfelelő tűzfal-szabályokkal biztosítod az eléréseket.

Az nem megy, hogy Internal-ba és External-ba is teszel 1-1 DC-t, a 2 között pedig felhúzol egy VPN-t, amin szinkronizálni tudnak?

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Hát, ami belelóg mindkét hálózatba az a DNS, DHCP szerver és a DC-k. Én nem tartok attól, hogy vagy az lxc-t vagy a sambát meghekkelik úgy, hogy azon forgalom átmenjen(*).

Tűzfalszabályokat nem tudok tenni, mert nincs IP szintű kapcsolat a hálózatok között. Persze az megoldás lehetne, hogy a DC-ket beteszem egy harmadik (negyedik) hálózatba, és arra dobálok route-okat meg szűrögetek. Még szabad portok is akadnak a routeren. Bár az is színezi a képet, hogy a remote hálózat eleve VPN-en megy, oda is kéne DC, ami persze megoldható, de a fentiek alapján, ha magát az AD-t és/vagy a DC-ket nem zavarja hogy több lábuk van, akkor nem feltétlenül erőltetném a plusz egy hálózatot.

A VPN-t először helyből el akartam vetni, mert milyenhülyeségmár, de akár működhet is. Persze picit megdobja a bonyolultságot, és nem hiszem hogy az adott esetben megérné a plusz adminisztrációt.

*) Nem, nem állítom hogy lehetetlen, de ha már azt meg tudják oldani, akkor nem ez lesz az igazi probléma.

Nham, az alvás és egy nyugodt tíz perc sokat segített, a samba-tool dns query azért várt, mert a resolv.conf-ban rossz volt a domain és a search beállítás. PEBKAC.