The oxTrust password reset feature is for small deployments, where the Gluu LDAP is used to store passwords. We don't recommend that oxTrust (the admin UI for Gluu) be Internet facing, except in small deployments. If some other system can update passwords in AD for you... use that.

Thanks for your response. In which case, any idea what I am may be doing wrong in the customization process to get that link to redirect to my Moodle password reset page? Why did you close my ticket? Do I need to resubmit it?

You can still comment on it, but I closed it to signal to the Gluu support team that this is not a priority issue. If you want priority answers, perhaps budget for a Gluu support contract.

I would love to have a support contract but I work in K12 Education and your support contracts are apparently designed for large corporations that have endless finances. Thank you for explaining the closing of the ticket though. It is sad that it is done that way as other people that might want to help me will think it has been resolved when I still actually need help.

Gluu is overwhelmed with support requests. We're trying to figure out how to get the community more involved in helping each other. One of our ideas is to create mailing lists by state or country, or perhaps by industry. We're a relatively small company--30 people. So we have to be tactical about the kinds of issues we engage on. It is implicit that when you use the open source community edition, you will primarily self-support. We do our best to help organizations, but we're not a charity.

The moodle forums are amazing with excellent community support. It used to be that if you posted to a particular area, you were automatically subscribed to that forum (e.g customization, installing, etc). Now you can subscribe to individual posts. If you started something like that where when people posted they automatically received all posts to that particular section, it might be a start...if people received new posts in their email that they could just reply to, I think you would get the community starting to respond. I would be happy to help people where I could and most open source people are like that...

Good idea... I'll send this the support portal team. The Gluu Support forums can be a firehose, and we don't want to overload people with spam.

Hi, Emma. Regarding the page customization issue - I can't reproduce it in my test 3.1.6 instance. I see changes I do to `/opt/gluu/jetty/oxauth/custom/pages/login.xhtml` file at my default login page. You shouldn't need to delete the original files, neither to restart anything. 1. Do you use any custom scripts in your setup? If you try to change a custom login page the script uses, you may need to mimic the entire directory structure it uses under `/opt/gluu/jetty/oxauth/custom/pages/` directory. 2. Have you set proper user rights to the file(s) you copied under `/opt/gluu/jetty/oxauth/custom/pages/`? Please run `# chown -R jetty:jetty /opt/gluu/jetty/oxauth/custom/pages/` to be sure >I am confused why Gluu docs say that it cannot change passwords on an active directory server when my moodle and joomla sites have no problem with that at all I suppose you're talking about a feature which would allow you to change password in AD via a control in Gluu's web UI? Please correct me otherwise. Cache Refresh used in Gluu Server to pull in user accounts from external LDAP servers is by design a very simple, one-direction system. It just pulls in and caches user entries, to save a lot of resources that would be spent to constantly call external databases each time Gluu needs to release user's data (hence the name). It's not designed to be "tightly coupled" with the external directory. Adding some code implementing such a procedure to web UI would require a considerable investment, especially taking into account that different directories may require slightly different procedures for that. But Michael can explain this much better, I believe. If you would like to have such a feature in some custom authentication script, it's not impossible. Until you are able to conduct this operation (a password change) remotely somehow (AFAIK, AD allows update of user password via LDAP, which is fairly simple to script in python), you can add some extra logic implementing it yourself. That's not something we can provide support for within bounds of Community Support, though.

Thank you so much for your help. On going back through everything, I realized that there are two places in the file that reference the forgot your password - changing the second one resolved it. I knew I had to be missing something simple. I will think about the custom script for a long term solution but for now at least I have people getting to a password reset page that is functional. Thank you again.