I had always intended to get this document published publicly, but for one reason or another, it never happened. With KB4490059 being released in response to @_dirkjan‘s #PriveExchange vulnerability, I’ve decided it’s beyond time to just share it here on my blog. KB4490059 is a step in the right direction. You can add these mitigations on top of it for even further protections, or perhaps find a more compelling reason to switch to the Active Directory Split Permissions model.

Removing Exchange’s ability to impact Tier 0 and Tier 1

Exchange is tightly integrated with Active Directory. When Exchange is installed, the Active Directory Schema is extended, and several highly privileged groups are created. These privileged groups are granted rights to a large number of objects within Active Directory.  A compromised Exchange Server can easily lead to complete control of Tier 1, and in many instances Tier 0.

For more information on the Tier model, see “Securing Privileged Access”.

In Exchange 2010 and later, there are two options for mitigating this risk. Both should be evaluated carefully before implementation. It is only necessary to implement one of these two options.

Mitigation Option 1 – Implement the Active Directory Split Permissions Model

Starting with Exchange 2010, there are three Permissions Models available. Of the three, the Active Directory Split Permissions Model, is the only one that can mitigate this risk without additional modifications to Active Directory. Because this model does not allow Exchange to modify security principles (i.e. create/delete/reset password) or group membership (i.e. add members to security groups that may grant access to other systems), compromise of an Exchange Server is contained to the Exchange environment when running under this permissions model.

This permissions model isn’t for everyone. You should carefully consider the impact switching to Active Directory Split Permissions may have on your organization. It may require a significant change in user provisioning, business practices, or workflows that revolve around Exchange. It is also important to note that while this permissions model is fully supported by the Exchange Product Group, it does not receive the same level of testing as the default Shared Permissions model.

If you’ve determined that the Active Directory Split Permissions Model is right for your organization, you can switch to it by running the following setup command:

setup.com /PrepareAD /ActiveDirectorySplitPermissions:true

For more information on configuring split permissions, see “Configure Exchange 2010 for Split Permissions”.

Implementing the Active Directory Split Permissions model both removes Exchange from Tier 0, placing it in Tier 1, and reduces potential impact to Tier 1.

Mitigation Option 2 – Reduce privileges granted to Exchange in Active Directory

If your organization needs to use the default Shared Permissions Model, the RBAC Split Permissions Model, or still has legacy versions of Exchange present, modifications to permissions in Active Directory are required to mitigate this risk.

To remove Exchange’s potential to impact to Tier 0, permissions granted to Exchange’s privileged groups must be removed from the Access Control List (ACL) on the following groups and their members in all domains within the Active Directory Forest Exchange has been installed in, to include any nested groups and members of those nested groups.

• Enterprise Admins
• Domain Admins
• Schema Admin
• BUILTIN\Administrators
• Account Operators
• Backup Operators
• Print Operators
• Server Operators
• Domain Controllers
• Read-only Domain Controllers
• Group Policy Creators Owners
• Cryptographic Operators
• Other Delegated Groups

With the exception of the last 3 entries above, these groups should already be protected by AdminSDHolder, which prevents them from inheriting permissions that would allow Exchange’s privileged groups (Exchange Trusted Subsystem, Exchange Windows Permissions, Organization Management, etc.) to take control of them. Members of these groups should have the same protection. However, since Account Operators, Backup Operators, Print Operators, and Server Operators, can be excluded from AdminSDHolder protection, it is worthwhile to take the extra step of removing Exchange’s permission to all of the above groups (if present).

Because the permissions are inherited, the easiest way to accomplish this, is to place all Tier 0 users and groups into the same OU, block inheritance on that OU, and restrict permissions on the ACL for that OU. Full Control (GenericAll), Write (GenericWrite), Modify Permissions (WriteDacl), Write Member (WriteMember), and Change Password (note that Change Password permissions should NOT be removed from “Everyone” or “SELF”), are the permissions that should be removed from any object that should not have the ability to manipulate Tier 0 OUs/users/groups. In most cases the entire security principal can be removed from the Tier 0 OUs/users/groups.

To remove Exchange’s potential to impact Tier 1, a similar approach to the above must be taken.  Exchange’s permissions on the ACLs of users and groups with privileged access to Tier 1 assets.

Because the permissions are inherited, the easiest way to accomplish this, is to place all Tier 1 privileged users and groups into the same OU, block inheritance on that OU, and restrict permissions on the ACL for that OU. Full Control (GenericAll), Write (GenericWrite), Modify Permissions (WriteDACLl), and Write Member (WriteMember), are the permissions that should be removed from any object that should not have the ability to manipulate Tier 1 privileged users/groups. In most cases the entire security principal can be removed from the ACL on the Tier 1 OUs/users/groups.

For example, Exchange should not have permissions to an account or group that grants privileged access to a SQL server.

Privileged accounts and groups should NOT be mail enabled. Therefore removing Exchange’s permissions from them should have no negative impact on operations.  If an account with, or a group used to grant privileged access to, any system, regardless of what tier it resides in, has been mail enabled, privileges should either by removed, or they should be mail disabled. Either way, it may be necessary to create unprivileged accounts/groups for mail use, or non-mail enabled accounts/groups for privileged access use, in order to avoid disruptions.

This approach is not tested by the Exchange Product Group. Failure to exercise caution when implementing this approach could result in damage to the Exchange environment.

Additional Considerations

Service Packs and Cumulative Updates in Exchange often include Schema updates to Active Directory. Because Schema extensions and Active Directory preparation require Schema Admins and Enterprise Admins privileges, this portion of updating Exchange is a Tier 0 operation. Schema extensions and Active Directory preparation must be performed from a Tier 0 Privileged Access Workstation (PAW).

Schema extension and Active Directory preparation performed during an update to Exchange may overwrite some Exchange related settings in Active Directory. It is recommended that permissions on Tier 0 and Tier 1 set according to the guidance above are validated after every Exchange update install.

Josh Bryant

Cybersecurity Product Leader and internationally recognized Speaker at several Information Security conferences and events with over 26 years of experience as a proven leader in Cybersecurity, Product Management, Threat Hunting, Incident Response, IT Management, IT Architecture, IT Operations, IT Engineering, and Messaging Systems, on a global scale, across a diverse set of industries in both the Public and Private sectors.

192.168.2.21:30040

The post Reducing the Exchange and Active Directory Attack Surface first appeared on Fix The Exchange!.

Obviously this information is stored in Active Directory (AD), and Exchange presents it to Outlook via the Global Address List (GAL), so to accomplish this task, I'd need to update the appropriate field in AD.  My first thought was "This should be easy to do with PowerShell, IF someone has a list of names and mobile phone numbers.".   I was in luck, and received a list with almost 7000 names and mobile phone numbers, for all US Employees.  I did a little formatting in Excel, all names in Column A, all Numbers in the appropriate format in Column B, and saved it as a .csv file.

Of course I wasn't going to get off that easy.  The users were spread across multiple domains within our AD forest.  The Set-QADuser command from the QAD Tools snap-in gave an error saying it couldn't resolve a directory object for the given identity.  The command defaults to the domain the account your running the script from is logged into, so the script was giving me this error for every user that was not in the same domain.   To get around this, I had to add a few lines to the script, and use the Get-QADuser command first, then pipe it into the Set-QADuser command.

Here is the final import-mpn.ps1 script:

With almost 7000 accounts to process, it took quite some time for the script to complete, but it got the job done. 

As always, if you use or repost this script anywhere, please keep the author information at the top in place, and remember to link back to this site, thanks!

Josh Bryant

Cybersecurity Product Leader and internationally recognized Speaker at several Information Security conferences and events with over 26 years of experience as a proven leader in Cybersecurity, Product Management, Threat Hunting, Incident Response, IT Management, IT Architecture, IT Operations, IT Engineering, and Messaging Systems, on a global scale, across a diverse set of industries in both the Public and Private sectors.

192.168.2.21:30040

The post Mass Importing Mobile Phone Numbers into Active Directory using PowerShell and QAD Tools. first appeared on Fix The Exchange!.

You will need:

• A server running Windows Server 2003.*
• The Windows Server 2003 installation disk, or disk image.**

*I recommend using a fresh install with all the latest updates applied.  Microsoft used to offer a free trial of Windows Server 2003, but has since discontinued it.  A TechNet subscription is the cheapest way to get access to licenses for Windows Server 2003, and the entire family of Microsoft's server products, if you don't already have it.

**Before you begin, make sure you have the install disk in the optical drive, or disk image (.iso) mounted.

Let's get started…

There are a couple of ways to start the Active Directory Installation Wizard.  My favorite is to simply run "dcpromo".

Click "Start" then "Run".  Enter "dcpromo" in the "Open:" box, and click "Ok".

This starts the Active Directory Installation Wizard.

On the "Welcome" screen, click "Next".

This screen gives you a warning about older operating systems that you'd hope no one is really still running these day.  Unfortunately there are more of these old systems out there than you'd think.  Click "Next".

This is the first domain controller for our new Active Directory environment, so select "Domain controller for a new domain" and click "Next".

Again, this is a brand new Active Directory environment, so here we'll choose "Domain in a new forest" and click "Next".

Here you must enter a name for your new domain.  I used "fixtheexchange.com".  Some places like to use ".int" for "internal" or ".dev" for "development".   You could even use ".lab", it's up to you, so pick a name for your new AD Domain, and click "Next".

Here you have to enter a NetBIOS name.  I like to shorten mine, so I used "FTE" short for "Fix the Exchange".  Give yours a name that makes sense to you, and click "Next".

Here you can change the folder that AD stores the database and logs in.  Since this is a test lab, I just left the default location.  In production environments, I like to put these on their own drive, separate from the system drive.  Click "Next".

Here you can change the location of the SYSVOL folder.  Click "Next".

Active Directory relies on DNS.  We could have installed it prior to starting the AD Install Wizard, but Microsoft was nice enough to include this option to do it for us.  Select the option shown in the image above, and click "Next".

If you have older operating systems that will need to access the domain, select the first option, otherwise choose the 2nd, and click "Next".

Set and confirm a restore mode password (don't forget what it is!) and click "Next".

Click Next.

This part will take a little while, let it do its thing.

Click Finish!

That's it, you have a brand new Active Directory environment, containing a single domain in a single forest, ready for use!

Josh Bryant

Cybersecurity Product Leader and internationally recognized Speaker at several Information Security conferences and events with over 26 years of experience as a proven leader in Cybersecurity, Product Management, Threat Hunting, Incident Response, IT Management, IT Architecture, IT Operations, IT Engineering, and Messaging Systems, on a global scale, across a diverse set of industries in both the Public and Private sectors.

192.168.2.21:30040

The post How To: Install Active Directory on Windows Server 2003 first appeared on Fix The Exchange!.