[XP/2003] IPsec - verkeer tussen server<>client securen*

[Verwijderd]

Hoi Allemaal,

Ik ben een poging aan het wagen om de wereld van IPsec beter te begrijpen.
Ik heb een Windows XP SP2 Workstation en een Standaard Windows 2003 Server met SP1.
De Windows 2003 server heeft de volgende rollen: AD Domain Controller, Global Catalog Server, DNS server, SUS server en Web en ftp server.
Ik wil in eerste instantie gebruik maken van de standaard IPsec policy's (Client, Server en Secure Server).

Wanneer ik de IPsec policy's op mijn werkstation apply (d.m.v local policy's of groups policy in Active Directory). lijkt alles goed te gaan. De local IP-sec Monitor verteld me dan een hoop info.

Echter wanneer ik een policy op mijn Windows 2003 server apply (bijv. Server "Request Security") (zowel local als via GPO). Lijkt alle toegang tot de server en dus ook AD op slot te worden gezet.

aanloggen op de server met mijn workstation wil niet meer

- ik ga er van uit dat ook windows servers met deze policy's moeten kunnen werken, toch ?
- kan het zijn dat er wat extra diensten moeten worden open gezet in de IPsec policy van de server ?

iemand enig idee / suggesties wat hier mis gaat ?

[Guldan]

In de ipsec policy van de server moeten idd een aantal dingen insteld worden. DNS, SMB etc. anders kun je idd niet inloggen via de AD. Een howto is te vinden in de faq: hier Dan moet het lukken.

[ Voor 16% gewijzigd door Guldan op 17-02-2006 16:40 ]

[Verwijderd]

Dat vermoeden kreeg ik al. Ik ga je howto gelijk even uitproberen.. thanx.

- is er ook ergens een lijstje beschikbaar waar het minimale op staat om ipsec op een domain controller werkend te krijgen, daarmee bedoel ik welke protocollen kunnen niet overweg met ipsec op een domain controller? mijns dns server is bijv. in active directory geintegreerd moet ik dan alsnog dns verkeer toelaten, omdat dit niet ipsec-aware is ? ondanks dat mijn dns via active directory wordt gerepliceerd.

[alt-92]

Natuurlijk moet dat.
Hoe wil je anders via 53TCP/UDP een DC laten registreren in DNS (ook al is die AD integrated, loopt nog steeds over tcp/ip).

Wat voor verkeer een DC nodig heeft (ook GC) kun je eventueel ook vinden door te zoeken op firewall rules in ISA Server bijvoorbeeld.
Een frontend/backend setup voor Exchange heeft ook toegang tot AD nodig:"

code:

LDAP to Directory Service:
389/UDP
389/TCP
LDAP to Global Catalog Server: 
3268/TCP
Kerberos Authentication:
88/UDP 
88/TCP

Daarnaast ook nog RPC:
http://support.microsoft.com/?kbID=224196

[ Voor 63% gewijzigd door alt-92 op 18-02-2006 11:34 ]

[Verwijderd]

ik ben bezig een template te maken voor mijn DC. Ik maak gebruik van de de standaard instellingen van het Request Security template. Dit zou volgens mij al voldoende moeten zijn om een client/server opstelling met IPsec te laten werken. kan het protocol de encryptie enz. aan dan maakt hij daar gebruik van, kan het protocol het niet aan zoals DNS dan maakt hij er geen gebruik van.

in de praktijk blijkt bovenstaande iig niet te kloppen. behalve als het security template niet op de DC zelf wordt toegepast.

ik wil mijn security template voor de DC nu zo modificeren dat hij op mijn DC toegepast kan worden.

hoe kan ik nu no IPsec aware protocollen (zoals DNS,WINS en DHCP) excluden.

ik wil zoveel mogelijk van de encryptie/authenticatie gebruik maken.

[ Voor 4% gewijzigd door Verwijderd op 19-02-2006 18:00 ]

[Verwijderd]

Ik heb nu ook nog inbound en outbound filter lists aan de IP security rules toegevoegd, zoals beschreven in de "howto voor de webserver" echter jammer dat hier geen encryptie in wordt gebruikt. Dit dan voor DNS (port 53 tcp en udp)en HTTP (port 80 tcp) verkeer. voor inbound en outbound zijn de filter actions op Permit gezet..

echter nog steeds hetzelfde resultaat, nu deze GPO met deze ipsec instellingen op mijn server is toegepast.. zucht... kan iemand mij aangeven waar het mis gaat.







heeft het nog zin om ook de overige protocollen aan de inbound en outbound security rules toe te voegen ? of zit ik er nu helemaal naast ?

LDAP to Directory Service:
389/UDP
389/TCP
LDAP to Global Catalog Server:
3268/TCP
Kerberos Authentication:
88/UDP
88/TCP

[ Voor 36% gewijzigd door Verwijderd op 19-02-2006 19:38 ]

[alt-92]

Je haalt 2 dingen door elkaar nu vrees ik.

Die ipsec filtering voor webserver is eigenlijk een firewalling ruleset.

[Verwijderd]

In dat geval zal ik de inbound en outbound security rules weer verwijderen, maar dan loop ik nu helemaal vast.

hoe/waar moet ik dan het security template aanpassen

iemand nog suggesties..

[ Voor 8% gewijzigd door Verwijderd op 20-02-2006 16:10 ]

[[ash]]

Volgens mij is het niet mogelijk om IPSec op deze wijze te gebruiken. In iedergeval niet gesupport door microsoft.

quote: http://www.microsoft.com/.../en-us/dnsbj_ips_teur.asp

Requiring IPSec for communication between Active Directory domain members and domain controllers might block connections

IPSec is based on the authentication of computers on a network; therefore, before a computer can send IPSec-protected data, it must be authenticated. The Active Directory security domain provides this authentication using the Kerberos protocol. Accordingly, when IKE uses Kerberos to authenticate, the Kerberos protocol and other dependent protocols (DNS, UDP LDAP and ICMP) are used for communication with domain controllers. Additionally, Active Directory–based IPSec policy settings are typically applied to domain members through Group Policy. As a result, if IPSec is required from domain members to the domain controllers, authentication traffic will be blocked and IPSec communications will fail. In addition, no other authenticated connections can be made using other protocols, and no IPSec other policy settings can be applied to that domain member through Group Policy. For these reasons, using IPSec for communications between domain members and domain controllers is not supported.

[PenguinPower]

Vooropgesteld wat [ash] zegt klopt. Het is niet gesupport, echter, het kan het wel.

IPsec meerdere verificatie mogelijkheden, via Kerberos, een certificaat of een preshared key nodig (gebruik een preshared key alleen bij test omgeving) Alleen bij de laatste 2 kun je zonder workaround werken met een beveiligde verbinding naar een ad controller toe.

Kerberos kan ook, echter het heeft zijn beperking zoals Jesper Johansson tijdens TechEd 2005 zei. (zelf nooit getest aangezien je het nergens op slaat om je dedicated domein controller via ipsec beveiligde verbindingen op te zetten naar domein clients)
Als je kerberos gebruikt als verificatie mogelijkheid kun je niet meer een client toevoegen aan het domein. aangezien de clients niet meer kunnen connecten met de domein controller. Voor kerberos als verificatie middel gebruikt moet je tevens in de ipsec mmc op de domein controller poort 88 toestaan zonder verificatie. Logisch, want client moeten tijdens de mutual authentication toch kunnen verifieren via kerberos (duh!) .
BTW: als de server ook dhcp server is moet je ook poort 68 toestaan zonder authenticatie (source port 67 op client)

[ Voor 7% gewijzigd door PenguinPower op 25-02-2006 23:17 ]

[alt-92]

[dubbel]

[ Voor 98% gewijzigd door alt-92 op 26-02-2006 11:57 ]

[alt-92]

Ik ben btw bezig met een testopstelling, in samenwerking met MS PSS, om hier wat meer duidelijkheid over te krijgen
Die sessies van Jesper ken ik, stonden ook op technet online (itsshowtime) toch?

(zelf nooit getest aangezien je het nergens op slaat om je dedicated domein controller via ipsec beveiligde verbindingen op te zetten naar domein clients)

Dan zou je tunnelmode kunnen inzetten, als je bijvoorbeeld één clientPC gebruik wil laten maken van een secure verbinding met een financieel pakket.
Wel een interessant scenario op zich