Exchange

Script to Change Multiple Out Of Office Messages

This is probably an inefficient script, but I needed to create it as a once off to change the wording of any user with an Out Of Office message. It will go through every account, and change any instance of swearword and replace it with censored (no, this isn’t what I needed to use it for!).

This is using the Exchange Management Shell:

$data = get-mailbox -resultsize unlimited
foreach ($user in $data){
$currentreply = Get-MailboxAutoReplyConfiguration $user.alias
$newreply = $currentreply.internalmessage -replace “swearword”, “censored”
Set-MailboxAutoReplyConfiguration $user.Alias -InternalMessage $newreply -ExternalMessage $newreply
}

You can also use this to find any accounts with an Out Of Office message containing a certain word or phrase:

$data = get-mailbox -resultsize unlimited
foreach ($user in $data){
Get-MailboxAutoReplyConfiguration $user.alias | Where-Object {$_.internalmessage -like “*swearword1 swearword2*”}
}

Used on Exchange 2010, but should work on 2007 and 2013 also. You may notice the results of InternalMessage and ExternalMessage are hard to read, as by default they’ll show the HTML coding – you may need to factor this into any searches or replaces you perform.

Full Mailbox Access to All Mailboxes in Exchange 2010

I’ll start this out by saying ‘Full Mailbox Access to All Mailboxes’ is generally a bad idea. It should be done on demand with the appropriate approvals and paper trails, but there are times when this may be needed – for example a service account for 3rd party software that has to read or add things to everyone’s mailbox in the company.

In my last post “End User Management of Distribution Groups in Exchange 2010” I explained how the new Role Based Access Control (RBAC) worked. Although this can be used to configure many things, it won’t give you full access to a mailbox as it’s an Active Directory based permission.

You can manually do this on a per mailbox level by either using the Exchange Management Console, or the Exchange Management Shell by following the Microsoft Technet documentation here and it’s fairly easy to convert this to all mailboxes in powershell, but that won’t help you with newly created mailboxes after running the command.

Yes you could run a daily task to get around that, but an alternative is giving AD access at the database level. Any existing or newly created mailbox will get permissions this way.

So, with that all in mind, the Exchange Powershell command to run on a particular database is:

Get-MailboxDatabase -identity “[mailbox database name]” | Add-ADPermission -user [username] -AccessRights GenericAll

If you don’t know what your databases are, just run ‘Get-MailboxDatabase’ or if you want to just apply the permissions to all databases:

Get-MailboxDatabase | Add-ADPermission -user [username] -AccessRights GenericAll

You can apply this to a AD group rather than a user which I’d suggest (no changes to the command required apart from typing the group name rather than user name), because it’s then easier to manage the members of the AD group than re-run this command. Also if you apply the settings to a particular user, and that user launches Outlook, all mailboxes they have full access to will auto-load into their Outlook session. Not ideal if you’ve got hundreds!

If you’d like to know more about the Add-AdPermission command, and the possible AccessRights settings check out this Technet article.

End User Management of Distribution Groups in Exchange 2010

After migrating from Exchange 2007 to 2010 and addressing all immediate issues, we eventually hit a new issue. Managers of Distribution lists who previously could add and remove members, now couldn’t do it!

savedChanges to the public group membership cannot be saved. You do not have sufficient permission to perform this operation on this object.

So, why would this break going from Exchange 2007 to 2010, and why would there be a delay?

Role Based Access Control (RBAC) was a new feature introduced in Exchange 2010 which changed the way a lot of security worked. There’s a greatly detailed 4 part article from msExchange.org here http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/exchange-2010-role-based-access-control-part1.html which explains this in detail.

As far as the groups are concerned, they stay in a 2007 mode until they get updated. When updated (by something like adding/removing a member) you’ll get prompted about changing the object:

To save changes on objectTo save changes on object “Silly name”, the object must be upgraded to the current Exchange version. After the upgrade, this object cannot be managed by an earlier version of hte Exchange Management Tools. Do you want to continue to upgrade and save the object?

Once you do this, that particular object (distribution group) now runs under the new RBAC security settings.

By default, the RBAC security settings out of the box don’t allow anyone to be able to add or remove members to distribution groups. The Exchange Team Blog explains this perfectly here: http://blogs.technet.com/b/exchange/archive/2009/11/18/3408844.aspx and also leads onto a script which will probably set things up how you want. If you don’t read this carefully, you may end up applying the built in ‘MyDistributionGroups’ role to the ‘Default Role Assignment Policy’ which means everyone can create distribution groups – definitely not ideal in most environments. I started reading another blog post which said to do exactly that, but didn’t explain why or how it worked. Sure it fixes your immediate issue, but you’re opening up a lot more than what you should.

So it’s a fairly easy fix once you now how, but if you haven’t had to worry about RBAC before there’s a little bit to get your head around first before ticking boxes and hoping for the best.

A big thanks to @ExchangeGoddess and @24x7ITConnect for their assistance and guidance on this information.

What Happened To My Email? Mailbox Audit Logging

Hi,

A very common question. An email goes ‘missing’ from someone’s mailbox, and they want to know what happened. A fair enough question – rarely is it a fault of your Exchange servers, but it’s your problem to prove otherwise.

You can use Message Tracking (details here http://technet.microsoft.com/en-us/library/bb124926(v=exchg.141).aspx, and a great guide here http://exchangeserverpro.com/exchange-2010-message-tracking/) but that will just prove the email hit the person’s mailbox, which often we already know because they saw it. Keep in mind this won’t help you for past events, but if someone is making multiple claims of emails going missing you can enable this to find out for the next occurance.

To prove what happened next, you can use the Exchange 2010 and greater feature called Mailbox Audit Logging. This will track actions on individual emails, and save the log inside the person’s actual mailbox. This can not only log what the user themselves does, but also delegates and administrators. To see what you can log, have a look at this Technet article: http://technet.microsoft.com/en-us/library/ff459237.aspx

There is also a great guide from Paul Cunningham to get you started: http://exchangeserverpro.com/exchange-2010-mailbox-audit-logging/

My scenario requires a few more commands, as I want to log all actions rather than the default which doesn’t log anything the owner of the mailbox does.
First, enable MMailbox Audit Logging on the mailbox you’re concerned with via Powershell:

Set-Mailbox -identity Adam.Fowler -AuditEnabled $true

Easy. Now, if you run this command:

Get-Mailbox -identity Adam.Fowler | fl *audit*

You will see a few results. AuditEnabled should be true, and you’ll notice by default there are some different options between AuditAdmin, AuditDelegate and AuditOwner, with AuditOwner having no settings at all. To enable all possible logging options, for the Owner of the mailbox, run this command:

Set-mailbox -identity Adam.Fowler -AuditOwner Create, HardDelete, Move, MoveToDeletedItems, SoftDelete, Update

You can then run the previous command to see the extra options show up. Now that Mailbox Audit Logging is running on the mailbox, logs start to get generated. Once a few actions have been run on the mailbox, you can start looking at the results. Technet have some good examples here: http://technet.microsoft.com/en-us/library/ff522360.aspx

One example is if you are looking for an email with a subject that contains the word “test” within a date range:

Search-MailboxAuditLog -Identity Adam.Fowler -StartDate 7/21/2013 -EndDate 7/21/2013 -showdetails | where-object {$_.ItemSubject -like “*test*”}

If you want a glance at how many results you’re seeing, filter just to show the subject of each result and what happened to it (operation):

Search-MailboxAuditLog -Identity Adam.Fowler -StartDate 7/21/2013 -EndDate 7/21/2013 -showdetails | where-object {$_.ItemSubject -like “*test*”} | fl itemsubject, operation

Once you find the result you’re looking for, you’ll see a lot of helpful information – especially what device did the action. For example, under the ClientInfoString I can tell a particular action was done by my account on a Samsung Galaxy S3 via ActiveSync (aka Samsung I9300)

ClientInfoString : Client=ActiveSync;UserAgent=SAMSUNG-GT-I9300/100.40102;Action=/Microsoft-Server-ActiveSync/default.eas?Cmd=Sync&User=adam.fowler&DeviceId=SEC10FE7073DAC69&DeviceType=SAMSUNGGTI9300

The Operation field tells you what action was taken (e.g. MoveToDeletedItems), you’ll also get FolderPathName and DestFolderPathName (where the email went from and to). Of course this will help identify if a delegate has been cleaning up the owner’s emails, but also if a certain device they have is doing something it shouldn’t.

I would recommend only using Mailbox Audit Logging when required, due to the small amount of extra space and load you’ll use on your mailboxes, you would need to do extensive testing before enabling company wide.

Good luck!

LinkedIn Security/Information Risks with Exchange

Hi,

Today after logging on to LinkedIn, I was greeted with a new screen I found rather worrying. It is commonplace for services like LinkedIn and Facebook to scan through your address book, and ask for credentials to do so (which is rather concerning already), but a new option has popped up:

 

linkedin

 

This is asking for your work username and password. No 3rd party should be asking for corporate credentials like this, even more so a company that’s been hacked before http://www.pcworld.com/article/257045/6_5m_linkedin_passwords_posted_online_after_apparent_hack.html . I tried this with a test account, entering the username and temporary password. It then asked for further information, which was the address for the Outlook webmail link and then connected and started showing contacts.

LinkedIn on this page says “We’ll import your address book to suggest connections and help you manage your contacts. And we won’t store your password or email anyone without your permission.” which is a start, but it’s just such a bad practise to get into, and encouraging people to do this is irresponsible of LinkedIn in my opinion. On top of this, it’s providing an easy mechanism for staff to mass extract their contacts outside the company, which many companies frown upon or even have strict policies in place.

You can’t stop people from entering in these details of course, but you can block the connection from working at the Exchange end, as long as you have at least Exchange 2010 SP1.

There are a few settings to check. First, under the Set-OrganizationConfig area, you’ll need to check that EwsApplicationAccessPolicy is set to ‘EnforceBlockList’. If it’s not, it’s going to be “EnforceAllowList” and you’re probably OK, as it’s using a whitelist for access to only what’s listed rather than a blacklist, to only block what’s listed.

Next, you need to add LinkedIn into the BlockList. This is done with the command “Set-OrganizationConfig -EwsBlockList LinkedInEWS

How do we know it’s the string “LinkedInEWS” to block? The IIS log files from Exchange will reveal this. After doing your test of trying LinkedIn (or any other Exchange Web Services connection) there will be a log entry. You can read this blog post from Microsoft for some great details http://blogs.technet.com/b/matabra/archive/2012/08/23/block-mobile-apps-that-use-exchange-web-services.aspx but the abbreviated version is to look at what’s connecting fir POST /EWS/Exchange.asmx, and you’ll see the username you used to test, then the named connection. Here’s an example (with domain, username and IP changed):

2013-06-02 10:37:48 192.1.1.135 POST /EWS/Exchange.asmx – 443 domain\testusername 192.168.1.1 LinkedInEWS+(ExchangeServicesClient/0.0.0.0) 200 0 0 296

After applying, I retested and it seemed to still connect, but couldn’t find any contacts. My guess is that it’s authenticating OK, but then refusing to do much else. If anyone else would like to test this and post the results, I’d be very happy to find out update this.

 

Funnily enough, after writing this I found that LinkedIn had posted a very short version of the above:

From: http://help.linkedin.com/app/answers/detail/a_id/5025

Disabling Contact Import Process – Corporate IT Managers Instructions

How do I disable the ability for employees at my company to import contacts from their work email account?

Last Reviewed: 10/10/2012

Report Answer Inaccuracies

If you’re a Corporate IT manager, you can disable an employee’s ability to import contacts from their work email accounts.

Use Set-OrganizationConfig cmdlet to:

  • Set the value of config parameter EwsApplicationAccessPolicy to EnforceBlockList.
  • Add value LinkedInEWS to config parameter EwsBlockList.

For more information on using Set-OrganizationConfig cmdlet, please refer to Microsoft’s Managing Access for EWS Managed API Applications.

 

Further reading is available here:

http://thoughtsofanidlemind.wordpress.com/2010/08/12/controlling-ews-access-in-exchange-2010-sp1/

http://security.stackexchange.com/questions/36560/how-do-i-block-linkedin-from-extracting-data-from-microsoft-exchange-server

 

Update:

Paul Cunningham has done a great writeup about this with some extra investigation and details, have a read: http://exchangeserverpro.com/blocking-linkedin-access-to-your-exchange-server-organization/

 

Update 2:

This story had now been picked up by The Register, have a read here: http://www.theregister.co.uk/2013/06/06/linkedin_snarfing_contacts_from_exchange/

 

Update 3:

Seems to be getting picked up all over the place, so I’ll just keep updating this point as I find other articles. There’s some good discussion and opinions on this out there, such as why is Exchange configured to allow everything by default?

http://securencrypt.com/blog/linkedin-has-major-privacy-issue/

http://webwereld.nl/beveiliging/78036-linkedin-slurpt-data-van-zakelijke-exchange-servers