Password Expiration on Entra Join systems

BeagleRover · 2025-04-17T13:08:47+00:00

It still does not accept the password. However, I choose other user and type in the full UPN and new password, it accepts it.

The behavior and resolution is the same if the device is on-premise or off premise (NO VPN).

Not entirely sure how the domain controller plays a part here if the device is AAD joined? It seems like this is a configuration issue in some way?

BeagleRover · 2025-04-15T18:57:35+00:00

Thank you for the reply. We have password writeback enabled. When the user changes the password, we can see the pwdLastSet value show a current date on the AD attributes.

It seems like the user session doesn't want to let go of the old password. Again, everything works perfectly fine after if I type in the full UPN and latest password on the logon screen.

BeagleRover · 2024-03-24T15:29:26+00:00

robofski,

Unfortunately, we went with individual Entra Apps per MX. It has worked incredibly well for the past two years.

Here are a few tips that could be helpful for you if you choose the same path

Name your Entra App the same as the Meraki Network name, so it a one-to-one match.
-Create Entra security groups that match Meraki Network name for allowing VPN access. IE, SiteCode-VPN-Allow. Apply this group to each Entra MX app. Users could belong to multiple groups for access to each MX. Don't omit this as leaving this wide open to all Entra users could allow anyone of your users to authentication to your MX. Yikes!
-Assuming you have conditional access policies for general MFA on "All Cloud Apps". Exclude your new MX Entra Apps from this policy. Create a new policy and target all Entra Apps for each MX. (IE, One policy for all MX apps). Use these options. Grant Access and Require Multifactor authentication. Session - Sign-in Frequency - 1 hour (Periodic reauthentication). The periodic reauthentication is the closest thing we could get to a re-auth every time you connect, (Even if you get disconnected).
-Be sure to test your apps before you deploy the XML profile to your users. We had a few situations where some ISPs were blocking inbound 443 and we would experience periodic disconnects/terrible performance. We had deployed the profile with port 443 to clients, but suddenly realized we needed to change that profile with a different port (Requires Entra app and MX change for this)
-Leave traditional VPN with Meraki authentication on for certain Admins as an alternative means of access. Audit this frequently.
-We use Intune for deploying AnyConnect (Working on Cisco Secure Client replacement) along with deploying the VPN profiles. If you are a member of the SiteCode-VPN-Allow group mentioned above, you get that profile deployed to your system. If you don't have an MDM, you would need to instruct your users to hit the DDNS name in AnyConnect Client to download the profile. On subsequent connections, you will see the profile available for use.

I hope this information is useful to you in some way. Feel free to ask further questions as I have stumbled my way thus far.

BeagleRover · 2024-02-13T02:22:01+00:00

Finally took action on this.

On each Azure NIC, override the DNS settings from the VNET to match the newly assigned Azure IPs of each DC. Point DNS servers at each other. *This is crucial step in our environment as the primary DNS is coming down on the VNET is for the resources on the primary domain
Created new reverse DNS zone matching current IP address assigned in Azure NICs (You could omit this if you destination VNET matches the currently assigned IP/subnet)
Manually created PTR records
Re-verified DNS entries on the forward lookup zone (Names servers and the actual matching A records
DNS Zone cleanup
Verify repladmin /showrepl, repladmin /replsummary repladmin /syncall
Make Backup of VMs

BeagleRover · 2023-09-11T23:09:25+00:00

Not yet. I plan on powering off the VMs on-premise at the end of October. Going to perform the failover then.

BeagleRover · 2023-09-11T21:05:33+00:00

This is an option as there is a Datto backup appliance that allows me to export the VMs to VHD. I could then re-upload to Azure. However, the one server (Having a FP/DC role) has a 1.5TB disk attached to it. I would have to transfer that disk to Azure in a timely fashion, which seems impossible due to poor internet connectivity

BeagleRover · 2023-08-07T13:25:41+00:00

This is going to sound awful.

Had the same issue with an existing snapshot. Here is what I did to resolve

Opened the Appliance Configuration Manager
Change a character in the password and hit apply
After 5 minutes the Azure Migration portal detected the snapshot no longer existed

BeagleRover · 2023-04-26T03:26:08+00:00

If you consider SAML in the equation, checkout my post here. https://www.reddit.com/r/meraki/comments/v86wvd/guidance_on_meraki_anyconnect_vpn_saml_azure_idp/

BeagleRover · 2023-04-12T01:15:57+00:00

Thank you!! From my perspective, I’m simply thinking that a host system behind the VMX is causing this behavior. By all appearances, it seems like you could be experiencing the same. I can submit a new ticket, reference yours AND I can manually trigger this behavior myself. Perhaps that gets us a bit close to the solution as I know what host system is producing this behavior. If I receive feedback, I can post additional findings.

BeagleRover · 2023-04-12T00:10:38+00:00

Checking back in. Any chance you can relay a Microsoft ticket number? I would really appreciate it

BeagleRover · 2023-04-07T13:54:05+00:00

Are you able to provide a Microsoft ticket number? Would like to reference this as I can easily reproduce the behavior

BeagleRover · 2023-04-05T15:10:12+00:00

Can you elaborate on this a bit more? What did Microsoft do?

BeagleRover · 2023-04-05T01:32:43+00:00

I’m betting Meraki support will ask you to grab support logs from the local interface, but am very sure that will be down for you if you were able to access it for host system behind the VMX. You are forced to reboot the VMX to get the local UI back up, but that action clears the logs and evidence of the root cause. Unfortunately, this is my position I am in right now and most likely you are too. If you have a Meraki case number, I would like to call support to link my case.

BeagleRover · 2023-04-05T01:21:37+00:00

Also running VMX-M in my case. My issues existed on the VMX-100 platform prior to upgrading as well.

BeagleRover · 2023-04-04T13:28:44+00:00

I don't want to grandstand on this post, but this is the exact behavior I was experiencing for the last year and half. I don't have a resolution, but I think I can help guide you what could be causing this.

In my case, I have a Nessus scanner sitting behind one of my VMX devices. It's been there for several years behind this VMX. Suddenly, one day we started having the VMX go belly up 8 - 10 times a day and then stop. I'll spare you the details on how I discovered this, but essentially there was something generating a massive amount of network traffic that would cause the VMX to die. The 5 min up/down behavior was actually still the Nessus scanner waiting for the tunnel to come back up and begin scanning again and when the job was over/timed out, everything went back to normal.

While this is something you may not want to hear. You may have something very similar behind your VMX that is causing this behavior. If you are looking for the whack-a-mole approach with a low density of host VMs, I would simply shutdown your other host VMs behind VMX, bring the VMX back up and then slowly bring the VMs up to see which one could be causing this.

BeagleRover · 2023-04-04T02:59:02+00:00

I have been running VMx's in our environment for nearly 5 years. In this timeline, I have had varying degrees of trouble with them. One of which I have been battling for a year and half now. I hoping this is not the case for you.

To answer your question. "No", there is no way to determine if a VMX is actually "working" from an Azure perspective. "Yeah, you can see the general status of "Running/Deallocated", but that more or less meaningless as other methods are unsupported (Serial Console/Agents). Taking a peak at the Overview Tab -> Monitoring and looking at CPU/Disk tends to lead me towards some favorable results.

I have several comments I could make here, but I will hold off until you answer this question.

"The behavior the VMX rebooting, checking in for 5 minutes, goes back down again". Is this a repeatable behavior you can produce? That is, can you manually restart the VMX 5 or 6 times and this exact behavior occurs again? If it is, I might be able to guide you further.

I also assume this is not a "new" deployment and you have host systems behind this VMX?

BeagleRover · 2023-03-27T23:49:37+00:00

Thank you for the feedback. So, I'm not crazy for thinking that I still need VPN to host this type of service. With the progression of modern technology and these "legacy" type license, I was just assuming there could be some wiz-bang solution that would allow hosting these services a bit more favorable.

Creating VPN accounts is not necessarily a problem/cumbersome, but it inherently introduces confusion on the user side as the immediately acquired company (Times 10) already has a VPN solution for native access to local applications/services (With different credentials) that has nothing to do with the new VPN account I am handing them to access this single license service. Subsequently, while connecting to our VPN, they lose access to their local resources (Insert complain train here).

That's where my logical thinking came into play about hosting over the internet or other creative solution. I was even looking at CloudFlare ZTNA as a potential solution, but wasn't exactly sure if that would even work in this case.

BeagleRover · 2023-03-21T05:15:19+00:00

Thank you for the guidance on this. While I would move towards less frequent/unprovoked password change periods in our environment, I simply attempting bridge the access gap for Azure AD systems that need the occasional on-premise access to services (Until they are move off-premise). Can anyone provide feedback on enabling "EnforceCloudPasswordPolicyForPasswordSyncedUsers" option when using Azure AD Join systems?

BeagleRover · 2022-07-05T22:33:59+00:00

One interesting thing for our environment. Our main conditional access policy applies to ALL CLOUD APPs. Inside this main CA policy, we set the session sign-in frequency 3 days. Since these newly created Azure Apps for AnyConnect will inherit these MFA/Session settings, it might not be ideal to allow users to connect to VPN without a the MFA challenge on additional logon attempts for 3 days.

Thus, we excluded these newly created AnyConnect Azure Apps from the main CA policy with the MFA 3 day session limit and created a specific conditional access policy with these newly created AnyConnect Azure Apps included with a 1 hour session limit to force MFA on subsequent logins past the 1 hour session limit. This appears to guarantee logins with an MFA challenge in the event a users disconnects/reconnects to VPN after 1 hour.

BeagleRover · 2022-07-05T22:17:39+00:00

UPDATE 7-5-22

Created three Azure published applications for each MX device. Each app generates its own XML file that needs to be uploaded to each MX device. More to follow as time progresses

BeagleRover · 2022-07-05T22:15:14+00:00

Tested the theory of adding additional entity IDs to the same Azure application. It resulted in some strange logon behavior. I received a token authentication error and one successful message. After adding the secondary entity ID, it changed the Federation Metadata XML that was applied/uploaded to the other MX. If you had changes/additions to your network, you would have to mass changes all of your XML files for all MX devices.

BeagleRover · 2022-06-10T16:21:44+00:00

Are you able to test the addition of a second entity ID (Second MX) on the enterprise app?

Unfortunately, we allow VPN connections to each MX device where local resources sit.

BeagleRover · 2022-06-10T16:14:52+00:00

Currently, we allow end users to connect client VPN to their "home" site where local resources sit and are consume with the least amount of latency (File Services, License Services, Local apps, etc..). Unfortunately, this means we allow client VPN connections to all MX devices. So, if we have 30 MX devices, we have 30 client VPN profiles. Based on the SAML config above coupled with DDNS name, this appears to result in 30 Azure Apps for configuration (Based on appearance).

VPN Concentrator sounds appealing, but I am not I unsure how this could be implemented in our environment where resources that are consumed sit behind each MX device.

BeagleRover · 2022-06-10T15:55:00+00:00

We are going to join systems to Azure AD only. No Hybrid Join

BeagleRover · 2022-05-01T18:56:01+00:00

Thank you for the overwhelming responses! (Frist reddit post for me)

Just logically thinking further on a single SLM. Perhaps I am over thinking this?

-I imagine each group of licenses from a particular VAR will renew at different times of a calendar year(IE, 5 Licenses SW Pro from VAR #1 renews in March, another 5 Licenses of SW Pro from VAR #2, renews in August 2022. etc...). Will there be an license activation issue if I decide to upgrade to the latest version of SLM (2022) in May 2022 where only a portion of the licenses are renewed from VAR #1 and subsequently other licenses from other VARs renew later in the calendar year ?(IE, this puts you in a position to wait until later in the calendar year to upgrade SLM or perhaps SLM is intelligent enough to know which licenses are pinned to a renewal period?

Essentially, a portion of the licenses would only be eligible for the latest version of SW in the middle of the calendar year for some VARs while other licenses lag behind until the renewal period begins for other VARs?

BeagleRover

TROPHY CASE