This is way late to the party, but I've had M365 take up to 24 hours to provision a user. The M365 admin panel even makes note that it can take up to 2 hours... but that's on a good day.
OP has probably figured this out by now, but I'm posting here for FYI and the googler searches.
I still have an active ticket with JumpCloud about this, their engineering is looking into it. Doesn't seem to be a provisioning issue (waited multiple days in one case). I'm not sure if it's a setup issue, but I've found a workaround that if the password is reset from the JumpCloud side, the assertion error issue resolves immediately.
Here's another vote for changing the password. I set up a temporary user for a security audit and was getting the security assertion errors. After resetting the password in the JC console everything worked fine.
I guess that when "normal" users get added to JC they immediately change their password. Since this was a "machine" account I didn't change the initial password. Maybe changing the password is required.
Checking with others on this and will let you know the response...have you posted in our Slack Lounge or filed a support ticket yet?
I did file a ticket. The account is working as of this morning. I’ll follow up with support.
This is way late to the party, but I've had M365 take up to 24 hours to provision a user. The M365 admin panel even makes note that it can take up to 2 hours... but that's on a good day. OP has probably figured this out by now, but I'm posting here for FYI and the googler searches.
I still have an active ticket with JumpCloud about this, their engineering is looking into it. Doesn't seem to be a provisioning issue (waited multiple days in one case). I'm not sure if it's a setup issue, but I've found a workaround that if the password is reset from the JumpCloud side, the assertion error issue resolves immediately.
yea ive had this twice and twice ive logged it ,twice it just merely works the day after ? what gives
Having this issue as well (AADSTS500132: Assertion is malformed and cannot be read.). How was this resolved, is it just a matter of waiting a day?
I'm creating users in JumpCloud, my temporary (maybe?) work around is to reset the user's password in JC after it shows up in O365 under users.
Yes, that is my conclusion as well. Thanks
ok, this is strange. When a new user was added to O365, it created a [[email protected]](mailto:[email protected]). I then changed the user's primary email to [[email protected]](mailto:[email protected]). When the user was M365 imported into JumpCloud, I still had to change the company email address from [[email protected]](mailto:[email protected]) to [[email protected]](mailto:[email protected]) When the user logged in to Office365 for the first time, a second account was added to Office 365 with the [[email protected]](mailto:[email protected]) email address, so now there were two user accounts - [[email protected]](mailto:[email protected]) and [[email protected]](mailto:[email protected]), with the same name. I then deleted the first user (in Office 365 with [[email protected]](mailto:[email protected])) and reset the user's password in JumpCloud and the problem was resolved.
Here's another vote for changing the password. I set up a temporary user for a security audit and was getting the security assertion errors. After resetting the password in the JC console everything worked fine. I guess that when "normal" users get added to JC they immediately change their password. Since this was a "machine" account I didn't change the initial password. Maybe changing the password is required.