locked
Access Control Policy in ADFS Windows Server 2016: expect & or RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    We are using ADFS on Windows Server 2016. Now, we have the following requirement:

    Creating a Access control policy for the following logic:

    Permit everyone,
            except claim type is 'E' (external users) OR is member of an AD group 'abc'

    We don't know, how we can create a logic for that in ADFS 4.0, because multiple parameters in the expect part can only combined with "AND" and multiple permit rules are single for each one to get access to the application.

    Has someone an idea to realize this?


    • Edited by Ewoki Thursday, August 30, 2018 11:18 AM
    Wednesday, August 29, 2018 5:41 AM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Here you go:

    $rules = @"
@RuleName = "Get the description attribute"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => add(store = "Active Directory", types = ("temp:claim/description"), query = ";description;{0}", param = c.Value);

@RuleName = "Deny access for description = 9"
c:[Type == "temp:claim/description", Value == "9"]
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");

@RuleName = "Deny access for group X"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "^(?i)123-456-788$"]
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");

@RuleName = "Allow everyone else (deny claim superseeds this rule)"
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

"@
Set-AdfsRelyingPartyTrust -TargetName "ClaimsXRay" -AccessControlPolicyName $null -IssuanceAuthorizationRules $rules

    Replace ClaimsXRay but the actual name of your RP and use the actual SID for the groups.

    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.

    Tuesday, October 9, 2018 6:18 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    "expect claim type is 'E' (external users)"

    exists([Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value=="true"])
=>issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");


    "is member of an AD group 'abc'"

    not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-1411547893-2725445261-4116970666-2123"])
    =>issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

    If we have those two rules, you can request an access token only if you are internal OR if you are not a member of a group (here identified by its SID).

    And in an access policy, it would look like this:

    Is that what you are looking for?

    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.

    Wednesday, August 29, 2018 8:44 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Pierre

    Thanks so lot for your response. Each line (Permit ...) represents an indipended condition, which have to be true for itself. We are looking for a condition, where users with at least one of two conditions are meet, can't login to this relying party application.

    Here the goal:

    Userattrib 1 / Userattrib 2 --> wished result
         "E"        /        -          -->      Deny
           -         /      "abc"      -->      Deny
         "E"        /      "abc"      -->      Deny
           -         /        -          -->      Permit

    With your described logic we couldn't reach the goal.

    Here the use cases (UC):

    UC-No. / Userattrib 1 / Userattrib 2 -> Policy 1 (except "E") / Policy 2 (except "abc") --> result
        1        /      "E"         /        -          ->           -                   /              Permit           -->  Permit
        2        /        -          /     "abc"       ->       Permit               /                 -                -->  Permit
        3        /      "E"         /     "abc"       ->           -                   /                 -                -->  Deny
        4        /        -          /        -          ->       Permit                /             Permit           -->  Permit

    You see, that only use cases No. 3 and 4 have the wished result, the use cases No. 1 and 2 not.

    Therefore, the question is still unsolved.




    • Edited by Ewoki Thursday, August 30, 2018 11:17 AM
    Thursday, August 30, 2018 11:11 AM
  • Question
    Sign in to vote
    1
    Sign in to vote

    oh :) I understood the opposite... So I am not sure I understand now...

    Well, then the wizard with one rule does the trick doesn't it? Assuming that your E means that the user is connected externally (through the WAP).

    exists([Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "true"])
 && NOT exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-1411547893-2725445261-4116970666-2123"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

    Which is:


    With the following:

    Connected externally / Not a member of the group = No permit
    Connected externally / Member of the group = No permit
    Connected Internally / Not a member of the group = Permit
    Connected Internally / Member of the group = No permit

    Not having a permit claim in the pipeline prevents a user from getting a token. We could issue a deny claim, but then we cannot do the rule with the wizard. We would have to do it the 2012 R2 way.

    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.

    Thursday, August 30, 2018 5:05 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks for your reply.

    "Assuming that your E means that the user is connected externally (through the WAP)."
    No, "E" means one attribute of the AD user account. "E" is an example for a value like "employee". The second attribute is a group membership.

    Therefore, everyone has access, only users with the attribute value "employee" OR with a membership in a special group should have NO access to the relying party.

    This condition doesn't meet your code :-(


    • Edited by Ewoki Wednesday, September 5, 2018 6:33 AM
    Wednesday, September 5, 2018 6:29 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    But you get the logic though...

    Alright, tell me the SID of the group and the exact name of the attribute in AD you want to use. We'll craft the rules here :)

    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.

    Thursday, September 6, 2018 12:42 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    So? Tell us more about the exact attribute names and claims and we can craft these rules!

    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.

    Tuesday, September 18, 2018 2:52 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi Pierre Sorry for the delay. I have had trouble to place my answer here... Thanks for your offer. The Information for the users, which should NO access: - User is member of the AD group with SID „123-456-788“ (I know, this is only a fictitious number) OR - User has the value „9“ in his AD user account in the attribute „Description“. All others (everyone) should have access. Thanks for your support.
    Friday, September 21, 2018 3:47 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Here you go:

    $rules = @"
@RuleName = "Get the description attribute"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => add(store = "Active Directory", types = ("temp:claim/description"), query = ";description;{0}", param = c.Value);

@RuleName = "Deny access for description = 9"
c:[Type == "temp:claim/description", Value == "9"]
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");

@RuleName = "Deny access for group X"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "^(?i)123-456-788$"]
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");

@RuleName = "Allow everyone else (deny claim superseeds this rule)"
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

"@
Set-AdfsRelyingPartyTrust -TargetName "ClaimsXRay" -AccessControlPolicyName $null -IssuanceAuthorizationRules $rules

    Replace ClaimsXRay but the actual name of your RP and use the actual SID for the groups.

    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.

    Tuesday, October 9, 2018 6:18 PM