You should scheule a meeting with me at http://gluu.org/booking It would be easier to provide a quick demo then to point you to all the docs on this issue!

Great! Got it booked. Talk to you then!

Hi, Chris. >We see that we can use the basic multi auth script to achieve authentication from multiple backends. Does this require that users for all backends be cached using the cache refresh functionality? Standard multi-auth script requires this, yes. It may be possible to customize it and lift this requirement, but you also need to take into account that when Gluu releases some attributes/claims during SAML/OIDC flows, it uses internal LDAP directory for sources of those. It may be hard to customize this too, and I'm not sure such non-conventional modifications are covered by community support. You could describe your intended use case in more details, though, may be we'll find some solution. >If so, we see that we can add multiple Source Backend LDAP Servers on the cache refresh configuration page. We have some users in Active Directory and some users in a secondary LDAP server. The mapping to the local Gluu uid would be different in each case as are the customer backend key attributes, but we don't see how to configure cache refresh to handle these differences. Seems like you have somewhat complex setup. Mappings may won't be enough. For such cases we have CR custom scripts feature, this way you'll have much more freedom in choosing what external attribute is mapped to what internal attribute, you also can apply modifications to its values on the fly. You only need to select some key attribute that will be present at both your directories and will help you to determine to which directory belongs user which attributes CR script needs to process at each moment. Let me know if something still isn't clear to you. Best regards, Alex.

As Michael already proposed voice call, that will present much better opportunity to resolve all doubts :) Just wanted to correct some ambiguities in my post: > You only need to select some key attribute that will be present at both your directories and will help you to determine to which directory belongs user which attributes CR script needs to process at each moment. The only real requirement for key attribute is to be unique for all entries across all involved directories. For simplicity it would better be some scoped name-like value, like "user_name_unique_within_this_domain@domain.name". But it also could be some opaque Global Unique ID of any sort, then you would need to rely on some other attributes to distinguish between users of different domains. Like, you could additionally pull "orgName" and "Company" attributes (names have been chosen arbitrary) and use them to distinguish users from each directory.

The cache refresh config is stored in the `oxTrustConfCacheRefresh` attribute in the entry `ou=oxtrust,ou=configuration,inum=(appliance-inum),ou=appliances,o=gluu` I don't have a problem setting the password on LDAP server two: ``` { "sourceConfigs": [ { "configId": "MyLDAP", "bindDN": "cn=directory manager", "bindPassword": "YbKcVYCmTbs=", "servers": [ "myldap.examle.com:636" ], "maxConnections": 0, "useSSL": true, "baseDNs": [ "o=example.com" ], "primaryKey": null, "localPrimaryKey": null, "useAnonymousBind": false, "enabled": false, "version": 0, "level": 0 }, { "configId": "otherLDAP", "bindDN": "cn=manager", "bindPassword": "YbKcVYCmTbs=", "servers": [ "otherldap.example.com:1636" ], "maxConnections": 0, "useSSL": true, "baseDNs": [ "o=otherExample.com" ], "primaryKey": null, "localPrimaryKey": null, "useAnonymousBind": false, "enabled": false, "version": 0, "level": 0 } ], ``` If you need to upate this entry iva LDIF, it's tricky because it's a multi-line value which needs to be indented properly. You should consider using an LDAP browser like JExplorer which will make it easier for you. I use an ssh tunnel port 1636 to my local workstation so I can connect on localshot and use JExplorer. Also, the password is two way encrypted with triple des. To properly encode, in the container, use: ``` # /opt/gluu/bin/encode.py secret ``` Where secret = the password and delete that command from your `.bash_history`! Please post to this issue if you this entry is really not populated properly with the bindPW of LDAP server 2!

Can't reproduce it either, neither for clean 2.4.4 CE package, nor for updated to SP1. Michael provided a good point: may be you just were confused because of passwords are encrypted before stored in the directory?

In Firefox when clicking on the widget it sometimes displays ``` Change Backend '' Bind Password ``` Or, if the name of a backend LDAP server is "Active Directory" ``` Change Backend 'Active Directory' Bind Password ``` In our case, what we see sometimes is that we may have one server named 'Active Directory' and another 'OpenLDAP', that clicking on the change password link brings a modal with the opposite server name or simply ''. This behavior appears to be intermittent.

Very strange. If you see an error in `/opt/tomcat/logs/oxTrust.log` when this happens, please post. We've never heard of a similar report, and we are using cache refresh at 90% of our customers. Something is different about your config. The logs might help flush it out.

> In our case, what we see sometimes is that we may have one server named 'Active Directory' and another 'OpenLDAP', that clicking on the change password link brings a modal with the opposite server name or simply ''. Is it just confusing Web UI behaviour, or there is more to it? Like, when this happens and you update configuration it breaks it in some way, etc? That's important to know how serious it is.

I am having trouble reproducing the issue myself. I will let you know what is in the error logs if I am able to make it occur again.

This is a very complicated multi-tab form. I just opened another issue on this form for [duplicate messages](https://github.com/GluuFederation/oxTrust/issues/375) I think there are some state issues with the multiple-tabs. The developer will take a look at it. It's not something you generally touch that much once its configured, but it is annoying that the UI is buggy.

> I am having trouble reproducing the issue myself. I will let you know what is in the error logs if I am able to make it occur again. I can reproduce it now, Chris, don't waste your time. Still, it isn't that bad - despite what this pop-up dialogue window says, it updates password of the correct backend anyway, so it's a web UI issue. I'll create report on it on github.

Issue is created on github: [link](https://github.com/GluuFederation/oxTrust/issues/376) Chris, do you still need any help regarding CR? Should we keep this ticket open for some time?

We can close this ticket. Our solution was to modify one of the backends to contain a universally unique identifier to use as our primary key across both backends. Thanks for all of your help on related issues!