I have a c# class which uses the WindowsIdentity namespace to return details of the current Active Directory user. This is accessible through a web part on SPS and sure enough returns the desired record values specific to that user.
I have a classic ASP application which I would like to have inherit this functionality. After wrapping it up as a COM and registering it to the server, I created a Classic ASP page from which to call and display the details to the browser window.
My problem is that when this page is accessed from an authenticated user on a client machine the only user details it displays is that of the local machine.
How do I therefore alter my code so I can display the details of the user accessing the page from a client machine?
Classic ASP takes us back. :-)
Don't think I've touched it since 2002...
Anything wrong with just looking at Request.ServerVariables("logon_user") in the ASP page?
That should give you the domain\username.
Rather than trying to run the COM-wrapped class under the identity of the end-user (which is the problem you're having), you could just pass the domain\username through to a class to retrieve the account details from AD and then display any needed items from there. That would do away with the need of impersonating to obtain the windows-identity of the current user.
Also check to see what authentication methods the site is running as in IIS.
Right click the website in IIS Manager, Properties --> Directory Security --> Authentication and access control --> Edit...
Make sure Integrated Windows authentication is checked, Enable anonymous access is cleared.
Related
I have a Silverlight application and in web project i have a login.aspx; which authenticates an user and allows silverlight page to be opened. My problem is i need to disallow a user to copy the direct silverlight url and paste it. The user should follow the sequence all the time i.e Login then SL page.
How to prevent this behaviour.
The basic idea is that each access to the page should check the provided log in details. If the user hasn't logged in, then there will be no log in details and so they will not gain access to the page.
There are several ways to achieve this. You could even implement your own custom authentication system without too much trouble - it just involves checking log in details before displaying any relevant pages. Alternatively, you can read more about the .NET authentication services in the Walkthrough: Using Authentication Service with Silverlight Business Application page on MSDN.
I'm developing a MVC application that will require a user to be authenticated against an AD. how to create log in page in MVC to create an Intranet Application that automatically authenticates a user against an AD
Why don't you use the Intranet Template provided by Microsoft Visual Studio, which does exactly what you want out of the box?
Your requirement is paradox. Why do you want a login page, which does login a user automatically, while being logged in by visiting the (main-)site automatically, does not require the visitor to do anything at all, because he is already authenticated by entering his credentials at the windows-logon
More information: http://msdn.microsoft.com/en-us/library/gg703322(v=vs.98).aspx
you can use the built in windows authentication feature. the example is in here
if you need mixed authenticated for example you want the user can access from outside using their AD it will involve either two applications or two different pages for authentication types. find the example here
I'm not entirely sure if you actually want a login page that automatically authenticates a user that visits the main site. Maybe your wording is a bit confusing there.
I'll asumme you want your Web-App to be able to authenticate users against AD after having to log in with intranet credentials. If that's the case, you might want to have a look at this article detailing how to set that up using IIS and an ASP.NET app.
If not, please disregard this answer.
I have a deployed application that is using the Active Directory Membership Provider in order to authenticate users to our domain on an extranet. The application is using the .NET 3.5 framework. If you run the application locally it goes straight to the login page. But if you run the application from its deployed location on the server it first prompts with a Windows Security login prompt and after logging in, you are taken to the login page where you must login again. Why is this?
Your web application seems to be configured to use Active Directory Authentication (and doesn't allow anonymous access). Your users internally are already logged on to the domain and so IIS simply lets them past.
Your login.aspx page is protected by IIS so that you must be a member of the domain in order to even see the login.aspx page. This is a configuration issue in IIS and has very little to do with asp.net or C#.
If you are using forms authentication, you should be able to allow anonymous authentication in IIS and handle authentication using Forms only. However, this entirely depends on the web app and enabling anonymous access may inadvertently expose information you didn't intend to be publicly accessible.
Without knowing more about your application it's difficult to offer any more advice. Good luck.
I have a few websites which allow both anonymous and window auth users at the same time. Basically if you hit the site with IE or Webkit based browsers on a windows system, the server instantly recognizes your active directory user and group.
In the past I've provided a link to a windows auth only page which allows the current user to login, or bounce back to where they started.
I find the management of this kind of frustrating as I need to make certain that IIS has the correct security settings for that single page after every deployment.
Is there a better way for me to allow a user to elevate from anon to authenticated?
There is no other way to do that elevation automatically. The server can't know that the current user is a Windows user and elevate them, or automatically redirect them to the Windows auth only page. On the other hand, if every user will get through the Windows auth only page, all of them which are not inside the domain will see the challenge/response dialog box (user + password).
As for the management part of making sure that this special page has the correct security settings, you can (and should) automate the check somehow. For example, by querying the IIS metabase for that setting when the application starts (in Global.asax) and if the setting is not there, log it as an email message or so.
Personally I prefer a different attitude - a special "integration/deployment" page which contains a series of tests against my application so I can make sure everything's set up correctly on the server, i.e. NTFS write permissions to certain folders, availability of the SMTP server set in web.config to send emails through, etc.
Note: You're using Windows authentication along with anonymous access. Just keep in mind that if you consider implementing Forms Authentication in the future, a misarchitecture (I don't know if by design or due to a flaw) of IIS 7 does not allow you to set the app to be Forms Authentication and set one specific page to be Windows Authentication. The override just doesn't work and it's very frustrating.
Good luck!
OK, I figured out a fairly nice way to do this...however it's not as elegant as I had hoped since it doesn't work across applications.
Basically, if you create a single page within your Anon + Integrated Auth IIS6 website or virtual directory, let's call it auth.aspx, then you can use this page to prompt authentication.
Go into IIS settings and specify that auth.aspx is Integrated Auth ONLY (no anon). Then create a hidden iframe somewhere on your page. I then created a simple JavaScript action to update the src attribute of the iframe to the auth.aspx page. This forces the browser to try and authenticate using NTLM. Once you enter valid credentials you've successfully elevated your current user beyond the generic anonymous user.
One final touch was to then include a Response.Redirect into the auth.aspx which reloads the current page. Assuming your ASP.net session tokens are set correctly, the page will reload and the user will be authenticated.
I have a simple silverlight application hosted on a corporate network. However I want to allow access to this website to few select NT users and restrict the rest. How do I configure it?
Also would such a configuration work for out of browser as well?
you should enable the Integrated windows authentication in the IIS web site or virtual directory configuration. After that in any moment you can take the User.Identity and User.Principal objects and cast them to WindowsIdentity and WindowsPrincipal and check if current user is in a certain role ( aka in a windows group ) or his/her username...
about out of the box I don't know because I have never tried it but you could surely test it once you have a label showing current user name in your SL User Interface, checking if the functionality is the same in the browser or out of browser. Hope this helps...
There are several things you can do.
1) Restrict access to the web services this is calling into - Davide's answer covers this nicely.
2) Restrict access to thw website where the SL app exists, which is easy to do with ASP.NET and the built-in support for Windows Authentication via a MembershipProvider. This way, a user can't even load the HTML page hosting the Silverlight app if they're not in the right role. This would also prevent them from installing the app as Out of Browser, as they can never get to it in the first place.
3) In the OOB mode of the app (when Application.Current.IsRunningOutOfBrowser is true), at startup call into a web service that verifies the user is in the right role - if they're not, the app could simply diplay a "not authorized" visual and not show the real app functionality.
This way, if the user ever was in the role and installed the app OOB, but then lost that permission, they'd still not be able to use the app.
As to implementation of all this, I suggest looking at WCF RIA Services. It has great authentication/authorization support that should simplify implementing this, even if you don't want to use RIA Services for data access for whatever reason (though I recommend that as well, it helps hide a lot of the async complexity of Silverlight data access).