Please use user_mapping.user_name.from instead.
Then please activate the debug mode. You should get debug infos then directly on the login screen:
Not much help, unfortunately
Can you then please check the ES logs again?
Sorry for the trouble.
Hmmm maybe that one:
{"type": "server", "timestamp": "2022-07-05T14:12:37,226+02:00", "level": "WARN", "component": "c.f.s.a.b.RequestAuthenticationProcessor", "cluster.name": "test", "node.name": "node42", "message": "Error while mapping auth credentials for trusted_origin[adca255d]", "cluster.uuid": "3LC10Pj8TTCaDX54FfnlrA", "node.id": "pZrWb7qMSP2-n4Jx86HZpA" ,
"stacktrace": ["com.floragunn.searchguard.authc.CredentialsException: No user name found",
I also tried user_mapping.user_name.from: oidc.preferred_username
Hm, that log message indicates that trusted_origin auth domain could not find credentials. In the context of Kibana, that should be expected. So, I do not believe that the log message is related.
Can you raise the log level of com.floragunn.searchguard.authc to trace? From the command line, you can do this with:
curl --insecure -u admin:admin -X PUT "https://your-cluster:9200/_cluster/settings" -H "Content-Type: application/json" -d "{ \"transient\": { \"logger.com.floragunn.searchguard.authc\": \"trace\" } }"
If the volume is the logs is too large, don’t hesitate to send the the whole bunch to me by private message.
Also, can you also provide the Kibana log output again?
Thank you,
Nils
Ok, thanks for the information.
Could you please try the following sg_frontend_authc.yml config:
default:
auth_domains:
- type: "oidc"
oidc.idp.openid_configuration_url: "..."
oidc.client_id: "..."
oidc.client_secret: "..."
user_mapping.user_name.from: oidc_id_token.preferred_username
user_mapping.roles.from: oidc_id_token.roles
oh 
What is the order in which you initialize the nodes of your cluster? In your elasticsearch.yml, do you use any of the gateway.* options?
Could you try to restart your master node to check whether this fixes things?
Restarting the master node and kibana did the trick.
I’m not using any gateway options in elasticsearch.yml.
Oh noes, now we have another problem:
Thanks Nils, for your patience and hard work at getting this to work in our environment !
Joke aside, what needs to be done here now ?
Fix the migration script I guess. Do you want me to open an issue on gitlab? search-guard / sgctl · GitLab ?
This is easy to fix. Add to your kibana.yml this:
security.showInsecureClusterWarning: false
We are already working on that, so it is not really necessary. Thank you for the offer, anyway!
If you don’t mind I would provide you a new snapshot version of Search Guard to check whether the issue with the .searchguard_sessions index can be fixed without having to manually restart the master node. This, however, will take one or two days.
Thank you for your patience! This direct feedback is the most valuable information we can have in order to straighten out things.
1 Like
FWIW the cluster has currently one OS node and all the others are ES
Cool, interesting setup! We would love to learn about your experience with this.
well, the idea is to migrate to Opensearch. So we’re waiting for OS support to be stable, so we can migrate all our production clusters, hence the experimentation with flx beta2 and this discussion 
1 Like
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.