1. I think you would just create the file. I think you are using the script found [here](https://github.com/GluuFederation/oxAuth/tree/master/Server/integrations/basic.multi_auth_conf) 2. You can add multiple backend servers. There is a link where you can add an additional data source. You can also add more then one primary key, although hopefully there is a common attribute (mail?) that can be used to uniquely identify a person in both LDAP servers. 3. If you are using the Gluu Server LDAP to consolidate your LDAP servers, and once it's done that, you don't need to run cache refresh anymore... that's ok. You can disable cache refresh at that point. The only issue I can see is that the passwords in AD are not encrypted with a standard algorithm. So there is no way to export AD passwords. The only way to migrate is to force a password reset. 4. The biggest change in Gluu Server 3.0 is going to be OpenLDAP versus OpenDJ as the LDAP server. We'll provide a migration script. Also, you can keep using OpenDJ if you want--we're going to publish 3.0 schema for OpenDJ too. We are also moving to Shibboleth v3 from Shibboleth v2, and from Tomcat to Jetty. We hope the move will be pretty smooth though. There is no change to the interfaces to the applications. If you get stuck, post screenshots and we'll try to guide you on the right config settings. If you have budget for professional services, we have some integration partners who may be able to assist. See our [partners page](https://www.gluu.org/partners-service/)

Thank you Michael! I appreciate the answers. Now I have a followup question (#3). 1. Yes, I have been looking at the script you linked. And I'm embarrassed to say that I missed the Installation.txt file. Now it makes much more sense. 2. I'll have to play with this since there is user overlap between directories. (Removing that overlap is one of our goals that we think Gluu can help with - a user exists in only one directory.) 3. I wasn't completely clear. We only want to turn off CR for one LDAP server (We'll call that LDAP-A) once the Cache sync is complete. We'll still need CR for two other LDAP servers (LDAP-B, LDAP-C) and the AD server. So can I safely remove LDAP-A from the data sources list without losing the already cached data? And can I then just use Gluu as the only management interface for the "imported" LDAP-A users? 4. Thanks for the info on Gluu Server 3.0! Thanks for the link to the partners page. If this gets too complex, we may need to hire a bit of help.

Hi, Brad. First I would like to ask you to elaborate on this a bit: >I have several services that currently authenticate using a single LDAP server. I would like to use Gluu to REPLACE that single LDAP server and also to PULL in user information from two additional LDAP servers and an Active Directory. The part about using Gluu as a sort of aggregation LDAP directory which will be used by you services for authentication - how exactly do you expect this to work? Context implies those services still will use LDAP bind operation (probably) to authenticate users, just from now on they will be using Gluu's internal LDAP (which will contain all users from all your backends) instead. This can be done, I suppose, but this is not the usual role Gluu plays in the network, it's expected that your services are able "to talk" in OpenID Connect, SAML, CAS protocols to it, as Gluu is identity and access management suite. Using it as an LDAP directory with a web UI will leave most of its potential untapped :) Another thing that confuses me a bit is this: >I have tested Cache Refresh and have pulled in the user data from the current LDAP server, and was able to successfully authenticate a service user. (I mapped the userPassword data and continued to authenticate using the Gluu server for authentication.) Did you somehow manage to pull hashed passwords into Gluu's LDAP using CR, and after that login with user entries created like that? Or were those passwords in clear-text format? It's still a bit new to me, it's not a regular way CR is used, and I don't think we tried something like that before. Just to clarify things: usually CR is used as a tool to aggregate user data from one/several backend LDAP servers, and [optionally] modify it on the fly, preparing to be released to third parties requesting authentication for a user. So passwords are never being pulled in, Cache Refresh just creates a cache of aggregated and processed user attributes (hence the name). Authentication still happens against those backend LDAP servers. Though, technically-wise, there is no obvious obstacle to prevent you from doing what you want (to have complete user entries with passwords inside of Gluu and use its internal LDAP for authentication). And of course there is no way (AFAIK) to request passwords from Active Directory via LDAP interface, only with replication. So you probably indeed will need to employ basic multi-auth script to be able to authenticate both against internal directory and AD. For that to work you'll still need to pull in users from AD anyway, just without passwords.

...now proceeding to your last set of questions: 1. I think basic multi-auth script's installation instructions are a bit too much. You shouldn't need to add any python/jython libraries, should work just fine out of the box. You already know you also need to create a json configuration file in `/etc/certs`, its composition is pretty self-explanatory. Don't forget to ensure **"tomcat"** user is able to read it. Though the doc misses a vital step, as I see now. You can see that bind passwords in example json file are not in clear-text. You must encrypt them prior to putting in there, using command like this: `# /opt/gluu/bin/encode.py YOUR_PASS_IN_CLEARTEXT`. After script is added and configured, please proceed to the "Manage authentication" page to set it as default auth method, as installation docs suggests. A bit of advice: it's not unusual for users to lock themselves out of admin web UI when playing with authentication options, so I would suggest you to have another active web UI session in a different browser, while you'll be using your main browser to test login functionality; this way you'll be able to revert authentication options back to defaults if you'll lose ability to log in after changing them. 2. Yes, you can pull users once with CR, then disable it and manage them in Gluu from that moment on. The only stumbling block here - as Michael has mentioned - is different password-related issues. You'll need to find some strategy how to import them into OpenDJ

Thank you Aliaksandr! To answer some of your questions and comments: > The part about using Gluu as a sort of aggregation LDAP directory which will be used by you services for authentication - how exactly do you expect this to work? Ideally, I want to use CR to easily transfer all the information from our main current LDAP (LDAP-A) directory into Gluu. I'd let it continue to refresh until we test and re-point our services to the Gluu Server LDAP. Once they are working with Gluu, then I would like to stop the CR for that server only, and permanently shut down the old server (LDAP-A). At the same time, I need to add the AD server in a "normal" CR setup, with AD handling authentication, caching attributes (and possibly modifying those attributes in the process). I do understand that the strength of the Gluu Server is when using OpenID Connect, SAML or CAS. And we hope to move that direction with our services in the future. However, a couple of our most critical services only support LDAP, or SAML provides a reduced set of capabilities. So until they are changed, we still need to stick with LDAP authentication. While we won't be using all the strenghts of the Gluu Server to begin with, it will allow us to make use of them in the future. Right now, our "interface" for managing the existing "primary" LDAP (What I called LDAP-A above) is horrendous and not admin user friendly. That's why I'd like to transition that server completely to Gluu, since the Gluu interface would be a huge improvement. In addition to the Active Directory CR mentioned above, in the future, I want to start using two other LDAP servers in the "normal" CR way, where attributes are cached in Gluu, but actually authenticated on the backend servers. But that is "phase 2 or 3". > Did you somehow manage to pull hashed passwords into Gluu's LDAP using CR, and after that login with user entries created like that? Or were those passwords in clear-text format? It's still a bit new to me, it's not a regular way CR is used, and I don't think we tried something like that before. Yes. CR pulled the hashed (SHA) passwords into the new Gluu account. I just set this up again and verified that it works. After the sync, I was able to login to a service using the credentials that worked with LDAP-A. I then changed the password for this account in Gluu and then authenticated again successfully with the new password. Then I verified that the original LDAP server still had the original password. So it was clearly authenticating against the Gluu Server and not passing it through. I had also NOT setup anything in the Manage Authentication section. It still has the default settings for the local LDAP. (Note that after changing the password on the Gluu Server, the password changed from "SHA Hashed" to "SSHA-512 Hashed" as seen in Directory Studio.) As I work to setup AD (and eventually the other two LDAP servers) for CR, I'll need to figure out the basic multi-auth script. Your information about that is very helpful. Thank you! I think you've given me enough to get started, unless you see a real flaw in my plan. I'm open to suggestions of better ways, since I only know enough to be dangerous. :-) But I'll consider this closed... Until I get stuck in the process. :-) Thanks again!

Thanks for detailed answer, Brad. > Once they are working with Gluu, then I would like to stop the CR for that server only, and permanently shut down the old server (LDAP-A). That should be as easy as removing this server from sources in CR's configuration. >At the same time, I need to add the AD server in a "normal" CR setup, with AD handling authentication, caching attributes (and possibly modifying those attributes in the process). What I said before was said having the usual usage of Gluu framework in mind - when users' browsers are redirected to Gluu by remote parties and they are asked to authenticate before their attribute will be sent to those parties. I.e., users are being authenticated via interactions with web UI. In your case your apps will probably do LDAP BIND operations to Gluu's internal directory directly, those flows are, like, in orthogonal planes (hope you understand my point). In regular mode of operations java app on behalf of user does a series of LDAP search and a bind operation combined in a complex login flow. In your case you won't be able to use this functionality, as your app will "talk" ot Gluu on a much lower level. What I want to say is that functionality you configure on "Manage authentication" page is only mean something during web UI logins. Same goes for basic multi auth script, and any other authentication method you can find described in docs. Gluu is fully designed to authenticate users by presenting some kind of web UI to them, in interactive manner. Sorry if I'm repeating obvious things and just missed some of your points :) So if your intention is to also somehow incorporate user entries from AD into Gluu and make them usable for authentication purposes in one place, you'll have to find a way how to migrate their passwords too. Or you'll have to re-enter them manually for each such user entry. >Yes. CR pulled the hashed (SHA) passwords into the new Gluu account. I just set this up again and verified that it works. After the sync, I was able to login to a service using the credentials that worked with LDAP-A. I then changed the password for this account in Gluu and then authenticated again successfully with the new password. Then I verified that the original LDAP server still had the original password. That's really interesting, thanks again for conducting and sharing proper detailed investigation of this use case. Before we just speculated of this possibility sometimes, but there hasn't been an opportunity/need to try this. This may prove useful in certain scenarios for sure.

> That should be as easy as removing this server from sources in CR's configuration. On a second thought.. I'm not that sure. Let's say it this way: I can guarantee you that if server will be just inaccessible (for whatever reason), those entries won't be removed. But, AFAICR, even if one server out of set of several different backends isn't accessible, the whole CR machine will stop function, i.e. entries won't be deleted, but updates won't be pulled in either. But if you'll delete just one server from configuration.. Hm, if I understand CR's logic correctly, on the next pull attempt it will see a lot of entries in the hash table which are - from its updated point of view - are not any more present in the backend (and in case of several backends CR perceives them as a giant meta-backend of sort), so they very likely will be deleted. That may be a problem and needs to be tested first, I guess.

Thank you Aliaksandr! I do (now) understand your comments about the Active Directory passwords. That does confirm my testing. I was able to login to the Gluu dashboard with AD credentials, but the LDAP bind was not taking working correctly for the service I was testing. Your message confirmed what I was just starting to understand. I will continue to dig into SAML and CAS options that will probably work better with Gluu, but will require us to get by with reduced functionality in one of our services. One thing I came across while searching for options was the idea of using SASL to pass through the bind request to Active Directory. Please see: http://ltb-project.org/documentation/general/sasl_delegation I have no idea if this could be used on a Gluu Server or not. This particular method is based on OpenLDAP, so I'm guessing it would need to be tested using Gluu 3.0. Thank you for your patience as I try to learn and understand what all is possible. I am absolutely amazed at the great "community" level of support!!!

Hi, Brad. This SASL pass-through option looks pretty interesting to me, from a technician's perspective :) I would be grateful if you'll share you findings along this way in case you'll decide to head this direction. FYI, Gluu CE 3.0 is now officially released, so if you wish, you could give this idea a try.