Pictures of WinDays 19

WinDays

In the first week of April, I traveled to Šibenik to deliver a session at WinDays 19 Technology.

My trip started with a flight from Amsterdam Schiphol Airport to Zagreb’s new Franjo Tuđman Airport. I had reserved a car and drove it to Amadria Park in Šibenik, where I arrived around 8PM.

My Hertz Rental CarCroatia's A1 highway near Zadar
Amadria Park's Hotel Jakov at night

I ran into Sasa Kranjac, Goran Žarinac, Catalin Gheorghiu, Rastko Đorđević and André Melancia on my way in, but decided to get a meal before going to the WinDays party. We eventually arrived at the party, but left after one drink… Well, at least I did.

Convention Center Šibenik Entrance to WinDays 19

The next morning, I went to pick up the bag, explore the rooms and just mingle with the attendees of the WinDays Conference. I sat down in a quiet corner and prepared my slides and demos, while doing some work for a customer.

Umbrellas on the beachMore beachRelaxing at the PoolGetting some Work done

Before my session, I decided to clear my head. Walk around the resort for an hour, and saw Marin Frankovic with a couple of his former colleagues. I joined them for a couple of minutes, before heading off to room Šibenik 5 at the Convention Center.

Heading back to the Convention CenterQuiet before the Storm
Presenting at WinDays

After my presentation, we went for diner, I met with Adis Jugo and some other speakers and we had great conversations. I went to bed early, because I needed to leave early on Friday morning to Zagreb Airport.

I left at 4 AM. I got at Zagreb Airport at 8 AM and got on the plane to Paris Charles de Gaulle Airport. After breakfast in Paris, another plane took me to Amsterdam. I did some more work for a customer before I had dinner with my family and closed off the week.

Thank you!Thumbs up

Thank your for inviting me as a WinDays speaker once again, and to all the people attending, sitting in on my session and, of course, the people who stuck around after these sessions for the interesting discussions.

0  

I’m presenting my Active Directory 101 course with Netwrix again

Netwrix Active Directory 101

Whether you are an Active Directory novice or an experienced IT professional, enroll in my upcoming free online course for step-by-step instructions and industry best practices for Active Directory management.

These sessions are also a great way to get ready for Exam 70-742.

Note:
These webinars cover only 3 out of 5 topics for Microsoft exam 70-742: the Active Directory Domain Services (AD DS) ones. You will need to find a source for Active Directory Federation Services (AD FS), AD LDS and AD RMS to fully prepare for the exam.

       

Three webinars

1. Active Directory 101: Install and Configure AD Domain Services

Tuesday April 23 2019 1PM EDT / 7PM CEST

This webinar covers the first section of the Exam 70-742. We’re focusing on effective installation and administration of Active Directory. Apart from step-by-step training, the session also explores the potential pitfalls of AD configuration and the ways to ensure reinforced security of your IT environment.

Watch this webinar to explore:

  • How to install and configure domain controllers
  • Best practices in creation of AD users and computers
  • How to effectively approach AD groups and Organizational Unit (OU) management
  • Netwrix Auditor’s reporting functionality to help you mitigate cyber risks and enforce good IT hygiene

2. Active Directory 101: Manage and maintain AD Domain Services

Thursday April 25 2019 1PM EDT / 7PM CEST

Once the Active Directory Domain Controllers are configured and groups are set in place, it’s time to explore the options you have for monitoring AD changes. Watch this webinar to prepare for the second section of Exam 70-742, dedicated to continuous management of Active Directory.

During this session, you will learn:

  • Main techniques to configure service authentication and account policies
  • Top methods to maintain Active Directory
  • How to configure Active Directory in a complex enterprise environment
  • How to determine which changes in your environment merit inspection with Netwrix Auditor

3. Active Directory 101: Create and Manage Group Policy

Tuesday April 30 2019 1PM EDT / 7PM CEST

Proper Group Policy setup and management can ensure continuous uninterrupted functionality of any organization. This session covers the third section of Exam 70-742 about Group Policy management and explains how Group Policy auditing can mitigate the risk of security breaches and compliance failures.

By the end of this session, you will know:

  • How to create and manage Group Policy Objects
  • Top methods to configure Group Policy processing, settings and preferences
  • How to deliver complete visibility into all security and configuration changes in Group Policy

     

Join me!

Advance your career as a systems administrator and start aiming to attend the live sessions, or get access by the recordings if you cannot join online.

Register here.

Note:
These webinars are offered free of charge, thanks to the sponsoring by Netwrix. By signing up for these webinars you agree to their privacy policy.

     

About Netwrix

Netwrix logoNetwrix is a private IT security software company. They offer IT auditing solutions for systems and applications across your IT infrastructure. Netwrix  specializes in change, configuration and access auditing software with its Netwrix Auditor solution. Netwrix is a partner of Microsoft, VMware, EMC, NetApp and HP ArcSight.

If you’ve worked in highly-secure highly-regulated IT environments, you’re probably familiar with the Netwrix brand, because their Active Directory auditing solution is one of the best out there.

2  

Knowledgebase: In-place Upgrading Domain Controllers to Windows Server 2019 while still using NTFRS breaks SYSVOL Replication and DSLocator

Windows Server

In a domain that is configured to use the File Replication Service, the SYSVOL folder is not shared after you in-place upgrade a Windows Server 2019-based Domain Controller from an earlier version of Windows. Until this directory is shared, Domain Controllers do not respond to DCLOCATOR requests for LDAP, Kerberos, and other Domain Controller workloads.

   

The situation

In a domain that uses the legacy File Replication Service(NTFRS) for the Active Directory System Volume (SYSVOL), you in-place upgrade a Domain Controller to Windows Server 2019.

    

The issue

When you try to migrate the domain to Distributed File System (DFS) Replication, the following issues occur:

  • All Windows Server 2019-based Domain Controllers in the domain stop sharing the SYSVOL folder and stop responding to DCLOCATOR requests.
  • All Windows Server 2019-based Domain Controllers in the domain have the following event log errors:
    • Event ID 8013 with source DFS Replication
    • Event ID 8028 with source DFS Replication

When you run dfsrmig.exe /GetMigrationState, this command generates the following output for all Windows Server 2019 Domain Controllers:

The following domain controllers have not reached Global state (‘Prepared’): Domain Controller (Local Migration State) – DC Type ===================================================
<Computer name> (‘Start’) – Writable DC Migration has not yet reached a consistent state on all domain controllers. State information might be stale due to Active Directory Domain Services latency.

    

The cause

The File Replication Service (FRS) was deprecated in Windows Server 2008 R2 and is included in later operating system releases for backwards compatibility only.

Starting in Windows Server 2019, promoting new Domain Controllers requires DFS Replication (DFSR) to replicate the contents of the SYSVOL share. If you try to promote a Windows Server 2019-based computer in a domain that still using FRS for SYSVOL replication, the following error occurs:

Verification of prerequisites for Domain Controller promotion failed. The specified domain domain.tld is still using the File Replication Service (FRS) to replicate the SYSVOL share. FRS is deprecated. The server being promoted does not support FRS and cannot be promoted as a replica into the specified domain. You MUST migrate the specified domain to use DFS Replication using the DFSRMIG command before continuing. For more information, see https://go.microsoft.com/fwlink/?linkid=849270

However, in-place upgrading a Windows Server 2012 R2 or Windows Server 2016-based Domain Controller to Windows Server 2019 does not enforce this block.

When you then run dfsrmig.exe /SetGlobalState to migrate SYSVOL replication to DFSR, all upgraded Windows Server 2019 Domain Controllers are stuck in the Start phase and cannot complete the transition to the Prepared or later phases. Therefore, the SYSVOL and NETLOGON folders for the Domain Controllers are no longer shared, and the Domain Controllers stop responding to location questions from clients in the domain.

   

The solution

There are several workarounds for this issue, depending on which migration global state you specified earlier.

Issue occurs in the Preparing or Redirecting phase

  1. If you have already run dfsrmig.exe /SetGlobalState 1 or dfsrmig.exe /SetGlobalState 2 previously, run the following command as a Domain Admin:
             
    dfsrmig.exe /SetGlobalState 0
             
  2. Wait for Active Directory replication to propagate throughout the domain, and for the state of Windows Server 2019 Domain Controllers to revert to the Start phase.
  3. Verify that SYSVOL is shared on those Domain Controllers and that SYSVOL is replicating as usual again by using NTFRS.
  4. Make sure that at least one Windows Server 2008 R2, Windows Server 2012 R2, or Windows Server 2016-based Domain Controller exists in that domain. Verify all Active Directory partitions and the files in the SYSVOL are fully sourced from one or more source Domain Controllers and that they are replicating Active Directory as usual before you demote all of your Windows Server 2019 Domain Controllers in the next step. For more information, see Troubleshooting Active Directory Replication Problems.
  5. Demote all Windows Server 2019-based Domain Controllers to member servers. 
    This is a temporary step.
  6. Migrate SYSVOL to DFSR normally on the remaining Windows Server 2008 R2, Windows Server 2012 R2, and Windows Server 2016 Domain Controllers.
  7. Re-promote the Windows Server 2019-based member servers to Domain Controllers.
              

Issue occurs in the Eliminating phase

The FRS elimination phase cannot be rolled back by using dfsrmig.exe. If have already specified FRS elimination, you can use either of the following workarounds.

Option 1

If you still have one or more Windows Server 2008 R2, Windows Server 2012 R2, or Windows Server 2016-based Domain Controllers in that domain, verify all Active Directory partitions and the files in the SYSVOL are fully sourced from one or more source Domain Controllers and that they are replicating Active Directory as usual before you demote all of your Windows Server 2019 Domain Controllers in the next step. For more information, see Troubleshooting Active Directory Replication Problems.

  1. Demote all Windows Server 2019-based Domain Controllers. 
    This is a temporary step.
  2. Migrate SYSVOL to DFSR as usual on the remaining Windows Server 2008 R2, Windows Server 2012 R2, and Windows Server 2016 Domain Controllers.
  3. Re-promote the Windows Server 2019-based member servers to Domain Controllers.

Option 2

If all Domain Controllers in the domain are running Windows Server 2019, perform these steps:

  1. Open AdsiEdit (AdsiEdit.msc)
  2. In the AdsiEdit tool, change the following distinguished name value and attribute on the PDC Emulator:
              
    CN=DFSR-GlobalSettings,CN=System,DC=domain,DC=tld
    msDFSR-Flags = 0

            
  3. Wait for Active Directory replication to propagate throughout the domain.
  4. On all Windows Server 2019 DCs, change the DWORD type registry value Local State to 0:

    Registry Setting: Local State
    Registry Path:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating SysVols
    Registry Value: 0
    Data Type: REG_DWORD
               

  5. On all Windows Server 2019 Domain Controllers, restart the following services by running the following lines of Windows PowerShell:

    Restart-Service NetLogon
    Restart-Service DFSR

  6. Verify that SYSVOL has shared on those Domain Controllers and that SYSVOL is replicating as usual again by using FRS.
  7. Promote one or more Windows Server 2008 R2, Windows Server 2012 R2, or Windows Server 2016-based Domain Controller in that domain.  Verify all Active Directory partitions and the files in the SYSVOL are fully sourced from one or more source Domain Controllers and that they are replicating Active Directory as usual before you demote all of your Windows Server 2019 Domain Controllers in the next step. For more information, see  Troubleshooting Active Directory Replication Problems.
  8. Demote all Windows Server 2019-based Domain Controllers to member servers.
    This is a temporary step.
  9. Migrate SYSVOL to DFSR as usual on the remaining Windows Server 2008 R2, Windows Server 2012 R2, and Windows Server 2016-based Domain Controllers.
  10. Re-promote the Windows Server 2019-based member servers to Domain Controllers.
  11. Optional: Demote the Windows Server 2008 R2, Windows Server 2012 R2, or Windows Server 2016-based Domain Controllers that you added in step 7.

     

Concluding

NTFRS is an old technology, but many organizations still seem to cling onto it. It’s not hard to migrate, but it just needs to be done. We’ve been putting this tasks on agendas of Active Directory admins for a while now, but regret seeing that this slight code defect means admins that haven’t performed this action yet, may now start experiencing troubles.

Troubleshooting NTFRS without burflags? Wow. Hot smile

Further reading

4493934 SYSVOL DFSR Migration fails after you in-place upgrade a Domain Controller to Windows Server 2019 
SYSVOL Replication Migration Guide: FRS to DFS Replication
SYSVOL Replication Migration Guide: FRS to DFS Replication (downloadable)
Streamlined Migration of FRS to DFSR SYSVOL

0  

What’s New in Azure Active Directory for March 2019

Azure Active Directory

Azure Active Directory is Microsoft’s Identity Management-as-a-Service solution, offering seamless access, easy collaboration, efficiency in IT processes and improved security and compliance. In its Release Notes for Azure Active Directory, Microsoft communicated the following planned, new and changed functionality for Azure Active Directory for March 2019:

        

What’s Planned

Updates to condition evaluation by Exchange ActiveSync (EAS) Breaking change

Service category: Conditional Access
Product capability: Access Control

Microsoft is in the process of updating how Exchange ActiveSync (EAS) evaluates the following conditions:

  • User location, based on country, region, or IP address
  • Sign-in risk
  • Device platform

If, as an admin, you’ve previously used these conditions in your Conditional Access policies, be aware that the condition behavior might change. For example, if you previously used the user location condition in a policy, you might find the policy now being skipped based on the location of your end-users.

            

What’s New

Identity Experience Framework and custom policy support in Azure Active Directory B2C Generally Available

Service category: B2C – Consumer Identity Management
Product capability: B2B/B2C

Admins can now create custom policies in Azure AD B2C, including the following tasks, which are supported at-scale and under Microsoft’s Azure Service Level Agreement (SLA):

  • Create and upload custom authentication user journeys by using custom policies.
  • Describe user journeys step-by-step as exchanges between claims providers.
  • Define conditional branching in user journeys.
  • Transform and map claims for use in real-time decisions and communications.
  • Use REST API-enabled services in custom authentication user journeys. For example, with email providers, CRMs, and proprietary authorization systems.
  • Federate with identity providers who are compliant with the OpenIDConnect protocol. For example, with multi-tenant Azure AD, social account providers, or two-factor verification providers.

   

New Federated Apps available in Azure AD app gallery

Service category: Enterprise Apps
Product capability: 3rd Party Integration

In March 2019, Microsoft has added these 14 new apps with Federation support to the Azure AD App Gallery:

        

New Zscaler and Atlassian provisioning connectors in the Azure AD gallery

Service category: App Provisioning
Product capability: 3rd Party Integration

Automate creating, updating, and deleting user accounts for the following apps with the new provisioning connectors from the Azure AD Gallery:

       

Restore and manage deleted Office 365 groups in the Azure AD portal

Service category: Group Management
Product capability: Collaboration

Admins can now view and manage deleted Office 365 groups from the Azure AD portal. This change helps them to see which groups are available to restore, along with letting them permanently delete any groups that aren’t needed by the organization.

        

Single sign-on for Azure AD SAML-secured on-premises apps through the Azure AD Application Proxy public preview

Service category: App Proxy
Product capability: Access Control

Admins can now provide a single sign-on (SSO) experience for on-premises, SAML-authenticated apps, along with remote access to these apps through the Azure AD Application Proxy.

       

Client apps in request loops will be interrupted to improve reliability and user experience

Service category: Authentications (Logins)
Product capability: User Authentication

Client apps can incorrectly issue hundreds of the same login requests over a short period of time. These requests, whether they’re successful or not, all contribute to a poor user experience and heightened workloads for the IDP, increasing latency for all users and reducing the availability of the Identity Provider (IdP).

     

What’s Changed

New Audit Logs user experience now available

Service category: Reporting
Product capability: Monitoring & Reporting

Microsoft has created a new Azure AD Audit logs page to help improve both readability and how admins search for information. To see the new Audit logs page, select Audit logs in the Activity section of Azure AD.

      

New warnings and guidance to help prevent accidental administrator lockout from misconfigured Conditional Access policies

Service category: Conditional Access
Product capability: Identity Security & Protection

To help prevent administrators from accidentally locking themselves out of their own tenants through misconfigured Conditional Access policies, Microsoft has created new warnings and updated guidance in the Azure portal.

Improved end-user Terms of use experiences on mobile devices

Service category: Terms of Use
Product capability: Governance

Microsoft has updated their existing Terms of Use (ToU) experiences to help improve how admins review and consent to Terms of Use on a mobile device. End-users can now zoom in and out, go back, download the information, and select hyperlinks.

  

New Azure AD Activity logs download experience available

Service category: Reporting
Product capability: Monitoring & Reporting

Admins can now download large amounts of activity logs directly from the Azure portal. This update lets them:

  • Download up to 250,000 rows.
  • Get notified after the download completes.
  • Customize the file name.
  • Determine the output format, either JSON or CSV.
0  

Veeam Backup for Office 365 now offers support for the Baseline Policy ‘Require MFA for Admins’

Veeam Backup for Microsoft Office 365

Today’s release of version 3.0.0.422 of Veeam Backup for Office 365 (VBO) offers many new features and benefits, but none as significant as the ability to use multi-factor authentication for the admin account when configuring and reconfiguring VBO.

Let me explain why.  

    

Azure AD Privileged access, today

Microsoft is working hard to further harden Azure Active Directory tenants, so the roughly 18 million organization depending on it, don’t get disappointed by Azure AD-based security breaches and don’t have to worry about attacks on their infrastructure.

One of the newest technologies Microsoft is developing is Baseline Policies. Using baseline policies, fields of attention will be addressed automatically and continually. The first baseline policy, which is now in public preview, is the Baseline Policy: Require MFA for admins.

Currently, this baseline policy is in public preview and non-enforced. However, Microsoft is planning to turn this baseline policy on, automatically, in the near future.

       

About the Baseline Policy: Require MFA for admins (Preview)

The Baseline Policy: Require MFA for admins (Preview) in Azure AD requires multi-factor authentication for the following directory roles:

  • Global administrators (also known as Company administrators)
    This role permits access to all administrative features across Azure AD and Office 365. This is the most powerful role.
  • SharePoint administrators
    This role permits access to the SharePoint online admin center. This includes the ability to create, delete, and assign permissions to site collections and manage OneDrive for Business.
  • Exchange administrators
    This role permits management of Exchange Online. This includes the ability to grant Send As and Send on Behalf permissions to users for other user’s mailboxes.
  • Conditional Access administrators
    This role grants the ability to manage Azure Active Directory conditional access settings. To deploy Exchange ActiveSync conditional access policy in Azure, the user must also be a Global Administrator.
  • Security administrators
    This role grants the ability to read security and audit information, and to manage the Privileged Identity Management service and the Identity Protection Center (requires Azure AD Premium P2).

These roles have a high potential to be misused. To verify the authentication for users with these roles within your tenant, additional authentication is required in the form of Azure Multi-Factor Authentication (Azure MFA)

    

Veeam Backup for Office 365 and the Baseline Policy

Veeam Backup for Office 365 version 2 requires a service account with the SharePoint administrators role. This service account is impacted by the Baseline Policy: Require MFA for admins (Preview) and the service account keeps popping up at organizations that use VBO and use my script to assess the impact that the new Baseline Policy for Admins in Azure AD might have. Up till today, they had no other option than to disable the Baseline Policy, or to exclude the VBO service account.

That stops today.

     

Call to action

If your organization uses Veeam Backup for Office 365, please upgrade to Veeam Backup for Office 365. Lightning speed backups, data protection reports and flexible retention options are also thrown in the mix, but in my opinion the multi-factor authentication support and the fact that Veeam Backup for Microsoft Office 365 v3.0.0.422 now connects to Office 365 securely by leveraging a custom application in Azure AD along with an MFA-enabled service account with its app password to create secure backups is the best reason to upgrade.

Security first! Thumbs up

   

Known issues when upgrading

Please be aware of the following upgrade notes:

  • Upgrade from the beta version of the application is not supported.
  • After upgrading from version 1.5 or 2.0 to 3.0, the nearest scheduled job run is displayed in the console as performing a Full sync, though actually it performs Incremental sync. The amount of transferred data, however, will show that only changes are being synchronized during that job session.
  • If you have edited the Config.xml file for Veeam Backup for Microsoft Office 365 manually, these modifications will not be preserved after the upgrade. You may need to make new custom settings (if necessary).

   

Further reading

What’s new in v3 of Veeam’s Office 365 backup 
NEW Veeam Backup for Microsoft Office 365 v3   
Veeam Backup for Office 365 v3 Product overview    
Veeam Backup for Office 365 v3 User guide  
Veeam Backup for Office 365 v3.0.0.422 Release notes

0  

The state of Azure AD PowerShell today

PowerShell

Currently, there’s four Windows PowerShell modules to manage settings and objects in Microsoft’s Azure Active Directory:

  1. MSOnline
  2. AzureAD
  3. AzureADPreview
  4. AzureAD.Standard.Preview

         

MSOnline

The MSOnline Module, with its *-MSOL* cmdlets, was the first Windows PowerShell Module for Azure Active Directory. It started life as a PowerShell Module to manage all Microsoft Online Services, hence the name. Microsoft refers to this module as version 1.0.

The cmdlets in the MSOnline PowerShell Module use its own non-public-callable API. Currently, the MSOnline module is the most complete module for CRUD of common objects in the directory.

          

AzureAD

The AzureAD Module, with its *-AzureAD* cmdlets, was introduced on November 17th, 2016. Its full name is Azure Active Directory PowerShell for Graph, which gives away the reasoning behind the existence of this PowerShell module next to the MSOnline module: The AzureAD PowerShell module started life as a result of the vision that all the CRUD functionality should be available through public APIs. The Graph API was the API chosen. Microsoft refers to this module as version 2.0. Its current version is version 2.0.2.4.

The AzureAD module, and its dependencies, can be installed and updated using PowerShellGet from the PowerShell Gallery. It requires PowerShell 3.0 or above.

To install the AzureAD Module run Install-Module AzureAD

In comparison to other PowerShell modules, the AzureAD Module is updated by running Install-Module again. Other PowerShell modules use Update-Module

Starting in 2017, Microsoft has been offering new Azure AD-oriented cmdlets for functionality in the AzureAD module only. Cmdlets to manage the Azure AD App Proxy, for instance, are not available in the MSOnline module.

For all intents and purposes, the AzureAD module can be seen as the Generally Available (GA) module. It should be the module admins should use for management in production environment. However, some functionality is only available in the MSOnline module and Microsoft Support might ask to run Get-MSOL* cmdlets in certain scenarios. Luckily, the MSOnline and AzureAD modules can be installed side-by-side.

          

AzureADPreview

The AzureADPreview module is offered as an installable module, and is the module offered in the Azure Cloud Shell. Microsoft refers to it as version 2.0-preview. Its version, today, is version 2.0.2.5, published October 3, 2018.

The AzureADPreview module, and its dependencies, can be installed and updated using PowerShellGet from the PowerShell Gallery. It requires PowerShell 3.0 or above.

To install the AzureADPreview Module run Install-Module AzureADPreview

The AzureADPreview module, today, is different to the AzureAD module in that it references the beta Graph API..

On one system, the AzureAD and AzureADPreview modules cannot be installed side-by-side, but both modules can individually co-exist with the MSOnline module.

          

AzureAD.Standard.Preview

The AzureAD.Standard.Preview module, or in full: the Azure Active Directory .Net Standard Preview Module is a Private Preview release of Azure Active Directory .NetStandard Module, available in PSGallery Internal only.

Its current version is version 0.1.599.7, published on August 30th, 2018.

0  

I’m speaking at WinDays 19

WinDays 19

This April, I’m returning to Croatia to speak at WinDays 19 at the Šibenik Convention Center, part of Amadria Park. It’s been almost 2 years since I delivered a presentation in Croatia and it feels great to appear on the schedule for Windows 19 Technology, again.

       

About WinDays

WinDays is the leading Croatian business and technology conference, celebrating its 19th anniversary this year.  The conference brings together more than 2,000 attendees from Croatia and the region, as well as the most prestigious international and regional speakers and lecturers from the world of business and technology.

Sibenik Conference Center at Amadria Park

WinDays 19 is held from 2nd till 5th April 2019 in Šibenik and is divided into two sections: WinDays19 Business Conference, held on 2nd and 3rd April, and WinDays19 Technology Conference, which will be held from 3rd till 5th April 2019.

     

About my session

I will be delivering one 45-minute session as part of WinDays 19 Technology:

Hardening Hybrid Identity in the real world

Thursday April 4 2019 4PM – 4:45PM, Room Sibenik 5, level 400

As organizations rely heavily on Active Directory and embrace Azure AD, proper configurations of their setups becomes more important: as Azure AD is often built upon Active Directory, you need a solid base. As Azure AD offers more functionality, it too should be tuned.

To avoid the tyranny of the default settings, in some situations, we’ll look at properly securing on-premises Active Directory Domain Services environments and hardening Azure AD tenants to match their levels of security.

  

Will I see you there? Knipogende emoticon

 

Related blogposts

Pictures of WinDays 17 
Pictures of WinDays 16 in Porec, Croatia  
Pictures of WinDays XV

0  

I’m a 2019 VMware vExpert

VMware vExpert 2019 Award Announcement

I’m proud to announce I am a 2019 VMware vExpert.

Deji Akomolafe’s invitation to join the stage with him for VMworld early last year sparked my interest in VMware’s product. After presenting several sessions at both 2018 VMworld events with Matt Liebowitz and Deji, I walked away with much more knowledge of how Active Directory Domain Services (AD DS) and VMware vSphere interact. This was a huge benefit to me… but it didn’t stop there.

Deji invited me into the vSphere (pun intended), but it was Matt who encouraged me to apply for the vExpert Program. Today, I received an e-mail from the vExpert Program telling me I made the cut as a 2019 VMware vExpert.

Thank you! Thumbs up

  

About the VMware vExpert Program

The VMware vExpert Program is VMware’s global evangelism and advocacy program. The program is designed to put VMware’s marketing resources towards advocacy efforts.

The vExpert award is for individuals, not companies, and last for one year. Employees of both customers and partners can receive the vExpert award. View a list of all VMware vExperts in the vExpert Directory, including mine.

Further reading

Pictures of VMware VMworld Europe 2018
I’m speaking at VMware VMworld Europe 2018
VIDEO: ‘Virtualizing Active Directory the Right Way’ from VMware’s VMworld 2018 US
Pictures of VMware VMworld US 2018
I’m speaking at VMware VMworld US 2018

0  

What’s New in Azure Active Directory for February 2019

AzureADBanner[4]

Azure Active Directory is Microsoft’s Identity Management-as-a-Service solution, offering seamless access, easy collaboration, efficiency in IT processes and improved security and compliance. In its Release Notes for Azure Active Directory, Microsoft communicated the following new and changed functionality for Azure Active Directory for February 2019:

 

What’s New

Configurable Azure AD SAML token encryption Public preview

Service category: Enterprise Apps
Product capability: SSO

Admins can now configure any supported Security Assertion Markup Language (SAML)-based app to receive encrypted tokens. When configured and used with an app, Azure AD encrypts the emitted SAML assertions using a public key obtained from a certificate stored in Azure AD.

 

Create an access review for groups or apps

Service category: Access Reviews
Product capability: Governance

Admins can now include multiple groups or apps in a single Azure AD access review for group membership or app assignment. Access reviews with multiple groups or apps are set up using the same settings and all included reviewers are notified at the same time.

 

New Federated Apps available in Azure AD app gallery

Service category: Enterprise Apps
Product capability: 3rd Party Integration

In January 2019, Microsoft has added these 27 new apps with Federation support to the app gallery:

 

Choose specific page element versions provided by Azure AD B2C

Service category: B2C – Consumer Identity Management
Product capability: B2B/B2C

Admins can now choose a specific version of the page elements provided by Azure AD B2C. By selecting a specific version, admins can test their updates before they appear on a page and can get predictable behavior. Additionally, admins can now opt in to enforce specific page versions to allow JavaScript customizations. To turn this feature on, go to the Properties page in the user flows (previously known as: built-in policies).

 

Configurable end-user password requirements for B2C

Service category: B2C – Consumer Identity Management
Product capability: B2B/B2C

Admins can now specifically set up their organization’s password complexity for end-users, instead of having to use their native Azure AD password policy. From the Properties blade of the user flows (previously known as: built-in policies), admins can choose a password complexity of Simple or Strong, or you can create a Custom set of requirements.

 

New default templates for custom branded authentication experiences

Service category: B2C – Consumer Identity Management
Product capability: B2B/B2C

Admins can use the new default templates, located on the Page layouts blade of the user flows (previously known as: built-in policies), to create a custom branded authentication experience for users.

 

What’s Changed

Enhanced combined MFA/SSPR registration

Service category: Self-service Password Reset
Product capability: User Authentication

In response to customer feedback, Microsoft has enhanced the combined Multi-factor Authentication (MFA) and Self-service Password Reset (SSPR) registration preview experience, helping users to more quickly register their security info for both MFA and SSPR.

Over the next few weeks, Microsoft will be removing the ability for admins to turn on the old combined MFA/SSPR registration preview experience for tenants that don’t already have it turned on.

Regardless of whether admins have previously turned on the old combined MFA/SSPR registration preview experience for users or not, the old experience will be turned off at a future date. Because of that, Microsoft strongly suggests that admins move to the new, enhanced experience as soon as possible.

 

Updated policy management experience for user flows

Service category: B2C – Consumer Identity Management
Product capability: B2B/B2C

Microsoft has updated the policy creation and management process for user flows (previously known as: built-in policies) easier. This new experience is now the default for all Azure AD tenants.

Admins can provide additional feedback and suggestions by using the smile or frown icons in the Send us feedback area at the top of the portal screen.

0  

Ten things you need to know about Pass-through Authentication

Azure Active Directory

For Azure AD, Microsoft offers and recommends to use Pass-through Authentication (PTA) as the authentication method. This method is then used to authenticate to applications, services and systems connected to Azure AD, like Office 365, Intune and Power BI.

However, there are a couple of things you should know:

 

Only outbound connections

When using Pass-through Authentication (PTA), the servers in your datacenter(s) will not have to be opened up from the Internet through firewalls. Each PTA Agent, sets up an outbound connection to the Azure Service Bus and don’t even need to be placed in a perimeter network.

However, based on ISO/IEC 17799, some organizations have seen reasons to implement standards that don’t allow systems to setup outbound connections to insecure networks, like the Internet, For these organizations, the way PTA works might be problematic.

While on the subject of legal compliance… ISO/IEC 17799 requires session time-outs as part of section 11.5.6. As the documentation states that PTA Agents make persistent outbound HTTPS connections, this control might also prove bothersome.

 

Minimum three PTA Agents

Of course, Pass-through Authentication (PTA) is the alternative to Active Directory Federation Services (AD FS).

That’s great, because any serious AD FS deployment would require five servers in the datacenter; 2 AD FS Servers, 2 Web Application Proxies en an Azure AD Connect installation. Ideally, the AD FS Servers are placed in different datacenters with an accompanying Web Application Proxy. This may be scoped down by placing AD FS on Domain Controllers, only requiring three new boxes.

Microsoft recommends a minimum of three PTA Agents in your environment. The Azure AD Connect installation that is used to configure PTA, by default, becomes the first PTA Agent. That’s 3 servers for AD FS vs. 3 servers for AD FS? Well, PTA Agents can also be placed on Domain Controllers, so it’s 1 server vs. 3 servers, actually.

There is such a thing as oversizing your PTA deployment too. As authentication requests are placed on the Azure Service Bus with encryption destined for each PTA Agent, having more PTA Agents equals more encryption overhead and a busy service bus…

 

Authentication may be highly available… synchronization not so much

When an organization deploys multiple PTA Agents, authentication requests are distributed amongst the PTA Agents. Each PTA Agent is capable of authenticating users independently of the other PTA Agent, as long as it has a connection to a functioning Domain Controller and to the Azure Service Bus.

However, Azure AD Connect still is a single point of failure to the solution. When Azure AD Connect doesn’t function (properly):

  • objects are not synchronized
  • attributes are not synchronized
  • the Authentication Method cannot be changed to PTA or Password Hash Sync (PHS) or to include Seamless Single Sign-on (S3O)
    (but it can be changed to AD FS through Windows PowerShell)

This may result in authentication and authorization failures.

 

Azure AD Premium licenses are required for Azure AD Smart Lock-out

Active Directory Federation Services (AD FS) offers Extranet Lock-out. In recent versions of Windows Server, it even offers Extranet Smart Lock-out. However, Pass-through Authentication (PTA) doesn’t offer lock-outs natively. Yes, Microsoft’s Machine Learning (ML) might detect malicious authentication attempts and block them, but by that time accounts in Active Directory Domain Services may already be locked-out, when organizations use strict settings in (fine-grained) password and account lock-out policies.

When the Azure AD Smart Lock-out feature is to be used with non-default settings, each account that is used with Pass-through Authentication requires an Azure AD Premium license. These licenses may be acquired separately, or as part of the EMS E3 license or Microsoft 365 E3 license.

 

There is no Azure AD Connect Health for PTA Agents

When contemplating Azure AD Premium, Azure AD Connect Health might also be of interest. Azure AD Connect Health offers integrated monitoring of Microsoft’s Hybrid Identity stack. We install the Azure AD Connect Health agents for monitoring on the following systems:

  • Azure AD Connect installations;
  • AD FS Servers;
  • Web Application Proxies, and;
  • Domain Controllers.

Alas, PTA Agents cannot be monitored with Azure AD Connect Health. This means notifications are not sent when PTA Agents are in trouble and root cause analyses are manual and require access to logs and local tools on the Windows Server installations running PTA Agents.

However, the PTA Agents are visible in the Azure AD Portal with their external IP addresses:

  1. Sign into the Azure Portal with an account that has the Global Admin role.
    Perform multi-factor authentication and Privileged Identity Management (PIM), when required.
  2. In the Azure Portal, select Azure Active Directory in the left navigation pane.
  3. Select Azure AD Connect in Azure AD’s navigation pane.
  4. On the Azure AD Connect pane, click the text Pass-through Authentication.
  5. Review the PTA Agents and their external IP addresses in the Pass-through Authentication pane.

 

Monitoring the connections to Domain Controllers

When checking PTA Agents in the Azure Portal, you might think that authentication to Azure AD is working flawlessly for your organization, when you see nothing but green check marks.

However, these checkmarks merely indicate that a PTA Agent is authenticated and connected to the Azure Service Bus. It does not mean that it is actually capable of authenticating users. When its connection to a Domain Controller is lost, for some reason, the check mark is there in the Azure Portal, but authentications won’t be possible.

The solution might be to implement Azure AD Connect Health for Active Directory Domain Services (AD DS) and monitor the Domain Controllers that way. Please note that this requires 25 Azure AD Premium licenses in the tenant per Domain Controller, on top of the single license needed for Azure AD Connect Health for the Azure AD Connect installation itself.

 

No certificate-based authentication

Pass-through Authentication (PTA) offers many features. Combined with Seamless Single Sign-on (S3O), it allows for authenticating end-users towards Azure AD-integrated resources.

However, several features that organizations might need are not offered with PTA and S3O. The most glaring feature that is missing has to be certificate-based authentication. If an organization requires certificate-based authentication, AD FS should be on their to-do list.

 

Forget about self-managed third-party MFA

Many organizations have already deployed multi-factor authentication (MFA) solutions on-premises in the past few years. The previously mentioned ISO/IEC 17799 standard plays a role in that for some organizations. These investments may become technical debt when Pass-through Authentication (PTA) is deployed. End-users require the organization-managed MFA solution to access on-premises resources, but require one of the four Azure AD-managed  MFA solutions (Azure MFA, Trusona, DUO and/or RSA) to access cloud resources. From their point of view, this means that when their mobile number and/or their mobile device changes, they have to change settings and/or register twice. With kids these days switching phones and numbers each year, this becomes a force to recognize.

 

Roll-over the password for AzureADSSOAcc

We rarely see a Pass-through Authentication (PTA) implementation without Seamless Single Sign-On (S3O) enabled as an authentication method, too. When you enable S3O, an computer account is created: AzureADSSOAcc. It is created in the Computers container, by default.

It is important to frequently roll over the Kerberos decryption key of this computer account (which represents Azure AD) created in your on-premises AD forest. Azure AD Connect does not notify of this caveat. And to do so, is complicated and cannot be automated without adding credentials of an account with the Global Admin role, configured without MFA, to the script.

 

Don’t disable TLS 1.0 (yet)

Since version 1.2.65 of Azure AD Connect (October 25th, 2018), it supports all other protocols being disabled and only TLS 1.2 being enabled on the machine where Azure AD Connect is installed.

However, when PTA is used as the authentication method and the PTA Agent is installed on the same Windows Server installation as Azure AD Connect, by default, the PTA Agent will not be able to communicate with Azure, when TLS 1.0 is disabled.

It appears the PTA Agent still requires TLS 1.0, for now.

2