Microsoft Teams and Authenticator lockdown
I’m having a very frustrating issue with Microsoft Teams. I am able to log in to teams using my normal personal email and account ONLY ON THE WEB BROWSER. From the web browser, I am not able to access the business channel that I am in. When attempting to log in on the downloaded mobile Teams App, I am sent directly to Microsoft Authenticator, which after waiting several hours, waiting even a full day, is still displaying a message about repeated verification attempt and to wait and try again later. I have accessed Microsoft support chat and they had no help for me. I need the authenticator lockdown to refresh and it will not.Unexpected button behaviour when using the prompt=create parameter in Entra External ID user flows
Hi, In a recent workload, I'm assisting a client to implement Entra External ID for streamlined authorization as well as single sign-on for associated registered external facing third-party applications for external customer users through their Entra External ID identity, as well as assisting the client with auth branding and other UI customizations, and preparing Entra ID federation custom OIDC providers and configuration for enabling SSO with organizational internal and remote work- and school accounts etc. The sign-up / create account experience is of importance to the client, as a rather substantial amount of users are expected to sign-up via self-service sign-up following having received an invite via another app. To ensure that the user lands on the create account view, in order to minimize the number of steps and actions the users need to take to get there, the prompt=create parameter is used to pre-select the sign-up/register experience in the user flows UI. Having stress-tested the user flows and experience recently, we noticed that in a specific scenario, some UI elements behave in a manner that could be described as unexpected, and even though a workaround has mitigated it to some extent, the behaviour of some elements could probably be improved a bit to ensure an even more consistent user experience in the built-in user flows. Specifically, if the user flow is invoked with the prompt parameter set, the user lands on the create account screen as expected, however, unless custom CSS modification is applied, the Back button that would typically be there, as if having arrived there from the initial sign-in screen where it’s also displayed. If pressing the Back button displayed on the Create account view when having navigated there with the prompt=create set in the /authorize request, pressing the button seemingly doesn’t have any impact or result in any action, one can click it, but nothing happens. I'd suspect it's perhaps a "remnant" from if the flow is invoked without any prompt parameter set, or with prompt=login set, but when prompt=create is set, there is no state/page history in the UI to navigate back to, as no previous page has been displayed or rendered yet and added to the history, and the Back button click thus doesn’t have any effect. In general, I think buttons that don't have any tangible action should not be displayed, also, if prompt=login is set, the Back button isn't shown then either on the very initial user flow view shown then, so it would seem the built-in user flows actually already follow such approach in fact, but not when the prompt=create has been set, thus causing some inconsistency in the UI that users could notice unless custom CSS styling is applied. The expected behaviour for our business case would be that if prompt=create is set, then, similar to the prompt=login, no Back button should be displayed, or, if shown, it should result in some navigation (perhaps something like javascript.go(-1), but that could/would be dependent on from where the user arrived, e.g., going back a step in the browser history won't work if the user clicked a link from an invite email ) and preferably not be non-actionable. Furthermore, on the topic of the Back button and its behaviour when the prompt=create parameter is set, there is another case at which we observed some unexpected button behaviour as well, that could probably benefit from some attention. At a specific second scenario, it seems that the Continue button is displayed without providing any action, and when clicking the Back button then, clicking it seemingly resets the "create account", state likely set by the prompt=create initially, and instead switches the flow back to the sign-in state, which can at least affect the display text of some subsequent buttons shown in later steps in the UI. The user arrives at a built-in Entra External ID user flow /authorize endpoint, with the prompt=create query parameter set The user triggers the OTP challenge by entering an email address to verify the email address The user receives the OTP code but enters it incorrectly, i.e., doesn't copy the full code length of eight digits, and instead enters/pastes six of the eight code digits. The UI then shows an error message that the code could not be used/validated, and the email address field is displayed again with the email address that was used for the verification attempt prefilled. If the user clicks the Continue button at this stage, nothing happens. If the user clicks the Back button instead (given that it’s not hidden), it shows the same view one more time, with the Back and Continue buttons at the bottom. However, if the user clicks the Continue button this time, it works and a new code is sent. On the next screen, where the newly sent code can be entered, instead of a button named "Continue", it will now instead show a button with the text "Sign-in" (it would seem like the create account state has gotten lost somewhere along the way at this point, perhaps when the back button in the step 5 above was pressed). If one omits the prompt=create parameter, or when using prompt=login, things seem to work fine, the above occurs when the prompt=create is set. The reason why is the prompt=create is used is due to a business requirement to try to minimize the steps, especially in conjunction with the registration/sign-up, as far a possible when signing up. We have opted for the built-in user flows, not the self-hosted native authentication UI pages, for this project, and then as I understand it, it is the prompt=create parameter that can/should be used to enable the user to land directly on the registration page without having to navigate there manually via the sign-up link, that is otherwise shown on the initial sign-in page. It would thus be great if the prompt=create parameter could have some attention (or perhaps if a dedicated sign-up user flow type could be added potentially, even though that would perhaps warrant some update to the user flow app linking as well, as my understanding is that one user flow can be linked to one app registration at a time currently) to avoid that some buttons become unresponsive when the parameter is used, or falls back to sign-in, to improve the built-in user flows further, as the prompt=create fulfils the business requirement well otherwise. If there would be any further/follow-up questions on the above, e.g., to clarify the requirement, or further explain the reproduction steps and behaviour observed, or anything else, please tell, and I'll ensure to get back as soon as possible. Also, would someone have some input on potential other/additional ways to pre-select the create account/sign-up experience, that would naturally be much appreciated as well, thanks! Regards Kristoffer
Not able to do an account recovory when 2FA is enabled and Passkeey is half set up
I am not able to log into my personal account. I have tried account recovery, but I have 2FA set up so I go a message saying this is ignored. I have rest the password using 2FA but when I try to login the message is that I can not use password to login. I beleive my partern loged me out of the account and tried to log in to her account but instead started Passkey set up. I have needed to login with my company account even to raise this post. Any help would be great.Authenticator não funciona
Tenho um e-mail corporativo (sou o adm único, nao tem ti) que faço login na conta do powerbi, contudo, meu celular com o authenticator foi perdido e já nao tenho mais acesso, por este motivo, nao consigo mais logar na conta pq ele sempre direciona para o authenticador que nao tenho mais acesso e não abre a possibilidade de receber o codigo por outro meio, (sms ou email). ja tentei vários recursos (chat, telefone do suporte) para recuperar a conta e nao consigo. Todas as opções direcionam para o autenticador. solicito a microsoft que dê uma solução, resetando o autenticador anterior para que eu possa acessar a conta e incluir métodos alternativos de desbloqueio, ou sugira outra solução.
Trapped in an Authenticator Loop
Dear Community, please help! I am trapped in an Authenticator Loop. I've got a microsoft workplace account, but if I want to log in, I have to type in a code from the microsoft authenticator app. I downloaded the app, but in order to use it, I have to log into my account and in order to do so, I also have to type in a code from the authenticator app, which I don't get, because to get the code I would have to log into the authenticator app, what I would need a code for... No matter which link I click, I can't open anything before I enter the code, which I can't get. I am using teams on mac, either on a firefox browser or on the desktop app and the authenticator on an Iphone. Please don't just tell me "don't use teams on a mac", this wasn't my choice. Unfortunately, my emplyer's IT support also is chronically unavailable. So is here anyone who could help me? I've already gone through the usual deleting the app, using another browser etc. options. Best LukasLooking for an on-prem MFA solution for Active Directory and RDP
Hi everyone, We're reviewing options for adding MFA to our on-premises Active Directory environment. Most of our users authenticate with Active Directory, while administrators also use RDP for managing Windows servers. Because part of our infrastructure is isolated from the Internet, we'd prefer an on-premises MFA solution instead of relying on a cloud-only service. Has anyone implemented something similar recently? I'm interested in hearing: Which solution did you choose? How difficult was the deployment? Did you run into any compatibility or performance issues? Is there anything you'd do differently if you were deploying it again? Any real-world experience or recommendations would be greatly appreciated. Thanks!
