## Spaces login fails for AD users (works in Classic)

Thanks for the clear description. Given:
- Spaces login fails for established AD/LDAP users with “invalid password” in logs
- Same users can log in via Classic
- Local/Gmail (non-AD) users can log in to Spaces

This strongly points to an SSO/LDAP authentication path difference between Spaces and Classic. Let’s isolate and fix it.

### Quick isolation checks
1. Test manual (non-SSO) login on Spaces
- Try: https://yourcompany.sysaidit.com/spaces/login?manual=true
- If this works for an AD user, the issue is with SSO redirect/claims, not LDAP credentials.

2. Bypass Spaces (control) vs Classic (baseline)
- Compare both URLs using the same user at nearly the same time to rule out AD lockouts or wrong domain suffix.

3. Check the username format expected by Spaces
- Try: domain\username, username@domain.tld, and plain username. Spaces may enforce the login identifier differently than Classic depending on your LDAP/SSO mapping.

### LDAP/SSO configuration points to verify
- LDAP repository selection in Spaces:
- Settings → Integration → LDAP
- Ensure the default repository and domain mapping match what users select on the Spaces login page (if domain picker is enabled).
- “Primary” DC or repository availability:
- If you list multiple LDAP servers, check that the first/primary is reachable from the SysAid server. Classic might be falling back differently than Spaces.
- Run “Check Connection” on your LDAP integration and note the exact result.
- Attribute mapping
- Confirm the login attribute used by Spaces matches your AD setup (sAMAccountName vs userPrincipalName).
- Time drift and lockouts
- Ensure no account lockouts are happening after a few failed attempts (AD audit).
- Verify server time sync (NTP) to avoid Kerberos/SSO token issues if you use SSO.

### If you use SSO (Azure/Okta/ADFS)
- Try manual bypass to confirm: /spaces/login?manual=true
- Validate SSO application configuration:
- Reply URL/ACS includes Spaces endpoints
- Example: https://yourcompany.sysaidit.com/spaces/saml/SSO (or OIDC equivalent)
- NameID/UPN claim matches what SysAid expects for user lookup
- Ensure email/UPN in the SSO claims maps to the same user record that LDAP created (no duplicate local vs LDAP users)
- Test a user with both SSO and manual: confirm both paths resolve to the same SysAid user record.

### Targeted fixes to try now
1. Enable domain-qualified login on Spaces
- Ask users to log in as DOMAIN\username (or username@domain.tld), matching your LDAP setting.
2. Set a consistent default UI during troubleshooting
- Settings → User Management → User Preferences → Default Interface = Classic for affected users, so they can work while we fix Spaces.
3. Verify and update LDAP credentials and order
- If your bind account or primary DC changed, update credentials and server list. Remove unreachable DCs; ensure the primary is healthy.
4. Run an LDAP sync
- Settings → Integration → LDAP → Run Sync
- This can resolve mismatches if usernames/emails changed in AD.

### Helpful data to collect if the issue persists
- Does /spaces/login?manual=true work for these AD users?
- Exact username format used when it fails in Spaces and succeeds in Classic
- Screenshot or copy of the LDAP “Check Connection” result
- Whether a domain chooser is shown on Spaces and what domain was selected
- For SSO: a redacted SSO claim set (NameID/UPN/email) and the configured identifier in SysAid

Reply with the results of the manual login test and the LDAP check connection message, and I’ll guide you to the next exact step.