Couple of things to check: 1. Which version of Ubuntu you are using? 2. What httpd2 log saying? 3. Check if you are using https ( not http ).

503 is a very weird error... I've never seen that before. What cloud provider is this on? Is this a 64-bit server? I think you're using Centos, not Ubuntu, but still please provide the version.

I'm actually seeing the 503 on both CentOS and Ubuntu (sorry, I said debian in the OP). **Cloud Provider:** Azure. Vanilla VMs. **Versions:** - 14.04.3 LTS, Trusty Tahr - CentOS release 6.5 (Final) **HTTPS (not http):** yes **Logs:** **CentOS:** [Wed Sep 23 18:51:34 2015] [error] (111)Connection refused: proxy: AJP: attempt to connect to 127.0.0.1:8009 (localhost) failed [Wed Sep 23 18:51:34 2015] [error] ap_proxy_connect_backend disabling worker for (localhost) [Wed Sep 23 18:51:34 2015] [error] proxy: AJP: failed to make connection to backend: localhost **Ubuntu:** [Wed Sep 23 18:53:56.213343 2015] [proxy:error] [pid 8044:tid 139961538483968] (111)Connection refused: AH00957: AJP: attempt to connect to 127.0.0.1:8009 (localhost) failed [Wed Sep 23 18:53:56.213516 2015] [proxy:error] [pid 8044:tid 139961538483968] AH00959: ap_proxy_connect_backend disabling worker for (localhost) for 5s [Wed Sep 23 18:53:56.213599 2015] [proxy_ajp:error] [pid 8044:tid 139961538483968] [client 24.18.25.218:56853] AH00896: failed to make connection to backend: localhost

Ah, ok Azure has some weird network issues. See this article: https://github.com/GluuFederation/docs/blob/master/sources/faq/cloud-faq.md

So do I need to enter the internal IP or the external IP during setup.py?

If I understand correctly: 1. the host machine (outside the gluu server... vm?) needs the host-mapping (/etc/hosts) from url to the PRIVATE IP 2. the gluu vm needs the host-mapping (/etc/hosts) from url to PUBLIC IP 3. httpd.conf needs to change the `Listen` directives to `*:80` and `*:443` 4. httpd.conf needs to remove the `NamedVirtualHost` directive 5. https_gluu.conf needs to adjust the VirtualHosts to `*:80` and `*:443` Correct? I've done all the above, refreshed the browser (which required me to re-accept the ssl cert before continuing (good sign that changes did something)), but then promptly received the same 503 error again. I've _also_ tried the above _without_ changes 3, 4, and 5 above. Same 503

Another item that might be helpful, is that if I visit `https://auth.example.com`, I get redirected to `https://auth.example.com/identity/` first, and THEN get the 503

Hi, Bob. Just a few quick questions: 1) I haven't been able to understand your setup completely. Are you running 2 boxes, and try to access Gluu on one of them from the other host? On which of there 2 boxes you have desktop environment running, browser opened etc? Or you have Gluu installed on both of them, and attempt to access it from your other machine? 2) Could you please run "sudo netstat -lnpt" on both boxes (Ubuntu and CentOS, if you have Gluu installed on both of them, of course), and provide us its output?

Sorry, quick notice: for 2) make sure that gluu service is running

> Another item that might be helpful, is that if I visit https://auth.example.com, I get redirected to https://auth.example.com/identity/ first, and THEN get the 503 You are right, it sheds some light. This is because this redirection is set in Gluu's Apache config file (on centos it will be /etc/httpd/conf.d/https_gluu.conf). Further on the request is being handed off to tomcat, and that's when, I assume, your issues is being triggered (you can see it in logs you provided)

Btw, have you already tried to monitor /opt/tomcat/logs/wrapper.log (like, "tail -F /some/path"), while attempting to access the Gluu again? That could also help understand why tomcat is failing to serve these requests. If you'll spot some wierd/wron records in that log, feel free to post it here, or, if they are too bulky, you could use public hostings like pastebin, or google files.

@Aliaksandr, I have 2 separate machines on Azure -- auth1 and auth2 (auth1 is running centos, and auth2 is running ubuntu) -- just using both versions to be more thorough with my debugging. These are both VMs in Azure, command line only. My browser is running on my local desktop at my office which is where I'm getting the 503. Output of `sudo netstat -lnpt`: **CentOS** Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:11211 0.0.0.0:* LISTEN 30529/memcached tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 941/rpcbind tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 1167/dnsmasq tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1598/sshd tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1031/cupsd tcp 0 0 0.0.0.0:50399 0.0.0.0:* LISTEN 959/rpc.statd tcp 0 0 100.118.100.77:16001 0.0.0.0:* LISTEN 1216/python tcp 0 0 :::11211 :::* LISTEN 30529/memcached tcp 0 0 :::1389 :::* LISTEN 30603/java tcp 0 0 :::111 :::* LISTEN 941/rpcbind tcp 0 0 :::80 :::* LISTEN 31023/httpd tcp 0 0 :::53 :::* LISTEN 1167/dnsmasq tcp 0 0 :::47637 :::* LISTEN 959/rpc.statd tcp 0 0 :::22 :::* LISTEN 1598/sshd tcp 0 0 ::1:631 :::* LISTEN 1031/cupsd tcp 0 0 :::36217 :::* LISTEN 30603/java tcp 0 0 :::1689 :::* LISTEN 30603/java tcp 0 0 :::443 :::* LISTEN 31023/httpd tcp 0 0 :::4444 :::* LISTEN 30603/java tcp 0 0 :::1636 :::* LISTEN 30603/java **Ubuntu** (auth2) Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 10.79.10.86:16001 0.0.0.0:* LISTEN 804/python tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 9420/memcached tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1524/sshd tcp6 0 0 :::4444 :::* LISTEN 9467/java tcp6 0 0 :::1636 :::* LISTEN 9467/java tcp6 0 0 :::1389 :::* LISTEN 9467/java tcp6 0 0 :::80 :::* LISTEN 9843/apache2 tcp6 0 0 :::40594 :::* LISTEN 9467/java tcp6 0 0 :::22 :::* LISTEN 1524/sshd tcp6 0 0 :::1689 :::* LISTEN 9467/java tcp6 0 0 :::443 :::* LISTEN 9843/apache2 The IPs listed above (ubuntu: 10.79.10.86, centos: 100.118.100.77) are Azure's internal/private IPs.

Well, something is really out of order. I can't see Gluu's tomcat listening on usual ports (AFAIK it will always be 8005 and 8009). So the question now is why your tomcat isn't listening. When stopping/starting service, do you see notifications like "stopping/starting tomcat"? Could you now do the following: 1) Rename aforementioned wrapper.log to something like wrapper.log.bak 2) Stop and start gluu service again. It should recreate the log when it won't find it. 3) Now check the log, not with tail, but with less or cat, to see full length of it. If we are lucky, you'll see java-related errors, like insufficient memory allocation, or permissions or anything.

A couple more questions: 1) How much memory do these boxes have? Gluu is quite memory-needy application, and we usually recommend to dedicate at least 4GB for it (but I must admit my test instances are run quite well with 1,5GB for tomcat's allocations and 2,5GB assigned to the vm, so it shouldn't be an issue) 2) Were these vms perfectly clean at the moment you installed Gluu to them? Or had they been already in use by other services/packages of similar nature? 3) Aside from (still somewhat misterious to me) modifications to httpd.conf you have mentioned, have you tried to customize some other modules/services on these boxes, too?

Plus: try to run "/etc/init.d/tomcat status" from within Gluu's chroot-ed container (i.e. after running "service gluu-server login") - what does it say?

A remark: no need to restart gluu service as a whole, to see updated wrapper.log, I think. You can restart (or, if previous command will show it isn't running - start) just tomcat with "/etc/init.d/tomcat stop/start"

A thought just have crossed my mind, as I also have remembered a couple of other wierd issues which also were related to running Gluu server in some cloud-hosted vms. My unpleasant past experience with GoDaddy's hosting services taught me that some hosting service providers can be quite stingy when it comes to HDD access rate limits, even for their virtual machine rental services. So, can it be, that due to very low disk access speed Gluu's tomcat just takes and eternity toload and start, and you, thinking it just doesn't work at all, restart its service again and again, thus not even giving it a chance? For example, have you waited long enough after starting service before running netstat I asked you to? Mb we can't see it's ports open because it's still in starting state?

Agreed. Is this a 2GB RAM server? http://www.gluu.org/docs/admin-guide/getting-started/#minimum-server-requirements We should ask this question before we even provide support...

@aleksandr I'm working on your other questions, but for your last one, yes, I've waited for it to start. When I ran netstat about 2 hours after the last restart of Gluu.

How much RAM and CPU does this server have?

It looks like it was low for sure. I've just changed it and am working on testing it again.

Ok, lots of updates: 1. updated the VM to have 3.5 gigs of RAM (not sure how this wasn't already the case, because I thought I set it, but it is now) 2. `netstat` appears to be looking better now (details below) 3. yes tomcat is running 4. yes the VMs were perfectly clean before installing gluu (and still are other than the debugging we've been doing) 5. no, other than the apache config tweaks, I haven't made any other changes 6. we're still getting working SSL 7. we're still getting working apache redirect (from `/` to `/identity/`) 8. the 503 is gone, but now replaced with a 404 9. wrapper.log doesn't get any new info when refreshing the browser 10. if I start at `/identity/` apache logs don't get any new info 11. if I start at `/` then apache logs get the following entries [Thu Sep 24 00:55:45 2015] [warn] [client 65.55.244.47] incomplete redirection target of '/identity/' for URI '/' modified to 'https://auth1.example.com/identity/', referer: http://auth1.cloudapp.net/ [Thu Sep 24 00:55:48 2015] [warn] [client 24.18.25.218] incomplete redirection target of '/identity/' for URI '/' modified to 'https://auth1.example.com/identity/' [Thu Sep 24 00:55:48 2015] [warn] [client 24.18.25.218] incomplete redirection target of '/identity/' for URI '/' modified to 'https://auth1.example.com/identity/' New netstat output: Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:11211 0.0.0.0:* LISTEN 1874/memcached tcp 0 0 0.0.0.0:44203 0.0.0.0:* LISTEN 992/rpc.statd tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 974/rpcbind tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 1199/dnsmasq tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1219/sshd tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1064/cupsd tcp 0 0 127.0.0.1:32000 0.0.0.0:* LISTEN 2573/java tcp 0 0 100.118.114.55:16001 0.0.0.0:* LISTEN 1233/python tcp 0 0 :::11211 :::* LISTEN 1874/memcached tcp 0 0 :::36431 :::* LISTEN 992/rpc.statd tcp 0 0 :::111 :::* LISTEN 974/rpcbind tcp 0 0 :::80 :::* LISTEN 4716/httpd tcp 0 0 :::53 :::* LISTEN 1199/dnsmasq tcp 0 0 :::22 :::* LISTEN 1219/sshd tcp 0 0 ::1:631 :::* LISTEN 1064/cupsd tcp 0 0 :::443 :::* LISTEN 4716/httpd tcp 0 0 ::ffff:127.0.0.1:8005 :::* LISTEN 2573/java tcp 0 0 ::ffff:127.0.0.1:8009 :::* LISTEN 2573/java

I think you need to re-review the notes for apache on https://github.com/GluuFederation/docs/blob/master/sources/faq/cloud-faq.md This could indicate a problem with the host names pointing at the wrong interfaces.

Before we proceed I must be sure about one thing. Are you currently working with the Gluu instance that undergone customizations you mentioned (I'm citing them below for clarity)? 1. the host machine (outside the gluu server... vm?) needs the host-mapping (/etc/hosts) from url to the PRIVATE IP 2. the gluu vm needs the host-mapping (/etc/hosts) from url to PUBLIC IP 3. httpd.conf needs to change the Listen directives to *:80 and *:443 4. httpd.conf needs to remove the NamedVirtualHost directive 5. https_gluu.conf needs to adjust the VirtualHosts to *:80 and *:443 If you do, is it possible to rebuild it from scrach (i.e., reflash the OS, than reinstall Gluu stricly following installation guide)? I must admit I still can't get what you were trying to achieve with items 3 to 5. Regarding hostnames and mappings: as you are accessing it from a totally different machine, the only mappings you should care about is the ones that affect Gluu running in its own closed chroot-ed container. I.e. the ones you set after "service gluu-server login". If you are assigning a resolvable dns name to that host (meaning, while running setup.py you assing it to the "hostname" parameter), I think you don't need to edit /etc/hosts, but you should make sure /etc/resolve.conf has all entries it needs to resolve your resolvable dns name. But it of course won't hurt to put it into the /etc/hosts too, just in case (for the sake of testing); if your just making up your hostname, then you of course must put it in hosts and map it to this box's ip address (on which your apache is listening). Second, regardless, of what kind of name for your machine you have chosen, you must change hostname to it, too. And must make sure it persists. For CentOS it seems it isn't enough to just run "hostname _name_", you must edit /etc/sysconfig/network file to persist the change. In ubuntu, afaik, running hostname command is enough. Remember, all these changes must be done from within chroot-ed container. That's about all you usually need to get a running instance of gluu, no modifications of apache configs are needed (actually, strictly recommended against)

@Mike, I've studied that faq harder than I care to admit. It's really not terribly clear. If you could update it to be more clear and more specific about what needs to be done, it might be helpful. (when mentioning IPs specify public or private ip. when mentioning hosts files, specify inside or outside the gluu container. when mentioning edits to config files, specify exactly what changes, not just generic pseudo-code.) @Aleksandr, my latest tests were done on the same servers, but I ran a setup.py again which reset all of the apache configs. All 5 of the above steps were required in order to get a response. At this point, I'm starting to wonder if what really needs to happen is maybe you guys need to set up your own VM in azure and document the special steps needed to get things working properly. It will be MUCH faster than going back and forth on here especially when I'm not familiar with Gluu to begin with.

Sorry, I missed that one: > the gluu vm needs the host-mapping (/etc/hosts) from url to PUBLIC IP What do you mean by "public ip"? Are your machines hidden behind some NAT?

Sorry, Bob, I have to take back my remarks about your customizations. I have little experince working with Azure/Amazon vms, so I didn't know there are special circumstances. You should follow this guide Mike has provided, then. And I think you are right when suggesting us to give it another look, mb it indeed lacks clarity, or doesn't represent current situation well. If you'll be able to solve your issue before that, we would be gratefull if you would share it with us and with the rest of community.

I'll definitely share with you if I figure it out before you do. (I've already spent 3 days on it, though, so it's gonna be tough to justify spending any more time when I still haven't even seen it and don't know if we actually want to use it or not :/ )

Ok, we're going to try setting up an instance on Azure. We might even be able to update community-edition-setup to a certain extent if we can figure out what is so unconventional about Azure.

Hi, Bob Just want to notify you that I was able to setup Gluu CE at azure without any problems. I will try to run it with different set of configuration options now, to be sure all is taken into account, and then will provide you guidlines how to do it. Please stay with us a little longer. Regards, Alex.

And the other issue is that not all cloud network setups are the same. Perhaps Bob is using virtual private clouds (VPC using Amazon jargon...) or some other network security configuration?

Nope. Nothing out of the ordinary. Just a plain vanilla VM attached to a cloud service.

Hi Bob. Okay, these steps worked for me each time, regardless of chosen OS: 1) After logging in to windowsazure administrative panel at http://manage.windowsazure.com/, choose "Virtual Machines" tab, click the "Create a Virtual Machine" link 2) Chose "Compute -> Virtual Machine -> From Gallery" branch from menus 3) Choose "Ubuntu" from the list to the left, then "Ubuntu Server 14.04 LTS", click the "Next" arrow button (I also tried OpenLogic's flavor of CentOS 6.7 offered there; btw, note that it comes with selinux set to "Enforce" by default; though I was able to login and complete a couple of simple tasks, I'm not aware whether Gluu is already prepared for selinux; perhaps Mike can answer; if you'll choose it and encounter any problems later on, you could try to switch it to permissive mode and see whether it will help) 4) On the next page make sure "9/9/2015" release date is selected, provide a name for a vm in "Virtual machine name" field, (which will then become a hostname; it should be just a host's name, without any DNS suffixes), use "Standard" for "Tier" (it worked with "Basic" too for me), in "Size"dropdown select at least "A2" variant, equpped with 3.5GB of RAM; provide username you will use to connect via ssh to it, set access password, or upload certificate for passwordless auth; click the "Next" arrow button 5a) On the next page you will have a choice either to reuse existing cloud service, or to create new; for the sake of testing it, I recommend to create it again, same goes for storage account option; I didn't tested it with "Availability Set" feature added, so set it to"None" for now; I used "Central US" for affinity, you can probably use any region. 5b) Now, relly important part - the "Endpoints" section. Thats where port forwarding is set so your internal ip address could be selectively reachable for the outside world. By default, only ssh tcp 22 port is there, you must add public ports http and https (tcp ports 80 and 443) too, mapped to the same private ports. Depending on your previous activity, and, perhaps, on what you have selected for options on that page, http/https ports mappings you have added may be flagged as being in conflict with already existing mappings. I even saw it flagged like that when I didn't have any existing vms (as I removed them not so long ago), but latter on they became available again, so odds are the "lock" on these ports may sometimes persist longer than it should. In that case proceed without setting mappings, you should be given a chance to set them after you have created vm; click the "Next" arrow button 6) On the next page choose to not install "VM Agent", as you probably don't need it anyway, and we don't need any additional, possibly troublesome, software; click the "tick"-button to finalize your vm, and wait until it's ready. 7a) If you was forced to proceed without setting port mappings on step 5b), now it's time to give it another try. Choose "Virtual Machines" from the menu to the left, find the one you've just created in the list and click on the small "arrow" link next to its name to get into vm's management menu. Select "Endpoints" tab there. Add all endpoints mentioned above by clicking "Add" cross button at the bottom. It should work this time, or you will have to contact service's support in case problem won't go away after some time. 7b) Now go to the "Dashboard" tab of the vm's management panel. Scroll down there untill you'll see part where ip addresses and DNS names are supplied. Copy the "DNS Name" line from there - this is the name you'll be using in the browser to access your Gluu instance. 8) Now you are ready to ssh into the box and install Gluu server. On connection, elevate your priveleges to root with "sudo -i" and follow this guide link(http://www.gluu.org/docs/admin-guide/deployment/ubuntu/) strictly to install Gluu CE. 9) After switching to chroot-ed environment and running ./setup.py from there, provide settings for it as follows: a) for ip address just hit "Enter", so it will use the private ip of the box for it (unless you are running a box with 2 interfaces, then some additional configurations may be needed) b) for the hostname use the "DNS name" you've acquired on step 7b) (full string with hostname and suffixes) c) choose to update host/hosname for ubuntu, but don't do that when setting up Gluu on CentOS - it seems to not work properly there (I'm writting a bug report on that); on CentOS you will have to manually update /etc/sysconfig/networking file by adding full DNS name you acquired at step 7b) there, to persist the hostname. d) you can leave other settings at their defaults, or set them as you wish; but please remember, that we recommend setting tomcat's allocation limits to at least 4G for production environments (so the box should have at least 5-6GB of physical memory); and you must use 64bit OS for running Gluu e) complete the setup 10) Do not modify any config files other than mentioned above, like the ones mentioned in that guide you tried to follow - it doesn't seem to represent current situation well. 11) Now you should be able to connect to the host from your working PC by using that DNS name from step 7b)

Thanks for the *very* detailed instructions, William. Unfortunately, this didn't help. This is how I've installed Gluu every time I've attempted it, but I followed these instructions again just to be sure. I followed them very closely. I set it up on a 64-bit VM with 4 cores and 7GB of RAM, so it should have more than enough. This is an Ubuntu 14.04LTS system. I configured tomcat with 4gb max. I get the same thing as usual. Have to accept a "bad" SSL (I assume since it's self-generated), then get redirected to /identity/ and then, just like before, a 404 not found and a blank page. (the only way I knew it was a 404 was by opening the console).

Ok... I think I know what it is. It very likely a default browser security setting that is messing you up. Try from another browser like Chrome, Firefox, IE or Safari (whatever you're not using...)

Still a 404. (default: chrome, also tried: microsoft edge)

404 is a not found in your browswer. Are you sure you updated your local windows host file in c:\windows\system32\drivers\etc\hosts You need to edit this file as administrator (i.e. right click on notepad.exe and "Run as administrator")

Wait, the hosts file on my browsing machine? My local desktop? Why in the world would I need to do that!? The url I'm hitting is already in public DNS (as proven by the fact that I get an SSL warning AND by the fact that I get redirected from `/` to `/identity/`). Even if it _is_ necessary for some reason, what would I point it to that's different than public DNS already has? I'm not familiar with the internals of gluu's container, but as far as I can tell in this situation, this isn't a DNS issue. Apache seems to be handling requests fine. It seems to me like it's tomcat and/or the `/identity/` route specifically that's having an issue. Seeing as the previous 503 error had an Apache "signature" (text at the bottom of the page showing apache version number), the fact that the 404 page is *completely* blank suggests to me that the 404 is coming from Tomcat, which in turn suggests a problem with the `/identity/` route.

Just 2 more suggestions/questions: 1) Have you tried to completely remove your browsing history (cookies of all sorts, to be precise)? If not, could you do it, and try to log in again? 2) While following guide will posted, did you reuse the vm from your previous installation attempt? If you did, could you create a fresh new one, and follow this guide again? While composing it, I'm personnally repeated all steps at least 4 times, trying both Ubuntu and CentOS - and it worked perfectly, every time.

1) Yes, I have, but that's not the problem. The problem is with the server, NOT the browser. 1b) Just to be clear, this isn't a problem with logging in. I can't even get that far. I can't get ANY webpage from gluu. **nothing at all** 2) Yes. Brand new, fresh server.

> I get the same thing as usual. Have to accept a "bad" SSL (I assume since it's self-generated), then get redirected to /identity/ and then, just like before, a 404 not found and a blank page. If my suggestions above won't help, the next step will be checking the logs. As your tomcat is clearly listening now, there has to be something in them. You will need "tail -F" each of the logs below and try to login, and see what will pop up there. If you see something suspicious - put it here, or put it on pastebin, and let us know: Directory: /opt/tomcat/logs/ Files in it: wrapper.log, oxauth.log, oxtrust.log

I checked those 3 logs and they were **FULL** of errors. I wasn't sure which ones were related to setup and which ones were related to web requests, so I did the following: 1. renamed them all to *.log.bak 2. logged out of the container 3. stopped the gluu-server 4. started the gluu-server (`service gluu-server restart` is broken, btw, hence the separate stop/start commands) 5. started a tail on one of the logs 6. refreshed my browser and watched The browser took an inordinate amount of time to do anything, but the logs were going crazy, so I let it go. After a **solid 60 seconds** (this is on a 4-core, 64-bit server with 7gb ram), I was surprised to see a login page pop up in my browser! I don't know why that worked, but it did. I don't know why other service restarts didn't fix it, and I'm not sure why resetting the logs fixed it, either, but something fixed it. :) NOW... I don't see anything in the documentation about a default username/password (or place to configure it) for this page. What's the next step? 

That's a relief. I hope it will run without additional issues now. Default username is "admin", and default password is the one you have specified during setup.py phase, there is parameter named "password for oxtrust and ldap root user" (they are actually 2 different passwords, but right after installation they will be equal), or, if you didn't provide one, it's autogenerated value (it's being displayed in square brackets by script). Right after installation all its settings are saved in /install/community-edition-setup/setup.properties.last, you can fetch your password from it.

Excellent. Thank you :) Is that default username in the documentation somewhere?

Ok. That username and password doesn't work. I've confirmed the password by looking in setup.properties.last. All I want to do is **look** at what gluu has to offer, and that's taken a week now -- I haven't even started trying to integrate with it. I really appreciate all the help guys, but I think your product is simply too young at this point in time. If it takes me a week just to preview it, I can't even imagine the amount of work it's going to take to maintain it... If you guys get things figured out and reliable, please let me know.

If you didn't write down the "admin" password, you can grep for ldapPass in /install/community-edition-setup/*.last

Bob, I can understand your frustration, but, still, you must admit, that most of the problems you've encountered were caused not by Gluu's "youth" (what can't be true, as our solution has been being used for many years by many corporate clients over the world), but by somewhat misleading/incomplete information you got from docs portal. First, you selected a vm that didn't meet Gluu's minimal requirements. Then you followed an outdated guide, and after that some issues of unknown nature followed, which I was not able to reproduce, so we can blame MS/Azure for that, as not a single installation of Gluu I did (and I have done several dozens of them already) had such problems from the first minutes, except for broken builds (and build in this case was fully functional). Docs at the moment can often seem not descriptive enough, or appear outdated, I give you that. That's why not so long ago a project aiming to renew and expand documentation portal was started. Though I admit that blame for what you had to endure can partly be laid on us, please accept my apologies for that.

I agree that this long thread indicates that the Gluu Server is probably not a fit for you. In fact, you haven't even gotten to the hard part--integrating the applications. You should probably consider using a SaaS SSO provider. In fact, Gluu is working on a SaaS offering which we expect to launch by year end.