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.
Related
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?
So I have set up a IIS 7 server with windows authentication, and all works well. I have an aspx (test page) returning the users name and groups.
Code:
IIdentity WinId = HttpContext.Current.User.Identity;
WindowsIdentity wi = (WindowsIdentity)WinId;
string userDomain = wi.Name.ToString();
the userdomain string returns (example) "DOMAIN/username"
however, I have only one user on my domain (same active directory groups as similar users) but he returns "Server/administrator". I checked all the groups in security and he doesn't belong to them. So im out of ideas.
EDIT: See my answer below (figured it out)
There are two places storing user accounts, local SAM store and Active Directory.
If you see "Server\username", it means you have logon to the machine using an account from local SAM store.
If you see "Domain\username", it means you have logon to the machine using an account from Active Directory
The confusion usually comes up when you have a local user account with the same user name as a domain user account. The built-in account "administrator" is usually one of the most common accounts causing this confusion.
In order to make sure you logon using a domain account but not a local user account, you can specify fully qualified name at the logon time. e.g. Domain\Administrator or Server\Administartor
Figured it out. He had a certificate attached to his user account that didn't get destroyed when using remote desktop connection. Thanks anyway.
I am using
FormsAuthentication.SetAuthCookie("username", true );
so that a helpdesk person could impersonate another person's ans go in and see what the account looks like. I as wondering if there is a way my code can determine that this session is running through impersonation (so that I can block a couple of pages and flash a sign saying "You are impersonating this user: username)?
The best thing to do here is make sure the helpdesk users have to be logged in as themselves before they go to the page that allows them to impersonate another user.
At that point, either save a session variable or send a second cookie down to the browser that identifies who they really are and any other info you need to keep up with. I prefer storing this in session variables because it is more secure and you remain in control of the information on the server.
The rest of your code would work mostly like it does now responding as if the user really were the one they impersonate, but any code that needs to test for impersonation can read the session or alt cookie to know if they are impersonating or not.
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.
We have an ASP.NET application that manages it's own User, Roles and Permission database and we have recently added a field to the User table to hold the Windows domain account.
I would like to make it so that the user doesn't have to physically log in to our application, but rather would be automatically logged in based on the currently logged in Windows domain account DOMAIN\username. We want to authenticate the Windows domain account against our own User table.
This is a piece of cake to do in Windows Forms, is it possible to do this in Web Forms?
I don't want the user to be prompted with a Windows challenge screen, I want our system to handle the log in.
Clarification: We are using our own custom Principal object.
Clarification: Not sure if it makes a difference or not, but we are using IIS7.
Integration of this sort is at the server level, it's IIS that decides that the user is not logged in; and it's IIS that sends back the authentication prompt to the user, to which the browser reacts.
As you want to use the domain login there is only one way to do this; integrated windows authentication. This will only work if the IIS server is also part of the domain and the users are accessing the machine directly, not through a proxy, and from machines which are also part of the domain (with the users suitably logged in).
However your custom principal object may create fun and games; authentication of this type will be a WindowsPrincipal and a WindowsIdentity; which you can access via the User object (see How To: Use Windows Authentication in ASP.NET 2.0)
I assume you want a custom principal because of your custom roles? I doubt you can get the two to play nicely; you could create a custom role provider which looks at your data store or look at you could look at ADAM, an extension to AD which provides roles on a per program basis and comes with nice management tools.
I did pretty much exactly what you want to do a few years ago. Im trying to find some code for it, though it was at a previous job so that code is at home.
I do remember though i used this article as my starting point. You set up the LDAP provider so you can actually run a check of the user vs the LDAP. One thing to make sure of if you try the LDAP approach. In the setting file where you set up the LDAP make sure LDAP is all caps, if it is not it will not resolve.
using System.Security.Principal;
...
WindowsPrincipal wp = (WindowsPrincipal)HttpContext.Current.User;
to get the current domain user. Of course you have to make sure that the IIS is set up to handle Windows Authentication.
This might be helpful:
WindowsIdentity myIdentity = WindowsIdentity.GetCurrent();
WindowsPrincipal myPrincipal = new WindowsPrincipal(myIdentity);
string name = myPrincipal.Identity.Name;
string authType = myPrincipal.Identity.AuthenticationType;
string isAuth = myPrincipal.Identity.IsAuthenticated.ToString();
string identName = myIdentity.Name;
string identType = myIdentity.AuthenticationType;
string identIsAuth = myIdentity.IsAuthenticated.ToString();
string iSAnon = myIdentity.IsAnonymous.ToString();
string isG = myIdentity.IsGuest.ToString();
string isSys = myIdentity.IsSystem.ToString();
string token = myIdentity.Token.ToString();
Disclaimer: I got this from a technet article, but I can't find the link.
You can use System.Threading.Thread.CurrentPrincipal.
Request.ServerVariables["REMOTE_USER"]
This is unverified for your setup, but I recall using this awhile back.
Try Request.ServerVariables("LOGON_USER").
If the directory security options are set so that this directory does not allow anonymous users, when the surfer hits this page they will be prompted with the standard modal dialog asking for username and password. Request.ServerVariables("LOGON_USER") will return that user.
However, this will probably not work for you because you are using your own custom security objects. If you can figure out how to get around that logon box, or pass in NT credentials to the site before it askes for them, then you would be all set.
Have you thought about impersonation? You could store the user's NT logon credentials in your custom security object, and then just impseronate the user via code when appropriate.
http://msdn.microsoft.com/en-us/library/aa292118(VS.71).aspx