Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

Archive for the ‘Windows Azure Active Directory’ Category

(2019-05-22) Some Basic Steps For Troubleshooting PRTs

Posted by Jorge on 2019-05-22


In Windows 10 currently there are 2 PRTs:

  • The Azure AD Primary Refresh Token
  • And the Enterprise Primary Refresh Token, a.k.a. the ADFS Primary Refresh Token

For both the following troubleshooting steps apply if you are experiencing issues somehow:

  • Always check the output of: DSREGCMD.EXE /STATUS
  • Event Logs to check on the client:
    • “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log
    • “Applications And Services Log\Microsoft\Windows\User Device Registration\Admin” Event Log
  • Any correlation ID in any event related to the error experienced on the client, can most like also be found at server side in the corresponding event log. If server side is AAD, then you need Microsoft. If server side is ADFS, then you can check it yourself
  • Changing or resetting the password, invalidates the current PRTs and fresh ones are retrieved/generated
  • If a PRT is missing, triggering to try to retrieve a PRT can be done by either logoff/logon or lock/unlock

With this information you should have a good start to try troubleshooting PRT related issues, although not always easy!

Do not forget to also read Jairo’s blog post about how SSO works in Windows 10

Enjoy and have fun!,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Advertisements

Posted in Active Directory Federation Services (ADFS), Azure AD PRT, Enterprise PRT, Windows Azure Active Directory | Leave a Comment »

(2019-05-16) Azure AD Connect v1.3.21.0 Has Been Released

Posted by Jorge on 2019-05-16


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

Download "Microsoft Azure Active Directory Connect"

Azure AD Connect: Version Release History

1.3.21.0

Released: 05/14/2019

Released for download

Prerequisites for Azure AD Connect

More information about Azure AD Connect

New Features And Improvements

  • N.A.

Fixed issues

  • Fixed an elevation of privilege vulnerability that exists in Microsoft Azure Active Directory Connect build 1.3.20.0. This vulnerability, under certain conditions, may allow an attacker to execute two powershell cmdlets in the context of a privileged account, and perform privileged actions. This security update addresses the issue by disabling these cmdlets. For more information see security update.

I ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle!

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Connect, Windows Azure Active Directory | Leave a Comment »

(2019-04-30) Azure AD Connect v1.3.20.0 Has Been Released

Posted by Jorge on 2019-04-30


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

Download "Microsoft Azure Active Directory Connect"

IMPORTANT: I upgraded from Azure AD Connect 1.2.70.0. As mentioned below in the “New Features And Improvements” section it upgrades a group sync rule to include additional transformations (flows). To be more specific it updates the sync rule called “In from AD – Group Common”. If you have this rule enabled it will most likely perform a full sync for at least the AD connector the next time it syncs after the AAD Connect upgrade. If you have this rule enabled disabled, that means you have a cloned version of it that requires updating if you need those additional transformations (flows) to support group claims in AAD. If you do update that cloned version, then it will most likely perform a full sync for both the AD connector the next time it syncs after the AAD Connect upgrade. Since that may take some time, depending on the size of your AD/AAD environment in terms of number objects being synched, make sure that you have taken the necessary steps to support this or hold off on upgrading until you have found a convenient moment to do so.

However, to my surprise it did not trigger the expected full sync for the AD connector. That was weird, because when sync rules are updated all data needs to be reevaluated, whether or not it has changed. In my case I triggered the full sync myself by running the Run Profiles manually for both the AD Connector and the AAD Connector. The order was: Disable Sync Scheduler, Delta Import for AD Connector, Full Sync for AD Connector, Export for AAD Connector, Delta Import for AAD Connector, Delta Sync for AAD Connector, Export for AD Connector and Re-enable Sync Scheduler.

Azure AD Connect: Version Release History

1.3.20.0

Released: 04/24/2019

Released for download

Prerequisites for Azure AD Connect

More information about Azure AD Connect

New Features And Improvements

  • Add support for Domain Refresh
  • Exchange Mail Public Folders feature goes GA
  • Improve wizard error handling for service failures
  • Added warning link for old UI on connector properties page.
  • The Unified Groups Writeback feature is now GA
  • Improved SSPR error message when the DC is missing an LDAP control
  • Added diagnostics for DCOM registry errors during install
  • Improved tracing of PHS RPC errors
  • Allow EA creds from a child domain
  • Allow database name to be entered during install (default name ADSync)
  • Upgrade to ADAL 3.19.8 to pick up a WS-Trust fix for Ping and add support for new Azure instances
  • Modify Group Sync Rules to flow samAccountName, DomainNetbios and DomainFQDN to cloud – needed for claims
  • Modified Default Sync Rule Handling – read more here.
  • Added a new agent running as a windows service. This agent, named “Admin Agent”, enables deeper remote diagnostics of the Azure AD Connect server to help Microsoft Engineers troubleshoot when you open a support case. This agent is not installed and enabled by default. For more information on how to install and enable the agent see What is the Azure AD Connect Admin Agent?.
  • Updated the End User License Agreement (EULA)
  • Added auto upgrade support for deployments that use AD FS as their login type. This also removed the requirement of updating the AD FS Azure AD Relying Party Trust as part of the upgrade process.
  • Added an Azure AD trust management task that provides two options: analyze/update trust and reset trust.
  • Changed the AD FS Azure AD Relying Party trust behavior so that it always uses the -SupportMultipleDomain switch (includes trust and Azure AD domain updates).
  • Changed the install new AD FS farm behavior so that it requires a .pfx certificate by removing the option of using a pre-installed certificate.
  • Updated the install new AD FS farm workflow so that it only allows deploying 1 AD FS and 1 WAP server. All additional servers will be done after initial installation.

Fixed issues

  • Fix the SQL reconnect logic for ADSync serviceFix to allow clean Install using an empty SQL AOA DB
  • Fix PS Permissions script to refine GWB permissions
  • Fix VSS Errors with LocalDB
  • Fix misleading error message when object type is not in scope
  • Corrected an issue where installation of Azure AD PowerShell on a server could potentially cause an assembly conflict with Azure AD Connect.
  • Fixed PHS bug on Staging Server when Connector Credentials are updated in the old UI.
  • Fixed some memory leaks
  • Miscellaneous Autoupgrade fixes
  • Miscellaneous fixes to Export and Unconfirmed Import Processing
  • Fixed a bug with handling a backslash in Domain and OU filtering
  • Fixed an issue where ADSync service takes more than 2 minutes to stop and causes a problem at upgrade time.

I ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle!

…And just to get ahead of things when needed I also installed the Azure AD Connect Admin Agent in a disabled state. By the way, as mentioned in the documentation, you will be prompted multiple times (about 5x or so) for credentials. So, don’t freak out thinking it is not working.

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Connect, Windows Azure Active Directory | Leave a Comment »

(2018-12-30) Azure AD Connect v1.2.70.0 Has Been Released

Posted by Jorge on 2018-12-30


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

Download "Microsoft Azure Active Directory Connect"

Azure AD Connect: Version Release History

1.2.70.0

Released: 12/18/2018

Released for download

Prerequisites for Azure AD Connect

More information about Azure AD Connect

Fixed issues

  • This build updates the non-standard connectors (for example, Generic LDAP Connector and Generic SQL Connector) shipped with Azure AD Connect. For more information on applicable connectors, see version 1.1.911.0 in Connector Version Release History.

I (finally) ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle!

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Connect, Windows Azure Active Directory | Leave a Comment »

(2018-12-30) Azure AD Connect v1.2.69.0 Has Been Released

Posted by Jorge on 2018-12-30


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications
  • Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

Download "Microsoft Azure Active Directory Connect"

IMPORTANT: I upgraded from Azure AD Connect v1.2.68.0, and the next time it synched after performing the steps below it triggered a full import and full sync for both the AD connector and the AAD connector. Since this may take some time, depending on the size of your AD/AAD environment in terms of number objects being synched, make sure that you have taken the necessary steps to support this or hold off on upgrading until you have found a convenient moment to do so.

Azure AD Connect: Version Release History

1.2.69.0

Released: 12/11/2018

Released for download

Prerequisites for Azure AD Connect

More information about Azure AD Connect

Fixed issues

  • This hotfix build allows the user to select a target domain, within the specified forest, for the RegisteredDevices container when enabling device writeback. In the previous versions that contain the new Device Options functionality (1.1.819.0 – 1.2.68.0), the RegisteredDevices container location was limited to the forest root and did not allow child domains. This limitation only manifested itself on new deployments – in-place upgrades were unaffected.
  • If any build containing the updated Device Options functionality was deployed to a new server and device writeback was enabled, you will need to manually specify the location of the container if you do not want it in the forest root. To do this, you need to disable device writeback and re-enable it which will allow you to specify the container location on the “Writeback forest” page.

I (finally) ran the MSI and upgraded from the previous version without any issues (except for what I mentioned below!) and ran at least one scheduled sync cycle!

After the upgrade I noticed the following, which was weird! Device writeback was enabled and configured correctly. I have one single AD domain. No idea why this happened. This was not a new server as the second bullet mentions in the “fixed issues” section mentions above.

After the next sync I started seeing….

The upper 2 are devices synched from AAD to AD, the lower 2 are Windows 10 devices being synched from AD to AAD.

image

Figure 1: “Container-Not-In-Scope” Errors

After checking the device writeback config, it was empty!

Get-ADSyncGlobalSettingsParameter | ?{$_.name -like "Microsoft.DeviceWriteBack*"}

image

Figure 2: Device Writeback NOT Being Enabled And Configured After The Upgrade

Checking the Azure AD Connect Wizard it said it was enabled. Again, weird!

My solution for this were the following steps

  • Disable the sync scheduler

Set-ADSyncScheduler -SyncCycleEnabled $false # <— By The Way, Should ALWAYS Be Executed Before An Upgrade Of AAD Connect To Make Sure The Sync DOES NOT Start

  • Using The Azure AD Connect Wizard: Disable Device Writeback
    • Start AAD Connect Wizard –> Click [Configure] –> Select [Configure Device Options] –> Click [Next] (2x) –> Enter AAD Global Credentials –> Select “Disable Device Writeback” –> Click [Next] –> Click [Configure] –> Click [Exit])

  • Using The Azure AD Connect Wizard: Reenable Device Writeback
    • Start AAD Connect Wizard –> Click [Configure] –> Select [Configure Device Options] –> Click [Next] (2x) –> Enter AAD Global Credentials –> Select “Configure Device Writeback” –> Click [Next] –> Select the AD Forest And AD Domain To Host The Synched Devices From AAD –> Enter AD Enterprise Admin Credentials Or Select The Option To Download The PowerShell Script –> Click [Next] –> Click [Configure] –> Click [Exit])

  • Check The Device Writeback Configuration
    • Get-ADSyncGlobalSettingsParameter | ?{$_.name -like "Microsoft.DeviceWriteBack*"}

image

Figure 3: Device Writeback Being Enabled And Configured

  • Reenable the sync scheduler

Set-ADSyncScheduler -SyncCycleEnabled $true # <—Should ALWAYS Be Executed AFTER A Successful And Verified Upgrade Of AAD Connect To Make Sure The Sync DOES Start The Next Schedule

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Connect, Windows Azure Active Directory | Leave a Comment »

(2018-12-30) Azure AD Connect v1.2.68.0 Has Been Released

Posted by Jorge on 2018-12-30


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

Download "Microsoft Azure Active Directory Connect"

Azure AD Connect: Version Release History

1.2.68.0

Released: 11/30/2018

Released for download

Prerequisites for Azure AD Connect

More information about Azure AD Connect

Fixed issues

  • This hotfix build fixes a conflict where an authentication error might occur due to the independent presence of the MSOnline PowerShell Gallery module on the synchronization server

I (finally) ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle!

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Connect, Windows Azure Active Directory | Leave a Comment »

(2018-12-30) Azure AD Connect v1.2.67.0 Has Been Released

Posted by Jorge on 2018-12-30


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

Download "Microsoft Azure Active Directory Connect"

Azure AD Connect: Version Release History

1.2.67.0

Released: 11/19/2018

Released for download

Prerequisites for Azure AD Connect

More information about Azure AD Connect

IMPORTANT: I upgraded from Azure AD Connect v1.2.65.0, and the next time it synched it triggered a full sync for the AD connector. Since this may take some time, depending on the size of your AD environment in terms of number objects being synched, make sure that you have taken the necessary steps to support this or hold off on upgrading until you have found a convenient moment to do so.

Fixed issues
  • This hotfix build fixes a regression in the previous build where Password Writeback fails when using an ADDS Domain Controller on Windows Server 2008/R2

I (finally) ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle!

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Connect, Windows Azure Active Directory | Leave a Comment »

(2018-11-05) Azure AD Connect v1.2.65.0 Has Been Released

Posted by Jorge on 2018-11-05


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

Download "Microsoft Azure Active Directory Connect"

Azure AD Connect: Version Release History

1.2.65.0

Released: 10/25/2018

Released for download

Prerequisites for Azure AD Connect

More information about Azure AD Connect

IMPORTANT: I upgraded Azure AD Connect v1.1.882, and the next time it synched it triggered a full import and full sync for both the AD connector and the AAD connector. Since this may take some time, depending on the size of your AD/AAD environment in terms of number objects being synched, make sure that you have taken the necessary steps to support this or hold off on upgrading until you have found a convenient moment to do so.

New features and improvements
  • Changed the functionality of attribute write-back to ensure hosted voice-mail is working as expected. Under certain scenarios, Azure AD was overwriting the msExchUcVoicemailSettings attribute during write-back with a null value. Azure AD will now no longer clear the on-premises value of this attribute if the cloud value is not set.
  • Added diagnostics in the Azure AD Connect wizard to investigate and identify Connectivity issues to Azure AD. These same diagnostics can also be run directly through Powershell using the Test- AdSyncAzureServiceConnectivity Cmdlet.
  • Added diagnostics in the Azure AD Connect wizard to investigate and identify Connectivity issues to AD. These same diagnostics can also be run directly through Powershell using the Start-ConnectivityValidation function in the ADConnectivityTools Powershell module. For more information see What is the ADConnectivityTool PowerShell Module?
  • Added an AD schema version pre-check for Hybrid Azure Active Directory Join and device write-back
  • Changed the Directory Extension page attribute search to be non-case sensitive.
  • Added full support for TLS 1.2. This release supports all other protocols being disabled and only TLS 1.2 being enabled on the machine where Azure AD Connect is installed. For more information see TLS 1.2 enforcement for Azure AD Connect

Fixed issues
  • Fixed a bug where Azure AD Connect Upgrade would fail if SQL Always On was being used.
  • Fixed a bug to correctly parse OU names that contain a forward slash.
  • Fixed an issue where Pass-Through Authentication would be disabled for a clean install in staging mode.
  • Fixed a bug that prevented the PowerShell module to be loaded when running the Troubleshooting tools
  • Fixed a bug that would block customers from using numeric values in the first character of a host name.
  • Fixed a bug where Azure AD Connect would allow invalid partitions and container selection
  • Fixed the “Invalid Password” error message when Desktop SSO is enabled.
  • Various Bug fixes for AD FS Trust Management
  • When configuring Device Writeback – fixed the schema check to look for the msDs-DeviceContainer object class (introduced on WS2012 R2)

I (finally) ran the MSI and upgraded from the previous version without any issues!

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Connect, Windows Azure Active Directory | Tagged: , | Leave a Comment »

(2018-11-01) Deploying The Sample Azure AD GraphAPI B2B Web Portal, Starting From “App Registrations (Preview)”

Posted by Jorge on 2018-11-01


If you are interested in Azure AD B2B, and especially in the self-service part, you may also be interested in deploying and testing the sample Azure AD GraphAPI B2B Web Portal. I’m one of those persons that falls into that category!

The sample Azure AD GraphAPI B2B Web Portal can be found here. A detailed instruction to configure and deploy can be found here.

Reasons for this blog post are:

  • You should be good when starting from “App Registrations”, but if you start from “App Registrations (Preview)” (or whatever it will be called in the future), then some steps are slightly different and you may or may not understand what you need to do;
  • The sample Azure AD GraphAPI B2B Web Portal may not work in the end, which needs fixing.

So, let’s get started while starting from “App Registrations (Preview)”

[Step 1] Determine Your Tenant ID

No changes in the steps

[Step 2] Registering The AAD B2B Admin Application

When creating a new registration for the AAD B2B Admin Application, go to the “App Registrations (Preview)” and click “New Registration”

  • For the “user-facing display name for this application” enter for example “Azure AD B2B Admin Application”
  • For the “Supported Account Types” choose “Accounts In This Organization Directory Only” (meaning, all user accounts and all guests accounts from this directory only)
  • For the “Redirect URI” choose “Web” and as a URL specify “https://loopback” (will be updated later!)
  • At the bottom click “Register”

image

Figure 1: Registering The Azure AD B2B Admin Application

Right after registering, it will open in the “Overview” node.

  • Write down the “application ID” which is required later in the Web Application/App Service as the client ID for the admin application

image

Figure 2: Overview Details Of The Azure AD B2B Admin Application

Click on the “Authentication” node

  • Make sure to check “ID Tokens” or you will have some fun later on!
  • Click on SAVE at the top

image

Figure 3: Selecting The Required Token For The Implicit Grant Flow

Click on the “Certificates And Secrets” node

  • Click on “New Client Secret”

image

Figure 4: The Certificates And Secrets Page

  • As a “Description” enter for example “Azure AD B2B Admin Application Secret – Key 1”
  • Select an expiration period that you are comfortable with
  • Click ADD

image

Figure 5: Adding A Client Secret For The Azure AD B2B Admin Application

  • Make sure to copy or write down the value as you will not have a chance to get it back later!

image

Figure 6: Client Secret Defined For The Azure AD B2B Admin Application

Click on the API Permissions node

  • If correct, the “Delegated” permission for “Sign In And Read User Profile” is already configured
  • Click on Add A Permission

image

Figure 7: API Permissions For The Azure AD B2B Admin Application

  • On the new pane at the right that opens click on Microsoft Graph

image

Figure 8: Selecting The Microsoft Graph As The API To Grant Permissions To

  • If the “Delegated” permissions are not yet configured, click on “Delegated Permissions”, otherwise skip this step

    • Scroll down to User and expand User and select User.Read (“Sign In And Read User Profile”)

    • Click Add Permissions

image

Figure 9: Selecting Delegated Permissions

image

Figure 10: User Permissions To Assign As Delegated Permissions

  • Click on Add A Permission

    • On the new pane at the right that opens click on Microsoft Graph

    image

    Figure 11: Selecting The Microsoft Graph As The API To Grant Permissions To

      • Click on “Application Permissions”
        • Scroll down to Directory and expand Directory and select Directory.ReadWrite.All (“Read And Write Directory Data”)
        • Scroll down to User and expand User and select User.ReadWrite.All (“Read And Write All Users’ Full Profiles”)
        • Click Add Permissions

      image

      Figure 12: Selecting Application Permissions

      image

      Figure 13: Directory Permissions To Assign As Application Permissions

      image

      Figure 14: User Permissions To Assign As Application Permissions

      [Step 3] Registering The AAD B2B Pre-AuthN Application

      When creating a new registration for the AAD B2B Pre-AuthN Application, go to the “App Registrations (Preview)” and click “New Registration”

      • For the “user-facing display name for this application” enter for example “Azure AD B2B Pre-AuthN Application”
      • For the “Supported Account Types” choose “Accounts In Any Organization Directory And Personal Microsoft Accounts” (meaning, any user account from any Azure AD directory and any personal Microsoft Account) OR choose “Accounts In Any Organization Directory” (meaning, any user account from any Azure AD directory)
      • For the “Redirect URI” choose “Web” and as a URL specify “https://loopback” (will be updated later!)
      • At the bottom click “Register”

      image

      Figure 15: Registering The Azure AD B2B Pre-AuthN Application

      Right after registering, it will open in the “Overview” node.

      • Write down the “application ID” which is required later in the app service as the client ID for the pre-authN application

      image

      Figure 16: Overview Details Of The Azure AD B2B Pre-AuthN Application

      Click on the “Authentication” node

      • Make sure to check “Access Tokens” and “ID Tokens” or you will have some fun later on!
      • Click on SAVE at the top

      image

      Figure 17: Selecting The Required Tokens For The Implicit Grant Flow

      Click on the “Certificates And Secrets” node

      • Click on “New Client Secret”

      image

      Figure 18: The Certificates And Secrets Page

      As a “Description” enter for example “Azure AD B2B Admin Application Secret – Key 1”

      • Select an expiration period that you are willing to accept
      • Click ADD

      image

      Figure 19: Adding A Client Secret For The Azure AD B2B Pre-AuthN Application

      • Make sure to copy or write down the value as you will not have a chance to get it back later!

      image

      Figure 20: Client Secret Defined For The Azure AD B2B Pre-AuthN Application

      Click on the “API Permissions” node

      • If correct, the “Delegated” permission for “Sign In And Read User Profile” is already configured
      • If the “Delegated” permissions are not yet configured (otherwise skip this step)
        • Click on “Click on Add A Permission”
        • Click on “Microsoft Graph”
        • Click on “Delegated Permissions”
        • Scroll down to User and expand User and select User.Read (“Sign In And Read User Profile”
        • Click Add Permissions

      image

      Figure 21: API Permissions For The Azure AD B2B Pre-AuthN Application

      image

      Figure 22: Selecting The Microsoft Graph As The API To Grant Permissions To

      image

      Figure 23: Selecting Delegated Permissions

      image

      Figure 24: User Permissions To Assign As Delegated Permissions

      Click on the “Manifest” node

      • Find the line "oauth2AllowImplicitFlow", and change "false" to "true". Don’t include quotes, just replace the word.
      • Click SAVE

      image

      Figure 25: Editing The Manifest

      [Step 4] Deploying The Web Application

      No changes in the steps

      [Step 5] Post Configuration Cleanup

      No changes in the steps for the The Azure AD B2B Admin Application

      However, for the The Azure AD B2B Pre-AuthN Application, you should specify 2 reply URLs instead of just 1.

      The following Reply URLs must be specified:

      image

      Figure 26: Reply URLs For The Azure AD B2B Pre-AuthN Application

      [Step 6] Trying It Out

      Navigate to the URL of the Web Application and you will see the following

      image

      Figure 27: Notification The B2B Portal Requires Configuration By An Admin

      After clicking on Admin Sign In on the right and signing in, you should see

      image

      Figure 28: Site Configuration Screen For The B2B Portal

      …but if you see

      image

      Figure 29: Error Notification Something Is Wrong

      Error

      An error occurred while processing your request.

      link: /Home/Error?message=unsupported_response_type">https://<Web_Application_URL>/Home/Error?message=unsupported_response_type

      Something is really wrong (duh!)

      Now retry it again until you need to authenticate, but don’t!. Now look at the URL which should be similar to the one below

      image

      Figure 30: The URL At The Time Of Authentication

      It is expecting a response type of “code” and “id_token” for the client with ID as specified by the red arrow (which is the Application ID of the Admin application registration)

      have you checked “ID Token” for the Admin application registration? If not, then go back and check it (Picture 3)

      After changing that, retry and it should work!

      In all three cases below, when the invited user logs in to /Profile">https://<Web_Application_URL>/Profile, everything is OK.

      However, as soon as the user tries to sync its profile from its home tenant to the inviting tenant, you will experience the following:

      … if the “ID Token” is not checked for the Azure AD B2B Pre-AuthN Application (Figure 17)

      image

      Figure 31: Error When The “ID Token” Is Not Selected For The Azure AD B2B Pre-AuthN Application

      … if only one reply URL is configured (main URL for the web application) and not 2 as shown in figure 26

      image

      Figure 32: Error When The “ID Token” Is Not Selected For The Azure AD B2B Pre-AuthN Application

      … if the “Access Token” is not checked for the Azure AD B2B Pre-AuthN Application (Figure 17)

      image

      Figure 33: Error When The “Access Token” Is Not Selected For The Azure AD B2B Pre-AuthN Application

      Cheers,
      Jorge

      ————————————————————————————————————————————————————-
      This posting is provided "AS IS" with no warranties and confers no rights!
      Always evaluate/test everything yourself first before using/implementing this in production!
      This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
      DISCLAIMER:
      https://jorgequestforknowledge.wordpress.com/disclaimer/
      ————————————————————————————————————————————————————-
      ########################### Jorge’s Quest For Knowledge ##########################
      ####################
      http://JorgeQuestForKnowledge.wordpress.com/ ###################
      ————————————————————————————————————————————————————-

      Posted in Azure AD B2B, Windows Azure Active Directory | Leave a Comment »

      (2018-10-26) Running The Azure AD Password Protection Summary Report May Generate An Error

      Posted by Jorge on 2018-10-26


      When on one of the Azure AD Password Protection Proxy servers, you can generate an Azure AD Password Protection Summary report through one of the following commands:

      Targeting a specific DC:

      Get-AzureADPasswordProtectionSummaryReport -DomainController <RWDC FQDN>

      Targeting all DCs in a specific AD Domain:

      Get-AzureADPasswordProtectionSummaryReport -Domain <AD DOMAIN FQDN>

      Targeting all DCs in a specific AD Forest:

      Get-AzureADPasswordProtectionSummaryReport -Forest <AD FOREST FQDN>

      Targeting all DCs in the local AD Forest:

      Get-AzureADPasswordProtectionSummaryReport

      So, whatever your targeted scope is, if all DCs have have the Azure AD Password Protection DC Agent installed, they will also have the corresponding event logs, which are:

      Get-WinEvent -ListLog * | ?{$_.LogName -like "*AzureADPasswordProtection*"}

      image

      Figure 1: All The Azure AD Password Protection DC Agent Event Logs On An RWDC

      ….and for completeness on the Azure AD Password Protection Proxy servers

      Get-WinEvent -ListLog * | ?{$_.LogName -like "*AzureADPasswordProtection*"}

      image

      Figure 2: All The Azure AD Password Protection Proxy Event Logs On The Proxy Servers

      However, if you see errors similar to the one below…

      image

      Figure 2: Error When Generating The Azure AD Password Protection Summary Report Against Targeted DCs

      …then the targeted event logs are missing. And of the events logs are missing, then the Azure AD Password Protection DC Agent is most likely not installed on the RWDC.

      Solution? Install the Azure AD Password Protection DC Agent on the RWDC that throws the error.

      Please be aware that querying for DCs that have the Service Connection Point (SCP) registered in AD, may not be accurate. Why? If you installed the Azure AD Password Protection DC Agent and then uninstall it, for whatever reason, the SCP for that RWDC is not cleaned during the uninstall. Also be aware that if you force removed any DC and did not clean up its metadata, you will be trying to reach an RWDC that does not exist anymore when running the summary report.

      Although more intense, the most accurate way is checking for any of the following:

      • If the Azure AD Password Protection DC Agent is installed (against every RWDC –> Get-WmiObject -Class win32_product -Filter "Name like ‘Azure AD Password Protection DC Agent’")
      • If the Azure AD Password Protection DC Agent service is installed (against every RWDC –> Get-Service AzureADPasswordProtectionDCAgent)
      • If the Azure AD Password Protection DC Agent is installed (against every RWDC –> Get-WinEvent -ListLog * | ?{$_.LogName -like "*AzureADPasswordProtection*"})

      Cheers,
      Jorge

      ————————————————————————————————————————————————————-
      This posting is provided "AS IS" with no warranties and confers no rights!
      Always evaluate/test everything yourself first before using/implementing this in production!
      This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
      DISCLAIMER:
      https://jorgequestforknowledge.wordpress.com/disclaimer/
      ————————————————————————————————————————————————————-
      ########################### Jorge’s Quest For Knowledge ##########################
      ####################
      http://JorgeQuestForKnowledge.wordpress.com/ ###################
      ————————————————————————————————————————————————————-

      Posted in Azure AD Password Protection, Windows Azure Active Directory | Leave a Comment »

       
      %d bloggers like this: