Update authentication-conditional-access.md
@ChristianJBergstrom : Thanks for your contribution! The author(s) have been notified to review your proposed change.
Learn Build status updates of commit 0fdba7f:
:white_check_mark: Validation status: passed
| File | Status | Preview URL | Details |
|---|---|---|---|
| articles/active-directory/external-identities/authentication-conditional-access.md | :white_check_mark:Succeeded |
For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:
- Try searching the learn.microsoft.com contributor guides
- Post your question in the Learn support channel
@msmimart
Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged" @MicrosoftDocs/public-repo-pr-review-team
@msmimart feel free to rephrase if necessary.
Hi @ChristianJBergstrom, I'm reviewing the changes with the product team. Thanks for your suggestions!
@msmimart any update from the team yet? 😊
Hi @ChristianJBergstrom, not yet so I want to make sure I understand the context or issue behind these suggested changes. I ask because in this section of the doc we're describing how you can scope a Conditional Access policy to B2B direct connect users with the new Assignments > Guest or external users > B2B direct connect users option (also described in the linked Conditional Access user assignments). So a B2B direct connect user can be in-scope for CA policies, which work together with trust settings to determine access. Can you help clarify the proposed changes?
Hi @msmimart ! You’re spot on. What I’m proposing is that one could get the idea that when selecting B2B direct connect users you can choose whatever CA setting available. But direct connect users are only affected by the three trust settings (as you mention) as there’s no presence of an object in AAD as with a guest. Not everyone knows this.
I.e. One can complete a CA config as if the direct connect user is an org. user or proper B2B guest user but it will not take effect. Hope that explains it better 😊
update
My CA works now (yay) and used a direct connect user where I require compliant device or it will be blocked. Probably delays and it was really late in my timezone so hit the sack.
But from my perspective the docs should reflect the limitations more clearer as initially proposed. You’re a very skilled writer so feel free to add a rephrase or let me know if I should change my suggestion 🤓
Thanks!
@msmimart By any chance you could fetch a table of the settings one actually can use with direct connect? Just tried a Terms of use with CA and it worked for the shared channel. That hasn’t worked before but awesome that it does. I believe the preview is causing some confusion, what works, whats to come etc. I did get a copy like a year ago from Teams PG and it basically said only the three trust settings will work with CA. Thanks again and hope you don’t get reminders for all edits ☺️
Update
I keep on trying different scenarios when I have some time over and also noticed that I can actually use Conditional Access App Control with Defender for Cloud Apps. Cool! But then again, that table of what's supported would be awesome. Would it be possible to tag someone "in the know" for this conversation?
Update Okay, the reason my "block download" worked is that even though I specified B2B direct connect in the CA it actually used the guest account of that individual to block the download. I noticed that in the MDFCA log. Interesting.
Update So I figured it out. If the User Type is "Member" on a guest account you can impose CA with MDFCA on a B2B Direct connect user trying, for example, to download a file.
Update So I thought... tried with another user and I could download. Oh my, the inconsistency. Will try again later if there's an delay involved.
@ChristianJBergstrom thank you so much for testing all of this out. Your point is well taken, and we are working on ways to outline the policies you can apply in B2B direct connect scenarios. If you don't mind, I'd like to hold off on these changes until we can make the updates we have in the works. In meantime, we can close this PR but still track the thread in case there are any other findings you want to add. Again, thanks for your dedication to helping us get this right!
@msmimart Sure thing! Please let me know as soon as possible when that "outline of policies" is completed. I'm going crazy over here 😅
#please-close
@msmimart It was the UserType "Member" instead of default "Guest" on a proper B2B guest account that did it. So I've actually used a session CA with MDFCA blocking downloads for B2B direct connect users in shared channels if being on an unmanaged device by using that property. Please send a thumbs up so I know you've read this. Thanks.
@msmimart Didn't make sense with only the UserType so continued. From what I can tell it ”must” be the field "Company name" with the external domain name that are the triggers, perhaps together. They are the only things that differs. I must say it isn't consistent so difficult to say and MDFCA doesn't inform you about being "monitored" as in normal cases, but if you look at the link one can see mcas involved and the file is blocked from download, not all the time though. I.e. one second you can download and the other not on the same file 🤷♂️
Managed to use 'Terms of use' as previously mentioned and 'app enforced restrictions' and ’authentication strength’ too. The enforced option is probably the preferred way right now as you don't even see the download option and is consistent. To conclude it all, as long as one target any of those three ’trust settings’ in any way it actually seems to do the work.
Let me know if there’s any preview group I can join. Identity & Access is really interesting and something I enjoy working with.