I was recently working on a project that involved creating some Retention policies for our Exchange 2010 sp1 environment. The project got a bit scary in the testing phase when we realized that the Inbox deletion policies were also deleting emails in the user’s sub-folder.  The came as a surprise to us since we were able to use the same type of policy in Exchange 2003 prior to upgrading.

To solve this issue we had to create retention policies to manage our deleted items, sent items, and drafts but use message record management to handle our inbox. Since MRM was being phased out of 2010 this solution needed to be implemented via the Exchange management shell (Powershell).

Implementing MRM:

Messaging records management (MRM) is the records management technology in Microsoft Exchange Server 2010 that helps organizations reduce the legal risks associated with e-mail. MRM makes it easier to keep the messages needed to comply with company policy, government regulations, or legal needs, and to remove content that has no legal or business value.

Prior to implementing this its best to check to see if any additional policies were created and if you don’t play on using them going forward delete them. You can do so with the below commands:

Review commands:

ManagedFolderMailboxPolicy

 [PS] C:\Windows\system32>Get-ManagedFolderMailboxPolicy

Name                      ManagedFolderLinks

—-                              ——————

Test Policy1            {Inbox}

ManagedContentSettings

 [PS] C:\Windows\system32>Get-ManagedContentSettings

 Name                      MessageClass              ManagedFolderName

—-                            ————- ————              —————–

Inbox Content               *                                           Inbox1

ManagedFolder

 [PS] C:\Windows\system32>Get-ManagedFolder

 Name                      FolderName                Description

—-                              ———-                ———–

Inbox1                    Inbox                     ManagedDefaultFolder

After retrieving this information you can now issue the following commands to remove any old or test policy:

Remove Policy from users

Set-Mailbox username -ManagedFolderMailboxPolicy $null

Removed ManagedFolder Mailbox Policy

[PS] C:\Windows\system32>Remove-ManagedFolderMailboxPolicy “Test Inbox Policy”

Remove Manage Content Setting

 [PS] C:\Windows\system32>Remove-ManagedContentSettings “Inbox Content”
Creating and Implementing MRM:

1. Create your managed folder
2. Create your managed folder content setting
3. Create your manage mailbox folder policy
4. Apply your policy to a user or to an exchange data store.
5. Start the managed folder assistant service or wait for it process on schedule

The below policy will delete all emails from the user mailbox that are 60 days old without touching any sub folders in the user’s Inbox.

Managed Folder Creation

 New-ManagedFolder -Name “Test Inbox” -DefaultFolderType Inbox -BaseFolderOnly $true -Comment “Items would be moved to deleted items for 60 days” -MustDisplayCommentEnabled  $true

Managed Folder Content Settings

New-ManagedContentSettings -Name “Test Content” -FolderName “Test Inbox” -MessageClass * -AgeLimitForRetention 60 -RetentionAction MoveToDeletedItems -RetentionEnabled $true -TriggerForRetention WhenDelivered

 Managed Mailbox Folder Policy

New-ManagedFolderMailboxPolicy -Name “TestPolicy” -ManagedFolderLinks “Test Inbox”

Verify settings

[PS] C:\Windows\system32>Get-ManagedFolderMailboxPolicy “TestPolicy” |fl

[PS] C:\Windows\system32>Get-ManagedContentSettings “Test Content”|fl

[PS] C:\Windows\system32>Get-ManagedFolder “Test Inbox” |fl

Start the Managed Folder Assistant to process the mailbox.

Apply to single user:

 Set-Mailbox -Identity testuser -ManagedFolderMailboxPolicy “TestPolicy”

Start-ManagedFolderAssistant -ID  testuser

Apply to a database level:

Get-Mailbox –database “Database Name” | Set-Mailbox –ManagedFolderMailboxPolicy “Name of the Policy”

Tip:

If you run into issues wait about 30 mins for the folders to replicate after created them. You can also stop and restart the “Managed Folder Assistant” service.

Would love to know how others handled this issue.

References:

http://technet.microsoft.com/en-us/library/bb508901%28EXCHG.80%29.aspx
http://technet.microsoft.com/en-us/library/dd335093.aspx

Hello all, so once more I have another post that’s Exchange 2010 related; why you ask because with so much to learn about Exchange you can never stop talking about it. So the issue I was faced with a few weeks ago was trying to figure out how to stop the students at the Uni I worked for from created their personal  groups and publishing it to the GAL (Global Address List) for everyone to see.

Just picture the president of the college trying to search for a contact and seeing something like “HackerContacts” as an option, that might trigger a few calls to the IT department.

I release that by default Exchange 2010 “Default Role Assignment Policy” allow all users to login via Outlook Web App, go to options –> see all options, then click on the groups options and on the right under “Public Groups I Own” a user can create a new group which would be published in the GAL.

After doing some research I release to block this you need to edit the “Default Role Assignment Policy” and uncheck the options under “Distribution groups, and Distribution group membership”.

• On your exchange server go to the toolbox->Role Based Access Control, This will launch IE and attempt to open the permissions area. If this does not open/work double check the account your logged in has a mailbox on 2010 first or is in the Enterprise admin group.
• You should see 2 menu items, “Users & Groups” and “Reporting” , You want “Users & Groups” then switch to the “User Roles” tab. In there edit the “Default Role Assignment Policy” which will pop up in a new window. All you have to do is remove the checkboxes as required  and it will get rid of the option for you.

Hope you found this useful, leave a comment if you have a better way or doing this or if these steps did not solve the issue for you. Thanks for reading!

Resource:

http://help.outlook.com/en-gb/140/ee424427.aspx

http://www.edugeek.net/forums/windows/53916-outlook-web-app-exchange-2010-public-groups.html

Hello all, so  I know its been a while since my last post and I have not really posted anything Infosec related recently but to be honest I have been so busy at work I have not had any time for anything else.

Today I wanted to share with you a script that I originally got from  http://www.myexchangeworld.com , I have been working on tweaking this script as part of our migration to 2010. We normally get a list csv file with (Firstname, Lastname, StudentID) from our registra department and we have to create AD, and Exchange user account for these users.

The script would have worked as it is but instead of adding the following fields in the csv file I wanted to have the script input these vaules on the fly:

•  User principal name
• Alias
• Database
• OU
• Display Name
• Retention policy

We have recently upgraded to Exchange 2010 from 2003 and with that update comes new ways of dealing with old recurring task, I will try to outline over the new few blog posting how to accomplish these task. If you are ask to remove or grant someone access to a user’s mailbox below is the recommended approach.

You can do this two ways first is via the Exchange management console (EMC) or via the PowerShell:

EMC approach:

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the “Permissions and delegation” entry in the Mailbox Permissions topic.

1. In the console tree, navigate to Recipient Configuration > Mailbox.
2. In the result pane, select the mailbox for which you want to grant Full Access permission.
3. In the action pane, under the mailbox name, click Manage Full Access Permission. The Manage Full Access Permission wizard opens.
4. On the Manage Full Access Permission page, click Add.
5. In Select User or Group, select the user to which you want to grant Full Access permission, and then click OK.
6. Click Manage.
7. On the Completion page, the Summary states whether Full Access permission was successfully granted. The summary also displays the Shell command used to grant Full Access permission.
8. Click Finish.

PowerShell approach:

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the “Permissions and delegation” entry in the Mailbox Permissions topic.
First verify who currently has access to the user’s mailbox with the Get-MailboxPremission cmdlet, you will notice several default system accords you are only concern with user accounts.

Get-GmailboxPermission “John Doe”

If you want to remove Jane Doe  from having full access to John’s  mailbox you can do the following:

Remove-MailboxPermission “John Doe” -AccessRights FullAccess -User “Jane Doe”

If  you are ask to  grant the user Marry Full Access permission to Frank’s mailbox do the following:

Add-MailboxPermission “Frank Loew” -User “Mary May” -AccessRights FullAccess

Once you are finish granting access just mount the mailbox via outlook and close and reopen outlook and it should be accessible.

Source:

http://technet.microsoft.com/en-us/library/aa996343.aspx

Today one of our faculty member forward an email to our help-desk and indicated we take a look at it because it might be a phising/spam email, you can only image how happy that made me. Now in the past we have had cases where people would reply to these type of emails and receive more  spam in the process, or worst, “give their credentials away” but that was not the case today.

Below is an image of the email that was received today.

Fig-1 Phising Email

Now the first thing that I found funny about this email is the fact that the phone number for tech support was an IP Address, maybe the overlooked that one or it was done out of humor either way it set off some flags for me and it should for anyone that receives an email like this.

Once I identified the email as a phising attempt to harvest login credentials I got curious and decided to load Firefox within sandboxie and clicked on the link in the email to see what it would do.

Fig-2 Firefox Untrusted Error

Now after clicking on the link in the email I was redirected to www.eformit.com , which triggered a FireFox error because Firefox was unable to confirm that my connection to the site was secure. Since I was in search of seeing where the link would take me I went ahead and added the certificate and continued. In general if you ever get this error you should never add the certificate but instead close out your browser and do some research on the site in question.

Next I went ahead and examine the server SSL certificate and realized that it expired a few days ago, that’s another reason that would tell me this site was bad business, but since I already knew that I proceeded all the same.

Fig-3 Expired Cert

Now on to the next portion of this journey, after clicking on the link I was taken to a website with a very contradictory notice, “we will never send emails to users requesting email account information” however that’s exactly what the page is asking you to type in.

Fig-4 Credentials harvesting form

Now lastly after filling in my email and password , I was redirected to a parking page filled with cheap advertising another sign of trouble.

Fig-5 Redirected page

Additional information courtesy of  http://anubis.iseclab.org a very useful source for analyzing uncertain files and URL’s.

Fig-6 Additional network analysis information

In the end its always important to train your users to identify what a good or bad email look like and what your network policies are for these type of emails. Also when in doubt load-up your sandbox and have some fun.

References

http://scanner.novirusthanks.org/

http://anubis.iseclab.org

http://www.sandboxie.com/