By Cesar Hara, Victor Santana and Caio Cesar

Greetings everyone!

Today we are going to cover a very interesting way to troubleshoot user synchronization issues to Office 365 (Azure Active Directory). The method consists of using the attribute: “mS-DS-ConsistencyGuid”.

We recommend going through this article for a better understanding of what is being discussed in this post.

As many of you know, historically, AD Connect used to choose “ObjectGUID” as the sourceAnchor attribute to sync objects to the cloud. Starting on version 1.1.524.0, we can use mS-DS-ConsistencyGuid instead.

What is the big deal with it? Unlike ObjectGuid, this attribute is writable. This means we can manipulate synced objects easier.

Recently, customers started to raise tickets related to this matter. We were able to fix these incidents without causing service disruption to the end users, scenarios may vary from: “I have a synced multi-forest environment and the user was migrated between them”, “A user was deleted from Active Directory by mistake while AD Connect was not working and we reinstalled it” and “I lost the only DC in my forest, so I had to rebuild my AD forest completely”.
(PLEASE, ALWAYS PROMOTE AT LEAST TWO DOMAIN CONTROLLERS!!)

Pre-requisites: You will need to have access to AAD PowerShell connected to your tenant (with global admin permissions), AD Connect Server and access to the Domain Controller.

Scenario 1:

“A user was deleted from AD by mistake while AD Connect was not working. We created a new account since we cannot recover the old one and then we reinstalled AD Connect, but the changes performed on local Active Directory object are not syncing to the cloud account.”
NOTE: There are other possible scenarios, this is only one of the scenarios we have seen.

Understanding the problem:

• As AD Connect was down, the removal of the user was not “picked” by AD Connect.
• As a result, this deletion did not occur in AAD. This means the account is orphan in AAD.
• The new account has a new on-prem ImmutableID (originated from ObjectGUID). This attribute cannot be changed in the cloud for synced accounts.
To reproduce this behavior, we have uninstalled AD Connect, deleted the user account from Active Directory and re-installed AD Connect.

To confirm that the problem is with the different ImmutableID, you can follow these steps:
• Get the ImmutableID of the affected account in the cloud:

Get-MsolUser -UserPrincipalName john@cesarhara.com | select ImmutableID
ImmutableID: kKfL2wwI+0W+rN0kfeaboA==

• Perform a metaverse search for the new user created in AD (or convert the ObjectGUID taken from AD into a base64 format with the GUID2ImmutableID tool) to confirm the new ImmutableID:

• If you have attribute resiliency, AD Connect will not show any errors. You can go to the Portal or PowerShell to identify the error:

In summary, any changes we make to this on-prem object will not be reflected to the cloud.

Steps to resolve:

1- Confirm that the attribute being used in AD Connect as the “SourceAnchor” is the “mS-DS-ConsistencyGuid”, just run the AD Connect Wizard and choose “View Current Configuration”:

2- Make sure that the “UPN” and “ProxyAddresses” attributes are the same in O365 and AD accounts - you can download the users report in the Admin Portal or use PowerShell to extract this information. These attributes are essential, if you are aware of any other one missing, proceed to add it to the account in your local AD accordingly.

3- Grab the ImmutableID value of the cloud/original account. Here is the cmdlet again:

Get-MsolUser -UserPrincipalName john@cesarhara.com | select ImmutableID
ImmutableID: kKfL2wwI+0W+rN0kfeaboA==

4- We have to convert the value of the “ImmutableID” to a HEX format so we can add it into the on-prem account:

[system.convert]::FromBase64String("kKfL2wwI+0W+rN0kfeaboA==") | %{$a += [System.String]::Format("{0:X}", $_) + " "};$result = $null;$result = $a.trimend();$result

The output is:
90 A7 CB DB C 8 FB 45 BE AC DD 24 7D E6 9B A0

5- Now let’s get back to our AD Connect server and stop the scheduled task (it’s a good practice to do so, avoiding a sync task to run while we are troubleshooting this):

Set-ADSyncScheduler -SyncCycleEnabled $false

6- Move the account to a non-synced OU and run a delta sync (this is required to the match occurs later).

Start-ADSyncSyncCycle -PolicyType Delta

7- In the new account created in ADDS, edit its attributes. Do this by locating the mS-DS-ConsistencyGuid and adding the HEX value from step 2 (if there is a value, AD Connect added the current ObjectGUID value as the default behavior, proceed to add the new one):

8- Move the account back to a synced OU and run a delta sync again, if everything ran as expected the sync would occur successfully.

9- Add or change an attribute in AD to make sure the sync worked as expected. Finally, check in the Portal and the error will be gone:

Conclusion:

With this new feature, it is possible to resolve problems that used to be hard to deal with it when using “ObjectGUID”. Regardless the scenario, we must always use the original ImmutableID (already set in the cloud), convert it to an HEX value and add into the “mS-DS-ConsistencyGuid” so the match occurs.
If you are going to migrate accounts between forests make sure to populate in the target forest object “mS-DS-ConsistencyGuid”, the value of the source object “ObjectGUID”.

NTLM vs KERBEROS

(WWW)

Podemos interpretar este post como os três W's, um para cada capítulo.

Vamos passar pelos conceitos basicos do NTLM e do Kerberos. Quais são as principais diferenças entre eles, como funciona o fluxo e como podemos identificar qual protocolo está sendo usado.

Então, sem mais demora. Aqui vai a história ...

Capítulo 1

The What:

O que é o NTLM?
O NTLM é um protocolo de autenticação. Era o protocolo padrão usado nas versões antigas do Windows, mas ainda é usado hoje. Se por algum motivo o Kerberos falhar, o NTLM será usado.
O NTLM possui um mecanismo de desafio / resposta.
Aqui está como funciona o fluxo NTLM:

1 - Um usuário acessa um computador cliente e fornece um nome de domínio, um nome de usuário e uma senha.
O cliente calcula um hash criptográfico da senha e descarta a senha real. O cliente envia o nome do usuário para o servidor (em texto sem formatação).

2 - O servidor gera um número aleatório de 16 bytes, chamado desafio, e o envia de volta ao cliente.

3 - O cliente criptografa esse desafio com o hash da senha do usuário e retorna o resultado para o servidor. Isso é chamado de resposta.

4 - O servidor envia os três itens a seguir para o controlador de domínio:
- Nome do usuário
- Desafio enviado ao cliente
- Resposta recebida do cliente

5 - O controlador de domínio usa o nome de usuário para recuperar o hash da senha do usuário. Ele compara o desafio criptografado com a resposta do cliente (na etapa 4). Se eles forem idênticos, a autenticação será bem-sucedida e o controlador de domínio notificará o servidor.

6 - O servidor envia a resposta apropriada de volta ao cliente.

O que é o Kerberos?
O Kerberos é um protocolo de autenticação. É o protocolo de autenticação padrão nas versões do Windows acima do W2k, substituindo o protocolo de autenticação NTLM.
Aqui está como o fluxo do Kerberos funciona:

1 - Um usuário loga na máquina cliente. O cliente faz um pedido de texto simples (TGT). A mensagem contém: (ID do usuário; ID do serviço solicitado (TGT); O endereço de rede do cliente (IP); tempo de vida da validação)

2 - O servidor de autenticação verificará se o usuário existe no banco de dados do KDC. Se o usuário for encontrado, ele gerará aleatoriamente uma chave (chave de sessão) para uso entre o usuário e o Servidor de Concessão de Ticket (TGS). O servidor de autenticação enviará duas mensagens de volta para o cliente: - Um é criptografado com a chave secreta do TGS. - Um é criptografado com a chave secreta do cliente.

NOTA: A chave de sessão TGS é a chave compartilhada entre o cliente e o TGS. A chave secreta do cliente é o hash das credenciais do usuário (nome de usuário + senha).

3 - O cliente descriptografa a chave e pode fazer logon, fazendo o cache localmente. Ele também armazena o TGT criptografado em seu cache. Ao acessar um recurso de rede, o cliente envia uma solicitação ao TGS com o nome do recurso que ele deseja acessar, o ID do usuário / registro de data e hora e o TGT em cache.

4 - O TGS descriptografa as informações do usuário e fornece um tíquete de serviço e uma chave de sessão de serviço para acessar o serviço e enviá-lo de volta ao Cliente depois de criptografado.

5 - O cliente envia o pedido para o servidor (criptografado com o tíquete de serviço e a chave de sessão)

6 - O servidor descriptografa o pedido e, se for genuíno, fornece acesso ao serviço.

Capítulo 2

The When:

Como podemos identificar quando estamos usando o NTLM ou o Kerberos?
Podemos confirmar a autenticação sendo usada pela simples coleta de um Fiddler. No Fiddler, podemos ver os pedidos sendo feitos nos Inspetores / Cabeçalhos:

Kerberos:

NTLM:

Se a solicitação iniciar com o Kerberos e falhar, o NTLM será usado. Podemos ver a resposta nos cabeçalhos também:

Quais são as dependências do Kerberos?
Tanto o cliente quanto o servidor precisam estar executando o W2k ou versões posteriores e estar no mesmo domínio ou confiável.
Um SPN precisa existir no AD para a conta de domínio em uso para executar o serviço no qual o cliente está sendo autenticado.

Capítulo 3

The Why:

Os hashes NTLMv1 podem ser quebrados em segundos com a computação de hoje, pois eles têm sempre o mesmo tamanho e não são salted.
O NTLMv2 é um pouco melhor, desde o tamanho variável e o hash salted, mas não muito melhor. Mesmo que o hash seja salted antes de ser enviado, ele é salvo unsalted na memória de uma máquina.
E claro, quando falamos sobre o NTLM, falamos sobre um mecanismo de desafio / resposta, que expõe sua senha ao cracking off-line ao responder ao desafio.

O Kerberos fornece várias vantagens sobre o NTLM:
- Mais seguro: Nenhuma senha armazenada localmente ou enviada pela rede.
- Melhor desempenho: desempenho aprimorado em relação à autenticação NTLM.
- Suporte à delegação: os servidores podem representar clientes e usar o contexto de segurança do cliente para acessar um recurso.
- Gerenciamento de confiança mais simples: evita a necessidade de ter relações de confiança p2p em ambientes de vários domínios.
- Suporta MFA (Multi Factor Authentication)

O fim

By: Caio Ribeiro César

 Como muitos já perceberam, existe uma nova opção abaixo de “Threat management” no Security & Compliance Center:

Trata-se do novo Message Trace, disponibilizado para os administradores desde o dia 25 de Abril (full availability para todos os tenants pode demorar de 4 até 6 semanas).

A decisão foi tomada a partir de diversos pedidos do time de suporte, juntamente com o field.

Message trace antigo e suas limitações

Utilizado desde a época de migração de BPOS para O365, sem muitos updates, o Message Trace antigo possui algumas limitações.

1. O search comum é efetuado apenas para o range de até 7 dias;
2. O search detalhado de +7 dias demora para ser entregue;
3. Filtro de emails e queries customizáveis são apenas disponibilizados via PowerShell.

Message trace antigo e sua interface disponibilizada no Exchange Admin Center (EAC).

Message trace novo e suas novas features

Com a ferramenta disponibilizada no SCC, podemos:

• Procurar e-mails baseando-se no time zone;
• Filtrar e-mails via Subject filtering;
• Filtrar apenas e-mails marcados como Junk

• Real time trace, facilitando o troubleshooting para procurar mensagens real time;
• Common queries (templates) criados pelo time de Produto;
• Disponibilização da criação de custom queries para os administradores;
• Repositório de relatórios para download;
• Search detalhado mais rápido e efetivo;
• Output de resultados na interface gráfica estendido de 1.000 para 10.000;
• On-screen search aumentado de 7 para 10 dias;
• Extended search customizado de últimas 6 horas até 90 dias.

Gostaram da atualização? Deixe seu comentário!

Obrigado ao Arindam Thokder, SEE Beta Engineer de Exchange que nos apresentou esta feature antes de estar released para o público!

Kudos to Arindam Thokder, SEE Beta Engineer from the Exchange team, that presented this feature to us before it was publically available, making us aware and ready to build this post!

Obs. O Message trace antigo também continuará funcionando após a release do novo Message Trace.

O final do suporte para a release de Exchange 2010 está chegando! Atualize-se!

Exchange 2010 end of Support is coming! Patch it up!!

By: Caio Ribeiro César

Hoje iremos discutir um cenário comum no suporte em um método short and simple (kiss).

Alguns clientes que possuem um ambiente híbrido, ligam informando receber o erro abaixo em mailbox moves:

Hybrid migration of mailboxes with more than 100GB of storage from an Exchange 2010 to Office 365.

Error: MigrationPermanentException: The size of Recoverable Items 129.7 GB (139,275,977,263 bytes) exceeds the Recoverable Items quota of the target mailbox database 100 GB (107,374,182,400 bytes). -> The size of Recoverable Items 129.7 GB (139,275,977,263 bytes) exceeds the Recoverable Items quota of the target mailbox database 100 GB (107,374,182,400 bytes).

Mesmo a causa sendo bem simples, iremos discutir aqui o que ocorre neste cenário. Primeiro, iremos coletar um Get-Mailbox da conta On-Premises:

ServerName : caiocex01
Database : DB01
ProhibitSendQuota : unlimited
ProhibitSendReceiveQuota : unlimited
RecoverableItemsQuota : unlimited
RecoverableItemsWarningQuota : unlimited

Ter o “RecoverableItemsQuota” configurado como unlimited é um problema por diversos motivos, iremos listar alguns:

1. Mailbox Audit logging. O mailbox audit utiliza quota de RecoverableItems para armazenamento de logs. Caso esteja configurado como unlimited, os logs podem alcançar um tamanho muito grande (por exemplo, com a opção de mailbox audit owner hablilitado).

2. Gerência de dados. O administrador deve ter controle dos dados, caso contrário temos uma “bola de neve”. Em questão de Scalability, não é recomendado ter ambientes sem quota.

3. Segurança: não é um cenário comum, porém pode acontecer (lembre-se das leis imutáveis de segurança*). Um atacante pode conseguir acesso para uma única conta do seu ambiente e transformar este ataque simples em um Denial of Service (DoS). O atacante não precisa ser um gênio para tal feito – basta consumir os dados de RecoverableItems até a database da mailbox chegar em um limite máximo de disco.

Para o administrador que quer testar seus limites, recomendamos o Jetstress.

Vamos então para as ações necessárias para que este “problema” de mailbox move seja resolvido.

1. O Recoverable Items quota está configurado como unlimited no ambiente On-Premises. Este é o real motivo do mailbox move falhar. No Exchange Online temos esta configuração para 100GB e a mailbox On-Premises está utilizando ~130GB.
2. Para um entendimento de “quotas”, explicamos para o administrador como elas funcionam.
3. A ação necessária para o ambiente local seria a criação de uma quota/customização de como o retention está configurado para o ambiente, ou a remoção de dados (purge) para que o mailbox move possa ser efetuado. Recomendamos aguardar a atuação do MFA (Managed Folder Assistant) e não executar o comando de Start-ManagedFolderAssistant manualmente após estas alterações.
4. A partir do momento que o mailbox move pode ser concluído, podemos atuar em outras soluções tais como a utilização de Archive com Auxiliary (+100GB a cada 30 dias) para o cenário.
5. Podemos (suporte) estudar um aumento de RecoverableItemsQuota para alguns ambientes, porém este aumento só é efetuado após um Business Justification para o estudo da real necessidade. Lembrando também que este possível aumento só é efetuado post-migration, já que na migração, o objeto no ambiente cloud não é uma “mailbox” (não possui store) e sim um Mail Enabled User.

*Nobody believes anything bad can happen to them, until it does.

Recurso de bloqueio inteligente de extranet - Extranet Smart Lockout (ESL)

Em 22 de março de 2018, uma nova atualização foi lançada para o servidor Windows 2016 (KB4088889). Esta atualização nos trouxe o novo recurso de bloqueio inteligente da extranet do ADFS, ou ESL.

O recurso de bloqueio de extranet interromperá os ataques de força bruta bloqueando a conta no ADFS e impedindo que as contas sejam bloqueadas no Active Directory.
Como o nome sugere, esse recurso só será aplicado se a solicitação de autenticação for proveniente da extranet e para autenticações de nome de usuário/senha.

O novo recurso de ESL consiste na implementação de um novo parâmetro chamado <ExtranetLockoutMode >
Este parâmetro contém 3 valores diferentes:
ADPasswordCounter - este é o valor padrão. O "bloqueio de extranet suave". Não difere com base na localização.
ADFSSmartLockoutLogOnly - Esse é o modo somente de logs de bloqueio inteligente da extranet. Não rejeitará os pedidos. Em vez disso, auditará os eventos para análises.
ADFSSmartLockoutEnforce - Este é o bloqueio inteligente da extranet eficaz. Ele bloqueará as tentativas de senha incorreta quando o limite for atingido.

Antes de começar, precisamos conceder permissões de leitura/gravação ao nosso Administrador sobre o banco de dados de artefatos do ADFS, executando:

Update-AdfsArtifactDatabasePermission

(Autenticar com um administrador do ADFS)
Quando as permissões estiverem definidas, podemos iniciar a configuração de bloqueio inteligente da extranet.

Para ativar o bloqueio de extranet, precisamos executar o cmdlet:

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold <valor> -ExtranetObservationWindow <valor>

Vamos examinar os parâmetros individualmente:
EnableExtranetLockout - Este parâmetro representa a chave liga/desliga. É sempre um valor codificado, $true ou $false
ExtranetLockoutThreshold - Esse parâmetro representa o número de tentativas de senha com falha antes que a conta seja bloqueada.
Nota: O limite de bloqueio deve ser sempre menor que o do Active Directory, de modo que as contas sejam bloqueadas no ADFS apenas enquanto os usuários ainda puderem acessar seu Active Directory pela intranet ou usando uma VPN.
ExtranetObservationWindow - Este parâmetro representa a janela de tempo de observação entre os blocos. Quando o limite de bloqueio é atingido, o intervalo de tempo da janela de observação é iniciado. Quando o período de tempo da janela de observação expirar e a tentativa de autenticação for bem-sucedida, a conta será desbloqueada automaticamente e a contagem será redefinida para 0. Se uma tentativa de autenticação incorreta for feita, a janela de observação será reiniciada.

Gerenciando o ESL:

Depois de definir o ExtranetLockoutMode como <ADFSSmartLockoutEnforce>, a diversão começa

PS: Certifique-se de reiniciar o serviço do ADFS em todos os nods do ADFS no farm:

Restart-Service adfssrv

Por padrão, todos os registros de contas ficarão assim:

Depois que o usuário autentica com sucesso (com base em senha), o endereço IP é automaticamente adicionado à lista de itens conhecidos.

Se o limite de bloqueio for atingido, a conta será bloqueada automaticamente e a janela de observação será iniciada:

Mesmo que a conta esteja bloqueada, ela só é bloqueada em locais desconhecidos. O usuário ainda poderá acessar sua conta a partir de um local familiar.
Esta é uma melhoria maciça no recurso de bloqueio de extranet.

Em um cenário de força bruta, em que a conta está sendo constantemente bloqueada de locais desconhecidos, o que acontece quando o proprietário da conta tenta acessar sua conta também de um local desconhecido?
Ele não poderá acessar sua conta. No entanto, ele pode entrar em contato com o administrador para ter seu endereço IP atual adicionado nos locais conhecidos:

Set-AdfsAccountActivity -Identity <UPN> -AdditionalFamiliarIps "IP"

NOTA: A qualquer momento, a atividade da conta de bloqueio inteligente da extranet pode ser definida como padrão:

Set-AdfsAccountActivity -Identity <UPN> -Clear

O log de tentativa de acesso à conta será exibido no respectivo nod do ADFS em "Windows Logs/Segurança do Windows"

Aqui está um exemplo do log:

The Federation Service failed to issue a valid token. See XML for failure details.
Activity ID: 6d265a76-f305-4ede-a7c1-316c35514791
Additional Data
XML: <?xml version="1.0" encoding="utf-16"?>
<AuditBase xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AppTokenAudit">
<AuditType>AppToken</AuditType>
<AuditResult>Failure</AuditResult>
<FailureType>GenericError</FailureType>
<ErrorCode>N/A</ErrorCode>
<ContextComponents>
<Component xsi:type="ResourceAuditComponent">
<RelyingParty>http://adfs.contoso.com/adfs/services/trust</RelyingParty>
<ClaimsProvider>N/A</ClaimsProvider>
<UserId>user@contoso.com</UserId>
</Component>
<Component xsi:type="AuthNAuditComponent">
<PrimaryAuth>N/A</PrimaryAuth>
<DeviceAuth>false</DeviceAuth>
<DeviceId>N/A</DeviceId>
<MfaPerformed>false</MfaPerformed>
<MfaMethod>N/A</MfaMethod>
<TokenBindingProvidedId>false</TokenBindingProvidedId>
<TokenBindingReferredId>false</TokenBindingReferredId>
<SsoBindingValidationLevel>NotSet</SsoBindingValidationLevel>
</Component>
<Component xsi:type="ProtocolAuditComponent">
<OAuthClientId>N/A</OAuthClientId>
<OAuthGrant>N/A</OAuthGrant>
</Component>
<Component xsi:type="RequestAuditComponent">
<Server>http://adfs.contoso.com/adfs/services/trust</Server>
<AuthProtocol>WSFederation</AuthProtocol>
<NetworkLocation>Extranet</NetworkLocation>
<IpAddress>1.2.3.4</IpAddress>
<ForwardedIpAddress>1.2.3.4</ForwardedIpAddress>
<ProxyIpAddress>N/A</ProxyIpAddress>
<NetworkIpAddress>N/A</NetworkIpAddress>
<ProxyServer>WAP</ProxyServer>
<UserAgentString>Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36</UserAgentString>
<Endpoint>/adfs/ls/</Endpoint>
</Component>
</ContextComponents>
</AuditBase>

Espero que isto ajude.

By: Caio Ribeiro César e Cesar Augusto Hara

Após um longo período de tempo, recebemos um chamado referente à uma migração “Staged” para o Exchange Online.

Como o nome sugere, uma migração “Staged” é feita em estágios, etapas. Pode parecer um cenário simples com poucos pontos de falha, porém temos que entender um pouco como esta migração funciona antes de iniciar qualquer tipo de troubleshooting.

Considerações deste tipo de migração:

1. Os objetos são provisionados via AD<>AAD. Ou seja, mandatório que exista um AADConnect no ambiente;
2. Algumas funcionalidades cross premises não são suportadas (tais como FreeBusy, Cross Prem Archive , Hybrid Mailbox Permission entre outros) ;
3. Não existe um mailbox offboard feito nativamente via Exchange (assim como temos no ambiente híbrido);
4. Não é uma solução “longo termo”. O decomission dos servidores on-premises pode ser feito após a migração.

Resumindo a migração “Staged” em etapas:

(mais detalhes aqui)

1. Provisionamento de objetos
2. Mailbox Permission para o administrador (Full Access)
3. Arquivo CSV
4. Criação do endpoint para conexão (Outlook Anywhere do ambiente On-Premises deve estar configurado e disponibilizado externamente – este é o ponto de falha mais comum em migrações staged).
5. Migração
6. Alteração do DNS (MX)
7. Completar a migração
8. Clean Up (remoção de batches, decommission).

Vamos então ao cenário.

Cliente informa que a maioria das caixas de correio foram migradas com êxito via Staged Migration, porém algumas não estão sendo migradas.

Para ter o foco na coleta de dados e troubleshooting, isolamos o problema para uma específica. Inicialmente, coletamos o erro que estava aparecendo na interface gráfica do Exchange Online:

SourceRecipientDoesNotExistException: Não foi possível encontrar o endereço de email de origem caioc@contoso.com.br no domínio local. Relatório: caioc@contoso.com.br Baixe o relatório para esse usuário

Criamos um plano de ação de coleta de dados:

1. Para confirmar que o SMTP é valido no ambiente On-Premises, executados a coleta do comando

Get-Mailbox -Id caioc@contoso.com.br | fl

Resultado: SMTP válido e existente, mailbox ativa no Exchange 2007.

2. Coletamos os relatórios enviados para o email do administrador que estava efetuando o move mailbox.

MailboxesCreated.csv

MailboxCreationErrors.csv

EmailMigrationErrors.csv

Resultado:  o relatório mostra o Status “SyncedWithErrors”, com o mesmo erro da interface gráfica.

3. Coletamos relatórios verbose para o batch e para o usuário em questão.

Get-MigrationBatch -identity  |fl *status*
Get-MigrationBatch  -IncludeReport -Diagnostic | Export-clixml batchname_report.xml
Get-MigrationUser -Identity caioc@contoso.com.br| fl 
Get-MigrationUserStatistics -Identity caioc@contoso.com.br -IncludeReport | Export-Clixml report.xml

Resultado: todos os logs informaram a mesma mensagem de erro:

SerializationData         : {0, 1, 0, 0...}
RunspaceId                : 48fbab7-5386-473b-9e30-22c7cb09cc02
Identity                  : caioc@contoso.com.br
Guid                      : e8764567812df-08bd-433a-9987652-cd6e7eb2e1a0
Identifier                : caioc@contoso.com.br
BatchId                   : migracao
MailboxIdentifier         : caioc@contoso.com.br
MailboxEmailAddress       : 
RecipientType             : Mailbox
SkippedItemCount          : 0
SyncedItemCount           : 0
MailboxGuid               : 00000000-0000-0000-0000-000000000000
MailboxLegacyDN           : 
RequestGuid               : 00000000-0000-0000-0000-000000000000
LastSuccessfulSyncTime    : 
Status                    : Failed
State                     : Failed
Flags                     : None
WorkflowStep              : Provisioning
WorkflowStage             : Discovery
TriggeredAction           : None
ErrorSummary              : Não foi possível encontrar o endereço de email de origem caioc@contoso.com.br no domínio local.
StatusSummary             : Failed
LastSubscriptionCheckTime : 
SupportedActions          : Start, Set, Remove
IsValid                   : True
ObjectState               : Unchanged

SerializationData : {0, 1, 0, 0...}
CreationTime : 5/8/2018 4:20:31 PM
ServerName : SC1P215MB0907
Type : Error
TypeInt : 4
Flags : Failure, Fatal, Target
FlagsInt : 2066
Message : User 'caioc@contoso.com.br' failed migration: The source email address caioc@contoso.com.br couldn't be found in the on-premises domain.
MessageData                : {0, 1, 0, 0...}
Failure : SourceRecipientDoesNotExistException: Nao foi possível encontrar o endereço de email de origem caioc@contoso.com.br no domínio local.					 
LocalizedString :  User 'caioc@contoso.com.br' failed migration: The source email address caioc@contoso.com.br couldn't be found in the on-premises domain.

Efetuamos um query local no AD e conseguimos encontrar a mailbox utilizando o valor de SMTP como Identifier. A partir deste ponto, voltamos ao entendimento da teoria do mailbox move em um ambiente staged.

Como fomos informados que outras contas foram movidas sem problemas, tentamos não focar o troubleshooting no Outlook Anywhere em si (networking, endpoint, test migration connectivity).

Discutimos o cenário em questão e lembramos que nesta migração, o Exchange Online irá se comunicar via NSPI com o ambiente OnPremises para localizar a mailbox (diferente de um ambiente híbrido que utilizaria o serviço de EWS via MRSProxy):

O objeto estava sincronizado sem problema algum para o Exchange Online via AADConnect, então focamos na análise de dados utilizando um método de comparação e a matriz de soluções de suporte.

Utilizando este método, conseguimos isolar o problema para uma possível falha ou configuração do objeto em si. Comparamos o get-mailbox de uma conta que foi migrada com sucesso vs. a que está falhando e encontramos uma diferença na configuração abaixo (opção “Compare” do Office Word):

HiddenFromAddressListsEnabled : True

Se o objeto está “Hidden”, logo o Exchange Online não conseguirá efetuar o move via Outlook Anywhere :).

Após esta alteração, efetuamos um novo batch de migração para o usuário, desta vez com sucesso.

1) Install AzureAD and AzureADPreview and connect into them and Connect on MsolService too
Install-Module azuread
Install-Module azureadpreview
Connect-AzureAD
Connect-MsolService
2) Check your tenant is allowed to create groups:
Get-MsolCompanyInformation | fl UsersPermissionToCreateGroupsEnabled

3) You need to have a security group, which members will have the capability to create new groups:
New-MsolGroup
ObjectId DisplayName GroupType Description
-------- ----------- --------- -----------
465439e2-7ffb-4ea7-b778-33a65e65daee Security

Set-MsolGroup -ObjectId 465439e2-7ffb-4ea7-b778-33a65e65daee -DisplayName AllowedGroupCreation
Get-MsolGroup -SearchString allowed

4) Get and save your custom template, based on the existing template based on the “Unified Groups”:
$template = Get-AzureADDirectorySettingTemplate | Where-Object {$_.displayname -eq "Group.Unified"}

5) Save the settings extracted from this custom template:
$setting = $template.CreateDirectorySetting()

6) Modify this custom settings, so now we don’t allow users to create groups, and stamp your MSOLgroup ObjectID:
$setting["EnableGroupCreation"] = "false"
$setting["GroupCreationAllowedGroupId"] = "465439e2-7ffb-4ea7-b778-33a65e65daee"

7) Now you can create the new Azure Setting, that will apply to the whole tenant, based on your custom settings created in previous steps 4 and 5:
New-AzureADDirectorySetting -DirectorySetting $setting

8) Test with a user in Outlook to see if the button to create group is gone

Olá Pessoal,
Tivemos um caso no suporte onde o cliente queria validar se as politicas de retenção criadas estão corretas no Centro de Conformidade e Segurança do Office 365

Então tivemos as seguintes perguntas:
1 - Como validar se minha organização possui política de retenção configurada para cada workload a partir do Centro de Conformidade e Segurança do Office 365 ?
2 - Como validar se a política de retenção está ativa na organização?
3 - Como confirmar se há exceção por usuário?

• O resultado do primeiro comando indica que há InPlaceHold aplicado a nivel de organização que precede as politicas de usuario
PS C:\Users\Vinicius> Get-OrganizationConfig | Fl *hold*
MailTipsLargeAudienceThreshold : 25
SCLJunkThreshold : 4
InPlaceHolds : {mbx02f024e2f88f4358a0bba395a1a5652f:2, grp02f024e2f88f4358a0bba395a1a5652f:2}

• Mesmo que nao vejamos nenhum InPlaceHold atribuido diretamente ao usuario pois como disse a politica aplicada a nivel de organização precede as politicas aplicadas a usuario
PS C:\Users\Vinicius> Get-Mailbox -Identity mago | FL *hold*
LitigationHoldEnabled : False
RetentionHoldEnabled : False
EndDateForRetentionHold :
StartDateForRetentionHold :
LitigationHoldDate :
LitigationHoldOwner :
ComplianceTagHoldApplied : False
DelayHoldApplied : False
LitigationHoldDuration : Unlimited
SCLDeleteThreshold :
SCLRejectThreshold :
SCLQuarantineThreshold :
SCLJunkThreshold :
InPlaceHolds : {}

• Sem o switch -DistributionDetail veja que o status é exibido como pending no exemplo e logo abaixo com o switch inserido no comando veja que o status é success
O que vale aqui é com o switch -DistributionDetail !

• No exemplo abaixo temos a indicação que há duas politicas aplicadas a nivel de organização:
PS C:\Users\Vinicius> Get-OrganizationConfig | FL inplaceholds
InPlaceHolds : {mbx02f024e2f88f4358a0bba395a1a5652f:2, grp02f024e2f88f4358a0bba395a1a5652f:2}

OBS: aqui as politicas estão sendo aplicadas a caixas de correio (sigla mbx no começo do id) e a Office 365 Groups (sigla grp no começo do id), caso voce aplique ao Sharepoint, Skype, etc… outras siglas serão exibidas aqui antes do id.

• Se o resultado do comando ‘Get-OrganizationConfig | FL inplaceholds’ no parametro InPlaceHolds nao traz nada populado ( Ex: InPlaceHolds : {} ) então não há nenhuma politica aplicada a nivel de organização

• Na questão do usuario é diferente pois mesmo se vermos que o parametro InPlaceHolds nao traz nada populado no resultado do Get-Mailbox isso não quer dizer que não há nenhuma politica aplicada a ele, o que quer dizer é que não há nenhuma politica aplicada diretamente a ele. Ex:

PS C:\Users\visipo\OneDrive - Microsoft\Scripts> Get-Mailbox -Identity mago | FL inplaceholds
InPlaceHolds : {}

• Nesse exemplo o usuario ‘mago’ nao tem nenhuma politica aplicada diretamente a ele, mas como as politicas da organização tem precedencia então tal regra é aplicada a ele pois ele herda a herança de politicas da organização

• Fiz um exemplo aqui onde adicionei uma exceção ao usuario Bruno onde o adicionei na opção ‘exclude recpients’

• E pode-se ver a exceção do usuario no comando a nivel de organização no exemplo abaixo exibindo que a regra está para a All com exceção do usuario Bruno, na mailbox do mesmo será exibido o resultado da politica com um sinal de menos ( - )
PS C:\Users\Vinicius> Get-RetentionCompliancePolicy -DistributionDetail | FL *ex*,dis*
SharePointLocationException : {}
ExchangeLocation : {All}
ExchangeLocationException : {Bruno Duarte Sipoli}
SkypeLocationException : {}
ModernGroupLocationException : {}
OneDriveLocationException : {}
ExternalIdentity :
ExchangeVersion : 0.20 (15.0.0.0)
DistributionStatus : Success
DistributionResults : {}
DistinguishedName : CN=reter por 90 dias,CN=Configuration,CN=sipoli.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=FFO,DC=extest,DC=microsoft,DC=com

PS C:\Users\Vinicius> Get-Mailbox -Identity bruno | FL inplaceholds
InPlaceHolds : {-mbx02f024e2f88f4358a0bba395a1a5652f}

• Então resumidamente as perguntas foram respondidas assim

---------------------------------------------------------------------------------------------------------
1 - Como validar se minha organização possui política de retenção configurada para cada workload a partir do Centro de Conformidade e Segurança do Office 365 ?
Comando:
Get-OrganizationConfig | FL InPlaceHolds

Resultados:
InPlaceHolds : {} -> Se vazio, não há política configurada;
InPlaceHolds: {mbx (…)} -> Significa que há política aplicada a objetos do tipo caixas de correio (mailboxes), salvo em casos de exceção.
InPlaceHolds: {grp (…)} -> Significa que há política aplicada a objetos tipo grupo, salvo em casos de exceção

2 - Como validar se a política de retenção está ativa na organização?
Comando:
Get-RetentionCompliancePolicy -DistributionDetail | FL

Resultados:
DistributionStatus: Success -> Significa que a política de retenção está ativa;
DistributionStatus: Failed -> Significa que não há uma política de retenção ativa
DistributionStatus: Pending -> Significa que a política de retenção está pendente de ser aplicada.

OBS:
Baseado na validação do ítem dois, todos os usuários herdarão a política definida em nível de organização.
Os usuários apenas não herdarão a política global (da organização) se explicitamente, tivermos uma exceção estampada

3 - Como confirmar se há exceção por usuário?
Comando:
Get-RetentionCompliancePolicy -DistributionDetail | FL exchange*,dis*

Resultados:
ExchangeLocation : {All}
ExchangeLocationException : {UserName}

OBS:
O resultado acima informa que apenas o usuário “UserName” possui exceção de retention, logo, não recebe a política da organização.
Evidente, caso tivéssemos outros usuários, eles constariam na resposta do campo “ExchangeLocationException”
---------------------------------------------------------------------------------------------------------
Você pode ter mais informações no artigo abaixo também sobre tais politicas:
Visão geral de políticas de retenção

Na última semana, recebemos um caso muito interessante, o cliente criou algumas etiquetas(labels) no Azure Information Protection (AIP), e precisava identificar anexos em mensagens que estivessem com labels internos e a mensagem tivesse sido enviado para destinatários fora da organização como por exemplo Hotmail.com.

A propriedade que armazena o label do AIP é MSIP_Label_<GUID>_Enabled=True, onde <GUID> é o ID do label que foi adicionado ao arquivo, e será alterado de acordo com o label que desejamos identificar nos arquivos anexados a mensagem através da regra de transporte, e, para obter este label basta executar o comando Get-AIPFileStatus, abaixo segue o exemplo:

PS C:\Users\robsons\Documents> Get-AIPFileStatus "INTERNAL DOCUMENT.docx"


FileName        : C:\Users\robsons\Documents\INTERNAL DOCUMENT.docx
IsLabeled       : True
MainLabelId     : fcfefb29-28fb-463f-9b1d-2a89533fff91
MainLabelName   : Internal
SubLabelId      :
SubLabelName    :
LabelingSiteId  : b3f9bf4c-6b71-467d-81b2-d4e86150d0c0
Owner           : robsons@robsons.msftonlinerepro.com
LabelingMethod  : Manual
LabelDate       : 6/26/2018 11:49:44 AM
IsRMSProtected  : True
RMSTemplateId   : 91dcc681-31fa-461a-8768-b7258b5b61ae
RMSTemplateName : Internal
RMSIssuedTime   : 6/26/2018 11:50:00 AM
RMSOwner        : robsons@robsons.msftonlinerepro.com
RMSIssuer       : robsons@robsons.msftonlinerepro.com 

Esse ID também pode ser obtido através do portal do Azure – Azure Information Protection – Labels – clique no label que seja identificar o ID, e ele aparecerá como Label ID ao final das configurações do Label:

Agora que já temos o ID do label que desejamos identificar em anexos de mensagens através de regras de transporte, vamos a construção da regra:

1. Em um navegador web, usando sua conta de global administrator, acesse o Office 365.
2. Escolha Admin
3. No portal de Administração do Office 365 escolha Admin Centers > Exchange.
4. No Portal de Administração do Exchange : mail flow > + > Create a new rule.
5. No nome da regra digite algo para identificar facilmente sua regra como “Detecta Label “Interno”
6. Em Apply this rules if: Selecione The Recipient is located, selecione Outside the Organization, e então selecione OK.
7. Selecione More options, e então selecione add condition.
8. Selecione Any attachment, e então selecione has these properties, including any of these words
9. Selecione + > Specify a custom attachment property.
10. Para Property, digite MSIP_Label_fcfefb29-28fb-463f-9b1d-2a89533fff91_Enabled
11. Para Value, digite True
12. Selecione Save, e em seguida, selecione OK.
13. Em Do the following selecione Delete the message without notifying anyone
14. Clique em Save.

Sua regra será parecida com a seguinte regra:

Em meu caso decidi deletar a mensagem sem notificar ninguém por se tratar de um anexo contendo um label interno o qual não deseja que seja enviado para destinatários fora de minha organização.

1- Hi Folks, we got a case somedays ago where the admin wanted to move the mailbox of user that is hosted in cloud (Exchange Online) to OnPrem environment
2- They commented with us they cannot move back the user in cloud to onprem because of the error below presented on Powershell connected to Exchange Online in order to try move the mailbox cloud -> onprem
PS C:\Windows\system32> Get-Mailbox -Identity name.lastname@domain.com | New-MoveRequest -OutBound -RemoteTargetDatabase 'ExchangeLocalDatabase' -RemoteHostName 'mail.domain.onmicrosoft.com' -RemoteCredential $OnPremAdminCred -TargetDeliveryDomain 'domain.com'
Cannot find a recipient that has mailbox GUID 'c4c85e6e-bc47-4e12-adc8-67bce80dd7b6'.
+ CategoryInfo : NotSpecified: (:) [New-MoveRequest], RemotePermanentException
+ FullyQualifiedErrorId : [Server=CY4PR12MB1574,RequestId=fe527a05-bea2-431d-8775-8905a20515ff,TimeStamp=XX/XX/XXXX - X:XX:XX p.m.] [FailureCategory=Cmdlet-RemotePermanentException] 81AD4932,Microsoft.Exchange.Management.Migration.MailboxReplication.MoveRequest.NewMoveRequest
+ PSComputerName : outlook.office365.com

PS C:\Windows\system32>

3- We told them this is because the mailboxes are different since they duplicated it and the local AD (we will not comment why they duplicated, but one of most causes of dups is assign a license to cloud user with a current mailbox on OnPrem that is not synced with all attributes through all DCs in local AD) user don’t have the guid filled in msExchMailboxGuid attribute in local AD with same value of guid that we see in error, but it seems easy if we just copy and paste the guid on error (c4c85e6e-bc47-4e12-adc8-67bce80dd7b6) to the attribute in local AD, the problem here is because that attribute doesn’t accept the guid as it is, we have to fill it as Hexadecimal, Binary, Decimal or Octal.
4- So we will need to do a conversion to proceed, here is the trick that the engineer Agustin Gallegos show to us:

a. Sample EXO Guid: c4c85e6e-bc47-4e12-adc8-67bce80dd7b6
b. Split the value in pairs: c4 c8 5e 6e - bc 47 - 4e 12 - ad c8 - 67 bc e8 0d d7 b6
c. First 4 pairs, you need to invert the order: c4 c8 5e 6e >> 6e 5e c8 c4
d. Invert next 2 pairs as well: bc 47 >> 47 bc
e. Invert next 2 pairs as well: 4e 12 >> 12 4e
f. Leave the rest of the GUID as it is: ad c8 67 bc e8 0d d7 b6
g. New on-premises HEXA value is: 6e 5e c8 c4 47 bc 12 4e ad c8 67 bc e8 0d d7 b6
h. Go and insert the value on msExchMailboxGuid attribute of the expected user as Hexadecimal

5- after insert the value into msExchMailboxGuid run a delta sync in your AADConnect Server (Start-ADSyncSyncCycle -PolicyType Delta) and run the same cmdlet to move mailbox again
6- And also I have to remember you this is a workaround when you are sure there is nothing else that will be impacted with this change, use at your own risk.

By: Caio Ribeiro César, Fabio Baleizão e João Domingues

Este post faz referência ao artigo “Search-UnifiedAuditLog”.

Ao coletar dados de auditoria utilizando o Search-UnifiedAuditlog, ou até o portal de gerência do Security & Compliance Center (SCC), alguns administradores se perguntam como é feita a leitura do log.

No exemplo abaixo, temos as informações necessárias para entender –

1) Quem efetuou o comando Remove-MailboxPermission;

2) Para qual Mailbox este comando foi executado;

3) Qual delegate esta permissão foi removida.

Será que você consegue identificar os 3?

Para ficar mais fácil, vamos ver o mesmo resultado no PowerShell para outro comando (Add-MailboxPermission):

Search-UnifiedAuditLog -RecordType ExchangeAdmin -StartDate 7/19/2018 -EndDate 7/20/2018 -Operations "Add-MailboxPermission" | fl

RunspaceId   : bed7251c-2c12-461b-8254-9d833aff33b7

RecordType   : ExchangeAdmin

CreationDate : 7/19/2018 9:24:53 AM

UserIds      : Admin@tplisbon202202.onmicrosoft.com

Operations   : Add-MailboxPermission

AuditData    : {"CreationTime":"2018-07-19T09:24:53","Id":"185dd1ef-7a09-451d-7733-08d5ed597bf5","Operation":"Add-MailboxPermission","OrganizationId":"3880fe49-d569-49f4-8a2c-112282572473","RecordType":1,"ResultStatus":"Tru           e","UserKey":"10033FFFA233BA3C","UserType":2,"Version":1,"Workload":"Exchange","ClientIP":"193.126.243.78:24225","ObjectId":"Teste,"UserId":"Admin@tplisbon202202.onmicrosoft.com","ExternalAccess":false,"OrganizationName":"tplisbon202202.onmicrosoft.com","OriginatingServer":"VI1PR0801MB1632 (15.20.0973.010)","Parameters":[{"Name":"Identity","Value":"Teste1"},{"Name":"User","Value":"EURPR08A005\\clou55083"},{"Name":"AccessRights","Value":"FullAccess"},{"Name":"InheritanceType","Value":"All"}],"SessionId":""}

ResultIndex  : 2

ResultCount  : 2

Identity     : 185dd1ef-7a09-451d-7733-08d5ed597bf5

IsValid      : True

ObjectState  : Unchanged

Quem executou o comando? Este objeto está identificado no valor “UserID” - Admin@tplisbon202202.onmicrosoft.com

Qual a mailbox em questão (mailbox que o add-mailboxpermission foi executado)? Este objeto está identificado no valor “ObjectID” – teste

Qual delegate esta permissão foi concedida? Este objeto está identificado no valor “User” - EURPR08A005\\clou55083

“EURPR08A005\\clou55083” é o sAMAccountName do usuário que a permissão de FullAccess foi concedida. Para que o Administrador possa validar qual seria o objeto, basta executar o comando Get-User.

Get-User "clou55083”

By: Caio Ribeiro César, Edgar Gonzalez

Cada dia que passa no suporte, lembramos da regra número um em troubleshooting – Keep it Short and Simple (KISS).

Em um cenário que o Administrador não estava conseguindo exportar os dados via eDiscovery PST Export Tool, nosso instinto inicial foi executar o plano de ação discutido em um post anterior (EDiscovery PST Export – coleta de dados e análise para troubleshooting).

Os passos do artigo ajudaram para a análise, porém algo mais simples poderia ter resolvido o problema de maneira mais rápida – Scoping.

O processo de Scoping já resolveu diversos problemas em suporte (e até nas nossas rotinas de vida). Scoping basicamente discute o cenário em questões que irão abranger a natureza do problema – recomendamos um artigo da MS para um detalhamento melhor de Scoping (First Step in troubleshooting complex issues – Define and scope your issue propely).

Vamos ao cenário. Administrador com RBAC permissions de eDiscovery informa não conseguir exportar os dados pst algumas mailboxes específicas com o erro “object reference not set to an instance of an object”:

O mesmo administrador, para outras mailboxes, consegue efetuar o procedimento. Coletamos o Fiddler trace discutido no artigo acima mencionado, com a informação abaixo:

User-Agent: Exchange\15.20.0952.024\EDiscovery\EWS\

MailboxSearchScopes><t:MailboxSearchScope><t:Mailbox>Caio Cesar</t:Mailbox><t:SearchScope>All</t:SearchScope></t:MailboxSearchScope></t:MailboxSearchScopes></t:MailboxQuery></t:SearchQueries><t:ResultType>PreviewOnly</t:ResultType><t:ItemCount>0</t:ItemCount><t:Size>0</t:Size><t:PageItemCount>0</t:PageItemCount><t:PageItemSize>0</t:PageItemSize><t:FailedMailboxes><t:FailedMailbox><t:Mailbox>

/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=af6396c2a11231231239804c2eb21f05f0d-Caioc</t:Mailbox><t:ErrorCode>0</t:ErrorCode><t:ErrorMessage>The mailbox recipient type is not supported.</t:ErrorMessage><t:IsArchive>false</t:IsArchive></t:FailedMailbox></t:FailedMailboxes></m:SearchMailboxesResult></m:SearchMailboxesResponseMessage></m:ResponseMessages>

Assim que recebemos o erro “The mailbox recipient type is not supported“ via coleta de dados Fiddler, visualizamos o status da conta. A conta em si não era uma mailbox, pois não possuía licenciamento atribuído.

A conta deve ser uma mailbox e possuir uma licença válida para que o export possa ser efetuado.

You'll need an active mail account attached to the account you wish to export.

Pingback de https://techcommunity.microsoft.com/t5/Security-Privacy-and-Compliance/Exchange-Mailbox-Auditing-will-be-enabled-by-default/ba-p/215171

Nossas preces foram ouvidas! Após diversos feedbacks e sugestões, a Microsoft irá trazer a funcionalidade de Mailbox Audit Habilitada por default nas mailboxes!

Isto significa que administradores terão mais informações em um cenário comum em suporte - emails sumiram ou foram movidos sem ter que habilitar a funcionalidade manualmente.

Além de habilitar mailbox audit para as mailboxes que ainda não possuem a funcionalidade habilitada, iremos expandir os tags de audit que estão configurados para as mailboxes que já possuem audit.

Quando a Microsoft irá habilitar esta funcionalidade?

Nos meses seguintes, iremos efetuar em etapas para todos os tenants do mundo. Nenhuma ação será necessária por parte do administrador, porém eu recomendo não fechar esta janela do browser ainda já que irei discutir um pouco o impacto da alteração =)

Impacto

Como podem entender, a Microsoft demorou um tempo para efetuar esta alteração de comportamento do produto. A resposta é simples - storage. Adicionar logging em todas as mailboxes do mundo requer espaço.

O impacto para o administrador é inexistente.

a) Logging de mailbox audit, mesmo com o Owner habilitado, não ultrapassa GBs de Storage. Lembrando que ele irá utilizar o RecoverableItemQuota de cada Mailbox , um pequeno Storage de 100GB (as entradas de Mailbox Audit são armazenadas na pasta "Audits" localizada em Recoverable Items).

b) Você pode monitorar o espaço de RecoverableItemQuota, caso o AuditLogAgeLimit seja aumentado para um valor maior de 90 dias e entender se existe algum API ou Delegate utilizando recursos da mailbox de tempos em tempos. Caso exista um crescimento elevado em storage pela parte de RecoverableItemQuota, recomendamos o Cmdlet Set-MailboxAuditBypassAssociation.

Caso queira, o comando "Set-OrganizationConfig -AuditDisabled $True" pode ser executado, para que nenhum objeto do tenant tenha auditoria habilitado - obviamente, não recomendamos tal ação.

Discussões anteriores sobre o tema:

O365 – How Mailbox Audit works in a Hybrid scenario

Exchange Online – o que esperar nas mudanças em Auditing

Office 365: Precisamos Falar Sobre Segurança

O365 Shared Mailbox Auditing – Melhores Praticas

Greetings everyone, in today’s article we will cover how to skip MFA for intranet users in Office 365, this can be achieved if you have or not a federated domain environment (ADFS).
We will not cover “Conditional Access” from AAD Premium suite in this article, but be aware this can be done through there too.

1- Lets make sure the required option is enabled in the MFA portal, select the option “Skip multi-factor authentication for requests from federated users on my intranet”:

2- The next step is to create or verify if the rule “Inside Corporate Network” is created for your O365 relaying party trust on your ADFS server.

On the RP properties click on “Add Rule” if the rule does not exist:

On the Add Transform Claim Rule Wizard, select “Pass Through or Filter an Incoming Claim” from the drop-down and click Next:

Name your rule and from the drop-down, next to “Incoming claim type”, select “Inside Corporate Network”:

Click “Finish” and “Ok” on the next page.

3- Test internally if the MFA will be skipped now.

4- If you don’t have a federated environment, you can add the company list of public IP into the field of “Skip multi-factor authentication for requests from following range of IP address subnets” of image in step 1.

Hope this clarifies how you can simply achieve this goal. Cheers!!!

Olá Pessoal,
Vimos alguns casos no suporte onde usuarios de dominios federados não conseguiam logar em suas contas ou criar um novo perfil do Exchange Online usando o aplicativo Outlook para Android e a mensagem exibida é somente "ocorreu um erro"

• O que acontece é que apesar do aplicativo ser desenvolvido por nós cada dispositivo gerencia suas requests/responses de maneira diferente e o Android é mais exigente na questão de certificados do serviço de federação
• Com isso os certificados root e intermediate não podem faltar em suas respectivas pastas como também nao podem estar inseridos em outras pastas, o correto é seguir essa ordem:

• Você pode verificar se o ceritficado publicado nos servidores WAP & ADFS se o endereço (exemplo: adfs.dominio.com.br) não contém corretamente o intermediate e root em suas pastas nos servidores que respondem pelo endereço usando alguns links como https://cryptoreport.websecurity.symantec.com/checker/ ou https://ssltools.digicert.com/checker/views/checkInstallation.jsp (você também pode usar qualquer outro site que verifique a cadeia de certificados no endereço que você inserir (você precisa inserir o endereço do seu serviço de federação que está publicado na internet).
Exemplo que pode ser exibido na consulta aos sites descritos acima:

adfs.dominio.com.br
You have 1 error
Intermediate certificate missing.
SHA2 Extended Validation Server CA | Download certificate

Intermediate certificate missing.
SHA2 Extended Validation Server CA | Download certificate

• Se você estiver enfrentando esse problema tome as ações de inserir o certificado nos servidores WAP e ADFS nas respectivas pastas corretas e reinicie os servidores.

• Documentado aqui está o contexto do que o erro de codigo 3 significa: https://developer.android.com/reference/android/net/http/SslError.html
SSL_UNTRUSTED
int SSL_UNTRUSTED
The certificate authority is not trusted
Constant Value: 3 (0x00000003)

• E aqui está o log do Outlook App analisado pelo time especialista em Outlook para Android onde consta o erro de codigo 3

D 2018-07-20T11:43:27.900+0000 [ci=lkZEpaox7M] main Office365LoginA Authentication error:Code:-11 primary error: 3 certificate: Issued to: CN=adfs.dominio.com.br,O=COMPANHIA DE TI,OU=MS,L=PARANA,ST=CuritibaC=BR;
Issued by: CN=Organization Validation CA - SHA256 - G2,O=nv-sa,C=BE;
on URL: https://adfs.dominio.com.br/adfs/ls/?login_hint=nome.sobrenome%40dominio.com.br&wfresh=0&wauth=http%3a%2f%2fschemas.microsoft.com%2fws%2f2008%2f06%2fidentity%2fauthenticationmethod%2fpassword&client-request-id=e416db57-b03b-44b4-b280-f33bee6a1592&username=nome.sobrenome%40dominio.com.br&wa=wsignin1.0&wtrealm=urn%3afederation%3aMicrosoftOnline&wctx=estsredirect%3d2%26estsrequest%3drQIIAa1RPW_TQBjO2YmBqlKrSoWOHaiEkOKPc9LmAyQcmbYCh5Cqbeqoi-_Oji-xfcaxL22m_gNQR8TEgtQJVQwI_kGnSCwIxMbUASGxMOL8B5ZXz7M8X--CpMkalNUVoN0Xc9i4C7fqEKpqpVyFVa1cUXW1jCAk5brmYlJ39C3XqSQrC8u977d_Nt9_MC_P_jR_DVfPL4AZjp0s9RuKglkohxQnbMy8VGaeR7ErsywNGBspHh7U1BectTW7_fRJn6Jha9LFpteJ2IZufgRgBsCZAM6FO56DKJMxcwOfPcLjSJ7romQmgG_CUsfIveD8sIRO3WuhFLABjV6Lx_a-xsju3gRPGbfgCe_DILMiEqNwjxO9naHwULXgM456Gke0f_q856tktzXt0Bq3j1qxFW4PEdQmaGeU2bCeWvCwYkPfRyEJLsR1P03jcV7Sians5InigM6DKe4J9p1o4F6KUk5DFn0VwawIrouLN8Hy4lphvXBPUMHfInhbyud78HLtS_bux86bjc9LxeZq4aqknAZVVtsedDcNPWz3vGRz2g0PaqmixKbHjf2DxOCjhHDn6HH3YbWhvZLAlXTDiEjCKPktFT7d-i8P-Ac1 CorrelationId: e416db57-b03b-44b4-b280-f33bee6a1952

Uma mensagem de erro é exibida ao tentar criar uma nova reunião através do Outlook para iOS.

“Send Meeting Request Failed. Your meeting request '<Meeting Subject>' failed to send. Please contact support for assistance.”

Adicionalmente, a exceção a seguir é registrada no log do Exchange ActiveSync para este dispositivo:

SyncCommand_ConvertRequestsAndApply_Add_Exception :
Microsoft.Exchange.AirSync.SchemaConverter.Common.ConversionException: ExTimeZoneFromRegTimeZoneInfo failed: Specified argument was out of the range of valid values.
Parameter name: Hour
   at Microsoft.Exchange.AirSync.SchemaConverter.Common.TimeZoneConverter.GetExTimeZone(Byte[] timeZoneInformation)
   at Microsoft.Exchange.AirSync.SchemaConverter.XSO.XsoTimeZoneProperty.InternalCopyFromModified(IProperty srcProperty)
   at Microsoft.Exchange.AirSync.SchemaConverter.XSO.XsoDataObject.CopyFrom(IProperty srcRootProperty)
   at Microsoft.Exchange.AirSync.SyncCollection.ConvertClientToServerObjectAndSendIfNeeded(SyncCommandItem syncCommandItem, Boolean sendEnabled)
   at Microsoft.Exchange.AirSync.SyncCollection.ConvertClientToServerObjectAndSave(SyncCommandItem syncCommandItem, UInt32& maxWindowSize, Boolean& mergeToClient)
   at Microsoft.Exchange.AirSync.SyncCommand.ConvertRequestsAndApply(SyncCollection collection)

Nota: Esse problema afeta os usuários do fuso horário Brasília (UTC-03:00) e é limitado ao Outlook para iOS usando o protocolo ActiveSync. Os usuários hospedados no Office 365 usam o protocolo REST e não são afetados por esse problema.

Este problema ocorre porque o valor do atributo TimeZone na requisição de sincronismo é inválido.

O problema foi corrigido no código do Outlook e estará disponível na próxima atualização do aplicativo.

É possível contornar o problema alterando o fuso horário no iOS, porém tenha em mente que isso poderá afetar os convidados da reunião uma vez que o horário final estará errado.

Recomendamos utilizar o aplicativo nativo ou o cliente Web para gerenciar o calendário até que a correção esteja disponível.

By: Marcela Chitiva Peñaloza. SharePoint Online Support Engineer.

Microsoft Stream —the intelligent video service in Office 365— makes it easy to create, securely share, and interact with video, whether in a team or across your organization. If you have any of these licenses (click here for more details) you can start to use Microsoft Stream.

Some tenants (with plans including Stream) may not have enabled the feature and do not see the Stream tile into the App Launcher, even logging in to Stream portal, appears the following message:

“AADSTS70001: Application 'cf53fce8-def6-4aeb-8d30-b158e7b1cf83' is disabled”

For solve this issue, connect to your Office 365 organization using Office 365 PowerShell (click here for download it)

Run the following commands:

Wait a couple of minutes and try again the login process going to https://web.microsoftstream.com

Nos últimos dias recebemos a notícia que o início do horário de verão poderá ser postergado para o dia 18 de Novembro. A partir desta comunicação, a nova configuração de horário de verão ficou definido para:

Inicio do Horário de verão:18 de Novembro de 2018 (Terceiro domingo de novembro)

Fim do Horário de verão finaliza:17 de fevereiro de 2019 (Terceiro domingo de fevereiro)

A fim de alcançar uma transição perfeita das políticas para a possível alteração do início do horário de verão, e permitir tempo suficiente para implementar as mudanças em produtos e serviços, a Microsoft respeitosamente solicita aos governos que considerem em fornecer, com pelo menos 1 ano de antecedência, o aviso de confirmação oficial do horário de verão (DST) e as mudanças planejadas.

Essa também é a recomendação da IANA

https://data.iana.org/time-zones/tz-link.html

"If your government plans to change its time zone boundaries or daylight saving rules, inform tz@iana.org well in advance, as this will coordinate updates to many cell phones, computers, and other devices around the world. With less than a year's notice there is a good chance that some computer-based clocks will operate incorrectly after the change, due to delays in propagating updates to software and data. The shorter the notice, the more likely clock problems will arise; see "On the Timing of Time Zone Changes" for examples."

Neste momento não há nenhuma publicação oficial (decreto) do governo brasileiro de que o início do horário de verão será alterado. Portanto, qualquer orientação pública oficial ou a eventual correção sobre como acomodar as mudanças de horário de verão nos produtos Microsoft não serão tornados públicos neste momento.

O decreto atual ainda informa a data de 04 de Novembro como início do Horário de verão.

https://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm

Se a data de início do horário de verão for alterada oficialmente, nosso serviço de assistência e equipes de suporte estarão prontos para ajudar nossos clientes em relação a esta mudança. Assim, após a confirmação oficial do governo brasileiro sobre a alteração ou não do início do horário de verão, a Microsoft publicará uma orientação completa aos clientes.

Mais informações sobre configurações de horário de verão no Windows:

Blog Oficial do time de DST (Daylight Saving Time) da Microsoft

https://blogs.technet.microsoft.com/dst2007/

How to configure daylight saving time for Microsoft Windows operating systems

https://support.microsoft.com/en-us/help/914387/how-to-configure-daylight-saving-time-for-microsoft-windows-operating

O governo federal decidiu manter o início do horário de verão para o dia 4 de novembro, quando os relógios serão adiantados em uma hora em vários estados do País. A partir desta comunicação, a configuração do horário de verão fica definida como:

Inicio do Horário de verão: 04 de Novembro de 2018 (Primeiro domingo de novembro) - Adiado em duas semanas, do dia 21/10 para 04/11 pelo decreto abaixo.
Fim do Horário de verão finaliza: 17 de fevereiro de 2019 (Terceiro domingo de fevereiro)

Decreto Oficial com as datas de horário de verão:
https://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm

Portanto, as atualizações referentes ao início de horário de verão permanecem as mesmas já disponibilizadas desde abril.

Em Abril/18, a Microsoft liberou as atualizações para que as diversas versões de sistemas operacionais suportadas tivessem esta atualização implementada.

Time zone and DST changes in Windows for Brazil, Morocco, and São Tomé and Príncipe
https://support.microsoft.com/en-us/help/4093753/time-zone-and-dst-changes-in-windows-for-brazil-morocco-and-sao-tome-a

A tabela abaixo descreve quais foram os primeiros Monthly Quality Rollups que contem a atualização do horário de verão do Brasil. Como esses Monthly Quality Rollups são cumulativos, qualquer rollup mais recente que esses abaixo contemplam a correção:

• Lembrando que os KBs que são Security-only não contém as alterações de horário de verão.
• O Windows Server 2008 SP2 não tem Monthly Quality Rollups, por esse motivo a única opção é instalar os KBs avulsos abaixo.

Além dos Monthly Quality Rollups descritos na tabela acima, os sistemas operacionais Windows Server 2008 até 2012 R2 e Windows client 7 até 8.1 tem a opção de instalar os KBs individuais abaixo:

KB4093753 (Lançado 16/04/2018)
KB4130978 (Lançado 17/05/2018 – substitui o KB 4093753)
KB4339284 (Lançado 24/07/2018 – substitui o KB 4130978)

As mudanças do KB4093753, já foram incluidas nos Monthly Quality Rollups mais recentes, por isso é esperado que você receba mensagens de que o KB avulso não é aplicável caso a máquina já possua os Monthly Quality Rollups mais recentes.

Uma forma simples de identificar se a máquina já possui a correção é com o comando w32tm /tz .O comando exibe a diferença do valor antigo (M:10 D:3), para o novo (M:11 D:1):

Antes do KB instalado:
C:\>w32tm /tz
Time zone: Current:TIME_ZONE_ID_STANDARD Bias: 180min (UTC=LocalTime+Bias)
[Standard Name:"E. South America Standard Time" Bias:0min Date:(M:2 D:3 DoW:6)]
[Daylight Name:"E. South America Daylight Time" Bias:-60min Date:(M:10 D:3 DoW:6)]

Após KB instalado:
C:\>w32tm /tz
Time zone: Current:TIME_ZONE_ID_STANDARD Bias: 180min (UTC=LocalTime+Bias)
[Standard Name:"E. South America Standard Time" Bias:0min Date:(M:2 D:3 DoW:6)]
[Daylight Name:"E. South America Daylight Time" Bias:-60min Date:(M:11 D:1 DoW:6)]

Informações adicionais:
A data crítica nessa mudança de horário de verão será o dia 21/10/2018. Os clientes que não instalarem nenhum KB descrito acima, terão o horário de servidores e estações incorretamente adiantados em uma hora na virada do Sábado para o Domingo dia 21/10/2018, pois era a data que o horário de verão estava programado para começar antes do decreto de Dez/2017.

https://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm