O
oldapple

  • Feb 17, 2017
  • Joined Jan 6, 2017
  • 0 best answers
  • Hello, this seems to be an old message, but there was no solution found.. And I have exactly the same question. I need to change (this time on Linux), this particular exact text that appears inside the sign-in page:      "To better serve you, we encourage our Clients to register for an account."This exact text is in fact present in one and only one file:     ./include/i18n/en_US/templates/page/banner-client.yamlChanging this text in this file leads to nothing at a browser level, as was mentioned by "buck_rogers". The advice of "ntozier" is not applicable, since he is mentioning a different piece of text present in a different file. I first thought that the issue has to do with the caching on the Apache server side or on the browser side, but that's not the case. So any advice on how one could modify this text in such a way that the change becomes visible at the browser side, would be highly appreciated.Thanks ahead for any comment and best regards.Andy.

  • Hello Ntozier and Greezybacon, and thanks for replying!The link provided by Ntozier was not helpful, and the search base was correct. I was still unable to authenticate.. Shortly after I asked the question, I digged further and made a fast hack that solved my issue (I needed badly to put the LDAP auth in production, and did not care too much about the way I arrive to the goal). I leave here now a short memo on what I did, since maybe somebody else may find it useful.Basically, there were three issues that I workarounded, obviously not in a clean but still sufficient way: 1) the "defaults" array did not contain the right values of binddn, bindpw and that of the search base before the non-anomyous bind attempt;2) my schema 2307 needed to be adjusted to our particular user LDAP entry layout; 3) LDAP2.php also needed to have an extra bind added. These are the changes that I introduced:--- authentication.php.orig     2017-01-13 17.000000002 +0100+++ authentication.php  2017-01-13 17.000000002 +0100@@ -50,17 +50,17 @@         // A general approach for RFC-2307         '2307' => array(             'user' => array(-                'filter' => '(objectClass=inetOrgPerson)',-                'first' => 'gn',+                'filter' => '(objectClass=*)',+                'first' => 'cn',                 'last' => 'sn',-                'full' => array('displayName', 'gecos', 'cn'),+                'full' => array('displayName'),                 'email' => 'mail',                 'phone' => 'telephoneNumber',-                'mobile' => 'mobileTelephoneNumber',+                'mobile' => 'telephoneNumber',                 'username' => 'uid',                 'dn' => 'uid={username},{search_base}',-                'search' => '(&(objectClass=inetOrgPerson)(|(uid={q}*)(displayName={q}*)(cn={q}*)))',-                'lookup' => '(&(objectClass=inetOrgPerson)({attr}={q}))',+                'search' => '(&(objectClass=*)(|(uid={q}*)(displayName={q}*)(cn={q}*)))',+                'lookup' => '(&(objectClass=*)({attr}={q}))',             ),         ),     );@@ -134,6 +134,7 @@             'options' => array(                 'LDAP_OPT_TIMELIMIT' => 5,                 'LDAP_OPT_NETWORK_TIMEOUT' => 5,+                'LDAP_OPT_PROTOCOL_VERSION' => 3,             )         );         if ($this->getConfig()->get('tls'))@@ -149,6 +150,11 @@             putenv('LDAPTLS_REQCERT=never');         } +$defaults = $this->getConfig()->get('bind_dn');+$defaults = Crypto:($this->getConfig()->get('bind_pw'),+                      SECRET_SALT, $this->getConfig()->getNamespace());+$defaults = $this->getConfig()->get('search_base');+         foreach ($this->getServers() as $s) {             $params = $defaults + $s;             $c = new Net_LDAP2($params);--- include/Net/LDAP2.php.orig  2017-01-13 17.000000002 +0100+++ include/Net/LDAP2.php       2017-01-13 17.000000002 +0100@@ -1077,6 +1077,10 @@         // or a definitive failure.         while (true) {             $link = $this->getLink();++ldap_set_option($link, LDAP_OPT_PROTOCOL_VERSION, 3);+ldap_bind($link,$this->_config,$this->_config);+             $search = @[deleted]($search_function,                                       $link,                                       $base,In the end, authentication worked.

  • Hello, we are successfully using osTicket in one installation without a central directory. Currently we have to deploy one more instance of it, but the strong requirement is to interface it to an existing LDAP user base. So we proceeded with a new install and addition of the "auth-ldap" plugin.All the prerequisites were preinstalled, the installation went on without any glitches, and in the end "auth-ldap.phar" plugin was added. These are the technical details of our installation:OS: Centos 7 (1611)Mysql: mysql-community-server-5.6.35-2.el7.x86_64PHP: php-5.4.16-42.el7.x86_64osTicket: 1.10auth-ldap.phar plugin: 0.6.3LDAP server: openldap-2.4.40-13.el7.x86_64 (no anon bind, ldaps with K5 backend responding at port 636). This server perfecly works with SSSD on many nodes and, among other uses, provides authentication for a  Dokuwiki web site running on the same host where osTicket was just installed.This is how our typical user is defined inside LDAP:# LDAPv3# base <dc=example,dc=com> (default) with scope subtree# filter: uid=testus# requesting: ALL## testus, Users, example.comdn: uid=testus,ou=Users,dc=example,dc=comobjectClass: topobjectClass: inetOrgPersonobjectClass: posixAccountuid: testuscn: Andysn: AppledisplayName: Andy AppleuidNumber: 16055gidNumber: 21003loginShell: /bin/tcshhomeDirectory: /home/testustelephoneNumber: 008189934mail: andy.apple@example.comThe installation and enablement of auth-ldap.phar went smoothly, and we were able to obtain the green message after configuring the plugin. To get this green message, we had to specify "ldaps://ldap.example.com" in place of "ldap.example.com". The binddn and its password worked without problems. So far so good..Finally, I've tried to login into osTicket usting the existing LDAP user and its password. This did not work and the web server reported this error: PHP Fatal error:  Call to a member function bind() on a non-object in phar:///var/www/html/tt/include/plugins/auth-ldap.phar/authentication.php on line 220, referer: https://ticket.example.com/login.phpDigging a bit, I've discovered that this problem was occuring in the "getConnection" function inside "authentication.php", specifically some of "defaults" array entries were undefined before executing "bind" within this fragment of code:        foreach ($this->getServers() as $s) {            $params = $defaults + $s;            $c = new Net_LDAP2($params);            $r = $c->bind();            if (!PEAR:($r)) {                $connection = $c;                return $c;            }        }So I have set these:$defaults = 636;$defaults = false;$defaults = 'uid=bindus,ou=Users,dc=example,dc=com';$defaults = 'bindpassword';$defaults = 'dc=example,dc=com';Then I added into $defaults 'LDAP_OPT_PROTOCOL_VERSION' => 3(this setting is successfully used for Dokuwiki authentication on the same box).After that, the error message did not appear anymore, and the authentication process went much further. But the user was anyway not accepted ("Access denied" message). I then redfined the RFC-2307 schema as follows:        // A general approach for RFC-2307        '2307' => array(            'user' => array(                'filter' => '(objectClass=posixAccount)',                'first' => 'cn',                'last' => 'sn',                'full' => array('displayName'),                'email' => 'mail',                'phone' => 'telephoneNumber',                'mobile' => 'telephoneNumber',                'username' => 'uid',                'dn' => 'uid={username},{search_base}',                'search' => '(&(objectClass=posixAccount)(|(uid={q}*)))',                'lookup' => '(&(objectClass=posixAccount)({attr}={q}))',            ),        ),And then traced the issue to this point at function "authenticate":        if (!PEAR:($r))            return $this->lookupAndSync($username, $dn);This led me to the "lookup" function call inside lookupAndSync:            if (!($info = $this->lookup($dn, false)))                return;Which finally ported me to the search call defined in the "include/Net/LDAP2/Search.php"        $r = $c->search($lookup_dn, '(objectClass=*)', $opts);        if (PEAR:($r) || !$r->count())              return null;         So this search call ended without finding the user inside LDAP (but the bind went well with his password).===========================================To conclude, it seems that everything is almost working, but, most probably, I must have made some mistake with the schema definition. I will dig it further, but any hint/help at this stage would be highly appreciated. We are very much impressed with osTicket (use it at another organization), but in our current setup we absolutely need to interface it with LDAP. Thanks ahead for your help, and best regards!Andy.