Office365 and MFA - Excluding internal

[Simcfc73]

Hi,

 

I've just been on the phone to M$ who says the only way to not prompt for MFA verification in Outlook 2016 is to use a app password.

 

Is this correct, I've found the IP settings for disabling internal clients but our IP changes on our firewall changes when we reboot.

 

I've also read about conditional access but don't think that's the way forward either.

 

Any advise/help would be super.

[Davit2005]

Who supplies your Internet connection? Do they not give a Static IP?

[Simcfc73]

BT, I pay for statics too but they are aliases on my connections (I have 2 Fibres)

[chaplic]

Lousy advise from Microsoft. And wrong.

 

There’s a few options here.

 

I’m a little confused about you saying you have static IPs but they change on firewall reboot? Adding Trusted IPs (not a 10.something or 192.something but the real IPs the internet sees) to the azure AD portal is the easiest way if they are static or shared with a known community

 

Alternatively if you are using ADFS we can use a ‘insidecorporatenetwork’ claims rule.

 

Finally we can turn *OFF* MFA per user and use conditional access to turn it on when you are are external, but that’s possibly not needed.

 

I would first look at Trusted IPs in the azure ad portal as the first option.

 

If you never want to require MFA on trusted device you can allow a long keep me signed in value, or use azure ad hybrid join to mark trusted devices.

[Simcfc73]

Cheers, I was getting a bit confused and added the wrong address from my SW box. I've got a Gateway IP and a Local IP on my SW interfaces as well as my statics I bought. When I do a whatsmyip I am getting one of the assigned Local IPs not my statics.. this is what changes when it dials up again.

[chaplic]

So you are not using your static IPs to access the internet? Trusted IPs is the easiest way to avoid MFA prompt when internal.

 

If you Azure ad hybrid join your devices (win 10 on 1803 vastly preferable) then those devices can be configured never to prompt for MFA.

 

Do you have an ADFS server?

[Simcfc73]

No I'm using azure AD connect. It seems to be working now but I've never configured Smoothwall to use my statics to connect to the internet, I've always let it use my assigned IP's. I have 2 fibre connections so not sure how I'd work that out. My migration coincided with BT fixing one of my lines so they connection was up and down for a couple of days before it settled so its probably going to be okay now.

 

I've migrated 120 mailboxes now so almost there.

 

Issues I am having now are.

 

I stupidly didnt renew my azure MFA licesning so the new starters cannot be assinged a MFA license until its cleared (including the new head.. oops). I disabled it but I've set it up to assign licenses based on AD group membership so when it resyncs it reassigns him to use MFA... which isnt licensed.

Clients who've setup outlook on their devices arent moving to the new Outlook365 servers, having to tell them to delete the account and create it again.

 

The biggest issue is I'm getting 503 errors when autoconfiguring outlook with the new O365 settings on some machines. Its bypassing the MFA prompt correctly but a popup box appears similar to the MFA prompt and shows a serice is unavailable.. when I look in SW logs its a 503 error when trying to connect. SW's solution is to change the autodiscover to port 80 rather than 443 but I'm struggling with a fix.

 

I'll look at joining computer to azure and see if that helps.

[chaplic]

Forget azure ad domain join right now, I fear that’s another layer of complexity you don’t need when you have basic issues.

 

Assuming you’ve moved the mailboxes using the standard ms route and azure ad connect is working, you do not need users to reconfigure outlook.

 

Something is definelty not right with autodiscover. I would raise a support ticket through the admin portal, this should be basic stuff for them.

 

Symptom: when I move a mailbox outlook does not automatically right connect. Suspect autodiscover, dns or azure ad connect issue.

[Simcfc73]

Its only been reported by a few users. Internally the autodiscover does change outlook...it just messes up with the mfa prompt.

[chaplic]

Ok, we’re trying to fault find about a dozen things here so let’s try narrowing it down

 

Go to http://aad.portal.azure.com login and click on azure active directory, click on users then MFA link.

 

 

Click on service settings

 

Bash your IPs (your static and your current IP) into the skip multi factor authentication... box

 

The tick box about intranet is only useful if you have adfs.

 

Give this ten-fifteen minutes

 

Now MFA shouldn’t be messing with us. Don’t quote me on this, but I don’t think for just o366 you need a license for MFA (azure P1 etc). Just for o366 you get MFA out of the box. But I try my hardest to stay ignorant of o365 licenses as it’s auch a pain :-)

 

Can you do an autodiscover test from outlook (both internal and external) and share (you may wish to obsfucate or PM it)

[Simcfc73]

I've narrowed it down to a network issue. The skip MFA for internal is all working now (a couple of blemishes) but its working.

 

What I've found is, if the netowrk icon in the bottom right is showing no internet connection (even though there is) then the popup fails and I cannot log in. If its saying connected to.... then autoconfigure works and all is perfect. So I need to work that out.

 

I've seen the couple of articles on here so am working through those.

 

Thanks for the help.

[jwb503]

The no internet connection indicated despite it working fine rings a bell. We had problems opening online Office documents locally which was caused by this (amongst other things).

 

Turned out to be the winHTTP proxy setting hadn't been configured correctly on affected machines. Running netsh winhttp>show proxy in cmd should give you the current value.

[nicholab]

Please could you explain how you are turning off MFA inside school are you using Azure P1?

 

Lousy advise from Microsoft. And wrong.

 

There’s a few options here.

 

I’m a little confused about you saying you have static IPs but they change on firewall reboot? Adding Trusted IPs (not a 10.something or 192.something but the real IPs the internet sees) to the azure AD portal is the easiest way if they are static or shared with a known community

 

Alternatively if you are using ADFS we can use a ‘insidecorporatenetwork’ claims rule.

 

Finally we can turn *OFF* MFA per user and use conditional access to turn it on when you are are external, but that’s possibly not needed.

 

I would first look at Trusted IPs in the azure ad portal as the first option.

 

If you never want to require MFA on trusted device you can allow a long keep me signed in value, or use azure ad hybrid join to mark trusted devices.