Exchange Server – O curioso caso de alterações indevidas em calendários
Autor: Frederico Barradas / Revisão: Caio Ribeiro César
Recentemente, trabalhamos em um cenário em que alguns usuários reportaram que seus compromissos no Outlook estavam sendo atualizados sem o seu consentimento.
Os usuários em questão seriam os organizadores dos compromissos e segundo eles, estavam sendo enviados status de atualização e de cancelamento sem que eles tenham feito nenhuma ação. Todos os participantes do evento recebiam as notificações de atualização, geralmente alguns minutos antes ou até mesmo depois do término das reuniões.
Discutimos em um artigo anterior, a possibilidade de se ativar o mailbox audit para manter um registro sobre as ações feitas numa caixa de correio. Após alterações e melhorias no produto (EXO), a auditoria de mailbox audit funciona para ambos delegates e owners de mailbox.
Analisar os logs de auditoria de mailbox seria interessante para investigar quem fez ou quando foi feita alguma ação específica (como por exemplo saber quem acessou a caixa de correio/quem poderia ter enviado as atualizações dos eventos).
Antes de coletar os logs de auditoria em mailbox, validamos o permissionamento das contas (Get-MailboxPermission e Get-MailboxFolderPermission). Verificamos que nenhum outro usuário possuia permissões de delegação nas caixas de correio, nem mesmo delegação de calendário. O mailbox audit pode nos trazer a informação de que o próprio dono da mailbox efetuou alterações, porém não seria o foco de troubleshooting - pois a partir deste momento, suspeitamos ser algum device que estava fazendo alterações com a autenticação do mailbox owner.
Focamos o troubleshooting em um exemplo concreto de alteração indevida de uma reunião:
Horário da reunião: 24 de Março 07:30-08:00 (UTC -3).
Horário de envio da atualização indevida: 24 de Março 08:05 (UTC-3) - 5 minutos após o término da reunião.
O organizador do compromisso acima efetuava acesso em sua mailbox de diversas maneiras: Outlook 2013, OWA e ActiveSync através de um device iPhone. Os outros dois usuários que também reportaram o mesmo comportamento de atualizações indevidas dos seus compromissos informaram que o acesso era feito pelo Outlook e também dispositivos móveis.
Continuamos colhendo informações que poderia nos trazer detalhes mais precisos sobre como as atualizações indevidas de compromissos estavam ocorrendo:
1) Cabeçalhos originais da atualização indevida de dia 24 de Março
2) Logs dos eventos da Store da caixa de correio do usuário
*Em uma leitura de logs, é importante sempre observar a diferença entre o fuso horário do servidor vs. o fuso horário dos usuários finais.
Através dos headers da atualização do compromisso que foi enviada, podemos validar a hora exata (UTC 0) do envio feito através do Exchange Online:
Observando a diferença de fuso horário, confirmamos que o evento indevido foi recebido pelos usuários no horário “08h04h34s” com o fuso horário de UTC -3. O fuso horário do nosso servidor é de UTC0, logo essas ações iriam aparecer no log da store as 11h04m34s.
No log verificamos ações em bulk feitas na mailbox nesse exato horário. O log mostra que objetos do calendário sendo modificados em bulk pelo client “AirSync”.
Neste mesmo log, vemos o mesmo padrão de comportamento (items na caixa de correio sendo modificados) com o “AirSync”. Vemos que algumas das ações em massa “ObjectModified” foram feitas em items da classe IPM.Appointment que corresponde exatamente a compromissos do calendário.
Ao ser comprovada a origem das alterações indevidas, os usuários afetados (que utilizavam o ActiveSync através aplicações nativas do iOS e Android) recriaram a conta nos dispositivos móveis e o comportamento deixou de acontecer.
Os logs Store Trace poderão ser úteis em outros cenários específicos tais como:
- Descobrir o que aconteceu com um item apagado, especialmente em situações em que o Mailbox Audit não está habilitado, conforme explicado neste artigo.
- Ações automáticas feitas pelos mailbox assistants do Exchange. No exemplo abaixo vemos que mensagens foram purged devido a políticas de retenção. – Os logs mostram eventos “ObjectDeleted” feitos pelo “TimeBasedAssistants” (abaixo em amarelo).
- O tipo de cliente que efetuou acesso a caixa de correio. No exemplo abaixo, podemos ver um compromisso que foram processados através do MOMT (MAPI On The Middle Tier), ou seja um cliente de MAPI como o Outlook 2013.
Agora iremos explicar como podemos coletar os logs de Store Trace no Exchange Server. Por padrão, os logs de Store Trace são mantidos por um período de 7 dias (pode ser aumentado até um máximo de 30 dias):
Método 1 – Como explicado no artigo do Chris Pollit mencionamos anteriormente, podemos consultar a tabela de eventos através dos comandos abaixo:
Add-PSSnapin Microsoft.Exchange.Management.Powershell.Support
$db = (get-mailbox <user alias>).database
$mb=(get-mailbox <user alias>).exchangeguid
Get-DatabaseEvent $db -MailboxGuid $mb -resultsize unlimited | ? {$_.documentid -ne 0 -and $_.CreateTime -ge “<mm/dd/yyyy>”} | fl > c:\temp\EventHistory.txt
Abaixo vemos o output do Exchange Management Shell mostrando detalhes sobre um email enviado (EventName = MailSubmitted), pelo próprio owner da caixa de correio (UserType = PrimaryOwner), feito através do Outlook Web App (ClientCategory = OWA).
Método 2 – ExTRA. A coleta de dados via Store Trace utilizando a ferramenta Exchange Troubleshooting Assistant (ExTRA) ainda é feita para cenários com Exchange 2007 e 2010, porém a partir da versão 2013, esta ferramenta é de utilização interna para a Microsoft.
Se você é um cliente de Exchange Online e estiver experienciando este comportamento, pode ser necessário a abertura de um chamado com o time de suporte (já que a coleta de store trace é feita pelos engenheiros de suporte da Microsoft).
Para ambos os cenários (Onprem e Oncloud), recomendamos sempre o troubleshooting inicial se inicie com o básico:
- Permissões da Mailbox, como delegações e FullAccess concedidos a outros usuários;
- Coleta de informações do usuário owner (quais métodos são utilizados para o acesso na mailbox, quais add-ins estão instalados no Outlook);
- Leitura dos logs de Mailbox Audit.