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

(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/ ###################
————————————————————————————————————————————————————-

Advertisements

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 »

      (2018-10-25) When Installing The Azure AD Password Protection DC Agent Generates An Error

      Posted by Jorge on 2018-10-25


      If you are installing the Azure AD Password Protection DC Agent on an RWDC and you receive the following error….

      image

      Figure 1: An Error The Azure AD Password Protection DC Agent Setup Wizard Ended Prematurely

      ….execute the AADPwdProtection\AzureADPasswordProtectionDCAgent.msi with the following options

      MSIEXEC /i AzureADPasswordProtectionDCAgent.msi /log AzureADPasswordProtectionDCAgent.log

      After it errors again, open the log file and search for the word ERROR. When you do, you will most likely find why it errors. If it has the same cause as I had, you will see something similar to the following:

      Dumping MSI properties of interest:
        ‘INSTALLDIR’ = ‘C:\Program Files\Azure AD Password Protection DC Agent\’
        ‘Installed’ = ”
        ‘INSTALLLEVEL’ = ‘1’
        ‘ProductCode’ = ‘{67E66797-A45C-4C3C-B481-554F9F427227}’
        ‘ProductID’ = ”
        ‘ProductName’ = ‘Azure AD Password Protection DC Agent’
        ‘ProductState’ = ‘-1’
        ‘ProductVersion’ = ‘1.2.10.0’
        ‘ProgramFiles64Folder’ = ‘C:\Program Files\’
        ‘Remove’ = ”
        ‘UPGRADINGPRODUCTCODE’ = ”
        ‘BPL_NONUPGRADEABLEAPPFOUND’ = ”
        ‘BPL_STATEMIGRATIONFOLDER’ = ”
      Done with MSI property dump
      CheckForNonUpgradeableApps – opened Uninstall key with 9 subkeys
      CheckForNonUpgradeableApps – a nonupgradeable app was found ‘Azure AD Password Protection DC Agent’ – ‘1.1.10.3’
      CustomAction BPL_CheckForNonUpgradeableApps returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
      Action ended 16:30:01: BPL_CheckForNonUpgradeableApps. Return value 3.
      Action ended 16:30:01: INSTALL. Return value 3.


      In plain English this means you are trying to install a newer version on top of an version that cannot be upgraded. Check the versions. The old version here was installed by means months ago when I participated in the public preview. Today I wanted to install the officially released version and had forgotten the old version was still installed.

      The solution here? Uninstall the old version first and install the newer version. After both the uninstall and the install a reboot of the RWDC is required.

      To determine if a version is already installed and if yes to uninstall it, execute the following commands:

      WMIC PRODUCT GET NAME | FIND /I "Azure AD Password Protection DC Agent"

      WMIC PRODUCT WHERE NAME="Azure AD Password Protection DC Agent" CALL UNINSTALL

      ….and if you are a PowerShell junky, you can also use the following for the uninstall

      $product = Get-WmiObject -Class win32_product -Filter "Name like ‘Azure AD Password Protection DC Agent’"

      $product

      $product.Uninstall() # WARNING: Reboot is immediate, no mercy and no questions asked!!!

      After the uninstall and reboot, install the newest AzureADPasswordProtectionDCAgent.msi available from Microsoft

      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 »

      (2018-10-22) Cloning Windows 10 Or Windows Server 2016 May Break Hybrid Azure AD Domain Join

      Posted by Jorge on 2018-10-22


      When cloning Windows computers you are basically copying everything from some source computer to one or more target computers. One of the benefits is the speed in deployment and the time you same to have to configure stuff every single time. Are there downsides? Yes, there are, at least if you do not take some risk mitigating measures. One of those is the SID of the local computer. Every time you deploy a cloned version of Windows you MUST execute SYSPREP to make the clone gets its own unique SID. If you don’t at the beginning and along the way things may appear to be correct. However, at some point in time you may find yourself with a huge headache trying to understand why something does not work or shows weird behavior.

      Recently I found another downside of cloning, that in the end can be mitigated with some post-deployment actions.

      For more info about Hybrid Azure AD Domain Join (HAADJ) please also have a look at

      I was trying to Hybrid Azure AD Domain Join (HAADJ) a AD domain joined Windows Server 2016 by logging on and waiting for the scheduled task to kick in and checking the correct Event Logs, and later on under the context of “NT AUTHORITY\SYSTEM” by running DSREGCMD.EXE /DEBUG. When running that last command I kept seeing the following error at the end:

      DsrDeviceAutoJoinFederated failed with -2146893802
      wmain: failed with error code 0x80090016.

      After some troubleshooting I discovered that Windows was a cloned deployment. One of the thing that is also cloned is the key material. The key material is in the folder “C:\ProgramData\Microsoft\Crypto\Keys” to “C:\ProgramData\Microsoft\Crypto\Keys”. The solution therefore is to get rid of the old key material and start fresh from the beginning. You can do that by running the following PowerShell commands:

      # Rename The “Keys” Folder To “KeysOLD”

      Rename-Item -Path "C:\ProgramData\Microsoft\Crypto\Keys" -NewName "KeysOLD"

      # Create A New “Keys” Folder

      New-Item -Path "C:\ProgramData\Microsoft\Crypto\Keys" -ItemType Directory

      # Copy The ACL From The “KeysOLD” Folder To The New “Keys” Folder

      Get-Acl -Path "C:\ProgramData\Microsoft\Crypto\KeysOLD" | Set-Acl -Path "C:\ProgramData\Microsoft\Crypto\Keys"

      Now retry HAADJ by rebooting the Windows computers and logging on, or executing DSREGCMD.EXE /DEBUG under the context of  “NT AUTHORITY\SYSTEM”. It should work now!

      REMARK: If you did not know it yet, you can get into the context of “NT AUTHORITY\SYSTEM” by using PSEXEC and running the following command: PSEXEC –i –s CMD.EXE

      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 Join, Windows Azure Active Directory, Windows Client, Windows Server | 3 Comments »

      (2018-10-07) Presenting At Hybrid Identity Protection (HIP) Conference In New York

      Posted by Jorge on 2018-10-07


      As we speak, I’m preparing my presentation and demo’s for my presentation at the Hybrid Identity Protection (HIP) conference in New York. You can get more information, and of course register (did you already register?) through the following link https://www.hipconf.com/. The conference dates are Monday November 5th and Tuesday November 6th.

      The Speaker List: https://www.hipconf.com/speakers/

      The Agenda: https://www.hipconf.com/agenda/

      My session is scheduled for Monday November 5th at 5 PM (17:00) and is called “How To Secure Shared Social Media Accounts And Achieve SSO Through Azure AD”

      Abstract:

      Nowadays many companies have an online presence in most likely more than one social media to at least service and/or communicate with customers regarding all kinds of matters. Some well-known examples are Twitter, Facebook, Instagram and YouTube. Of course, other social media may exist specific to the business or country.

      The main question is: how can you make sure those (shared) social media accounts are used in a secure manner by a group of people and still keep the bad guys out?

      The answer is: That’s where Azure AD comes into the playing field!

      Come to this session to learn and see about experiences using the Azure AD solution. Yes, demos are included!

      See you there!

      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 Conferences, Windows Azure Active Directory | Leave a Comment »

      (2018-10-07) Azure AD Connect v1.1.882.0 Has Been Released

      Posted by Jorge on 2018-10-07


      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.1.882.0

      Released: 9/7/2018

      Released for download, will not be released for auto upgrade

      Prerequisites for Azure AD Connect

      More information about Azure AD Connect

      Fixed Issues:

      • Azure AD Connect Upgrade fails if SQL Always On Availability is configured for the ADSync DB. This hotfix addresses this issue and allows Upgrade to succeed

      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 | Leave a Comment »

      (2018-10-07) Azure AD Connect v1.1.880.0 Has Been Released

      Posted by Jorge on 2018-10-07


      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.1.880.0

      Released: 8/21/2018

      Released for auto upgrade and download

      Prerequisites for Azure AD Connect

      More information about Azure AD Connect

      New Features And Improvements:

      • The Ping Federate integration in Azure AD Connect is now available for General Availability. Learn more about how to federated Azure AD with Ping Federate
      • Azure AD Connect now creates the backup of Azure AD trust in AD FS every time an update is made and stores it in a separate file for easy restore if required. Learn more about the new functionality and Azure AD trust management in Azure AD Connect.
      • New troubleshooting tooling helps troubleshoot changing primary email address and hiding account from global address list
      • Azure AD Connect was updated to include the latest SQL Server 2012 Native Client
      • When you switch user sign-in to Password Hash Synchronization or Pass-through Authentication in the "Change user sign-in" task, the Seamless Single Sign-On checkbox is enabled by default.
      • Added support for Windows Server Essentials 2019
      • The Azure AD Connect Health agent was updated to the latest version 3.1.7.0
      • During an upgrade, if the installer detects changes to the default sync rules, the admin is prompted with a warning before overwriting the modified rules. This will allow the user to take corrective actions and resume later. Old Behavior: If there was any modified out-of-box rule then manual upgrade was overwriting those rules without giving any warning to the user and sync scheduler was disabled without informing user. New Behavior: User will be prompted with warning before overwriting the modified out-of-box sync rules. User will have choice to stop the upgrade process and resume later after taking corrective action.
      • Provide a better handling of a FIPS compliance issue, providing an error message for MD5 hash generation in a FIPS compliant environment and a link to documentation that provides a work around for this issue.
      • UI update to improve federation tasks in the wizard, which are now under a separate sub group for federation.
      • All federation additional tasks are now grouped under a single sub-menu for ease of use.
      • A new revamped ADSyncConfig Posh Module (AdSyncConfig.psm1) with new AD Permissions functions moved from the old ADSyncPrep.psm1 (which may be deprecated shortly)

      Fixed Issues:

      • Fixed a bug where the AAD Connect server would show high CPU usage after upgrading to .Net 4.7.2
      • Fixed a bug that would intermittently produce an error message for an auto-resolved SQL deadlock issue
      • Fixed several accessibility issues for the Sync Rules Editor and the Sync Service Manager
      • Fixed a bug where Azure AD Connect can not get registry setting information
      • Fixed a bug that created issues when the user goes forward/back in the wizard
      • Fixed a bug to prevent an error happening due to incorrect multi thread handing in the wizard
      • When Group Sync Filtering page encounters an LDAP error when resolving security groups, Azure AD Connect now returns the exception with full fidelity. The root cause for the referral exception is still unknown and will be addressed by a different bug.
      • Fixed a bug where permissions for STK and NGC keys (ms-DS-KeyCredentialLink attribute on User/Device objects for WHfB) were not correctly set.
      • Fixed a bug where ‘Set-ADSyncRestrictedPermissions’ was not called correctly
      • Adding support for permission granting on Group Writeback in AADConnect’s installation wizard
      • When changing sign in method from Password Hash Sync to AD FS, Password Hash Sync was not disabled.
      • Added verification for IPv6 addresses in AD FS configuration
      • Updated the notification message to inform that an existing configuration exists.
      • Device writeback fails to detect container in untrusted forest. This has been updated to provide a better error message and a link to the appropriate documentation
      • Deselecting an OU and then synchronization/writeback corresponding to that OU gives a generic sync error. This has been changed to create a more understandable error message

      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 | Leave a Comment »

      (2018-07-22) Azure AD Connect v1.1.819.0 Has Been Released

      Posted by Jorge on 2018-07-22


      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.1.819.0

      Released: 5/14/2018

      Released for auto upgrade and download

      Prerequisites for Azure AD Connect

      More information about Azure AD Connect

      New Features And Improvements:

      • This release includes the public preview of the integration of PingFederate in Azure AD Connect. With this release, customers can easily, and reliably configure their Azure Active Directory environment to leverage PingFederate as their federation provider. To learn more about how to use this new feature, please visit our online documentation.
      • Updated the Azure AD Connect Wizard Troubleshooting Utility, where it now analyzes more error scenario’s, such as Linked Mailboxes and AD Dynamic Groups. Read more about the troubleshooting utility here.
      • Device Writeback configuration is now managed solely within the Azure AD Connect Wizard.
      • A new PowerShell Module called ADSyncTools.psm1 is added that can be used to troubleshoot SQL Connectivity issues and various other troubleshooting utilities. Read more about the ADSyncTools module here.
      • A new additional task “Configure device options” has been added. You can use the task to configure the following two operations:
        • Hybrid Azure AD join: If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Azure Active Directory, you can implement hybrid Azure AD joined devices. These are devices that are both, joined to your on-premises Active Directory and your Azure Active Directory.
        • Device writeback: Device writeback is used to enable conditional access based on devices to AD FS (2012 R2 or higher) protected devices

      Note:

      • The option to enable device writeback from Customize synchronization options will be greyed out.
      • The PowerShell module for ADPrep is deprecated with this release.

      Fixed Issues:

      • This release updates the SQL Server Express installation to SQL Server 2012 SP4, which, among others, provides fixes for several security vulnerabilities. Please see here for more information about SQL Server 2012 SP4.
      • Sync Rule Processing: outbound Join sync rules with no Join Condition should be de-applied if the parent sync rule is no longer applicable
      • Several accessibility fixes have been applied to the Synchronization Service Manager UI and the Sync Rules Editor
      • Azure AD Connect Wizard: Error creating AD Connector account when Azure AD Connect is in a workgroup
      • Azure AD Connect Wizard: On the Azure AD Sign-in page display the verification checkbox whenever there is any mismatch in AD domains and Azure AD Verified domains
      • Auto-upgrade PowerShell fix to set auto upgrade state correctly in certain cases after auto upgrade attempted.
      • Azure AD Connect Wizard: Updated telemetry to capture previously missing information
      • Azure AD Connect Wizard: The following changes have been made when you use the Change user sign-in task to switch from AD FS to Pass-through Authentication:
        • The Pass-through Authentication Agent is installed on the Azure AD Connect server and the Pass-through Authentication feature is enabled, before we convert domain(s) from federated to managed.
        • Users are no longer converted from federated to managed. Only domain(s) are converted.
      • Azure AD Connect Wizard: AD FS Multi Domain Regex is not correct when user UPN has ‘ special character Regex update to support special characters
      • Azure AD Connect Wizard: Remove spurious "Configure source anchor attribute" message when no change
      • Azure AD Connect Wizard: AD FS support for the dual federation scenario
      • Azure AD Connect Wizard: AD FS Claims are not updated for added domain when converting a managed domain to federated
      • Azure AD Connect Wizard: During detection of installed packages, we find stale Dirsync/Azure AD Sync/Azure AD Connect related products. We will now attempt to uninstall the stale products.
      • Azure AD Connect Wizard: Correct Error Message Mapping when installation of passthrough authentication agent fails
      • Azure AD Connect Wizard: Removed "Configuration" container from Domain OU Filtering page
      • Sync Engine install: remove unnecessary legacy logic that occasionally failed from Sync Engine install msi
      • Azure AD Connect Wizard: Fix popup help text on Optional Features page for Password Hash Sync
      • Sync Engine runtime: Fix the scenario where a CS object has an imported delete and Sync Rules attempt to re-provision the object.
      • Sync Engine runtime: Add help link for Online connectivity troubleshooting guide to the event log for an Import Error
      • Sync Engine runtime: Reduced memory usage of Sync Scheduler when enumerating Connectors
      • Azure AD Connect Wizard: Fix an issue resolving a custom Sync Service Account which has no AD Read privileges
      • Azure AD Connect Wizard: Improve logging of Domain and OU filtering selections
      • Azure AD Connect Wizard: AD FS Add default claims to federation trust created for MFA scenario
      • Azure AD Connect Wizard: AD FS Deploy WAP: Adding server fails to use new certificate
      • Azure AD Connect Wizard: DSSO exception when onPremCredentials aren’t initialized for a domain
      • Preferentially flow the AD distinguishedName attribute from the Active User object.
      • Fixed a cosmetic bug were the Precedence of the first OOB Sync Rule was set to 99 instead of 100

      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 | Leave a Comment »

      (2018-04-20) Azure AD MFA Server v8.0.0.3 Has Been Released

      Posted by Jorge on 2018-04-20


      Azure Multi-Factor Authentication Server provides a way to secure resources with MFA capabilities

      Download "Azure Multi-Factor Authentication Server"

      Azure Multi-Factor Authentication Server

      8.0.0.3

      Released: 4/9/2018

      Microsoft has released a newer version of the Azure AD MFA server. If you start the MFA Server Console you should see a notification about a newer version being available.

      Version 8.0.0.3 of the Azure Multi-Factor Authentication Server adds the following additional functionality:

      • Registration experience improvements on mobile
      • Improved interaction with AD Sync
      • Support for TLS 1.2 for LDAP, User Portal to Web Service SDK, and SChannel replication
      • Compliance with General Data Protection Regulation
      • Accessibility improvements to User Portal, MFA Server management, and installation
      • Fixed issue with fallback to security questions
      • Fixed issue with security questions appearing multiple times
      • Miscellaneous bug fixes and improvements
      • NOT MENTIONED IN RELEASE NOTES: It now DOES install on Server Core!

      Known Issues:

      • Windows Authentication for Terminal Services is not supported for Windows Server 2012 R2

      Upgrade Considerations:

      • Must upgrade MFA Server and Web Service SDK before upgrading User Portal And AD FS adapter
      • All other features and components are backwards-compatible with all previous versions
      • Installation of the mobile app web service is not necessary for v8.0 or higher. Complete only the steps under Configure the mobile app. After the upgrade you may want to uninstall the previous mobile app web service, remove the virtual directory and application pool from IIS. If you have published the mobile app web service, then that is not required anymore

      More information about Azure AD MFA Server can be found here.

      Upgrade steps can be found here, but also take the following info into account

      For this version of the MFA server:

      • you need to have MS-KB2919355 installed on the MFA server before starting the installation (check with Get-HotFix KB2919355)
      • you need to have the following installed on any server with any MFA server component: The Visual C++ 2017 Redistribution packages (a.k.a. Visual C++ "14" Runtime Libraries) are also available from here
      • you need to have the at least following version installed on any server with any MFA server component: .NET Framework 4.6.2 is available from here.

      Before upgrading/installing the new ADFS adapter, you need to unselect and unregister the previous ADFS adapter

      • Using WID?: Execute the commands below on primary ADFS server and wait at least 5 minutes to allow WID replication to take place and finish
      • Using SQL?: Execute the commands below on any ADFS server

      # Unselecting The Use Of Azure AD MFA Adapter To Be Listed
      $listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
      $listOfNewMFAProviders = $listOfCurrentMFAProviders
      $listOfNewMFAProviders.Remove("WindowsAzureMultiFactorAuthentication")  # Use THIS line if the old version is v6.3.0 or lower
      $listOfNewMFAProviders.Remove("AzureMfaServerAuthentication")  # Use THIS line if the old version is v7.0.0.9 or higher
      Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

      # Unregistering The Azure AD MFA Adapter Within ADFS
      Unregister-AdfsAuthenticationProvider -Name WindowsAzureMultiFactorAuthentication  # Use THIS line if the old version is v6.3.0 or lower
      Unregister-AdfsAuthenticationProvider -Name AzureMfaServerAuthentication  # Use THIS line if the old version is v7.0.0.9 or higher

      After installing the new ADFS adapter, you need to configure it, register it and configure it within ADFS

      • Using WID?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on the primary ADFS server as explained below (use your previous settings where applicable), and SAVE it afterwards
      • Using SQL?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on any ADFS server as explained below (use your previous settings where applicable), and SAVE it afterwards

      FILE: MultiFactorAuthenticationAdfsAdapter.config

      <ConfigurationData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

          <UseWebServiceSdk><true OR false></UseWebServiceSdk>

          <WebServiceSdkUrl><URL to the MFA Web Service SDK></WebServiceSdkUrl>

          <WebServiceSdkUsername><the account (DOMAIN\SAMACCOUNTNAME) the user portal is also using in its web.config></WebServiceSdkUsername>

          <WebServiceSdkPassword><the password of the account above the user portal is also using in its web.config></WebServiceSdkPassword>

          <WebServiceSdkCertificateThumbprint><thumbprint of certificate of web service sdk></WebServiceSdkCertificateThumbprint>

          <AutomaticallyTriggerUserDefaultMethod><true OR false></AutomaticallyTriggerUserDefaultMethod>

          <TestMode><true OR false></TestMode>

      </ConfigurationData>

      Now we need to register and configure the new ADFS adapter within ADFS

      # Registering The Azure AD MFA Adapter Within ADFS

      $typeName = "pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=8.0.0.3, Culture=neutral, PublicKeyToken=f300afd708cefcd3"
      Register-AdfsAuthenticationProvider -TypeName $typeName -Name AzureMfaServerAuthentication –ConfigurationFilePath "<Provide Path To MultiFactorAuthenticationAdfsAdapter.config>"

      # Selecting The Use Of Azure AD MFA Adapter To Be Listed
      $listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
      $listOfNewMFAProviders = $listOfCurrentMFAProviders + "AzureMfaServerAuthentication"
      Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

      # Configuring Custom Display Name And Custom Description
      Set-AdfsAuthenticationProviderWebContent -Name "AzureMfaServerAuthentication" -DisplayName "<Provide Custom DisplayName>" -Description "<Provide Custom Description>"

      I 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 Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Multi-Factor AuthN, Windows Azure Active Directory | 2 Comments »

       
      %d bloggers like this: