segunda-feira, 9 de novembro de 2020

Cloud Password Expiration Policy with Synchronized Users - O365

 

I have brought the steps to enable the password expiration for the users in Office 365. Synchronized users and not synchronized. No On-prem policy nor On-prem user will be touched.

About the synchronized users, we can make them obey the Expiration Policy in the cloud.

 

So, I suggest to first enable the password expiration policy for cloud users and after that Enable Password Expiration for Office 365 Synchronized Users.

The result will be that Cloud users not synced are going to obey the expiration policy and also the Office 365 synced users. Synced users will have to change their password in On-prem Active Directory. If you have password write-back feature enabled they will also be able to change the password online.

 

Enable Password Expiration for Cloud Users

To enable password expiration for cloud users, check the print below:

* Note that this will only affect new cloud users. Synced users and existent cloud users won´t be affected. 

 



 

To set the already existent cloud users to expire the password, it will be necessary to run a command for each cloud user:

set-MsolUser -UserPrincipalName user@domain.onmicrosoft.com -PasswordNeverExpires:$False -StrongPasswordRequired:$True

 

 

Enable Password Expiration for Office 365 Synchronized Users

To enable password expiration in office 365 for synchronized users, run the following command on a Powershell prompt of the AADConnect Server:

Set-MsolDirSyncFeature -Feature EnforceCloudPasswordPolicyForPasswordSyncedUsers

                Enable Yes

 

After running the above command and after the users change their password on-prem, the cloud password will start to expire according described in “Enable Password Expiration for Cloud Users” session above.

 

Usefulness

=========================

You get the best of it when you align your Local AD Password Expiration with Office 365 Password Expiration Policy and have Password Write Back configured.

 

 

Documents

=========================

Set the password expiration policy for your organization

https://docs.microsoft.com/en-us/microsoft-365/admin/manage/set-password-expiration-policy?view=o365-worldwide

 

Password expiration policy

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchronization#password-expiration-policy

 

Tutorial: Enable Azure Active Directory self-service password reset writeback to an on-premises environment

https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-enable-sspr-writeback

 

sábado, 22 de agosto de 2020

Como obter a Retention TAG aplicada a uma mensagem de e-mail utilizando MFCMAPI

 

Os itens de e-mail possuem um campo chamado “PR_POLICY_TAG”. Ele possui parte da RetentionID da

Retention TAG aplicada à mensagem de e-mail.

 

Obter o campo “PR_POLICY_TAG” do item de e-mail:

 

Para obtermos o campo “PR_POLICY_TAG”, será necessário abrir um programa chamado “MFCMAPI”

na máquina do usuário que a possui. Seguem passos:

 

  1. Baixe o MFCMAPI do site abaixo. MFCMAPI.x64.exe.20.0.20227.01.zip

https://github.com/stephenegriffin/mfcmapi/releases/tag/20.0.20227.01

  1. Descompacte e abra o arquivo MFCMapi.exe
  2. Clique em menu  QuickStart\Open Folder\Inbox







 

 

 

 

 

  1. Clique em menu  QuickStart\Open Folder\Itens Excluídos

 







 

 

 

 

 

 

 

 

 

 

 

 

 

  1. Procure pela mensagem antiga e clique sobre ela.
  2. Procure pela propriedade “PR_POLICY_TAG” E clique sobre ela.
  3. Expanda a coluna “Value” para que possa comportar/exibir todo o valor. Conforme foto
    abaixo:

 

 


 *  Note que o valor é “05DD9E39C123F54D9FE305E9B0096BEE

 

 

 

Obtendo o RetentionID das Retention TAGs

Veja que, neste exemplo, a TAG criada no Exchange Online possui a

RetentionId     : 399edd05-23c1-4df5-9fe3-05e9b0096bee

 

 
 
 
 
 
 
 
 
 

 









 

 

 

PS C:\temp> Get-RetentionPolicyTag|fl identity,retentionaction,retentionid*

 

 

Identity        : Deleta em 4 anos (DPT)

RetentionAction : DeleteAndAllowRecovery

RetentionId     : 399edd05-23c1-4df5-9fe3-05e9b0096bee

 

 

Comparando o valor de “PR_POLICY_TAG” com o RetentionID

“PR_POLICY_TAG” - “05DD9E39C123F54D9FE305E9B0096BEE

RetentionId     : 399edd05-23c1-4df5-9fe3-05e9b0096bee

 

*  Note que o final é igual nos dois casos:






 

Conclusão

 

Com o procedimento acima, foi possível identificar qual a Retention TAG

aplicada a uma determinada mensagem de e-mail.

 

 

 

Documentos relacionados a Retention TAGs

============================

Understanding of Managed Folder Assistant with retention policies

https://docs.microsoft.com/en-us/archive/blogs/anya/understanding-of-managed-folder-assistant-with-retention-policies

 

How retention age is calculated

https://docs.microsoft.com/en-us/exchange/security-and-compliance/messaging-records-management/retention-age

 

Retention tags and retention policies

https://docs.microsoft.com/en-us/exchange/security-and-compliance/messaging-records-management/retention-tags-and-policies

 

segunda-feira, 1 de junho de 2020

Old e-mails are not being moved to archive by Retention Policy in Office 365

Problem
============================
    - Mailbox "user@domain.com" is full and retention policy is not moving old items to archive.


Troubleshooting
===========================
    - Checked the retention policy and it has only one tag, that moves items older than 1 year to archive and it´s type is "Default". So everything is ok with Retention Policy.
    - Command "Get-Mailbox "user@domain.com" | FL *RetentionHoldEnabled*" releved that Retention Hold was enabled.


“Retention Hold” prevents the “Retention Policy” to run.


Solution
===========================
    - Disabled Retention Hold and started Retention Policy engine to run the Retention Policy. As follows:

PS C:\> Get-Mailbox "user@domain.com" | FL *RetentionHoldEnabled*

RetentionHoldEnabled : True

PS C:\> Set-Mailbox "user@domain.com" -RetentionHoldEnabled $false
PS C:\> Get-Mailbox "user@domain.com" | FL *RetentionHoldEnabled*

RetentionHoldEnabled : False

PS C:\> Start-ManagedFolderAssistant -Identity "user@domain.com"
PS C:\>


Documentation
=================================
Retention hold
https://docs.microsoft.com/en-us/exchange/security-and-compliance/messaging-records-management/retention-tags-and-policies#retention-hold

quinta-feira, 30 de abril de 2020

E-mails enviados para grupos do Office 365 não caem na caixa de entrada dos usuários




    Estive trabalhando em um caso aonde os membros de um grupo de tipo "Office 365" não recebiam
os e-mails enviados para o grupo em suas caixas de entrada. Os e-mails chegavam somente dentro do 

próprio grupo.


Solução

===========================
  • Para que os membros do grupo recebam uma cópia da mensagem na caixa de entrada,
é necessário que o membro esteja inscrito no grupo. Não basta ser membro, tem que estar inscrito.



Subscrição pelo Administrador pelo Microsoft 365 admin center

Aqui temos um dos locais para ativar as subscrições. As subscrições ativadas por aqui aplicam-se para
membros já existentes no grupo. Seguem passos:

  1. Acessar o "Microsoft 365 admin center"
  2. Clicar e "Groups"
  3. Localizar e abrir o grupo.


  1. Acessar as propriedades do grupo, guia "Settings"
  2. Marcar a opção "Send copies of group conversations and events to group members".
    Conforme figura abaixo:


Pronto, desta maneira todos os membros do grupo passarão a estarem subscritos e receberão os e-mails
enviados para o grupo também em suas caixas de entrada.


Subscrição pelo Administrador pelo portal do Exchange Online

    A subscrição pode ser feita por aqui, mas somente antes de adicionar os membros. 
    Siga os passos para subscrever os usuários: 


  • Acessar o Exchange admin center, recipients, groups e abrir as configurações do grupo.
  • Logo na guia "general" haverá a opção "subscribe new members".
  • Somente após esta opção estar marcada, é que os novos membros adicionados no grupo já
    terão a subscrição feita.
  • Portanto se os membros do grupo foram adicionados antes desta opção ter sido marcada,
    os membros não receberão as mensagens de e-mail enviadas para o grupo.

Este print mostra o local para o administrador ativar a subscrição automática para novos
membros:



Subscrição pelo Próprio Usuário

  • Os usuários podem escolher estarem inscritos ou não em um grupo para receber os e-mails
enviados para este grupo. Para isto, bastará que o usuário acesse as configurações do grupo e selecione
a opção "Receive all email and events" ou "Receber todos os e-mails e eventos". Conforme passos abaixo:

  1. Clicar sobre o grupo desejado, neste caso o nome do grupo é "Novo365".
  2. Clicar sobre os 3 pontinhos ...
  3. Clicar em "Settings" ou "Configurações". Conforme figura abaixo:


  1. Em seguida, selecionar a opção desejada. Em nosso caso, para que receba todos os e-mails
    e
    eventos, clicar em "Receive all emails and events.". Conforme abaixo:




  • Pronto. A partir de agora o usuário já deve receber os e-mails enviados para o grupo tanto
no grupo quanto na caixa de entrada.

terça-feira, 4 de fevereiro de 2020

Horário de Verão - Updates

A esta altura, quem vive nas áreas sujeitas à mudança de horário de verão no Brasil, já notou que não houve mudança de horário este ano, horário este que iniciaria em outubro de 2019 e terminaria em fevereiro de 2020.

É importante lembrar que, até segunda ordem, não haverá horário de verão em 2020 nem nos anos seguintes no Brasil.

De qualquer maneira, gostaria de compartilhar os KBs da Microsoft que configuram os Windows Server e Windows Client que não haverá mudança de horário no fuso Brasília -3.


Para sistemas:
Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2
Windows Server 2008 x86 e x64
Windows 8.1
Windows 8
Windows 7
Utilizar a kb4507704


Para sistemas Windows 10, os updates são cumulativos.
A atualização que configura o sistema operacional de que não haverá horário de verão saiu no release de 16 de julho de 2019. Portanto, se o Windows estiver em qualquer release mais recente, já terá a atualização de que não haverá horário de verão para 2019 em diante.

Ação Paliativa
Se por algum motivo o update não puder ser instalado, uma ação paliativa é alterar o fuso horário do Windows para "Caiena, Fortaleza", pois este é um fuso que nunca teve horário de verão. Esta não é uma solução definitiva pois o outlook ou outro aplicativo que trabalhe com agendas e compromissos terão problemas para calcular apontamentos que relacionem o fuso Brasília no período que havería horário de verão, nestes sistemas.


Mais informações:


sábado, 1 de fevereiro de 2020

Filtrar Sincronização por Atributo no AADConnect


Introdução
=============
Existem cenários em que a sincronização do AADConnect precisa ser filtrada com maior granularidade que a filtragem por Unidade Organizacional.

Neste post irei mostrar como filtrar a sincronização por atributo.

Em nosso exemplo, utilizaremos o atributo msExchExtensionAttribute39 e para que a conta seja sincronizada, o valor Sync deverá estar presente.


Ambiente
============
AADConnect versão 1.4.38.0 instalado em um Windows Server 2012 R2


Passos
============
Iniciar abrindo o Synchronization Rules Editor.


Na Janela "Synchronization Rules Editor" clicar em "Add new rule".



Digitar um nome para a regra;
No campo "Conected System" selecionar o domínio do AD local;
Em "Connected System Object Type" selecionar "user";
Em "Metaverse Object Type" selecionar "person";
Em "Link Type" "Join";
Alterar o "Precedence" para "50" ou outro valor abaixo de "99";
Clicar em "Next".



Em "Scoping Filter" adicionar uma "clause", selecionar o atributo desejado, neste caso é o atributo "msExchExtensionAttribute39", Operator "EQUAL" e valor "Sync".



Em "Join rules" não fazemos alteração e simplesmente clicamos em "next".

Em "Transformations":
Selecionar campo "Constant", "cloudFiltered";
No campo "Source" inserir o valor "false";
Clicar em "Add".




Clicar novamente em "add new rule" para criar uma nova regra.




Escolher o nome da segunda regra;
Inserir as mesmas informações da regra anterior, exceto o campo "Precedence" que deve estar com valor entre regra recém criada e a próxima regra. No caso 99 é um número satisfatório.



Seguir para "Transformations" sem inserir nada em "Scoping filter" nem em "Join rules";
Inserir os mesmos dados da regra anterior, exceto o campo "Source" que terá valor "true";
Clicar em "Add".




Para que as alterações tenham efeito, um full sync será realizado na próxima janela de sincronização.



Lembre-se que a OU ainda deverá estar selecionada, nas configurações do conector, para que os objetos dentro dela sejam sincronizados.






Mais Informações
============
Positive filtering: "only sync these"


Azure AD Connect sync: Understanding Declarative Provisioning

sexta-feira, 31 de janeiro de 2020

HardMatch de Ms-Ds-ConsistencyGuid e ImmutableId




Em uma implantação de AADConnect, me deparei com um tenant do Office 365 que possuía usuários de produção criados na nuvem, no Office 365. E mais, ao colocar somente 1 conta para ser sincronizada com o AADConnect, o SoftMatch não acontecia, ocasionando a criação de uma conta sincronizada, porém diferente da que o usuário já utilizava no Office 365.

Durante a instalação do AADConnect tomei o cuidado de não permitir a sincronização inicial ao final do wizard de configuração. Isto me poupou o trabalho de ter que remover todas as contas duplicadas que teriam sido criadas pela sincronização inicial.

Vemos abaixo um de nossos usuários que já haviam sido criados na nuvem antes da instalação do AADConnect:



Análise do ambiente para aplicar o HardMatch
======================
O AADConnect foi instalado na versão 1.4.38.0 e o SourceAnchor escolhido na instalação foi o campo mS-Ds-ConsistencyGuid.

Caso o SourceAnchor de sua implementação seja diferente, não prossiga com o passo a passo deste blog.




Verificando os usuários de nuvem no Office 365, notei que não possuíam ImmutableID. Isto é normal pois foram criados on-line. Veja abaixo:



Verifiquei também, no Active Directory (AD) local, que as contas que eu queria fazer o HardMatch possuiam o campo Ms-Ds-ConsistencyGuid com valores. Veja abaixo:




Estratégia Adotada
======================
Adotada a seguinte estratégia:

  1. Obter a relação de UserPrincipalName e ms-ds-consistencyguid do AD Local.
  2. Traduzir o valor obtido no passo anterior para base64 usando Translate_ImmutableID.ps1
  3. Usar comando Set-Msoluser -userprincipalname XXX -ImmutableId YYYY
  4. No AADConnect, colocar o usuário em uma OU marcada para ser sincronizada pelo AADCnnect e então fazer o delta sync.


Com a estratégia em mente, mãos à obra!
=======================
  • Passo 1 - Obter a relação de UserPrincipalName e ms-ds-consistencyguid do AD Local.
    • Loguei em um controlador de domínio e abri o powershell
    • Executado o comando abaixo para obter o ms-ds-consistencyguid do usuário

Get-ADUser -Filter "UserPrincipalName -eq 'fio@maier.eti.br'" -Properties Ms-Ds-ConsistencyGuid |select userprincipalname,@{name='ms-ds-consistencyguid';expression={[guid]$_.'ms-ds-consistencyguid'}}


  • Com o valor do campo em mãos, pude partir para o passo 2, que seria converter este valor para que pudesse ser inserido no campo ImmutableId da conta correspondente no Office 365

  • Passo 2 - Traduzir o valor do campo ms-ds-consistencyguid, para o valor correspondente do ImmutableID, utilizando o script Translate_ImmutableID.ps1
    • Este versátil script permite converter qualquer uma das bases vindas do campo ms-ds-consistencyguid para o ImmutableId e o contrário também
    • Segue exemplo da utilização do script. E observe o valor do ImmutableID




  • Passo 3 - Usar comando Set-Msoluser -userprincipalname fio@maier.eti.br -ImmutableId YYYY
    • Agora que já temos o valor do ImmutableID correspondente ao valor do campo ms-ds-consistencyguid do AD local, vamos inseri-lo à conta do Office 365.

Set-MsolUser -UserPrincipalName fio@maier.eti.br -ImmutableId 0cqchBysdU6a7ZsPodvuoA==


 

  • O processo até aqui ficou assim:

Agora que o ms-ds-consistencyguid da conta do AD local está de acordo com o ImmutableId da conta do Office 365, basta colocar o usuário do AD local em uma OU que é sincronizada pelo AADConnect e efetuar um delta sync.

  • Passo 4 - No AADConnect, colocar o usuário em uma OU marcada para ser sincronizada pelo AADCnnect e então fazer o delta sync.

 


  • Acessando o portal do Office 365, podemos ver que a conta agora aparece como "Sincronizado" e sem duplicatas.

 

Até a próxima,

Daniel Maier