Category Archives: Azure

Creating group-based GPO without requiring a logoff/logon to take effect

As part of piloting O365 I was tasked with implementing hybrid modern authentication in our Exchange org in order to leverage functionality like the Outlook mobile application and MFA within the Windows version of Outlook for on-prem mailboxes. One caveat of enabling hybrid modern authentication in Exchange is that once this is flipped on any compatible client (ex. Outlook 2016) will begin using modern authentication (ADAL) exclusively by default. This switch can potentially be disruptive and we did not want to run into issues with the general user base. To do this we needed to disable modern authentication in Outlook on the client-side while being able to selectively enable it for certain users. This is easily handled with a ‘EnableADAL’ registry setting via GPO/Group Policy Preferences (GPP)/AD group. The issue is when you use an AD group with a group policy any member addition/removal needs to be coupled with a logoff/logon (or a reboot if it involves in a computer object in an AD group) to generate a new Kerberos token. I wanted to be able to quickly enable/disable ADAL for a user without requiring them to logoff/logon.

In order to get around this requirement I used GPP targeting with an LDAP query that looked for the group membership rather than standard group membership check. This LDAP query is completely dynamic and isn’t tied to the group list in user’s Kerberos token.

To do this you can do the following:

  • Create your GPP setting
  • Enable ‘Item-level targeting‘ on the setting
  • Create a new ‘LDAP Query‘ item
  • Create your filter using the distinguished name of your AD group and the ‘%LogonUser% variable
(&(objectCategory=user)(memberOf=GROUP DISTINGUISHED NAME)(sAMAccountName=%LogonUser%))
Create LDAP Query
Create LDAP Query condition
Retrieve group distinguishedName

This method could also be used for traditional GPO settings as well, but you’d have to use GPP to directly target GPO registry value(s) (ex. HKCU\Software\Policies\Microsoft\Windows\Control Panel\Desktop – ScreenSaveActive=0/1). This method could also be used for computer-based settings, but the LDAP query would have to be adjusted to target a ‘computerobjectCategory and the name of the computer (%ComputerName%). I wouldn’t use this method for everything, but can be very helpful for those one-off situations where you want a setting to take effect immediately without requiring a logoff/logon or reboot.

FAILED_TO_AUTO_DISCOVER_DOMAIN – Teams Admin Console

I recently started working on an O365 pilot/implementation and had issues getting into the Teams Admin Console. Even after making sure a license was applied to my admin account I was still receiving this error:

Sorry, we can't sign you in.

The domain you are trying to sign in to doesn't have any users that have a Microsoft Teams or Skype for Business Online license assigned to them. Learn more

...

Error Code: FAILED_TO_AUTO_DISCOVER_DOMAIN
Tenant ID: xxxx
Correlation ID: xxxx
Timestamp: 2019-06-18T13:14:35.0463597Z

This wound up being an AutoDiscover issue with the domain my account was using. This can be verified by going to https://webdir.online.lync.com/Autodiscover/AutodiscoverService.svc/root?Domain=yourdomain.com. When AutoDiscover was not working the output was:

<reason xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/rtc/2012/03/ucwa" reasonid="0">
<code>NotFound</code>
<subcode>None</subcode>
<debugInfo/>
<parameters/>
</reason>

I had to enable, disable, AND re-enable the domain using the LyncOnlineConnector PowerShell cmdlets:

  • Import-Module LyncOnlineConnector
  • $Session = New-CsOnlineSession –UserName ‘AdminAccountUPN‘ –OverrideAdminDomain ‘AzureADDomainFQDN’ (Azure domain will be *.onmicrosoft.com)
  • Enable-CsOnlineSipDomain –Domain ‘DomainOfAdminAccountUPN
  • Disable-CsOnlineSipDomain –Domain ‘DomainOfAdminAccountUPN
  • Enable-CsOnlineSipDomain –Domain ‘DomainOfAdminAccountUPN

After doing the above I was able to go to https://webdir.online.lync.com/Autodiscover/AutodiscoverService.svc/root?Domain=yourdomain.com and get a proper output:

<resource xmlns="http://schemas.microsoft.com/rtc/2012/03/ucwa" rel="root" href="https://webdir1b.online.lync.com/Autodiscover/AutodiscoverService.svc/root?originalDomain=domain.com">
<link rel="xframe" href="https://webdir4a.online.lync.com/Autodiscover/AutodiscoverService.svc/root/xframe"/>
<link rel="redirect" href="https://webdir4a.online.lync.com/Autodiscover/AutodiscoverService.svc/root?originalDomain=domain.com"/></resource>

Azure AD Connect mail-enabled public folder synchronization issues – The cause of the error is not clear

We recently went through some Exchange Online Protection (EOP) cleanup and part of that involved turning on Directory Based Edge Blocking. We already went through the exercise of syncing all objects (especially ones part of Exchange), but the only ones that weren’t being synced were mail-enabled public folders. After turning on Directory Based Edge Blocking we realized there were a few public folders that needed to receive mail from the Internet. After syncing mail-enabled public folders (this is a newer feature in AD Connect) we received synchronization errors for four objects. The only thing these objects had in common was that they referenced a mail-enabled public folder by either having that object as a group member or having it as a forwarding object on a mailbox.

The errors we receiving were:

  • The cause of the error is not clear. This operation will be retried during the next synchronization. If the issue persists, contact Technical Support.
  • IdentityDataValidationFailed

The workaround is to create a mail contact object that has the same targetAddress as the mail-enabled public folder object and use that object in place of the public folder object in something like a group membership. The issue with this is that by design a mail contact’s targetAddress is also part of its proxyAddresses attribute and the mail-enabled public folder object of course already has the email address as part of its proxyAddresses attribute. This duplicate is not allowed. The way around this is to modify the mail contact object so that the targetAddress is not part of proxyAddresses. To create this special mail contact you do the following:

  • Create a mail contact in Exchange with a fake external address
  • Disable e-mail address policy for the object
  • Use ADSIEdit to:
    • Change the targetAddress to the email address of the mail-enabled public folder
    • Remove the fake external address you specified earlier from proxyAddresses

After the object has been created you can now use it in lieu of the mail-enabled public folder in group memberships and other attributes.