Multi-provider SSO is enabled but side_door.do is not allowing logins despite the glide.authentication.external.disable_local_login property being set to false.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-04-2017 05:39 AM
We are trying to implement multi-provider sso with okta, but any attempt to log into the side_door comes back with a "User name or password invalid" error message. The glide.authentication.external.disable_local_login property is set to false. This is making it difficult to set up service accounts. Nothing shows up in the logs. Does anyone have any ideas as to what else needs to be checked?
- Labels:
-
Instance Configuration
-
Integrations
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-15-2018 12:04 PM
Thanks. I tried using an Incognito tab and still couldn't log in... so I don't think that it's a session issue.
It appears that there is some check that is happening when using Multi-provider SSO on the 'Source' field on the sys_user record. Our user records are imported from AD... so they all start with "ldap:". I was able to access via login.do and side_door using an AD-created account by clearing the Source field on the user record... but of course this won't solve the issue long term because that field will be re-written the next time we sync with AD.
Thanks,
Nate
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-15-2018 12:14 PM
Correct - to add one more bit of info to Chuck's response, even if the account exists in sys_user, if the source has an LDAP entry in it, it wants to access that table to authenticate, so if it's truly not available, it won't work. You'll need a 'true' local account not connected to LDAP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-15-2018 12:37 PM
That may be true. We have migrated from an AD managed authentication (Non-multi-provider SSO) to Okta Multi-provider SSO, and entries in the source field carried over would cause problems. We don't create users via AD integration any longer however, so we have the source field cleared for all users now.