Monthly Archives: July 2023

Using Ubiquiti switches and Mitel phones with PC port passthrough on different VLANs

Phones, , , ,

A while back I wrote a article about doing this with a older Dell switch but recently needed to do the same thing using a Ubiquiti switch. With a upcoming phone system upgrade I will be changing out about 130 old digital phones to IP phones and a lot of the cubicles don’t have extra Ethernet ports. So I will be using the 1Gb passthrough port on the new Mitel 6930w phones. But to keep everything separate the phones will be on one VLAN and the PCs on another. Configuration within the UniFi ecosystem is a lot different then command line Dell switches, personally once you get used to it I think it’s a lot faster and easier.

Like in the other article the user/PC network is VLAN 10 (10.40.10.) and the phones are on VLAN 20 (10.40.20.). First the setup within the UniFi Network software where you define custom ports (Settings -> Profiles -> Ethernet Ports -> Create New):

  • Name: Phones (Tagged) with User Passthrough (Untagged)
  • Primary Network: VLAN 10 Users
  • Traffic Restriction: All other VLANs except for VLAN 20

Save that profile then go into a switch where you will be plugging in a phone. In the switches Port Manager go to a port you will be using this on, select it, then scroll down to Advanced and switch it from Auto to Manual. You can now check the Feature box for Ethernet Port Profile and select your profile. Note that with the newest UI what this really is doing is manually setting the port profile above for you. So you can do this without setting up custom profiles but doing it this way is easier and personally quicker to see whats going on.

Now that the switch is setup you modify DHCP just like in the previous article by adding a Mitel specific Option 43 to both VLANs. First we will add the option on the Users VLAN 10 to tell the phones to switch over to VLAN 20:

id:ipphone.mitel.com;vlan=20

Then add Option 43 to the Phones VLAN 20:

id:ipphone.mitel.com;sw_tftp=(serverIP);call_srv=(serverIP);l2p=6v6;vlan=20;dscp=46v46s26

And your done. The phone will boot up and send it’s initial DHCP request untagged which the switch will tag as VLAN 10. DHCP will get this and option 43 will tell the phone to switch over to VLAN 20. It will, reboot, and then make another DHCP request tagged with VLAN 20. It will then get the correct server info. Any computer you plug into the passthrough port will get tagged by the switch back to VLAN 10 and everything should work together which keeping the traffic separate.

Need Password prompt in Outlook after clearing everyone’s sessions

Exchange Server, , ,

Long story short one of our vendors got hacked and sent out a phishing scam email using a SharePoint link and session hijacking that was able to bypass MFA. One of my users, who was waiting on a quote from this vendor, clicked it and entered their credentials. A week later their email was used to send out the same phishing email.

We followed the recommended Microsoft steps to clean things up. I did a content search on his account to see what he sent out and then emailed everyone letting them know it was a phishing attempt and if they fell for it they should reset their own passwords and contact their IT people. I then sent out a internal email saying if anyone clicked on the link they also need to change their password and to remind everyone about phishing emails. Then to be extra careful we forced a logout of all 365 sessions using PowerShell:

Connect-AzureAD
Get-AzureADUser | Revoke-Azureaduserallrefreshtoken

Which should have been the equivalent of going into the admin center on each user and clicking “Sign out of all sessions”. We told everyone that they might have to re-login to things and to reboot. Then followed up with some exports of everyones inbox rules, forwarding rules, etc, to make sure no one else was affected. It was a super fun Friday afternoon into evening.

The following Monday 95% of our users are completely fine, no issues, everything works. 5% of our users are getting the “Need Password” prompt at the bottom right in Outlook right after it finishes syncing all folders. If they try to get to public folders, other mailboxes they have access to, etc Outlook hard locks for a couple minutes and then connects and looks fine. Opening up the “Outlook Connection Status” during this time and you can see under status it saying “Connecting….” for each one then disconnected, over and over until it figures it out and connects. But then will go back to Need Password after a couple minutes. But if you simply click on where it says “Need Password” as soon as it pops up it connects the user with no other issues and works fine. So they were operational but with a annoying work around.

So I search google and the majority of things tell people to set a couple of registry keys which Microsoft has a entire article about not doing. Instead I followed the steps in that article which didn’t help at all. Tried the Microsoft support assistant for this issue, also didn’t work. Then moved on to having users change passwords and reboot, disconnect their accounts under “Access work or school” and reconnect, delete the Outlook profile and recreate, etc. All the standard Outlook is broken things to try but nothing seemed to work.

Well it turns out Microsoft put out a advisory that users with a Online Archive in a Exchange Hybrid setup were having trouble if the Autodiscover URL was pointing to the on prem server. So it ended up being a really bad coincidence. But this got me thinking why do I need to point Autodiscover to the on prem server at all if 100% of our mailboxes are migrated. It’s just a extra unneeded step which at best adds a little time to autodiscover compared to going directly to Microsoft and at worst if our internet or Exchange is down could prevent users from connecting.

Time to change that. I deleted my internal DNS autodiscover HOST record and put in a autodiscover CNAME record pointing to Microsofts autodiscover.outlook.com. Did the same for my GoDaddy DNS record. Once that was done I removed the SCP value from the internal server:

Get-ClientAccessService | Set-ClientAccessService -AutoDiscoverServiceInternalUri $Null

Flushed DNS on my own computer, rebooted, and verified Outlook connected without issues. I then updated the SRV records to also point directly up just in case in DNS under Domain -> _tcp -> _autodiscover and pointed that to autodiscover.outlook.com.

It’s now been like this for a couple months with no issues and since we have 0 mailboxes hosted locally there is no reason not to go directly to Microsoft for autodiscover.