Připojení klienta na jiné VLAN síti do internetu
Připojení koncového zařízení do nové VLAN tak, aby mělo konektivitu do internetu a zároveň bylo k hlavnímu routeru/firewallu připojeno přes několik switchů, se provede následujícím způsobem. (Více …)
Připojení koncového zařízení do nové VLAN tak, aby mělo konektivitu do internetu a zároveň bylo k hlavnímu routeru/firewallu připojeno přes několik switchů, se provede následujícím způsobem. (Více …)
Po zjištění plnících se front na konektoru mezi interním MS Exchange serverem a edge SMTP forwarderem (realizovaným v IIS na Microsoft ISA serveru umístěného v DMZ) byly objeveny chyby, které poukazovaly na problém komunikace mezi edge serverem a doménovými kontrolery, proti kterým probíhá AA (autentizační a autorizační) proces uživatelů, kteří chtějí surfovat/posílat maily.
MS ISA někdy přestane ověřovat doménové uživatele a poškození služby RPC (nelze restartovat) způsobí nedostupnost internetu pro tyto uživatele. Některé příčiny, které mi připadají pravděpodobné, jsou uvedeny níže.
Pokud interní DNS v doméně funguje, pak je třeba na MS ISA zkontrolovat, zda je spuštěná služba IPSEC a DNS Server.
Restartujte službu “DNS Server”, restartujte službu “IPSEC” a zkuste dostupnost DNS rezoluce: (Více …)
Domnívám se, že třetí nejhotší věc na světě, která se může přihodit vám a vašemu Exchange serveru, je rozpojení mezi Exchange a doménovým řadičem (chcete-li vědět, co jsou první dvě horší, jděte do undergroundu). Vítejte na setkání s hepteridou u bronzové medaile.
“As an Exchange admin you should always worry about Active Directory. A lot of Exchange problems are a direct result of domain controller errors. Exchange actually uses only domain controllers that are global catalog servers for some functions. You should make sure that all the domain controllers are global catalog servers. Otherwise you might find that a problem with your first domain controller which is a global catalog server by default will cause Exchange not to service users anymore.”
http://www.msexchange.org/tutorials/planning-first-exchange-server.html
Protokol DHCP neumožňuje ve své nativní podobě nijak omezit nebo odfiltrovat klienty, kteří dostanou nebo nedostanou přidělenou IP adresu. To nepochybně otvírá doširoka dveře všem potenciálním záškodníkům, kterým vzniká prostor pro MitM nebo DoS útoky na samotné DHCP nebo dokonce DNS servery v organizaci
Nejen, že jsem obdržel negativní odpověď na dotaz, zda již gétéeska provozuje kryptované DNS (root doména FYI plně podporuje DNSSEC od července 2010). Není prý ještě hotov ani rámec implementace
. Proč mi guy z CZ.NICu tvrdil, že GTS už DNSSEC podporuje? Na http://www.dnssec.cz mám stále červený, zlomený klíček. Kde je pravda?
/3GB
Před ukázkou samotné možnosti optimalizace využívání paměti aplikacemi na serverech Microsoft Windows 2000 Advanced Server a vyšších je třeba uvést následující. (Více …)
V Active Directory vytvořte kontakt a přidělte mu emailovou adresu, která má být blokována (např.mad.cow@kdesi.cz). Potom v záložce “Exchange General” na kartě kontaktu nastavte, kdo může tomuto kontaktu odesílat a kdo nikoliv. (Více …)
Po připojení do vzdálené destinace nefungoval přístup na tamní interní webové služby. Proč? Čtěte dále… (Více …)
Je dobré ještě provést kontrolu DNS překladů:
> server interni_dns_server
> externi_domena.cz
…
Stejně tak aktivitu služby “DNS Client” na DNS/SMTP forwarderu (musí být “Automatic”). Pokud neprojde resolution externí domény na interním DNS, je potřeba zkontrolovat ve vlastnostech interních DNS serverů, jestli jsou nastaveny forwardery (DNS forwarder v DMZ např.).
V případě problémů s příchozí poštou ještě kontrola syntaxe smart hosta. Pokud je ve FQDN a neprochází resolution, změňte jej na IP adresu smart hosta.