Our client requested from us to make our web application accessible from Intranet and Internet.
When user tried to access the website from Intranet, The user should be logged in immediately (Windows Auth) ... The user should have public access also (e.g. Home, Coffee shop), But in this case he should use his credentials and the server will check if its valid.
Any advises?
This is the standard way Integrated Windows Authentication works. If you're inside the intranet (logged onto the domain), IE will automatically send your credentials when the website returns 401.2 (no auth method specified). When you're not inside the domain, the credentials will have to be prompted for, since the domain server cannot be contacted from the client machine.
This is not the same as the "tricky" solution you referred to. That solution is tricky because it also uses forms authentication, which you don't need here (AFAIK).
We decided not to use Windows Auth at all.
The customer want to stay logged in if he is in the Intranet.
so we did the following (and the customer is ok with that)
Forms Auth + 'Keeps me logged in' checkbox
Validate Credentials with AD.
Check if User in trusted IP Addresses Range (Something like allowed IP addresses in SQL Azure)
If trusted IP Range, user becomes authenticated.
If its not, Two factor auth by sending SMS.
One more reason for not using Windows Auth.
The user want to log-out at anytime to use different credentials to do some special tasks.
Usually customers do not know what exactly they want, so we will start dreaming and make things complicated. 'Simply keeps me logged in' for trusted IP addresses and he will stay logged in for N days.
Related
Is it possible to grab a users windows credentials (i.e. username) without having windows authentication enabled in IIS? With windows auth disabled the code below returns either NT AUTHORITY or IIS APPPOOL\ASP.NET v4.0 depending on if impersonation and anonymous authentication are enabled or not.
System.Security.Principal.WindowsIdentity.GetCurrent().Name.ToString();
I am converting an asp.net web application that is using forms authentication to custom authentication. Basically if a user is connecting from outside the network I force a credential check whereas if they are connecting from within the network I would like to be able to just grab their windows username. The internal portion works when I turn on windows authentication but I get the popup login box when testing outside of the network. I either need to disable windows authentication for non local connections or figure out how to get the windows username with windows authentication disabled. Any suggestions? (The other alternative i thought of was splitting the application in two and having separate authentication modes for each but I'd like to avoid this).
-I have also tried:
System.Web.HttpContext.Current.User.Identity.ToString();
System.Threading.Thread.CurrentPrincipal.ToString();
something like this is actually (kind of) possible using Active Directory Federated Services. In the event of a windows user from inside the network they can be configured to use their account details. For external users, they can be redirected to a page that will require them to log in.
However. This is very heavy-duty and an extreme pain in the..neck to implement and is really only applicable to enterprise solutions that have the resourses to use this kind of solution. Otherwise, I'd say go with the 2 site approach.
Simple answer is no.
Best solution is to create 2 sites. One for internal users that user windows authentication, one for external user that user forms authentication but authenticate against AD. You can make users always go to external site by default and then redirect based on their IP. That is redirect intranet users to internal user.
I'm developing a website in ASP.NET and C#.
I've created the website so when a user goes to the site, his windows client username is read out with:
System.Security.Principal.WindowsIdentity.GetCurrent().Name.ToString();
and then I lookup his username in the db and create a user object with all necessary data (team, name, permission level, role, ...) from the return data.
Then I keep this object in a session var until the user logs out.
This was working like a charm locally but now that I've deployed to the server I get defaultAppPool for every user.
What am I doing wrong?
In my web.config file I have:
authentication mode="Windows"
I have to admit this is the first time that I'm doing the deploying myself and everything went smoothly except for this.
As you've discovered, System.Security.Principal.WindowsIdentity.GetCurrent() gives you the identity of the application pool.
You should be using HttpContext.Current.User.Identity.
Windows authentication and IIS
If you select Windows authentication for your ASP.NET application, you also need to configure authentication within IIS. That’s because Windows authentication is delegated back to IIS. IIS gives you a choice of four authentication methods:
If you select anonymous authentication, IIS does not perform any authentication. Anyone is allowed access to the ASP.NET application.
If you select basic authentication, users must provide a Windows username and password to connect. This information is sent across the network in clear text, making basic authentication dangerously insecure on the Internet.
If you select digest authentication, users must still provide a Windows username and password to connect. However, the password is hashed before being sent across the network. Digest authentication requires that all users be running Internet Explorer 5 or later and that Windows accounts be stored in Active Directory.
If you select Windows integrated authentication, passwords never cross the network. Users must still have a Windows username and password, but either the Kerberos or challenge/response protocols are used to authenticate the user. Windows-integrated authentication requires that all users be running Internet Explorer 3.01 or later.
Get current user identity as :
var userWinId = HttpContext.Current.User.Identity as WindowsIdentity;
Use
System.Web.HttpContext.Current.User.Identity.Name
instead of
User.Identity.Name
or
System.Security.Principal.WindowsIdentity.GetCurrent().Name
We are implementing the following log on mechanism for our 3-tier application:
User launches the client application and -
authenticates using her Windows session credentials (Active Directory)
or enters her AD credentials if another user is already logged on to this Windows session
or enters her user name and password if the computer is not on the AD domain.
I.e. something like the SQL Server Management Studio log on box (+point 2. above).
The solution we came up with is having two endpoints, with two system bindings (one with Windows, the other with UserName client credential type).
I was wondering if there's a way of having just one endpoint with a custom binding that would magically allow the mixed authentication (either Windows or UserName)?
Also, why is it a bad idea?
Thanks!
I am using VSTS 2008 + C# + .Net 3.5 + IIS 7.0 + ASP.Net. I have two IIS web site, site A and site B. When user request url http://sitea/abc.aspx, my ASP.Net code handler will authenticate user (using Forms authentication), and if authenticaiton passed, I will redirect user to http://siteb/bcd.aspx.
My current issue is, some users will access http://siteb/bcd.aspx directly to skip the authentication process of sitea. This is not what I want since I want to ensure all users who access http://siteb/bcd.aspx authenticated.
My question is, what is the easy solution to solve the issue when user will access siteb directly to skip authentication?
My thoughts on this...
Disallow anonymous access to both the site
Since you are using forms authentication set the loginurl appropriately.
If a user access http://sitseb/bcd.aspx directly, since anonymous access is disallowed it will be redirected to the respective login URL.
Do let me know if you need any further clarification.
A similar solution is presented here..
Multiple site authentication with asp.net
NOTE: IF need be, the forms authentication cookie domain should be set to "*.yourdomain.com" so that the same cookie can be used for both the site.
On siteb you can restrict access to the ip address of sitea.
In IIS Manager
Click the Directory Security or File Security tab, and then do one of the following:
in the IP address and domain name restrictions section, click Edit.
Click Granted access or Denied access. When you select Denied access, you deny access to all computers and domains, except to those that you specifically grant access. When you select Granted access, you grant access to all computers and domains, except to those that you specifically deny access.
Click Add, and then click Single computer.
Click DNS Lookup to search for computers or domains by name, rather than by IP address.
Type the DNS name for the computer. IIS searches on the current domain for the computer, and if found, enters its IP address in the IP address box.
Right now we have AD/Exchange to manage all of our users logins/e-mail on-site at the office. The major app that everyone uses maintains its own login accounts and all users have a tendency to forget login information for at least one of the two logins.
What I'm considering doing is using AD to authenticate the user in the application so that they don't even have to login to the app after they've logged into their machine.
The problem is that there are small number of users that work off-site (the app can work over the internet) and just use the machine's local account (which is causing problems of its own).
What I'm wondering is, will using AD to authenticate users on-site still be an option if a user works off-site?
The answer to almost any question posed to a programmer is "Yes..." It's what comes after the ellipses that is important. You may not want to do the things that come after the ellipses.
Based on the information in your question I think the answer is "No" but there are several scenarios where we could change that to a "yes".
If the AD account is only being used to authenticate that a user knows the password, then you could make a web service, host it in your domain, set it up to use windows authentication and SSL, modify the application to prompt the user for credentials, and call a method in the web service using those credentials. In that scenario, a successful call to the web service means that the user is authenticated. You could use the user's credentials to continue from there.
Detecting weather the application needs to prompt the user for credentials or not could be done by attempting to call the web service with the user's logged in credentials first. If this call fails then you know you need to prompt the user.
Not knowing the rest of the details of your application however means that there are many scenarios where this would not be enough.
I have done something very similar to what I described above. My scenario was the reverse: the application worked over the internet but I wanted it to be easier to log in in the cases where the machine has domain membership.
As an aside, the members who work from home: are they using laptops that are part of the domain or are they using machines that are not connected? In this case you may be able to use cached credentials but you should ask that question over at ServerFault.
Yes, you can definitely do that. It'll be a bit of work though.
What your app would have to do is either find out automagically whether it's directly connected to the office LAN, or working away from the office. Or you could have the user tell you, of course :-)
If it's on the LAN, no problem - you authenticate against AD.
If it's away from the office, you could e.g. call a WCF service on the company LAN, pass your Windows credentials, and have it authenticate you against the company AD. If you provide the right set of credentials, you'll be authenticated and allowed to work - if you're not allowed to log in, the call to the WCF service would fail.
You could do this almost automatically by using Windows credentials - in which case the "remote" user would still have to log on to your domain and use his / her normal Windows credentials; or you can pass username/password over the wire to WCF, or even install a certificate on the remote user's machine that WCF will then map to an AD account on the server side.
The options are plentiful! :-)
Marc