Skip to content

Ulysses Neves

Microsoft Entra ID, authentication, and hybrid identity troubleshooting.

Menu
  • Início
  • Microsoft Azure
  • Microsoft AD FS
  • Microsoft 365
  • Contact
Menu

Azure MFA – Preenchendo as informações de telefone para MFA usando o PowerShell e o Microsoft Graph

Posted on 20 de October de 2020

Olá pessoal. Muitos administradores têm a dura missão de automatizar tarefas para facilitar a vida do usuário final. No artigo de hoje vamos explicar como popular previamente as informações de telefone para autenticação com MFA no Azure AD usando o PowerShell e o Microsoft Graph, evitando que os usuários tenham que fazer esse registro durante a implantação do MFA na empresa.

O que é o Azure MFA?

O Azure MFA (Multi-factor Authentication) minimiza as chances de sua conta ser comprometida e utilizada caso suas credenciais sejam roubadas. É uma camada de segurança extra baseada na necessidade da posse de outros métodos para comprovar sua identidade. Mais informações sobre o Azure MFA, dê uma olhada neste artigo que escrevi explicando como habilitar o MFA no Azure AD.

Instalando o módulo MSAL

Vamos iniciar abrindo o PowerShell como administrador e instalando o módulo MSAL através do comando abaixo:

Install-Module -Name MSAL.PS -force 

Caso tenha restrições em seu ambiente para rodar o comando acima, execute o comando abaixo:

Save-Module -Name PowerShellGet -Path C:\LocalFolder -Repository PSGallery (CHANGE THE PATH) 

Depois navegue para o caminho e você deve ter 2 pastas baixadas nesse caminho: “PowerShellGet and PackageManagement”. Copie essas pastas na seguinte pasta: “C:\Program Files\WindowsPowerShell\Modules”

Import-module -name PowerShellGet 
Install-module -name MSAL.PS

Obs: Este script foi criado pelo brilhante Mircea Farcasanu e agradeço a ele por compartilhar o conteúdo conosco.

Copie o código abaixo, cole no notepad e salve como “Phone_edit.ps1”.

#install-module -name MSAL.PS

#PARAMATERS (Please Modify with your values)
################################################
#Clear-MsalCache
$ClientID = Read-Host("Add your ApplicationID:")
$tenantId = Read-Host("Add your TeantID:")
################################################

$Token = Get-MsalToken -clientID $clientID -tenantID $tenantID -Scope 'https://graph.microsoft.com/.default' -RedirectUri "https://login.microsoftonline.com/common/oauth2/nativeclient"
$Identity = $Token.AccessToken

################################################
#BUILD THE REQUEST:
$headerParams = @{'Authorization'="$("Bearer") $($Identity)"}

#Import your CSV: (Please Modify with your CSV PATH)
Write-host "Import the CSV file with your information, in the format of <C:\Users\<USER>\Desktop\Users.csv>" -ForegroundColor white -BackgroundColor Black
$importPath = Read-Host 
$CSV = Import-Csv -Path $importPath

$Logs = @()
$error.Clear()

foreach ($user in $CSV)
{
$ObjectID = $user.ObjectId
$phone = $user.PhoneNumber
$username = $user.UserPrincipalName
$error.Clear()

$Update = "https://graph.microsoft.com/beta/users/$ObjectID/authentication/phoneMethods/3179e48a-750b-4051-897c-87b9720928f7"
$Add = "https://graph.microsoft.com/beta/users/$ObjectID/authentication/phoneMethods/"

$Body = @"
{
  "phoneNumber": "$phone",
  "phoneType": "mobile"
}
"@ 

try
        {
        $AddPhoneNumber = Invoke-WebRequest -UseBasicParsing -Headers $headerParams -Uri $Add -body $Body -Method POST -ContentType "application/Json"
        }
        catch [System.Net.WebException]
        {
 
        }

            #EXCEPTION
      
                $Except = $Error[0].ErrorDetails.Message
                $Exception = $Except | Convertfrom-json -ErrorAction SilentlyContinue
             
            
            #LOGS
           if ($Exception -ne $null)
           {
            $Log = New-Object System.Object
            $Log | Add-Member -MemberType NoteProperty -Name "ErrorCode" -Value $Exception.error.code
            $Log | Add-Member -MemberType NoteProperty -Name "ErrorMessage" -Value $Exception.error.message
            $Log | Add-Member -MemberType NoteProperty -Name  "User" -value $username
            $Log | Add-Member -MemberType NoteProperty -Name  "UserObjectID" -value $ObjectID
            $Logs += $Log
            }
}
Write-host "Add the Path you'd like us to export the ERRORS CSV file to, in the format of <C:\Users\<USER>\Desktop\Users.csv>" -ForegroundColor white -BackgroundColor Black
$Export = Read-Host 
$Logs | Export-CSV  $Export -NoTypeInformation -Encoding UTF8

Registrando a aplicação

O próximo passo é registrar a aplicação que será utilizada para inserir as informações nos perfis dos usuários.

Abra o portal do Azure AD App registration usando a URL https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps e selecione + New Registration conforme abaixo:

Registre a aplicação seguindo as configurações abaixo:
1 – Nome da aplicação.
2 – Selecione a opção Accounts in this organizational directory only (<your domain> only – Single tenant)
3 – Na opção Redirect URI, selecione Public Client/native
4 – Cole este endereço no campo URI conforme abaixo: https://login.microsoftonline.com/common/oauth2/nativeclient

Selecione Register.
Dentro da aplicação, clique em API Permissions.

Vamos configurar as permissões do Microsoft Graph seguindo os passos abaixo:
1 – Selecione a opção + Add Permission.
2 – Selecione Microsoft Graph.

1 – Selecione Delegated Permissions.
2 – Na barra de buscas, escreva: UserAuthenticationMethod.ReadWrite.All
3 – Marque a permissão conforme abaixo:

Selecione Add Permissions.
Clique em Grant admin consent for <seu domínio> conforme abaixo:

Preenchendo o arquivo .csv com as informações dos usuários

Com a aplicação configurada, vamos agora criar um arquivo com as informações dos usuários.

Vocês podem criar um arquivo em Excel ou exportar diretamente do Azure AD já no padrão utilizado pelo script executando os comandos abaixo:

Connect-MsolService
Get-msoluser -all | select UserPrincipalName, ObjectId, PhoneNumber | Export-CSV “C:\Users\<USER>>\Desktop\Users.csv” -NoTypeInformation -Encoding UTF8

Obs: Após gerar o arquivo .CSV, converta a coluna “phone number” do formato “general” em formato “text” para evitar que o número de telefone seja tratado como uma fórmula.

Ajustando o script com as informações da aplicação registrada

No script, será necessário que você preencha as informações de ApplicationID e TenantID do App criado no segundo passo deste artigo. Você pode localizar as informações selecionando sua aplicação e a opção Overview conforme abaixo:

Rodando o Script

Vamos agora abrir o PowerShell e executar o arquivo Phone_edit.ps1, criado por mim para essa ilustração.

Vamos preencher o Application ID da aplicação registrada.

Vamos preencher o Tenant ID do domínio no Azure AD.

Vamos entrar com uma credencial com privilégios de administrador no Azure AD conforme abaixo:

Vamos preencher o caminho onde se encontra o arquivo .CSV com as informações dos usuários devidamente preenchida.

É necessário preencher um caminho onde o arquivo de log de saída do script será salvo. Este arquivo é importante para verificar se tudo correu bem com o script.

Se o output do script for igual ao apresentado abaixo, tudo correu bem e todos os usuários tiveram suas informações de MFA devidamente registradas.

Validando o registro automatizado das informações de MFA

Após rodarmos o script utilizando o arquivo .csv com apenas um usuário, validamos que não houveram erros e ao acessar a conta do usuário, percebemos que o numero fictício +55 21988889087 foi atribuído com sucesso.

Com a confirmação da informação de MFA, no primeiro acesso a um recurso que tenha como requisito o MFA, o usuário não será redirecionado para a página de registro, mas será enviado o SMS para o número registrado pelo script nos passos anteriores.

Resumo

No artigo de hoje, explicamos como registrar previamente informações de MFA para usuários usando o PowerShell e Microsoft Graph, evitando o redirecionamento de usuários para a página de registros do Azure MFA em um cenário de implantação de Azure MFA.

Espero que este conteúdo tenha contribuído com o enriquecimento do conhecimento de vocês em Azure MFA.

Gostaram do post? Curtam e compartilhem. 🙂

Tem alguma sugestão ou observação, comente.

[ ]’s

Ulysses Neves

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

  • Microsoft Authenticator Will Block Jailbroken Devices in 2026 — What You Need to Know 17 de March de 2026
  • Enhancing Azure role activation security with FIDO2/Passkeys 23 de September de 2024
  • Microsoft Entra ID CAP | Enforcing WHfB using Authentication Strength 21 de April de 2024
  • Troubleshooting Error Code ‘0x000005e’ in WHfB: PIN Authentication Woes 11 de February de 2024
  • WHfB: Fixing Windows Hello for Business error ‘LogoncertTemplateReady: NO (StateNoTemplate)’ 29 de December de 2023

Archives

  • March 2026
  • September 2024
  • April 2024
  • February 2024
  • December 2023
  • September 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019

Tags

#aaddownleveldevice #aadhybridjoin #adfs #adfsonsql #azuread #azureauth #azureCA #azuredevice #azurehybridjoin #azuremfa #azuresecurity #capolicy #cloudkerberostrust #conditionalaccess #conditionalaccesspolicy #deviceregistration #gmsaaccount #gopasswordless #hybridaadjoin #mfaserver #msadfs #msazure #msidentity #namedlocation #sslcertificatevalidation #tshootadfs #tshoothybridjoin #tshootwaptrust #waptrust #WHFBcerttrust #whfbdeployment #WHfBhybridsetup #widdatabase adconnect authenticationcontext authenticationstrength az500 azuread azuremfa azurepim azuresecurity cloudsecurity microsoft365 msazure WHfB
©2026 Ulysses Neves | Design: Newspaperly WordPress Theme
Ulysses Neves
Gerenciar Consentimento de Cookies
Para fornecer as melhores experiências, usamos tecnologias como cookies para armazenar e/ou acessar informações do dispositivo. O consentimento para essas tecnologias nos permitirá processar dados como comportamento de navegação ou IDs exclusivos neste site. Não consentir ou retirar o consentimento pode afetar negativamente certos recursos e funções.
Funcional Always active
O armazenamento ou acesso técnico é estritamente necessário para a finalidade legítima de permitir a utilização de um serviço específico explicitamente solicitado pelo assinante ou utilizador, ou com a finalidade exclusiva de efetuar a transmissão de uma comunicação através de uma rede de comunicações eletrónicas.
Preferências
O armazenamento ou acesso técnico é necessário para o propósito legítimo de armazenar preferências que não são solicitadas pelo assinante ou usuário.
Estatísticas
O armazenamento ou acesso técnico que é usado exclusivamente para fins estatísticos. O armazenamento técnico ou acesso que é usado exclusivamente para fins estatísticos anônimos. Sem uma intimação, conformidade voluntária por parte de seu provedor de serviços de Internet ou registros adicionais de terceiros, as informações armazenadas ou recuperadas apenas para esse fim geralmente não podem ser usadas para identificá-lo.
Marketing
O armazenamento ou acesso técnico é necessário para criar perfis de usuário para enviar publicidade ou para rastrear o usuário em um site ou em vários sites para fins de marketing semelhantes.
  • Manage options
  • Manage services
  • Manage {vendor_count} vendors
  • Read more about these purposes
Ver preferências
  • {title}
  • {title}
  • {title}