Password creation, reset and activation flows were restored by correcting contact records, verifying outbound delivery and resending fresh one‑time tokens or performing authoritative resets at the IdP or application side. Technicians repaired mistyped, outdated, concatenated or malformed contact fields and, when institutional mailboxes were inaccessible, delivered resets using alternate external addresses (for example Gmail or iCloud) or via secure transfer so users could receive credentials. Expired, consumed or invalid tokens were replaced by resending fresh reset/activation links or by performing admin/system resets at the authoritative IdP (for example Okta or EntraID/Azure AD); administrators sometimes used admin resets or direct sends to bypass service‑side request limits or cooldowns. Tokens prefetched or consumed by email‑security scanners and link‑previewers were resolved by coordinating with mail/security teams and issuing fresh tokens or alternative delivery paths. Truncated, redirected or previewed links were fixed by extracting or regenerating full URLs and completing flows in supported contexts; clearing browser cache/cookies or using a private/incognito browser restored usable sessions in multiple incidents. Technicians observed Microsoft verification emails from msonlineservicesteam@microsoftonline.com and noted codes that expired in roughly five minutes; retries that generated immediate lockouts were addressed by issuing fresh MFA/verification flows and by administrative unlocks or IdP resets. Missing, archived, locked or unlicensed accounts were reconciled by provisioning, unarchiving, unlocking, restoring licenses or performing application‑side password resets so dashboards, add‑ins and embedded app tiles could reauthenticate. Application‑specific blocks, orphaned MFA artifacts, out‑of‑sync role/app assignments and corrupted application profiles were repaired by regranting app roles, repairing profiles, or reprovisioning at the application side. Notification‑provider delivery failures (for example SMS/email vendors) were corrected in provider settings and notifications retriggered. Incidents that coincided with local device sign‑in problems (for example inability to change a Windows sign‑in password or missing VPN/WLAN client UI) were treated as parallel endpoint issues and escalated to desktop teams; remediation in those cases included local profile repair, device reprovisioning or restoring/reinstalling network/VPN clients so devices accepted new credentials and SSO/app resets completed. For requests or applications managed outside the IT Service Portal, technicians routed or forwarded the requests to the appropriate support team or vendor portal; in one case a student account was outside employee IT support scope and the request was forwarded to Student Support (techsupport@iu.org), which resent the customer's login credentials. These actions restored delivery and usability of password, activation and verification messages and repaired related sign‑in, MFA and licensing access issues across production and sandbox environments.

Access was restored by correcting identity state, resolving entitlement and license issues, clearing obsolete authentication factors, re‑importing disabled identities into Okta and setting required profile attributes, and using platform resets when self‑service failed. Support actions that resolved incidents included reactivating or extending user accounts by updating termination/contingent‑worker dates and licence/contract end dates and recording extensions; importing disabled or omitted accounts into Okta and assigning the responsible/manager in the user profile before issuing reset emails; reactivating or escalating application‑specific accounts (for example Salesforce or course accounts) to the owning application teams when application entitlements blocked access; removing or updating legacy authentication factors that prevented 2‑factor enrollment and retriggering password‑reset or initial‑access flows; initiating Microsoft password resets when Microsoft identities had expired so reset/access emails were delivered and users could create new passwords and enroll 2FA; resending reset emails to known addresses and coordinating with internal teams for deactivated employee accounts while following verification practices for requests from personal email addresses; and triggering an Okta password reset when self‑service recovery was blocked (for example the recovery email matched the sign‑in) or an account appeared locked. A subset of incidents required handing off remediation to application owners for application‑level entitlement fixes, backend identity‑state updates followed by users retrying sign‑in, or workstation support to restore local admin or privacy settings (for example macOS Privacy & Security changes affecting Teams).

Support restored on‑device sign‑in by re‑establishing synchronization between affected devices and corporate identity services, refreshing cached credentials, or re‑provisioning devices. Observed successful remedies included: allowing vendor/Phase‑1 provisioning flows to fully complete (some new laptops required ~60+ minutes and SupportAssist to finish) and permitting that provisioning to finish before attempting local sign‑in. When devices were offline or had stale cached state, restoring network connectivity from the Windows sign‑in screen — using campus LAN/Wi‑Fi, the same VPN method used during initial provisioning, or a mobile hotspot — allowed the device to validate or refresh cached/domain credentials; in a few incidents temporarily disabling WLAN allowed cached/local sign‑ins to succeed. When the sign‑in UI showed an outdated username, signing via Other user, using Switch user, or signing once with an older username bypassed the stale state and allowed subsequent logins with the current UPN. Clicking the sign‑in screen "Reset password" control cleared cached credential state in multiple incidents so the same password then succeeded without a separate cloud reset. Okta and Microsoft password resets were accepted by affected devices once they regained connectivity, but SSPR via email was sometimes not available when users had no private email on file. Cases where Ctrl+Alt+Del password changes failed with domain‑controller errors resolved after network restoration and credential sync. Factor-related blocks were cleared by removing and re‑enrolling Windows Hello PIN/biometrics or by resetting Microsoft Authenticator; one team reported using a hardware security key to reduce recurrence. Devices that combined sign‑in failures with system instability recovered after updating or reinstalling device drivers, removing/reinstalling vendor driver‑management components (for example Dell Command), and forcing reboots. Transient Company Portal/Intune or gpupdate failures cleared once the device completed credential sync/provisioning; affected devices sometimes displayed an Intune/Hello credential flag (hellocredbroken). Exchange/Outlook and shared‑mailbox visibility problems that accompanied sign‑in or name‑change issues were resolved by removing and re‑adding mailbox entries to refresh visibility and send‑as permissions. New‑device fixes included enabling missing provisioning/sign‑in checkboxes and adding devices/users to required Azure AD/AD groups (examples: a "Win11" device group and an AD "wireless" group) which allowed sign‑in on otherwise‑blocked laptops. A reproducible Other user/lock‑screen black‑screen failure was escalated to Microsoft; in at least one Dell case a vendor‑side Microsoft update deployed by specialist teams resolved a device that repeatedly requested passwords and only accepted a new password after a full reboot. A browser cookie clear resolved an initial Teams access failure in one password‑reset case where cloud services were reachable but the local client was blocked by stale cookies.

Support performed Keychain Access repairs and progressive keychain reset/repair measures (attempted in increasing invasiveness) and provided targeted keychain troubleshooting and reset instructions. After those Keychain Access fixes and the keychain reset, the persistent macOS Keychain password prompts stopped, permission‑denied errors when updating the keychain ceased, and affected apps (Self Service+, Okta integrations, 1Password) authenticated normally.

Access failures were traced primarily to corrupted browser/session state and incorrect sign‑in URLs, and were resolved by restoring a clean Okta session and, where necessary, resetting credentials. Clearing the browser session or using a private/Incognito/InPrivate window returned users to the Okta dashboard, restored downstream SSO access (including Atlassian/Jira/Confluence), and allowed 'Forgot password' reset emails to be delivered. In multiple incidents support-issued direct password‑reset links or IT‑triggered Okta password resets sent to the user's IU email were used to reset Okta (and related Microsoft) credentials and immediately restore browser access; in one macOS case signing into the browser once with the old password produced a change‑password popup that completed the reset. Separately, switching from outdated or incorrect sign‑in URLs (for IU environments, https://okta.iu.org/) to the current URL resolved sign‑in failures tied to wrong endpoints. Recurrent failures that reappeared after a successful password reset were traced to account/session conflicts from using personal and corporate accounts in the same browser profile; resolving browser session state (for example by clearing session/cache, using a private window, or using a separate browser/profile) prevented recurrence. Restoring Okta access also resolved related downstream anomalies such as email drafts stuck as 'not sent', TEAQ save/overwrite errors, and SharePoint upload failures that were observed while the browser/session was corrupted.

Support first verified which user identifier each service required (student handle, institutional email, or service‑specific username) and which credential store the service validated; in several cases the root cause was an account mapping or migration mismatch (for example myCampus still mapped to a prior email), and reissuing a password reset for the correct handle resolved access. Okta-initiated password resets restored Okta dashboard and SSO access and often restored Microsoft/Outlook for newly provisioned devices; launching apps from the Okta dashboard or using app URLs with a session_hint re-established SSO sessions in many cases. When downstream services remained inaccessible, support either waited for password propagation (some Atlassian/Jira accounts regained access the next day) or re‑synchronized the downstream account; Atlassian issues were also resolved by selecting a password that met Atlassian’s complexity/policy and re‑synchronizing the account. Where SSO tiles or apps failed to redirect to a password‑set flow, administrators reset both the Okta account and the downstream service account so the service redirected and allowed a new password (Salesforce example). CARE‑specific accounts required triggering an EPOS reset and confirming the user completed the password set via EPOS so the change persisted. Jamf Connect failures were logged as unsuccessful password‑sync attempts returning “Password Expired., Status: 400.” Managed laptops that rejected newly set passwords while offline were resolved by issuing an administrator‑initiated Okta password reset link (Service Portal), delivering the new credentials, and then either forcing a local Windows password change (which triggered sync to Microsoft/Azure AD and Okta) or restoring network connectivity (for example VPN) and signing in with the new password to re‑establish Teams and email. When users lacked two‑factor authentication and could not use self‑service reset, support issued administrator reset links; after the user changed the Okta password, entering the new password into the Jamf authentication prompt re‑synchronized device credentials. Delayed or undelivered password‑reset emails were handled by verifying delivery paths, reissuing reset links, and sending reset information to users’ private email addresses; adding a secondary/private email in Workday prevented later delivery failures. Support identified cached credentials in password managers and on old devices (including 1Password); after users removed or updated saved credentials, seamless sign‑in was restored. Transient self‑service reset errors returning “password reset is not possible” were resolved by retrying the self‑service reset or completing a reissued reset link sent to a private email.

Technicians primarily restored access by resetting the local macOS account password in Recovery, which recreated a usable local credential and cleared account lockouts. Recovery resets used the device recovery key from Jamf or the Safe Portal, or a Safe Portal one‑time code sent to the user’s verified alternate email. In several cases technicians performed an IdP (Okta/Microsoft) password reset first and communicated the new password to the user’s private email before completing a Recovery reset. For newly provisioned Macs where the initial one‑time provisioning password appeared to stop working after restart, administrators noted that reissuing a provisioning OTP for MacBooks was not straightforward; instead, technicians sometimes emailed the user clear sign‑in instructions or sent a Safe Portal one‑time code to the user’s verified alternate email, after which the user completed sign‑in and setup. For first‑time IdP sign‑ins and FileVault unlocks technicians confirmed Wi‑Fi availability at the network login prompt and corrected the keyboard/input source when special characters had been entered incorrectly; after those checks users completed sign‑in. When domain‑qualified usernames were rejected, signing in with the short local username often succeeded. In recurring cases where a Recovery‑created password was accepted only briefly, technicians reconfirmed the reset and set a simpler password (avoiding complex special characters), which persisted. Some incidents resolved after a transient cached‑password lockout period of roughly one to a few hours without Recovery‑key use. After restoring local access technicians completed post‑access tasks such as granting admin privileges and assigning required software licenses (for example, Adobe Complete). Several resolves referenced the internal Confluence procedure for changing a local password in macOS Recovery.

Support resolved these incidents by either providing a temporary credential after a password reset or by identifying the mailbox owner and directing the requester to that owner. When a password reset was required, support reset the service account password and delivered a temporary credential via safe.app’s ShowSecret one‑time Safe‑Link or provided the temporary password directly; recipients used the one‑time link or temporary password to sign in, were prompted to change the password at login, and then set a new permanent password. For Exchange/Office 365 service mailboxes, support also checked mailbox ownership and full‑access permissions and supplied the identified mailbox owner/contact (or notified them) when credential sharing was inappropriate or the requester only needed mailbox access.

Three root causes and their observed resolutions explained the incidents. 1) On‑premises Active Directory expired‑password state: Accounts showed expired‑password attributes; after AD attributes were adjusted (for example enabling an account’s “Password never expires” flag) authentication agents accepted the account once directory state propagated (observed propagation time ~10 minutes). 2) Identity provider (IdP) password expiry or reset: Token endpoints that returned HTTP 400 responses (examples: Okta “Password has expired.”, OAuth sign‑on‑policy denials, Azure AD AADSTS50126) stopped denying authentication after the user completed the IdP web password change or reset. Where the Mac’s local account had become unsynchronized with the updated cloud password, access was restored when the local and cloud credential states were reconciled — examples observed included the user signing into macOS with the existing local password and then using the management/authentication client’s password‑sync or re‑authentication flow (Jamf Connect) to reconcile credentials, or support staff coordinating a simultaneous password change on the Mac and in Okta to align both accounts. When the cloud password was reset remotely, successful reconciliation required the Mac to reach corporate authentication infrastructure (on‑campus or via VPN) so new credentials could be synchronized. 3) Client session or authentication state errors: Stale or disconnected client sessions caused repeated prompts or credential rejections despite valid cloud passwords; re‑authenticating the user session via the client (for example Jamf Connect’s menu‑bar sign‑in) cleared the stale session and stopped recurring dialogs. A subset of these incidents produced token‑endpoint 400 sign‑on‑policy denials that were resolved either after completing the provider’s web password flow or after establishing a fresh client session. Additional operational notes observed across cases: Jamf Connector/Connect occasionally failed to synchronize a changed password, and remote support or remote‑session interventions sometimes left the Mac in an inconsistent state that was resolved by coordinating changes to both the IdP and the local account. Collectively, expired AD password flags, IdP password‑expiry or sign‑on‑policy denials, and stale client/session state explained the observed token errors, local password mismatches, missing biometric sign‑in, and recurring authentication prompts.

Support restored access primarily by performing administrator‑initiated password resets from the Okta Admin Console or by using each service’s native reset flow where integrations were absent. When self‑service flows failed (reset‑link loops, provider rate limits, account‑lookup errors, expired passwords or persistent login/MFA loops), staff issued admin resets or temporary credentials and triggered automated reset notifications to the account’s registered primary and any alternate addresses; resend/spam checks and temporary‑password expiries were recorded. For Azure/Entra accounts that displayed “password can only be changed by Global Admins,” requests were escalated to Global Admins who performed the reset. Missing accounts or mailboxes were imported or recreated in Okta and contact addresses updated before issuing reset links or one‑time credentials. Generated credentials for managed service accounts and LAPS‑managed local admin passwords were recorded in approved secrets storage (1Password, safe‑app) and delivered through those vaults or other documented secure channels (SafeLink for network drives, approved external addresses, or Teams when authorized).

When downstream integrations reported credential errors after a password change, staff coordinated updating stored service credentials and revalidating federations; federated applications were launched from the Okta dashboard to confirm federation, and app‑level signing or permission errors were escalated with captured correlation IDs and error details. Locked, disabled, or on‑prem AD accounts were unlocked and AD passwords reset directly while leaving Azure AD unchanged when appropriate. For problematic MFA states or missing recovery factors, staff cleared or reset MFA state and issued admin resets so users could reconfigure authentication, supplying temporary verification codes where required. For device sign‑in, users applied new credentials by signing into the device locally or over VPN so Windows sign‑in picked up updated credentials.

When stronger identity assurance was required or no alternate address existed, staff accepted forwarded external email evidence or performed live identity‑verification calls before handing credentials. License status (including A1 licenses) and expiries were checked and adjusted when requested. Recurring or intermittent failures were resolved by performing resets and opening follow‑up investigations with the user to identify causes such as credential caching, federation/sync issues, multiple/conflicting identities, device keychain mismatches, or stored credentials in downstream integrations. Microsoft PowerApps/Microsoft PWA issues were handled by sending tenant‑specific password‑reset emails or demonstrating manual password creation when automatic generators produced non‑standard strings, escalating to specialists when manual passwords still failed.

Incidents were resolved by ensuring the account identifier and authentication path matched each application’s expected username format and identity provider and by correcting inconsistent stored account records. Technicians restored or corrected stored login names (for example re‑adding stripped @iu.org domains, fixing punctuation differences such as dot vs hyphen, and applying external markers like “.ext” to the local part) and signed users in with the application‑specific/local username when appropriate (for example firstname.lastname, an app short username, or username.ext). When applications shared an authoritative credential store, technicians confirmed the canonical source (for example myCampus and CARE shared the same password database) and performed resets at the authoritative system rather than duplicating resets. Login‑loop cases where a password change still returned users to the login prompt were resolved by confirming the correct SSO instance or vendor portal and by performing provider‑specific resets when CARE/EPOS or other services used a different identity flow than myCampus. Password‑reset failures caused by rate limits or time‑locks were resolved by allowing lock expiry or by performing administrator/provider resets and supplying temporary first‑login passwords when available. Missing or rejected reset emails were investigated by confirming the authoritative provider and contact address and by resending from that system. Failures from saved or autofilled credentials were resolved by locating, restoring, or creating correct entries in enterprise password managers (for example 1Password), clearing or updating saved browser credentials, and disabling browser autofill when it supplied outdated identifiers. Post‑login stale UI content was cleared by removing browser cache and cookies or performing a hard refresh. Support investigated vendor provisioning and activation windows and provisioned or reactivated accounts when appropriate; live assisted troubleshooting (for example via Microsoft Teams) was used to gather screenshots and determine account existence. For accounts not managed by internal IT, support confirmed ownership and referred users to the responsible vendor or campus office (for example advising contact with the vendor’s service desk or with the exam office for PebblePad at pruefungsamt-fernstudium@iu.org) and closed the ticket after the user confirmed external support resolved the issue. Ambiguous login UIs were removed or clarified. Student or study‑portal cases were routed to the Study‑Support‑Team, vendor or product‑owner integration issues were escalated to the people‑products team, and inconsistent canonical identifiers were escalated to specialist teams to correct authoritative usernames and confirm successful sign‑in.

The support team explained that the browser's prompt was a built-in security measure that requires the user's local Windows account password to display stored credentials. The user supplied their normal Windows/Notebook login password (which matched their Okta password on devices where sign-in used Okta) and was then able to view the saved passwords.

Access failures were resolved either by users completing the self-service 'Forgot password'/password-reset flow or by support generating and sending a manual password-reset email. In some myCampus cases support reviewed and corrected user attributes in the account record before issuing the reset. A recurring symptom in the myCampus flow was loss of previously saved password prefill, which required users to create a new password. After receiving a reset email, users created passwords that met the myCampus service policy (minimum 8 characters, at least one uppercase letter, one lowercase letter, one digit, and one special character) and access was restored. In a Salesforce case support confirmed the error message meant the submitted new password matched the existing password (password-reuse blocked) and advised the user to choose a different new password; no system-side fix was required and some users elected to continue using the assigned password.

Support reset the user's Microsoft 365 password and delivered the reset details to the user's alternate (private) email; the user was then able to sign in. Editing remained disabled on the iMac because the account was assigned an A1 (web-only) license that does not include full desktop Office editing. Support explained the A1 license limitation and advised that a license with desktop Office rights would be required to enable editing in the macOS Office apps.

Multiple incidents of recurring password-expiration prompts were traced to different authentication systems and resolved by clearing expiration flags or changing platform password-expiration policies. For IU Windows accounts, an administrator cleared the password-expiration flag on affected accounts (noted 2024-04-22) and the organization-wide Windows password policy was changed to mark accounts as 'password never expires' on 2024-06-19, which stopped the Windows expiration notices. Separate incidents where notifications originated from Microsoft platform accounts were resolved when users changed the associated Microsoft account passwords. In incidents that caused VPN authentication failures, support identified Okta password expiration as the cause; the Okta policy was changed on 2024-06-19 to remove mandatory periodic password expiration for non-administrative users, after which forced three-month password changes and related VPN denials ceased. Support also observed that IU Windows account passwords were rotating on roughly a three-month cycle, which matched some reported timing of prompts.

Incidents were resolved by repairing or restoring server-side authentication services and fixing faulty integrations between web frontends and backend identity or customer-maintenance systems. Transient provider outages cleared when the external provider restored service and users regained access. Configuration- or integration-related failures were fixed when specialist teams corrected authentication/service configuration or integration code and deployed changes to production. Several incidents traced to backend data-handling or database errors (for example Oracle ORA-01400: cannot insert NULL into WEB_USER_DETAIL_HISTORY.USER_ID during MyLIBF login) and were resolved by repairing the integration and ensuring required fields were populated. Support restored access in some cases by issuing functioning password-reset links or by directing users to SSO entry points (for example Okta) that bypassed broken manual-reset flows. For Miro password-reset blocks the support team recommended signing in via SSO or providing live assistance as a workaround. For LIBF/Azure AD B2C OpenID Connect errors helpdesk checks included account verification and advising a password reset; helpdesk sometimes requested a full screenshot including the browser URL for further diagnosis, and some tickets remained unresolved when users did not respond.

Support verified that affected services and integrations were functioning and that the same credentials authenticated successfully from other devices. Logs were reviewed; some environments showed no initial activity then recorded failed login attempts. Failures were primarily traced to credential mismatches: many users had mistyped or supplied an out‑of‑date password and access was restored once the correct password was entered. Several accounts required a password reset (for example a reset link delivered to the user’s private email); after the reset those devices and accounts authenticated normally. In at least one case the problem was isolated to a MacBook using Chrome and support noted the device’s keyboard layout or input state (for example a changed layout causing different symbol positions or active caps lock) as a likely contributor, though that ticket lacked a documented confirmation of the specific fix. No client, LDAP binding, or service configuration changes were required to resolve these incidents.

Okta authentication was confirmed to be functioning (password resets and SSO logins succeeded). Investigation found that missing course or lecturer role assignments in the course-management system (LCC) — surfaced as missing booking information or the STUDY_INFO_NO_ACCESS error (Edge/IE sometimes showed JSON id/ac5Id details while other browsers showed a generic “access denied”) — caused the Infocenter/myCampus listings to be empty. Restoring the user’s course/booking assignments or lecturer roles in the course-management system (LCC / myCampus booking data) restored Infocenter visibility. Instances where password-reset emails were not received were incidental when the user later authenticated successfully; no Okta configuration changes were required.

The Azure AD Password Reset properties were changed from scope = "All" to scope = "Specific group" and the Students group was selected using the Azure Portal Password Reset blade (https://portal.azure.com/#view/Microsoft_AAD_IAM/PasswordResetMenuBlade/~/Properties). The change was approved by Boehlk, Oliver and Akmal, Asif and implemented by Hirschfeld, Maximilian on 2025-08-20. After the change, SSPR remained enabled for Students only.

Support located the Apple ID/email displayed on the device and attempted account-recovery through iforgot.apple.com, verifying any recovery phone numbers and recovery emails that Apple reported. In multiple cases recovery failed because Apple showed incorrect or third-party recovery contacts, required confirmation to an Apple-assigned temporary email (…@temporary.appleaccount.com), or there was no preconfigured Apple ID email available; support verified messages referencing temporary.appleaccount.com as legitimate where necessary. For MacBook incidents where the Apple ID was locked, enterprise password resets (for example via Okta) did not restore device access; those cases required Apple’s Mac login account-recovery flow and retrieval/use of the personal Recovery Key to unlock the Apple account. IT confirmed it could not access or reset Apple IDs owned by third parties. Incidents were resolved when users located the Apple ID password in internal documentation or obtained it from the person who created the Apple ID and signed in; where the account owner or password could not be obtained, the device user created and used a new Apple ID/iCloud account on the device. Tickets were closed after successful sign-in or after 14 days with no response.

Support resolved these incidents by initiating and completing the 1Password account recovery process on the user's behalf. Support sent the 1Password recovery email flow to the user's recovery address; in some cases the initial recovery email produced an error and support resent the recovery email. The user completed the recovery steps provided in the recovery email, after which support confirmed the account recovery and restored access to the 1Password account.

Support resolved account-access issues by initiating the account-type–appropriate recovery or reset flow and completing any required administrative confirmations. For Okta/SSO-managed accounts support coordinated with Okta administrators to reset passwords or accounts and sent reset messages to the account’s registered addresses; during verification support checked whether MFA (including biometric factors) was configured and performed explicit MFA resets only when required. For standalone 1Password accounts support initiated the 1Password account-recovery workflow which generated recovery emails; when the web recovery flow required administrator confirmation support finalized the recovery so the user could set a new master password. Support initiated recoveries on users’ behalf when self-service UI elements (for example the People/sidebar) were inaccessible, when users reported sign-in errors after resetting a master password (including on new laptops), or when web change-password flows completed email confirmation but redirected to a help/recovery page or instructed the user to contact an administrator. Support documented that possession of an Emergency Kit did not permit vault unlock without the correct master password, that multiple associated email addresses sometimes required separate resets or recovery messages, and that deletion of a stored master password (for example a macOS Keychain removed after Group Policy or local account password changes) caused users to lose access and require IT-assisted recovery. All communications and recovery confirmations were routed via the account’s registered email and occurred alongside Okta/SSO verification as applicable.

Investigators confirmed the Chrome warning was caused by the account password appearing in breached-password databases; the test password "Welcome01!" matched entries commonly marked as compromised. The problem was resolved by changing the test account password to a stronger, unique password and by advising use of institutional guidance on creating complex passwords. The Chrome compromised-password warning was therefore expected behavior from the browser's password manager rather than an authentication or service-side error.

Support restored access by initiating password resets and dispatching password‑set/reset links through institutional identity systems (commonly Okta and Azure AD/Microsoft 365), sending messages to the contact address on the user profile (institutional and/or user‑provided private addresses) and, when necessary, to both. Technicians checked account activity and audit logs to confirm password‑set events and last interactive logins when users reported reset‑link failures and advised users when logs showed successful resets but sign‑in still failed (for example when the new password was not saved or entered). When reset messages were not received or addresses were stale, staff corrected incorrect contact addresses (including legacy entries), re‑triggered or resent reset messages (occasionally repeatedly), and reenabled or restored self‑service “forgot password” where applicable. Additional actions included issuing Okta tokens/password‑set links, generating temporary/initial credentials for new hires (noting provisioning sometimes sent password‑set emails to private addresses on start dates), importing accounts into Okta, contacting users at their private addresses to assist with resets, and completing resets on behalf of users in time‑sensitive situations. Support recorded delivery evidence or explicit user confirmation before closing tickets and noted occasional duplicate messages or inadvertent resets while correcting contact information. Operational context observed in tickets included Okta automation and termination‑date behavior that affected when reset emails were routed to external addresses, conditional‑access and corporate‑network requirements (for example VPN) that needed to be satisfied during a reset, and client‑specific problems where some mail or client apps refused the new credentials (for example Outlook and Apple Mail errors). In cases involving applicants or students, requests that were misrouted to the employee portal were redirected or closed after staff advised the requester to contact IU Student Support (techsupport@iu.org) because those accounts and recovery flows were managed by student support; staff noted instances where phone loss/theft prevented MFA completion and required alternate student‑support handling. These combined actions restored access to Okta, Office 365 (Outlook, Teams), Windows laptop sign‑in, VPN, Workday, IU Mail, Outlook mobile/desktop and linked third‑party services; MyCampus sometimes used a separate credential store and was not affected by Okta password resets.

Support first determined whether each affected application and environment (production, staging/test, or third‑party) was administered by central IT or by a departmental/third‑party owner. When ownership lay outside central IT, users were referred to the application’s documented access/password request channel (for example a SharePoint access/password form, the IU Meldeportal, or the application owner’s Jira/Atlassian service desk) and to the listed application owner; such tickets were closed as wrong department when appropriate. When central IT located the user account in an external system and had credential‑reset capability (examples included CARE systems, academyFIVE/Campus Management, and Atlassian), staff performed password resets or account updates, provided new credentials or reset links, and confirmed successful sign‑in. For invitation‑based third‑party SaaS accounts, support advised a password reset when an invited user lacked usable credentials and, where admin access allowed, offered account deletion and re‑invitation to recreate usable credentials; follow‑up indicated this resolved the reported access issues. For multi‑environment applications, staging/test environments often used separate accounts or experienced delayed synchronization; sign‑in failures to a staging environment were resolved by obtaining environment‑specific credentials from the application owner or by resetting the account in that environment when central IT had access. Brief propagation delays (approximately five minutes) explained some immediate post‑change failures. Support clarified cases where an application was implemented as a background/service system: some user roles did not have interactive accounts and were expected to use a user‑facing portal (for example myCampus), so users were referred accordingly. Support noted that several academic/exam tools (Examity, Turnitin, PebblePad, Atlas, Bongo) were managed exclusively by the Prüfungsamt and referred users to pruefungsamt-fernstudium@iu.org for account/password assistance; PebblePad password‑reset/email delivery issues were handled by the Prüfungsamt. TEAQ/Sitefusion account lock/unlock requests were directed to TEAQ support at cfe-teaq@iu.org. For Workday, sign‑in often used Okta SSO while Workday API or standalone Workday credentials were separate from the Okta password; support did not perform Workday API credential resets and instead advised contacting the Workday interface/support team (WCC) at wd-support@iu.org or the listed Workday contact for API/Workday credential requests. Where SharePoint pages listed a responsible person for an application, support referred users to that contact (for example the Index SharePoint entry listed Luca Robel).

The problem was resolved by using the IU Self Service App (the "yellow Minion") to grant temporary local administrator privileges. The user authenticated with their normal account password when prompted by the Minion and then installed the system updates; the Minion reported the updates succeeded.

Support confirmed affected Care accounts commonly used the user's IU email address as the account username and retried sign-in with the user; in some cases instructing the user to sign in with their IU email and their new password restored access. Multiple incidents involved failures in the Care self-service reset flow: the system either did not generate or deliver reset emails, or returned an error during processing after the user submitted a new password. Technicians performed administrative password resets and, where applicable, created accounts and provided the correct IU-email username; those administrative resets restored access to Care and to connected systems such as Workday and Salesforce. Administrators noted Care's self-service reset was unreliable for some users and recommended using alternate IU password-reset channels (myCampus or EPOS) when available.

Support investigated Okta and Sentinel logs, confirmed repeated invalid‑credential sign‑ins from varying IPs consistent with travel and third‑party VPN use, and verified Microsoft Identity had classified the account as "risky." Okta logs did not show geoblock or an Okta account block entry; a later attempted password change failed because the new password did not meet the institution's password policy. No single configuration change or definitive root‑cause was identified and no confirmed fix was applied in this ticket. Support documented remediation options for downstream teams, including administratively resetting the account password and clearing the Microsoft risk state, coordinating with security to review Conditional Access/risk policies and known IP allowlists, and working with the user to reduce use of third‑party VPNs during authentication windows. These investigation findings and suggested mitigations were recorded for follow up by the identity/security team.

The technician directed the user to the institution's onboarding documentation that described the prescribed procedure for changing the password after first log‑in. After the user followed the onboarding steps referenced in Microsoft Teams, the password change completed successfully and the permission denied symptom did not recur.

Support generated a new password for the affected .PWA account and stored/delivered the credential through the organisation's Password Safe so the user could reclaim access. The action restored access without modifying application configuration or requiring further tenant changes.

Support confirmed they did not have administrative access to Turnitin account management for shared institutional accounts (examples included turnitin-cs@iubh.de and pruefungsamt-fernstudium@iu.org) and therefore did not perform any technical password resets. In the reported cases, self-service password reset attempts could not be completed because the shared mailbox was not accessible and no password‑reset emails were received or visible in Salesforce. Requesters were referred to the central examinations office (zpa-dualesstudium@iu.org) or the original account owner who had created the Turnitin account; no internal credential changes were made by IT.

Support provided temporary passwords to the user's private email; the user was able to sign in sporadically with those temporary credentials but the problem recurred after subsequent logouts. Support advised connecting via VPN and changing the corporate password as troubleshooting measures; no permanent resolution was documented in the ticket.

The user's account password was reset by an administrator to restore access. Enabling the LAPS UI on that Jump Server was not completed because Microsoft LAPS is not supported on Windows 11 multi-session; the requester was informed and no configuration changes to enable LAPS were possible.

Credentials were migrated into the company's 1Password vault following the organization's documented procedure. Password entries were created/stored in 1Password and the migration was performed in line with the internal documentation and knowledge article (links recorded in the ticket). The request was completed and the ticket was closed.