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

{syntax type="tiki" editor="plain"}
Scenario:
TikiWiki version 4.1
Auth against LDAP
LDAP being used: Novell eDirectory

Problem:
user can not log in unless the complete DN of the user is specified.
In my scenario the users are spread across the complete tree, so no chance to provide a specific "User DN", additionally a "Base DN" needs to be specified in order restrict the search to the city where the service runs. Finally only the default option provided at the "LDAP Bind Type" seems to be correct for eDirectory.

How this has been solved:
1.- The code modified has been: lib/auth/ldap.php
2.- If the LDAP connect operation fails, then a try to search for the user is triggered
3.- if the user is found then the LDAP, the his/her DN is extracted and a new LDAP connect is performed.

Here the diff of the modified code:
{CODE(colors="php")}diff -uN ldap.php ldap.php.new
--- ldap.php 2009-10-30 16:53:31.000000000 +0100
+++ ldap.php.new 2010-01-13 22:28:18.000000000 +0100
@@ -200,6 +200,50 @@

$this->ldaplink= Net_LDAP2::connect($options);
if(Net_LDAP2::isError($this->ldaplink)) {
+ /* This modification is placed in order to add a kind of e-Directory compatibility.
+ For e-Directory and according to what I found about documentation - please consider I'm not an expert on this matter -
+ e-Directory will only get a positive result for the user search (with is password) only if the dn is pointing to the place where
+ the user object has been created, so we need first to find this data.
+ In the next lines the user data will be searched, and once found (if found) the info related to binddn will be updated
+ */
+ // filters to locate the user
+ $filter1=Net_LDAP2_Filter::create('objectClass','equals',$this->options['useroc']);
+ $filter2=Net_LDAP2_Filter::create($this->options['userattr'],'equals',$this->options['username']);
+ $filter=Net_LDAP2_Filter::combine('and',array($filter1,$filter2));
+ if(Net_LDAP2::isError($filter)) {
+ $this->add_log('ldap','LDAP Filter creation error: '.$filter->getMessage().' at line '.__LINE__.' in '.__FILE__);
+ return false;
+ }
+ $searchoptions=array('scope' => $this->options['scope']);
+ // unset the binddn, if set then the connect will fail
+ unset ($options['binddn']);
+ $this->ldaplink= Net_LDAP2::connect($options);
+ if(Net_LDAP2::isError($this->ldaplink)) {
+ $this->add_log('ldap','Error: '.$this->ldaplink->getMessage().' at line '.__LINE__.' in '.__FILE__);
+ return($this->ldaplink->getCode());
+ }
+ $searchresult = $this->ldaplink->search($this->options['basedn'],$filter,$searchoptions);
+ if($searchresult->count()!=1) {
+ // More then 1 user ... problem
+ $this->add_log('ldap','Error: ldap search found this amount of useres:'.$searchresult->count().' which is not 1. at line '.__LINE__.' in '.__FILE__);
+ return false;
+ }
+ $entry=$searchresult->shiftEntry();
+ if (Net_LDAP2::isError($entry)) {
+ $this->add_log('ldap','Error fetching user entries: '.$entry->getMessage().' at line '.__LINE__.' in '.__FILE__);
+ return($this->ldaplink->getCode());
+ }
+ // Set the binddn again
+ $options['binddn']=$entry->dn();
+ // Try again now with the correct binddn
+ $this->ldaplink= Net_LDAP2::connect($options);
+ if(Net_LDAP2::isError($this->ldaplink)) {
+ $this->add_log('ldap','Error: '.$this->ldaplink->getMessage().' at line '.__LINE__.' in '.__FILE__);
+ // return Net_LDAP2 Error codes. No need to redefine this.
+ return($this->ldaplink->getCode());
+ }
+ // The rest of the code gets encapsulated in the else
+ }else {
$this->add_log('ldap','Error: '.$this->ldaplink->getMessage().' at line '.__LINE__.' in '.__FILE__);
// return Net_LDAP2 Error codes. No need to redefine this.
return($this->ldaplink->getCode());
@@ -371,5 +415,5 @@
if($this->options['debug'])
$this->logslib->add_log($facility,$message);
}
-
+
}
{CODE}

References:
[http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=19&topics_sort_mode=lastPost_desc&forumId=17&comments_parentId=32433|Info in TikiForum]
[http://www.codeproject.com/KB/system/eDirectoryAuthentication.aspx|Info about eDirectory]

Hope this could be a kind of contribution
TalindoChe

When using OpenID + Registration CAPTCHA...
With Tiki 2.2...

I attempted to register using my OpenID:

#On the Login page, I entered my OpenID.
#My OpenID was validated and Tiki shows the page where I can either associate my OpenID with an existing Tiki account, or register as a new user.
#I completed the registration form (including the correct CAPTCHA), but Tiki keeps saying that the Anti-bot code was incorrect.

Additionally, the registration form presented with the OpenID __does not__:
*Display the password minimum requirements (such as number of characters).
*Allow for the selection of groups.


__Duplicate of {wish id=1505}__

For sites with open content it's very important that a visitor who came through a link from search engine or somewhere else would have minimum problems with adding new information to the wiki.
My personal example: I have a blog on livejournal.com and now plan to create a homepage based on tiki, but I don't want to make all of my friends from LJ to pass registration on my site. Even if they all would, it's unreal to make them all use the same logins as there.

Active Directory doesn't allow for anonymous searches of its structure. Instead, an username and password for an account with search access must be given when connecting.

Hi,

After pulling in the newest code from the trunk (as of r56661), I am experiencing a permissions error that is being caused by the LDAP not syncing with my groups properly.

When I attempt to log in to my site, it allows me to log in, however when I get to the home page it simply gives me an error message that reads "You do not have permission to view this page." The only way I am able to see anything on the site is through the default admin account (but this is because it does not need to be authenticated externally).

I have been unable to find a solution to this, but this was working for me just before the weekend. Also, I am unable to do a tiki demonstration due to the nature of the LDAP, so please contact me if there are any questions about my set up.

Any help would be greatly appreciated. Thanks.

{syntax type="tiki" editor="plain"}
The ldap_sync_user_and_groups function is missing the $user and $pass arguments (types, or whatever you call them). This means that when using LDAP the user will not be added to the LDAP groups and the user's information (name, email, etc) will not be populated. I have a fix listed below, but I don't know if it will break something else.

The login settings page should be refactored to eliminate the presentation of unneeded configuration options.

userslib.php is actually a mess where AuthPAM, PEAR and CAS have been pasted inside, my idea is to rewrite userslib.php with the idea of "modular authenticators" that is, having a directory like lib/userslib/ put there authlib_cas.php, authlib_pear.php, authlib_pam.php and tikiauth.php (for the builtin tiki's authentication).

The goal is that a user can create a new authlib_*.php file for his own purposes (actually I need one for Active Directory via php-ldap and another for our customers database) without the need of touching userslib.php at all, so upgrading would be much easier, and writting your own authenticator would be really much easier than now.

I'm currently working on that on BRANCH-1-9 as that's the one I use at the office but userslib.php from 1.9 to HEAD is untouched so no issues come with that.

My plan is to initially split userslib.php into cas, pear, pam and the builtin modules (a lot of work there!) then rewrite the Login section of the admin panel so it adapts to it's new nature.

The ways to preserve environment I've tought are: being able to enable/disable any module at any time, having only the current 3 enabled by default, and set what would be the new "authenticators_order" preference to meet the current possible situations also retaining preferences.

What I still don't know how to handle is:
* How an authenticator can create/delete it's preferences from tiki_preferences when enabled/disabled (is there any tikilib function to create/delete preferences?)

Comments are welcome!

(NOTE: I'm not sure that this tracker is the place for that.. I saw it's a TODO... am I right?)

I don't know whether it's a regression or not.

There is a feature called "Show user's real name instead of login in autocomplete selector in trackers feature" (Admin/Config Wizard > Community General Settings). I ensured that the user field in the tracker is set to display realname also instead of username. The feature works when listing items through the tracker itself of plugin trakerlist, etc., but ....

__....it does not do the job at the autocomplete selector for the filtering of items__.

See it reproduced here:
http://xavi-9794-5892.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1&status=o&sort_mode=created_desc&filterfield=10&filtervalue[10]=user1&filtervalue[2]=&filtervalue_other=&filtervalue[3]=&filtervalue_other=&filtervalue[4]=&filtervalue_other=&filtervalue[5]=&filtervalue_other=&filtervalue[6]=&filtervalue_other=&filtervalue[7]=&filtervalue_other=&filtervalue[8]=&filtervalue_other=&filtervalue[9]=&filtervalue_other=&filtervalue[11]=&filter=Filter#

u: admin
p: 12345

This can disclose taxID's or other not-so-public information in LDAP setups.

I have configured "tiki and pear::auth" in the login section of tikiwiki on a server which did not have the pear php libraries installed.
Next time I try to login with a user (not admin), I see a blank page.

This happens because on line 756 of file lib/userslib.php
$a = new Auth("LDAP", $options, "", false, $user, $pass);
just dies without any error message.

In Tiki it is not possible to create tracker items automatically from a remote system. There is no way to include/connect Tiki to a external system.
It would be good if Tiki could be used as frontend and/or database to some automation via M2M (machine to machine) communication.

As example, in Sharepoint you can add list-items via a https-call (API-call). In my environment i used Sharepoint as database and frontend to manage and document backups, which is legally mandatory for us. For that i use some Powershell scripts that do the backups and create a list entry in a Sharepoint list via a API call (https with authentication).
This is also relevant if you like to have a frontend for e.g. (hardware) production and distribution where you can use a barcode scanner that fires a API-call to Wiki to list a parcel in a Tiki tracker.
And so on, and so on, the usage cases are really unlimited and it's a very important function, heavily used in e.g. big Sharepoint Intranet applications.

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.