Forum Discussion
Sign up with Microsoft Account vs Microsoft Tenant ?
Hi, We are able to sign up Microsoft Tech Community using personal Microsoft Account and Microsoft tenant like Microsoft365 Azure and so on. The issue is when you login with tenant account and fo...
Allen
Community Manager
Community ManagerHotCakeX Reza_Ameri Dean_Gross
Thank you all for the robust discussion and I think you're all talking about the correct issues, let me take a moment to explain why things are the way they are (without making an argument for them continue to be that way).
The Microsoft Tech Community grew out of the old Office 365 Network Yammer group, back then we focused exclusively on products that were in the Office 365 Product group and at products aimed entirely at enterprise. Indeed even today I work for the Office Marketing team.
When you're focused on Enterprise you quickly learn that some employers want you to conduct business, i.e. speak to partners and stakeholders, on accounts that they own (indeed some employers have it in their terms of employment that you must). This means if you are given access to a special area through your work or sent documentation that might be privileged or confidential and then leave the company you will lose access to this information / data. This is why we support login via Azure Active Directory.
So all that said why can you not take your account with you? well its because the account, created via AAD and your employer, doesn't actually belong to you and we can't give you access to it because it does not belong to us either. In data protection speak we are merely the 'data processors'(1) if we migrated that data to your personal account we could be seen as stealing data from your former company.
So why support it? simply put we want to ensure that people can engage on the Microsoft Tech Community via their work account if they have to and their personal account if they want to. In this way those that have to use work accounts can, while those who wish to use personal accounts can do so as well. We have, in recent months, considered if we need to enable login with Social Media / Git Hub but the jury is still out on that one.
Could we hybrid login? where by a user can connect a AAD account and a Personal account? possibly but this becomes very complex, i.e. we would need to find a way to sanitize this hybrid account of anything that belonged or could be seen to belong to the employer. This could include Private message, Subscriptions and even posts. Needless to say all this would require infrastructure for those companies to notify us, manually or via AAD Signals, of users leaving so that the appropriate updates could be made and then some sort of review done to make sure all appropriate data was removed. Also what happens if we remove something that you think belongs to you but your employer feels it belongs to them? In my mind a hybrid account is veritable minefield of complexity, the overhead for which probably means it isn't worth what would be left of the account afterwards.
Today if you leave a company you only lose access to the account purely because you can no longer login with it, assuming you or someone authorized by your company does not come and manually close the account, the account itself still exists in our system.
I am not sure what the 'solution' needs to be for this but I hope from my intervention today you have gained some understanding into why its the way it is.
Happy to continue to engage with this discussion as I do understand the frustration users have when this happens to them.
Allen
I would like thank you for your comprehensive and valuable explanation.
There is an option to manage multiple accounts in some platforms like LinkedIn. For example, someone is signing up with company's account and then they could just add their own personal account and remove the company's one while keeping their actual LinkedIn account.
I am wondering do we consider this forum as a public forum for everyone?
For example consider someone is working in a company and has his/her own Yammer in the company and once left the company the user will lose access to the Yammer and in new company should create a new one. However, for public forum, I believe users is the owner of the account.
A policy should set like if like domain==Microsoft , then grant some rules like access to private forums and once user is no longer in Microsoft meaning domain has been expired, then these accesses will be revoke but user would be able to participate in public forums with the same account.
I got the idea and I will think more about it and try to share a solution and hope continue discussion. May be we could come up with some design to resolve this issue 🙂
Thank you Allen for your comprehensive response and explanation.
What you have discussed makes scenes , I have an idea and how about account transfer feature:
Inside Microsoft Azure app the administrator could select this feature like when account is being retired (e.g. employee left the company) to enable transfer to Microsoft Account. The experience could be like this:
Administrator: the administrator would login to account management portal (Azure or/and Microsoft 365) and select the user account wanted to transfer and it should open a dialogue and select the app (Microsoft Tech Community) wanted to transfer the account and in next dialogue box it shows permissions associated with Azure AD which will be removed from the account (like private forum for Microsoft Employees) and then click finish.
User: User won't be able to login with the account transfer status in any of Azure AD websites and only it will be authenticate in websites where they have transfer account status (in our case Microsoft Tech Community) and when user login will be presented with a screen explaining the Azure AD is disable and could transfer account to the new one. Then user would press next and enter credential for Microsoft Account and press next and it shows what permissions will be lost. Then user will show transfer has been successful and could login with the new Microsoft Account.
This is new account status which we could call is as Account Transfer, once this has been done , then the account will be disabled or removed (based on the company's policy). In the process it will check whether the account is valid and could be authenticated and once it has been done it will replace the SSO id. Actually, it would stays in the queue and once account has been cleared from the previous account, it will assign the new one. Something like this.
The administrator would be able to set the period to do this transfer. I believe what I have shared it more like an Azure feature but I am wondering is it feasible from engineering point of view?
- Yammer is a paid service, part of M365 subscription.
so in this context of public/private, it's considered "private".
now if we consider other services such as Teams, OneNote, Kaizala, OneDrive and many more, they are public, no need for M365 subscription, and anyone with free Microsoft account can use them. they are just like Microsoft Tech Community, a public service.
when a user leaves a company, their work account and all services and data that came with it will become inaccessible to that user, that includes all the services I mentioned above, so why should Microsoft Tech Community be an exception here.
it wouldn't make sense when logically thinking about it.
sure this is a "forum" but those are just "cloud drives, "note books" and so on too. - Allen
Happy to explore it but in our current setup it just wouldn't work. Each account is connected to the creating credentials via an SSO id which we receive from the oAuth authentication endpoint. Each account can only have one SSO id which means you wouldn't be able to use more than one account to login unless that login occurred at the authentication provider stage, i.e. in the Microsoft Login backend systems.
This leaves one of three options:
1) We overhaul the login experience for the community to allow the storage of more than one SSO ID
2) We overhaul the Microsoft Login backend system to allow user to connect their personal and work accounts together
3) we detach the community login from the Microsoft Authentication entirely and allow users to create non SSO accounts which they can then use to connect their respective Microsoft accounts.
1) is problematic as it would require you to login to two accounts at the one time, which is problematic as anyone who has ever tried to use an AAD account and a Microsoft account at the same time, in the same browser can attest to.
2) I think is unlikely because literally no other Microsoft product is asking for this.
3) I suspect would be an undesirable experience for end users as they now have up to 3 accounts to maintain.
And none of these three options would ultimately address the issue of how we remove PMs that belong to the company and or subscriptions to content that was only possible as an employee of that company, especially since none of these are connected by a role or permission on the backend that's bound by a domain.
I genuinely love the exchange of ideas, I just do not see a way at the moment to resolve what your trying to resolve - if I did we would clearly have resolved it by now.
Allen
