Technical Focus Group - Identity https://docs.microsoft.com/archive/blogs/tfg/feed.xml Cloud and Hybrid Wed, 17 Apr 2019 03:47:38 GMT en-US hourly 1 [English] Tips to Manage Azure AD User's Consent to Applications Using Azure AD Graph API https://docs.microsoft.com/archive/blogs/tfg/english-tips-to-manage-azure-ad-users-consent-to-applications-using-azure-ad-graph-api Sun, 15 Oct 2017 18:06:02 GMT https://blogs.technet.microsoft.com/tfg/?p=535 https://graphexplorer.azurewebsites.net/ 3. List existent consents: GET https://graph.windows.net/myorganization/oauth2PermissionGrants/ 4. Search under "clientId" to identify the objectID of Service Principal created in 1) 5. Copy the details of the identified consent above, and change it according to the needs. E.g.: { "clientId": "6518c856-4cb3-4c22-bb5c-935739ed5477", "consentType": "Principal", "expiryTime": "2018-04-12T21:51:49.5446711", "principalId": "e83078bf-ab20-4ca3-bf78-ec0662b0856f", "resourceId": "e4b81415-37ca-4acb-a178-0b33dc42ffdc", "scope": " User.Read openid", "startTime": "0001-01-01T00:00:00" } Notes: "clientId": ObjectID of the Service Principal "consentType": Principal means "user consent" "principalId": The objectID of the user the consent applies to "scope": Permissions given on the consent on behalf of the user 6. Create consent for the user: POST https://graph.windows.net/myorganization/oauth2PermissionGrants/ Data for POST: { "clientId": "6518c856-4cb3-4c22-bb5c-935739ed5477", "consentType": "Principal", "expiryTime": "2018-04-12T21:51:49.5446711", "principalId": "e83078bf-ab20-4ca3-bf78-ec0662b0856f", "resourceId": "e4b81415-37ca-4acb-a178-0b33dc42ffdc", "scope": " User.Read openid", "startTime": "0001-01-01T00:00:00" } 7. After the above, the consent is given for the user/principal, and if you list again the existent consents, you'll identify a new one: { "clientId": "6518c856-4cb3-4c22-bb5c-935739ed5477", "consentType": "Principal", "expiryTime": "2018-04-12T21:51:49.5446711", "objectId": "LLc7jy3wpEacSf2S_weYbR", "principalId": "e83078bf-ab20-4ca3-bf78-ec0662b0856f", "resourceId": "e4b81415-37ca-4acb-a178-0b33dc42ffdc", "scope": " User.Read openid", "startTime": "0001-01-01T00:00:00" } 8. If you need to remove/revoke consent, use the "objectId" (auto-generated during creation), and execute the following: DELETE https://graph.windows.net/myorganization/oauth2PermissionGrants/LLc7jy3wpEacSf2S_weYbR   More Details: Understanding user and admin consent - https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview#understanding-user-and-admin-consent oAuth2PermissionGrant resource type - https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/oauth2permissiongrant  ]]> [English] Azure AD Domain Services - Domain join an ARM Virtual Machine https://docs.microsoft.com/archive/blogs/tfg/english-azure-ad-domain-services-domain-join-an-arm-virtual-machine Tue, 31 May 2016 14:50:44 GMT https://blogs.technet.microsoft.com/tfg/?p=506 ONLY available for classic virtual networks (VNet guidelines), therefore, you might think that it is only possible to domain join classic VMs to a domain. Not exactly true, it is also POSSIBLE to join an Azure Resource Manager (ARM) virtual machine. However, you first need to:
  1. Enable AADDS on a classic VNET
  2. Create a VPN Site-to-Site between the classic VNet and an ARM VNET (view article)
  3. Connect the VM to the ARM VNET
  4. Now you can domain join the ARM VM using AADDS
TIP: you might want to change the DNS servers for the ARM VNet to, instead of using Azure DNS, use the DNS provided by AADDS service, which you can get from Azure Active Directory -> Select your directory -> Configure -> Domain Services.]]> [English] Unblocking Azure MFA for an O365/AAD user https://docs.microsoft.com/archive/blogs/tfg/english-unblocking-azure-mfa-for-an-o365aad-user Wed, 02 Dec 2015 02:54:00 GMT https://blogs.technet.microsoft.com/tfg/2015/12/02/english-unblocking-azure-mfa-for-an-o365aad-user/ If for some reason, possible due to a submitted Fraud alert or when setting up initial MFA configuration something went wrong and the user got in a blocked/inconsistent MFA state, the user won't be able to login.

There are 2 ways to go, depending on the scenario:

If O365 Global Admin has an AAD Premium license

Go to O365 Portal > Users > Set Multi-factor authentication requirements: Set up > Service Settings > Manage advanced settings and view reports Go to the portal

  • From Azure Multi-Factor Authentication portal > User Administration > Block/Unblock Users
  • If user is present as blocked: Proceed with unblock
  • If user is not present, MFA is enabled and gets CorrelationID when acessing or DISABLING MFA for user: Force a BLOCK to the user and then UNBLOCK him, DISABLE user MFA and re-enable


If customer has a full Azure Subscription with O365 directory integrated

In Azure Portal > Add new MFA Auth Provider and link it to O365 directory (Attention: if you keep this after unblocking the user and use MFA charges might apply)

Go to AAD directories > O365 directory > Configure > Multi-factor authentication > Manage service settings > Service Settings > Manage advanced settings and view reports Go to the portal

  • From Azure Multi-Factor Authentication portal > User Administration > Block/Unblock Users
  • If user is present and blocked: Proceed with unblock
  • If user is not present, MFA is enabled and gets CorrelationID when acessing or DISABLING MFA for user: Force a BLOCK to the user and than UNBLOCK him, DISABLE user MFA and re-enable
]]> [English] Change ImmutableID* in Azure Active Directoy (AAD/O365) for a Synced (and Federated) User https://docs.microsoft.com/archive/blogs/tfg/english-change-immutableid-in-azure-active-directoy-aado365-for-a-synced-and-federated-user Tue, 11 Aug 2015 16:58:00 GMT https://blogs.technet.microsoft.com/tfg/2015/08/11/english-change-immutableid-in-azure-active-directoy-aado365-for-a-synced-and-federated-user/ objectGUID, and needs to be changed for a user(s), e.g. object migrated/moved to a new forest, there are some potential steps that might help to achieve that: 1 - Create a new OU (e.g. OU=tempOU,DC=contoso,DC=com) in Active Directory and move temporarily the user(s) that you need to change the immutableID. 2 - Go to Sync Console, select containers for Active Directory management agent, and filter out the OU. 3 - Run a full sync in order to soft delete the user(s) in the OU and temporarily disable sync. 4 - Run the following in (Azure Active Directory/O365) PowerShell: Connect-MsolService (Insert AAD/O365 Admin credentials) Import-Module ActiveDirectory Get-ADUser -Filter * -SearchBase "OU=tempOU,DC=contoso,DC=com" | select UserPrincipalName | Export-Csv "C:\AADtemp.csv" $upnsuffix = "@contoso.onmicrosoft.com" #THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED "AS IS" WITHOUT #WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED #TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. Import-Csv "C:\AADtemp.csv" | ForEach-Object { $upn = $_."UserPrincipalName" $user = $upn.IndexOf("@") $upnpreffix = $upn.Substring(0,$user) $upntemp = "$upnpreffix" + "$upnsuffix" Restore-MsolUser -UserPrincipalName $upn Set-MsolUserPrincipalName -UserPrincipalName $upn -NewUserPrincipalName $upntemp Set-Msoluser -UserPrincipalName $upntemp -ImmutableID "$Null" $id=(Get-ADUser -Filter {UserPrincipalName -like $upn } -Properties ObjectGUID | select ObjectGUID | foreach {[system.convert]::ToBase64String(([GUID]($_.ObjectGUID)).tobytearray())}) Set-MSOLUser –UserPrincipalName $upntemp –ImmutableID $id Set-MsolUserPrincipalName -UserPrincipalName $upntemp -NewUserPrincipalName $upn } The above PowerShell cmdlets should first run and be tested on a very small set of test user accounts before executing in any production environment. 5 - Move the users in Active Directory back to their original OU's, enable sync and run full sync so hard match of the objects can occur. Important Note: Because Azure AD is continuously growing and evolving, the steps presented above, might not work for some or all environments. Due to that fact, you should always opt to follow official supported methods: a) If you're using a single forest but you want to keep a potential expansion to multiple forests or you're already using multiple forests with an intention to migrate users between them, then do not use ObjectGUID as a SourceAnchor/ImmutableID due to its dependence on AD Forest. Instead select an attribute which doesn’t have to rely on the AD forest. This option is offered in the Azure AD Connect. b) If you're using a single forest and want to just use a different value for SourceAnchor/ImmutableID for a single or few objects, then deactivate Dirsync on the tenant, wait for all the changes to commit, and then run the Set-MSOLUser cmdlet with -ImmuableID switch to update the new value of SourceAnchor/ImmutabeID. Note that Dirsync may take up to 72 hours to be deactivated. c) Create a new custom attribute on the new AD Forest where the objects are going to be migrated, and store/populate the current SourceAnchor/ImmutableID in that new attribute. Then, modify the attribute flow in Azure AD Connect to source the SourceAnchor/ImmutableID from that new attribute instead of ObjectGUID. Finally, you can move objects between forests while always maintaining the SourceAnchor/ImmutableID.]]> [English] Azure Self-Service Password Reset (SSPR) - How To Update User's Alternate E-mail Address and Mobile Phone Number https://docs.microsoft.com/archive/blogs/tfg/english-azure-self-service-password-reset-sspr-how-to-update-users-alternate-e-mail-address-and-mobile-phone-number Tue, 04 Nov 2014 15:42:00 GMT https://blogs.technet.microsoft.com/tfg/2014/11/04/english-azure-self-service-password-reset-sspr-how-to-update-users-alternate-e-mail-address-and-mobile-phone-number/ Once you activate on Azure the Self-Service Password Reset mechanism for your users, in order to work, they need to have at least one validation method, either by using the alternate e-mail address or a phone number. This information can be updated administratively or each user can update his own data. To achieve that, follow the next steps:

Note: In order to use this functionality user must have an AAD Premium or Basic license assigned.

1 - Go to https://myapps.microsoft.com/

2 - Sign-in with user credentials

3 - Select "profile" tab and click on “Register for Password Reset”




4 - On the “Register for Password Reset” option, select the field that you want to update




5 - Once you update, click on “finish”.

]]> [English] Activate Additional Audit Reports for Office 365 Subscription Using $0 Azure Subscription https://docs.microsoft.com/archive/blogs/tfg/english-activate-additional-audit-reports-for-office-365-subscription-using-0-azure-subscription Wed, 22 Oct 2014 02:48:00 GMT https://blogs.technet.microsoft.com/tfg/2014/10/22/english-activate-additional-audit-reports-for-office-365-subscription-using-0-azure-subscription/ If you already have an active Office 365 subscription you can signup for a $0 Azure subscription that allows you to activate additional audit reports. To achieve that, follow the next steps: 

1 - Go to Office 365 Portal

2 - Insert your Office 365 admin credentials

3 - Insert the link on the URL bar https://account.windowsazure.com/signup?offer=MS-AZR-0110P 

4 - Fill in the form



5 - After finishing "Mobile verification", select "Sign up"

 


6 - Next, select "Portal"




7 - On the Portal, select "Active Directory"



8 - Open Directory, select "Reports" tab and activate what you need. Premium Reports are only available with Azure Active Directory Premium Licensing



9 - For activating the report you need to check that your admins will be able to view private user data



10 - After this point, reports are active for future user access.

]]> [English] Change Default DNS Records on Office 365 Business Essentials (Small Business - P1) to Point to External Website https://docs.microsoft.com/archive/blogs/tfg/english-change-default-dns-records-on-office-365-business-essentials-small-business-p1-to-point-to-external-website Mon, 06 Oct 2014 10:23:00 GMT https://blogs.technet.microsoft.com/tfg/2014/10/06/english-change-default-dns-records-on-office-365-business-essentials-small-business-p1-to-point-to-external-website/ After you setup a custom domain (e.g. contoso.com), as the default domain in Office 365, with a public Sharepoint website, you are unable to change the default A record for @ or WWW.

To overcome this scenario and point the default A record to an external location, follow the next steps:

1) On the Office 365 portal dashboard, go to "Manage your public website"





2) Select the option "Change address" and point to the initial value "x#y#z-public.sharepoint.com" 





3) After changing, click on save and wait until the operation is complete





4) Once the process is complete you'll noticed that the "Refresh" warning will no longer be displayed





5) Go back to dashboard and select "Manage domains for your website and email"




6) Select the domain and "Manage DNS"





7) Now you can change the @ and WWW records of your custom domain.

]]> [English] ADFS Token-Signing and Token-Decrypt Certificates Expiration Process and Dates https://docs.microsoft.com/archive/blogs/tfg/english-adfs-token-signing-and-token-decrypt-certificates-expiration-process-and-dates Mon, 21 Apr 2014 07:51:00 GMT https://blogs.technet.microsoft.com/tfg/2014/04/21/english-adfs-token-signing-and-token-decrypt-certificates-expiration-process-and-dates/ [English] - Content Developed by the EMEA Cloud Identity Support Team.



By default, Token-Signing and Token-Decrypting Certificates will expire one year after your ADFS was setup. Near to the expiration period you will get the following notification on your Portal Admin Page.
This notification do not apply to SSL Certificate, also known as Service Communications Certificate.


W14



 W15


 



The number of days represents the day where the service will stop. Due to certificate change.


How to calculate the effective day:


The new Certificate will be generated 20 days before the certificate expirations date:
1) Go to Powershell
2) Connect-MsolService
3) Get-MsolFederationProperty
4) Check [CertificateGenerationThreshold: 20]


The new certificate will be promoted to Primary after 5 days:
1) Go to Powershell
2) Connect-MsolService
3) Get-MsolFederationProperty
4) Check [CertificatePromotionThreshold: 5]


Knowing that AD FS Service only uses the primary certificate, as we will switch the certificates 15 days before the current primary certificates expires the service will stop 15 days before the current certificate expiration.


This is not true if the Relying party has been updated on the 5 days that exist between the new certificate creation and the promotion.


Example:
Certificate expires on 30-01-2014.
New certificate will be created on 10-01-1014 and will be marked as Secondary [20 days before expiration].
On the 15-01-2014 the Secondary Certificate is promoted to Primary [5 days after new certificate generation].
If we see the message on the portal on the day 05-01-2014 this should be informing that the service will stop in 10 days, if federation metadata information is not updated.



ADFS default configuration:

Default configuration on AD FS regarding Token Signing and Token Decrypting certificates includes an auto-renewal process, [AutoCertificateRollover].

If you did not change this value from “True” to “False”, no renewal operation regarding token certificates is needed, this will happen automatically based on triggers explained below.



Default values of ADFS - [see details below for default values]:

The Rollover interval is checked by the AD FS service every 720 minutes (12 hours).
If the existing primary certificate (Token Signing or Token Decryption) expiration time is within the window of the CertificateGenerationThreshold value (20 days), then a new certificate is generated and configured as the secondary certificate.
Noted by event ID 385 in the event logs: It will remain as the secondary certificate until the CertificatePromotionThreshold value is observed (5 days). So, 5 days after creation of the certificate, it will be promoted and the existing primary will be configured as the secondary until the next CertificateGenerationThreshold window is observed.

Once the Promotion event has occurred, the Token Service will sign/encrypt all issued tokens with the new primary certificate.

This does not cause a service outage of AD FS 2.0, but an application issue when the token is received and signed with something other than the expected certificate. This is true for O365 or any other application.

With AutoCertificateRollover enabled, AD FS 2.0 will continue to function as expected.



Validate your ADFS configuration:

To validate your configuration, connect to your primary ADFS Server and follow these PowerShell instructions:

Open the Windows PowerShell
Add-PSSnapin Microsoft.ADFS.PowerShell
Get-ADFSProperties

CertificateCriticalThreshold: 2 - Days prior to expiry of the certificate before a new certificate is generated and promoted if AutoCertificateRollover has not performed naturally.

CertificateDuration: 365 - Validity period of the auto-generated Certificate.

CertificateGenerationThreshold: 20 - Days before expiration of current primary a new certificate will be generated.

CertficatePromotionThreshold: 5 - Days the newly generated certificate will exist before being promoted from secondary to primary.

CertificateRolloverInterval: 720 - Interval in minutes at which we check to see if a new certificate needs to be generated.

CertificateThresholdMulitplier: 1440 - Number of minutes used in calculation of other threshold counters (default value is 1440 minutes or 24 hrs. X 60 minutes, which makes threshold values equal to full days).



To have single sign on with ADFS the federation certificates need to be updated with the online platform. O365 is now automatically pulling the certificates from the AD FS server via the public metadata endpoint on a regular basis.


You may need to manually update the federation metadata using the PowerShell in complement to the Microsoft pull mechanism, as this will not pull the certificates on all scenarios.


To setup this to run automatically on your infrastructure implement the following script:
https://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc.

]]> [English] What do I have to do if I received the alert on the Office 365 portal or an E-mail informing that one of the federation services certificates is expiring https://docs.microsoft.com/archive/blogs/tfg/english-what-do-i-have-to-do-if-i-received-the-alert-on-the-office-365-portal-or-an-e-mail-informing-that-one-of-the-federation-services-certificates-is-expiring Sun, 20 Apr 2014 14:56:00 GMT https://blogs.technet.microsoft.com/tfg/2014/04/20/english-what-do-i-have-to-do-if-i-received-the-alert-on-the-office-365-portal-or-an-e-mail-informing-that-one-of-the-federation-services-certificates-is-expiring/ [English] - Content Developed by the Shared Services Support Team.





This information is normally related to the Token-Signing and Token-Decrypting Certificates.


To overcome the current situation, most of the times you do not need to do anything. By default, your ADFS server is configured for “AutoCertificateRollover”. This means that the new certificates will be automatically generated and promoted to primary. You simply need to confirm that your on-premises AD FS infrastructure is configured as displayed:

1) Go to Powershell
2) Get-ADFSProperties |fl AutoCertificateRollover




If the output is “AutoCertificateRollover: True”, you do not need to do anything, your Token-Signing and Token-Decrypting Certificates will update automatically. You can also check that "NextTokenSigningCertificate" contains the information of the next certificate to be used:

1) Go to Powershell
2) Connect-MsolService
3) Get-MsolFederationProperty
4) Check "NextTokenSigningCertificate" information for both "ADFS Server" and "Microsoft Office 365".


On rare occasions, after the automatic switch to the new Certificates, you might need to update the O365 federation information:

Option a)
Check if you previously have installed the automatic update federation tool:




If not, install it using the following script - Microsoft Office 365 Federation Metadata Update Automation Installation Tool - https://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc.


Option b)
Manually update federation information (only needed once after the Certificates renewal)
1) Connect-MsolService
2) Insert O365 Admin Credentials
3) Update-MsolFederatedDomain -DomainName yourdomain.name -SupportMultipleDomain


And that’s it.


If for some reason the “AutoCertificateRollover: false”, please find guidance on the following article https://social.technet.microsoft.com/wiki/contents/articles/2554.ad-fs-2-0-how-to-replace-the-ssl-service-communications-token-signing-and-token-decrypting-certificates.aspx.


Additional Notes:
To now more about Certificates on ADFS, please go to the following article https://social.technet.microsoft.com/wiki/contents/articles/2554.ad-fs-2-0-how-to-replace-the-ssl-service-communications-token-signing-and-token-decrypting-certificates.aspx

To understand the difference in the date displayed on the alert message, and the date of expire of the certificate on the ADFS, a new article is available on this blog https://blogs.technet.com/b/tfg/archive/2014/04/21/token-signing-and-token-decrypt-certificates-expiration-process-and-dates.aspx.

]]> [Português] Associar Subscrição do Azure ao Directório do Office 365 / [English] Link Azure Subscription with Office 365 Directory https://docs.microsoft.com/archive/blogs/tfg/portugus-associar-subscrio-do-azure-ao-directrio-do-office-365-english-link-azure-subscription-with-office-365-directory Thu, 16 Jan 2014 14:57:00 GMT https://blogs.technet.microsoft.com/tfg/2014/01/16/portugus-associar-subscrio-do-azure-ao-directrio-do-office-365-english-link-azure-subscription-with-office-365-directory/ [Português]
> Aceder a https://manage.windowsazure.com/.
> Efetuar o login com a Microsoft account (live.com, hotmail.com, outlook.com, etc.).
> Ir para Active Directory > Directory > ADD.
> Selecionar "Use existing directory".
> Selecionar a opção "I am ready to be signed out now" e Continuar (redireccionamento para o login do Office 365).
> Login com a conta de global admin do Office 365 e Continuar.
> [Atualização - Não é necessário introduzir manualmente o URL] Depois do redireccionamento para o login do Azure novamente, não continue, em vez disso deve inserir manualmente o URL https://manage.windowsazure.com/.
> Efectue o login novamente no Azure with com a Microsoft Account e verifique a existência de dois diretórios na opção de Active Directory, uma correspondente ao Azure default, e a outra referente ao Office 365.
> Para permitir que os users do diretório do Office 365 possam ser adicionados como Co-Administrators da subscrição do Azure > Selecione Settings (Azure) > Subscriptions.
> Selecione a Azure Subscription > Edit Directory > Escolha o Diretório do Office 365 e termine o processo.
> A partir deste momento os users da default Azure Directory não poderão ser adicionados como Co-Administrators do Azure, apenas os users do Diretório do Office 365.


[English]
> Go to https://manage.windowsazure.com/.
> Login with the Microsoft account (live.com, hotmail.com, outlook.com, etc.).
> Go to Active directory > Directory > ADD.
> Select "Use existing directory".
> Select the box "I am ready to be signed out now" and Continue (redirection to Office 365 Login).
> Login with Office 365 Global Admin account and Continue with the Wizard.
> [Update - No longer needed to insert the URL manually] After redirection to the Azure login page, do not continue, instead, manually insert the URL on the address bar https://manage.windowsazure.com/.
> Login again into Azure with the Microsoft Account and Check Active Directory for the two Directories, one, the Azure default, and the other, with the Office 365 users.
> To enable the users from the Office 365 directory to be added as co-administrators for the Azure subscription, go to Settings (on Azure) > Subscriptions.
> Select the Azure Subscription > Edit Directory > Choose Office 365 Directory and Finish.
> From this time on, users from the default Azure Directory, cannot be used as Co-Administrators, only users from Office 365 Organizational Directory.

]]>