I want to know whats the "right" way to setup membership in a new website.
When i have new project i can go to Website/ASP.NET Configuration. There i can setup Forms authentication and manage all users that will be using this page. I can make roles and rules on folders. All of this info are saved into table that will be saved locally in database App_Data/ASPNETDB.MDF. What i'm trying to do is that all this info would be on a host server along with the website but not locally.
What is the best way to connect my website that i made locally to a mssql server that is central. I want to be able to go to the asp.net configuration and manage users but i want the data to be saved in the tables on the mssql server not to the aspnetdb.mdf file.
I have already made the asp.net membership tables on the mssql server by using the aspnet_regsql.exe file.
Update:
Never mind, i found out a way to to this.
Just had to add
<remove name="LocalSqlServer"/>
in <ConnectionStrings> and then my own connection string. Now its working...
There is a line command in the Visual Studio SDK called "aspnet_regsql". It opens a window, and you can use it to set up the ASP.NET membership, roles, and profile support in any SQL Server database.
For most applications, you'll probably end up writing your own membership admin pages. It's not hard, and most of the controls you need are in the toolbox in Visual Studio. Here's the cookbook I've given in presentations on security:
To add ASP.NET membership and roles to an existing SQL Server database:
Open a Visual Studio 2008 command window.
(If you must run SQL line commands in Administrator mode, you will need
to open a command line in administrator mode, then set the path to
include the Visual Studio SDK executables.)
Run aspnet_regsql in that command window.
For the SQL user logins that will use the database, add one or more
of the following membership provider roles:
aspnet_Membership_FullAccess - if users can register themselves or others
aspnet_Membership_BasicAccess - users cannot register themselves
aspnet_Membership_ReportingAccess - for membership statistics
For the SQL user logins, add one or more of the following role provider roles:
aspnet_Roles_FullAccess - create and delete roles
aspnet_Roles_BasicAccess - use asp.net roles
Configure your initial application and roles using SQL Server Management Studio:
exec aspnet_Applications_CreateApplication #ApplicationName='Northwind',#ApplicationID=''
exec aspnet_Roles_CreateRole #ApplicationName='Northwind', #RoleName='Employee'
exec aspnet_Roles_CreateRole #ApplicationName='Northwind', #RoleName='Manager'
exec aspnet_Roles_CreateRole #ApplicationName='Northwind', #RoleName='Master'
Implement your "New User" page, but don't lock it down with forms authorization yet.
You may want to implement your own form, assuming you have user records already existing
in your database, and assuming that you'd like to add roles as part of the "create user"
process. In any case, use this page to create an initial set of users for ASP.NET
membership; it's easier this way than trying to make it work with stored procedures.
See sample code for an implementation of user creation without using the ASP.NET
LoginView control.
Note that this "Add a User" page in the sample application assumes a number of things
that are hard to do with the standard Login control in ASP.NET. If you're creating users
as an administrative function, rather than letting users add themselves, you probably
want to have multiple roles, and be able to select the role. Even more important,
you may have "user" tables already established in your database, and need to integrate
"new user" functionality with adding records to your application's user table. This is
a prototype for creating your own Login control, collecting additional data and
integrating the creation of user records, ASP.NET membership records, and ASP.NET role
assignments. All of this is done within an ambient transaction, so they either succeed
or fail as a single unit of work.
Once you've created users and added them to roles, you can set up forms authentication
and lock down your pages that require authorization. Notes:
a. Don't require authentication for your top-level directory. Pages at this level
should be publicly accessible.
b. Add a web.config in each subdirectory where pages require authentication.
Usually, setting the authentication level will be the only function in these
web.config files.
Related
I have looked at numerous articles and tried a multitude of settings, but I can't seem to achieve what I'm looking for in my intranet site. Even if I don't get a solution, a definitive "you can't do that" will help me move forward. Here is what I'm trying to do:
Web site recognizes the user's network login credentials - ONLY so I can get their user ID without a login
The website uses some generic account (IUSR or something like that) to access a SQL Server that the same network users can NOT access EXCEPT through the website
Users can upload files to a set of folders created on-the-fly by the website to contain their files for later reference by them
The website can construct web pages on-the-fly with links to the users' files - and ONLY theirs - so they can open / download them through the web pages
Users can NOT access the uploaded files through a network share on the web server
All of the folder creation, file upload, and file serving occur under some generic account like IUSR
I currently have things configured to use Windows Authentication and I could probably live with that except I don't want to require a login to the site. Apparently, in order to make this happen, I need to have the server configured as a trusted delegate and IT is dragging their feet on doing that. Also, this config allows the users to access the SQL Server and folders/files through means other than the web site and I don't really want that. I only need to pick off their user ID so I can use it to get information about them out of Active Directory and keep track of their interactions with the web app.
In reviewing your post I must first say "Yes" it seems like what you want to accomplish can be done. However the enormity of your question precludes simple posting answers. From what I gather there are three security issues you want to navigate 1) Windows Authentication, 2) Admin only SQL access, 3) User only Access to files and directories while authenticated using Active Directory.
I have been building ASP.net intranet web applications using Active Directory (Windows logins) for a few months. I would encourage you to explore this article: http://www.mikesdotnetting.com/article/216/windows-authentication-with-asp-net-web-pages for details on setting up windows authentication in an ASP.net web application. You can add elements to your web pages using a section of Visual Studio [Toolbox] called 'Login', which contains elements such as 'LoginName'.
Next I am pretty sure you can control the SQL server query access using authentication parameters of your choosing. In the portion of the connectionString that is normally 'Integrated Security=True;' you will need to switch that to 'Integrated Security=False;username=sqlAdminUserName;password=sqlAdminPassword'. For more information I suggest reviewing this post: Integrated Security = False.
For the third security issue once you have isolated the user's windows login identity you should be able to dynamically build web pages, files, directories, and whatever other resources you require all customized for that individual user. I believe the generation of all those materials can be done with an IUSR account with the only needed ingredient being the Windows login user identity.
Good Luck and I hope my suggestions help move you ahead.
Actually, the answer is not all that complex and it is a real mystery why it is so difficult to find a single source on the web to spell it out. Here is my IIS authentication for an intranet app that acts exactly how I want:
Enable ASP.NET Impersonation and edit to Authenticated User
Enable Windows Authentication
Advanced Settings->Extended Protection->Off
Advanced Settings->Enable Kernel-mode authentication->unchecked
Providers->Available Providers->Negotiate:Kerberos and move that to the top
Disable all other authentications
Most critical: Make the server a 'trusted delegate' in Active Directory
That should do it.
We have completed developing a custom CMS using ASP.NET. The CMS will be setup in IIS hundreds to thousands of times (one per domain). The CMS uses SQL Server to store page content, settings etc.
Should we create a new SQL Server login (using SQL Authentication) for every website or should we use the same login for all websites?
Any thoughts on this would be appreciated
If you are going to the trouble of provisioning a separate CMS and DB for each instance, then you should create a separate sql login for each instance.
This way you add one more layer of security to the design (and incur little more of your already hellish maintenance cost).
It would seem safer to let each site have it's own login.
That way you can't look at the wrong content database by accident (or mischief).
I would advise using Windows Authentication in SQL. It is easier to set up, and doesn't require storing passwords in web.config files.
You can further restrict this user account for security purposes.
Also don't let these user accounts use the same passwords, that screams insecurity.
I am just learning the admin side of this in the Web Site Administration Tool, having set up a new project. I have accessed the security panel at the back end, and created an admin role, which is used to access a view through a controller filter. All standard stuff.
However when I try to log in to the front end with this user, it doesn't exist, and I have to create it afresh.
Alternatively when I create a user at the front end, and try to assign him an admin role at the back end it he also doesn't exist.
Only users created at the back end, exist at the back end and can be assigned roles
There seems to be no connection between front end users and back end users. There appears to be two separate databases one holding front end users and one back end users.
Giving a backend user admin rights doesn't seem to work from the front end.
is there some explanation on how this system work around? I have used google without help.
If you're using a standard asp.net mvc 4 application, then yes. This is to be expected.
The reason is that MVC4 by default users a different membership provider called SimpleMembership, and this provider is not compatible with the ASP.NET Configuration utility. That configuration utility uses the old membership provider, which has entirely different tables.
Your options are:
don't use the web configuration utility. Add users manually, or through a script, or maybe create your own admin pages.
Disable simple membership so that MVC uses the old membership system
do something completely different (don't use membership, use a different provider, create your own provider, etc...)
As for a separate database, yes. If you notice, there is no membership configuration in your web.config. Instead, the ASP.NET Congifuration utility uses the default membership configuration that's defined in your machine.config in c:\windows\microsoft.net\framework[64]\config. the default location is a file located in your project directory under the App_Data directory called aspnet.mdf
EDIT:
More information about the new provider here:
http://weblogs.asp.net/jgalloway/archive/2012/08/29/simplemembership-membership-providers-universal-providers-and-the-new-asp-net-4-5-web-forms-and-asp-net-mvc-4-templates.aspx
Also:
http://geekswithblogs.net/Aligned/archive/2012/08/30/mvc-4-authentication.aspx
I have set up an Active Directory Membership provider and can successfully create and log in users into the active directory with an ASP.NET application.
However, the active directory has other fields besides Username/Password such as First Name, Last Name , Telephone Number etc. Is there any way for me to be able to gather this information using my ASP.NET website and store it in the Active Directory?
I understand that I need to use a Profile Provider and I can technically set it up to use an SQL DB to store the extra profile information, but is there any way I can store the information directly in the fields available in the Active Directory? As far as I know there is no ActiveDirectoryProfileProvider.
Thank you,
You could get there -- probably would need to step outside the membership system and use the System.DirectoryServices to write to AD. Now, writing to SQL will be a lot easier, especially at development time. And you won't have to fight a sysadmin who doesn't want your web app having elevated AD privileges.
If I am using Windows Authentication in an ASP.NET app, and I want to use custom roles instead of using Windows security groups as roles, do I need to write a custom Role provider? The solution needs to be able to map Windows users and groups to application specific roles.
If I understand your question - no you don't need to use roles from Active Directory security groups as roles for your ASP.NET application. And you dont need to implement a custom Role provider. The default one simply retrieves the Roles from the ASP.NET application database.
You can simply have application defined roles in this database, that you create with the aspnet_regsql.exe utility (in the .NET 2.0 framework folder).
Probably the greatest collections of resources/information on this topic:
http://weblogs.asp.net/scottgu/archive/2006/02/24/ASP.NET-2.0-Membership_2C00_-Roles_2C00_-Forms-Authentication_2C00_-and-Security-Resources-.aspx
Actually you CAN use the built in ASP.NET security configuration web site. You have to temporarily switch to Internet Mode, Then you can add users DOMAIN\username as username, enter some password (it won't be used once you switch back), you can then assign these to roles. Once you switch back to Windows mode these users will be used automatically.