The principle of least privilege means only granting a user, process or program the minimum level of access it requires to perform its task. Least privilege is considered a best practice, and when it comes to Exchange Server the same principle applies.
In the early 2000’s I worked in a tier 2 support team. One day while assisting some tier 1 staff with a task I watched them run a batch file as one of the steps in their process. When I asked what that batch file was doing, they told me it fired off commands to force replicate between all of the Active Directory sites in the environment, so that their change (whether that be a new user account or a change to an existing account) would replicate faster. When the Active Directory sites were designed, careful consideration was given to the site links and replication intervals taking into account the bandwidth available to some of the remote sites. And here was the help desk, running this batch file as often as every few minutes. And if they had the rights to do that, what else could they do that might be even more harmful?
Fast forward to a few years ago, and I recall a case where suddenly every email sent by a user in the company was being rejected. The culprit was a misconfigured transport rule (and a lack of change control, which is a different matter). But again, the question needed to be asked, if they had the rights to do that, what else could they do that might be even more harmful?
Despite the principle of least privilege being well known, and merrily enforced on people such as external contractors, when it comes to internal IT staff far too many organizations these days ignore it. Just about anyone is granted Domain Admins and Organization Management rights, with perhaps a few important superuser passwords kept semi-secret.
A large part of the problem is the challenge of retrofitting least privilege to an IT organization that is already in motion. Few people willingly give up administrative privileges once they have them, and many of them will be used to being able to freely perform tasks themselves without having to seek out someone else who has the required permissions.
All is not lost. I have seen least privilege successfully applied to IT organizations that previously ran wild with powerful admin rights handed out like candy on Halloween. Not everyone was happy about it, but who cares as long as the right people are on board with the idea. The key to success was not immediately ripping access away from everyone. Instead, a slow process of analysing roles and responsibilities, and then incrementally removing privileges, was used to eventually roll out least privilege to each of the teams.
During the transition there was extra effort made to assist anyone who was trying to do a task they *should* be able to do, but could not because their admin rights had been restricted too much. That last point is important, because nothing will sink this effort quicker than any perception that support can’t be provided to meet SLAs due to lack of admin rights.
A few general rules were developed to assist with the adoption and smooth out ruffled feathers:
- Your day to day user account must have zero administrative rights
- Your general admin account should have rights to perform any task that is your team’s responsibility within the agreed SLA
- Where possible, your general admin account should not have rights to perform any task that requires change approval
In effect this meant that I, as an Exchange admin, had a regular user account just like everyone else. I also had a day to day administration account that let me do recipient admin, message tracking, and view everything in the org. I then had a powerful admin account that was used for approved changes such as modifying a virtual directory or adding a new database. Finally, I had an account with Enterprise Admins and Schema Admins membership for the infrequent situations where a schema update was required.
So where do you start? Looking specifically at Exchange, you should review your RBAC role group membership to see where you stand on Exchange admin rights today. In fact, you can use my PowerShell script to do just that. Once you know how messy things are, you can seek buy in from an appropriate stakeholder in your IT organization (a manager who takes security and risk seriously would be a good candidate) and begin planning the transition.
