I would guess that the user names provided by ADFS don’t completely match the user names used by LDAP.
Assuming that the user name from your example is email@example.com is coming from ADFS, it seems that ADFS/SAML provides the user name in the format of an email address. I don’t know so much about ADFS, but generally, the SAML protocol allows a selection of the user name format to use:
According to your sg_config.yml file, the LDAP user search is configured to use the LDAP attribute sAMAccountName whis is not necessarily in email address format.
As the authorization backends are executed independently of the authentication backend which created a user, the LDAP authorization backend is also queried when a user has authenticated by SAML. Thus, you get the information that there is no matching entry in LDAP for firstname.lastname@example.org.
Still, if things would work well, the error would have been without effect, as you would have got the roles via SAML. And thus, you would have got no “Unauthorized” error.
Can you post the whole stacktrace of this log entry plus maybe +/- 10 lines of context from the logs?
Unfortunately, that is correct. We use O365 for our ADFS, which gives them different domains. They would be members of the same backend groups, however, and for everything I’ve used them for, both the LDAP- and SAML-authenticated user ID’s have identical permissions (i.e., I can execute Elasticsearch admin tasks using my account, when authenticating directly to Elasticsearch via LDAP, or through Kibana, when authenticating via SAML).
This also makes sense. I have all the access I expect to have through SAML. But for some reason, with the update from the 7.9.2 stack to 7.10.2, with the corresponding SG update to 49.0.0 that you recommended to address another issue, I’ve started getting this error only for these two roles; I never observed this error prior to upgrading to 7.10.x, but then I also wasn’t starting to turn on alerts in Signals, so maybe I wouldn’t’ve seen it. Ordinarily, the only auth errors I get are if someone attempts to do something that their SAML roles don’t allow, and whenever the ELK stack authenticates with a user ID created using the built-in authentication (i.e., one of the default system accounts).
I may work with my ADFS team to resolve this issue, just to clean up the logs, however. But, since I don’t get this error for any other roles, it looks to me as if SG stops going down the list of authenticators (SAML->LDAP->Internal) as soon as it finds the role it’s looking for assigned to the user; based on what you’re saying, I suspect that even if the SAML/LDAP ID’s matched up perfectly, I’d still be getting this error.
As far as I can tell, these roles aren’t defined in my deployment. I’ve also checked the default config files from 49.0.0, and I can’t even see where these roles are defined. If they were, I’d assign them to the SAML group that we use for admin and see what happened. Could this be the issue - it’s looking for a role that’s not assigned, because it’s not defined anywhere?
Here’s the full error. As far as the context goes, this is all that’s being written to the log at the moment on the node that’s throwing this exception.
SG 49 brought some changes to the authcz process which might have also introduced this behavioural change you are observing. We need to investigate this a bit more.
For the time being, it might be possible to use a workaround:
If the user names coming from SAML are structurally easy to tell apart from the user names coming from from LDAP, you could use the skip_users config option. For example, if SAML user names are always email addresses containing a @ and if LDAP user names never contain a @, the you can extend your configuration this way:
OK…since I finally located where SG_ADMIN/SG_USER are being used and I understand better what’s going on now, I went ahead and added the skip_users: to the LDAP role config. That has resolved this issue. I was also getting similar errors at startup for the internal users (admin, etc.) and added them as well.
If you can turn on the “Solutions” flag for this forum as well, I’ll mark it as solved.