I have a web application that uses Integrated Windows Authentication to validate users. Most of them are remote and don't have access to a workstation to update their AD password.
Rather than manually managing passwords my self, I'd like to put together a script so they can change them on their own.
How would I update their windows password through ASP?
If you are going to offer this in a website, you should consider the security implications. A self-service password changing website is generally considered a major security risk and is not common.
You mention that your users are remote. If the site will be public, how will they authenticate through Integrated Authentication? They only way I know to make this possible is through VPN. Otherwise, they will have to use Basic Authentication to enter their username and password. This is very insecure, even over SSL.
Here are some recommendations:
Secure the site using client certificates. If this is not possible use SSL at a minimum.
I would strongly recommend that you implement the actual password-changing logic in a secure webservice. The ASP.NET page should call the webservice to request the change.
You should store an audit trail of password changes. DO NOT store the passwords, just an event log of the user, time, and IP address.
Test very thoroughly to ensure that the integrated security is recognizing your users properly. Make sure that users cannot accidentally change other users' passwords.
There is a function in the System.DirectoryServices namespace that seems to be able to handle this. You will need to add a reference to it in order to use it.
Here is the article on how to change user passwords:
http://msdn.microsoft.com/en-us/library/ms817839.aspx
http://support.microsoft.com/kb/555071
If you can set up IISADMPWD like this, you should be able to change passwords. This is actually an ASP application which relies on a COM component.
Note that IISADMPWD is obsolete and does not ship with IIS 7.0.
Related
I have a legacy, monster software that is built around SQL membership. It isn't the most elegant code and sometimes the code goes directly into the database to pull users or roles out.
I need to migrate this to Active Directory. I'm thinking of authenticating against Active Directory, then saving the user on-demand into SQL. That way, the rest of the code works when trying to work with users, roles, etc against SQL. I would also have to plug the places where users are created and deleted.
Is it possible to authenticate against Active Directory via form authentication, but use SQL membership for the rest?
I'm sure what you ask is possible, but you may want to consider authenticating against ADFS instead of directly against Active Directory.
ADFS issues security tokens you can use to make authorization decisions. You can have it issue role claims into the token based on look-ups in a SQL attribute store. If your application is using things like IPrincipal.IsInRole to determine permissions, it should not have to change much.
Moving your application to token based authentication will make it easier to make your application internet ready (ADFS proxy) or trust issuers from other authentication domains (federation).
I am currently working on a project in which I am rewriting an old (late 1990s) web application in ASP.NET. Part of this application is a user authentication system, which is used to access a couple of pages on the site. The user credentials (username, password, etc.) are stored in a database table.
This is all pretty standard, but while working with this database I found, to my horror, that this data is stored in plaintext.
I am wondering what the best way would be to improve the security of this insecure system. Is there an easy method of taking the plaintext data, encrypting (or hashing) it, and reinserting it? Can I use .NET Forms Authentication to facilitate any of this, and is it a good option for user authentication in the new app?
Thanks!
If you are on a Windows network, I'd use Windows Auth, which uses Active Directory. That would allow your Systems Admin group/person to administer who has access to the application.
Forms Auth is a good idea if Windows Auth won't work for you.
If they won't give you the time to implement either of the auth frameworks, I'd definitely encrypt the passwords on the database. Write a Console app and encrypt the passwords using information found here: Encrypt and decrypt a string
Then you'd need to modify your existing app to check encrypted passwords instead of plaintext ones.
I'm wanting to secure ELMAH in an internet facing application. The system uses Forms Authentication, but doesn't currently have any non-user accounts (e.g. Admins). The user accounts are set up in an automated fashion.
I don't really want to shoehorn any admin accounts into the system (the current DB schema for the users would be quite inappropriate for storing an admin user in), so I was thinking of corrupting the Forms authentication by checking for an SSL client certificate. If I pick all the right options in IIS, I believe I can ensure that only certificates issued by our internal CA (currently used for non-production sites needing SSL certs) will get passed through to ASP.Net.
I can then use the presence of a Valid ClientCertificate (checking IsPresent and IsValid properties of Request.ClientCertificate) to know that this is a connection from an internal user, and set the Forms Authentication cookie as "Diagnostic" or "Admin" (Or any other special username), and then secure elmah.axd using any of the usual methods suggested for doing it via Forms Authentication.
So my question is - am I overcomplicating things, missing something obvious, opening a massive security hole, etc?
Why don't you just store an admin user account credentials within Web.Config and lock down the URL using Forms Authentication anyway?
Edit
Ok, if the application is entirely internal anyway, why not secure a subdirectory of your site (e.g. myapplication.domain.com/exceptions/elmah.axd or even just myapplication.domain.com/elmah.axd) using Active Directory and set authorisation through IIS?
I'm looking for a way to pass some sort of credentials or Authorization token from a VB.Net Client to an ASP.Net web application that allows the Client to auto-login to our Forms-Authenticated website. If a user is logged into a local application, I want them to be able to view some web pages without having to login to the website as well. The credentials are not the same between the apps, but I would just like to pass some sort of encrypted token or key to the web page so I know they are coming from the desktop application. Is this possible without requiring a username and password login?
I also need to make sure this URL that is used cannot be simply copied and used from another location, so I'll need to include some sort of information in the encrypted value to know where it's coming from.
I know how to login the user with Forms Authentication and all that, just need to figure out the best way to secure this. Thanks!
OAuth is commonly used to allow desktop applications to access a user's private data on a web site. Since you're using .NET, I suggest you check out DotNetOpenAuth which includes sample OAuth web sites and client applications. It allows for this secure token to be passed that can tell your web site that the desktop app is the one making the requests and (usually) whose data is being accessed.
The best part about the OAuth solution is your desktop app never has to ask for the user's credentials. No credentials are in the URL. And if the desktop application is ever compromised (perhaps by the computer being stolen), the web site can kill the secure token the desktop app was using to cut off access without requiring the user to change their password.
You might want to look into issuing client-side certificates for these applications. Basically, you generate a certificate that you install with the client application and then on the server side, you check the ClientCertificate property of the HttpRequest instance exposed by the Request property on the current context.
Note that what you are doing is really a very bad idea, in that applications should never be assigned identity, only users. To that end, you should be authenticating each and every user that is using your app, not considering the application to be the identity. It's commonly considered a bad practice to do such a thing.
You can share credentials between the applications using ASP.NET Client Application Services.
Here are some resources:
Client Application Services
Client Application Services with Visual Studio 2008
Is your desktop app running on machines that are in the same domain as your web server (i.e. all in the same company)? If so, Integrated Windows Authentication is your easiest solution.
I think its best idea to use a web browser control inside the desktop application .
Then use the WebBrowser1.Document most probably
WebBrowser1.Document.Cookie
get if the user is singed in.
I also need to make sure this URL that
is used cannot be simply copied and
used from another location, so I'll
need to include some sort of
information in the encrypted value to
know where it's coming from.
If you store the encrypted value in a cookie or as a field in a form (POST request), then the credential is no longer in the URL and so it can't be easily copied (note that I said "easily").
I am in the process of writing an application that will need multiple forms of authentication.
The application will need to support authentication to Active Directory, but be able to fail back to a SQL Membership Provider if the user is not in Active Directory. We can handle the failing to the SQL Provider in code based on the username provided because the username will be a different format than the Active Directory username.
Is this even possible? What I mean is, can I use membership and use both ActiveDirectoryMembershipProvider and SqlMembershipProvider together or will I have to roll my own?
Another additional added complexity is that I would like to automatically authenticate my internal users based of Windows Authentication back to AD, but use Forms Authentication for users not on our internal network, or users that are using the SQL Provider.
These will most likely be separate servers, one internal, and the other external so I have a lot of planning to do to figure out the data replication, and how I will authenticate the AD users if they hit the outside server etc.
I am wondering what thoughts are out there as I start down this road. Is what I am wanting to do even possible without me rolling my own, or is there a way to mesh these together?
Thanks for the reply.
The reason I asked originally was because I was able to get this specific senerio working about 7 years ago using IIS to authenticate and then passing back the credentials to a Lotus Domino Server Web App. If the user was not authenticated via the Windows Authentication/ISS then Domino would handle the authentication. This was what I was looking to do here, but really couldn't think of a way to make it work in IIS.
As for the rest of your reply, I think you are on to the way that I will need to take. I have thought this through and tossed it around in my head a lot. The application will be somewhat different on the two servers anyway since there is going to be limited access to the data on the external server anyway. The fact that so much is going to be different already I may just treat these as two applications, thus negating the need to use two types of authentication in the same application anyway.
I am playing around with the idea already of writing my own authentication/login window for the external server, and if the user trys to log in with their AD credentials on the external server I will be able to detect that and redirect them to the internal server. If they are not on the local network or VPN'd in they will simply not get access. This part still has some thought process to go though so I am not sure.
As an additional thought - is there a way to pull just enough of AD into a SQL database to allow me to authenticate users to the SQL database from the external server using their AD credentials, without creating any security issues? I hope I am clearly typing what I am thinking....
Thanks again!
Tim
This is the way I've handled a similar situation based on this info:
Configured the application to use Forms authentication.
Set the LoginUrl to a page called WinLogin.aspx.
In WinLogin.aspx, use Request.ServerVariables["LOGON_USER"] to get the username then call FormsAuthentication.RedirectFromLoginPage( authorizedUserName, false ) to log them in. I guess you can manually check Active Directory as this point as well.
Create an html page that redirects to a page called Login.aspx
Login.aspx is your standard username/password login.
In IIS, Enable Integrated Authentication and Anonymous on the entire site, but deny anonymous access to WinLogin.aspx.
In IIS, set your 401 errors to the page created in step 3.
What basically happens is that when an unauthenicated user hits the site, they're redirected to WinLogin.aspx. Since anonymous is turned off, integrated security makes a check. If that passes, your custom code in WinLogin can run. If the integrated security check fails, a 401 error occurs. Your custom 401 page redirects to Login.aspx where the user can log in using their username and password with the SQL provider.
As far as I know, Web Applications are configured to use either Windows Authentication or Forms Authentication, but not both. Therefore, I do not believe it is possible to automatically authenticate internal users while requiring others to enter a username / password.
You could authenticate to Active Directory or a SQL user store via Forms authentication by using a custom provider. However, the AD users would still need to enter their username and password. Although I've never combined these two methods, I have used Forms authentication to authenticate against both sources at one time or another.
With that said, I think you may want to consider reducing the "flexibility" of your system. If you have an external facing server and an internal facing server, you could simply change the provider configuration on each copy of the application to go against a different source. Then, you could configure the internal one to use Windows (automatic) authentication and the external one to use Forms authentication.
IMHO, I believe that internal users should not be using the external server to access the application. If they are, they should have a user account stored in SQL, completely separated from their AD account. Basically, when someone accesses the application externally, they are acting as an external user, irregardless of their physical location.
Well, it is possible to use ActiveDirectoryMembershipProvider and SqlMembershipProvider, but this requires you design your log on page with your own code instead of the Login controls.
About the mix authentication (Windows and Forms), as far as I know only IIS 7 makes it easy and clean. See this post for details,
http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx