locked
Adding custom rule to allow Skype online but not SharePoint externally RRS feed

  • Question

  • Hello,

    I have a need to allow Skype for everyone.  That being said, I need to deny access to SharePoint online for everyone.  I have a custom ADFS rule written now that disallows access for everyone to everything externally using the rule that denies everyone externally using the formats given in the Technet article below.

    https://technet.microsoft.com/en-us/library/dn592182.aspx

    Can someone help me out please?

    Thanks,
    Dean

    Friday, March 11, 2016 3:02 PM

Answers

  • The only tested and supported scenarios for conditional access at the ADFS level are the one mentioned in the article you quoted.

    What you could do is open Office365 for a group of users, but those will have access to Skype as well as other workload.

    You can have a look here:

    - Securing access to Office 365 and other apps connected to Azure Active Directory https://azure.microsoft.com/en-us/documentation/articles/active-directory-conditional-access/

    It's another approach though.

    An alternative would be to filter based on the useragent. Skype for PC is using a user-agent and the windowstransport endpoint. So you could technically create a rule such as:

    exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent", Value =~ "(?i)lync|msoidcrl"])
    && exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~ "/adfs/services/trust/2005/usernamemixed|/adfs/services/trust/2005/windowstransport"])
    Should catch this case... However, the user agent string can be manipulated by the user. So if they discover this, they should be able to connect to other services... So from a security standpoint, that's not ideal at all! Skype on other platform probably use other useragent string such as "Lync MOBILE" and probably another endpoint too... So maybe you should look at Intune conditional access too: Deployment guide for conditional access to email with Microsoft Intune https://blogs.technet.microsoft.com/microsoftintune/2016/03/10/deployment-guide-for-conditional-access-to-email-with-microsoft-intune/


    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, March 11, 2016 3:20 PM
  • FYI, the regex I shared is the one I had in my test done along time ago.

    See, it also outlines another weakness for this approach. It depends on the client, the app, the version, the OS... etc... So you might have to write a pretty complex regex to fit all situation, with the risk of opening even wider to the first risk we mentioned.

    If you are a service provider or a contractor, I would not recommend this to my customer. It's too risky, it's data privacy after all if the data end up on the wrong device and the device gets stolen... Please, give them BIG WARNING! And bring awareness of the conditional aspect I mentioned in my first post.

    Be safe :)


    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, March 11, 2016 10:37 PM

All replies

  • Hello,

    I have a need to allow Skype for everyone.  That being said, I need to deny access to SharePoint online for everyone.  I have a custom ADFS rule written now that disallows access for everyone to everything externally using the rule that denies everyone externally using the formats given in the Technet article below.

    https://technet.microsoft.com/en-us/library/dn592182.aspx

    Can someone help me out please?

    Thanks,
    Dean

    • Merged by Cindy_lim Monday, March 14, 2016 6:32 AM same
    Friday, March 11, 2016 3:03 PM
  • The only tested and supported scenarios for conditional access at the ADFS level are the one mentioned in the article you quoted.

    What you could do is open Office365 for a group of users, but those will have access to Skype as well as other workload.

    You can have a look here:

    - Securing access to Office 365 and other apps connected to Azure Active Directory https://azure.microsoft.com/en-us/documentation/articles/active-directory-conditional-access/

    It's another approach though.

    An alternative would be to filter based on the useragent. Skype for PC is using a user-agent and the windowstransport endpoint. So you could technically create a rule such as:

    exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent", Value =~ "(?i)lync|msoidcrl"])
    && exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~ "/adfs/services/trust/2005/usernamemixed|/adfs/services/trust/2005/windowstransport"])
    Should catch this case... However, the user agent string can be manipulated by the user. So if they discover this, they should be able to connect to other services... So from a security standpoint, that's not ideal at all! Skype on other platform probably use other useragent string such as "Lync MOBILE" and probably another endpoint too... So maybe you should look at Intune conditional access too: Deployment guide for conditional access to email with Microsoft Intune https://blogs.technet.microsoft.com/microsoftintune/2016/03/10/deployment-guide-for-conditional-access-to-email-with-microsoft-intune/


    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, March 11, 2016 3:20 PM
  • I was actually just looking into doing the User-Agent string method.  I'm somewhat new to writing these custom rules so I apologize if I'm way off.  I used WireShark to capture the User-Agent string and I see that my Skype client string is "User-Agent: OC/16.0.6366.2062 (Skype for Business)" but I'm not sure how to implement it as a rule or if I have the string correct.  I see that you have "(?i)lync|msoidcrl" as your User-Agent string.  Where did you get that?  Also, is the line for "x-ms-endpoint-absolute-path" needed?

    I was thinking of adding something like this line just above the deny rule that already exists.

    NOT exists[Type=="http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent", Value =~ "User-Agent: OC/16.0.6366.2062 (Skype for Business)"]

    => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny",
    Value = "true");

    I do see your point about the security concern.  I'll have to bring this up with the client and let them make that call.  I'm not sure that this is a must have thing or a nice to have thing.

    Thanks a ton for your help!

    Dean

    Friday, March 11, 2016 3:31 PM
  • Nevermind my last post. I just needed to read http://social.technet.microsoft.com/wiki/contents/articles/4792.understanding-claim-rule-language-in-ad-fs-2-0-higher.aspx to understand what the "(?i)" represented.  I think this will work for what we need.

    Thanks again Pierre.

    Friday, March 11, 2016 6:32 PM
  • FYI, the regex I shared is the one I had in my test done along time ago.

    See, it also outlines another weakness for this approach. It depends on the client, the app, the version, the OS... etc... So you might have to write a pretty complex regex to fit all situation, with the risk of opening even wider to the first risk we mentioned.

    If you are a service provider or a contractor, I would not recommend this to my customer. It's too risky, it's data privacy after all if the data end up on the wrong device and the device gets stolen... Please, give them BIG WARNING! And bring awareness of the conditional aspect I mentioned in my first post.

    Be safe :)


    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, March 11, 2016 10:37 PM
  • Yes sir.  I understand the risks and have made the client well aware of them as well. Not sure that it's worth the added exposure.

    Thanks again,

    Dean 

    Monday, March 14, 2016 5:13 PM