Microsoft

Update UPN from AD to Azure AD

When there was a name change in Active Directory (AD), we used to update the Universal Principal Name (UPN) in AD, then separately run the Set-MsolUserPrincipalName command to update Azure AD to the same UPN. Except, it no longer worked – I was now getting an ‘Access Denied’ message.

When trying to update the UPN via the Microsoft 365 admin center, it would correctly advise that the object was homed in AD, so changes needed to be made there. Except, they were, and Azure AD Connect was even reporting that it had seen the update and sent it off to Azure AD, no errors.

After some investigation, I found that there is now an option to allow ‘Synchronize userPrincipalName updates‘ which is off in older tenants. To check and update this:

In PowerShell, first install and connect to MSOLService. Then to check the status if UPN updates will sync and update:

Get-MsolDirSyncFeatures -Feature SynchronizeUpnForManagedUsers

If it’s $true, you’re already set. If it’s $false, update the value to $true with this command:

Set-MsolDirSyncFeature -Feature SynchronizeUpnForManagedUsers -Enable $true

In my testing, running another Azure AD Sync (both delta and full) did not resolve any already updated UPNs. I had to change the UPNs to a temporary value, sync, then change them back to the original value I wanted, and sync again. The update was instant in Azure AD once the sync had run each time.

SMTP to Exchange Online

SMTP is still needed by certain applications and devices, such as printers, which don’t support Modern Authentication and instead require legacy authentication to talk to a SMTP server.

You are able to use Exchange Online as an SMTP server, but this can be tricky to set up if you’ve hardened your environment by requiring Multi-factor authentication through Security Defaults or Conditional Access.

Microsoft have good documentation on “How to set up a multifunction device or application to send email using Microsoft 365 or Office 365” with the recommended approach to use SMTP, but you may need to poke some security holes through your environment.

Assuming you can get out through your firewalls on port 587 or 25 for SMTP, you’ll need to turn off Azure AD Security Defaults if you have them on. If you do this, understand what you’re turning off and rebuild those same settings in Conditional Access. If you have them off, then you should have Conditional Access policies already.

Personally, I have a ‘Block Legacy Authentication’ conditional access policy which as it says, blocks legacy authentication. For an account I want to send emails from via SMTP, I add it as an exception to this policy.

I then have a second policy ‘Allow Legacy Authentication Internal Only’ which I then target this user at, which still blocks legacy auth unless it’s coming from a trusted IP address. These two rules together then block all users from legacy auth, except the ones on the second policy, and then only if they’re coming from inside my network. The goal of this is to prevent anyone externally using spray attacks against accounts to gain a username and password – although they couldn’t log in anywhere beyond SMTP due to MFA policies, they could still start sending emails that would be from a legitimate email address.

If you have IPs restricted on Exchange Online connectors, that does not appear to affect SMTP auth and you shouldn’t need to add your internal IPs there.

The account you want to use for SMTP sending must have a mailbox license, I use ‘Exchange Online Plan 1’ for one of the cheaper options that is pure mailbox. The SMTP settings are listed here.

You also need to allow SMTP auth across your organisation (not ideal), or on a per account basis (much better security wise, plus it overrides the org default – so you can disable at org level and allow at account level). Microsoft Docs covers this in detail but the command (which requires connecting to Exchange Online via PowerShell first) to allow on a single mailbox is:

Set-CASMailbox -Identity sean@contoso.com -SmtpClientAuthenticationDisabled $false

Once these policies and licenses is in place, you can test. The easiest way I found was a 1 liner PowerShell command. You must use the source mailbox’s account as the from address:

Send-MailMessage –From account@contoso.com –To test@contoso.com –Subject "Test Email" –Body "Test SMTP Service from Powershell on Port 587" -SmtpServer smtp.office365.com -UseSsl -Port 587 -credential $madeupvariable

When testing, I found that after changing the Conditional Access rules to let a specific account go through as legacy auth took several minutes. Azure AD logs also take several minutes to show auth attempts, so don’t rush and change too many things at once trying to do this.

Ideally, nobody would be using SMTP – but in the real world we still have to, so the above will at least keep login records in Azure AD, and limit it to trusted IPs, certain accounts, or any other Conditional Access rules you can come up with to reduce the risk of allowing this.

PowerShell Slow to Load and AutoFill

I had this problem on a server for a while – when first launching PowerShell, it would take ~20 seconds or so to accept input. Also, when pressing tab to auto-complete a command, it would again take ~20 seconds to start, like it was freezing. These were one time problems when launching PowerShell, after that it would work fine until a new session was launched.

A lot of searching didn’t help me work it out, so I logged a Microsoft case. After a few task manager executable dumps, they worked out the delay was on a path I had in an environment variable. Somehow in my account’s user variable, I had a github desktop path that was mapping to a network share, using a PC name that was decommissioned (e.g. ;\\pcname\c$\Users\AdamFowler\AppData\Local\GitHubDesktop\bin.

I expect that this name was timing out, and PowerShell was waiting a while before giving up. In case you have the same symptoms as me, check the environment variables – user variables paths if it’s only your account affected, or the system variables if it’s all users. Click on the path value, then click edit, and remove anything that shoudn’t be there (take a backup of the text if you aren’t sure, it’s easy to put back in if you keep a copy).

To get to Environment Variables, depending on the OS version, get to System Properties, the Advanced tab, and then the Environment Variables button:

Hope that helps someone else with the same problem!

How to (really) factory reset a Poly CCX 500

Hi,

Quick one here, I was testing a few Poly CCX 500 devices for Teams Calling, and wanted to do a factory reset.

The official documentation says:

Procedure

  1. Disconnect the power, then power on the Poly phone.
  2. As soon as the Poly logo shows on the screen, press and hold the four corners of the LCD display. Note: It may take several tries to get the timing right or to find the correct spots to press on the LCD display.
  3. Release the LCD display when the Mute indicator on the lower-right corner of the phone begins flashing red, amber, and green.

However, I tried this many times without success. Doing large crab claw fingers to cover the 4 corners of the screen was doing nothing beyond hurting my fingers.

I ended up working out it was a timing thing, and the Poly logo shows twice. It will first show, then go to a black screen for a second or two, then re-show the Poly logo. If you press the 4 corners before the Poly logo comes up for the second time – nothing happens. You have to press the 4 corners of the touch screen straight away AFTER the Poly logo has come up for the second time. It won’t register if you do it earlier, and leave your fingers in the right place.

They actually have a video showing this correctly:

https://community.polycom.com/t5/video/gallerypage/video-id/6198164788001

Hope this saves someone time! I assume this is the same for CCX 400, CCX 600, Poly Trio C60 etc but haven’t tested those.

Note the default admin password for these phones is ‘456’ and you should be changing this, which is easily done automatically via a Teams Configuration Profile

Organization Branding for Safe Link Warnings

Two new little features have turned up for Safe Links as part of the Microsoft 365 Security & Compliance suite.

  • Display the organization branding on notification and warning pages

The first option is to show your organization’s branding on warning pages. This should help users identify that it’s a legitimate warning they’re seeing, as default Microsoft warning pages are often used by malicious actors to look legitimate themselves.

  • Use custom notification text

This lets you put a message that sounds like it’s actually from your own company when a webpage gets blocked. This means you can put in contact details or a process you want users to follow when they hit a site – which could be sending an email or calling helpdesk.

Here’s how the custom text and logo looks on a blocked page:

The custom branding will appear above this warning as a banner and a small logo for your company.

If you haven’t set up branding already, have a read on Microsoft Docs on how to do it for Azure AD and Microsoft 365 (do both!).