Let the fun begin and create new IPsec tunnel. We will be starting with the client-side. We will introduce this GPO configuration on a dedicated GPO applicable to our DirectAccess clients. Remember, it’s not supported to customize DirectAccess configuration (We will break that rule later, …).
We are in a client-to-gateway configuration and we to need to ensure that if network traffic match this rule we use this tunnel.
During IPsec Initialization, DirectAccess client send authentication information. These information will be required for filtering purpose on the DirectAccess gateway side.
On client-side of the tunnel our new tunnel must only be used if we try to access our server with sensitive information. IPv6 address of this server will be configured as a remote endpoint.
IPsec authentication is a negotiation process (Show me who you are and show me who are you).
I wanted to provide the same security level as default DirectAccess IPsec tunnels, so I choose to use a primary and a secondary authentications methods.
My choice, using Computer certificate plus Computer Kerberos ticket as primary authentication methods and only user Kerberos ticket for secondary authentication methods. With this choice I will be able to filter access based on computer account group membership or user account membership.
At last, this new IPSEC tunnel must only apply on DirectAccess scenarios, so limited to private and public firewall profiles.
This Connection Security rule will be name « SECURED ZONE ».
That’s all on DirectAccess client-side. On DirectAccess gateway-side we will follow the same logic. So until now it’s not so complicated. Not yet. Don’t worry headache is on the way.
BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)
Les derniers articles par Benoit (tout voir)
- Publier une application Azure Managed Application avec BluePrint - 22 avril 2019
- Consommer un Storage Account avec une authentification Azure AD - 14 avril 2019
- Découverte d’Azure BluePrint - 7 avril 2019