Quantcast
Channel: LATAM Support Blog
Viewing all 98 articles
Browse latest View live

restrict the Office 365 groups creation on Outlook (en-us)

$
0
0

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


Como validar se minha organização possui política de retenção configurada a partir do Centro de Conformidade e Segurança do Office 365 ?

$
0
0

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

Exchange Online – Como detectar anexos em mensagens com “Azure Information Protection Labels” utilizando regras de transporte do Exchange.

$
0
0

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.

Move mailbox offboard (Cloud to OnPrem) fails with “Cannot find a recipient that has mailbox GUID ‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’.”

$
0
0

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.

Exchange Online – Coletando e lendo logs de Auditoria para Full Mailbox Permission

$
0
0

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”

Exchange Online – Não é possível exportar dados pst (Ediscovery) com erro “object reference not set to an instance of an object”

$
0
0

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.

Exchange Online – Melhorias em Mailbox Auditing

$
0
0

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

 

Skip MFA for intranet users in Office 365

$
0
0

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- Teste 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!!!


Usuários não conseguem se logar ou criar um novo perfil usando o Outlook app para Android

$
0
0

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

Não é possivel criar nova reunião através do aplicativo do Outlook para iOS

$
0
0

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.

Office 365 e Active Directory: como os atributos msExchRecipientDisplayType, msExchangeRecipientTypeDetails e msExchRemoteRecipientType são relacionados no ambiente local

$
0
0

Olá Pessoal,

Temos visto muitos casos no suporte onde antes de migrar a mailbox localizada no Exchange OnPremises (seja ele 2010, 2013, 2016 ou 2019) o administrador já assinala uma licença para aquele usuario sincronizado.

Quando você assinala uma licença de Exchange Online ao usuário, uma nova mailbox é provisionada na nuvem - caso ainda não haja nenhuma. Isso faz com que muitas vezes a caixa de correio deste usuário fique duplicada (sendo uma na nuvem e uma mailbox no ambiente OnPremises).

O cenário de mailbox duplicada configura um administrador que faz a migração neste cenário. Geralmente, após a migração, o usuário reclama que não localiza nenhuma mensagem, então nesse momento o administrador entre em contato com o time de suporte.

Abaixo, temos uma lista de atributos que ficam no AD local que fazem referencia (ou não) com uma caixa na nuvem. Conforme já conversamos em outro post, o comportamento do autodiscover é utilizar um atributo (TargetAddress) para popular no Exchange local o valor de RemoteRoutingAddress da mailbox - se tal atributo não contem um endereço valido ex: usuario@dominio.onmicrosoft.com , a mailbox não será localizada.

Para isolar o problema de mailbox duplicada, utilizamos o OWA local (ex: https://mail.seudominio.com/owa) e também o OWA do Office365 (https://outlook.office365.com/owa) para visualizar se as mensagens contidas estão diferentes - caso você não consiga efetuar acesso, isso pode indicar que a caixa não está provisionada/habilitada na nuvem ou no local (OnPrem).

Caso o usuario visualize as mensagens corretamente usando o OWA do Office 365 mas não visualiza tais mensagens corretamente no OWA local, você pode então alterar alguns atributos para que o apontamento seja feito para a mailbox localizada na nuvem, - lembrando sempre de ter um backup/ldap dump do usuario no AD antes de realizar qualquer alteração.

Esta alteração consiste em alterar os seguintes campos como mostra o exemplo abaixo indicando uma caixa migrada:

homeMDB -> esse atributo indica ao AD local um banco de dados, se tiver algo populado aqui então sabemos que esse usuário tem a indicação de um banco de dados local;

homeMTA -> esse atributo indica por sua vez um MailTransferAgent local também e caso esteja populado teremos a indicação de fluxo de e-mail realizado por servidores locais;

MsExchMailboxGuid -> a identificação única da caixa de correio este valor deve ser o mesmo entre OnPremises e OnCloud;

msExchHomeServerName -> indica onde a caixa do usuário está hospedada localmente, novamente se tivermos um valor aqui então sabemos que há um servidor local hospedando a caixa;

msExchRecipientDisplayType -> [verifique os valores adequados no diagrama abaixo]

PSC: lembrando que alterar o atributo msExchRecipientDisplayType direto pelo AD local não é algo suportado.

msExchRecipientTypeDetails -> [verifique os valores adequados no diagrama abaixo]

msExchRemoteRecipientType ->  [verifique os valores adequados no diagrama abaixo]

msExchVersion -> indica qual é a versão atual do Microsoft Exchange;

ProxyAddresses -> smtp:name.lastname@domain.onmicrosoft.com

smtp:name.lastname@domain.mail.onmicrosoft.com

targetAddress -> smtp:name.lastname@domain.onmicrosoft.com -> esse é o endereço do usuário com referencia na nuvem para o AD local, o autodiscover irá procurar o endereço contido aqui caso esse atributo tenha algum valor inserido, sempre deve ser algo como @dominio.onmicrosoft.com ou @dominio.mail.onmicrosoft.com para que o redirect do autodiscover encontre o usuário na nuvem.

Um exemplo de como ficaria um usuário que foi criado no ad local, sincronizado com a nuvem e teve sua caixa migrada do Exchange local para o Exchange Online:

homeMDB -> sem valor

homeMTA -> sem valor

MsExchMailboxGuid -> unique identifier, mesmo valor entre o objeto onpremises e online;

msExchHomeServerName -> sem valor

msExchRecipientDisplayType -> -2147483642

msExchRecipientTypeDetails -> 2147483648

msExchRemoteRecipientType -> 4

msExchVersion -> 44220983382016

ProxyAddresses -> smtp:name.lastname@domain.onmicrosoft.com

smtp:name.lastname@domain.mail.onmicrosoft.com

targetAddress -> smtp:name.lastname@domain.onmicrosoft.com

Abaixo temos a tabela de valores para msExchangeRecipientType. Lembrando que estes valores não devem ser alterados manualmente (apenas para informação):

 

Recipient Display Type

Value Name Value
MailboxUser 0
DistributionGroup 1
PublicFolder 2
DynamicDistributionGroup 3
Organization 4
PrivateDistributionList 5
RemoteMailUser 6
ConferenceRoomMailbox 7
EquipmentMailbox 8
ArbitrationMailbox 10
MailboxPlan 11
LinkedUser 12
RoomList 15
SecurityDistributionGroup 1073741833
ACLableMailboxUser 1073741824
ACLableRemoteMailUser 1073741830
SyncedUSGasUDG -2147481343
SyncedUSGasUSG -1073739511
SyncedUSGasContact -2147481338
ACLableSyncedUSGasContact -1073739514
SyncedDynamicDistributionGroup -2147482874
ACLableSyncedMailboxUser -1073741818
SyncedMailboxUser -2147483642
SyncedConferenceRoomMailbox -2147481850
SyncedEquipmentMailbox -2147481594
SyncedRemoteMailUser -2147482106
ACLableSyncedRemoteMailUser -1073740282
SyncedPublicFolder -2147483130

 

Recipient Type Details

Value Name RecipientTypeDetails (Decimal Value)
None 0
UserMailbox 1
LinkedMailbox 2
SharedMailbox 4
LegacyMailbox 8
RoomMailbox 16
EquipmentMailbox 32
MailContact 64
MailUser 128
MailUniversalDistributionGroup 256
MailNonUniversalGroup 512
MailUniversalSecurityGroup 1024
DynamicDistributionGroup 2048
PublicFolder 4096
SystemAttendantMailbox 8192
SystemMailbox 16384
MailForestContact 32768
User 65536
Contact 131072
UniversalDistributionGroup 262144
UniversalSecurityGroup 524288
NonUniversalGroup 1048576
DisabledUser 2097152
MicrosoftExchange 4194304
ArbitrationMailbox 8388608
MailboxPlan 16777216
LinkedUser 33554432
RoomList 268435456
DiscoveryMailbox 536870912
RoleGroup 1073741824
RemoteUserMailbox 2147483648
Computer 4294967296
RemoteRoomMailbox 8589934592
RemoteEquipmentMailbox 17179869184
RemoteSharedMailbox 34359738368
PublicFolderMailbox 68719476736
TeamMailbox 137438953472
RemoteTeamMailbox 274877906944
MonitoringMailbox 549755813888
GroupMailbox 1099511627776
LinkedRoomMailbox 2199023255552
AuditLogMailbox 4398046511104
RemoteGroupMailbox 8796093022208
SchedulingMailbox 17592186044416
GuestMailUser 35184372088832
AuxAuditLogMailbox 70368744177664
SupervisoryReviewPolicyMailbox 140737488355328

 

Remote Recipient Types

Decimal Value Hex Value Value Name
1 0x1 ProvisionedMailbox (Cloud MBX)
2 0x2 ProvisionedArchive (Cloud Archive)
3 0x3 ProvisionedMailbox, ProvisionedArchive (Cloud MBX & Cloud Archive)
4 0x4 Migrated
6 0x6 Migrated, ProvisionedArchive (Migrated MBX & Cloud Archive)
8 0x8 DeprovisionMailbox
16 0x10 DeprovisionArchive
20 0x14 DeprovisionArchive, Migrated
32 0x20 RoomMailbox
36 0x24 Migrated, RoomMailbox
64 0x40 EquipmentMailbox
68 0x44 Migrated, EquipmentMailbox
96 0x60 SharedMailbox
100 0x64 Migrated, SharedMailbox

Users cannot login in Stream, error: AADSTS70001: Application ‘cf53fce8-def6-4aeb-8d30-b158e7b1cf83’ is disabled

$
0
0

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 () 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


stream


For solve this issue, connect to your Office 365 organization using Office 365 PowerShell ()

Run the following commands:


Connect-MsolService

Import-Module MSOnlineExtended -Force

$MSP = Get-MsolServicePrincipal -AppPrincipalId “cf53fce8-def6-4aeb-8d30-b158e7b1cf83”

Set-MsolServicePrincipal -AppPrincipalId $MSP.AppPrincipalId -AccountEnabled $true



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

Mudanças no horário de verão no Brasil para 2018

$
0
0

Edit: O governo cancelou a alteração mencionada nesse post, com isso o início do horário de verão será dia 04 de Abril.
Mais informaçoes em https://blogs.technet.microsoft.com/latam/2018/10/17/horario-de-verao-no-brasil-inicia-em-04-de-novembro-de-2018-lista-de-kbs/

--------------------------------------------------------------------

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

 

 

Horário de verão no Brasil inicia em 04 de Novembro de 2018 (lista de KBs)

$
0
0

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:

OS Release Date Update Rollup KB
1809 - RS5 RS5 RTM RS5 RTM
1803 - RS4 2018.06 B KB4284835
1709 - RS3 2018.04 B KB4093112
1703 - RS2 2018.04 B KB4093107
1607 - RS1 2018.04 B KB4093119
1511 - TH2 2018.04 B KB4093109
Windows 2016 RTM 2018.04 B KB4093111
Windows server 2012 R2 / 8.1 2018.04 C KB4093121
Windows Server 2012 2018.04 C KB4093116
Windows Server 2008 SP2 N/A N/A
Windows Server 2008 R2 / 7 2018.04 C KB4093113
  • 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

 

Horário de verão no Brasil 2018 – Como isso afeta o calendário de clientes do Microsoft Exchange e Office 365

$
0
0

Sobre o horário de verão 2018:
==========================================

Conforme última atualização do decreto 6658, o horário de verão brasileiro está definido da seguinte forma:
Horário de verão inicia no primeiro domingo de novembro (dia 04) às 00:00:00
Horário de verão termina no terceiro domingo de fevereiro (dia 17) às 00:00:00
Para suportar estas alterações de horário de verão, a Microsoft disponibilizou desde abril de 2018 as atualizações para as versões de sistemas operacionais suportadas.
Segue abaixo o artigo oficial sobre a atualização;
#  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
* É possível que outras atualizações tenham substituído esta atualização. Consultar o site do Catalog para ver o último kb válido.



Como esta mudança afeta os clientes de Exchange / Office 365?
==========================================

Os clientes de correio trabalham de maneiras diferentes.
  • Outlook: irá utilizar a informação de fuso horário da máquina local para ajustar as reuniões. Se o Sistema Operacional estiver devidamente atualizado, o Outlook irá mostrar as reuniões com o horário correto.
  • OWA: O cliente OWA utiliza as informações de fuso horário do servidor. Isto significa que usuários do OWA necessitam que a atualização de fuso horário esteja aplicada em todos os servidores Exchange da organização.
  • ActiveSync: O ajuste dos compromissos no calendário dos dispositivos móveis dependem de atualização no S.O. do próprio dispositivo.
* Os servidores do Office 365 já estão atualizados com as últimas definições de horário de verão.



Informações adicionais
==========================================

Ao criar compromissos baseados em Exchange / Office 365, a solicitação da reunião inclui informações do horário de verão do organizador da reunião, ou seja, ao criar uma solicitação de reunião de uma estação de trabalho, o Outlook vai incluir o fuso horário do organizador e informações de quando o horário de verão começa e termina. Neste caso, mesmo que você tenha uma reunião recorrente que foi criada antes de sair a atualização do horário de verão, o cliente de correio tem que ser capaz de recalcular o horário do compromisso baseado nas informações atualizadas do SO da estação de trabalho ou servidor (dependendo do cliente utilizado).
Pode acontecer em alguns casos de compromissos seguirem com a data incorreta, principalmente no período Delta (período de alteração entre a antiga data de horário de verão e a nova data – neste ano de 2018 entre 21 de outubro a 03 de novembro), como se respeitasse o horário de verão de antes da atualização. Para estes casos o melhor é avaliar os compromissos individualmente, o maior motivo para isso acontecer é alguma propriedade do compromisso estar ausente ou corrompida, que pode gerar ainda resultados distintos para o mesmo compromisso se comparados em clientes diferentes como Outlook e OWA.
Para estes casos, a recomendação é rodar a ferramenta Calendar Checking Tool for Outlook (CalCheck) no calendário afetado.
https://www.microsoft.com/en-us/download/details.aspx?id=28786
A ferramenta irá gerar um relatório no formato *.csv. Verifique se o compromisso afetado está listado no relatório. Somente compromissos com erro aparecem no relatório.
Consulte o site abaixo para ver a relação dos erros e as respectivas soluções;
https://support.microsoft.com/en-us/help/2678030/information-about-the-calendar-checking-tool-for-outlook-calcheck


Para confirmar se a atualização do horário de verão foi aplicada no Windows, você pode utilizar o comando abaixo;
Antes do KB instalado:
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:
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)]



Artigos relacionados:
==========================================

# Decreto Oficial com as datas de horário de verão:
https://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm
# Horário de verão no Brasil inicia em 04 de Novembro de 2018 (lista de KBs)
https://blogs.technet.microsoft.com/latam/2018/10/17/horario-de-verao-no-brasil-inicia-em-04-de-novembro-de-2018-lista-de-kbs/
# How time zone normalization works in Microsoft Outlook
https://support.microsoft.com/en-us/help/2642044/how-time-zone-normalization-works-in-microsoft-outlook
# Information about the Calendar Checking Tool for Outlook (CalCheck)
https://support.microsoft.com/pt-br/help/2678030/information-about-the-calendar-checking-tool-for-outlook-calcheck

Nova plataforma de Blog Posts – Caio Cesar

$
0
0

Olá amigos,

Conforme solicitado por alguns, criei um site de armazenamento para os blog posts de minha autoria/co-autoria.

Endereço - https://c4iocesar.wordpress.com/blog/

No momento, irei criar os posts em ambas as plataformas (WordPress e LATAM Blog).

At,

Caio Ribeiro Cesar

Sr. Technical Advisor - Exchange & Identity Online

Exchange Online – Planejando Mailbox Moves para Mailboxes com +100GB

$
0
0

By: Caio Ribeiro César

Agradecimentos especiais ao time de suporte da Microsoft – Joao Nascimento, Sergio Duarte & Fabio Baleizao.

Aproveitando que irei sair de férias agora no dia 02 de Novembro, irei deixar um post de lembrança para meus amigos do suporte, consultoria e parceiros.

Alguns clientes abrem chamados com problemas para migrar mailboxes para a nuvem, com o erro abaixo:

Error: MigrationPermanentException: Mailbox size 160.96GB (165,457,177,916 bytes) exceeds target quota 100GB (107,374,182,400 bytes).

Em outras palavras, a mailbox source (OnPremises) possui uma database maior do que a quota da mailbox de destino (OnCloud). O problema pode ser simples de ser resolvido, porém o recomendado é sempre planejar antes de executar.

Vamos iniciar com o entendimento do ambiente local.

Possuir mailboxes com um quota superior a 100GB seria um best practice?

Pode depender do ambiente. O Exchange 2019 possui um warn limit de mailboxes para 2TB – o que não significa que devemos utilizá-lo desta maneira.

Existe um excelente artigo escrito  pelo time de produto sobre este tema, em que a conclusão seria entre 2.5k a 5k mensagens em cada folder e que o que importa realmente seriam os números de emails e não o tamanho em si. Com o tempo, a tecnologia se adapta e inovamos soluções – pessoalmente recomendo seguir a mesma métrica do ambiente online (100GB).

Matematicamente falando: um usuário comum pode utilizar um quota de 100GB sem problemas. Tendo uma compreensão que este usuário recebe aprox. 150 emails por dia, com aproximadamente 100KB para cada mensagem teríamos 15MB de dados por dia (5.47GB por ano). Para acomodar 100GB de dados, precisaríamos de ~18 anos (e até lá espero que o custo de disk irá diminuir e o quota aumentar). Consequentemente, os tamanhos de emails seriam maiores – seria uma discussão para outro post.

Isto significa que caso o seu usuário alcance o volume de 100GB, existe uma grande chance deste volume ser anormal ; gerado por notificações automáticas de monitoramento ou anti-virus, internal SPAM entre outros.

Possuir mailboxes com um archive quota superior a 100GB seria um best practice?

O mesmo estudo acima segue para quota de archive. A questão seria comparar a utilização. O archive deve ser utilizado para um conteúdo “antigo”, sendo este utilizado apenas pelo usuário dono da mailbox.

Conforme explicado no artigo abaixo, especificamente para Exchange Online -

O uso de journaling, regras de transporte ou regras de encaminhamento automático para copiar mensagens para uma caixa de correio do Exchange Online com a finalidade de arquivamento não é permitido. A caixa de correio de arquivo morto de um usuário destina-se somente a esse usuário. A Microsoft reserva o direito de negar o arquivamento ilimitado em situações onde a caixa de correio de arquivo morto do usuário é usada para armazenar dados de arquivo morto de outros usuários.

https://docs.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits

Logicamente, para ambientes OnPremises, o quota é customizado pelo administrador que pode optar pelo valor. Seguindo a regra anterior, seria uma boa idéia possuir 50GB de quota para archive (+9 anos de conteúdo).

Para coletar informações de sizing, basta executar os comandos:

Get-MailboxStatistics mailbox | ft DisplayName, TotalItemSize, ItemCount 
Get-MailboxStatistics -archive mailbox | ft DisplayName, TotalItemSize, ItemCount

O que acontece na migração?

Uma mailbox com utilização maior que a quota de serviços do Exchange Online irá falhar na migração, com o erro de “size exceeds target quota”. Isto serve também para a utilização de quota de Recoverable Items e para procedimentos de MailboxRestoreRequest (target mailbox vs. source mailbox size & quota).

A quota de Recoverable Items é “separada” da quota da mailbox. Ela é utilizada não apenas por conteúdo recoverable como por exemplo, conteúdo de mailbox audit:

 

Storage quota for Recoverable Items folder in primary mailbox (not on hold) 30 GB

 

 

Storage quota for Recoverable Items folder in primary mailbox (on hold) 100 GB

 

 

Caso o administrador precise aumentar esta quota no ambiente de Exchange Online, disponibilizamos um artigo que explica passo a passo como efetuar esta tarefa.

Como migrar uma mailbox com utilização superior a 100GB?

  • Limpeza. Mitigar problemas de tecnologia também significa entender que “technology is not a panacea”. Ações de sysadmin consistem em ensinar usuários como gerenciar os dados de suas mailboxes – criando rules ou tags para remover conteúdo não utilizado.
  • Caso esta mailbox não possua Archive, a recomendação seria habilitar a funcionalidade do ambiente OnPremises e mover items antigos para o Archive antes da migração. Posteriormente, basta migrar a mailbox + archive.
  • Caso esta mailbox possua archive já com uma utilização próxima ou superior a 50GB, a recomendação seria:
  1. Separar o archive mais “antigo” e aguardar a migração completar para dados da mailbox e do initial archive de 50GB.
  2. Iniciar a migração de dados de archive remanescentes assim que o auto-expand archive habilite auxiliary archives para a mailbox da nuvem (lembrando que esta tarefa pode demorar diversos dias). Lembrando também que o auto-expand deve estar habilitado para a Mailbox Online.

Dos criadores de:

Não perca a nova moda, já disponível nas lojas:

Exchange Online Protection – Spear Phishing Attack, ASF and ATP

$
0
0

By: Caio Ribeiro Cesar

In this post, I will be discussing some practices used by attackers in order to get authentication information for VIP users.

This is a common practice called "spear phishing", or individual phishing - first, attackers get to know the victim (usually a CISO/CTO or someone that holds important data). Then, they start the attack.

These methodologies are evolving. Spear phishing are usually mixed with social engineering in order to create a relationship between the attacker and the victim - as getting a call about the email being sent with important information available on a link that they need to click. When this email is delivered, the victim usually trusts the attacker and does not hesitate to access the information.

Let's first understand how a phishing attack is done, so we can discuss individual attacks.

1) We need a website. Maybe a copy of a reliable site, as a methodology for people to trust the information they see. Attackers add the site to the email body (or maybe a site, forum or anywhere people can click and be lurked to the attacker)

Attackers create a clone of reliable websites, or they create their own. Spear phishing usually relies on cloning as they are more precise on a single attack rather than expecting "some hits" from a 10k/100k mail list.

The example below is a clone of the old O365 portal, created by me back in 2015 (https://c4iocesar.wordpress.com/2015/08/24/exchange-online-protection-spear-phishing-attack-asf-e-safe-links/).

The attacker would simply create a DNS entry for the external IP address of this website. The webpage is identical to the old "login.microsoftonline.com".

After the website is cloned and published, the attacker will build a nice written email with this information. It's important to understand that they usually use spoofs, so these emails are sent similar to the original sender - and this is why we should use features such as SPF/Dkim/DMARC.

In the simulation below, I'm adding my webserver to the email, spoofing the sender so they can be tricked by opening and clicking on my email:

*As much as I can create a valid clone, published externally and add a real spoof in the attack, I want to keep my Kali Linux Lab in Azure. If you are a Pentester, please let the azure team know in the procedure of creating the VM.

 

 

The victim then would access the URL from my email, and the HTTP POST would be added to my webserver DB.

How can administrators prevent end users from clicking on these emails?

Exchange Online Protection has not only tools that can prevent these emails from arriving, but also features that can prevent end users from accessing the information.

1) ASF

Advanced SPAM Filter acts on the SPAM Filter for ExO. It acts by reading the email body and preventing these emails from reaching the /Inbox. For example:

This was added as a Spam Confidence Level of 6, due to the "Numeric IP in URL" action. This methodology is commonly used by attackers in order to trick users by clicking on a fake URL.

 

- ATP (Safe Links)

Advanced Threat Protection has become common for larger enterprises. This avoids users from reaching out to unsafe links. When the end user tries to reach out the URL, it's validated by a MS server so we are sure this URL is valid/does not contain a malware, redirect or being used as a phishing endpoint. The end user is alerted and these actions can be monitored by the company admin:

 

 

 

 

As we can see below, when the website is redirected to a phishing endpoint, we are first routed to ".safelinks.protection.outlook.com":

Information received by the end user (language can be customized):

Admin reporting for the ATP:

 

++++++++++++++++++++++++++++++++++++++++++++++

This is a post translation for the 2015 article written in Portuguese. Today, ATP has evolved, together with multiple Microsoft (and third party) technologies. For Microsoft, I indicate going through the CISO workshop [https://docs.microsoft.com/en-us/office365/securitycompliance/ciso-workshop
], together with the Cybersecurity Reference Architecture (MCRA) for integrated solutions.

Other solutions that can help you and your organization to be ready for these attacks:

1) SecureScore can help you (as the admin) to understand your security score for O365.

2) Phishing Simulations (phishing campaigns) are available in O365. This can help to prepare your organization culture.

Viewing all 98 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>