eset + samba pdc [volt dhcp,pxe, win logon]

[szerk]
Időközben úgy fest, hogy az Eset fogja meg a rendszerünket. Éppen ezért újragondolva a helyzetet, a következő lenne a kérdésem:
* Aki hasznal esetleg Eset Endpoint Security-t Domain Controler-vel az milyen beállításokkal használja?
* Eset Endpoint Security helyett tudtok-e ajánlani más ingyenes cuccot? (Eset Endpoint Security van intezményi licence-vel, de hát így kuka... Alternativára nincs pénz, belső háló csak ismert kliensekkel, net nélkül, de nagyon változó felhasználókkal és pendrive-okkal)
[/szerk]

Van egy kisvallalati renszerunk, 32 kliens, egy szerver.
A kliensek belso halon csatlakoznak a szerverhez (eth0) ami kilat a kuso halora(eth1).
Szerveren debian 6.06,samba(ldap) 3.5.6,isc-dhcp-server(ldap) 4.1.1,tftpd-hpa 5.0.
Klienseken XP minden updattel es domainbe leptetve, Eset endpoint security, pxe-boot beallitva, alaplapi relatek halokartya.
Kliensek mac address alapjan kapnak fix ip-t a dhcp-tol.

Kliensek pxe-n keresztul lekerik, h nekik mit is kene bootolni, ip-t dhcpvel kapnak. Majd automatikusan indul az XP local diskrol, de a halozati nem elerheto egy ideig, ilyenkor a beleptetest cache-segitsegevel ugyna megcsinalja, de a halozati profilt nem eri el a gep, de a halozati meghajtokat szepen felmappeli. Ha varok a bejelentkezessel 20mp-t, akkor mar van net, es a bejelentkezes is egesz jol megy, ugyanez ha ki-bejelentkezek ujrainditas nekul. XP-k is dhcp-vel kapnanak ip-t, nem csak a pxe-boot.

Ami erdekes: ugyanez a rendszer ment korabban, de pxe es dhcp nelkul, fix ipvel, a gond azota van, hogy ezeket bevezettem. Probaltam a pxe-bootot kiszedni, utana is ugyanez, probaltam xp-ben beallitnai fix ip-t ugyanez, probaltam grouppolicy-t arra, h bootkor legyen mindenkepp net, ez se segitett.

DHCP loggbol a kovetkezot latom:


Nov  5 08:11:59 localhost dhcpd: DHCPDISCOVER from xx:xx:xx:xx:xx:xx via eth0
Nov  5 08:11:59 localhost dhcpd: DHCPOFFER on 192.168.0.116 to xx:xx:xx:xx:xx:xx via eth0
Nov  5 08:12:03 localhost dhcpd: DHCPREQUEST for 192.168.0.116 (192.168.0.254) from xx:xx:xx:xx:xx:xx via eth0
Nov  5 08:12:03 localhost dhcpd: DHCPACK on 192.168.0.116 to xx:xx:xx:xx:xx:xx via eth0
Nov  5 08:12:36 localhost dhcpd: DHCPOFFER on 192.168.0.116 to xx:xx:xx:xx:xx:xx via eth0
Nov  5 08:12:41 localhost dhcpd: DHCPDISCOVER from xx:xx:xx:xx:xx:xx via eth0
Nov  5 08:12:41 localhost dhcpd: DHCPOFFER on 192.168.0.116 to xx:xx:xx:xx:xx:xx via eth0
Nov  5 08:12:49 localhost dhcpd: DHCPDISCOVER from xx:xx:xx:xx:xx:xx via eth0
Nov  5 08:12:49 localhost dhcpd: DHCPOFFER on 192.168.0.116 to xx:xx:xx:xx:xx:xx via eth0
Nov  5 08:12:49 localhost dhcpd: DHCPREQUEST for 192.168.0.116 (192.168.0.254) from xx:xx:xx:xx:xx:xx via eth0
Nov  5 08:12:49 localhost dhcpd: DHCPACK on 192.168.0.116 to xx:xx:xx:xx:xx:xx via eth0
Nov  5 08:13:26 localhost dhcpd: DHCPINFORM from 192.168.0.116 via eth0
Nov  5 08:13:26 localhost dhcpd: DHCPACK to 192.168.0.116 (xx:xx:xx:xx:xx:xx) via eth0
Nov  5 08:14:30 localhost dhcpd: DHCPINFORM from 192.168.0.116 via eth0
Nov  5 08:14:30 localhost dhcpd: DHCPACK to 192.168.0.116 (xx:xx:xx:xx:xx:xx) via eth0

Nem ertek igazan dhcp-hez, en itt sejtem a bajt, de mindennemu segitseget koszonettel veszek, logokat, configokat tudok adni, csak nem akartam mindent ide berakni...

Kosz!

Hozzászólások

Ha fix IP-vel is volt probléma, akkor biztos nem a dhcp okozza.
Nem az LDAP-nál van gubanc?

A felvetes jogos, de mondom a regen mukodo valtozathoz kepest szerver oldalon csak a plusz dhcp+tftp valtozott, kliens oldalon meg a pxe boot, dhcp a win alatt illetve a windows update-k.
En gyanakszom valami cache dologra is, de ezugyben levo teljesen tapasztalatlan vagyok, ezert is fordultam ide.

Kosz a valaszokat!
Most volt idom jatszogatni a gepekkel egy kicsit, erdekes eredmenyek vannak.
Ha csak a pxe-bootot szedem ki, vagy csak a win dhcp-t, akkor mindig jelentkezik a hiba.
Ha nincs pxe-boot, es fix a win ip, akkor nemely gepen rendbejon a dolog, nemelyeken nem.

Belso halorol nincs kifele nezes, ezert dns sincs. Bar azt latom az iptables logokbol, h vannak dns keresek blokkolva, de ennek ezeddig sok jelentoseget nem tulajdonitottam, mert belso halon ip alapon tortenik minden cimzes, illetve wins is megy. Itt lenne a hiba? le lehet tiltani a dns nevfeloldast vhogy lokal halon, vagy pont hogy azt kene engednem?

Kosz!

Virtualizaltam az egesz kornyezetet, es igy is jelentkezik a problema, tehat nem hw/bios nyugnek latszik.

Egyelore oda jutottam, hogy ha van egy lease, akkor a server nem ad egy ideig uj ip-t. Ha a default-lease-time -t es a max-lease-time -t eleg alacsonyra leviszem, akkor megy minden jol. Pedig a kerdeses gepek mind fixed address-t kapnak mac alapjan, igy sok ertelme nincs a suru lease-nek.
Tehat azt latom, h ha a pxe ker dhcp-n cimet, akkor utana a win bootkor egy ideig nem fut le a teljese cim kiadas, csak kis idovel. Erre van valami akar szerver akar kliens oldali megoldas?

kicsit tisztabban:
klienseknek mindig ugyanaz az ip kell, ezert ket megoldas johet szoba, azok kozt valtogattam:
fixdhcp: mac address alapjan dhcp adja a cimet
fixip: kliensben beallitottam a cimet

Win alatt mindket verzioval probalkoztam, pxe alatt nem ismerek fix ip-s megoldast, igy ott a pxe boot ki-be kapcsolasaval jatszottam. A negy kombinacio kozul egyik se mukodott megbizhatoan (hol jo, hol nem), a kikapcsolt pxe-fixip paros se, pedig korabban ez a konfig tokeletesen mukodott, azota csak a dhcp jott be.

Amire en gyanakszom, az az, h a dhcp berleti idok nem jarnak le, es azok okozzak a veletlenszeru mukodest. Az latom, h ha tul surun erkezik dhcpdiscover a serverre, akkor esik panikba.

dhcp ldapbol jon, bemasolom azt:


dn: ou=DHCP,dc=serverdn
objectClass: top
objectClass: organizationalUnit
ou: DHCP

dn: cn=dhcpserver,ou=DHCP,dc=serverdn
objectClass: top
objectClass: dhcpServer
cn: dhcpserver
dhcpServiceDN: cn=dhcpconfig,ou=DHCP,dc=serverdn

dn: cn=dhcpconfig,ou=DHCP,dc=serverdn
objectClass: top
objectClass: dhcpService
cn: dhcpconfig
dhcpPrimaryDN: ou=DHCP,dc=serverdn
dhcpServerDN: cn=dhcpserver,ou=DHCP,dc=serverdn
dhcpOption: routers 192.168.0.254
dhcpOption: domain-name-servers 192.168.0.254
dhcpOption: ntp-servers 192.168.0.254
dhcpOption: netbios-name-servers 192.168.0.254
dhcpOption: subnet-mask 255.255.255.0
dhcpOption: broadcast-address 192.168.0.255
dhcpOption: netbios-dd-server 192.168.0.254
dhcpOption: netbios-node-type 8
dhcpOption: time-servers 192.168.0.254
dhcpStatements: ddns-update-style none
dhcpStatements: default-lease-time 20
dhcpStatements: max-lease-time 20
dhcpStatements: filename "pxelinux.0"
dhcpStatements: next-server 192.168.0.254
dhcpStatements: authoritative
dhcpStatements: log-facility local7
dhcpStatements: one-lease-per-client true

dn: cn=client001,cn=dhcpconfig,ou=DHCP,dc=serverdn
objectClass: top
objectClass: dhcpHost
cn: client001
dhcpStatements: fixed-address 192.168.0.1
dhcpOption: host-name "client001"
dhcpHWAddress: ethernet xx:yy:zz:00:11:22

dn: cn=192.168.0.0,cn=dhcpconfig,ou=DHCP,dc=serverdn
objectClass: top
objectClass: dhcpSubnet
cn: 192.168.0.0
dhcpNetMask: 24
dhcpStatements: deny unknown-clients
dhcpRange: 192.168.0.117 192.168.0.210

eredetileg ugy volt, ez mar a probalkozas eredmenye:( de persze kiszedem, hatha ez akadalyozza a tobbi probalkozast, tesztet..
Mindenesetre kosz a segitseget!

szerk:
amit megoldasnak latok: berlesi idot lerakom alacsonyra, es a klienseken win alatt tudok beallitani fix ip-ket. Es akkor elvileg a dolog rendben lehet. Mondjuk a halozati klonozast lassitani fogja a sok dhcp keres, de hat ez van.

Játszogattam meg egy kicsit, es sikerult melyebbre jutnom a tortenettel. Megpedig az a franya Eset Endpoint Security fogja meg a dhcp-t, meg a netet. Egy korabbi bejelentkezes gatlo hulyesege miatt a teljes halozati forgalom szuro reszet deaktivaltam, mivel ugy is helyi halon van. Ugy fest a halozati szures deativlasa meg jobban betesz a halozatnak, mintha aktiv lenne.

Tehat a kerdes ujrafogalmazva:
* Aki hasznal esetleg Eset Endpoint Security-t Domain Controler-vel az milyen beallitasokkal hasznalja?
* Eset Endpoint Security helyett tudtok-e ajanlani mas ingyenes cuccot? (Eset Endpoint Security van intezmenyi licence-vel, de hat igy kuka...)

Nem tudom milyen ESET licencetek van, de szerverre inkább az ESET File Security for Windows Server javasolt.

Bocs, nem olvastam el rendesen.
Viszont ilyet nálam is csinál, de nem az ESET, hanem az XP. Létezik rá egy GP beállítás, amit minden gépen be tudsz állítani (gpedit.msc), és arra vonatkozik, hogy a bejelentkező képernyő megjelenítése előtt várja meg a hálózat elindulását.
Computer Configuration\Administrative Templates\System\Logon\Always wait for network at computer startup and logon

4-es NOD, de nem minden gépen jelentkezett a gond, a lecserélt gépek közül csak páron. Én inkább hálókártya +driver vonalon indultam el, egy fix 100-ra beállítva meg a kártya energiatakarékos funkciót kikapcsolva pár meg is javult. Én nem hiszek a víruskereső problémakörben, pláne hogy mióta lecseréltem a 100-as switch-et egy gigabites-re a pár megmaradt problémás gép is "megjavult".

Rózsár Gábor (muszashi)