Nested Groups in Azure AD and Exchange 365

Posted by James F. Prudente on May 9, 2023
Posted in: Active Directory, Exchange, Office 365. Tagged: . 2 Comments

As in a lot of environments, we sync our on-prem AD to Azure AD, and as such, on-prem security groups are used to grant access to various cloud resources. For us, this includes shared calendars in Exchange 365.

We received a ticket that a few users were not getting the proper level of access to a shared calendar, and my initial investigation did not turn up anything that would explain the problem. Permissions were granted to a sync’d AD group, which itself contained two nested AD groups. Group nesting has always been a bit quirky in M365, so that was the obvious place to check, but users in the first nested group had the proper access. Only users in the second group were missing permissions.

I checked Azure AD and was able to confirm that all members of both groups were properly being placed in the parent group, so clearly the nesting itself was not the issue and there had to be something else going on. I started looking at the differences between the two nested groups and found that the working group was a mail-enabled security group, while the non-working group was not mail-enabled. Turns out that was the problem.

Evidently, Exchange 365 ignores group membership unless the relevant group is mail-enabled. It’s been a while since we had on-premise Exchange but I do not recall this being the case there. In any event, I added an e-mail address and proxy address to the problem group (in AD), and once things sync’d up to the cloud, the users had the proper permissions.

I was not able to find any documentation for this. Hopefully this post saves someone else the trouble of figuring it out on their own. If it does, or you have anything else to add, I’d love to hear from you.

MDT/ADK Issues – Path Not Found

Posted by James F. Prudente on October 12, 2022
Posted in: Deployment, Windows 10, Windows 11, Windows Server. Tagged: , , . Leave a comment

Brief but important warning here about Windows 11 ADK/MDT.

We recently ran into a corruption issue with our imaging server that led us to reinstall some of Microsoft’s imaging components including the Assessment and Deployment Kit and the additional WinPE extension. Naturally we went for the latest version, which as of this writing corresponds to Win 11 22H2 build 22621.

After the reinstall, we ran into an issue where we could not run scripts from within WinPE. I added the missing scripting packages to the deployment share, but every attempt to rebuild the WinPE media resulted in errors.

Deployment Image Servicing and Management tool
Version: 10.0.22621.1
Image Version: 10.0.22621.1
Processing 1 of 1 - Adding package WinPE-Scripting-Package~31bf3856ad364e35~amd64~~10.0.22621.1
[======                     11.0%                          ]
[===========                20.0%                          ]
[==============             25.0%                          ]
[=================          30.0%                          ]
[====================       35.0%                          ]
[=======================    40.0%                          ]
[========================== 45.0%                          ]
[==========================100.0%==========================]
An error occurred - WinPE-Scripting-Package Error: 0x80070003
Error: 3
The system cannot find the path specified.
The DISM log file can be found at C:\Windows\Logs\DISM\dism.log
Exit code = 3

I spent way too long trying to figure out why DISM was erroring trying to find a package file that was clearly available. Interestingly, Sysinternals Process Monitor did not show any file not found errors that seemed relevant.

Even more interesting was that the x86 WinPE image would build successfully with the scripting components. It was only x64 WinPE that failed while adding the additional packages.

I started looking at any obvious differences between the WinPE logs for x86 and x64, and one thing stood out: the version number for DISM and the WinPE image. The latest ADK shows x64 build 10.0.22621 but x86 build 10.0.22000.

Some quick research turned up this page which, in true Microsoft fashion, doesn’t quite tell the whole story. Per Microsoft, “The 32-bit versions of Windows PE are no longer included in the Windows PE add-ons starting with the ADK for Windows 11, version 22H2.” That doesn’t seem to be the case; although I didn’t install on a clean server to confirm, it looks like the 22H2 ADK still includes x86 WinPE components, just an older version.

Microsoft goes on to say that “The last supported version of 32-bit Windows PE is available in the Windows PE add-on for Windows 10, version 2004.” But that doesn’t seem to be accurate either. Win 10 version 2004 corresponds to build 19041, yet the x86 DISM included with the latest 22H2 ADK is 22000, which corresponds to Win 11 build 21H2.

At this point I had a path not found error that made no sense, and a version discrepancy that I also couldn’t explain. I wanted to try the 21H2 version of the ADK and see what happened, but Microsoft doesn’t list it for download on the page I linked above. Fortunately. I found a post by Prajwal Desai that included a link to the 21H2 ADK. Note that the download is direct from Microsoft.

I removed the 22H2 ADK and installed the 21H2 ADK. This gave me version 22000 for both x86 and x64 architectures. And perhaps not surprisingly at this point, the 22000 x64 build installs the scripting packages without issue.

So long story short, the 22H2 ADK is apparently bugged. Use the 21H2 ADK instead.

The Real-World Implications of PrintNightmare

Posted by James F. Prudente on August 23, 2021
Posted in: Group Policy, Permissions, Scripting, Windows 10, Windows Server. 1 Comment

PrintNightmare refers to a series of recent vulnerabilities in the Windows print spooler service. There are plenty of articles detailing the issues and Microsoft’s ongoing attempts to (partially) fix them. I’m not going to rehash any of those. What I do want to touch on is the real-world implication of Microsoft’s fixes.

Cutting straight to the point: The updates Microsoft released to fix PrintNightmare, which will of course be included in subsequent rollups, completely prevent non-admin users from receiving printer mappings through group policy and/or using the “internet printing” webpage to add printers.

Microsoft’s documentation does state that “non-administrator users will no longer be able to” “[i]nstall new printers using drivers on a remote computer or server” or “[u]pdate existing printer drivers using drivers from remote computer or server.” Unfortunately, because of the way the first statement is phrased, it isn’t as clear as it should be that standard users can no longer connect to a printer on a corporate print-server, unless they have the necessary driver pre-loaded.

I understand that Microsoft may not have many options for resolving the spooler vulnerability, but what they have pushed out is a fix that will make it quite difficult for IT staff to install printers on end-user PCs. For the many organizations out there using group policy, logon scripts, or other long-standing methods to connect printers to PCs, these updates broke significant functionality.

Unless you can quickly move to a new method of installing printers (System Center, Endpoint Configuration Manager, or a 3rd party platform), operational realities mean most of us are going to have to disable the security fix and make due with whatever other mitigations we can enable, such as limiting the servers from which a driver can be installed. It isn’t clear why Microsoft says that isn’t a full mitigation since end-user devices should be secure, as long as the print server itself is secure.

Aren’t you glad we’ve moved to a paperless office?

Office 365 Folder Naming Conflict

Posted by James F. Prudente on July 14, 2021
Posted in: Office 365. Leave a comment

I ran into what is either a nasty bug or an undocumented “feature” in OneDrive for Business recently.

Let’s say you create a OneNote Notebook named “MyStuff” and then create a folder in the same location as the notebook, also named “MyStuff”; OneDrive will allow you to do this and on the surface there is no reason it shouldn’t. I managed to do this inadvertently, and the first sign something was wrong was that the folder itself was completely invisible in the OneDrive UI, or in the modern file dialogs within the Office suite. It was however perfectly visible from the old-style Explorer file dialogs, and I could access files without a problem so long as I used the older dialogs.

The real problem started when I tried to rename the folder and lost the ability to access any of the files contained within. After some investigation, what I found is that because of the file and folder sharing a name, when it seemed to me that I was saving to the folder, I was actually saving within the OneNote notebook, as if it was a folder. Except that the files were not there if I opened the notebook itself.

I’m not even sure what I did to get the files back, as rather than documenting the recovery process I was busy questioning why I hadn’t just saved to my NAS.

It seems as if somehow OneDrive created something like a symlink between the folder and file, and renaming the folder broke that link. I can’t imagine that this is deliberate behavior but these days one never knows.

So long story short…don’t do this!

DHCP Registration of DNS Entries to an Alternate DNS Server

Posted by James F. Prudente on December 19, 2019
Posted in: Active Directory, Windows 10, Windows Server. 9 Comments

We are in the midst of a BYOD rollout, and one of the challenges we’ve faced is how to best provide DHCP services and DNS resolution to BYOD clients. On the surface these are not difficult items, but with BYOD you are inherently dealing with a variety of devices that are outside of your control, plus you obviously want them isolated from your production (secure) network. This implies a few things:

  • If you want BYOD devices registered in DNS, your DHCP server(s) will need to handle the registration and maintenance of DNS records.
  • A BYOD device that is behind your firewall yet physically isolated from production resources may need different DNS resolution than a domain-joined device. An example of this is a federation (ADFS) server; domain-joined devices connect to an “internal” ADFS server that does SSO, while non-domain devices need to connect to an ADFS proxy that accepts a manual login.

There are many posts about DHCP and/or DNS configuration, including how to handle DHCP registering DNS records. Rather than repeat anything, I’ll link to a few that I found helpful:

TechNet: Windows Server: Integration between DNS and DHCP

Ace Fekay: Dynamic DNS Updates…

Where things get a bit trickier (or perhaps less obvious) is when you want DHCP to register a client on a DNS server that is different from the DNS server assigned to that client. In our case, we want our BYOD devices registered on our Windows DNS servers, but the BYOD devices themselves need to query a DNS proxy rather than our Windows DNS servers.

We already had DHCP configured to register clients in DNS, but which DNS server? I could not find any reference for this, but based on packet captures and empirical evidence, this is what happens:

  1. DHCP queries the DNS server that is being assigned to the client for the address(es) associated with the DNS domain name in DHCP option 015
  2. DHCP then attempts to register the client on the address(es) returned by the prior query

Put another way…when DHCP offers a DNS server to a client via option 006, DHCP will query that same option 006 DNS server for the DNS Domain Name in option 015, in order to determine what DNS server the client should be registered on.

Long story short: the option 006 DNS server must have an entry that matches the option 015 DNS Domain Name, and resolves to the IP address of the DNS server where you actually want the clients registered.