Development Tasks

Sep 16, 2009 at 11:36 AM

Hi guys, I've been having some thoughts on how we can break this project down into chunks, and prioritise these so we can get started. Essentially I felt the service split into the following areas:

  • Provisioning Engine - the backend that will queue up jobs and execute them. This needs to handle all the provisioning tasks and be as efficient as possible. This could use the HMC provisioning engine or powershell directly. I believe the HMC service uses PowerShell eventually anyway, so if we can build an effective provisioning engine then we can ignore HMC altogether. My research lead me to think that writing this in WCF is prob the best way to go and running it as a windows service.
  • Client Backend - The Backend processes that respond to client input and build the request to send to the provisioning engine, will also save data to a DB if required
  • Client frontend - The GUI (
  • Database - We need to decide whether we will be using a DB to store data, or we will attempt to just use Active Directory and Exchange for all data storage

So, any thoughts on this, on the best ways to get started etc, I’m interested to hear your opinions!


Sep 24, 2009 at 6:41 PM

From my research as well HMC does not make lots of sense from a performance perspective. It is just another layer to work through. I do have to admit that I am not much of a programmer myself and I have a guy working for me doing that. I just have an idea of what I want the end product to be. The guy I have working for me has started to pickup Visual Studio 2008 Express Edition and right some basic things in C# to get the hang of things.

I don't know what you already have but what I have been going through on my end has been trying to figure out the various components of a web based admin tool. We came up with the following:

  • Authentication into the system. Who am I?
  • Where do I login? My personal account, a specific OU. This describes the Scope. It could also describe your filter set of DL/Groups, Contacts, Mailbox/AD User Accounts.
  • What am I doing? Broken up in to 4 major tasks:
    • Create account
    • View Accounts
    • Maintain account
    • Decommission (disable) account/mailbox

 The provisioning engine as you term I think would be best provided by PowerShell as I already said. Various common functions should be created as web services which can then just have a few parameters passed to it to perform the action.

The client backend I guess is where you could put in any business logic that you require.

You bring up the question of a DB. In some ways I would like to keep most of the data in LDAP as it is a good directory and quite speedy with responses. But my concern is on the frontend presentation of the information. If you have a domain with 1000 Mailboxes and want to sort by OU and then by mailbox size you need to cache that data so that it is not constantly transmitted from the server to the client.

You have mentioned that you have some basic code already that you have been working on. Did you want to upload that at least so I can get a basic idea of what we have to start with?

Sep 25, 2009 at 7:52 AM

As far as code goes, i've not got to much on this project, i've not really starting coding for it,  however this project stems from an application I wrote for my university dissertation, which was a control panel for Exchange, designed for small bussiness. It works, however its not really suitible for Hosting, mainly due to the fact that if you have multiple people using it at the same time then the powershell interactions become a bottleneck, therfore one of the major aims for this project is to build an effecient system to run the powershell commands.Anyway, i'm happy to put up the code that I created for my disseration, and put up a demo site so you can see it running, but please bear in mind this code was written for university, as a learning experience, so its not all pretty and some if it is probabley not the best way to do things, but it works.


Oct 15, 2009 at 4:46 PM

I've looked at the code from your project and it has been very good for learning. However, one problem I found was with authentication and trying to get impersonation to work instead of running the whole site as a privileged user. A simple way to solve the problems I had was to use basic authentication and disable integrated windows authentication, but that is not exactly a good way to authenticate and it doesn't fit with the forms authentication you used for your project. I might have found one possible impersonation solution that could work in conjunction with forms based authentication, but unfortunately I have run into hard to solve (if it's at all possible) problems there as well.

One big advantage of using impersonation is that we then allow powershell to decide who has the privileges to do what, so we don't have to worry that much about security holes in our authentication scheme. Do you have any thoughts on this Sam?

Oct 15, 2009 at 5:14 PM

Yeah, impersonation was one of the big problems I had at the time, because when I started work on the project, you could not use impersonation with the Exchange Management Shell, so you had to run it as a privilaged user all the time, not great. I had to get this original project done in time for the deadline, so that had to do for then.

The problem with using any sort of impersonation based on who is logged in to the system, is that most users do not (and should not) have the rights to create new mailboxes etc. What we really need to do is be able to specify an administrative user that can create mailboxes, that PowerShell can impersonate, only when it needs to and only from the back-end application, that way the Web applicaiton itself never has to interact as a privilaged users.

Supposedly it is now possible to do Impersonation with PowerShell and Exchange, so we may need to look into this and see if it is do-able, otherwise we are looking at having to run the back-end process as a privilaged user at all times. Because the back-end that will talk to Exchange is going to be separated from the Web application we do get some extra level of security if we do that, but its not ideal. I would really like to work a way to do impersonation properly.

Oct 21, 2009 at 2:53 PM

It seems I have found a solution to the impersonation problem! I've managed to integrate impersonation into your university project using the LogonUser API, and it only impersonates when it is actually necessary to have privileged rights (mostly calls to DirectorySearcher.FindOne() and Pipeline.Invoke()). It uses the username and password that was used to log in, which means there is no way to do anything without providing valid information.

I don't agree with you that specifying an administrative user is sufficient. For our organisation I'm pretty sure we will need more fine-grained control over what OUs certain administrators have read or write access to. By impersonating the user AD will take care of the security bit and we only have to worry about showing the available options in the GUI. The reason why we need more control is that we have administrators in different countries who should only be able to modify the users of their own field or country.

One thing I noticed is that logging on takes forever! I get a 50 second login time compared to your estimated 20, which might have to do with calling the LogonUser API. On a second thought, I realise I've been so blinded by the goal to make your code work that I'm actually validating the user twice! I found that the ASP.NET user didn't have sufficient rights to query AD, so I had to get a login token with LogonUser (requiring correct user credentials) which is used for impersonation so that your code can then see if the username and password is correct! The time could probably be cut down a lot by querying AD less.

Oct 21, 2009 at 3:15 PM

That is good news, good work.

I think I need to explain what I meant by the administrative user thing. My thoughts at the time (and this may very well have not been the best idea) was to limit who actually had the permissions in Exchange to create mailboxes etc, so I had the app setup to use the administrative user to actually run the powershell commands, as this had Exchange administrator rights.  The application itself uses Active Directory groups to determine what rights the user has, and which parts of the GUI to display.

For example a department manager has the rights to create mailboxes for their department. He is in the managers group in AD, so the app only shows him the list of users for his department not all users and only allows him to create users in his department. When he actually goes to create a mailbox, the command is run as the administrative user, in exchange, this is where I wanted to impersonate the admin user.

Your method of using the actual logged on users rights means you can do away with my method of having AD groups to determine exchange rights, as you would just use there account to create a mailbox, if they don't have the right they can't do it. This does mean though that you have to make each user you want to create mailboxes and Exchange admin, which means using the Exchange console, my way meant that you could allow a user to create a mailbox from the app. It de-couples the permissions you have to do things in the application, from Exchange permissions.


I'm not sure which is the best option, I don't think I want to be giving all users Exchange admin rights, if they need to create mailboxes. I think I would rather have what the user is able to do, determined by what they are shown in the application.

Oct 21, 2009 at 3:46 PM

All right, then I understand the user control a bit more. The way the administration is done right now in our organisation is using the Exchange console remotely, so in our case I think that the Exchange rights are set up with users as admins already. I've just started learning about AD though, so I don't know what the best way to do it is. When he comes back I think Leon can say what is the most sensible and secure way of doing it, he is the administrator and has lots of experience, I'm just a programmer.

Oct 22, 2009 at 3:55 PM

Leon agrees with me that impersonating the user is better as security is key, and it leaves no way to hack AD if there are security holes in our app. It might be easier with group based permissions, but I really like the idea of taking away some of the pressure of creating an absolutely secure app and rely on AD.

Wouldn't it be possible to make users admins from PowerShell? If so, it could still be possible to manage user rights within the app itself.

One thing with changing the permissions system though, is having to change almost the whole of your expanel to be able to use it. On the other hand we probably shouldn't use that as a base anyway... I'll see what I can come up with to move forward, having gotten forms based authentication working with impersonaiton I'm not sure what the next step should be.

Oct 22, 2009 at 4:27 PM

Ok, I guess both options have merit. The thing that concerns me is of using the user security based approach are:

1. This means we have to manually give users the appropriate Exchange permissions when we wish to allow them to create/edit/delete accounts. This may defeat teh point of the control panel, you may have users who wish to delegate control of specific users/departments to a user, they don't have access to the Exchange console, so they will have to request that the server admin does it, so reducing the functionality of the control panel
2. If we wish to display different parts of the application to a user based on there permisisons, it involves a call to Exchange to check whether they are Exchange admins, this will be slower than just calling AD for group membership
3. How do we determine who these users have the right to manage, they will have exchange admin rights, so in theory they can manage any mailbox on the server, but in reality they should only be allowed manage a single ou/department
4. If an account is compromised, the user can still cause problems, they are an Exchange admin, if the app is not secure enough they could run rouge commands against exchange (not that this solved by using a single admin account)

It may be that we could use a combination of these approaches, user based security, with the users access rights stored in SQL, so not needing to query exchange to see what area of the app they require access to. It would be good if users can be promoted to an admin level from inside the applicaiton, rather than needing to use the exchange console, not sure how we would do that.


Nov 3, 2009 at 4:39 PM
  1. Take a look at the split permissions model that MS documents from here: That is how we delegate the appropriate permissions to do Exchange administration but only in the OU in which they should be making those changes.

    A prerequisite during the install of ECP should be that you are a member of the "Exchange Organization Administrators" group and a member of the Domain Admins group. You can incorporate the script provided by MS and add a bit more ACL's to give full control of the appropriate OU or Domain for a group in each OU or Domain. That should sort the issue of being able to continue to do all admin from ECP.
  2. Not necessarily. You have 3 views in the website. The admin view is not really needed for much if you are using the split permissions model for security delegation. You can delegate all permissions from the manager view. Then the admin view is only there for configuring the website. The manager view should be able to do all the user/group admin. The third view would be a self service view for each user.
  3. We should have a standard error checking to say that sorry they don't have the rights to make those changes and to contact a full system administrator. If you have delegate permissoins so that they have the permissions to make changes for the entire domain then they won't have that problem at all. I would anticipate that most small companies would not require delegated permissions to the OU level so they would not use that.
  4. No, they are not Exchange admins if you are not using the split permissions. In our organization we have about 50 Exchange user admins who are not Exchange Organization Admins. If their account is compromised I can safely and easily disable their account and nothing bad would occur.

The issue I would have with not using impersonation is you still have to figure out if a person has the rights to make changes in a particular OU. You just are setting up your own security model to enforce this security. You then don't have a very good audit log if all the changes are made by a single service account.

You could still have a role group like you currently are using for who can see which administrative view on the web page. That role group is queried and based upon your membership you have the option to see different views into the ECP. So you still keep much of the model you originally proposed.