AD authenticatie netwerk poorten

[blaatpraat]

Iemand die weet welke poorten er op een firewall moeten opengezet zijn om AD authenticatie mogelijk te maken?

Langer verhaal:
Wij hebben een domein met veel PC's.
Een aantal PC's zullen verhuizen naar een untrusted zone.
Vanaf die zone wil ik zeer strikt zijn met poorten openzetten richting de AD servercluster.
Enige dat dus moet kunnen, is dat het mogelijk dat users kunnen inloggen.

De documentatie van Microsoft is zeer karig hiermee alvast.

[Sasuke]

135, 445, 88, 389,686, 3268,3269, 49152-65535

135 en de poort range zijn zowel tcp als udp nodig. Die grote Port range kan je kleiner maken, maar is niet supported of aan te raden. (Vereist reg changes op alle dc’s)

Niet vergeten dat je die poorten moet openzetten naar alle, of toch de meeste, dc’s aangezien niet alle AD operaties site aware zijn.

Opgelet, NAT of Multihomed IP op domain controllers of communicatie tussen cliënt en DC zijn niet supported en geven zeker issues.

Clients in DMZ to AD in Lan... not done

Betere oplossing is om een DC (geen readonly !) in die untrusted zone te zetten en je comms limiteren tot die DC. Zolang je geen oude NTLM authenticatie dingen doet werkt dat wel.

[Fatsie]

Toch beter een apart domein in DMZ met een trust naar binnen (als dat nodig is); Op die manier staat je main AD database niet in een onveilige zone. Many ways to skin a cat ...

[ITnetadmin]

Zou je niet beter een RODC (read only domain controller) opzetten in een speciale DMZ hiervoor?

Also, aub met VPNs werken, ook voor untrusted zones; niet zomaar poorten naar het internet openen.
Poorten voor auth openen is zee zeer exploiteerbaar.

[CCatalyst]

Idd, Zero Trust toepassen.

[Fatsie]

Zou je niet beter een RODC (read only domain controller) opzetten in een speciale DMZ hiervoor?

Het nadeel van een RODC is dat deze wel gewoon uw volledige AD database heeft.

[Kiwivogel]

Waarom geen VPN client of een kleinere firewall meegeven aan die mensen? Poorten openzetten naar het www

[profke]

cached credentials laten toe dat ze ook zonder AD-connectie kunnen inloggen

daarna vpn-tunnel laten opzetten naar je beveiligde zone

En dan kan men de company resources raadplegen.
(en hun paswoord wijzigen enzo)

[ITnetadmin]

Het nadeel van een RODC is dat deze wel gewoon uw volledige AD database heeft.

Klopt wel.
Alternatieven?
Zoiezo denk ik dat de gewone DC openzetten naar buiten toe nog erger is; dan hebben ze de volledige database én is ie nog ns writeable ook.

[blaatpraat]

Ik had mogelijks het niet verwoord, maar de untrusted zone is geen DMZ zone, en staat niet open vanaf het internet.
Het is meer een zone waarop externe personen ook kunnen inprikken, zie het meer als een gastennetwerk waarop er een aantal corporate toestellen aangesloten zullen zitten.
Geen toegang tot 1 van de trusted zones, enkel naar het internet (op deze vraagstelling nu na).
Men heeft ook geen nood aan interne zaken op die machines, hetzij zaken die in de DMZ zitten (en dus vanaf elk toestel bereikbaar zijn).
Enige waarvoor men wel interne toegang nodig heeft, is om te kunnen inloggen met de corporate creds.

Mijns inziens is de ideale oplossing Azure AD, maar zover zijn we nog niet op dit moment.

[misterjo]

Waarom moeten ze aanmelden?
Wat is de use-case waar jullie naar kijken?

[VOiD]

Waarom steek je die devices niet in aparte VLANs met 802.1x voor de domain joined machines ?

[Sasuke]

Zo doen wij het ook ... Network Access Controle op basis van computer certificates en de corporate WiFi overal doortrekken waar nodig. Geen corporate op guest of vice versa. Corporate owned smartphones hebben op alle locaties een aparte vlan/WiFi om 4G usage te verminderen waar mogelijk.

Heb je natuurlijk wel switchen en firewalls nodig die radius kunnen praten. De radius/nac zelf doen we via de Microsoft network protections services (nps / radius). Eens opgezet, geen issues meer (behalve bij cert changes )

[blaatpraat]

Omdat het netwerk waar die toestellen aan zullen komen te zitten niet gelijk is aan het netwerk waar de corporate devices zitten.
Laat ons gerust stellen: het is geen alledaags netwerk, en dat zal het ook nooit worden.
Enige koppeling gebeurt dmv een aantal firewalls.

Ik heb het nu opgelost via een andere weg, die "goed genoeg" is:
Vxlan tunnel tussen alle switches, waar deze devices zitten, gemaakt, uitbreken op de poorten waar die toestellen zitten, en aan de andere kant op een firewall laten termineren op een Q-tag, waarbij dat die tunnel toegang heeft tot de AD-controller.

Een poging om de usecase toe te lichten zonder de bedrijfskrititsche details vrij te geven:
Op een aantal plaatsen in het land staan er machines, vanwaar waar men supersnel moet kunnen bestanden overzetten naar een storage server die in onze DMZ staat.
Zie het dus als: het enige dat er nodig is, is supersnel internet, en meer is er ook niet voorzien. De bottleneck is momenteel de NIC van die machines die maar 1Gbps kan.
Maar nu kwam er opeens bericht dat er machines geïnstalleerd zijn, die zijn AD joined en de procedure naar de gebruikers is dat ze kunnen inloggen met hun eigen account... En dan begin je te denken naar oplossingen.
In plaats van lokale non-admin accounts te maken, en enkel de transfersoftware te installeren hierop bijvoorbeeld, moeten we dus opeens ervoor zorgen dat die toestellen aan de AD kunnen (dit is niet meer onderhandelbaar met de business)...

[Fatsie]

Klopt wel.
Alternatieven?
Zoiezo denk ik dat de gewone DC openzetten naar buiten toe nog erger is; dan hebben ze de volledige database én is ie nog ns writeable ook.

Apart domain voor die 'DMZ' zone met een trust naar binnen toe; Die poorten moet je toch openzetten voor een RODC of regular DC ook. Die DC die dan in de afgebakende zone staat is dan eigenlijk min of meer maar een doorgeefluik voor authenticatie & als die zijn DB moest uitgelezen worden zit er in feite niks in.

Is dat de ideale oplossing, welllicht niet, maar het is een stapje beter dan uw basis AD domain uitbreiden naar een niet vertrouwde zone.

[misterjo]

Ik zou ook delegatie van authenticatie verkiezen zoals Fatsie.

Misschien kan die software ook overweg met SAML, OpenID Connect ofzo?

[fuserke]

Ga voor always on vpn verbinding.