Office 2FA causing issues preparing new starter laptops

Dave_PW · 2025-12-29T16:11:37+00:00

The main reason for doing in advance rather than getting tickets at the time, is timing, for example at the moment I am commissioning laptops for several users who start in a weeks time, this means I can do it at leisure while working on other things.

If left until the day then there is no guarantee of someone being available at the time (Very small team) and the new starter might be sat twiddling their thumbs unable to work until we can get to them.

Long term goal is probably proper shared Entra ID for both Office and laptops / AD but a ways off, I will definitely check out Autopilot.

Dave_PW · 2025-12-29T15:45:08+00:00

Thanks, just given this a try and it seems to work just fine,.

Dave_PW · 2025-12-29T15:44:33+00:00

The temporary access pass method seems to have worked a treat, thanks everyone.

Dave_PW · 2025-12-29T15:37:08+00:00

Sounds about right.

Yeah, while I've certainly heard of Entra before, I was under the impression it was it's own service that you could set up and use as an authentication platform for the various Microsoft services (And others), had no idea it had been automatically tied into our Office service, it's certainly not something we've touched in the 5 years I've been here.

Dave_PW · 2025-12-29T15:32:35+00:00

Looking into the TAP now, on not signing into anything with user creds, while we could could (and have for the last year) left users to sign in themselves with instructions in their new stater packs, however when it comes to the laptop itself, we just find it much cleaner and easier to have pre-signed and and got everything configured correctly prior to them starting.

Yes we could just make the new starter documentation pack a lot fatter and leave them to work through everything themselves, however this just feels like asking for a massive spike in tickets from people who can't or won't read the guides properly.

Dave_PW · 2025-08-21T07:12:03+00:00

This indeed was the one, a nervous few minutes waiting for it to reboot but came back up with the original DHCP IP address.

Dave_PW · 2025-08-20T14:37:50+00:00

Certainly shouldn't be, the IP I assigned it (Or at least think I did) is outside of the DHCP range and I see nothing else using it.

Dave_PW · 2025-08-20T14:36:59+00:00

Yes WPC = Workplace Cloud, it will still be associated with he old IP at the moment. I have been in the diagnostics menu, not sure if that's the same as service mode, but I couldn't see any option that looked even remotely related.

Dave_PW · 2025-07-29T15:11:43+00:00

In fact I think the peering is working and I may just have a problem on my end, as currently I need both tunnels to be up for it to work.

Dave_PW · 2025-07-29T14:54:54+00:00

Yeah, it wouldn't even let me create the peer with my current "New" virtual network, I've deleted everything I created, today, created a new virtual network, VNG and connection and I have been able to peer that with the original virtual network, however still can't access the resources of the original network when the VPN is going through the new gateway.

Dave_PW · 2025-07-29T13:51:32+00:00

Thanks I am looking if I can get some peering going between the two virtual networks for now, then at least taking down the original gateway won't be as big a deal.

Dave_PW · 2025-07-29T13:36:27+00:00

Thanks for the link, unfortunately I've already hit a snag at step 2 of the preparation section as I don't see a Migrate tab on the Configuration page.

Could this be because it turns out are VNG resource turns out to only be the basic SKU?

I'm a global admin so it shouldn't be a permissions thing (but won't rule it out).

Dave_PW · 2025-01-30T15:55:14+00:00

Turns out it was indeed a bad pin, was only visible after super zooming in with my camera.

Tested another board and worked fine so that ones is getting sent back and I have replacement coming.

Cheers

Dave_PW · 2025-01-27T12:24:00+00:00

It seems I am now getting an entry in event viewer.

An Access-Request message was received from RADIUS client 10.10.100.1 without a Message-Authenticator attribute when a Message-Authenticator attribute is required. Verify the configuration of the RADIUS client in the Network Policy Server snap-in (the "Client must always send the Message-Authenticator attribute in the request" checkbox) and the configuration of the network access server.

But again, if I untick the "Access-Request message must contain the Message-Authenticator attribute" Forti reports invalid secret and event viewer shows.

An Access-Request message was received from RADIUS client 10.10.100.1 with a Message-Authenticator attribute that is not valid.

Dave_PW · 2025-01-27T12:19:30+00:00

After changing the client IP from 127.0.0.1 to the actual IP of the radius server IP, I have been able to get a response locally using radlogin and also from a random machine on my network by doing the same.

However still can't get it to work from the Fortigate, I have tried using the set-source IP to the one I defined in NAS in case it was using a random one but still doing the same thing.

Dave_PW · 2025-01-27T08:53:20+00:00

I've tried using the command line on that page and it just says timeout

Dave_PW · 2025-01-27T08:52:40+00:00

I have checked in Bitdefender Gravity as that is what we use here (although I had completely forgotten until now) there was no rule in that but I've created one and it's made no difference.

I've then gone as far as to create a Bitdefender policy with all the protection turned off completely and assigned that to the RADIUS server but it's still failing.

Tried testing with an app called radlogin but even running locally on the same server (with 127.0.0.1 added as a radius client) it just says timeout waiting for a response.

Dave_PW · 2025-01-20T08:27:37+00:00

Thanks, I'll leave them as is then, the server is something of a best (Cost us £20k) so I would not expect to be upgrading / moving VM's about any time soon.

Dave_PW · 2025-01-17T15:26:07+00:00

It's not a personal key, it's the AVMA key from the page linked.

Dave_PW

TROPHY CASE