locked
IAG DMZ Design ideas/questions RRS feed

  • Question

  • Hi,

    We have the following requirement:
    - Internal corporate staff need to access application (web & non-web) that reside on the intranet & DMZ
    - External partners need to access application (web & non-web) that reside on the intranet & DMZ

    We will use IAG/UAG for most of the application access and publishing.

    So I am suggesting 2 separate forests (internal staff & external partners) and a 2-way (selective authentication) trust between them.

    I am then thinking of placing both these forests on the intranet. (as opposed to placing the external partners AD in the DMZ) - whats the best practice here?
    Since some of the front-end Sharepoint components and IAG itself will reside in the DMZ, will there be any benefit of deploying RODCs to the DMZ from either forest?

    Any pointers, thoughts, url's welcome.

    Thank you,
    T
    Monday, November 16, 2009 8:06 PM

Answers

  • TZ--

    I'm suggesting that you dont use the same network connection to communicate with anything you plan on publishing.  My definition of publishing in this example is something you will allow IAG to communicate with internally.  Example, OWA, SPS, AD.  

    To elaborate on my above IP based examples:
    If AD is 192.168.0.10
    If OWA is on 172.168.0.1 

    Then make sure your WAN network card isnt on each of those networks listening to incoming connections from the web.

    Thats correct, IAG doesnt need to be joined the domain to provide SSO or AD authentication.

    Thanks

    • Marked as answer by Erez Benari Monday, November 23, 2009 6:11 PM
    Wednesday, November 18, 2009 5:07 PM

All replies

  • Hello.

    If you need a different look and feel for employees and partners then you can create two portal trunks each with its own set of applications and single authentication repository. For example:  Employees.company.com and partners.company.com.

     You can also publish one trunk with two different authentication repositories.  They can use a drop down to select which type of user they are.  Make sure to name the Authentication repository accordingly.   For example:  portal.company.com.

    As far as your applications, sure, you can build a trust to the external AD so that your users don’t need to manage multiple credentials or eliminate the need for federated identity.  A read only domain controller (RODC) would be optional, but totally up to you.

    Regarding networks,  a common mistake people make with your scenario is that they only utilize two network adapters.  You should use three:

    1 – Leg inside the Internal network (192.168.0.x)   
    2 -  Leg inside the External network /DMZ Network (172.168.0.x)
    3 -  Leg to a DIFFERENT External Network to listen to incoming connections (10.10.0.0) NAT to public or public IP address.

    The reason why I recommend three networks is to separate traffic flow and because the ISA firewall might suspect spoofing and start dropping packets.

    Good luck!!  Let us know how your deployment turns out.

    Dennis Lee

     

    Tuesday, November 17, 2009 2:00 AM
  • Dennis,

    Please could you elaborate a little bit more on the 2 External NICs that you advise for IAG?

    In addition - from what I have tested, IAG does not need to be part of the domain in order to provide Single Sign-on capabilities, correct?
    The setup I have is this:
    - IAG on stand-alone non domain member
    - IAG has portal trunk, that uses an existing AD back-end for authentication
    - IAG portal has both OWA and SPS published
    - When I log into the IAG Public URL using an AD account, and then click on either OWA or SPS, I do not get prompted for re-authentication.

    Thanks,
    T
    Tuesday, November 17, 2009 5:20 PM
  • TZ--

    I'm suggesting that you dont use the same network connection to communicate with anything you plan on publishing.  My definition of publishing in this example is something you will allow IAG to communicate with internally.  Example, OWA, SPS, AD.  

    To elaborate on my above IP based examples:
    If AD is 192.168.0.10
    If OWA is on 172.168.0.1 

    Then make sure your WAN network card isnt on each of those networks listening to incoming connections from the web.

    Thats correct, IAG doesnt need to be joined the domain to provide SSO or AD authentication.

    Thanks

    • Marked as answer by Erez Benari Monday, November 23, 2009 6:11 PM
    Wednesday, November 18, 2009 5:07 PM