- last edited on
I could give a guest access to SPO directly from the site's permissions settings, and I could give a guest access to Teams directly from the Teams interface (at least in a channel, if not in chat). Is there any reason not to first register the guest(s) in AAD?
12-12-2018 10:42 AM
12-12-2018 10:45 AM
12-12-2018 10:55 AM
Hi. thanks. Yes, I should have added that I'm aware of the differing abilities of users and admins to add guests in AAD. i think your reply implicitly answers the question, though, that there is no downside, and potentially some upsides, to pre-adding a guest in AAD. My actual situation is that there are two externals with whom I need regularly to chat across a number of different projects. I could add them into a Teams channel without pre-registering them in AAD, but sometimes the chats need to be outside the project-oriented Teams channels. To add them as a contact in Teams chat, I think I'll need to pre-register them as guest users in AAD. Sounds like there's no reason not to do that--right?
12-12-2018 11:06 AM - edited 12-12-2018 11:07 AM
The short answer is no – both ways create “shadow” accounts in your tenant, which the B2B user then needs to redeem before use.
Some customers manage and restrict account creation using the B2B portal, or create B2B accounts for their users to then assign to resources.
If you’d like to restrict B2B account creation, please refer to the ‘External collaboration settings’ blade.
Hope this helps.
12-12-2018 11:16 AM
Apologises, didn't see the other replies :)
If you'd like to move B2B invitations away from SPO/Teams, try the B2B portal or delegate one of the 3rd parties B2B accounts, the Guest Inviter role.
12-13-2018 05:50 AM
12-13-2018 06:02 AM
Some other benefits of pre-adding them is that you can add additional attributes, control the groups they go into and use the Access Review process to help confirm that they still belong on a routine schedule
12-13-2018 12:13 PM
@Chris Webb wrote:
federation(external access needs enabled in admin center on both sides)
they will have to tenant switch in the client to your tenant to participate in that chat. The only way to prevent this is to not have them as a guest and use the chat federation, but then they can't be in a Team. It's a mess
Your first point on having to enable external access on both ends might well be why the "just add them to chat" didn't work. I'll test this weekend.
Your second point couldn't be truer. The idea of switching tenants makes fine sense in theory, and without pondering too much it probably makes good if not essential sense from a security/access management perspective, but it's extremely cumbersome.
I think the answer to all this is to enter the people in AAD when possible; develop some written or video guide to administratively enabling federated chat and send a link to collaborating entities; and hope for the best.
In this context, is there any point--at all--in entering an external as a mail user? We had to do that for a few guests in order to get them into mail-enabled security groups, but with the ability to add them into AAD as guests it seems that a 'mail user' is no longer necessary or appropriate for externals. Thoughts?
12-24-2018 07:49 AM
According to my testing, adding an external to the Chat blade in Teams, i.e., not adding them to a team in the Teams blade, only works if they have been pre-added as a guest in AAD (assuming all other settings are correct).
12-24-2018 07:59 AM
12-24-2018 10:25 AM
12-24-2018 10:37 AM
12-24-2018 10:46 AM
@Chris Webb wrote:
You do not have to add people to use external federation “chat” tab. If everything is setup properly. You click new chat and type in their email and you should get a “search externally for x” underneath. If you are not getting this then something going on with config somehow.
When everything is configured properly on my end to Teams with externals, and I click on the Chat tab to start a new chat, and enter the name of an external person who is not in my AAD, Teams responds with, "We didn't find any matches." Note that I have no idea how the organizations for those externals have configured their own Teams.
So, given that experience and the earlier replies here, would it be correct to state the following:
12-24-2018 11:06 AM
12-24-2018 11:55 AM
12-24-2018 08:26 PMSolution
12-25-2018 02:53 PM - edited 12-25-2018 04:02 PM
I really wish out of the box it would disable the guest access for everyone. This was flagged by our security team because of the nature of business my company does. I think it should be turned off, but I am most likely in the minority in this one.
12-26-2018 08:24 AM