Using AzureAD, users can log in through https://portal.office.com/myapps to their assigned apps. Some of them use the password-based sso with the option "User manages credentials".
This works fine, the user gets a question for his password and this password is used for SSO. Exept when this password changes or is mistyped the first time, then the user can't change his own saved credentials unless two factor authentication is activated for this user.
What is the best way to let the initial password prompt reappear for an user, or give another way to reset the password without activating 2FA?
To answer my own question, there are two portals, the Office 365 version at https://portal.office.com/myapps and the Azure version at https://myapps.microsoft.com. At the second portal, you can click on the three dots and select "update credentials". This can only be done by the users themselves.
Another way, is via the Azure admin portal. There you can assign permissions to an app. We do this normally based on groups. If you assign the permission individually, you can set or change the password, but also empty the fields. This way the user will be re-prompted for their password. After this, you can delete the individual permission, so it's again only group assigned. This can only be done by an admin.
Related
I'm in a bind with Azure login account. I've forgotten my password for my account that I use for a client's DevOps. It wasn't until I ended up created another account today to troubleshoot the problem that I might understand the issue, but still can't fix it.
About a year ago, my client added me as a Guest in their Active Directory. I did not have an active directory myself. I got the notice from Microsoft in an invite email to get started, which created an account to get access to their Azure Portal and DevOps. I've been logged in for a year, but was trying test a feature which required me to login to DevOps during the process. I tried what I thought was my password, but that didn't work. No problem, I'll just click on the reset password feature. That ended up informing me that "password reset isn't properly set up for your organization." Knowing who setup my account up, I ask them to reset my password. The response was we do not have control to reset your password because you're a guest.
Through several discussions, and seeing what was available to them, and how a Guest was set up, it was suggested to setup an account within Microsoft for the email. I did that, and when I went back to try and login to their portal, I was presented with two options after I entered my email address. There was a work account and a personal account. Both with the same email address. The work account indicated it was created by "your IT department". Which we did not create this, it was a result of the client adding us as a guest, then finishing the process to gain access. So I can only assume, either an active directory was created for my domain, or I was added to a generic active directory.
In either case, I still can't change the password for the work account, and researching has not helped, as it keeps resetting my personal account.
Does anyone have any suggestions on how to resolve this issue?
Here is what I'm currently seeing.
Thank you,
Marc
You don't have an AAD tenant. So I assume that your account is an Microsoft personal account.
Although you are added as the guest user in your client's tenant, the password management is not handled by that tenant. It is still handled by Microsoft personal account.
You can reset your password here: click on Sign In, enter your account and click on Forgot password?.
In my Azure AD tenant, I currently have it configured so that users logging in for the first time must register at least one authentication method (e.g. an alternate email, a phone number). This is useful for MFA and self-service password reset (SSPR) - screenshot here.
I want to have several non-interactive service accounts that will not be configured for either MFA or for SSPR. Therefore, these non-interactive service accounts do not need alternate authentication methods. However, under my current setting, these service accounts are prompted to enter alternate authentication methods on first login:
First with the "More Info Required" screen (screenshot), which you
cannot cancel out of
And then with the "don't lose access to your
account!" screen (screenshot), which actually does allow for the user
to cancel the operation
This is extra inconvenient because, when adding an email, email verification is required, which doesn't allow us to do this programmatically (screenshot).
If I do just click "Cancel" on the "don't lose access to your account!" screen, I can simply proceed to sign-in without inputting alternate authentication methods (screenshot).
So the question is: how can I exclude a certain subset of users (e.g. non-interactive service accounts) from requiring alternate authentication info when first signing in?
We can include only a certain subset of groups for SSPR under Password Reset->Properties. This feature does not have an "Exclude" list, which makes it more difficult to implement.
More details in an MSDN forums post:
https://social.msdn.microsoft.com/Forums/en-US/51affd2c-a2c8-4faa-bbd8-bd1773c985d4/how-to-exclude-a-subset-of-users-from-requiring-authentication-info-when-first-signing-in?forum=WindowsAzureAD&prof=required
I am using username for the identity provider for local account.
When an user forget their username, is there a out-of-box policy that handle the username recovery? Or I have to implement it my own?
If I implement my own, as sign-in policy doesn't have UI customization that I will not be able to add a link for "For get your username" to redirect the user to my code to retrieve their username. Is there a way adding links on the Sign-In page?
There is no out of the box policy for forgotten username. It seems a nice feature though. But I anyway enforce usage of e-mail as username. And frankly, the way to implement this is a bit of a tricky.
You can first get (and confirm) users e-mail address which is registered with the AAD B2C. You have to send him/her an e-mail with a code to make sure that he/she owns the e-mail. Once you get e-mail confirmation, you can query the Graph API for the list of users and search for the provided e-mail.
As for providing link - you can have fully customized "Sign-in or sign-up" policy, where you can put the link. You need to use the special sign-in or sign-up policy, because currently it is the only one that allows for full user experience customisation.
When users in an MVC application with Google/Facebook/Twitter authentication, register for the first time, they go to the ExternalLoginConfirmation.cshtml page. There they are asked for their username, but are only allowed to fill in an email address, according to the ExternalLoginConfirmationViewModel model.
Is it set to email for a reason? In code it's creating a new applicationuser to store the user, but it's using just-entered-email for both username & email.
Can I go horribly wrong when I allow users to enter username of their choosing, and store email address as I got it from Google/Facebook/Twitter, etc?
I think the MVC5 registration flow is flawed by default, and needs to be reworked.
by trusting the default provider's emails (set email is auto confirmed from Google+, Yahoo, MS, and Facebook).
don't let the user enter an email+username, as he can register ANY email he enters in the box, straight to the AppUsers table.
MVC5 needs to create a User if not done so already at the ExternalLoginConfirmation method.
the default login password would be set to something blank, with links to reset it if needed (or totally disabled).
This would allow the users to register on any massively trusted providers automatically, it would link accounts together as long as their email is the same, and allow to unlink accounts once again.
The way MVC5 is setup right now is half-baked and broken, for no apparent reason.
When supporting a new web app in an enterprise environment, it is often necessary to log in as a specific user in order to diagnose a real or perceived problem they are having. Two opposing issues apply here:
Best practice is to use hashed or encrypted passwords, not clear text. Sometimes, there is a third-party SSO (single sign-on) in the middle. There is no way to retrieve the user's password. Unless the user provides it (not encouraged), there is no way to log in as that user.
Many web app's have personalization and complex authorization. Different users have different roles (admin, manager, user) with different permissions. Sometimes users can only see their data -- their customers or tasks. Some users have read-only access, while others can edit. So, each user's view of the web app is unique.
Assume that in an enterprise environment, it isn't feasible to go to the user's desk, or to connect directly to their machine.
How do you handle this situation?
Edit: I want to reiterate that in a large financial institution or typical Fortune 500 company with hundreds of thousands of employees all of the country, and around the world, it is not possible for a mere developer in some IT unit to be able to directly access a user's machine. Some of those are public-facing web apps used by customers (such as online banking and stock trading). And, many of those are intranet applications rely on Active Directory or an SSO, meaning that user credentials are the same for many applications. I do thank you all for your suggestions; some may be highly useful in other kinds of environments.
A number of these ideas inconvenience the user, either by forcing them to change their password, or by occupying their desktop for your debugging session.
Markc's idea is the best: augment your authentication logic to allow superusers to log in as a particular user by supplying not the user's credentials, but the user's name plus their superuser credentials.
I've done it like this in the past (pseudo-ish python):
if is_user_authenticated(username, userpassword):
login the user
else if ':' in userpassword:
supername, superpassword = userpassword.split(':')
if is_superuser_authenticated(supername, superpassword):
login the user
In other words, if the username and password don't authenticate, if the password has a colon, then it's actually the admin username and admin password joined by a colon, so login as the username if they are the right admin username and password.
This means you can login as the user without knowing their secrets, and without inconveniencing them.
For our web applications we use a process that for lack of a better term is defined as 'hijacking' a user's account.
Basically, administrators can 'hijack' a user's account with a simple button click. In the code, you simply use a unique identifier (user id works in a less secure environment) that then establishes the necessary credentials in the session so that they can then work within that user's profile. For a more secure environment you could use a unique hash for each user.
In order to ensure that this hijack method is secure, it always first verifies that the request is being made by an authenticated administrator with the appropriate rights. Because of this it becomes necessary for either the administrator's session to be hijacked or for their authentication credentials to be captured in order for someone to ever exploit the hijack function within the application.
I had 4 ideas. While I was typing 3 of them were already suggested (so I upvoted them)
Variant on idea 3 - impersonation:
To make this as "identical as possible" to a normal login with minimal code changes, you might add the ability to impersonate directly at login by supplying Admin credentials plus an alternate username, e.g. login as Admin:user, adminpassword. The system would treat this exactly as logging in as user with userpassword.
Idea 4: Can you access the password store? If so, temporarily replace the user's hash with the hash of a known password. (the passwords are often stored online in a database. A SQL Query tool can do the swaps )
An administrator should be able to change a user's password. Change the password for the user to something you know. You can then log in as that user.
Tell the user to reset his/her password after you are done debugging.
Usually by some sort of remote control software that can be used to view their desktop. If they're on a Windows terminal server, then the built in admin tools can be used for that. Otherwise I'd use something like VNC across an internal network, or an external service like LogMeIn (http://www.logmein.com/).
Could you have a testing environment where there is a regular cut of live data copied to (obviously sanitised to meet any security or data protection issues). A user similar in setup to the one having trouble could be used to troubleshoot or indeed the very user if this is allowed.
Use a remote desktop client as mentioned in other answers, but again this may not be practical for you. If you have these rights within the domain, I have heard of error handling even doing a screenscrape and including this in logs! but this sounds a little odd to me.
Could you have an admin tool to clone a user into a demo account?
The solution we have used in our web apps is to have the authN/authZ return the desired user as the effective user. We do this by having an admin feature to setup a masquerade, and then when we ask for the currently logged in user (current_user), we handle the masquerade:
def current_user_with_effective_user
if masked?
current_user_without_effective_user.masquerade_as
else
current_user_without_effective_user
end
end
alias_method_chain, :current_user, :effective_user