Converting a Teams Group to an actual O365 account.

thecomputerguy

Well-Known Member
Reaction score
1,326
Insurance client again.

They registered their account with CA Fair Plan as personalinsurance@constoso.com

personalinsurance@constoso.com is not an actual account, but it's a TEAMS group in the tenant and it receives mail from external users.

CA Fair Plan now requires them to login to their (CA Fair Plan) tenant as a guest in O365 to access their system.

Since personalinsurance@constoso.com is not an actual account, there is no password for it and as such, no ability to login to either tenant.

They have contacted CA Fair Plan to try and change their registration email to something else but it has been 60 days and they still have no indication that they can register a different email address.

I told the client the path of least resistance at this point is to (backup contents) delete the group, and then wait until the tenant allows us to create personalinsurance@constoso.com as an actual account. I know that this can take days or weeks until the tenant releases the address and allows us to us it as a mailbox. I'm assuming this will work similarly to when removing an alias. After removing an alias I know it takes X time to be able to use that alias as an actual email address.

Am I on the right track here?

I then setup a distribution group to forward all emails sent to personalinsurance@constoso.com to a cafairplan@constoso.com teams group, enable external senders, and then make that group public so all members can receive those emails in the Outlook group.

@YeOldeStonecat
@Sky-Knight
 
Last edited:
personalinsurance@constoso.com is not an actual account, but it's a TEAMS group in the tenant and it receives mail from external users.
I'm confused. Who owns the domain constoso.com? Is that the insurance company's domain? Assuming they own it why is this going to take weeks? It is a button press to convert a shared mailbox which is all a team's group is into an exchange account.
 
Automating a broken process just gets us to the wrong answer faster...

That's a group for a reason, you need to understand that reason before you can proceed.
 
SORRY EVERYONE FOR THE TYPO ... Yes it's supposed to be contoso.com as an example.

I'm confused. Who owns the domain constoso.com? Is that the insurance company's domain? Assuming they own it why is this going to take weeks? It is a button press to convert a shared mailbox which is all a team's group is into an exchange account.

If you remove an alias from a persons email address you are not able to use that alias as an account until it get's "flushed out" of the system. I've seen it take a couple of days before. I'm assuming by deleting a group it may function this way as well.

Can you convert a group to a shared mailbox? I'll have to look into that.

Automating a broken process just gets us to the wrong answer faster...

That's a group for a reason, you need to understand that reason before you can proceed.

It's a group because they went ape **** when then started the tenant and created a bunch of groups that weren't necessary. ALL the group is used for is to receive mail in the groups section of outlook. It might as well be a shared mailbox.

Wit that said they are completely fine deleting the group and restarting it as an account because the data in there is so incredibly minimal.

That and they need an account that will allow them to login to the CA Fair Plan website.
 
A mail enabled M365 group IS a a shared mailbox, except it's got more functionality bolted to it. So I'm confused as to why you think moving in that direction is moving forward. That's why I said you need to understand, because we seem to be trading hammers for screwdrivers without any visible explanation.

Also, a 3rd party website's account has nothing to do with the M365 configuration. Unless you need that group's email address to use it? And you want to control that differently?

If that's the case, then go change the groups's email address, and make a shared mailbox or whatever out of the address you freed. There's no need to delete anything as far as I can see.
 
A mail enabled M365 group IS a a shared mailbox, except it's got more functionality bolted to it. So I'm confused as to why you think moving in that direction is moving forward. That's why I said you need to understand, because we seem to be trading hammers for screwdrivers without any visible explanation.

Also, a 3rd party website's account has nothing to do with the M365 configuration. Unless you need that group's email address to use it? And you want to control that differently?

If that's the case, then go change the groups's email address, and make a shared mailbox or whatever out of the address you freed. There's no need to delete anything as far as I can see.

For some reason CA Fair Plan requires you to login using a M365 account to access their system.

If you go here and click broker login it immediately takes you to a M365 login. Since the account they have registered with them is personalinsurance@contoso.com and this email is technically not a login, it's a group. It is requiring credentials to access the system, and their are no credentials for a group.
 
For some reason CA Fair Plan requires you to login using a M365 account to access their system.

If you go here and click broker login it immediately takes you to a M365 login. Since the account they have registered with them is personalinsurance@contoso.com and this email is technically not a login, it's a group. It is requiring credentials to access the system, and their are no credentials for a group.

AHHH Yes, Federated guest access... ok yes now that makes sense!

Go take the email address off the M365 group, and attach it to an actual user. You won't be able to use a Shared mailbox here, you need an active MFA protected user credential. And if multiple people need to use it... you'll have to share it, which is stupid but where you're at!
 
AHHH Yes, Federated guest access... ok yes now that makes sense!

Go take the email address off the M365 group, and attach it to an actual user. You won't be able to use a Shared mailbox here, you need an active MFA protected user credential. And if multiple people need to use it... you'll have to share it, which is stupid but where you're at!

I thought I was on the right track. I actually deleted the group and I was able to create a user using the group email address immediately.

Unfortunately, still denied access because what they thought was their registered email still seems to be not added to guest tenant.

Can't fix dumb.
 
I thought I was on the right track. I actually deleted the group and I was able to create a user using the group email address immediately.

Unfortunately, still denied access because what they thought was their registered email still seems to be not added to guest tenant.

Can't fix dumb.

Actually... I'll bet it's too secure for its own good. If the system you're trying to access is using guest invites, the invite would have been received by the M365 mailbox, which would have been clicked on and accepted by someone that could get that mail. From there, the invitation would have attached itself to the identity of the user that clicked it, and not the groups mailbox.

Even if the invitation attached to the group's mailbox identity that was destroyed when you deleted the group. So now you have a new identity, with the same email address, but the GUID is different and it no workie.

Regardless, both pathways to resolution are the same... go to the service you're trying to access, open a ticket, and wait for them to fix it.
 

Entra ID Federations, or Active Directory Federations are the modern word to describe a trust. In this case there isn't an explicit trust of a target directory, but the "guest access" is enabled and associated with an external login which has Conditional Access applied to it to enforce MFA. But the actual identity and login are handled via a separate Entra ID directory.

All of that is a ton of technical gibberish to describe how M365 tenants can control authentication that's actually happening on another M365 tenant AND provide controlled access to a specific resource. It's Federated, yet it isn't all at the same time. And if you have a Microsoft account you've used it before, even if you don't know about it.
 

Entra ID Federations, or Active Directory Federations are the modern word to describe a trust. In this case there isn't an explicit trust of a target directory, but the "guest access" is enabled and associated with an external login which has Conditional Access applied to it to enforce MFA. But the actual identity and login are handled via a separate Entra ID directory.

All of that is a ton of technical gibberish to describe how M365 tenants can control authentication that's actually happening on another M365 tenant AND provide controlled access to a specific resource. It's Federated, yet it isn't all at the same time. And if you have a Microsoft account you've used it before, even if you don't know about it.
Gotchya. It’s Federated because Microsoft is validating both sides of the trust.
 
Back
Top