Impersonation in DotNetNuke Intranets By Ian Sampson on September 21st, 2009
This now means that when Joe Bloggs opens up our web page, DotNetNuke will run under the identity of Joe Bloggs. And because he is a network user, he can access Active Directory and so everything will work just fine - or so we think! Alternatively, we could add to the web.config <identity impersonate="true" username="svcUserName" password="P@ssw0rd" />
and actually specify the identity of the user that our DNN should run under instead of the user visiting the site. Rather than using an existing user account, for which the password may change or the user could leave the company (and then the site will simply stop working), we should go and ask the AD admins for a "service account". These are a system type of user account for which passwords can NEVER be changed and which generally have a very low level of access inside of the network (proxy servers, firewalls and AD read permissions) so can't do much damage.
We ( Glanton ) specialise in implementing DotNetNuke ("DNN") as an intranet application for large enterprises and vouch for the fact that it's a very different animal from setting up your standard internet facing DNN site for clients. I was surprised at the complexities introduced when impersonation is enabled on a DotNetNuke site and hopefully our experiences and thoughts below will help others. I've tried to keep this as simple and non-technical as possible. When working inside large enterprises, you are not working on your infrastructure; you have very little control and you don't get admin rights to machines to set up as you like. Furthermore you have to adhere to a bewildering array of branding, security, legal, infrastructure, change control, project management and technical standards - which are often quoted but seldom found! And, of course, you are running across a network - and that means that everything which DotNetNuke does has to be set against the backdrop of the identity in which it runs within that network. If you are running DotNetNuke as a simple, low level 'brochureware' site using DNN authentication, it's simple. DNN will run quite happily in the context of the ASP.NET worker process doing what it needs to do inside its own server walls and never having to venture out into the big bad network. However, what if we need to implement Active Directory authentication so users can manage DNN using their own familiar network accounts? Now the ASP.NET server account has to go and ask the Active Directory server ("AD") if Joe Bloggs is in AD (identification); if he is indeed Joe Blogs (authentication); what his phone number and email address are (profile management) and what groups he belongs to (role management). Because the ASP.NET account is local and specific to only the server that DNN is installed on, we have to get someone else - that AD knows and trusts - to ask for us. We have to enable impersonation. Enabling Impersonation Impersonation is enabled two ways: 1) By adding to the web.config file, the section <identity impersonate="true" />
Most Enterprise service desks will prohibit you from adding the service account password in clear text inside of a web.config so you'll have to either encrypt the password or get the service account password added to the server registry and retrieve it through code. This is to stop site users (not network admins) who may have root access to the site, from reading the service account details. 2) By code A method I prefer is that, if our module needs to go out to other servers on the network, we add a routine to our code that impersonates a service account within the context of that code or module function only. This means we are not locked to the identity of the user set in the web.config. Generally I look up the proxy username and password that is stored under host settings, but the Active Directory authentication provider does it by storing this information in the module settings table and encrypting the password in the database. The reality is that most DotNetNuke installations will set because of the extra effort of encrypting and retrieving passwords (or blatantly exposing service account passwords in clear text). Microsoft's MSDN library has lots of technical information on how to use impersonation and delegation in ASP.NET 2.0 . Implications of Impersonation OK great - we've done what the manual says and we've got impersonation working. Job done? Actually no - now the fun starts when you start getting calls from users saying the file manager is broken, RSS feeds don't work and performance has gone up the pole. Ooops! File Access For simplicity sake, assume we set impersonation=true but have not specified a user account so that that DotNetNuke assumes the identity of the visiting user - Joe Bloggs. If we impersonate Joe Bloggs and he tries to upload a file (or even read the folder contents) through the file manager, it will fail. This is because Joe Bloggs does not have specific read/write/delete file permissions on our web server. Firstly, who are we going to give permissions to? We certainly don't want to give the generic groups "All Users" or "Everyone" permissions because that means that anyone who did manage to get access to the server could cause havoc. Our best option is to give read/write/delete permissions to the "Authenticated Users" system role. Anyone accessing the
Created using zinepal.com. Go online to create your own zines or read what others have already published.
1
server would have to be network authenticated first and my network admins tell me network users can't map a direct drive to the share because sharing has not been enabled. So I'm feeling a little more comfortable but I'm still a bit twitchy about giving delete permissions for DNN system files. So what do we give "Authenticated Users" access to? In summary, I give authenticated users users read/write/modify access to everything and delete permissions over the contents of the /portals folder. I once fell into a trap where I initially just gave "Authenticated Users" permissions over the portals folder. Because I was the application owner and had been given full access to the share to set things up, I was able to install new modules, read pages (that were cached to file), use modules which write data to bizarre places (like Indogrid which writes to the app_data folder) and so on, and everything worked fine for me. But of course, as soon as it went into production, the phone started to ring with users who had different permissions to me. In one instance, we had to extend permission over the ASP.NET cache folder as well. You also need to consider the implication of changing server permissions if you are working in a three stage DEV/TEST/ Production environment - these server permissions have to be applied to all sites - and some support admins may have a problem with opening up permissions on a production site. Databases We've recently had to move into an enterprise environment where we had to use Integrated Security (i.e. a 'service account') to connect to a database server. For whatever reason, the Site admins could not set up a direct connection to the DB server so we had to use impersonation. This means we had to change the permission sets on the service account. And to make matters more complicated, the DB admin insisted on a separate service account for each of the three DEV/TEST/PROD databases. A mission to manage and coordinate. And then they complain that you can get hosted DNN out on the web for $50 per month!!! RSS If you are trying to access an RSS news feed from another web server on the network you are going to have a problem - even if you have enabled impersonation. The server that you are reading from will have to grant your impersonated user permissions to read its data. If you use a service account, it's easy for them to add. But they may not be so keen to open up Read access to "Authenticated Users" on their server. This is a difficult concept to explain to a user who is used to seamlessly accessing content across their intranet. In Conclusion I try and avoid impersonation like the plague and have written out of the DNN AD provider any calls that rely on impersonation. I stick to specific DirectoryEntry type searches where we can specify the service account and password stored in DNN. As systems integrators, it cuts down our work tremendously by avoiding all red tape associated with requesting service accounts and permission changes on boxes. If you do use impersonation, hopefully I've shared with you some of the issues you may encounter - but not have foreseen. Let me know your experiences?
Created using zinepal.com. Go online to create your own zines or read what others have already published.
2