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 May2019:

What’s Planned

Future support for only TLS 1.2 protocols on the Azure AD Application Proxy service

Service category: App Proxy
Product capability: Access Control

To help provide best-in-class encryption for our customers, Microsoft is limiting access to only TLS 1.2 protocols on the Azure AD Application Proxy service. This change is gradually being rolled out, first to customers who are already only using TLS 1.2 protocols.

Deprecation of TLS 1.0 and TLS 1.1 happens on August 31, 2019. Microsoft will provide additional advanced notice, so you’ll have time to prepare for this change. To prepare for this change make sure your client-server and browser-server combinations, including any clients your users use to access apps published through Application Proxy, are updated to use the TLS 1.2 protocol to maintain the connection to the Application Proxy service.

What’s New

Identity secure score is now available in Azure AD
General availability

Product capability: Identity Security & Protection

You can now monitor and improve your identity security posture by using the identity secure score feature in Azure AD. The identity secure score feature uses a single dashboard to help you:

• Objectively measure your identity security posture
• Plan for your identity security improvements
• Review the success of your security improvements

New App registrations experience is now available
General availability

Service category: Authentications (Logins)
Product capability: Developer Experience

The new App registrations experience is now in general availability. This new experience includes all the key features admins are familiar with from the Azure portal and the Application Registration portal and improves upon them through:

• Better app management. Instead of seeing their apps across different portals, admins can now see all their apps in one location.
• Simplified app registration. From the improved navigation experience to the revamped permission selection experience, it’s now easier for admins to register and manage apps.
• More detailed information. Admins can find more details about their app, including quickstart guides and more.

Conditional access for the combined registration process Public preview

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

Admins can now create Conditional Access policies for use by the combined SSPR/MFA registration page. This includes applying policies to allow registration if:

• Users are on a trusted network.
• Users are a low sign-in risk.
• Users are on a managed device.
• Users agree to the organization’s terms of use (TOU).

Use the usage and insights report to view your app-related sign-in data

Service category: Enterprise Apps
Product capability: Monitoring and Reporting

Admins can now use the usage and insights report, located in the Enterprise applications area of the Azure portal, to get an application-centric view of the sign-in data, including info about:

• Top used apps for your organization
• Apps with the most failed sign-ins
• Top sign-in errors for each app

Automate your user provisioning to cloud apps using Azure AD

Service category: Enterprise Apps
Product capability: Monitoring and Reporting

Follow these new tutorials to use the Azure AD Provisioning Service to automate the creation, deletion, and updating of user accounts for the following cloud-based apps:

• Comeet
• DynamicSignal
• KeeperSecurity

You can also follow this new Dropbox tutorial, which provides info about how to provision group objects.

New capabilities available in the Risky Users API for Identity Protection

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

Microsoft is pleased to announce that admins can now use the Risky Users API to retrieve users’ risk history, dismiss risky users, and to confirm users as compromised. This change helps admins to more efficiently update the risk status of their users and understand their risk history.

New Federated Apps available in Azure AD app gallery – May 2019

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

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

1. Freedcamp
2. Real Links
3. Kianda
4. Simple Sign
5. Braze
6. Displayr
7. Templafy
8. Marketo Sales Engage
9. ACLP
10. OutSystems
11. Meta4 Global HR
12. Quantum Workplace
13. Cobalt
14. webMethods API Cloud
15. RedFlag
16. Whatfix
17. Control
18. JOBHUB
19. NEOGOV
20. Foodee
21. MyVR

Improved groups creation and management experiences in the Azure AD portal

Service category: Group Management
Product capability: Collaboration

Microsoft has made improvements to the groups-related experiences in the Azure AD portal. These improvements allow admins to better manage groups lists, members lists, and to provide additional creation options. Improvements include:

• Basic filtering by membership type and group type.
• Addition of new columns, such as Source and Email address.
• Ability to multi-select groups, members, and owner lists for easy deletion.
• Ability to choose an email address and add owners during group creation.

What’s Changed

Configure a naming policy for Office 365 groups in Azure AD portal General availability

Service category: Group Management
Product capability: Collaboration

Admins can now configure a naming policy for Office 365 groups, using the Azure AD portal. This change helps to enforce consistent naming conventions for Office 365 groups created or edited by users in your organization.

Microsoft Graph API endpoints are now available for Azure AD activity logs General availability

Service category: Reporting
Product capability: Monitoring & Reporting

Microsoft is happy to announce general availability of Microsoft Graph API endpoints support for Azure AD activity logs. With this release, admins can now use Version 1.0 of both the Azure AD audit logs, as well as the sign-in logs APIs.

The post What’s New in Azure Active Directory for May 2019 appeared first on The things that are better left unspoken.

Last week, I delivered a 60-minute session, together with Raymond Comvalius at Experts Live Netherlands at Congress Center 1931 in Den Bosch, the Netherlands.

I left home early to arrive at 7:15 at the venue. This left me with ample time to find a (charging) parking spot, get to the speaker room and change to the Experts Live Polo shirt, and still catch the 7:45 pre-keynote session; I attended Orin Thomas’s session on Securing Azure Networks. Then, onward to the keynote.

After the keynote, it was time for Raymond and me to start working on the slides. I sat down in the speaker area, where my book drew quite some attention.

At 11:30AM, it was showtime for Raymond and me: We were allowed to talk for 60 minutes to a room full of attendees on Active Directory, AD FS, Certification Authorities and Windows to express how Windows Hello for Business could be used on-premises to start the password-less journeys.

After the session we spoke with a couple of attendees and then headed off to lunch.

I attended some more sessions that caught my interest and stood in the crowd during the epic raffle with my colleagues Barbara Forbes and Michiel Dekker. Toni Petrina took a picture of use, before we headed off for a nice dinner just outside of Den Bosch.

Thank you!

Thank you to the ExpertsLive organization for organizing yet another successful event and inviting me as a speaker once again, and to all the people attending, sitting in on our session and, of course, the people with whom I had interesting discussions.

The post Pictures of Experts Live Netherlands 2019 appeared first on The things that are better left unspoken.

Last week, Microsoft announced that Azure MFA Server will no longer be available for new deployments per July 1, 2019.

New customers who would like to require multi-factor authentication from their users should use cloud-based Azure Multi-Factor Authentication. Existing customers who have activated Azure MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual.

I’m expecting organizations to make the move from Azure MFA Server to the Azure MFA service, leveraging one or more of the following options:

1. Integrating applications, systems and services with Azure AD and leveraging Conditional Access to trigger Azure MFA
2. Using the built-in AD FS Adapter in Hybrid Identity implementations, that is available for use in Active Directory Federation Services since the Windows Server 2016 Farm Behavioral Level (FBL) 
3. The Azure MFA NPS Extension to secure RADIUS-based access solutions, and/or switching Citrix NetScaler-based configuration over to the claims-based access model.

After organizations have successfully migrated over from Azure MFA Server to the Azure MFA service, their next task is to decommission the Azure MFA Server infrastructure.

In this blogpost, I’ll cover how to remove an Azure MFA Server Complete Deployment, as mentioned in the supported Azure MFA Server Deployment Scenarios and their pros and cons. Some steps may not be applicable to every Azure MFA Server deployment scenario.

Uninstalling and removing Azure MFA Server consists of these high-level steps:

• Disable and remove Azure MFA Server as MFA provider in AD FS
• Uninstall the Azure MFA Server Mobile Web Service
• Uninstall the Azure MFA Server User Portal
• Uninstall the Azure MFA Server Web Service SDK
• Remove Server reference from Azure AD
• Uninstall the central Azure MFA Server component
• Remove IIS
• Remove TLS Certificate
• Remove service accounts and groups from Active Directory
• Remove DNS records from DNS
• Remove the server from the domain
• Remove the server from the network

Let’s walk through these steps:

Disable and remove Azure MFA Server as MFA provider in AD FS

The Azure MFA Server adapter in AD FS might be configured to allow multi-factor authentication in relying party trusts (RPTs). The first thing we need to do is remove Azure MFA Server’s MFA Adapter as an MFA method.

Execute the following three lines of Windows PowerShell in an elevated Windows PowerShell window on the primary AD FS Server to unselect Azure MFA Server’s AD FS Adapter in AD FS’ global multi-factor authentication policy:

AD FS farms leveraging the Windows Internal Database (WID) feature one AD FS server that operates as the Primary AD FS server. It is the only server with read/write access to the AD FS Configuration database. In an AD FS farm, where SQL Server is used, all AD FS server have read/write access to the database and the below lines of Windows PowerShell can be executed on any of the AD FS servers in the AD FS farm.

$C = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider

$C.Remove(“AzureMfaServerAuthentication“)

Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $C

Next, run the following lines of Windows PowerShell on all AD FS Servers in an elevated Windows PowerShell window, to remove Azure MFA Server’s AD FS adapter from these systems, followed by a restart of the AD FS service:

Unregister-ADFSAuthenticationProvider -Name AzureMFAServerAuthentication

Restart-Service -Name adfssrv

AD FS no longer knows about the Azure MFA Server Adapter and the Azure MFA Server. Now we can uninstall the components from the environment.

Use the following sequence (outside in):

• Uninstall the Mobile Web Service
• Uninstall the User Portal
• Uninstall the Web Service SDK
• Uninstall Azure MFA Server

Uninstall Azure MFA Server’s Mobile Web Service

Azure MFA Server 7.x’s Mobile Web Service offers the ability to people in the organization to register the Microsoft Authenticator app with the Azure MFA Server implementation.

Typically, you wouldn’t find Azure MFA Server’s Mobile Web Service in Azure MFA Server 8.x deployments, as the Mobile Web Service reference in Azure MFA Server’s User Portal was replaced with an iFrame that redirects to an Azure-based page. In this latter case, skip this paragraph.

To uninstall Azure MFA Server’s Mobile Web Service, perform these steps:

1. Sign in to the web server that hosts the Mobile Web Service.
2. Open the Internet Information Services (IIS) Manager (InetMgr.exe).
3. In the left navigation pane, navigate to Sites. Expand it.
4. Select the website or subfolder that corresponds to Azure MFA Server’s Mobile Web Service.
5. When Azure MFA Server’s Mobile Web Service is installed as a separate site, right-click the site, click on Manage Website and then select Stop.
6. In the action pane, click Basic Settings….
7. Note the information in the Physical Path: field.
8. Click OK to close the Edit Site pop-up.
9. When Azure MFA Server’s Mobile Web Service is installed as a separate site, in the main window of Internet Information Services (IIS) Manager, double-click Logging. Note the information in the Directory: field.
10. When Azure MFA Server’s Mobile Web Service is installed as a separate site, in the left navigation menu, right-click the site again and select Remove from the context-menu.
                       
    
                             
    Else, right-click the folder, and select Remove. Click Yes to confirm.
11. In the Confirm Remove pop-up window, click Yes.
12. In the left navigation menu, navigate to Application Pools. Expand it.
13. Right-click the application pool corresponding to Azure MFA Server’s Mobile Web Service and select Stop from the menu.
14. Right-click it again, and select Remove from the menu.
15. Click Yes to confirm.
16. Close Internet Information Services (IIS) Manager.
17. Open File Manager (explorer.exe)
18. Navigate to the folder that resembles the folder that was mentioned in the Physical Path: field of Azure MFA Server’s Mobile Web Service.
19. Remove the folder.
20. When Azure MFA Server’s Mobile Web Service ran as a separate website, navigate to the folder that resembles the folder that was mentioned in the Directory: field of Azure MFA Server’s Mobile Web Service’s logging properties and remove this folder, too.
21. Close File Explorer.

Uninstall Azure MFA Server’s Mobile Web Service from any Windows Server that offers it.

Uninstall Azure MFA Server’s User Portal

Use the following steps to uninstall Azure MFA Server’s User Portal in the same way as you have uninstalled Azure MFA Server’s Mobile Web Service from any Windows Server that offers it:

1. Sign in to the web server that hosts the User Portal.
2. Open the Internet Information Services (IIS) Manager (InetMgr.exe).
3. In the left navigation pane, navigate to Sites. Expand
   it.
4. Select the website or subfolder that corresponds to Azure MFA Server’s User Portal.
5. When Azure MFA Server’s User Portal is installed as a separate site,
   right-click the site, click on Manage Website and then
   select Stop.
6. In the action pane, click Basic Settings….
7. Note the information in the Physical Path:
   field.
8. Click OK to close the Edit Site
   pop-up.
9. When Azure Server’s User Portal is installed as a separate
   site, in the main window of Internet Information Services (IIS)
   Manager, double-click Logging. Note the information in
   the Directory: field.
10. When Azure MFA Server’s User Portal is installed as a separate site, in the
    left navigation menu, right-click the site again and select Remove
    from the
    context-menu.
11. Else, right-click the folder, and select Remove.
    Click Yes to confirm.
12. In the Confirm Remove pop-up window, click
    Yes.
13. In the left navigation menu, navigate to Application Pools.
    Expand it.
14. Right-click the application pool corresponding to Azure MFA Server’s User Portal and select Stop from the menu.
    
                                
    
                                  
15. Right-click it again, and select Remove from the menu.
16. Click Yes to confirm.
17. Close Internet Information Services (IIS) Manager.
18. Open File Manager (explorer.exe)
19. Navigate to the folder that resembles the folder that was mentioned in the
    Physical Path: field of Azure MFA Server’s User Portal.
20. Remove the folder.
21. When Azure MFA Server’s User Portal ran as a separate website, navigate to
    the folder that resembles the folder that was mentioned in
    the Directory: field of Azure MFA Server’s User Portal’s logging properties and remove this folder,
    too.
22. Close File Explorer.

Uninstall Azure MFA Server’s Web Service SDK

Azure MFA Server’s Mobile Web Service and Azure MFA Server’s User Portal communicate to the central Azure MFA Server component using its Web Service SDK.

Azure MFA Server deployment scenarios, where the Mobile Web Service and User Portal are not used, or are deployed on the same server that runs the Azure MFA Server’s central component, do not use the Web Service SDK. In these scenarios, this paragraph can be skipped.

To uninstall the Web Service SDK, perform these steps:

1. Press Win and X simultaneously, right-click the Start button and select Programs and Features from the top of the menu, or search for Programs and Features.
                         
   
                                
2. Select Multi-Factor Authentication Web Service SDK from the list of installed programs.
3. In the action bar on top of the list of installed programs, click Uninstall.
4. Click Yes to answer the pop-up question Are you sure you want to uninstall Multi-Factor Authentication Web Service SDK?
5. After several short progress bars filling, Azure MFA Server’s Web Service SDK will be removed.
6. Close Programs and Features.
7. Open the Internet Information Services (IIS) Manager (InetMgr.exe).
8. In the left navigation pane, navigate to Sites. Expand
   it.
9. Select the website or subfolder that corresponds to Azure MFA Server’s Web Service SDK.
10. When Azure MFA Server’s Web Service SDK is installed as a separate site, right-click
    the site, click on Manage Website and then select
    Stop.
11. In the action pane, click Basic Settings….
12. Note the information in the Physical Path:
    field.
13. Click OK to close the Edit Site
    pop-up.
14. When Azure MFA Server’s Web Service SDK is installed as a separate site, in the
    main window of Internet Information Services (IIS) Manager,
    double-click Logging. Note the information in the
    Directory: field.
15. When Azure MFA Server’s Web Service SDK is installed as a separate site, in the left
    navigation menu, right-click the site again and select Remove
    from the context-menu.
    Else, right-click the folder, and select Remove.
    Click Yes to confirm.
16. In the Confirm Remove pop-up window, click
    Yes.
17. In the left navigation menu, navigate to Application Pools.
    Expand it.
18. Right-click the application pool corresponding to Azure MFA Server’s Web Service SDK and select Stop from the menu.
19. Right-click it again, and select Remove from the menu.
20. Click Yes to confirm.
21. Close Internet Information Services (IIS) Manager.
22. Open File Manager (explorer.exe)
23. Navigate to the folder that resembles the folder that was mentioned in the
    Physical Path: field of Azure MFA Server’s Web Service SDK.
24. Remove the folder.
25. When Azure MFA Server’s Web Service SDK ran as a separate website, navigate to
    the folder that resembles the folder that was mentioned in
    the Directory: field of Azure MFA Server’s Web Service SDK’s logging properties and remove this folder,
    too.
26. Close File Explorer.

Remove Server references from Azure AD

To clean up the Azure AD tenant, delete the MFA Provider from Azure AD, since it’s no longer needed, even when you use Azure MFA with the NPS Extension for Azure MFA or Azure MFA with AD FS in Windows Server 2016 or Windows Server 2019. This paragraph also provides the ability to determine the primary server when there are multiple MFA Servers in the MFA Server group.

The steps in this paragraph depend on the way the Azure MFA Server implementation is licensed.

Perform these steps:

1. Open a web browser and navigate to the Azure Portal.
2. Sign in with an account that has the Global administrator role assigned.
   Perform Azure-based multi-factor authentication, when prompted.
3. In the left navigation menu, click Azure Active Directory.
4. In the Azure AD navigation menu, scroll down to the Security section.
5. Click MFA.

MFA Provider scenario

When the implementation uses an MFA Provider, perform these steps:

1. In the Multi-Factor Authentication navigation menu, click Providers.
2. Select a provider in the list of MFA providers to open its settings.
3. In the navigation menu for the MFA Provider, click Server Status.
4. In the list of Azure MFA Servers, take note of the Azure MFA Server installation that has the value Yes in the Master column.
5. Click on the … to the left of each of the Azure MFA Servers, and select Delete from the menu.
6. In the Delete Entry pop-up, click OK to acknowledge that the selected entry will be removed from the report.
                  
   Repeat steps 5 and 6 for each Azure MFA Server in the list.
                       
7. Delete the MFA Provider.

Hybrid Identity Scenario

When the implementation is licensed through Azure AD Premium license or another license that includes that license, perform these steps:

1. In the Multi-Factor Authentication navigation menu, click Server Status.
2. In the list of Azure MFA Servers, take note of the MFA Server installation that has the value Yes in the Master column.
3. Click on the … to the left of each of the Azure MFA Servers, and select Delete from the menu.
4. In the Delete Entry pop-up, click OK to acknowledge that the selected entry will be removed from the report.

Repeat steps 3 and 4 for each Azure MFA Server in the list.

Uninstall the central Azure MFA Server component    

The central Azure MFA Server component offers the Management User Interface, Directory Synchronization and other Azure MFA Server services that may be in use.

When multiple Azure MFA Servers are part of the implementation, uninstall the central Azure MFA Server component on the Master server last. This is the only Azure MFA Server that has read/write access to the phonefactor.pfdata file.

Perform the  To uninstall the central MFA Server components, perform these steps:

1. Press Win and X simultaneously, right-click the Start button and select Programs and Features from the top of the menu, or search for Programs and Features.
2. Select Multi-Factor Authentication Server from the list of installed programs.
3. In the action bar on top of the list of installed programs, click Uninstall.
4. Click Yes to answer the pop-up question Are you sure you want to uninstall Multi-Factor Authentication Server?
5. After several short progress bars filling, Azure MFA Server will be removed.
6. Close Programs and Features.
7. Open File Manager (explorer.exe)
8. Navigate to the C:\Program Files\Multi-Factor Authentication Server folder
   (or the installation location for Azure MFA Server, if you’ve changed it from the default during installation)
9. Delete the folder, including the Data and Logs subfolder and the files therein.
10. Close File Manager.
11. Restart the server.

Remove IIS

Skip this paragraph on Windows Servers that remain functioning as webservers, as the above steps will remove the Internet Information Services (IIS) role that hosts other IIS-based applications.

With all Azure MFA Server components removed, the servers in scope of the Azure MFA Server deployment no longer require Internet Information Services (IIS). Remove IIS from the server using the Remove roles and services wizard from Server Manager, or use the following line of Windows PowerShell in an elevated PowerShell window:

Uninstall-WindowsFeature -Name Web-Server,Web-Common-Http,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Static-Content,Web-Health,Web-Http-Logging,Web-Performance,Web-Stat-Compression,Web-Security,Web-Filtering,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Metabase

Afterward, restart the server. For instance, using the following line of Windows PowerShell:

Restart-Server        

If there are any load-balancer rules directing traffic to Azure MFA Server’s former Mobile Web Service, User Portal or Web Service SDK, remove these, too.

Remove TLS Certificates

The local computer still has a TLS certificate stored in its certificate store. Remove the certificate for the Windows Servers in scope for the Azure MFA Server implementation from their local computer certificate stores.

Skip this paragraph if any of the Windows Servers in scope of the Azure MFA Server implementation remains a webserver, hosting websites over https using the same TLS certificate. However, when the time comes to renew the certificate, opt to remove any Azure MFA Server-specific DNS entries in the certificate request.

Perform these steps:

1. Open the Certificates MMC Snap-in for the local computer (certlm.msc)
2. In the left navigation pane, expand Personal, then Certificates.
3. In the main pane, select the TLS certificate that was used for Azure MFA Server’s Mobile Web Service, Azure MFA Server’s User Portal and/or Azure MFA Server’s Web Service SDK.
4. Right-click the certificate and select Delete from the menu.
                      
   
                           
5. Click Yes.
6. Close the Certificates MMC Snap-in.

If you have connected MFA Server’s Mobile Web SDK and User Portal to Azure MFA Server’s Web Service SDK using certificate authentication, remove these certificates, too.

Remove service accounts and groups from Active Directory

For typical Azure MFA Server deployments, there are two service accounts and one group in Active Directory Domain Services:

• The PhoneFactor Admins group in the Users container
• The service account for the Azure MFA Server itself
• The service account for the portals to connect to the Web Service SDK

Remove them all.

Remove the servers from the domain

Skip this paragraph for any Windows Server in scope of the Azure MFA Server implementation that remains on the network to service end-users.

Configure the Azure MFA Server as a member of the WORKGROUP workgroup, instead of the domain it’s a member of.

Restart the server, afterwards.

After a successful restart, remove the computer object from Active Directory Domain Services.

Remove DNS records from DNS

Skip this paragraph for any Windows Server in scope of the Azure MFA Server implementation that remains on the network to service end-users.

Many Azure MFA Servers are known in the internal network and the Internet with other names, than their hostnames.

Remove the A, AAAA and CNAME records, pointing to the host in the DNS zone for the internal network. Remove the A, AAAA and CNAME records, pointing to the host in the public DNS zone for the Internet.

Remove the servers from the network

Skip this paragraph for any Windows Server in scope of the Azure MFA Server implementation that remains on the network to service end-users.

Shut down the server. Remove the server from the virtualization platform, or disconnect the physical server and remove it from the server room.

This is also the perfect moment to remove any custom firewall rules you might have had in place to allow communications between the Mobile Web Service and/or User Portal and the Web Service SDK, and replication between MFA Servers.

Make sure the hosts from the Azure MFA Server implementation are correctly removed from monitoring, backup and other information security services, as well as the service catalog.

Concluding

The above paragraphs provide steps to clean Azure MFA Server implementations off a network. Following these steps, no remnants remain of this legacy product.               

Related blogposts

Supported Azure MFA Server Deployment Scenarios and their pros and cons 
HOWTO: Install Azure Multi-Factor Authentication (MFA) Server 8.0.1.1 
Things to know about Billing for Azure MFA and Azure MFA Server 
Ten Things you need to know about Azure Multi-Factor Authentication Server 

Further reading

Configure Azure MFA as authentication provider with AD FS   
Integrate your existing NPS infrastructure with Azure Multi-Factor Authentication  
Azure: How to unregister and register MFA Server 6.x ADFS Authentication Provider 

The post HOWTO: Uninstall and Remove Azure MFA Server versions 7.x and 8.x Implementations appeared first on The things that are better left unspoken.

As a published technical writer, I’ve had my share of experiences working with a publisher and its editors for a period of seven months. For my own sanity, I’ll post some of my experiences in this series of blogposts on Experiences with Being Published. I feel these stories can be quite entertaining, and I might even get a smile on my face when I look back at these stores in a couple of years’ time…

I thought writing a book would be a lot of fun because I am quite creative. That turned out to be quite an assumption…

About Cookbooks

A Technology cookbook, as it turns out, is a very specific book. Just like any ‘normal’ cookbook, it contains recipes. The term cookbook is used metaphorically to refer to any book containing a straightforward set of already tried and tested recipes or instructions for a specific field or activity, presented in detail so that the reader, who is not necessarily an expert in the field, can produce workable results.

As it turns out, my publisher is very specific about what a cookbook should look like on the inside.

The rules

Before starting writing my first chapter, I received a sample chapter with some comments on how to do things. After receiving my first feedback, though, I realized the list of rules for chapters and recipes is quite long. I particularly struggled with the following rules:

1. Every chapter starts with a short introduction followed by a list of all the recipes in the chapter.
2. Every recipe has the same headings in the same order; Getting Ready, How it’s done, and How it works. None of these headings may be omitted. Their order must not be changed. Additional headings may be added after these headings: There’s more and See also. In that order.
   For recipes that aren’t that technical, this is a burden Three recipes in particular (Chapter 1’s “Creating the right trust”, Chapter 11’s “Choosing the right AD FS Farm deployment method” and Chapter 12’s “Choosing the right Hybrid Identity authentication method”) proved opportunities for debate with the content team.
   Eventually, the headings grew on me, when I realized I could interpret them the way I wanted to. I mean; Getting a coffee is a good way to get ready, too…
3. Between every heading and a subheading, there needs to be text. This is when you add standard non-creative sentences in a book, like “Use this recipe to <title heading here> “, “This is how to <title heading here>”.
4. You can’t have multiple Warning, Information or Tip blocks without having paragraphs between them. Guess how many of these blocks I removed, just to comply with the rules that were punt in place to uphold the quality of the book…
5. When using steps in a graphical user interface in a recipe, at least one screenshot needs to be added between the steps in the recipe.
6. Screenshots require a lead-in.
7. Screenshots are always centered and the publisher adds a border.
   For three flowcharts in the book, I debated for weeks to not get this rule applied. Eventually they agreed, but only after I sent the PowerPoint version of the flowcharts by mail, so that they could create sufficiently high-resolution images to the book to circumvent jarring of edges.
8. You can’t quote the Microsoft KnowledgeBase or link to it, because there is no permission to do so, apparently.
9. The See also section of a recipe is to be used to point to other recipes in the book. However, the links in the PDF of the book, as a rule, only point to the start of the chapter. This makes for a lot of unnecessary scrolling for people wanting to use this functionality. I guess it’s why one of the other rules is “Chapters may not exceed 50 pages”.
10. You can add links in the See also sections of a recipe, but the links will not be shortened. Apparently, if a reader wants to use the link, it will have to be typed manually into the browser…

The sample chapter

In the end, the sample chapter proved a disaster. The introduction for the chapter came after the list of recipes. Its comments around screenshots didn’t mention any lead-ins, but instead suggested captions below the screenshot. The editing team ‘created’ lead-ins, which I subsequently had to change, because they consistently referred to the wrong action.

To add to insult, the sample chapter was shared in Microsoft Word format.

Concluding

Interestingly, when I show people the cookbook, their reaction is that its style is really ‘Microsofty’, meaning that people experience the style of the book as the style of Microsoft Official Curricula.

I feel it’s positive feedback. I guess I’m ready to contribute to these now, too. I’ve been a Microsoft Certified Trainer (MCT) for the last five years, so why not.

Picture by Sandwich, used under CC BY-NC-ND 2.0 license. Adjusted in size.

Learn the intricacies of managing Azure AD, Azure AD Connect as well as Active Directory for Identity and Access Management (IAM) in the cloud and on Windows Server 2019.

Get up to date! Get your 620-page, 147-recipe copy of the Active Directory Administration Cookbook, today. Buy it from Packt directly, or through your favorite local reseller.

The post Experiences with Being Published, Part 4: Rules of Engagement appeared first on The things that are better left unspoken.

This weekend marks 13 years of me sharing my thoughts, knowledge and experiences on this blog, titled The Things That Are Better Left Unspoken. Thirteen years ago, in June, 2006, I posted the first blog post here.

That’s as many years as there are stripes in the US flag.

Today, almost 1000 posts, several whitepapers and the Active Directory Administration Cookbook later, I’m still enjoying blogging, sharing and informing you on Microsoft products, technologies, features and news.

To me, it’s not something that is tied to an employer, residence, a specific time of day, recognitions from Microsoft, Veeam or VMware… That’s why I’m sure I can share that I’ll continue blogging, sharing and informing you.

Enjoy!

Related blogposts

Ten Years of Blogging 
Nine Years of blogging, sharing and informing 
Eight years of blogging

The post 13 Years Better Left Unspoken appeared first on The things that are better left unspoken.

On Thursday June 20, 2019, the Active Directory Administration Cookbook was officially launched in the Netherlands at the SCCT office in Leidschendam.

I had invited my family, my closest friends, the people with whom I have worked together in recent years at several Identity-related projects and everyone else who would be interested in attending.

At 5:30 PM, Harro Borghardt kicked off the launch with a short introduction. Then, I gave a short talk about my experiences creating the book and thanking people present.

Then, I signed the first book for my parents. Their support, patience and listening, combined with the support from my wife and daughter helped me through the inevitable rough patches in such a journey.

By popular demand, I signed books for everyone present.

Then, we all called it a night and went home.

Do you want your copy of the Active Directory Administration Cookbook signed, like this guy? Leave a comment below.

The post Pictures of the Dutch Active Directory Administration Cookbook Launch appeared first on The things that are better left unspoken.

It’s a recommended practice to disable weak ciphers and encryption algorithms. Some standards require this. As technology evolves, the list of available ciphers and their priority in encryption negotiations changes. This limits the risk of losing confidentiality on communications between systems, applications and (cloud) services.

While you’ve probably heard of disabling 3DES and all versions of SSL, one other recommendation rears its ugly head: disable RC4_HMAC_MD5.

About RC4_HMAC_MD5

RC4_HMAC_MD5 means it’s Ron Rivest’s stream Cipher 4 (RC4) with Hashed Message Authentication Code (HMAC) using the Message-Digest algorithm 5 (MD5) checksum function.

When Microsoft released Windows 2000 Server and Active Directory, Microsoft supported backward compatibility with Windows NT and Windows 95. This support entailed support for different clients and enable them to communicate using Kerberos. The easy way to do this was to use the NTLM password hash as the Kerberos RC4 encryption private key used to encrypt/sign Kerberos tickets. Because of this, RC4_HMAC_MD5 takes center stage in several Kerberos attacks, including Kerberoasting.

How to disable RC4_HMAC_MD5 in Active Directory

Follow these steps to disable RC4_HMAC_MD5 in Active Directory:

1. Sign in with an account that is a member of the Domain Admins group of the Active Directory domain for which you want to disable RC4_HMAC_MD5.
2. Open the Group Policy Management Console (gpmc.msc).
3. In the left navigation pane, browse to the Default Domain Controllers Group Policy object.
4. Right-click the object and select Edit… from the context menu.
5. Navigate to Computer Configuration, Policies, Windows Settings, Security Settings, Local Policies and then Security Options,.
6. Select the Network Security: Configure encryption types allowed for Kerberos group policy setting.
7. Double-click the setting to edit it.
8. Select the Define these policy settings option.
9. In the list of available encryption types, deselect RC4_HMAC_MD5.
10. Close the Group Policy setting.
11. Close the Group Policy Management Console.

Impact

There is a situation where the above security measure impacts functionality: When you disable RC4_HMAC_MD5, Azure AD Connect will no longer be able to offer Seamless Single Sign-On (S3O).

This is made clear in the Troubleshoot Azure Active Directory Seamless Single Sign-on page. If you want Azure AD Connect’s Seamless Single Sign-on functionality to work, RC4_HMAC_MD5 will need to be available.

Further actions

If you would like Microsoft to address this issue in Azure AD Connect, please vote or this change on the Azure Feedback website.

Further reading

SSL and TLS Deployment Best Practices
RC4 in TLS is Broken: Now What?
Prioritizing Schannel Cipher Suites
Cipher Suites in TLS/SSL (Schannel SSP)
245030 How to restrict the use of certain cryptographic algorithms and protocols
How Do I Remove Legacy Ciphers (SSL2, SSL3, DES, 3DES, MD5 and RC4) on NetScaler?
A Cipher Best Practice: Configure IIS for SSL/TLS Protocol
How to disable RC4 and 3DES on Windows Server?

The post Knowledgebase: Azure AD Connect’s Seamless SSO breaks when you disable RC4_HMAC_MD5 appeared first on The things that are better left unspoken.

As a published technical writer, I’ve had my share of experiences working with a publisher and its editors for a period of seven months. For my own sanity, I’ll post some of my experiences in this series of blogposts on Experiences with Being Published. I feel these stories can be quite entertaining, and I might even get a smile on my face when I look back at these stores in a couple of years’ time…

As I mentioned previously, the process allows for checks and balances. There are stakeholders; people with roles.

My process

I must admit, I had a rough start writing my book. I decided to write a book about Windows Server 2019 and deliver my first chapter on October 15th. I expected Microsoft to release Windows Server 2019 at its Ignite 2018 event, and I figured I could start running Windows Server 2019-based virtual machines in Microsoft Azure Infrastructure as a Service (IaaS) on October 1st, 2018.

I was wrong… Microsoft released Windows Server 2019, but due to quality issues, didn’t release Windows Server 2019 until a whole month later. There was no way to test my command lines and PowerShell scripts. I was basically writing in the dark.

Luckily I didn’t write about Hyper-V Server 2019, as this product was only released last week, after being delayed for over six months.

About the technical reviews

Luckily, I knew I could rely on the process.

My technical reviewer (TR) would trace all my steps and note any inconsistencies in the texts, steps and commands. Then, a technical person from my publisher would do the same thing and come up with any items the two of us might have missed.

Official confirmations

Two days before the last deadline, I received a message from my publisher:

I need to discuss about codes in the chapters.

 

Can you please give a confirmation that they are working fine… We know that the TR has made suggestions for the codes and you have implemented it, but we need some sort of official confirmation… Unfortunately, the TR did not seem to add this in the questionnaire.

 

We did not find anything erroneous as such at our end… Also, the TR also did not flag anything. it’s just that as a protocol, we have to check it with you as well. Do not worry… the quality of the book is not hampered.

I was wrong…

I decided to check the scripts. I had performed most actions in the Active Directory Administrative Center, and copied the PowerShell commands from there, most of the time.

This is when I found out, no-one checked the command lines and PowerShell scripts in the book.

My technical reviewer even suggested some edits for readability that actually broke the lines of PowerShell involved. My publisher couldn’t perform technical reviews, because of some missing technology capabilities on their end.

I went through all the commands and scripts and edited them at break-neck speed. There were 17 commands that needed corrections. Corrections a technical reviewer could have easily picked up on, but apparently didn’t.

But … the quality of the book is not hampered. No.

Picture by Louise McLaren, under CC BY 2.0 license. Adjusted in size.

Learn the intricacies of managing Azure AD, Azure AD Connect as well as Active Directory for Identity and Access Management (IAM) in the cloud and on Windows Server 2019.

Get up to date! Get your 620-page, 147-recipe copy of the Active Directory Administration Cookbook, today. Buy it from Packt directly, or through your favorite local reseller.

The post Experiences with Being Published, Part 5: Quality Assurance appeared first on The things that are better left unspoken.

On June 20, 2019, we officially launched the Packt Active Directory Administration Cookbook in the Netherlands. I signed a ton of books.

After that fun event I was approached by the Royal Dutch Association of Information and IT Professionals (KNVI). They were interested in the book as well. As the book applies to a fairly large number of their members, we agreed upon a second event: “Active Directory, What’s Cooking?”.

About KNVI

The Dutch Professional Association of Information and IT Professionals (KNVI) is an independent platform for sharing professional knowledge and expanding the personal networks of ICT Pros, information professionals, students and employers who want to keep their employees up to date.

KNVI organizes multiple meetings per month, publishes AG Connect both online and in print, and offers discounts to its members.

KNVI is a merged organization of several professional associations, including the Dutch Networking User Group (Ngi-NGN) and the Dutch Association for Documentary Information and Organization Administration (SOD).

About KNVI “Active Directory, What’s Cooking?”

On July 9, 2019, KNVI organizes the “Active Directory, What’s Cooking?” event for its members at the Hitland Golf Club in Nieuwerkerk aan den IJssel.

Starting at 6PM, we are going to enjoy a BBQ. Then, at 8 PM, Erwin Derksen and I will share our experiences with Active Directory and Azure AD.

Part of my experiences is in the Active Directory Administration Cookbook. I will tell a bit about how the book fits in my ambition and strategy for “Better Active Directory admins and environments without breaking the bank”.

Members of KNVI will be able to purchase the Packt Active Directory Administration Cookbook with 40% discount, spending only € 32 instead of the normal Dutch price of € 52 for the book.

Join KNVI and the event!

It’s not too late to join KNVI Dutch.
This is a prerequisite to being able to attend the KNVI “Active Directory, What’s Cooking?” event.

Subscriptions to KNVI for students are a mere EUR 30 per year. Subscriptions for individuals start at EUR 99,00 per year for members aged 27 and below, for retirees and for unemployed people. Other individual subscriptions set you back EUR 165 per year. Organizational subscriptions are available upon request.

I’m sure you can do the math how many books you need to buy to break even.

The post Join us for the KNVI "Active Directory, What’s Cooking?" Event appeared first on The things that are better left unspoken.

Today, I received a localized e-mail from the Microsoft Most Valuable Professional (MVP) Award team:

In Dutch, it reads:

Beste Sander Berkouwer,

Nogmaals presenteren we u met genoegen de 2019-2020 Microsoft Most Valuable Professional (MVP) Award als erkenning van uw buitengewone leiderschap in technische community’s. We waarderen uw uitmuntende bijdragen in de volgende technische community’s in het afgelopen jaar:

• Enterprise Mobility

Uw MVP Award-cadeaupakket is onderweg. U ontvangt binnen vijf werkdagen een verzendingsmelding. Om toegang te krijgen tot alle Award-voordelen, voltooit u de MVP-activeringsstappen hierna.

This roughly translates to the messages I have been receiving from 2009 till 2016 on January 1st of these years and from July 1st, 2017 onward; I’m still worthy of the MVP badge.

It’s an honor to be part of this wonderful group of people helping others and closing the feedback circle with Microsoft, especially for the situations in which people use Microsoft products in ways Microsoft has never imagined.

Thank you!

The post I’m a 2019-2020 Microsoft MVP appeared first on The things that are better left unspoken.

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

Let’s harden the Web Application Proxy installations, by disabling unnecessary services running on it. This way, we lower their attack surfaces even further.

Note:
This blogpost assumes you’re running Web Application Proxies as non-domain-joined Server Core Windows Server 2016 installations. If your Web Application Proxies are domain-joined, use Group Policy to disable unnecessary services instead of PowerShell.

Unnecessary services

Services that are of no use to Web Application Proxies can be disabled.

By default

The following Windows services are disabled, by default, on Server Core installations of Windows Server 2016:

• Computer Browser (browser)
• Net.Tcp Port Sharing Service (NetTcpPortSharing)
• Routing and Remote Access (RemoteAccess)
• Smart Card (SCardSvr)

These services do not require any further attention.

Additional services

The following Windows services are enabled and have Manual or Automatic startup types on Server Core installations of Windows Server 2016. These can be disabled:

• Internet Connection Sharing (ICS) (SharedAccess)
• Link-Layer Topology Discovery Mapper (lltdsvc)
• Print Spooler (Spooler)
• Printer Extensions and Notifications (PrintNotify)
• Smart Card Device Enumeration Service (ScDeviceEnum)
• Windows Insider Service (wisvc)

Harden services

Disable unnecessary services

To disable these services, run the following Windows PowerShell script, when logged on with an account that has local administrative privileges on the Web Application Proxy:

Set-Service SharedAccess –StartupType Disabled

Stop-Service SharedAccess

Set-Service lltdsvc –StartupType Disabled

Stop-Service lltdsvc 

Set-Service Spooler –StartupType Disabled

Stop-Service Spooler 

Set-Service PrintNotify –StartupType Disabled

Stop-Service PrintNotify 

Set-Service ScDeviceEnum –StartupType Disabled

Stop-Service ScDeviceEnum 

Set-Service wisvc –StartupType Disabled

Stop-Service wisvc

Re-enable services

To re-enable the above services to their previous state, run the following Windows PowerShell script, when logged on with an account that has local administrative privileges on the Web Application Proxy:

Set-Service SharedAccess –StartupType Manual

Set-Service lltdsvc –StartupType Manual

Set-Service Spooler –StartupType Automatic

Start-Service Spooler 

Set-Service PrintNotify –StartupType Manual

Set-Service ScDeviceEnum –StartupType Manual

Set-Service wisvc –StartupType Manual

Concluding

Disable unnecessary services on all Web Application Proxies throughout the Hybrid Identity implementation using the Windows PowerShell script above.

The post HOWTO: Disable Unnecessary Services on Web Application Proxies appeared first on The things that are better left unspoken.

As a published technical writer, I’ve had my share of experiences working with a publisher and its editors for a period of seven months. For my own sanity, I’ll post some of my experiences in this series of blogposts on Experiences with Being Published. I feel these stories can be quite entertaining, and I might even get a smile on my face when I look back at these stores in a couple of years’ time…

Today, let’s talk about how a diverse team, consisting of people from multiple cultures added value f*cked sh*t up.

The last mile is the longest one

Once I was done writing the chapters, all I learned I needed to do was to copy all the command lines and PowerShell scripts from the book into separate files on GitHub, write the hardware and software list (listing all the hardware and software used for all the recipes) and write the Preface.

This last item proved to be the hardest, even though I only needed to describe the purpose and scope of the book…

A matter of style…

One of the content editors has been bugging me throughout the process with her unneeded and frustrating edits. It started with ‘correcting’ the ActiveDirectory PowerShell module name in the Import-Module command, by adding a space and continues throughout the book with other corrections, where she would continue to edit “The … screen appears.” with “The … screen will appear.” like we were working with some really slow domain controllers, and ‘Click Next >’ with ‘Click on Next >’.

With the help of the technical editor, all these corrections were corrected back, except one.

The one that got away

As I was writing the Preface to the book, it was my job to describe the contents for each chapter. For chapter 3, I wrote:

Chapter 3, Managing Active Directory Roles and Features, covers FSMO roles and global catalog servers for addressing all your organization’s multi-forest and multi-domain needs.

Deliberately, I chose not to explain the FSMO acronym. I felt that when people wanted to know what it meant, they would look it up in the chapter anyway.

In the version of the book a week before publishing, the Preface was edited. The above piece of text now read:

Chapter 3, Managing Active Directory Roles and Features, covers Flexible Single Operations Master (FSMO) roles and global catalog servers for addressing all your organization’s multi-forest and multi-domain needs.

That’s right. The editor thought it was wise to introduce the acronym in the Preface. As a matter of style, all introductions for acronyms are noted as bold text.

In the final book, however, this particular sentence reads:

Chapter 3, Managing Active Directory Roles and Features, covers Flexible Single Operations Master (FSOM) roles and global catalog servers for addressing all your organization’s multi-forest and multi-domain needs.

That’s right. A completely new acronym is introduced for Active Directory, because someone didn’t pay attention to write it down perfectly, and then edited it some more to make it look really ridiculous. As it is the only acronym introduced on the page, and therefore the only bold text, it stands out like a sore thumb.

Just don’t

When you know nothing about Active Directory and its acronyms, please keep as far away as possible from editing a book on it. Just don’t.

Picture by Fellowship of the Rich, under CC BY-NC-ND 2.0 license. Edited in size

Learn the intricacies of managing Azure AD, Azure AD Connect as well as Active Directory for Identity and Access Management (IAM) in the cloud and on Windows Server 2019.

Get up to date! Get your 620-page, 147-recipe copy of the Active Directory Administration Cookbook, today. Buy it from Packt directly, or through your favorite local reseller.

The post Experiences with Being Published, Part 6: A Matter of Style appeared first on The things that are better left unspoken.

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

In this part of the series, we’ll harden the AD FS Server installations, by disabling unnecessary services running on it. This way, we lower their attack surfaces.

Note:
This blogpost assumes you’re running AD FS Servers as domain-joined Windows Server 2016 Server Core installations. However, as management of AD FS on Server Core installations is PowerShell-only, we also include information for AD FS Servers running Windows Server 2016with Desktop Experience (Full).

Unnecessary services

By default

The following Windows services are disabled, by default, on Server Core installations of Windows Server 2016:

• Computer Browser (browser)
• Net.Tcp Port Sharing Service (NetTcpPortSharing)
• Routing and Remote Access (RemoteAccess)
• Smart Card (SCardSvr)
• Auto Time Zone Update (tzautoupdate)
• Microsoft App-V Client (AppVClient)
• Offline files (cscService)
• User Experience Virtualization Service (UevAgentService)
• Windows Search (WSearch)

These services do not require any further attention.

Additional services

The following Windows services are enabled and have Manual or Automatic startup types on installations of Windows Server 2016 with the Desktop Experience (Full Installations). These can be disabled:

• ActiveX Installer (AxInstSV) (AxInstSV)
• Bluetooth Support Service (bthserv)
• CDPUserSvc (CDPUserSvc)
• Contact Data (PimIndexMaintenancesvc)
• dmwappushsvc (dmwappushsvc)
• Downloaded Maps Manager (MapsBroker)
• Geolocation Service (lfsvc)
• Internet Connection Sharing (ICS) (SharedAccess)
• Link-Layer Topology Discovery Mapper (lltdsvc)
• Microsoft Account Sign-in Assistant (wlidsvc)
• Microsoft Passport (NgcSvc)
• Microsoft Passport Container (NgcCtnrSvc)
• Network Connection Broker (NcbService)
• Phone Service (PhoneSvc)
• Print Spooler (Spooler)
• Printer Extensions and Notifications (PrintNotify)
• Program Compatibility Assistant Service (PcaSvc)
• Quality Windows Audio Video Experience (QWAVE)
• Radio Management Service (RmSvc)
• Sensor Data Service (SensorDataService)
• Sensor Monitoring Service (SensrSvc)
• Sensor Service (SensorService)
• Shell Hardware Detection (ShellHWDetection)
• Smart Card Device Enumeration Service (ScDeviceEnum)
• SSDP Discovery (SSDPSRV)
• Still Image Acquisition Events (WiaRpc)
• Sync Host (OneSyncSvc)
• Touch Keyboard and Handwriting Panel (TabletInputService)
• UPnP Device Host (upnphost)
• User Data Access (UserDataSvc)
• User Data Storage (UnistoreSvc)
• WalletService (WalletService)
• Windows Audio (Audiosrv)
• Windows Audio Endpoint Builder (AudioEndpointBuilder)
• Windows Camera Frame Server (FrameServer)
• Windows Image Acquisition (WIA) (stisvc)
• Windows Insider Service (wisvc)
• Windows Mobile Hotspot Service (icssvc)
• Windows Push Notifications System Service (WpnService)
• Windows Push Notifications User Service (WpnUserService)
• Xbox Live Auth Manager (XblAuthManager)
• Xbox Live Game Save (XblGameSave)

Unnecessary tasks

On Windows Server installations with Desktop Experience, two scheduled tasks exist that can be removed without consequences on AD FS Servers:

1. \Microsoft\XblGameSave\XblGameSaveTask
2. \Microsoft\XblGameSave\XblGameSaveTaskLogon

Harden Services

As the AD FS Servers are part of Active Directory Domain Services, the best way to disable the unnecessary Windows Services is through Group Policy.

Follow these steps:

1. Sign in with an account that is a member of the Domain Admins group, or with an account that is delegated to create and link Group Policy objects (GPOs) to Organizational Units (OUs).
2. Open the Group Policy Management console (gpmc.msc).
3. In the left navigation pane, navigate to the Organizational Unit (OU) where the AD FS Servers reside.
4. Right-click the OU and select Create a GPO in this domain, and Link it here….
5. In the New GPO pop-up, provide a name for the Group Policy Object, corresponding to the naming convention for Group Policy objects in the environment.
6. Click OK
7. Back in navigation pane of the Group Policy Management console, expand the OU and click on the Group Policy object link.
8. Click OK in the Group Policy Management Console pop-up, explaining You have selected a link to a Group Policy Object (GPO). Except for changes to link properties, changes you make here are global to the GPO, and will impact all other location where this GPO is linked.
9. Right-click the Group Policy object and select Edit… from the context menu.
   The Group Policy Management Editor window appears.
10. In the left navigation pane, under Computer Configuration, expand the Policies node.
11. Expand the Windows Settings node.
12. Expand the Security Settings node.
13. Select System Services.

14. In the main pane, for each service in the above list, double-click the service, and then select the Define this policy setting option and select the Disabled service startup mode.
15. When done, close the Group Policy Management Editor window.
16. Close the Group Policy Management Console window.
17. Sign out.

Remove Scheduled Tasks

As the AD FS Servers are part of Active Directory Domain Services, the best way to remove the unnecessary scheduled tasks is through Group Policy Preferences.

Note:
Do not place Group Policy settings and Group Policy preferences in the same Group Policy object, as this will result in synchronous processing behavior and slowness during startups of the AD FS Servers.

Follow these steps:

1. Sign in with an account that is a member of the Domain Admins group, or with
   an account that is delegated to create and link Group Policy objects (GPOs) to
   Organizational Units (OUs).
2. Open the Group Policy Management console (gpmc.msc).
3. In the left navigation pane, navigate to the Organizational Unit (OU) where
   the AD FS Servers reside.
4. Right-click the OU and select Create a GPO in this domain, and Link
   it here….
5. In the New GPO pop-up, provide a name for the Group Policy
   Object, corresponding to the naming convention for Group Policy objects in the
   environment.
6. Click OK
7. Back in navigation pane of the Group Policy Management console,
   expand the OU and click on the Group Policy object link.
8. Click OK in the Group Policy Management
   Console pop-up, explaining You have selected a link to a Group
   Policy Object (GPO). Except for changes to link properties, changes you make
   here are global to the GPO, and will impact all other location where this GPO is
   linked.
9. Right-click the Group Policy object and select Edit… from
   the context menu.
   The Group Policy Management Editor window
   appears.
10. In the left navigation pane, under Computer Configuration,
    expand the Preferences node.
11. Expand the Control Panel Settings node.
12. Expand the Scheduled Tasks node.
13. In the main pane, right-click on Scheduled Tasks and select New  and then Scheduled Task from the context menu.

14. In the New Task Properties window,select Delete as the action and provide the name of the scheduled task, exactly as provided above.
15. Click OK.
16. Repeat steps 13-15 for the second task.
17. When done, close the Group Policy Management Editor
    window.
18. Close the Group Policy Management Console window.
19. Sign out.

Concluding

Disable unnecessary services on all AD FS Servers throughout the Hybrid Identity implementation using Group Policy.

The post HOWTO: Disable Unnecessary Services and Scheduled Tasks on AD FS Servers appeared first on The things that are better left unspoken.

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 June 2019:

What’s New

New riskDetections API for Microsoft Graph Public preview

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

Microsoft is pleased to announce the new riskDetections API for Microsoft Graph is now in public preview. Administrators can use this new API to view a list of their organization’s Identity Protection-related user and sign-in risk detections. Admins can also use this API to more efficiently query risk detections, including details about the detection type, status, level, and more.

New Federated Apps available in Azure AD app gallery

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

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

1. Azure AD SAML Toolkit
2. Otsuka Shokai (大塚商会)
3. ANAQUA
4. Azure VPN Client
5. ExpenseIn
6. Helper Helper
7. Costpoint
8. GlobalOne
9. Mercedes-Benz In-Car Office
10. Skore
11. Oracle Cloud Infrastructure Console
12. CyberArk SAML Authentication
13. Scrible Edu
14. PandaDoc
15. Perceptyx
16. Proptimise OS
17. Vtiger CRM (SAML)
18. Oracle Access Manager for Oracle Retail Merchandising
19. Oracle Access Manager for Oracle E-Business Suite
20. Oracle IDCS for E-Business Suite
21. Oracle IDCS for PeopleSoft
22. Oracle IDCS for JD Edwards

Automate user account provisioning for these SaaS apps

Service category: Enterprise Apps
Product capability: Monitoring & Reporting

Azure AD admins can now automate creating, updating, and deleting user accounts for these newly-integrated apps:

• Zoom
• Envoy
• Proxyclick
• 4me

What’s Changed

View the real-time progress of the Azure AD provisioning service

Service category: App Provisioning
Product capability: Identity Lifecycle Management

Microsoft has updated the Azure AD provisioning experience to include a new progress bar that shows admins how far they are in the user provisioning process. This updated experience also provides information about the number of users provisioned during the current cycle, as well as how many users have been provisioned to date.

Company branding now appears on sign out and error screens

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

Microsoft has updated Azure AD so that company branding now appears on the sign out and error screens, as well as the sign-in page. Administrators don’t have to do anything to turn this feature on; Azure AD simply uses the assets that have already been set up in the Company branding area of the Azure portal.

What’s Deprecated

Azure Multi-Factor Authentication (MFA) Server is no longer available for new deployments

Service category: MFA
Product capability: Identity Security & Protection

As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New organizations who want to require multi-factor authentication must now use cloud-based Azure Multi-Factor Authentication. Organizations who activated MFA Server prior to July 1 won’t see a change; Admins will still be able to download the latest version, get future updates, and generate activation credentials.

The post What’s New in Azure Active Directory for June 2019 appeared first on The things that are better left unspoken.

One of the questions I get asked a lot is:

Why virtualize Domain Controllers?

So, in this blogpost, I’m showing you reasons why virtualization for Domain Controllers and Active Directory is a good idea. I also know there are a lot of caveats when virtualization Domain Controllers, so this blogpost serves as a small part of a bigger series on how to do it right.

Reasons to virtualize Domain Controllers fall in three buckets:

• Virtualization is mainstream
• Active Directory is virtualization-friendly
• Physical Domain Controllers waste compute resources

Let’s look at these three areas and provide some real-world examples.

Virtualization is mainstream

You’ve probably heard of ‘cloud’. Whether it’s Private Cloud (hosted in your own datacenters or the datacenters of an organization you’ve outsourced it to) or Public Cloud (like Microsoft’s Azure and Amazon’s AWS), virtualization, coupled with self-service, is the cornerstone to making it happen. “Virtualize First” is the new normal.

Also, virtualization is no longer black magic. Virtualization platforms like VMware’s Sphere and Microsoft’s Hyper-V platforms are well-documented. People who want to be proficient at managing virtualization have a wide range of training to follow and certificates to achieve. When you run into problems with any of the virtualization platforms, there’s free support options available, like Stack Overflow and the vendor’s support forums, next to paid support options.

Since Windows Server 2012, virtualization for Active Directory is fully supported by Microsoft. VMware fully supports virtualizing Domain Controller (as long as you follow their recommended practices).

You could ask yourself if Microsoft still tests Domain Controller functionality and updates on physical hardware. If this is the case and you’re running Domain Controllers on physical hardware, aren’t you putting your organization at risk?

Active Directory is virtualization-friendly

From its inception back in 1997, Active Directory has been virtualization-friendly.

It has never had high memory or I/O requirements. You can run Domain Controllers on machines with loathsome specifications. A single CPU, just a few GBs of RAM and some GBs of disk storage is all you need to even run a Windows Server 2019-based Domain Controller. When running Domain Controllers as Server Core installations, the requirements drop even further. This makes them ideal candidates to virtualize.

The distributed nature of the Active Directory database also adds to the virtualization-friendliness of Active Directory. Scale-out is the preferred method to increase Active Directory performance, not scale-up (except perhaps for the Domain Controller holding the PDC emulator FSMO role…). Just add small-sized VMs to the virtualization platform and Active Directory is again ready to go.

All Domain Controllers are created equal (but some Domain Controllers, like the aforementioned PDC emulator) and replication offers a multi-master model. This makes Active Directory resilient; with the majority of Domain Controllers decimated during a disaster, it can still function. Also, purely based on the virtual disk of a Domain Controller, it can be restored on a compatible virtualization platform.

These system specs, its distributed nature and its sustainable level of degradation are all specifics for virtual machines that virtualization admins love to host for you.

Physical Domain Controllers waste compute
resources

When looking for the cheapest rack server on Dell.com today, I stumbled upon the PowerEdge R240. It has a Celeron G4900 3,1GHz processor, 8GB RAM and a 1TB HDD for a mere $589. For $926 there is an Intel Xeon E2124-based, 16GB model available from HP Enterprise. These systems have one thing in common: The smallest sized disk you can buy in them measures 1TB. This disk size is overkill in any networking environment, except for Fortune 500 companies as the Active Directory files don’t take up that much space. (unless you’re storing user profile pictures in them, but even then it’s not a huge problem). Even the 8GB RAM of the cheapest Dell rack server you can get allows you to cache the Active Directory database for an organization with over 100,000 users.

Active Directory simply isn’t able to utilize the compute resources available on modern hardware. Running Domain Controllers on physical hardware equals wasting computer resources. Wasting compute resources means wasting money.

Concluding

Virtualize Domain Controllers.

Does that mean you can virtualize all your Domain Controllers? Does that mean you can be as coarse with virtual Domain Controllers as you can be with physical Domain Controllers? Does that mean virtual Domain Controllers are as secure as physical Domain Controllers? Join me for the answers on these questions in the next parts of this series.

The post Why virtualize Domain Controllers? appeared first on The things that are better left unspoken.

In the first part of this series, we discussed why we want to virtualize Domain Controllers. The first question people ask is:

How do I properly size Domain Controllers on my virtualization platform?

Specifically, for VMware vSphere, this is a good question, because there are a couple of areas of attention, beyond the recommended practices from Microsoft:

Microsoft recommended practices

For sizing Domain Controllers, Microsoft recommends to:

• Deploy at least two Domain Controllers per Active Directory domain.
• Create exceptions for antimalware solutions for the folders containing Active Directory files.
• Deploy the Local Administrator Password Solution (LAPS).
• Do not install additional software or Server Roles on Domain Controllers.
• Install Windows updates on Domain Controllers.
• Keep information security measures on Domain Controllers, like antimalware, backup, restore, monitoring, auditing, bad password blocking and SIEM solutions, up to date.
• Have a recovery plan available for Active Directory.

Areas of Attention

CPU

A good rule of thumb for the number of virtual Central Processing Units (vCPUs) for is to size virtual Domain Controllers with 1 vCPU, when the environment has 10,000 users, or less. When the environment has more than 10,000 users, add another vCPU to the Domain Controllers.

When in doubt, start with 2 vCPUs in virtual Domain Controllers and add vCPUs as needed. The Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role will be the most burdened Domain Controller of all. It performs these additional tasks, when compared to all the other Domain Controllers in the Active Directory domain:

• Password changes performed by other Domain Controllers in the Active Directory domain are replicated preferentially to the PDC emulator.
• If a logon authentication fails at a given Domain Controller in an Active Directory domain due to a bad password, the Domain Controller will forward the authentication request to the PDC emulator to validate the request against the most current password. If the PDC reports an invalid password to the Domain Controller, the Domain Controller will send back a bad password failure message to the user.
• Account lockout is processed on the PDC emulator.
• The Domain Controller with the PDC emulator FSMO role, by default, functions as the authoritative source of time in the Active Directory domain.
• The Domain Controller with the PDC emulator FSMO role fulfills the role of the PDC in the NetLogon Remote Protocol methods. Therefore, the Domain Controller with the PDC emulator FSMO role must support and perform all PDC specific functionality specified in that section. Every other Domain Controller must not perform this functionality.

Tip!
In VMware vSphere-based VMs with more than one vCPU, make sure to look at the Networking section below to avoid the unavailability of receive-side scaling.

RAM

If you want highly-performing Domain Controllers, provide them with a sufficient amount of Random Access Memory (RAM) to be able to cache the Active Directory database (ntds.dit).

A good metric to monitor is the Database/Database Cache %Hit counter for the LSASS process on Domain Controllers. A low hit rate indicates that the Domain Controller would benefit from more RAM.

Storage

Microsoft recommends to use a 40GB system volume (C:\) to store the Windows Operating System. However, Active Directory requires additional storage. You may or may not place these files on the system volume, depending on your view on dynamic files. Independent of this choice, you need to take into account the following storage needs for a Domain Controller:

For a typical organization of 100,000 persons, this would lead to 5GB of additional storage requirements. Of course, when such an organization would decide to store user photos in Active Directory, storage requirements could potentially triple.

Networking

Ideally, configure virtual Domain Controllers with one virtual Network Interface Card (vNIC). Use VMXNET3 for best performance.

Additionally, upgrade the VMware Tools of existing virtual machines to version 10.2.5. The Windows Receive Side Scaling (RSS) feature is not functional on virtual machines running VMware Tools versions 9.10.0 up to 10.1.5. On virtual Domain Controllers with multiple vNICs, under heavy network load, this may cause a situation where CPU0 is overloaded, as depicted in the below screenshot:

Since VMXNET3 driver version 1.7.3.8 (as part of VMware Tools 10.2.5), this driver version enables Receive-side Scaling (RSS) and Receive Throttle settings, by default – but only for new VMware Tools installations on new virtual machines. If you upgrade an existing VMware Tools install, these settings will remain as is.

On existing virtual Domain Controllers, make sure to enable Receive Side Scaling (RSS) and set the Receive Throttle to 30, using the following line of Windows PowerShell on virtual Domain Controllers running VMware Tools 10.2.5, or up:

Enable-NetAdapterrss –Name “*”

Agents and add-ons

On top of the above requirements for the Active Directory role, make sure you provide sufficient resources for the typical agents and add-ons your organization would typically install on Domain Controllers, like antimalware, backup, restore, monitoring, auditing, bad password blocking and SIEM solutions.

In practice

Because of this last area of attention, we see organizations typically deploy virtual Domain Controllers with 1 vCPU, 4GB RAM, a 60GB system volume and 1 vNIC.

These dimension are a far cry from the other sizing we often encounter in organization where, according to the design all hardware factors are blades and a physical Domain Controller was deemed necessary. The typical dimension of these Domain Controller blades depend on the phase in the project where its importance was understood. The largest Domain Controller we’ve come across was a blade with 2 CPUs, 24 cores, 512GB RAM and 2 300GB hard disks in RAID1.

Concluding

Sizing is often the first hurdle to cross when virtualizing Domain Controllers. Join me for the next parts were we drill deeper into the integrity, confidentiality and availability of Domain Controllers.

Just out of curiosity, what was the largest physical Domain Controller you’ve ever come across in production?

The post Sizing Domain Controllers correctly on VMware vSphere appeared first on The things that are better left unspoken.

Last week, on Tuesday June 20 2019, the Royal Dutch Association of Information and IT Professionals (KNVI) organized the “Active Directory, What’s Cooking?” Event at Hit Eten en Drinken in Cappele aan den Ijssel in the Netherlands.

As we were to gather at 18:30, I worked for a customer in Utrecht that Tuesday. I can start and leave early, there, so this left me with ample room in my schedule to fiddle around.

I anticipated traffic on my way over, but didn’t meet any. I arrived at 16:45. I took a seat inside and prepared some slides, while I waited for the other speakers and the organization to arrive. At 18:30, the food on the BBQ was ready, and we could all enjoy food before getting to the presentation part of the evening.

At 20:00, Erwin Derksen and I kicked off with some light entertainment. We discussed Multi-Factor Authentication and Azure Active Directory Domain Services. 45 minutes in, I talked a bit about the book, its timelines and struggles. Concluding, my colleague Barbara Forbes talked about how she helped me with her Azure DevOps magic, to create pre-canned Active Directory environments with one click in under 35 minutes.

I signed a couple of books and then we had some drinks. I came home at 22:45 with a huge smile on my face.

Thank you!

Thank you KNVI for organizing this meetup.

The post Pictures of the KNVI "Active Directory, What’s Cooking?" Event appeared first on The things that are better left unspoken.

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

Why harden Azure AD Connect

Hardening provides additional layers to defense in depth approaches. It changes the default behavior of products and services to make them more resilient to unauthorized changes and compromise.

Reasons why

Azure AD Connect installations are typically placed on the internal network, close to Active Directory Domain Controllers. In fact, many security experts advice to treat Azure AD Connect installations as Domain Controllers. When an Azure AD Connect installation is compromised, the information on the Windows Server and in the Azure AD Connect database can be used to:

• Make changes to the entire Azure AD Connect tenant, for instance by changing the password of an account with the Global Administrator role or adding an account to a group to provide access to resources.
• Make changes to the Organizational Units (OUs) in Active Directory in scope for Azure AD Connect (in the case of hardened service accounts with privileges limited to the OUs in scope, for instance change passwords for administrators, add accounts to groups and attach new on-premises accounts to existing Azure AD accounts through the objectGUID or mS-DS-ConsistencyGUID attribute, used as source anchor.
• Implement additional Domain Controllers and/or perform a DCSync attack, based on the Replicate Changes and Replicate Changes All permissions assigned in Active Directory to the Azure AD Connect service account.

Also remember that Azure AD Connect cannot be implemented on Server Core installations of Windows Server or Windows containers: Azure AD Connect requires a Windows Server installation with Desktop Experience (or what most people call a ‘Full Server’)

Possible negative impact (What could go wrong?)

When an Azure AD Connect installation is hardened improperly, it may stop synchronizing objects from Active Directory to Azure Active Directory. Synchronization cycle occur every 30 minutes, by default. So you may not get events indicating something is wrong in Event Viewer right away.

When synchronization stops or is partial, the most apparent problem is that colleagues will start experiencing lack of functionality; When they get married, their name change is not reflected everywhere. When they get added to a group, they don’t gain access to cloud applications. When they change or reset their password, it’s not reflected, or they receive a “Something went wrong” error, etc.

However, things get tricky when people are laid off on the spot. In these situations, it’s important that the user account is disabled, stripped from permissions and/or removed throughout all systems as soon as possible.

Getting Ready

To disable unnecessary services on Windows Servers running Azure AD Connect, make sure to meet the following requirements:

System requirements

Make sure the Web Application Proxies are installed with the latest cumulative Windows Updates. Also make sure you run the latest stable version of Azure AD Connect.

Privilege requirements

Make sure to sign in with an account that has privileges to create and/or change and link Group Policy objects to the Organizational Unit (OU) in which the AD FS servers reside.

Who to communicate to

When intending to make changes to Azure AD Connect installations, make sure to send a heads-up to these people and/or teams in your organization:

• Load balancers and networking guys and gals
• The Active Directory team
• The people responsible for backups, restores and disaster recovery
• The people going through the logs, using a SIEM and/or a TSCM solution
• The monitoring team

One of the challenges you can easily avoid through communications is that multiple persons and/or teams make changes to the configuration. When it breaks, you don’t want to roll-back a bunch of changes, just the one that broke it. Make sure you have the proper freeze/unfreeze moments to achieve that.

Unnecessary services

By default

The following Windows services are disabled, by default, on Windows Server with Desktop Experience installations of Windows Server 2016:

• Auto Time Zone Update (tzautoupdate)
• Computer Browser (browser)
• Microsoft App-V Client (AppVClient)
• Net.Tcp Port Sharing Service (NetTcpPortSharing)
• Offline files (cscService)
• Routing and Remote Access (RemoteAccess)
• Smart Card (SCardSvr)
• User Experience Virtualization Service (UevAgentService)
• Windows Search (WSearch)

These services do not require any further attention.

Additional services

The following Windows services are enabled and have Manual or Automatic startup types on installations of Windows Server 2016 with the Desktop Experience (Full Installations). These can be disabled:

• ActiveX Installer (AxInstSV) (AxInstSV)
• Bluetooth Support Service (bthserv)
• CDPUserSvc (CDPUserSvc)
• Contact Data (PimIndexMaintenancesvc)
• dmwappushsvc (dmwappushsvc)
• Downloaded Maps Manager (MapsBroker)
• Geolocation Service (lfsvc)
• Internet Connection Sharing (ICS) (SharedAccess)
• Link-Layer Topology Discovery Mapper (lltdsvc)
• Microsoft Account Sign-in Assistant (wlidsvc)
• Microsoft Passport (NgcSvc)
• Microsoft Passport Container (NgcCtnrSvc)
• Network Connection Broker (NcbService)
• Phone Service (PhoneSvc)
• Print Spooler (Spooler)
• Printer Extensions and Notifications (PrintNotify)
• Program Compatibility Assistant Service (PcaSvc)
• Quality Windows Audio Video Experience (QWAVE)
• Radio Management Service (RmSvc)
• Sensor Data Service (SensorDataService)
• Sensor Monitoring Service (SensrSvc)
• Sensor Service (SensorService)
• Shell Hardware Detection (ShellHWDetection)
• Smart Card Device Enumeration Service (ScDeviceEnum)
• SSDP Discovery (SSDPSRV)
• Still Image Acquisition Events (WiaRpc)
• Sync Host (OneSyncSvc)
• Touch Keyboard and Handwriting Panel (TabletInputService)
• UPnP Device Host (upnphost)
• User Data Access (UserDataSvc)
• User Data Storage (UnistoreSvc)
• WalletService (WalletService)
• Windows Audio (Audiosrv)
• Windows Audio Endpoint Builder (AudioEndpointBuilder)
• Windows Camera Frame Server (FrameServer)
• Windows Image Acquisition (WIA) (stisvc)
• Windows Insider Service (wisvc)
• Windows Mobile Hotspot Service (icssvc)
• Windows Push Notifications System Service (WpnService)
• Windows Push Notifications User Service (WpnUserService)
• Xbox Live Auth Manager (XblAuthManager)
• Xbox Live Game Save (XblGameSave)

Unnecessary tasks

On Windows Server installations with Desktop Experience, two scheduled tasks exist that can be removed without consequences on Windows Servers running Azure AD Connect:

1. \Microsoft\XblGameSave\XblGameSaveTask
2. \Microsoft\XblGameSave\XblGameSaveTaskLogon

How to disable unnecessary services

As the Windows Servers running Azure AD Connect are part of Active Directory Domain Services, the best way to disable the unnecessary Windows Services is through Group Policy.

Follow these steps:

1. Sign in with an account that is a member of the Domain Admins group, or with an account that is delegated to create and link Group Policy objects (GPOs) to Organizational Units (OUs).
2. Open the Group Policy Management console (gpmc.msc).
3. In the left navigation pane, navigate to the Organizational Unit (OU) where the AD Windows Servers running Azure AD Connect reside.
4. Right-click the OU and select Create a GPO in this domain, and Link it here….
5. In the New GPO pop-up, provide a name for the Group Policy Object, corresponding to the naming convention for Group Policy objects in the environment.
6. Click OK
7. Back in navigation pane of the Group Policy Management console, expand the OU and click on the Group Policy object link.
8. Click OK in the Group Policy Management Console pop-up, explaining You have selected a link to a Group Policy Object (GPO). Except for changes to link properties, changes you make here are global to the GPO, and will impact all other location where this GPO is linked.
9. Right-click the Group Policy object and select Edit… from the context menu.
   The Group Policy Management Editor window appears.
10. In the left navigation pane, under Computer Configuration, expand the Policies node.
11. Expand the Windows Settings node.
12. Expand the Security Settings node.
13. Select System Services.
14. In the main pane, for each service in the above list, double-click the service, and then select the Define this policy setting option and select the Disabled service startup mode.
15. When done, close the Group Policy Management Editor window.
16. Close the Group Policy Management Console window.
17. Sign out.

How to remove scheduled tasks

As the Windows Servers running Azure AD Connect are part of Active Directory Domain Services, the best way to remove the unnecessary scheduled tasks is through Group Policy Preferences.

Note:
Do not place Group Policy settings and Group Policy preferences in the same Group Policy object, as this will result in synchronous processing behavior and slowness during startups of the Windows Servers running Azure AD Connect.

Follow these steps:

1. Sign in with an account that is a member of the Domain Admins group, or with
   an account that is delegated to create and link Group Policy objects (GPOs) to
   Organizational Units (OUs).
2. Open the Group Policy Management console (gpmc.msc).
3. In the left navigation pane, navigate to the Organizational Unit (OU) where
   the Windows Servers running Azure AD Connect reside.
4. Right-click the OU and select Create a GPO in this domain, and Link
   it here….
5. In the New GPO pop-up, provide a name for the Group Policy
   Object, corresponding to the naming convention for Group Policy objects in the
   environment.
6. Click OK
7. Back in navigation pane of the Group Policy Management console,
   expand the OU and click on the Group Policy object link.
8. Click OK in the Group Policy Management
   Console pop-up, explaining You have selected a link to a Group
   Policy Object (GPO). Except for changes to link properties, changes you make
   here are global to the GPO, and will impact all other location where this GPO is
   linked.
9. Right-click the Group Policy object and select Edit… from
   the context menu.
   The Group Policy Management Editor window
   appears.
10. In the left navigation pane, under Computer Configuration,
    expand the Preferences node.
11. Expand the Control Panel Settings node.
12. Expand the Scheduled Tasks node.
13. In the main pane, right-click on Scheduled Tasks and select New  and then Scheduled Task from the context menu.
14. In the New Task Properties window,select Delete as the action and provide the name of the scheduled task, exactly as provided above.
15. Click OK.
16. Repeat steps 13-15 for the second task.
17. When done, close the Group Policy Management Editor
    window.
18. Close the Group Policy Management Console window.
19. Sign out.

Testing proper hardening

After hardening it’s time to test the hardening. Everyone should sign off (not literally, unless that’s procedure) on the correct working of the Windows Servers running Azure AD Connect. Does authentication to cloud applications still work? Does rolling over the certificate still work? Does monitoring still work? Can we still make back-ups? Can we still restore the backups we make?

Typically, hardening is rolled out to one Windows Server running Azure AD Connect. When testing the hardening of the functionality behind the load balancer, make sure that the load balancer points you to the hardened system, not another one.

Rolling back hardening

To roll back hardening of the services and removal of the scheduled tasks, disable the Group Policy object(s) or remove the link between the Group Policy object(s) and the Organizational Unit (OU) where the Windows Servers running Azure AD Connect reside.

Concluding

Disable unnecessary services on all Windows Servers running Azure AD Connect throughout the Hybrid Identity implementation using Group Policy.

Further reading

Mimikatz and DCSync and ExtraSids, Oh My
Mimikatz DCSync Usage, Exploitation, and Detection

The post HOWTO: Disable Unnecessary Services and Scheduled Tasks on Windows Servers running Azure AD Connect appeared first on The things that are better left unspoken.

One of the hardest things to get right with virtual Domain Controllers is the time hierarchy in Active Directory. Recommended practices from Microsoft have been all over the place, but seem to have solidified in the last years, but the question remains:

How do I manage Active Directory Time Synchronization on VMware vSphere?

This is a valid question, and the answer for virtual Domain Controllers running on Microsoft Hyper-V is different to virtual Domain Controllers running on VMware vSphere…

Active Directory and time

Why the correct time is important to Domain Controllers

You might not think accurate time is important in Active Directory, and you would be right in most cases. However, there are a couple of cases where accurate time is important:

• Kerberos authentication, as heavily used in Active Directory, allows for five minutes time difference between an authenticating client (that could also be a domain-joined server) and the authenticating server (that is always a Domain Controller). Beyond the five minute time frame, authentication fails.
• Domain Controllers replicate the contents of the Active Directory database based on InvocationIDs, indicating replication partners, unique serial numbers per object (USNs) and the originating DN (Domain Controller) for writes to objects.
  Only when two writes in Active Directory cross replication, the time stamp is used to make the last write win.

That’s why Active Directory offers a time hierarchy.

About the Active Directory Time Hierarchy

In every Active Directory environment, time is synchronized in a hierarchy. This hierarchy is depicted in the below image, courtesy of the Time Synchronization in Active Directory Forests page in the Microsoft TechNet Wiki:

The Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role in the root domain represents the top of the hierarchy and is considered the authoritative time source. That’s why the Active Directory Best Practices Analyzer (BPA) reports an action when this Domain Controller does not synchronize its time with an external source, like a pool of NTP servers on the Internet or a couple of GPS-equipped internal appliances, or a combination of both.

The Domain Controller holding the PDCe FSMO role represents the top. This Domain Controller is contacted by the w32time service running on:

1. Domain Controllers holding the PDCe FSMO role for the other domains in the Active Directory forest (although these Domain Controllers can synchronize with any Domain Controller from the root domain)
2. The other Domain Controllers in the root domain

Domain-joined devices and member servers in the root domain, then, contact these other Domain Controllers to synchronize time with. (This reduces the load on the Domain Controller with the PDCe FSMO role.)

In the other domains in the Active Directory forest, other Domain Controllers in these domains synchronize their time with the Domain Controller holding the PDCe FSMO role in their domain. Domain-joined devices and member servers in the non-root domain can synchronize with any Domain Controller in their respective domain.

Challenges with time drift

The above hierarchy works almost flawless in environments with physical Domain Controllers, but represents a couple of challenges when working with virtualized Domain Controllers:

• When the hypervisor host is not synchronizing time with a reliable time source, it may provide the wrong time to a virtual Domain Controller. Domain Controllers synchronizes time with the tier above them only every 3600 seconds, so in extremis Domain Controllers may provide member servers and domain-joined devices wrong time for an hour, resulting in possible authentication failures.
• When the hypervisor host is not synchronizing time with a reliable time source, it may provide the wrong time to a virtual Domain Controller. In environments with high volumes of changes to objects in Active Directory, this might result in replicating changes from the Domain Controller as they are indicated as winning last writes, due to incorrect time stamps.
• When the time difference is greater than 48 hours, the w32time service on Windows Server 2008, and up, will not correct the time, because of the phase correction limits. Microsoft KnowledgeBase article 884776 explains how to change these limits through the MaxPosPhaseCorrection and MaxNegPhaseCorrection registry entries. (However, with incorrect time, there is no Kerberos, and thus no Group Policy…)

Microsoft recommended practices

Microsoft recommends to:

1. Synchronize the time of the Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role in the root domain with a reliable time source.
2. Use the default time synchronization hierarchy throughout Active Directory.

Specific to virtual Domain Controllers, Microsoft has held different points of view on time synchronization.

accurate time for Windows Server 2016

Microsoft introduced increased polling and clock update frequency in Windows Server 2016 Active Directory, when compared to Windows Server 2008/2012. While this introduces a small additional CPU load on Domain Controllers, it does provide for more Accurate Time for Windows Server 2016 because of more frequent polling, updating and through an algorithm that calculates time difference trends.

Time Synchronization on VMware vSphere

There are two models for time synchronization between virtual Domain Controllers and VMware vSphere hosts:

1. Disable time synchronization between virtual machines and the hypervisor to avoid a virtual Domain Controller to pick up bad time settings when the hypervisor is not synchronizing time properly.
2. Synchronize the time on hypervisor hosts to the same external time source as the Domain Controller with the PDCe FSMO role in the forest root domain.

There are some things you need to know:

Disable time synchronization with the hypervisor host

Many websites on the internet will instruct you to disable the Synchronize guest time with host option in the virtual machine’s properties to disable time synchronization with the hypervisor host, like in the below screenshot:

As VMware KnowledgeBase article 1189 points out, this does not completely disable time synchronization, because virtual Domain Controllers will synchronize their time when you,

• Suspend it, the next time you resume it
• Migrate the virtual Domain Controller using vMotion
• Take a snapshot
• Restore to a snapshot
• Shrink the virtual disk
• Restart the VMware Tools service
• Reboot the virtual Domain Controller

To effectively disable time synchronization, add the following lines to your virtual machine’s advanced configuration options:

tools.syncTime = “0”
time.synchronize.continue = “0”
time.synchronize.restore = “0”
time.synchronize.resume.disk = “0”
time.synchronize.shrink = “0”
time.synchronize.tools.startup = “0”
time.synchronize.tools.enable = “0”
time.synchronize.resume.host = “0”

To disable time synchronization across multiple VMs at once, use VMware vRealize Orchestrator.

Synchronize hypervisor time with a reliable source

Synchronizing the time on the hypervisor with a reliable source sounds like a piece of cake, but gets tedious to manage at large scale. When you’ve found your way to manage the configuration of all hypervisor hosts, it’s also noteworthy to:

• Disable VMware Distributed Resource Scheduler (DRS) for Domain Controllers holding the PDCe FSMO role
• Use Host-Guest Affinity Rule for Domain Controllers holding the PDCe FSMO role

Recommendations

Disable time synchronization with the hypervisor host on the virtual Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role in the root domain and synchronize its time with a combination of:

• DNS names of a reliable time source on the internet, like pool.ntp.org.
• IP addresses of a reliable time source on the internet, like 131.211.8.244 and 5.79.108.34. (This make sure time synchronization occurs even when DNS is unavailable and minimizes the effect of DNS poisoning attacks.)
• IP addresses of reliable time sources on the internal network, like GPS-based NTP appliances on the internal network. (This makes sure time synchronization occurs even when internet connectivity is unavailable).

For all other virtual Domain Controllers, virtual member servers and virtual domain-joined devices, make sure the hypervisor hosts they run on have accurate time. Then, the virtual machines will make the most of time synchronization from both the hypervisor and Active Directory. Especially when they run Windows Server 2016, or up.

Further reading

Time Synchronization in Active Directory Forests
Active Directory: Time Synchronization
Configuring the Windows Time Service in an Active Directory Forest – A step by step

The post Managing Active Directory Time Synchronization on VMware vSphere appeared first on The things that are better left unspoken.

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

Note:
This blogpost assumes Azure AD Connect runs on a Windows Server 2016 with Desktop Experience (“Full installation”) installation.

Why harden

Hardening provides additional layers to defense in depth approaches. It changes the default behavior of products and services to make them more resilient to unauthorized changes and compromise.

Reasons why

Secure connections over the Internet are commonly encrypted. The protocol, cipher suite and hashing algorithm are negotiated to make sure both ends of the communications channel can understand what’s being interchanged encrypted. In most cases, this would result in the strongest protocol, cipher suite and hashing algorithm being used.

However, for communications containing personally identifiable information (PII data) or information on data subjects, more guarantees are needed. A common mitigating measure in terms of a GDPR-enforced data privacy impact analysis (DPIA), would be to force the component responsible for interchanging this data to use the strongest protocol, cipher suite and hashing algorithm.

This is exactly what the topic is for today: Making sure Azure AD Connect interchanges information on the TLS 1.2 protocol only.

Possible negative impact (What could go wrong?)

When an Azure AD Connect installation is hardened improperly, it may stop synchronizing objects from Active Directory to Azure Active Directory. Synchronization cycle occur every 30 minutes, by default. So you may not get events indicating something is wrong in Event Viewer right away.

When synchronization stops or is partial, the most apparent problem is that colleagues will start experiencing lack of functionality; When they get married, their name change is not reflected everywhere. When they get added to a group, they don’t gain access to cloud applications. When they change or reset their password, it’s not reflected, or they receive a “Something went wrong” error, etc.

However, things get tricky when people are laid off on the spot. In these situations, it’s important that the user account is disabled, stripped from permissions and/or removed throughout all systems as soon as possible.

Getting Ready

To enforce Azure AD Connect to use TLS 1.2 only, make sure to meet the following requirements:

System requirements

Make sure the Windows Server installations are installed with the latest cumulative Windows Updates. Also make sure you run the latest stable version of Azure AD Connect.

Privilege requirements

Make sure you are signed in with an account that has local administrative privileges on the Windows Server(s) running Azure AD Connect.

Who to communicate to

When intending to make changes to Azure AD Connect installations, make sure to send a heads-up to these people and/or teams in your organization:

• Load balancers and networking guys and gals
• The Active Directory team
• The people responsible for backups, restores and disaster recovery
• The people going through the logs, using a SIEM and/or a TSCM solution
• The monitoring team

One of the challenges you can easily avoid through communications is that multiple persons and/or teams make changes to the configuration. When it breaks, you don’t want to roll-back a bunch of changes, just the one that broke it. Make sure you have the proper freeze/unfreeze moments to achieve that.

How to enforce Azure AD Connect to use TLS 1.2 only

To enforce Azure AD Connect to use TLS 1.2 only, run the following Windows PowerShell script in an elevated PowerShell window on each of the Windows Server installations running Azure AD Connect:

Note:
RFC 8446 defines the Transport Layer Security (TLS) Protocol Version 1.3. However, TLS 1.3 has not found its way to Windows Server, yet. It is unavailable at the time of writing.

$RegPath1 = “HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319”

New-ItemProperty -path $RegPath1 `
-name SystemDefaultTlsVersions -value 1 -PropertyType DWORD

New-ItemProperty -path $RegPath1 `
-name SchUseStrongCrypto -value 1 -PropertyType DWORD

$RegPath2 = “HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319”

New-ItemProperty -path $RegPath2 `
-name SystemDefaultTlsVersions -value 1 -PropertyType DWORD

New-ItemProperty -path $RegPath2 `
-name SchUseStrongCrypto -value 1 -PropertyType DWORD

Testing proper hardening

After hardening it’s time to test the hardening. Everyone should sign off (not literally, unless that’s procedure) on the correct working of the Windows Servers running Azure AD Connect.

Note:
The registry changes are step 1 of two steps to harden protocols, cipher suites and hashing algorithms of the Hybrid Identity implementation. Make sure to disable weak protocols, cipher suites and hashing algorithms on the Windows Servers running Azure AD Connect, before testing these systems.

Does authentication to cloud applications still work? Does rolling over the certificate still work? Does monitoring still work? Can we still make back-ups? Can we still restore the backups we make?

Typically, hardening is rolled out to one Windows Server running Azure AD Connect. In an environment with a Staging Mode Azure AD Connect installation, the hardening can be performed on this Windows Server installation and tested with the normal Staging Mode (imports only) synchronization cycles. When hardening is approved upon, the actively synchronizing Azure AD Connect installation can be switched, or hardened, too.

Rolling back hardening

To roll back the settings that enforce Azure AD Connect to use TLS 1.2 only, use the following lines of Windows PowerShell:

$RegPath1 = “HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319”

New-ItemProperty -path $RegPath1 `
-name SystemDefaultTlsVersions -value 0 -PropertyType DWORD

New-ItemProperty -path $RegPath1 `
-name SchUseStrongCrypto -value 0 -PropertyType DWORD

$RegPath2 = “HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319”

New-ItemProperty -path $RegPath2 `
-name SystemDefaultTlsVersions -value 0 -PropertyType DWORD

New-ItemProperty -path $RegPath2 `
-name SchUseStrongCrypto -value 0 -PropertyType DWORD

Concluding

Enforcing Azure AD Connect to use TLS v1.2 is a perfect mitigating measure in terms of a GDPR-enforced data privacy impact analysis (DPIA). Be sure to implement it, and enable TLS 1.2 on the Windows Server installations running Azure AD Connect, too.

Further reading

TLS 1.2 enforcement for Azure AD Connect
Azure AD Connect moves to TLS 1.2-only with version 1.2.65.0
What’s New in Azure Active Directory for May 2019

The post HOWTO Enforce Azure AD Connect to use TLS 1.2 only appeared first on The things that are better left unspoken.