locked
Deny based on claim in ADFS 3.0 RRS feed

All replies

  • First I apologize that I am not directly answering your question.

    I am wondering how a user coming from a WAP (your public publication of ADFS) could have the IP address in 192.168.0.0/24 do you also use the WAP internally?


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, December 4, 2015 3:10 PM
  • I actually am quit confused as to what IP address would go in there. Our setup is an external IP which NAT's to a Kemp load balancer which then send the request to the WAP servers. From the load servers back to the Kemp load balancer to hit the ADFS servers on the internal network (192.0.x.x). What IP or IP's would I need to be putting in the issuance authorization rules #1?

    Friday, December 4, 2015 5:47 PM
  • If your HLB is doing NAT unless you have an option to do SNAT or something similar, the IP in the claim x-ms-forwarded-client-ip will be the IP of the HLB. My question is more, why do you use IP addresses in the first place? Since the claim insidecorporatenetwork will tell you whether the user is connected internally or externally.

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, December 4, 2015 6:48 PM
  • A Cisco ASA is doing the NAT to the Kemps (service).

    However, your point about the insidecorporate network claim makes a lot of sense, it should be all we need. from my understanding if you authenticate against the internal ADFS farm you are considered inside and hitting the WAP you are NOT inside. Is my understanding correct? We will remove the IP information from the rule and see how it goes.. Thanks. I will post results around Monday-Tuesday.

    Out of curiosity, would the IP in the claim for for an external user be the external IP or the Natted IP of the service on the Kemp which is in our DMZ. I suppose then consideration would need to be taken whether we are using layer 7 transparency as well which I believe is not in place for this service.

    Saturday, December 5, 2015 3:07 PM
  • Gidday mate,

    I spent large amounts of time creating our Issuance Authorization Rules some time ago using the new and improved ADFS 3.0 claims language. I also used the article you referenced, and have managed to create a robust set of rules that allow for good scalability and flexibility. The rules end up working similarly to a firewall set of rules.

    The basic construct is a series of custom claims. Each claim addresses a specific requirement that meets a business need in order for a token to be issued. Each claim rule is processed iteratively (ie. one after another). If the claim evaluates to a value of true, then that value of true is used in the last claim which is the one for actually issuing the token.

    I specifically don't use deny claims, as it becomes a lot more complex trying to get tokens issued once a deny claim has been evaluated. It's not to say it can't be done, but I have worked on the principle that 'unless a custom claim requirement has been fulfilled, no token will be issued'. This is essentially the same as a deny rule.

    So here are the rules I use:

    1. Issue custom claim for internal client requests directly to federation server
    This claim states that any internal request has a claim type set to true. Internal in this instance means any claim request that has come directly to the ADFS server. This will depend on how you have your DNS setup internally for accessing the ADFS endpoint. For us, only internet based requests traverse the WAP.

    c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "true"]
     => issue(Type = "http://custom/allow", Value = "true");

    2. Issue custom claim based on IP regex
    This claim states that any request originating from the internal network gets a claim type set to true. The IP address(es) that get used here are the external IP's of outbound internet requests - not internal address ranges. The value listed here is an example only.

    c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "\b100\.100\.100\.(101|110)\b"]
     => issue(Type = "http://custom/allow", Value = "true");

    3. Issue custom claim if request is for Activesync from external network for 'Activesync Users' group
    This claim states that if the request came through the WAP, AND you are a member of the active directory group "Activesync Users', AND you are making the claim using the Activesync service, AND the request is NOT coming from an internal network (ie. request is coming from the internet), then set claim type to true.

    exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
     && exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "<SID of Activesync Users group>"])
     && exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.ActiveSync"])
     && NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "\b100\.100\.100\.(101|110)\b"])
     => issue(Type = "http://custom/allow", Value = "true");

    4. Issue custom claim if request is for Outlook from external network for 'Outlook Web Access Users' group
    This claim states that if the request came through the WAP, AND you are a member of the active directory group "Outlook Web Access Users', AND you are making the claim from the Outlook client, AND you are NOT making the claim using the Activesync service, AND the request is NOT coming from an internal network (ie. request is coming from the internet), then set claim type to true.

    exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
     && exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "<SID of Outlook Web Access Users group>"])
     && exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/services/trust/2005/usernamemixed"])
     && NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.ActiveSync"])
     && NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "\b100\.100\.100\.(101|110)\b"])
     => issue(Type = "http://custom/allow", Value = "true");

    5. Issue custom claim if request is for OWA from external network for 'Outlook Web Access Users' group
    This claim states that if the request came through the WAP, AND you are a member of the active directory group "Outlook Web Access Users', AND you are making the claim using OWA, AND the request is NOT coming from an internal network (ie. request is coming from the internet), then set claim type to true.

    exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
     && exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "<SID of Outlook Web Access Users group>"])
     && exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"])
     && NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "\b100\.100\.100\.(101|110)\b"])
     => issue(Type = "http://custom/allow", Value = "true");

    6. Issue permit claim based on the custom claim
    This claim allows a token to be issued if any of the claim rules from above have issued a type value of true.

    c:[Type == "http://custom/allow", Value == "true"]
     => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

    I hope this helps.

    Regards,

    ac


    Sunday, December 6, 2015 8:42 PM
  • Pierre, I after removing the IP potion it worked like a champ unfotunatley it broke all of the internal Outlook clients connectivity. I was not aware that Outlook 2013/2016 was utilizing ADFS. Any idea why the Outlook client would not work? Perhaps they are authenticating to the WAP servers and not the internal ADFS servers?
    Monday, December 7, 2015 3:50 PM
  • Awesome stuff Adrian! I will look at this in more detail when I get to work. Thanks a lot.
    Monday, December 7, 2015 3:51 PM
  • To-date Outlook/ActiveSync clients are always authenticated from the outside via the proxy. This is more a limitation of these rich clients as they're using legacy access mechanisms that wrap up the authentication request, send it to Exchange routed via the MS Fed Gateway before it's sent back to your AD FS instance (thru the proxy) for actual authentication via a web services endpoint.

    Modern authentication/ADAL changes how this works for Outlook if your clients have the appropriate Office update and registry changes to activate it.


    http://blog.auth360.net

    Tuesday, December 15, 2015 11:45 PM
  • Any update on this?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, December 21, 2015 3:37 AM