none
DirectAccess: Limit access to a group of known computer

    Question

  • Environement:  DA / UAG / TMG / NAP

    I have a requirment to limit access to the Intranet Tunnel to a limited group of known computers and not the entire intranet.  What are your suggested options. 

    Has anyone does this? and if so what method did you use?

    I can block access to a spacific computer with no problem using TMG firewall rules.

    The current approch is to create TMG computer group called "LimitedAccess" with all the systems that we need to access (intrAnet), then use a TMG Deny rule for all oubound protocols from "Local Host" to "Internal" and then excluding the "LimitedAccess" group.  The rule is currently just below "DirectAccess Allow Local Host Services".  Unfortunaly other access rules above this rule are allowing Netbios and other traffic to flow.

    Any thoughts?

    mercredi 27 juin 2012 15:00

Toutes les réponses

  • Place a firewall between the UAG internal interface and the group of known computers is probably the simplest solution.

    Alternatively you could use Group Policy to apply local Windows Firewall rules to internal hosts to achieve something similar...

    As you may be aware, messing with the TMG firewall policy is not supported on a UAG server, so this is therefore not really a recommended solution (although technically feasible).

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    mercredi 27 juin 2012 16:21
    Modérateur
  • Hi,

    This is specially why the Selected Access scenario was designed for. Problem, it configure an IPSEC transport tunnel to the selected access computers. Problem transport tunnel mode does not allow to filter on computer or user group membership bcause it is not configured into tunnel mode.

    According to Microsoft : http://technet.microsoft.com/en-us/library/ee382286(WS.10).aspx

    "By customizing the default Windows Firewall with Advanced Security connection security rules created by the DirectAccess Setup Wizard, you can restrict certain users or computers from accessing particular application servers or specify that certain client applications will not be able to access intranet resources remotely. However, customization of connection security rules requires knowledge of and experience with connection security rule design and configuration."

    Great but until now it seems that i do not have the appropriate level of knowledge. I tried to convert the IPSEC transport mode to tunnel but on client side, the firewall service halted. I have an alternate solution based on the default IPSEC transport tunnels but very complicated to setup and deploy.

    If someone find a solution, i would be happy.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    mercredi 27 juin 2012 21:27
  • After poking myself in the eye for a couple days this is working fine in our lab (100%  isolated test lab only) and it needs cleaning and testing, I would expect this will have at least some negative performance impact?  If I get time tomorrow I will play around with the Policy “Exceptions” to see if all the exceptions are needed.

    What I basically did was create a blocking rule for all traffic to the Internal network and added an exception for the TMG/UAG Array Servers for allowed computers and services.

    Note: I found that the positioning of this rule was tricky and it may still need to be moved up in TMG.  So far all the 5 Tuple checks look good and no leaks :-)

    1. In the Toolbox create a new computer set called “Custom: Intranet Allowed” add any computers and services your clients need, and yes this needs to be duplicated from the quarantine computer list if your using NAP L
    2. In the Toolbox create a new computer set called “Custom: Array Servers”, to this group add all your TMG / UAG computers INTERNAL address.
    3. In TMG Create a new Access rule under “DirectAccess Allow Local Host Servers”,  (this should be some place just under rule number 20)
    4. Name this new rule something like “Custom: Limit Internal Access”
    5. Leave the rule as a Deny Rule, Next
    6. Select “All outbound Traffic”, Next
    7. For “From / Listener” select “All Networks (and Local Host)”
    8. For “To” select Internal network,
      1. In the “Exceptions” area (this is the magic) add the computer lists created in step 1 and 2,  I also added “Forefront Protection Manager Core Servers”, ”Anyware (IPv6)”, “DirectAccess Local DNS” , and the TMG / UAG external ipaddress (another group I already had created but not documented here).
    9. Apply the policy and activate TMG.

    We use a 3<sup>rd</sup> party firewall wrapped around both sides of the DA infrastructure (internal and external) so this is over engineering and a backup policy if the primary firewall fails and but it helps us detect all the services / ports we need to open / close.  So far in the lab NMAP is not finding any Ports open to servers that are “not approved” all approved servers are working fine.   If we ever have to open a support ticket with MS we just disable the rule and it’s all good

    As a side note we are IPv4 internal only so IPSec is not an option.

    Also anyone know of a better IPv6 port scanner than NMAP, it's IPv6 support is a little funky at times or do i have a option line?

    nmap -Pn -6 -p 1-65535 -T4 -Pn --underprivilaged <taget computer>

    Thank you for your answers and suggestions, I hope this helps!

    jeudi 28 juin 2012 00:06
  • This is a senario where DA falls short of the convential VPN solution. But I'm woundering if it would be possible to be running multipel DA servers in the same site. Lets say that you a quite common setup in your internal network with lets say 4 security zones. Servers, Client, management systems and IT. Computers in the IT zone can access all other zones where the Client zone only can connect to the server zone. Would it be possible to have one DA server in the Client zone and one in the IT zone, or would there be some sort of conflict between them? Best regards, Johan Christensson
    jeudi 18 juillet 2013 10:19
  • It is possible and we have an MCS offering to help customers achieve just that...it is simply not included in the native deployment modes...

    Using an intranet firewall is a good start if you want to filter ingress DA traffic, but if you want user-level access control you need to be a little more sophisticated, hence the MCS offering ;)


    Jason Jones | Security Consultant | Microsoft Consultant Services (MCS)

    jeudi 18 juillet 2013 10:27
    Modérateur
  • This is a senario where DA falls short of the convential VPN solution. But I'm woundering if it would be possible to be running multipel DA servers in the same site. Lets say that you a quite common setup in your internal network with lets say 4 security zones. Servers, Client, management systems and IT. Computers in the IT zone can access all other zones where the Client zone only can connect to the server zone. Would it be possible to have one DA server in the Client zone and one in the IT zone, or would there be some sort of conflict between them? Best regards, Johan Christensson
    This may be feasible for inbound access, but that approach may introduce challenges for traffic that isn't subject to NAT64/DNS64 like ISATAP and/or manage out...obviously, you would also need some form of firewall architecture to control traffic flow between DA zones and the server zone.

    Jason Jones | Security Consultant | Microsoft Consultant Services (MCS)

    jeudi 18 juillet 2013 10:30
    Modérateur
  • I have done that a few times, configure multiple DA entry points and use them for different purposes and different levels of access. You may not even need a firewall to manage which DA servers can get where, if the resources you are trying to allow or disallow are complete subnets. Since there is only going to be a Default Gateway on the external NIC, you will be defining the internal routing table manually on the DA servers. If appropriate, you could simply only add the routes that you want to be accessible from each individual DA server. That way when a user comes in through the "IT DA Server", it has access to the routes you have added to that server, but if they come in through "Regular User DA Server", it is more restricted because the routes simply do not exist and the traffic cannot flow to the subnets for which you do not add.

    This of course may not work for everyone, depends on your network layout and where you have placed your servers.

    jeudi 18 juillet 2013 12:48
  • I have done that a few times, configure multiple DA entry points and use them for different purposes and different levels of access. You may not even need a firewall to manage which DA servers can get where, if the resources you are trying to allow or disallow are complete subnets. Since there is only going to be a Default Gateway on the external NIC, you will be defining the internal routing table manually on the DA servers. If appropriate, you could simply only add the routes that you want to be accessible from each individual DA server. That way when a user comes in through the "IT DA Server", it has access to the routes you have added to that server, but if they come in through "Regular User DA Server", it is more restricted because the routes simply do not exist and the traffic cannot flow to the subnets for which you do not add.

    This of course may not work for everyone, depends on your network layout and where you have placed your servers.

    I think that is fine if you use NAT64 for traffic, as the return path will always be by way of the DA servers internal IP address that performed the inbound NAT64. However, for ISATAP and Native IPv6 you would need to think about managing symmetric routing and determining the correct exit point to match the original entry point. This gets a bit trickier, but is doable ;)

    I like the idea of controlling routes, but I would probably want to supplement that mechanism with firewall ACLs for better security.


    Jason Jones | Security Consultant | Microsoft Consultant Services (MCS)

    jeudi 18 juillet 2013 12:54
    Modérateur
  • Understood, and agreed, I didn't think to mention that the installs I have done in this fashion were all NAT64. Anyone who wants multiple DirectAccess entry points I try to steer them away from using ISATAP, and I still really don't run into anybody who wants to do native IPv6. Very rarely.
    jeudi 18 juillet 2013 13:33
  • I know - just saying ;)

    Jason Jones | Security Consultant | Microsoft Consultant Services (MCS)

    jeudi 18 juillet 2013 14:31
    Modérateur
  • Poking this thread - I just finished deploying DA in our organization and while its been getting great praise, our users are unhappy with the solution simply because I was forced to restrict the servers that DA can communicate to small subset of our infrastructure (essentially our Director of Security said that if I can't restrict access based on IP or User, I can only allow users to access "universal" resources like DC's, Exchange, file shares, etc)

    It seems to me that most of the pieces necessary are sitting there but Microsoft didn't quite put them together, DA already does authentication and knows who you are and what workstation you're using, and the Windows Firewall has the capability of restricting traffic based on AD Credentials... seems that we just need a piece in the middle that would allow us to manage our resources right from the DA Management console. i.e. "I know who you are, here's the subnets you're allowed to get to"

    I know that Microsoft wants us to use Server and Domain Isolation but that's not realistic in our environment as we have MPLS connections to partners we manage and do not have AD trusts with, in addition to the large number of non-Microsoft servers and appliances we also have.

    We have been exploring upgrading our firewalls to allow us to build rules based on Windows Credentials, but it comes at a high cost and seems overkill for something that shouldn't be all that difficult to implement in DA Itself.

    So unless anyone has come up with another brilliant idea, guess we all just wait ;)


    • Modifié dustin.adam vendredi 13 septembre 2013 20:59
    vendredi 13 septembre 2013 20:59
  • Good or bad, the premise of DirectAccess is "extending the network to the user". You really have to think of DirectAccess clients as being part of the internal network rather than being a separated, quarantined group of remote clients. The idea is that with DA you get access to anything you have inside the office. User-level restrictions come by the same means that they do when the users are inside the office. So if Bill has access to a file share but Suzzi doesn't, then from their DirectAccess computers they have the exact same access level as they do from inside the office, because at user-level permissions the same mechanisms are still working on that file server to allow or disallow appropriately.

    I do understand where you are coming from on wanting to further restrict traffic, but unfortunately the answer is still the same and I haven't seen any plans yet to change it.

    lundi 16 septembre 2013 15:03
  • We understand that DirectAccess is designed to extend the network to the user and they are treated as if they are physically connected at the office, our issue as I think some others on this thread have experienced, is that we don't want to "extend more of the network to the user than they should have access to". There is no need for a Project Manager to have access to a Web Server in the DMZ. We currently have IP restrictions that carve out access to network resources that are only appropriate for the employees' job function. With DA we have only been able to extend to the DA Client very basic access that is categorized internally as "universal" such as global file shares, SharePoint, Domain Controllers, etc.

    It may help others reading this but we kind of got around this limitation by creating TS RemoteApp Servers on a per-department basis and controlled firewall access from there. we have started consolidating common department applications on these servers and publishing them via TS RemoteApp so that the end user has a Citrix-like local application with the relevant network access. It's been largely working well, its mostly been irritating that we had to engineer and entire server and application architecture to meet what is a rather common internal security practice.

    lundi 16 septembre 2013 16:32
  • I can see both sides here (Jordan and Dustin) and it is very much down to the security mind-set of remote access solutions and the perceived threats/implications of compromised endpoints.

    It is possible with some customisation to achieve user-level control, but it's quite complicated and I've only seen it done by MCS as part of a custom engagement.

    When people are security focused, I have also seen them use a presentation tier behind the DA servers (as described) in order to provide a greater level of control for remote access connections and thereby minimise the attack surface available to a compromised client. However, that needs more thought, money and infrastructure to make it happen.

    Just my 2c :)

    Cheers

    JJ


    Jason Jones | Security Consultant | Microsoft Consultant Services (MCS)

    lundi 16 septembre 2013 16:45
    Modérateur
  • Thanks for the reply Jason, I'm curious about the custom engagement you described, we believed that it was possible even if we didn't know how to implement it ourselves. Do you have any more information? we would be willing to reach out to MCS but it would help if we had more information on what they did to know if it would even be appropriate for our environment.

    Glad to hear we may have options even via consulting.

    Here's hoping.

    lundi 16 septembre 2013 17:03
  • Sure, connect with me offline...

    Jason Jones | Security Consultant | Microsoft Consultant Services (MCS)

    mardi 17 septembre 2013 22:43
    Modérateur