I am working on an old ASP.NET application whose end users authenticate with a local Windows account (no domain). We want to switch to using membership (via aspnet_regsql), and move the application to a new server. What's the best way to seamlessly do this?
My biggest concern is I don't want every single user to have to go through the "forgot password" process. Regarding passwords. As I understand, there's no supported way to get at the passwords in order to convert them to membership users. Is there an unsupported way to grab the passwords?
There are about 1000 users, and they log into the system rarely -- maybe a few times per year. Point being: there will be a huge % of users that won't log in until the old system is dead and gone.
My current thought is that we will need to implement two workflows:
Before migration to the new server, anyone that logs in will be authenticated with Windows, and their account automatically converted to a membership user. We will have their password from our custom login page.
After migration, anyone logging in that hasn't been converted to membership will have to go through the "forgot password" routine. We would present a message to them explaining why.
So bottom line: Is there a way to do this without requiring users to go through the forgot password process at all?
I would expect you cannot get the passwords from the windows accounts, you could import the users, create a password and send out an email to users with their new password or you could send a link for users to login and create a password or request a password reset given their email address?
Related
I am creating an asp.net web application with "Remember Me" option during Login and it has an Edit Profile module where users can change their passwords. Here is the scenario.
I logged into the website from Machine A clicking "Remember Me". So I am logged in and since a persistent cookie is created I dont need to login the next time
until my forms authentication times out.
I logged into the website from Machine B using the same account details I used above and from this machine, I changed my password. In this case How can I make the user in Machine A to login again? (Since my credentials have changed). The same scenario can happen if someone gets any user's credential and uses the application.
Thanks
You have to save the last credentials modification date in your database.
When a user try to consult a page of your website, you have to check the date specified in the cookie.
You can also make an AJAX system that verify each minute if any changes are done and, in that case, verify the validity of the credentials.
If the latest date is the "last credentials modification", then delete the cookie and ask the user to log by himself.
I am developing an asp.net application with Windows authentication. User.Identity.Name seems to return the logged in user in the form MACHINENAME\USERNAME.
I would like to use this to access a database of user specific settings but what happens if the user logs on from a different machine, then the MACHINENAME part will be different. So can I simply take the USERNAME part and ignore the MACHINENAME part? Is the format of User.Identity.Name always MACHINENAME\USERNAME for Windows authentication?
Thanks,
AJ
More specifically, User.Identity.Name returns in the format [Domain]\[User]
If your users are showing up as different domains when they access from different machines, then they are in fact different user accounts. You may be able to strip out the [Domain] part, but that means that if anybody on a machine (domain) connects as a user with the same name as a user on a different machine (domain) then the system won't be able to tell them apart. This may be "fine, for now" in your scenario, but it's definitely not good practice.
Example scenario in an ASP.NET application using SQL Server membership provider :
1) a user can't remember their exact password, and tries many times in a short space of time to login with an invalid password (say 5 times in a 10 minute window). This locks out the user (i.e. sets the IsLockedOut flag of the aspnet_Membership table to 1).
2) user goes to the "forgot my password" screen to try to get a new password emailed to them. This screen uses the PasswordRecovery control. User enters their correct user id, but then cannot go further in the password recovery process, since the IsLockedOut flag is 1. (They don't even get to see their security question).
3) The user would then have to phone tech support to get themselves unlocked etc.
To reduce the burden on support staff, we are trying to reduce the times step 3 is required, by making the PasswordRecovery control (if possible), work with locked out users. i.e. when they enter their login ID, the security question comes up, and IF they enter the correct answer, the system will unlock the user, and email the new temporary password to them. I'm wondering if it is possible to tweak the PasswordRecovery control to do this. Or maybe this approach has security issues ?
You could create a custom membership provider that has an AutoUnlockTimeout setting that can be configured via configuration - Implementing Automatic Unlocking in ASP.NET 2.0 SqlMembershipProvider.
I am trying to find a way to handle two types of users for an intranet system. There are users who login and there are those who do not. I need to store both types of users in the membership db. Does anyone have a common solution to this problem?
This is for an event booking system. The users who are in AD will see the app. We need to store the O/S Name along with a few other attributes from AD in our membership db. The O/S Name gets captured using the Request.ServerVariables(). We need to store those "requester" details along with other details about the event that is being booked.. In addition to those users, there are users that actually log into the system. I was hoping to store both types of users in the membership db, so that when an event is retrieved, the user details will get retrieved from the membership db as wel
If you can use 'Integrated Windows Authentication' you have access to some information about the user connecting to your system.
Therefore you could use this information for the general case, without the login.
If a user then want's more access, he can logon to the site with a special username/pwd.
A membership DB would typically restrict access to a set of users for a particular application on an Intranet site. Only those who are in Active Directory as network users would even see the Intranet in the first place. And only a subset of those network users who have been granted privileges for your application in its membership system would see the link and/or be able to gain access in one role or another. Can you be a little more specific with respect to what you are trying to achieve? :-)
very simple question:
I have admin site in my web project. So, how can I make it safe?
What I have until now:
Database handled user with userID and userlevel
on the pageload of the admin master page (which includes all admin sites) there is a clause to check if userID is okay (get the user from database) and if userlevel is right
If Not, redirect to Default.aspx with normal master page
if yes, go trought
How safe is it really?
Edit:
The userID is saved in a session on the server.
There is no way to save the login (no cookies).
The user must login to get the userID in the session
The login is saved in a database table user_log with username, password, ip, loginsucceeded and userID
The basic idea looks ok. It all comes down to how you are getting that UserID to make the checks against. If the userID is being passed as a querystring, then that is very bad. If it is stored in a session via sometype of pre authorization then it is better. If you are using SSL, IP checking, etc it will improve your level of security.
The main thing is HOW you are getting the userID to verify against. That is where the exploit will occur. Secure that process and you should be ok with your setup.
Edit: Based on your update this looks ok but it also depends on how secure you really need this to be. How secure is your sign in page? Are you using SSL? Any worries about session highjacking? Why not store an IP with the userID and verify the request IP against the stored IP when doing the UserID fetch from the session?
There are so many security solutions out there. You need to decide how far you need to safely go to ensure the level of security that is necessary for your particular application.
We use integrated windows authentication.
In IIS manager, click the "Directory Security" tab
Uncheck "Anonymous Access"
Check "Integrated Windows Authentication"
This lets you administer who has rights to your admin site by modifying domain accounts instead of using a roll-your-own solution. You can still get the logged-in user's credentials via the Environment class, which can be used to associate any web-specific properties for each user that you want to store in your database. This also has the advantage of automatically handling timeouts, relogin requirement if browser was closed, etc.
Your solution looks almost fine, though it sounds as though you're adding individual user accounts to the SQL server instead of handling everything through the ASP.NET service account login. I'd avoid adding individual user accounts into your database. In ASP.NET, unless you're jumping through some useless hoops, the ASP.NET service account is what is authenticated for DB connectivity, not the user that's logged into the site.