
Neomagora, hosted on Microsoft 365 SharePoint, centralizes schedules, notes, and absences for NEOMA Business School students. When the page refuses to load or loops on the login screen, the problem rarely stems from a forgotten password. The cause is most often related to session and cookie management by the browser.
Third-party cookies and SharePoint NEOMA authentication: the invisible blockage
Since 2024-2025, Chrome, Edge, and Firefox block third-party cookies by default. This change, designed to protect privacy, silently disrupts the Microsoft 365 authentication flow on which Neomagora relies.
Specifically, the SharePoint login page needs to exchange tokens between multiple Microsoft domains. If the browser intercepts these exchanges, the student sees a blank page, a redirect loop, or an access denied message, without a clear explanation.
The solution is to create explicit exceptions in the browser settings. In Chrome, open Settings, then Privacy and security, then Third-party cookies, and add two entries: *.microsoft.com and *.sharepoint.com. On Edge, the process is identical in the Cookies and site permissions section. Firefox uses a similar path through the enhanced tracking protection exceptions.
When a student tries to log in to Neomagora and SharePoint Neoma unsuccessfully after already resetting their password, this cookie unblocking step resolves the majority of cases.

Microsoft 365 account conflict on Windows: clean up before logging in
A NEOMA student logs in with their identifier [email protected]. The issue arises when another Microsoft account is already registered on the machine: an old internship account, a personal Outlook account, or the account from another school.
Windows remembers these accounts in a registry accessible via Settings, then Accounts, then Work or school access. A residual account can intercept the authentication request and redirect to the wrong SharePoint tenant.
Procedure for cleaning up stray accounts
- Open Settings, then Accounts, then Work or school access, and check the list of connected accounts.
- Disconnect any account that does not match the active NEOMA identifier (be careful with old internship or previous university accounts).
- Restart the browser, then attempt a new login on neoma.sharepoint.com/sites/myneomagora.
This check takes less than two minutes and avoids the classic loop where the browser tries to switch between two simultaneous Microsoft 365 tenants, causing an access error without an explicit message.
Private browsing and dedicated profile: two complementary strategies
When cleaning up accounts and cookies is not enough, private browsing provides a quick test. In private mode, the browser ignores active sessions and stored cookies, completely isolating the login attempt.
If Neomagora works in private browsing but not in normal mode, the problem is confirmed: an element of the usual browser profile is interfering. Two options are then available.
Create a separate browser profile for NEOMA
Chrome and Edge allow the creation of distinct profiles. A profile dedicated to the NEOMA identifier avoids any crossover with a personal account. This profile keeps its own cookies, sessions, and extensions.
The advantage over private browsing: sessions persist from one use to another. The student does not have to log in again each time they open the browser.
Clear the local DNS cache
In rare cases, an outdated DNS cache prevents the resolution of the domain neoma.sharepoint.com. On Windows, open the command prompt and type ipconfig /flushdns. On macOS, the equivalent command is done via the terminal. This operation forces the machine to query the DNS servers again and may unblock access that was failing for no apparent reason.

Microsoft 365 changes to watch for the 2026 school year
Microsoft has announced the removal of one-time password (OTP) authentication for SharePoint Online guests in summer 2026. The gradual shift to the internal B2B invitation model began in May 2026, with a complete withdrawal of old OTP links planned for the end of August 2026.
For NEOMA students, this change does not affect daily login via the @neoma-bs.com identifier. However, students who accessed SharePoint spaces shared by partner companies (group projects, internships) via an OTP link will need to go through a formal B2B invitation.
This change is likely to generate new error messages at the start of the school year, especially for students in alternating programs who navigate between the NEOMA tenant and that of their host company. Keeping a separate browser profile for each Microsoft 365 environment then becomes a useful precaution, not just a one-time fix.
The most effective reflex in the face of a Neomagora blockage remains to first test in private browsing. If the login works, the problem is local. Third-party cookies and residual accounts cover the vast majority of cases. Resetting your password is pointless as long as the browser environment is not clean.