I am writing a web application that works with exchange, and so needs to impersonate an account that has admin rihgts to Exchange. This account is specified by the user on setup. What is the best way to get impersonation to use this account, obviously hard-coding this into the web.config won't work as it needs to be able to change, but I'm not sure of the best way to do it.
Also, I actually only need to run as this administrative user for 1 class, is it possible to only impersonate for some methods?
I posted an answer on using impersonation to access a network file share, but it should work for you as well. It includes source for a c# class that can be used to manage the begin/end of impersonation and can be used by any class or method.
The source provided does assume that you are storing the username and password in the web.config.
See the original question and answer for more details.
The way I've done this in the past is to use LogonUser. The links below provide some guidance on how to go about this.
http://blogs.msdn.com/shawnfa/archive/2005/03/21/400088.aspx
http://www.guidanceshare.com/wiki/ASP.NET_2.0_Security_Guidelines_-_Impersonation/Delegation
You might also want to consider whether you can use Exchange impersonation and have your application run under a fixed identity that can impersonate in Exchange via Exchange Web Services.
You could do it as above, but in this scenario what's wrong with just modifying the web.config during your setup process?
In addition to LogonUser as others have noted, or the WindowsImpersonationContext class, you might also consider separating out the privileged code. For instance, running as an Enterprise Services object (running under COM+). This would allow you to have the OS manage the credentials, PLUS you have a builtin trust boundary around the privileged code.
Of course you would need to implement limits on who can call this object, but that's easily configurable...
Related
I have authenticated using Siteminder & I have obtained accessToken.
Now there is another application that comes under the scope of same application.
I want to use Alfresco there without any need of further sign-up. Basically I want to implement single sign on.
I don't know Siteminder, but sso is possible in alfresco.
You'll have to look at how the authentication subsystem work. You'll find the configuration under alfresco.war\WEB-INF\classes\alfresco\subsystems\Authentication\ you can redefine them under /shared/classes/alfresco/extension/subsystems/Authentication/
Things exist for:
alfrescoNtlm (alfresco's own mechanism)
kerberos
ldap
ldap-ad
passtrhu
external <- this on is a good candidate for you
With external you can tell aflresco to trust what comes from an url. You'll find information here http://docs.alfresco.com/5.0/concepts/auth-external-intro.html or there http://smasue.github.io/alfresco-external-sso
I hope this helps
So here's the scenario i'm trying to find a solution for.
my company currently has a records system for it's staff, but it is not linked to active directory. we have duplicate, and often inaccurate data because of this. what i'm trying to do allow the records system to update values in active directory, however i want to scope what can be changed and by who. so
when we have a new hire, IT will enter in the initial record, which would also create the AD user.
hr comes along and updates title/description/phone/address etc., but they shouldn't be able to create or delete a record from the system. (they'll have to file a ticket, or something)
i've been trying to read about the kerberos double-hop problem, and it seems i need the ability to delegate, however, my own IT powers aren't high enough. i could escalate and try and get sign off from the higher level IT folks to grant delegation to an account, but i'm saving that as a last resort.
I would like to accomplish things using impersonation, but i'm having a hard time finding a clear answer on how to implement impersonation.
i have enabled impersonation in web.config, and in iis. i have set the appPool Identity to network service. after that, i'm lost on what to do next or how to test settings.
edit 1:
i'm also following this pattern for impersonation
var iid = HttpContext.Current.User.Identity;
WindowsIdentity wi = (WindowsIdentity)iid;
WindowsImpersonationContext wic = wi.Impersonate();
try
{
// do something with a directory entry here
}
catch
{}
finally
{
wic.Undo();
}
Make sure your web server has delegation enabled in AD. That's the step I always forget about anyway.
Couple reference links:
http://blog.reveille.org.uk/2010/01/asp-net-impersonation-delegation/
http://support.microsoft.com/kb/810572?wa=wsignin1.0
Also make sure you're using windows auth for the website.
You'll be able to tell real quick if its working as only users with proper AD access will be able to manipulate the AD settings (because it will literally be just like they're making the AD change themselves).
Delegation is a stronger form of impersonation. Impersonation lets you act as the user on the local computer, delegation allows you to act as the user on remote computers. The only way to avoid delegation is to delegate control in AD to the web service (in this case you're running as the network service, so give the web server's computer account the ability to write to the desired attributes), and have the web service perform the updates. This is not a good idea though, since you can't attribute the changes to the user who was using the website.
We are receiving an application from a third party that will eventually be installed in our production environment.
As part of the setup, they want us to make Machine\ASPNET an Administrator account.
This seems to me like bad practice, but I need specific reasons if I am going to push back on this.
What are the implications of running Machine\ASPNET as an administrator?
Additional details:
This will be deployed under IIS6 on Windows Server 2003
This is a three tier application. I believe they want the Machine\ASPNET user as administrator on the middle tier, where the WCF services will be deployed.
As you've guessed, making the ASPNET account a member of the Administrators group is a really, really bad idea.
This is because a successful exploit against your third party app (or against any other web app running as ASPNET) would gain administrative access to the machine. This is the principal reason why web app accounts are generally low-privileged.
Instead of granting ASPNET admin rights, you could request from your third party what specific rights they require. You could then grant ASPNET just those rights. This would limit what a succesful exploit could accomplish.
For example, if the app needs read/write access to the registry under HKLM, you could grant ASPNET access to it. Thus an exploit could clobber the registry, but not the file system.
If a vendor is giving this advice you’ll normally find they’ve put doing the job properly in the “too hard basket”. Most likely they’re struck permissions issues and just recommended granting the broadest possible access rights to solve the problem rather than applying the proper due diligence and investigating the route cause.
As others have said, go back and pressure them for more details. There’s a very good reason the ASPNET account operates with limited rights; the onus is on the vendor to properly explain why good security practice should be compromised to run their product.
I would agree this is a very bad idea, if for some reason there was a security breach on the site an attacker could pretty much do what they want with the server.
You need to find out why the user needs to be an admin, get an exactly list of actions that the user needs to perform and just give permission for these tasks. If they can't give you a proper list then just reject it, it shows that they don't know their application very well and that should enough of a worry.
Here's the flow I'm looking for for authentication:
Attempt to pull in the user's name from windows authentication
If that failed (user is external to network), use BASIC authentication to get the username/password.
Check the username/password against the SQL database. If windows, password isn't required, if BASIC authentication and password is incorrect, prompt again
Create the Identity object with the user name, and populate the user's roles via another SQL database call
This would need to be used for multiple applications.
What would be the best method of implementing this? Creating a HTTPModule? If so, what do I need to keep in mind (security, virtual directory setup, etc)
This type of authentication is called Mixed Mode authentication (some google searches on this will get you alot of hits). We have a flavor of this running on a site I work on, however there are some quirks to our setup that have to do with odd business requirements.
Here is an article that might get you going on the subject:
http://www.15seconds.com/Issue/050203.htm
It is a big topic to give a huge detailed explanation of how you could set it up in one post.
Good luck!
We have several ASP.NET applications deployed to a few servers. Is there a standard way to reuse session data or some other method to not require users to log in to the next application when moving from application to application if they've already authenticated? I'm hoping there's a best practices way of doing this that you guys know about. I feel like there should be something easy that I'm missing.
Thanks.
Edit: To be be more clear, the main info in the session that I'd like to pass is the authenticated userid, but possibly some other session variables as well.
you could implement a single-signon strategy for your applications.
http://aspalliance.com/1545_Understanding_Single_SignOn_in_ASPNET_20.all
http://blah.winsmarts.com/2006/05/19/aspnet-20-implementing-single-sign-on-sso-with-membership-api.aspx
http://johndyer.name/post/2005/12/Single-SignOn-with-ASPNET-Membership-and-WebServices.aspx
http://msdn.microsoft.com/en-us/library/ms972971.aspx
Single Sign On (SSO)
http://msdn.microsoft.com/en-us/library/ms972971.aspx
For the session check this: http://www.codeproject.com/KB/aspnet/Sharing_session_state.aspx
Complement with this so the cookie is shared: http://mgrzyb.blogspot.com/2007/12/aspnet-and-subdomains.html
It's not clear from you question if you're just concerned about logons, or if you really need to share session data between applications.
Assuming the latter, you could try something like this:
first, make sure all the appliations are running in the same domain. If not, all bets are off. I don't know if there's a simple way to configure the domain property of the session cookie yet, so you may have to do it yourself, by setting the cookie domain property to the domain:
Response.Cookies["ASP.NET_SessionId"].Domain = ".mydomain.com";
you'll need to make sure that each application is configured to use either a common state server, or a db-backed session.
Sharing a sign-on between applications (covered above) is quite a different ball game to sharing ASP.NET Sessions between applications.
Why do you want to share Sessions between applications?
ASP.NET Session is a metaphor for a user's current interaction with one ASP.NET application. It exists in ASP.NET to give us a place to store temporary state data between the various page requests that a user makes while using your application.
If your applications are very closely related, e.g. the user uses both at the same time, or almost the same time, you could consider merging them into a single ASP.NET application.
If your applications are not that closely related, perhaps they should be sharing the same database as a means to exchange data, or using an API e.g. based on Web Services to exchange information.
Hope that helps.