Looking for the Dutch IT Pro Community Connection at Ignite 2017 Orlando? Look no further!

Meet up with the community at Microsoft Ignite 2017

So you love the Dutch; that interesting bunch of people occupying a little piece of mostly reclaimed coastal area in the Northwestern corner of Europe’s mainland. The guys and girls (and everything in between, we don’t judge) who do not shy away from giving you their opinions—their direct, unapologetic, blunt opinions on Microsoft technologies and products..

Great! Duim omhoog
Because there’s four Microsoft Most Valuable Professionals (MVPs), invited to speak at Ignite 2017 in Orlando Florida:
(in alphabetical order of our first names)

 

FreekBersonFreek Berson

Freek Berson works as an Infrastructure specialist at Wortell, a system integrator company based in Lijnden in the Netherlands near Schiphol Airport, where he focusses on End User Computing (EUC) and all related technologies, but mostly on the Microsoft platform. Freek delivers the following community session:

  • Virtual desktops in the cloud: Experiences from the field
    Tuesday September 26 10:20AM – 10:40AM, OCCC South – Expo Theater 4

PeterDaalmansPeter Daalmans

Having worked together with Peter Daalmans for a couple of months last year has helped me understand the ins and outs of enterprise client management in hybrid IT. Now a CTGlobal team member, Peter has joined up with Niall Brady to bring you this enticing session:

  • Conduct a successful pilot deployment of Microsoft Intune
    Friday, September 29 10:45AM – 12PM, OCCC Valencia W415 AB

RaymondComvaliusRaymond Comvalius

My buddy Raymond Comvalius, whom I had to pleasure of presenting with many times over the last ten years, has seen many of the big Dutch IT environments. Focusing on Windows, he has been a Microsoft MVP for the last consecutive seven years. Raymond presents these sessions:

  • Customizing the Start Menu in Windows 10
  • Tuesday September 26 1:35PM – 1:55 PM, OCCC South – Expo Theater 7
  • Device Guard: AppLocker on Steroids
    Tuesday September 26 2:10PM – 2:30 PM, OCCC South – Expo Theater 7
  • Group Policy in MDM: Dealing with ADMX backed policies
    Tuesday September 26 3:35PM – 3:55 PM, OCCC South – Expo Theater 5

Raymond also co-presents with Erdal Ozkaya on his 75-minute Halt hackers: Do those tricks still work with Windows 10? session on Wednesday September 27 12:30PM – 1:45PM in OCCC W207 AB.

SanderBSander Berkouwer

Yes. I’m also speaking at Microsoft Ignite 2017 in Orlando. Emoticon met brede lach
As a tenfold Microsoft Most Valuable Professional (MVP), double Veeam Vanguard and Microsoft Certified Trainer, I still can’t believe I was selected as a Microsoft Ignite community speaker, as I will present the following session:

  • Four common problems to avoid with your AD FS environment
    Wednesday September 27, 2:10PM – 2:30PM, OCCC South – Expo Theater 4

 

Concluding

The Dutch are well represented in Orlando this year. Besides the above speakers, I’m sure you’ll also enjoy the sessions by Marc van Eijk and Paul Huijbregts.

0  

I’m speaking at Microsoft Ignite 2017

Join my session at Microsoft Ignite

The tech world is changing fast—and that means the role of the tech professional is more vital than ever before. Microsoft Ignite is the place to meet the experts, get your questions answered, and connect with the tech community. I’ll be there, presenting on the four mistakes I see organization make with their Active Directory Federation Services (AD FS) and Hybrid Identity implementations.

 

About Microsoft Ignite

Ignite is Microsoft’s yearly event for IT Professionals and developers. At Microsoft Ignite they connect with IT leaders from around the world. They hear from industry thought-leaders on the changing landscape of IT, they find new technology partners and they see how others are transforming businesses. Ignite is a one-of-a-kind experience designed to fuel business, connections, and the future forward.

Microsoft Ignite features over 40 pre-day sessions, including Microsoft Azure, SharePoint, Dynamics 365, Windows, and much more, a keynote by Microsoft CEO Satya Nadella and several meetups with fellow IT Professionals, developers and community leaders.

 

About my session

I’m scheduled for Wednesday September 27 2:10 PM in Expo Theater 4 in the South wing of the Orange County Convention Center in Orlando, to deliver the following session:

Four common problems to avoid with your AD FS environment

Many organizations have deployed Active Directory Federation Services. Working with them, revealed a pattern of common misconfigurations and misconceptions on deployment and management of AD FS, resulting in serious problems. Here’s our top four from the field, so you won’t have to experience them.

    

Join me!

Microsoft Ignite is almost sold out, but some tickets still remain.
Register here.

image

If you have already, I hope you’ll add my session to your schedule and attend. The easiest way is to click the image above.

I hope to see you in Orlando, September 25-29!

0  

Azure AD Connect 1.1.614.0 offers a load of fixes and enhanced functionality

Yesterday, Microsoft released version 1.1.614.0 of Azure AD Connect, its free Hybrid Identity bridge product to synchronize objects and their attributes from on-premises Active Directory Domain Services (AD DS) environments to Azure Active Directory.

 

What’s New

Azure AD Connect Sync

Azure AD Connect now features a Troubleshoot task in the Azure AD Connect wizard under Additional Tasks. You can leverage this task to troubleshoot issues related to password synchronization and collect general diagnostics. In the future, the Troubleshoot task will be extended to include other directory synchronization-related issues.

Azure AD Connect now supports a new installation mode called Use Existing Database. This installation mode allows you to install Azure AD Connect that specifies an existing ADSync database. For more information about this feature, refer to the Install Azure AD Connect using an existing ADSync database article.

For improved security, Azure AD Connect now defaults to using TLS 1.2 to connect to Azure AD for directory synchronization. Previously, the default was TLS 1.0 and a lot of designs for Azure AD Connect already featured registry keys to make Azure AD Connect default to TLS 1.2.

When Azure AD Connect Password Synchronization Agent starts up, it tries to connect to the Azure AD well-known endpoint for password synchronization. Upon successful connection, it is redirected to a region-specific endpoint. Previously, the Password Synchronization Agent cached the region-specific endpoint until it was restarted. Now, the agent clears the cache and retries with the well-known endpoint if it encounters connection issue with the region-specific endpoint. This change ensures that password synchronization can failover to a different region-specific endpoint when the cached region-specific endpoint is no longer available.

To synchronize changes from an on-premises Active Directory forest, an account in the on-premises Active Directory Domain Services (AD DS) environment is required.

You can either:

  1. create the Active Directory account yourself and provide its credential to Azure AD Connect, or
  2. provide an Enterprise Admin credentials and let Azure AD Connect create the Active Directory account for you.

Previously, creating the account yourself was the default option in the Azure AD Connect wizard. Now, Azure AD Connect creates the account for you as the default option.

Azure AD Connect Health

On top of last week’s improvements to Azure AD Connect Health Sync Error Reporting, Azure AD Connect Health is now also supported for Microsoft Azure Government Cloud and Microsoft Cloud Germany.

Active Directory Federation Services (AD FS) Management

The Verify ADFS Login task in the list of Azure AD Connect’s additional tasks was updated so that it verifies logins against Microsoft Online and not just performs token retrieval from AD FS.

When setting up a new AD FS farm using Azure AD Connect, the page asking for the AD FS credentials was moved so that it now occurs before the user is asked to provide AD FS and WAP servers. This allows Azure AD Connect to check that the account specified has the correct permissions.

During Azure AD Connect upgrade, situations where the ‘Office 365 Identity Platform’ Relying Party Trust (RPT) fails to update, no longer result in a failed upgrade. In this scenario, you will be shown an appropriate warning message and should proceed to reset the trust via Azure AD Connect’s Repair AAD and ADFS Trust additional task:

Azure AD Connect's Repair AAD and ADFS Trust task (click for original screenshot)

 

Fixes

NTLM Fallback

The team fixed an issue that caused Azure AD Connect to fail installation if the on-premises Active Directory forest has NTLM disabled. The issue is due to Azure AD Connect wizard not providing fully qualified credentials when creating the security contexts required for Kerberos authentication. This causes Kerberos authentication to fail and the Azure AD Connect wizard to fall back to using NTLM.

Azure AD Connect Sync

The team fixed an issue that prevented the creation of new synchronization rules if the Tag attribute isn’t populated.

The team fixed an issue that caused Azure AD Connect to connect to on-premises Active Directory for Password Synchronization using NTLM, even though Kerberos is available. This issue occurs if the on-premises Active Directory topology has one or more Domain Controllers that was restored from a backup.

The team fixed an issue that caused full synchronization steps to occur unnecessarily after upgrade. In general, running the full synchronization steps is required after upgrade if there are changes to out-of-box synchronization rules. The issue was due to an error in the change detection logic that incorrectly detected a change when encountering synchronization rule expressions with newline characters. Newline characters are inserted into sync rule expressions to improve readability.

The team fixed an issue that can cause the Azure AD Connect server to not work correctly after an Automatic Upgrade. This issue affects Azure AD Connect servers with version 1.1.443.0 (or earlier). For details about the issue, refer to article Azure AD Connect is not working correctly after an automatic upgrade.

The team fixed an issue that can cause Automatic Upgrade to be retried every 5 minutes when errors are encountered. With the fix, Automatic Upgrade retries with exponential back-off when errors are encountered.

The team fixed an issue where password synchronization event 611 is incorrectly shown in the Windows Application Event log as informational instead of error. Event 611 is generated whenever password synchronization encounters an issue.

The team fixed an issue in the Azure AD Connect wizard that allows Group write-back feature to be enabled without selecting an Organizational Unit (OU) required for Group write-back.

Active Directory Federation Services (AD FS) Management

The Initialize-ADSyncNGCKeysWriteBack Windows PowerShell Cmdlet in the ADPrep PowerShell module was incorrectly applying access control entries to the device registration container and would therefore only inherit existing permissions. The behavior was updated so that the sync service account gains the correct permissions.

Seamless Single Sign-On (S3O)

The team fixed an issue that caused the Azure AD Connect wizard to return an error if you try to enable Seamless Single Sign-On:

Configuration of Microsoft Azure AD Connect Authentication Agent failed.

This issue affects existing Azure AD Connect installations where the preview version of the Authentication Agents for Pass-through Authentication were manually upgraded, based on the steps described in the Azure Active Directory Pass-through Authentication: Upgrade preview Authentication Agents article.

  

Known Issues

There is a known issue with Azure AD Connect Upgrade that is affecting customers who have enabled Seamless Single Sign-On. After Azure AD Connect is upgraded, the feature appears as disabled in the wizard, even though the feature remains enabled. A fix for this issue will be provided in future release. Customers who are concerned about this display issue can manually fix it by enabling Seamless Single Sign-On in the wizard.

 

Version information

This is version 1.1.614.0 of Azure AD Connect.
It was signed off on on September 5, 2017.

 

Download information

You can download Azure AD Connect here.
The download weighs 81,1 MB.

 

Concluding

Much of the above behavior was introduced in version 1.1.613.0, but internal testing led to several more fixes to make sure the choice for Azure AD Connect is the right choice for organizations on their Hybrid Identity journeys.

With its many features, this is a good version to test your Azure AD Connect lifecycle management processes on.

Related blogposts

Azure AD Connect 1.1.561.0 finalizes Automatic Upgrade scenario changes 
Azure AD Connect 1.1.557.0 is good news for highly-regulated organizations 
Azure AD Connect v1.1.553.0 addresses a critical security vulnerability  
Azure AD Connect 1.1.524.0 brings a ton of new functionality to Hybrid Identity 
Azure AD Connect versions 1.1.484.0 and 1.1.486.0 offer great enhancements 
Azure AD Connect v1.1.443.0 is here

0  

I’m speaking at iSense’s Security Summit

On Wednesday, September 20th 2017, iSense ICT Professionals organizes its first Security Summit at their HeadQuarts in Gouda, the Netherlands.

Eight speakers share five topics and the entire event is chaired by Ancilla van de Leest.

 

About iSense ICT Professionals

IsenseiSense ICT Professionals is a Dutch ICT company, specialized in staffing ICT Professionals. Their main focus is on systems management, database administration, business analysis and software development (based on java, .NET and PHP).

 

About the Security Summit

If you want to learn about the latest and greatest security opportunities, from the fields of Microsoft, VMware and cybersecurity, this event is for you.

Agenda

You’re welcome starting at 3PM at iSense ICT Professionals, Zuidelijk Halfrond 11 in Gouda, the Netherlands. Get a drink, grab a seat and shake some hands.

At 3:30PM, Jeff Wouters starts off the event with a 55-minute session on how to implement and leverage Just in Time (JIT) and Just Enough Administration (JEA) to lower your attack surface. PowerShell guaranteed.

After a 10-minute break, Raymond Comvalius and I present another 55-minute session. We’ll discuss the new Shielded VMs feature in Windows Server 2016’s Hyper-V. This allows VM admins to be the owners of their VMs again and shut out any rogue virtualization admin or hoster.

Then, it’s time for dinner at 5:30 PM.

Attendees have the same time to digest food as they have to digest knowledge, as 55 minutes later, Remko Weijnen and Wouter Arts kick-off another 55 minutes on threat management and red team practices. Specific topics of interest are RDS & XenApp hijacking, Windows logons with cloned smartcards and EternalBlue infections.

At the same time Remko Weijnen and Wouter Arts are presenting, Adnan Hendricks gives 14 privileged persons a 55 minute hands-on with Azure’s Security Center. Bring Your Own Device to the max.

After another short 10-minute break, Joep Piscaer details Docker containers. It should not be a surprise that Joep feels containers are the pinnacle of security. Ten minutes after Joep, Jacco van Tuyl dives deep into ransomware like WannaCry and Not-Petya.

To catch their breaths, drinks will be served after the sessions, starting at around 9:45PM. This is the perfect time to have that informal chat with the speakers, admit you’ve been hacked or gain some more real-world tips to get the technology working optimally in your environment.

 

Join us!

iSense is organizing their Security Summit free or charge, but seats are limited.
Sign up here Dutch and get to iSense Gouda office on Wednesday September 20, 2017

0  

Connecting to Azure MFA Server’s Web Service SDK using certificate authentication

Recently, I’ve been involved in some larger Azure Multi-Factor Authentication (MFA) Server projects as a senior engineer with a couple of demanding customers. It’s been a lot of fun and quite the roller coaster ride.

In my opinion, an increasing number of organizations are looking to implement multi-factor authentication. They may be required to by regulators, they’ve seen the amount of breaches currently, or they’ve simply got the message from Microsoft’s cloud strategy.

These organizations, increasingly have requirements throughout their environments, that require a little more thought, than simply check the Require Multi-Factor Authentication option in Office 365 or deploy an Azure MFA Server with default settings.

One of the requirements they might have is that confidential information is not stored unencrypted in configuration files, like the web.config files of the Azure MFA User Portal, Azure MFA Mobile Portal and Azure MFA AD FS Adapter so they can connect to the Azure MFA Web Service SDK.

 

Choices

Throughout this blogpost, I’ll make the following (design) choices:

  1. We’ll use an internal Certification Authority (CA) to issue certificates. We could use a publicly trusted Certification Authority (CA), but this might require external connections towards certificate revocation information (HTTP). We don’t use self-signed certificates, signed by the servers in scope, either.
  2. Since the communications between the Azure MFA User Portal, Azure MFA Mobile Portal, Azure MFA AD FS Adapter and the Azure MFA Web Service SDK already utilizes one (configurable) TCP port, we don’t implement IPSec.

Assumptions

Throughout this blogpost, I’ll make the following assumptions:

  • The Root Certification Authority is an Enterprise Root CA. This will allow you to set permissions on certificate templates, make domain-joined systems automatically enroll for certificates and make the certificate chain trusted throughout the Active Directory environment.
  • You’ve setup Azure Multi-Factor Authentication Server version 7 successfully, using one of the many write-ups available to do so using usernames and passwords for the service account. If you want to know your deployment options, click here. If you want to follow my write-up, start here.

Prerequisites

First, perform these steps:

  • Create at least one service account.
  • Add the service account(s) to the PhoneFactor Admins group in Active Directory.
  • Ensure the Certification Authority Web Enrollment feature is installed on the (issuing) Certificate Authority (CA), by navigating to /CertSrv”>https://<CAName>/CertSrv.

Steps

Test the configuration

To test the configuration, visit the User Portal and log on using multi-factor authentication, based on the Mobile App to gain access to it. When it’s not working using username/password configuration, it certainly won’t magically start working using certificate authentication.

Ensuring the availability of the right certificates

Perform these steps to allow the right certificate to be requested:

  • Log on to an Active Directory Domain Controller.
  • Open the Active Directory Sites and Services MMC Snap-in.
  • Enable Advanced Features.
  • In the navigation pane, navigate to Certificate Templates.
  • In the main pane, select the User certificate. Then, right-click it and select Properties from the context menu.
  • On the Security tab, grant the PhoneFactor Admins group permissions to enroll the certificate.
  • Log off.

Requesting the certificate

Perform these steps to request a certificate for a service account:

Note:
When you use service accounts per service, so one service account for AD FS, one service account for the Azure Multi-Factor Authentication Server User Portal and one service account for the Azure Multi-Factor Authentication Server Mobile Portal, perform the below fifteen steps for requesting a certificate for each of the service accounts.

  • Log on to the primary Azure Multi-Factor Authentication (MFA) Server as an admin.
  • Connect to the Certification Authority Web Enrollment website by navigating to \CertSrv”>\CertSrv”>http://<CAName>\CertSrv using Internet Explorer.
  • Log in with the Service Account.
  • Click Request a certificate.
  • On Request a Certificate, click User Certificate.
  • On the User Certificate Identifying Information page, do one of the following:
    • Comply to the message “No further identifying information is required. To complete your certificate, press Submit.”
    • Enter your identifying information for the certificate request.
  • (Optional) Click More Options to specify the cryptographic service provider (CSP) and choose if you want to enable strong private key protection. (You receive a prompt every time you use the private key that is associated with the certificate.)
  • Click Submit.
  • Do one of the following:
    • If you see the Certificate Pending page, the Certification Authority administrator will have to approve the request before you can retrieve and install the certificate.
    • If you see the Certificate Issued page, click Install this certificate.
  • Download the certificate.
  • Install the certificate within the admin session by right-clicking the downloaded certificate and selecting Install from the context-menu.
  • Open the Certificates MMC Snap-in, go to the Certificate pane and select User Account.
  • Right-click the certificate you installed previously and select Export from the context menu. Save it to a secure location and note the password you use to protect the key pair.
  • Export the certificate to a base64 .cer file, too.
  • Close the Certificates MMC Snap-in.

Configure the MFA WebService SDK

Perform these steps to configure Azure MFA Server’s Web Service SDK:

  • In Server Manager, verify that the Web Server (IIS)\Web Server\Security\IIS Client Certificate Mapping Authentication feature is installed. If it is not installed, select Add Roles and Features to add this feature.
  • In IIS Manager, double-click Configuration Editor in the website that contains the Web Service SDK virtual directory.

Note:
For security reasons, you want to perform these steps at the website level and not at the virtual directory level.

  • Go to the following section:  system.webServer/security/authentication/iisClientCertificateMappingAuthentication
  • Change enabled to true.
  • Change oneToOneCertificateMappingsEnabled to true.
  • Click the button next to oneToOneMappings, and then click the Add link.
  • Open the Base64 .cer file you exported earlier. Remove —–BEGIN CERTIFICATE—–, —–END CERTIFICATE—–, and any line breaks. It becomes a single line. Copy the resulting string.
  • Configure the certificate using the string copied in the preceding step.
  • Change enabled to true.
  • Configure userName to the service account your created as part of the prerequisites and is a member of the PhoneFactor Admins security group.

Tip!
Use the <domain>\<user name> format here.

  • Set the password to the appropriate service account password.
  • Close Configuration Editor.
  • Click the Apply link.
  • In the Web Service SDK virtual directory, double-click Authentication.
  • Verify that ASP.NET Impersonation and Basic Authentication are set to Enabled and all other items are set to Disabled.
  • In the Web Service SDK virtual directory, double-click SSL Settings.
  • Set Client Certificates to Accept, and then click Apply.

Configure the MFA AD FS Adapter

To (re)configure the Azure Multi-Factor Authentication (MFA) Server Active Directory Federation Services (AD FS) adapter, perform these steps:

  • Copy the .pfx file you exported earlier to the server that is running the AD FS adapter.
  • Open the MMC Snap-In for Local Computer Certificates by pressing the Start button and typing certlm.msc.
  • Import the .pfx file to the local computer’s personal certificate store.
  • Right-click and select Manage Private Keys, and then grant read access to the account you used to sign in to the AD FS service.
  • Open the client certificate and copy the thumbprint from the Details tab.
  • Make the following three changes in the MultiFactorAuthenticationAdfsAdapter.config file:
    • Change the value for WebServiceSdkCertificateThumbprint to the string copied in the previous step.
    • Change UseWebServiceSDK to “true” (Do not change it to “True”)
    • Specify the value for WebServiceSDKUrl.
  • Afterwards, it should look like this:

Contents of the MultiFactorAuthenticationAdfsAdapter.Config file (click for original screenshot)

  • Save the MultiFactorAuthenticationAdfsAdapter.config. file.
  • Next, alter the Register-MultiFactorAuthenticationAdfsAdapter.ps1 script to include the ConfigurationFilePath parameter to the full path of the MultiFactorAuthenticationAdfsAdapter.config file.
  • To register the MFA AD FS adapter, start a Windows PowerShell console window as administrator and run the Register-MultiFactorAuthenticationAdfsAdapter.ps1 script.

Configure the MFA User Portal and mobile portal

Perform these steps to (re)configure Azure Multi-Factor Authentication Server’s User Portal and Mobile Portal:

  • Copy the .pfx file you exported earlier to the server that is running the Azure Multi-Factor Authentication User Portal and/or Azure Multi-Factor Authentication Mobile Portal.
  • Open the MMC Snap-In for Local Computer Certificates by pressing the Start button and typing certlm.msc.
  • Import the .pfx file to the local computer’s personal certificate store.

When the server that is running the Azure Multi-Factor Authentication User Portal and/or Azure Multi-Factor Authentication Mobile Portal runs in a perimeter network, and is not joined to the Active Directory domain, also import the certificate chain, containing the Root CA, any relevant intermediate CAs and the CA that issued the certificate.

  • Right-click and select Manage Private Keys, and then grant read access to the following accounts:
    • IIS APPPOOL\MultiFactorAuthPhoneAppWebService*
    • IIS APPPOOL\MultiFactorAuthUserPortal
      *The application pools used in IIS to host the virtual directory’s.
  • Change the web.config of the Mobile Portal to include the private key as the value for the WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_THUMBPRINT setting and remove any values for WEB_…_USERNAME and WEB_…_PASSWORD:

Example contents of the web.config file for the Mobile Portal

    • Save the web.config file.
    • Change the web.config file on the User Portal to change the value for the USE_WEB_SERVICE_SDK setting to true and the private key as the value for the WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_THUMBPRINT setting and remove any values for WEB_…_USERNAME and WEB_…_PASSWORD:

    Example contents of the web.config file for the User Portal

    Test the configuration

    To test the configuration, visit the User Portal and log on using multi-factor authentication, based on the Mobile App to gain access to it.

     

    Concluding

    The requirement to not store confidential information unencrypted in configuration files, can be met using the steps above for the Azure MFA User Portal, Azure MFA Mobile Portal and Azure MFA AD FS Adapter for their connection to the Azure MFA Web Service SDK.

    Related blogposts

    Ten Things you need to know about Azure Multi-Factor Authentication Server
    Supported Azure MFA Server Deployment Scenarios and their pros and cons
    Azure Multi-Factor Authentication Server 7.3.0.3 with lots of improvements
    Branding the Azure Multi-Factor Authentication Server User Portal
    Azure Multi-Factor Authentication features per license and implementation
    Azure Multi-Factor Authentication Methods per Supported Protocol

    Further reading

    Azure Multi-Factor Authentication – Part 1: Introduction and licensing
    Azure Multi-Factor Authentication – Part 2: Components and traffic flows
    Azure Multi-Factor Authentication – Part 3: Configuring the service and server
    Azure Multi-Factor Authentication – Part 4: Portals
    Azure Multi-Factor Authentication – Part 5: Settings
    Azure Multi-Factor Authentication – Part 6: Onboarding
    Azure Multi-Factor Authentication – Part 7: Securing AD FS
    Azure Multi-Factor Authentication – Part 8: Delegating Administration

    0  

    Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 3

    In the first part of this series, I’ve explained how Azure AD Connect version 1.1.553.0 and beyond allows you to switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute , the benefits of doing so and what you may and may not expect when you make the switch.

    Now that I’ve shown you the changes in Part 2 of this series, it’s time to see how you’d actually perform the switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute, when you come from a previous version of Azure AD Connect to version 1.1.561.0, or up. (since new installations of Azure AD Connect are automatically configured with mS-DS-ConsistencyGuid as the source anchor attribute).

     

    Prerequisites

    Plan the switch

    When you switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute for Azure AD Connect, it will trigger a Full Synchronization cycle. With current Full Sync cycles as long as 42 hours for some organizations, it is important to plan the switch at a point in time, that does not bode a slew of changes in on-premises objects. During the Full Synchronization no other cycles may run; any changes you make will flow to Azure AD only after the next synchronization cycle(s).

    Document the Azure AD Connect configuration

    In case something goes wrong, it’s a nice feeling when you know how to recreate the Azure AD Connect configuration. Documentation also helps you to perform root cause analyses when something goes wrong, and formally sign off on the changes in synchronization rules.

    The following lines of PowerShell code will help you achieve this goal:

    Import-Module ADSync
    Get-ADSyncServerConfiguration -Path “C:\Install\Docu”

    Document the Active Directory Federation Services (AD FS configuration

    When you utilize Active Directory Federation Services (AD FS) for your Azure AD authentication scenario, it’s also a good idea to document the AD FS configuration before and after you switch.

    The AD FS Rapid Recreation Tool does the job.

    Ensure you can restore your Azure AD Connect Installation(s)

    Making backups may be considered to be the most important safety net some systems administrator will come up with. However, being able to restore your Azure AD Connect installation(s) is more important. Make sure you can, by performing a test restore.

    Do the work

    As I mentioned in part 1 of this series, when you make the switch, you’ll need to make the switch on all Azure AD Connect installation(s) in your environment. Don’t forget to make the switch on your Staging Mode servers, because the source anchor attribute is a per-Azure AD Connect setting.

     

    Switch Azure AD Connects Source Anchor

    Perform these steps:

    • Log on interactively to the Windows Server installation that runs Azure AD Connect.
    • Open Azure AD Connect using the link on the desktop or by searching for (part of) its name in the Start Screen and then clicking it in the search results.
    • Click the Configure button on the Welcome to Azure AD Connect screen.

    Azure AD Connect - Additional tasks (click for original screenshot)

    • Click on Configure Source Anchor in the Additional tasks screen.
    • Click Next.
    • Enter the credentials of an Azure AD account with Global Admin privileges for the Azure AD tenant you’re synchronizing with. Perform multi-factor authentication when this is configured.

    Azure AD Connect - Configure Source Anchor (click for original screenshot)

    • The Configure Source Anchor screen provides more information on the source anchor best practice and informs you that Azure AD Connect did not find any other application that uses the mS-DS-ConsistencyGUID attribute. Click Next.

    Azure AD Connect - Ready to configure (click for original screenshot)

    • In the Ready to configure screen, click Configure.

    Note:
    If you can’t perform the Full Synchronization associated with the Source Anchor switch, deselect the Start the synchronization process when configuration completes. option. Run the full sync at a better time, but please be aware that all synchronization stops until you manually trigger the full synchronization,

    Azure AD Connect - Configuration complete (click for original screenshot)

    • Click Exit in the Configuration complete screen.

    Azure AD Connect performs the Full Synchronization cycle. Half an hour after this cycle ends, by default, it will perform a delta synchronization cycle.

     

    Additional Tasks

    Switch Staging Mode Servers

    When you have Staging Mode Azure AD Connect installations, perform the same steps on these servers.

    Document Azure AD Connect Changes

    When you want to document your changes in Azure AD Connect, run the PowerShell cmdlets mentioned above again. A tool like the Azure AD Connect Configuration Diagrammer provides a quick overview of the changes in the Azure AD Connect configuration.

     

    Concluding

    That’s all there is to know about switching from ObjectGUID to mS-DS-ConsistencyGUID as Azure AD Connect’s source anchor attribute for user objects.

    Good luck! Duim omhoog

    0  

    Ten Things you need to know about Azure Multi-Factor Authentication Server

    PhoneFactorAzure Multi-Factor Authentication Server is Microsofts product to add the magic of multi-factor authentication to your organizations on-premises enterprise infrastructure.

    I’ve been designing, implementing, updating and managing Azure Multi-Factor Authentication for several organizations. It has become one of my favorite tools in my toolbox, but there are a couple of things that I think you should know:

     

    1. You can’t implement it through scripting

    Although we have built extensive PowerShell scripts to configure Internet Information Services (IIS) to prepare for the Multi-Factor Authentication User Portal and Multi-Factor Authentication Mobile Portal and the Web Services SDK and to configure service accounts and certificates, installation of the Multi-Factor Authentication Server components themselves cannot be scripted to your needs.

    That doesn’t sound too bad, except for when you want to deploy the Multi-Factor Authentication Server in an environment that requires quick scale out and scale back. Adding a new fresh Multi-Factor Authentication Server to that mix, or removing it, is not as easy as it sounds.

      

    2. No such thing as an IIS Agent

    Yes, you can install a special sleek package on your Active Directory Federation Services (AD FS) Servers to add multi-factor authentication to all your claims-based web-based application connected to it, but there is no such package for Internet Information Services (IIS).

    The Windows Integrated Authentication (WIA) and Forms-based Authentication (FBA) features only work for web-based applications, but it requires full installations of Azure Multi-Factor Authentication Server on these IIS Servers. Of course, you can reroute only the login pages to these IIS Servers and host your content on other web servers (including Apache and Nginx), but having a full server with its (replicated) database in a DMZ network is far from ideal.

      

    3. No database encryption

    Azure Multi-Factor Authentication Server uses its own phonefactor.pfdata file to store its settings and directory. There is an ingenious replication mechanism to keep this file up to date (that actually involves copying complete copies of the file around) so you don’t really have to worry about database corruption.

    Unless someone writes ‘Sander was here’ in this file. Who would do such a thing, right!? Oh wait. I actually would (and did) for Disaster Recovery purposes. Verhitte emoticon

    Upon opening the phonefactor.pfdata file on several Multi-Factor Authentication Servers, however, I found that several of the pieces of information are actually simply stored in plain text in this file. (just scroll down a bit and you’ll come across your user definitions).

    For a security product, this is far from ideal.

      

    4. No API or PowerShell

    Remember Microsofts 2009 Common Engineering Criteria (CEC)? It requires every product to have PowerShell support. Azure Multi-Factor Authentication Server doesn’t have that. We’ve searched long and hard for application programming interfaces (APIs) we could use for our purposes, but didn’t find any either.

    Basically, this means that the Azure Multi-Factor Authentication Server Administration Console and the Web Portals are the only ways to manage Azure Multi-Factor Authentication Server. Installing the Administration Console only requires a full installation, so we can safely conclude that remote management of core functionality boils down to RDP’ing into the primary Azure Multi-Factor Authentication Server.

    For user management, the User Portal offers delegated and granular management to Service desk personnel.

      

    5. No Azure MFA Server Health

    My implementations of Azure Multi-Factor Authentication Server have shifted over the previous couple of years from offering RADIUS and IIS authentication to AD FS integration. It’s been a fun ride, but I’ve seen Microsofts Identity Division make great improvements in the Hybrid Identity stack, where they’ve left Azure Multi-Factor Authentication Server in the dark.

    Azure AD Connect Health offers centralized monitoring, reporting and troubleshooting in one Azure-based dashboard for Azure AD Connect installations, Web Application Proxies, Active Directory Federation Services (AD FS) and Active Directory Domain Services (AD DS), but not for Azure Multi-Factor Authentication Server.

    Single Pane? Single Pain.

     

    6. SIEM and TSCM are hard

    Azure Multi-Factor Authentication Server offers logging. Its logging capabilities are granular and its log entries are concise. However, every component on every Azure Multi-Factor Authentication Server is logged into its own plain text file and log rotation is based on file sizes.

    We’ve spent weeks at a customer building a centralized Technical State Compliancy Monitoring (TSCM) solution for their eight Azure Multi-Factor Authentication Servers and plugging into their centralized Security Information and Event Management (SIEM) configuration: While user auditing in Azure Multi-Factor Authentication Server is very mature and even offers SYSLOG integration, auditing configuration changes is hard.

     

    7. No programmatic queue monitoring

    One of the technical limitations we’ve regularly hit at customers is the length of the authentication queue on the side of the Multi-Factor Authentication Provider in Azure. When phone-based and text-based authentication requests are in this queue for too long, the authentication request times out and end-users can’t log on.

    There is no programmatic way to get access to this queue. It’s displayed in the PhoneFactor portal, but having someone refresh this page three times per minute surely isn’t my definition of actively managing the authentication queue…

     

    8. Azure Multi-Factor Authentication still lives in the old Portal

    While large portions of Azure Active Directory and its related Identity solutions have moved to the new ‘Ibiza’ portal, the Multi-Factor Authentication Provider that Azure Multi-Factor Authentication Server relies on, is only available in the Azure Management Website, or as many have come to refer to as ‘the old portal’.

     

    9. No support for RSA Tokens

    Yes, Azure Multi-Factor Authentication supports hard tokens. It’s great!
    Except for the fact that it doesn’t support the one hard token almost every organization has entrenched themselves with in my neck of the woods: the RSA token.

    Azure Multi-Factor Authentication supports OATH-based hard tokens, like the ones from Gemalto, Yubico, Feitian, Secutech and Vasco.

     

    10. You’ll need (at least) two MFA Solutions

    Azure Multi-Factor Authentication Server does not protect Windows interactive logons. While this seems like an edge case, the ‘Windows Integrated Authentication’-feature to protect web-based applications often gets misunderstood as doing this.

    The Azure Multi-Factor Authentication Server User Portal always requires people perform multi-factor authentication. In delegated admin scenarios, these admins need to perform multi-factor authentication every time they log on to help a colleague or customer. This makes sense. However, admins using the Server Management Console and RDP’ing into the box(es) to manage the Azure Multi-Factor Authentication Server configuration, do not have to perform multi-factor authentication.

    You can use Azure Multi-Factor Authentication Server to protect these admin logons by making them use the RDS Web Gateway, but this won’t do you much good, when you want your admins to fix a broken Azure Multi-Factor Authentication configuration: they wouldn’t be able to go in.

    Therefore, you’d need at least two Multi-Factor Authentication solutions, where each solution protects the admin logons to the management of the other solution.

    0  

    I’m presenting at the Dutch Windows Management User Group 2017-4 Meetup

    The Dutch Windows Management User Group (WMUG) is one of the more active IT Pro user groups in the Netherlands.

    I was honored when they invited me to speak at their next meetup on September 13, 2017. Of course, I’d present at this meetup; their fourth meetup this year!

     

    WMUG NL Logo

    About the Dutch Windows Management User Group (WMUG)

    Windows Management User Group Netherlands (WMUG) is a Dutch user group offering a stage to share knowledge between fellow-IT Pros through regular and 100% community-driven user group meet-ups.

    I know many of the persons running WMUG. I’ve worked together with Adnan Hendricks at OGD, Meet Kenneth van Surksum, Arie de Haan, Erik Loef and Bob Cornelissen regularly at events and worked together with Peter Daalmans. Glimlach

     

    About the WMUG  2017-4 Meetup

    Windows Management User Group Netherlands (WMUG) organizes a free community event on Wednesday night September 13, 2017 at iSense ICT Professionals in Gouda, the Netherlands.

    The event starts at 4:30 PM with presentations and people are welcomed at the venue from 4 PM onwards. After the first one-hour presentation by Adnan Hendricks titled ‘Azure up in Arms! Automating your Azure infrastructure builds’ and a 75-minute break for diner, I have the stage for a maximum of 60-minutes, because, of course, we start enjoying drinks and snacks starting at 7:45 PM.

     

    About my presentation

    Microsoft offers a plethora of services, labeled Infrastructure-as-a-Service (IaaS).
    The large quantity of services makes it easy to overlook the true gems in Microsofts IaaS portfolio. I feel five of these gems are so unique because of their added value, but also their low (to no) cost, that IT Pros have mixed feelings. ‘Wow, this is so cool!’ and ‘This sounds too good to be true…’ alternate in IT Pros’ heads, so it’s about time to make it clear.

    I’ll explain five Microsoft IaaS gems in clear and concise language, you can’t afford to ignore as an IT Pro and which ones to embrace. Of course, I’ll also provide examples of services that appear to be gems, but are actually not (so much).

     

    Join us!

    This promises to be an excellent event!
    Register for this event for free. Dutch

    0  

    Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 2

    In the first part of this series, I’ve explained how Azure AD Connect version 1.1.553.0 and beyond allows you to switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute, the benefits of doing so and what you may and may not expect when you make the switch.

    In this second part, I’ll share the changes Azure AD Connect makes in its synchronization rules, in the Active Directory Federation Services (AD FS) claims transformation rules and a PowerShell script that you can use to grant your custom-managed Azure AD Connect service account permissions to write the mS-DS-ConsistencyGuid attribute in your on-premises Active Directory Domain Services (AD DS) environments.

     

    Determining the version of Azure AD Connect

    Now, the first thing you’d want to find out is your version of Azure AD Connect, since the embrace of the mS-DS-ConsistencyGuid attribute as the source anchor is only possible on Azure AD Connect installations running version 1.1.553.0 and up. Also, versions 1.1.561.0 and up of Azure AD Connect implement the change automatically, when you perform a fresh installation of Azure AD Connect.

    Perform these steps to determine your version of Azure AD Connect:

    • Log on interactively to the Windows Server installation that runs Azure AD Connect.
    • Right-click the Start button on the bottom left corner of your screen, or press Win + X simultaneously.
    • Select Programs and Features from the top of the context menu.

    Programs and Features (click for original screenshot)

    • In the list below Uninstall or change a program look into the Version column for Microsoft Azure AD Connect.

    Perform these steps for all Azure AD Connect installation(s) in your infrastructure. Don’t forget to check and upgrade your Staging Mode servers.

     

    Determining the attribute used as the source anchor for user objects in Azure AD Connect

    Perform these steps to determine the current attribute used as source anchor in your Azure AD Connect installation(s):

    • Log on interactively to the Windows Server installation that runs Azure AD Connect.
    • Open Azure AD Connect using the link on the desktop or by searching for (part of) its name in the Start Screen and then clicking it in the search results.
    • Click the Configure button on the Welcome to Azure AD Connect screen.
    • Click on View current configuration in the Additional tasks screen.
    • Click Next.

    Azure AD Connects Review Your Solution screen (click for original screenshot)

    • The attribute listed as the Source Anchor for user objects is listed underneath SOURCE ANCHOR in the Synchronization Settings area in the Review Your Solution screen.

    Changes in Azure AD Connects Configuration

    The following changes are observed in Azure AD Connects synchronization rules after you switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute in Azure AD Connect:

    Global Settings

    The Microsoft.SynchronizationOption.AnchorAttribute setting is changed from objectGUID to mS-DS-ConsitencyGuid

    Metaverse configuration

    The Source fields for the sourceAnchor and sourceAnchorBinary attributes for the Metaverse person have been updated.

    AD Connector Configuration

    The import flow component for the mS-DS-ConsitencyGUID attribute is enabled next to the previously enabled export flow.

    Attribute flows for the AD Connector

    The end-to-end import flow for the SourceAnchorBinary attribute for the contact object has been updated.

    The end-to-end import flows for the SourceAnchor and SourceAnchorBinary attributes for the inetOrgPerson object has been updated.

    The end-to-end import flows for the SourceAnchor and SourceAnchorBinary attributes for the user object has been updated.

    The end-to-end export flow for the mS-DS-ConsistencyGuid attribute for the user object has been added.

    The inbound provisioning rules have been updated to use the mS-DS-ConsistencyGuid as the Source Attribute.

    Attribute flows for the Azure AD Connector

    The end-to-end export flows for the dn and sourceAnchor attributes for the contact object have been updated.

    The end-to-end export flow for the dn and sourceAnchor attributes for the user object has been added.

     

    This is achieved through changes in the following synchronization rules:

    • In from AD – InetOrgPerson AccountEnabled
    • In from AD – InetOrgPerson Common
    • In from AD – InetOrgPerson Join
    • In from AD – User AccountEnabled
    • In from AD – User Common
    • In from AD – User Join
    • Out to AD – User ImmutableId
    • Out to AD – User Join SOAInA

    … and a bunch of precedence changes, of course.

     

    Granting your Azure AD Connect Service Account permissions to write to the mS-DS-ConsistencyGuid attribute

    Use the following lines of PowerShell to grant a custom-managed service account for Azure AD Connect the permissions to write to the mS-DS-ConsistencyGuid attribute throughout your on-premises Active Directory Domain Services (AD DS) environment, when you follow the rules for least administrative privileges for service accounts:

    #Specify the Base DN from where you d want to propogate:
    $DN = “OU=Service accounts,OU=my,DC=domain,DC=tld”

    #Specify the service acocunt itself
    $Account = “domain\sa_aadconnect”

    #Build the command line using dsacls.exe
    $cmd = “dsacls ‘$DN‘ /I:S /G ‘`”$Account`”:RPWP;`”mS-DS-ConsistencyGuid`”;user'”

    #Run the command line
    Invoke-Expression $cmd

    Note:
    Run the above PowerShell script in all Active Directory Domain Services (AD DS) environments in scope of Azure AD Connect synchronization.

    Note:
    If you want to granularly grant permissions to the service account, create scripts to target each of the Organizational Units (OUs) in scope of Azure AD Connect synchronization, on the highest level, or use the guidance here.

     

    Changes in Active Directory Federation Services (AD FS) claims rules with the mS-DS-ConsistencyGUID attribute as Source Anchor

    When you switch from objectGUID to mS-DS-ConsistencyGuid as the source anchor attribute, you’ll see that Azure AD Connect makes the following changes to the Active Directory Federation Services (AD FS) claims rules, when you manage AD FS through Azure AD Connect.

    The following claims issuance rule when using ObjectGUID as the Source Anchor:

    @RuleName = “Issue Immutable ID”

    c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname“]

    => issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID“), query = “samAccountName={0};objectGUID;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)“, “${user}”), param = c.Value);

    Is replaced with the following four claims issuance rules to accommodate mS-DS-ConsistencyGuid as the Source Anchor:

    @RuleName = “Query objectguid and msdsconsistencyguid for custom ImmutableId claim”

    c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname“]

    => add(store = “Active Directory”, types = (“http://schemas.microsoft.com/ws/2016/02/identity/claims/objectguid“, http://schemas.microsoft.com/ws/2016/02/identity/claims/msdsconsistencyguid), query = “samAccountName={0};objectGUID,mS-DS-ConsistencyGuid;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)“, “${user}”), param = c.Value);

     

    @RuleName = “Check for the existence of msdsconsistencyguid”

    NOT EXISTS([Type == “http://schemas.microsoft.com/ws/2016/02/identity/claims/msdsconsistencyguid“])

    => add(Type = “urn:federation:tmp/idflag”, Value = “useguid”);

     

    @RuleName = “Issue msdsconsistencyguid as Immutable ID if it exists”

    c:[Type == “http://schemas.microsoft.com/ws/2016/02/identity/claims/msdsconsistencyguid“]

    => issue(Type = “http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID“, Value = c.Value);

     

    @RuleName = “Issue objectGuidRule if msdsConsistencyGuid rule does not exist”

    c1:[Type == “urn:federation:tmp/idflag”, Value =~ “useguid”]
    && c2:[Type == “http://schemas.microsoft.com/ws/2016/02/identity/claims/objectguid“]

    => issue(Type = “http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID“, Value = c2.Value);

     

    Concluding

    Now we have a good understanding of what the switch from objectGuid to mS-DS-ConsistencyGuid as the source anchor attribute actually entails, it’s time to perform it.

    Join me for Part 3, where I show you how to perform the switch, and do all the work, so you won’t forget any steps.

    4  

    Identity-related sessions at Microsoft Ignite 2017 in Orlando

    Microsoft Ignite 2017 North America in Orlando is only a few weeks away and many of us have begun filling their session builder with interesting sessions, corresponding to their interests and knowledge.

    I decided to compile a list of the Active Directory, Azure Active Directory, Graph, Group Policy  and Enterprise Mobility + Security (EM+S) related sessions at Ignite 2017. I’ve compiled the list below, divided per Ignite session type and arranged by date, since Ignite offers breakout sessions, theater sessions, workshops, hands-on labs and even studio recordings (not all apply to identity).

    Breakout Sessions (75 minutes)

    When your goal at Ignite is to learn about the different Active Directory technologies and Group Policy topics, breakout sessions offer the most bang for your buck. In 75 minutes, speakers show technologies with presentations and demos.

    What’s New and upcoming in AD FS to securely sign-in your users to Office 365 and other applications
    Monday September 25 4PM-5:15PM, OCCC W307
    Speaker: Samuel Devasahayam Star

    Productivity and protection for your employees, partners and customers with Azure Active Directory
    Tuesday September 26 9AM-10:15AM, OCCC Valencia W415AB
    Speakers: Nasos Kladakis and Alex Simons Star

    Credential protection in Windows: An overview
    Tuesday September 26 4PM-5:15PM, OCCC West Hall E1
    Speaker: Yogesh Mehta

    Making life easier for IT: Automating credential management on connected and disconnected systems
    Wednesday September 27 10:45AM-12PM, OCCC S320 E-H
    Speaker: Philip Lieberman

    Windows devices in Azure Active Directory: Why should I care?
    Wednesday September 27, 2:15PM-3:30PM, OCCC S331
    Speaker: Jairo Cadena Star

    What’s New in Azure Active Directory Domain Services
    Wednesday September 27 4PM-5:15PM, Hyatt Plaza International I-K
    Speaker: Mahesh Unnikrishnan

    Shut the door to cybercrime with Azure Active Directory risk-based identity protection
    Wednesday September 27 4PM-5:15PM, OCCC Chaprin Theater W320
    Speaker: Nitika Gupta

    Extending Windows Hello with trusted signals
    Wednesday September 27 4PM-5:15PM, OCCC Valencia W415AB
    Speaker: Chris Bortlik

    Share corporate resources with your partners using Azure Active Directory B2B collaboration
    Thursday September 28 9AM-10:15AM, OCCC W208 AB,
    Speakers: Mary Lynch and Sarat Subramaniam

    Transition to cloud-based management of Windows 10 and Office 35 ProPlus with EMS
    Thursday September 28 9AM-10:15AM, OCCC West Hall 4B
    Speakers: Janani Vasudevan and Maayan Bar-Niv

    The keys to the cloud: Use Microsoft identities to sign in and access API from your mobile+web apps
    Thursday September 28 10:45AM-12PM, OCCC S310
    Speaker: Vittorio Bertocci Star

    Ensure users have the right access with Azure Active Directory
    Thursday September 28 12:30PM-1:45PM, OCCC Valencia W415AB
    Speaker: Joseph Dadzie

    Secure Windows 10 with Intune, Azure AD and System Center Configuration Manager
    Thursday September 28 12:30PM-1:45PM, OCCC West Hall B4
    Speaker: Dune Desormeaux

    Deep-dive: Azure Active Directory Authentication and Single Sign-On
    Thursday September 28 2:15PM-3:30PM, OCCC W414
    Speaker: John Craddock Star

    Microsoft’s guide for going password-less
    Thursday September 28 2:15PM-3:30PM, OCCC W207AB
    Speaker: Yogesh Mehta

    Azure Active Directory best practices from around the world
    Thursday September 28 4PM-5:15PM, OCCC Valencia W415AB
    Speakers: Tarek Dawoud and Mark Morowczynski Star

    Achieving a modern workplace with Windows 10, EM+S and Office 365
    Friday September 29 12:30PM-1:45PM, Hyatt Plaza International I-K
    Speaker: Paul Huijbregts

      

    Breakout sessions (45 minutes)

    There are also 45-minute Breakout sessions:

    Saying goodbye to passwords
    Tuesday September 26 12:45PM-1:30PM, OCCC W240
    Speaker: Alex Simons Star

    Microsoft Office 365 security and compliance
    Wednesday September 27 10:15AM-11AM, OCCC South – MSFT TechCenter
    Thursday September 28 3:15PM-4PM, OCCC South – MSFT TechCenter
    Speaker: Ed Hild

    The power of common identity across any cloud
    Wednesday September 27, 12:45PM-1:30PM, OCCC West Hall F3-4
    Speakers: Nasos Kladakis and Alex Simons Star

    Deliver management and security at scale to Office 365 with Azure Active Directory
    Wednesday September 27 3:15PM-4PM, Hyatt Plaza International H

    Modernize your customer identity management with Azure Active Directory B2C
    Friday September 29 9AM-9:45AM, OCCC West Hall F3-4
    Speaker: Saeed Akhter

    Theater Sessions

    When a deep-dive is not really necessary, why not opt for a 20-minute session, focusing on a specific part of a technology, explained and/or demoed by experts from the field, featuring real-world examples and cases. Theater sessions at Ignite offer this kind of interaction, and it’s no wonder most of these sessions are led by Microsoft Most Valuable Professionals (MVPs):

    Azure Active Directory Domain Services
    Monday September 25 4:35PM-4:55PM, OCCC South – Expo 10

    Using Azure Active Directory B2C for your WordPress site configuration and security considerations
    Monday September 25 7:05PM-7:25PM, OCCC South – Expo 1
    Speaker: Bill Hughes

    Five mistakes to avoid when deploying Enterprise Mobility + Security
    Tuesday September 26 10:50AM-11:10AM, OCCC South – Expo 4, Jussi Roine

    Managing enterprise applications, permissions and consent in Azure Active Directory
    Tuesday September 26 2:10PM-2:30PM, OCCC West Level 2
    Speaker: Jeff Sakowicz

    Group Policy in MDM: Dealing with ADMX backed policies
    Tuesday September 26 3:35PM-3:55PM, OCCC South – Expo 5
    Speaker: Raymond Comvalius Star

    Enterprise-grade security for your cloud apps with Microsoft Cloud App Security
    Tuesday September 26 5:05PM-5:25PM, OCCC South – Expo 10

    Surviving identity management in a hybrid world
    Wednesday September 27 10:20AM-10:40AM, OCCC South – Expo 11
    Speaker: Elias Mereb Star

    Make Windows devices more secure by taking them out of your existing infrastructure
    Wednesday September 27 10:50AM-11:10AM, OCCC South – Expo 7
    Speaker: Chris Rodes

    How to secure your front door with real-time risk assessments of your logons
    Wednesday September 27 12:35PM-12:55PM, OCCC South – Expo 4
    Speaker: Jan Ketil Skanke

    Four common problems to avoid with your AD FS environment
    Wednesday September 27 2:10PM-2:30PM, OCCC South – Expo 4
    Speaker: Sander Berkouwer Winking smile

    What’s your Active Directory recovery plan?
    Wednesday September 27 5:05PM-5:25PM, OCCC South – Expo 2
    Speaker: Shawny Reiner

    Fixing bad IT security: Stupid mistakes and dangerous conveniences
    Wednesday September 27 5:35PM-5:55PM, OCCC South – Expo 2
    Speaker: Philip Lieberman

    Windows 10 and the cloud: Why the future needs hybrid solutions
    Thursday September 28 10:20AM-10:40AM, OCCC South – Expo 7
    Speaker: Alex Benoit

    Manage mobile productivity with Microsoft Enterprise Mobility + Security (EMS)
    Thursday September 28 12:05PM-12:25PM, OCCC South – Expo 10
    Speaker: Vladimir Petrosyan

    Holistic management for Microsoft Azure and the hybrid IT ecosystem
    Thursday September 28 12:40PM-1PM, OCCC South – Expo 3

    Microsoft Studio

    If you’re looking to experiencing a live show on Azure Active Directory and the hybrid identity options, be sure to attend the following session:

    Azure Active Directory: Your options explained from AD sync to pass-through authentication and more
    Tuesday September 26, 2:10PM-2:30PM

     

    Tip!

    When you’re not attending Microsoft Ignite, this year, use the above list of Identity-related sessions to convince your manager.

    When you are attending Ignite and are into identity, please use the above list to add some identity flavor to your session builder: especially the sessions I’ve denoted with a star are worth your time. Of course, I invite you to visit my community session, but be sure that with every presentation, a certain amount of booth time is involved: contact me with any questions you may have.

    0