mobile
28 TopicsAdd filters/ grouping to microsoft authenticator app accounts
Hello! Hope you are all well! I would like to see filters of personal/ Work and school accounts or by domain. Or even the ability to organise accounts manually into groups. Currently have a long list of personal accounts and work account.7.8KViews6likes10CommentsMicrosoft Authenticator (iOS) 6.4.36 - What’s New?
Can someone at Microsoft comment on what the update contains (v6.4.36)? I don’t know why Microsoft even bothers including release notes if they’re just going to write something this vague: “We’re always working on new features, bug fixes, and performance improvements. Make sure you stay updated with the latest version for the best authentication experience.” Okay, great. I’m glad you update your apps like every other developer, but can you please elaborate on what you actually added, fixed, or improved? That’s the whole point of having release notes. I even checked Microsoft Roadmap (though I shouldn’t have to) and found nothing for Microsoft Authenticator, so I’m coming here as a last resort. This goes for your other mobiles apps as well, by the way - PLEASE buck the awful industry trend of skimping on release notes.1.9KViews2likes1CommentAuthentication with ADAL using managed Mobile devices
Hi everybody, I am facing a very strange authentication problem in my app. To get a valid adal token I use the adaljs library, which works fine. I get a valid token and can connect to my Azure AppService. The app that runs in the Azure AppService then uses my adal token to get a new token. I create a UserAssertion object from the token I got from Javascript adaljs. I need to do this, because otherwise I could not connect to SharePoint Online without getting a 401 unauthorized. The code works perfectly fine for desktop browsers but does fail when I try to access my AppService with a mobile device and a adfs managed user. Using a "cloud only" user works fine, but whenever I try to use a user which gets synced from my AD I get the following error when trying to get the second token: AADSTS50131: Your device is required to be managed to access this resource. The problem here is that the device is definitely managed. When I add an exception for this user in intune, I can access the App via the mobile device. Has anybody a clue what could be the problem here? Any help would be appreciated. Thanks in advance, Alex3.4KViews1like3CommentsFIDO2 Office 365 and Windows Hello For Business Sign-in?
I saw that this was in preview a year ago. https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/bg-p/Identity Is logging into Windows 10 Hybrid joined systems using FIDO security keys now working? What about signing into Office 365 desktop apps, mobile apps and web apps with FIDO security keys?11KViews1like2CommentsO365 MFA Mobile App Security Concern
We have implemented MFA in a broad section of test users. MFA was on the deployment plan, but it's getting fast tracked to mitigate an all out barrage of phishing attacks recently that specifically target non-MFA O365 users. I assume that the vector in known to everyone, but to summarize. User receives phishing email. User acts on phishing email and provides their username/password to bad actor. Bad actor logs in to Office 365 via web portal using username/password of user. Bad actor trolls Outlook on the Web and finds relevant emails. Bad actor initiates new email from within O365 portal as user using language from user's email. Bad actor creates one or more Outlook rules via the web to handle bounces and replies. Bad actor maintains presence via Outlook on the Web, coming and going freely, until they are found by log scans or suspicious user or recipient of outbound emails. MFA short circuits this process and is therefore good. One of the options for secondary verification via the mobile app is to receive auth request via the mobile app. This reduces complexity by allowing the user to just press Approve. The problem is that the same sort of user who would unknowingly be tricked into clicking and acting on a phishing scam is the same user who would blindly click on "Approve" if an auth request came in without an associated known logon attempt. Why do I think this? Because when I talk to the rank and file user, most of them are never aware that they compromised their credential. As a matter of fact, most of them don't even remember entering their credential. It's entirely possible that they would receive an MFA Approve request and just press Approve because they figure that since the system is asking for something, that they must have done something to initiate it. Additionally, although I have not heard of this happening, I could imaging a hacker scripting the process at the time of the initial compromise to pass the credentials to O365. That would kick off an Auth request and the user would think that they were responding to the initial request. Having to enter a code, either via the app or from a text forces the user to interact with a part of the auth process. That one feels to me like it would be harder to spoof. I keep thinking about this issue and hoping that I'm missing something and that it's not possible, but I've tested it up and down using multiple systems and, so far, it's totally possible. Here's a simple test assuming that an account is configured to allow Auth requests via the mobile app. Go to anyone else's mobile device other than yours (assuming yours is the test account). Using the other mobile device's browser, log on to portal.office.com. Authenticate using your (test account's) user name and password. Imaging that you are entering from halfway around the world. The auth request will show up on your verification phone (test account device). Blindly press Authorize as an unsuspecting user might. You will be granted access via the alien device and, if the unwitting user was nice enough to click "Don't ask me for X days" then you may have just bought yourself some more hack time. Am I missing something? Is this actually a reality. AndySolved4.6KViews1like6Comments