Category: External Authentication (LDAP, AD, PAM, CAS, etc)

I am referencing forum post: https://tiki.org/tiki-view_forum_thread.php?comments_parentId=43682&topics_offset=1

I would like the ability for users in child domains to access the TikiWiki site the same way users in the parent site are able to access it. According to the forum post, "Tiki is not currently capable of authenticating against multiple domains (or multiple LDAP servers)" and "The code could be modified to search, say, the global catalog for the user's DN and then authenticate against the corresponding domain, but this would be custom coding"

I would like an option to specify multiple domains, or a custom code I could use to search the global catalog for the user's DN.

Basically I want all of my users in all of my offices to access the Tiki site. Not just the home office users.

I was unable to get group sync for ldap working, and after changing two lines of code in userslib.php I was able to get it working.

The changes I made are the __procedure__ section, and I have included my settings also in case someone is having a similar issue, or is just trying to set up LDAP group sync and would like to see a working example, and in case it is useful in your troubleshooting.

When editing an external group (a group created automatically by tiki when syncing groups with ldap) the isExternal flag which should be set to Y is set to N.

Context:
User logs in, and tiki groups are syncing with a OU on the AD, so a group is added. Say this group is "tiki-admin".
We want users part of the group tiki-admin on the AD to have admin perms on the wiki, so we edit the group in tiki and set it to inherit permissions from the local Admin group. When you hit the "Save" button after editing the group (you don't have to change anything) the group's isExternal flag is set to "n", meaning it will not sync like an external group.

Users added to the group in the AD will be added to it in tiki, but users removed from it in the AD will not be removed from the group in tiki.

This tracker is made to help filtering and sorting the features vs categories vs options we need to tag a bug/regression/wish with.

Should already be supported since we use PEAR::AUTH
http://pear.php.net/package/Auth

Needs testing and confirmation.

Installed a fresh tikiwiki 17.1.
Enabled and configured LDAP.

When trying to login, getting this error in frontend:
"Authentication error"

Had to login second time in order to be logged in.

Here are the LDAP logs:
{CODE(theme="default")}UserLib::validate_user_ldap()
Connect Host: ldap://192.168.1.1:389. Binddn: acovali@magna.global at line 225 in /srv/www/htdocs/wiki/lib/auth/ldap.php
Searching for user information with filter: (sAMAccountName=acovali) at line 278 in /srv/www/htdocs/wiki/lib/auth/ldap.php
Connect Host: ldap://192.168.1.1:389. Binddn: CN=First Last Name,OU=IT,OU=Accounts,OU=PFT,OU=America,OU=Cosma,OU=Magna Group,DC=magna,DC=global at line 225 in /srv/www/htdocs/wiki/lib/auth/ldap.php
Bind successful.
UsersLib::ldap_sync_user_data()
UserLib::disable_tiki_auth(){CODE}


Analyzed /lib/userslib.php, line 904 - 932

It's not getting in "if ($result == USER_VALID)" because $result is a string that is a username
{CODE(theme="default")}$result = $this->add_user($user, $pass, $email);{CODE}

If I replace it with
{CODE(theme="default")}$result2 = $this->add_user($user, $pass, $email);{CODE}

$result now would get value from
{CODE(theme="default")}$result = $this->validate_user_ldap($user, $pass);{CODE}


So this edit fixed the issue, and I was able to be logged in after first login attempt
{CODE(theme="default")}$result2 = $this->add_user($user, $pass, $email);{CODE}

Hello all.

Almost by chance I noticed a behavior which seems wrong regarding the LDAP authentication on TikiWiki 2.0. I'm not sure if it was already present in 1.9.11 but I don't think so. We migrated last week.

Regarding the TW configuration:

- authentication method is "Tiki+PEAR::Auth"
- users cannot register and cannot change password
- "Create user if not in Tiki?" is on
- "Create user if not in Auth?" is off
- "Just use Tiki auth for admin?" is on
- The LDAP auth configuration paramters are correct, the auth itself works well, as it worked in 1.9.11. When TW connects to the LDAP server (OpenLDAP 2.1.30) the authentication works as expected.

This means that a Tiki account is created when LDAP users login for the first time. As expected, in presence of such a user, TW connects to LDAP, authenticates, creates Tiki account and logs the user in (I have some doubts in this last item though). However, when users log in again after this, I would expect that authentication is still delegated completely to the LDAP and is not done through Tiki. Instead, I have confirmed by looking at my LDAP logs that when TW finds a Tiki account, it authenticates the user through Tiki and never connects to the LDAP. This is not the expected behavior, because it means that passwords are being stored on the TW database and actually used for authentication. As a consequence, when a user changes his password on the LDAP, this is not "seen" by TW.

I'm pretty sure this is not the intended behavior also because if I go to Admin Users, both the "edit user" and the "add user" boxes show the following:

"No password is required
Tikiwiki is configured to delegate the password managment to LDAP through PEAR Auth."

And actually, the "edit user" box also says "Warning: changing the username will require the user to change his password" which is a contradiction since the password should be managed by LDAP and my TW is configured to disallow users from being able to change their passwords.

Paulo

The "LDAP external group" settings are not correctly used.

In lib/userslib.php around line 1320.
The array "ldap_group_options" is filled with the data for a search on the groups in ldap.
Later on "ldap->get_groups" is called with this options.

Inside "ldap->get_groups" the first action is to call "get_user_attributes".
But now the configuration is set up for the group search, means the search for the user attributes is done with the ldap configuration (host,port,basedn,...) from the "LDAP external groups".

Usually (with a single more or less unstructured ldap) you will not notice it.
But if you have a separate ldap or at least another "scope" for the groups, this will fail, because it will not find the user-attributes in the ldap where the groups are.

I have not thought about a fix yet ... first I wanted to report it :-)

Besides this, there are some harmless typos in lib/userslib.php: auth_ldap_groupdescattr is with one "t" only in some places.

We are using LDAP authentication at our site and the email field is not being automatically filled in. This means we must manually setup our email for each user for the page change notifications to work.


Note we are connecting to an ActiveDirectory LDAP database which does not like anonymous binds so had to make a patch based on the following suggestion:

http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=58&forumId=6&comments_parentId=14021

Our Active Directory is configured not to allow arbitrary LDAP searches for unprivileged users. However, these users can successfully bind to AD's LDAP interface. This would be enough for authentication and we would not need a special account for checking authentication.

I therefore removed parts of the function fetchData in /lib/pear/Auth/Container/LDAP.php:

{img src=images/code.png}%%% {CODE()}
function fetchData($username, $password)
{
$this->log('Auth_Container_LDAP::fetchData() called.', AUTH_LOG_DEBUG);
$err = $this->_prepare();
if ($err !== true) {
return PEAR::raiseError($err->getMessage(), $err->getCode());
}

$err = $this->_getBaseDN();
if ($err !== true) {
return PEAR::raiseError($err->getMessage(), $err->getCode());
}

// UTF8 Encode username for LDAPv3
if (@ldap_get_option($this->conn_id, LDAP_OPT_PROTOCOL_VERSION, $ver) && $ver == 3) {
$this->log('UTF8 encoding username for LDAPv3', AUTH_LOG_DEBUG);
$username = utf8_encode($username);
}

/* // make search filter
$filter = sprintf('(&(%s=%s)%s)',
$this->options['userattr'],
$this->_quoteFilterString($username),
$this->options['userfilter']);

// make search base dn
$search_basedn = $this->options['userdn'];
if ($search_basedn != '' && substr($search_basedn, -1) != ',') {
$search_basedn .= ',';
}
$search_basedn .= $this->options['basedn'];

// attributes
$searchAttributes = $this->options['attributes'];

// make functions params array
$func_params = array($this->conn_id, $search_basedn, $filter, $searchAttributes);

// search function to use
$func_name = $this->_scope2function($this->options['userscope']);

$this->log("Searching with $func_name and filter $filter in $search_basedn", AUTH_LOG_DEBUG);

// search
if (($result_id = @call_user_func_array($func_name, $func_params)) === false) {
$this->log('User not found', AUTH_LOG_DEBUG);
} elseif (@ldap_count_entries($this->conn_id, $result_id) >= 1) { // did we get some possible results?

$this->log('User(s) found', AUTH_LOG_DEBUG);

$first = true;
$entry_id = null;

do {

// then get the user dn
if ($first) {
$entry_id = @ldap_first_entry($this->conn_id, $result_id);
$first = false;
} else {
$entry_id = @ldap_next_entry($this->conn_id, $entry_id);
if ($entry_id === false)
break;
}
$user_dn = @ldap_get_dn($this->conn_id, $entry_id);

// as the dn is not fetched as an attribute, we save it anyway
if (is_array($searchAttributes) && in_array('dn', $searchAttributes)) {
$this->log('Saving DN to AuthData', AUTH_LOG_DEBUG);
$this->_auth_obj->setAuthData('dn', $user_dn);
}

// fetch attributes
if ($attributes = @ldap_get_attributes($this->conn_id, $entry_id)) {

if (is_array($attributes) && isset($attributes['count']) &&
$attributes['count'] > 0) {

// ldap_get_attributes() returns a specific multi dimensional array
// format containing all the attributes and where each array starts
// with a 'count' element providing the number of attributes in the
// entry, or the number of values for attribute. For compatibility
// reasons, it remains the default format returned by LDAP container
// setAuthData().
// The code below optionally returns attributes in another format,
// more compliant with other Auth containers, where each attribute
// element are directly set in the 'authData' list. This option is
// enabled by setting 'attrformat' to
// 'AUTH' in the 'options' array.
// eg. $this->options['attrformat'] = 'AUTH'

if ( strtoupper($this->options['attrformat']) == 'AUTH' ) {
$this->log('Saving attributes to Auth data in AUTH format', AUTH_LOG_DEBUG);
unset ($attributes['count']);
foreach ($attributes as $attributeName => $attributeValue ) {
if (is_int($attributeName)) continue;
if (is_array($attributeValue) && isset($attributeValue['count'])) {
unset ($attributeValue['count']);
}
if (count($attributeValue)<=1) $attributeValue = $attributeValue[0];
$this->log('Storing additional field: '.$attributeName, AUTH_LOG_DEBUG);
$this->_auth_obj->setAuthData($attributeName, $attributeValue);
}
}
else
{
$this->log('Saving attributes to Auth data in LDAP format', AUTH_LOG_DEBUG);
$this->_auth_obj->setAuthData('attributes', $attributes);
}
}
}
@ldap_free_result($result_id);


// need to catch an empty password as openldap seems to return TRUE
// if anonymous binding is allowed
*/ $user_dn = $username;
if ($password != "") {
$this->log("Bind as $user_dn", AUTH_LOG_DEBUG);

// try binding as this user with the supplied password
if (@ldap_bind($this->conn_id, $user_dn, $password)) {
$this->log('Bind successful', AUTH_LOG_DEBUG);
// check group if appropiate
if (strlen($this->options['group'])) {
// decide whether memberattr value is a dn or the username
$this->log('Checking group membership', AUTH_LOG_DEBUG);
$return = $this->checkGroup(($this->options['memberisdn']) ? $user_dn : $username);
$this->_disconnect();
return $return;
} else {
$this->log('Authenticated', AUTH_LOG_DEBUG);
$this->_disconnect();
return true; // user authenticated
} // checkGroup
} // bind
} // non-empty password
// } while ($this->options['try_all'] == true); // interate through entries
// } // get results
// default
$this->log('NOT authenticated!', AUTH_LOG_DEBUG);
$this->_disconnect();
return false;
}
{CODE}

If would be nice to have a checkbox in the LDAP part of the admin page for selecting this behaviour.

LDAPv2 is obsolete, and the use of LDAPv3 is now standard practice. In fact, the [http://www.openldap.org/faq/data/cache/822.html|latest releases of OpenLDAP don't even support LDAPv2 properly anymore]. However, PHP's ldap_connect() and PEAR::Auth [http://www.openldap.org/lists/openldap-software/200204/msg00046.html|default to LDAPv2].

The patch to use LDAPv3 is attached. It shouldn't be difficult to make the LDAP protocol version a configurable preference.

With the switch from Pear Net_LDAP2 to Zend\Ldap, the LDAP authentication to the AD is broken in Tiki 19.1.
With exactly the same configuration as with Tiki 18.3, I get this error message in the Action Log:
{CODE(theme="default")}Error: 0x31 (Invalid credentials; 80090308: LdapErr: DSID-0C090400, comment: AcceptSecurityContext error, data 52e, v1db1): sAMAccountName=wiebe.oudshoorn,cn=users,dc=moba-bv,dc=local at line 262 in D{CODE}

I have done some research with WireShark to inspect the packages from and to the LDAP server, when someone logs in to the wiki:

Tiki 18.3:{img fileId="1287" thumb="box"}

Tiki 19.1:{img fileId="1288" thumb="box"}

It's very clear where this is going wrong. It's trying to do a bind request with only the username instead of username@domain.url (row 355 in 18.3 screenshot vs row 239 in 19.1 screenshot ).
Although LDAP bind type is set to 'AD', so according to lib\auth\ldap.php row 184 it should add the correct information to the bind request instead of performing a 'plain' bind.


My LDAP settings:
{img fileId="1289" thumb="box"}

Not detailed here as per security protocol.

Hi All,

I’m working on the Tikiwiki 2.2 with a LDAP authentication.

In the login option, I see it is possible to automatically give someone access in the Tiki if this person is in LDAP directory.

My question is: Is it possible to define access with a Distribution List group and not with the entire LDAP directory?

On another note, do you know why “LDAP Member is DN” can not be set to “yes?”

Thanks for your response

in file tiki-admin_include_login.php
if (isset($_REQUEST["auth_pear"])) {
check_ticket('admin-inc-login');
simple_set_toggle('auth_create_user_tiki');
............
....
.....
missing 2 lines below.
simple_set_value('auth_ldap_emailattr');
simple_set_value('auth_ldap_countryattr');

Missing database entries for ldap email and country

System environment:
Tiki 6
Windows Server 2008 64bit
Apache x64 2.2.11
PHP x64 5.2.5 (lib/smarty/libs/internals/core.is_secure.php patched to make it work)

LDAP authentication against AD does work once configured properly
BUT
Debugging the configuration was hard because turning on logging caused errors!
When logging is off, all is well. When logging is on and line 346 of lib/auth/ldap.php is commented out, all is well.
It seems that when logging is active, "$filter->asString()" on that line causes an error on our system. The same call is made on line 262 with a simpler filter and works OK.

Perhaps when checking groups, asString is returning too much for the logging system to handle?

There was an issue with the LDAP not syncing groups properly, and would thus cause a blank page to appear when logging into my site.

Essentially, the entire problem is attributed to a typo in the function name for the ldap_sync_groups function. The file ~/lib/userslib.php contains the function:

{CODE()} private function _ldap_sync_groups($user, $pass)
{...}{CODE}
The major problem is that this function name has a leading underscore (_) and causes an issue when it attempts to sync the groups with the LDAP.

Simply removing the underscore solves the whole problem. The function should be named as such:

{CODE()} private function ldap_sync_groups($user, $pass)
{...}{CODE}
This will make it so that when the file reaches the line:

{CODE()}$ret &= $this->ldap_sync_groups($user, $pass);{CODE}
It can successfully sync with the LDAP.

Hi,

We've been using the LDAP to authenticate our users ever since we created our site a couple years ago. We've run into a few road bumps along they way, but this time I can't seem to figure out the issue that is occurring with the LDAP. The main issue that I am seeing here is that the LDAP doesn't appear to be syncing with our groups.

If I attempt a log in on my normal admin account, it appears to allow me to log in as if it's recognizing that I am a user, but while it logs me in, the groups aren't being synced. This results in an error that says "You do not have permission to view this page." So I logout of that account and log back in with the default admin account (which seems to be the only account still working without the LDAP group sync). When I check the Users list, I can see that even my normal admin account has been completely removed from the groups I previously belonged to before my login attempt.

Therefore, this leads me to believe that the issue is with the ldap_sync_group functions somewhere inside the lib/userslib.php file. I've tried a couple of workarounds, but to no avail. Has anyone experience anything like this?

Please help, as this is completely breaking my Tiki installation!

The LDAP syncing is the major problem here. I have tiki 12.2 installed, and everything works fine with the system. But when I attempt the upgrade to 12.3 on my development site, run the composer and installer, and upgrade the database, the LDAP seems to break and I cannot log in to the site using any account at all -- not even the default admin account. When I get to the login screen after finishing the installer process, I enter my username and password and it returns with the error "Invalid Username or Password." Again, the same thing happens with the default admin.

I submitted a post on the forum asking if anyone else had the same problem and I had a response where someone was indeed experiencing this as well. He offered a solution where I go into the file ~/lib/auth/ldap.php and comment out an error checking routine on lines 235-240, and this actually allowed me to login to the upgraded version. However, when I did this, it essentially broke the login authentication system, and you could log in as any user no matter what password credentials were entered. So, while this temporary solution did allow me to login to the site, it did not work as anticipated, as I believe it broke the TLS and/or LDAP authentication itself.

Behavior for ldap should be as follows:
#if user added to group in AD, added to group in tiki when log in
#if user removed from group in AD, removed from group in tiki when log in

1 is working fine, but 2 is broken. This is hard to demonstrate, as I can't really hook my AD up to a demonstration instance, but I have it set up in my tiki 11 install, and it works perfectly, but is not working on the latest 12.x pulled from svn (r49012 atm).

Another, problem that can cause the same symptoms, but is not the cause of the behavior above, is that when you edit an external group via -+tiki-admingroups.php?group=<group>+- the isExternal flag in
the users_groups table gets set to "n" for that group. This means that if you change the description of an external group in tiki, or set that group to inherit, or even don't change anything but click "Save" on the group options page, the group will no longer be treated as external, and you will see 2 break again. I submitted [https://dev.tiki.org/item4398|item4398] about this a while ago, but I figured I'd dump it here as well.

Login with user "admin" doesn't work when CAS authentication is enabled.

That's what the mod descritpion says:
{CODE()}
author: mcfarland
last modification: 2006/12/22 01:49:26
by: mcfarland
features/phpcas/COPYRIGHT -> lib/phpcas/COPYRIGHT
features/phpcas/README -> lib/phpcas/README
features/phpcas/source/CAS/CAS.php -> lib/phpcas/source/CAS/CAS.php
features/phpcas/source/CAS/PGTStorage -> lib/phpcas/source/CAS/PGTStorage
features/phpcas/source/CAS/PGTStorage/pgt-db.php -> lib/phpcas/source/CAS/PGTStorage/pgt-db.php
features/phpcas/source/CAS/PGTStorage/pgt-file.php -> lib/phpcas/source/CAS/PGTStorage/pgt-file.php
features/phpcas/source/CAS/PGTStorage/pgt-main.php -> lib/phpcas/source/CAS/PGTStorage/pgt-main.php
features/phpcas/source/CAS/client.php -> lib/phpcas/source/CAS/client.php
features/phpcas/source/CAS/domxml-php4-php5.php -> lib/phpcas/source/CAS/domxml-php4-php5.php
features/phpcas/source/CAS/languages/english.php -> lib/phpcas/source/CAS/languages/english.php
features/phpcas/source/CAS/languages/french.php -> lib/phpcas/source/CAS/languages/french.php
features/phpcas/source/CAS/languages/greek.php -> lib/phpcas/source/CAS/languages/greek.php
features/phpcas/source/CAS/languages/languages.php -> lib/phpcas/source/CAS/languages/languages.php
{CODE}

And that's what it says to me when attempting to install it:
{CODE()}
Warning: mkdir(lib/phpcas/source/CAS/PGTStorage): File exists in c:\archivos de programa\easyphp1-8\www\branch-1-9\lib\mods\modslib.php on line 68

Warning: copy(mods/features/phpcas/source/CAS/PGTStorage/pgt-db.php): failed to open stream: No such file or directory in c:\archivos de programa\easyphp1-8\www\branch-1-9\lib\mods\modslib.php on line 375
features/phpcas/source/CAS/PGTStorage/pgt-db.php to lib/phpcas/source/CAS/PGTStorage/pgt-db.php impossible to copy
{CODE}