Documentation  »  Features  »  Admin Panels  »  External Authentication  »  LDAP authentication

Support forum

http://tikiwiki.org/forum17

Bug reports and feature requests

http://dev.tikiwiki.org/LDAP

LDAP Authentication up to Tiki 3.X

LDAP Pear::Auth General Settings Overview

Tiki can authenticate users using a LDAP server via Pear::Auth (see http://pear.php.net/package-info.php?package=Auth) . The following settings only make sense, if you have set "Authentication method" to " Tiki/Pear::Auth " in the above dialog. Tiki then uses the LDAP server in addition to its own user database (users_users) to authenticate users. Your Php must have ldap support on (debian: php4-ldap, php5-ldap, ....)

The LDAP Group and LDAP Member settings are currently not used by Tiki (as of 1.10 rc).

If your admin page does not contain all the fields listed above, reference LDAPUseInPriorVersions for information on how to modify versions of tikiwiki prior to 1.9.8 to use LDAP.

LDAP Pear::Auth Troubleshooting

You can verify your connection by editing the file \tiki\lib\pear\Auth\Container\LDAP.php in line 441 (for tw < 4) from

$this->options['debug']       = false;

$this->options['debug']       = true;

281: Connecting with host:port
288: Successfully connected to server
292: Switching to LDAP version 3
306: Switching LDAP referrals to true
312: Binding with credentials
325: Binding was successful
548: UTF8 encoding username for LDAPv3
574: Searching with ldap_search and filter (&(sAMAccountName=exampleuser)(objectClass=*)) in ou=europe,dc=xnet,dc=oe,dc=examplehost
581: User was found
636: Bind as CN=exampleuser,OU=users,OU=ode,OU=europe,DC=xnet,DC=oe,DC=examplehost
640: Bind successful
650: Authenticated

Be ware that after your troubleshooting you must switch off the debug option to login.

LDAP Authentication in Tiki 4.0

Changes

The LDAP Authentication part has been rewritten in Tiki 4.0. Tiki no more uses PEARs Auth due to the lack of flexibility and missing features - PEARs Auth is not intended to be able to fetch any other LDAP entries than the user entry. Now it uses PEAR LDAP2.

List of changes:

• The words "PEAR Auth" and "Auth" have been replaced by "LDAP" in code and web frontend
• A proxy user (ldap admin) is no more needed to authenticate
• You can add more redundant LDAP servers in your configuration
• The use of ssl or tls is supported now (needs some more testing)
• You can specify the type of LDAP Server (Active Directory, Openldap, ...)
• User and Group information can be replicated to tiki on every user login. Therefore you can reuse data already present in your LDAP directory
• Users replicated from LDAP have now disabled tiki passwords to avoid having ghost users in tiki that are deleted in LDAP

How it works

If a user enters his username and password in tiki, a binddn is created and together with the password used to authenticate the user at the ldap server. Once authenticated the user is allowed to read data from the ldap server. Especially he usually can read his own data and the ldap group information. These data are used to create the user and group in tiki. The user has the tiki password disabled. He only can login via LDAP. On subsequent logins, the data are synchronized from LDAP to tiki (not the other direction!). The replicated data can be at the moment:

• Users full name
• Users email address
• Users country information
• Users group membership
• Group name and description

So if you change any of the above information in LDAP, the data are synchronized the next time the user logs into tiki. You can even change group membership in LDAP and it gets sychronized to tiki. What is not replicated to tiki are object (usr/group) deletions.

Group membership and permissions

One useful use of LDAP with groups is to give users from specific groups more permissions. Since every user created in tiki is assigned to the build in group "Registred", you should give "Registred" the same permissions like "Anonymous". You may want to give some LDAP usergroups special permissions. Let one user of that group login to tiki to automatically create the group. Then assign permissions to that group.

How anonymous binding works

- connect anonymously to the LDAP server - get the user DN - authenticate the user by binding with the server as DN + password

Settings

How to know which LDAP Bind Type you need to use

- Active Directory bind method will build a RDN like where your basedn is (dc=domain, dc=com) and username is your username - Plain bind method will build a RDN username - Full bind method will build a RDN like userattr=username, userdn, basedn where userattr is replaced with the value you put in 'User attribute', userdn with the value you put in 'User DN', basedn with the value with the value you put in 'base DN' - Openldap bind method will build a RDN like cn=username, basedn - anonymous bind method will build an empty RDN

If you do not know, the best is to use a tool to access the directory like Apache Directory Studio If you can enter your directory with your email, it is probably an Active Directory If you can access with your username, it can be plain, full, or openldap After with your tool navigate to select a user, the DN of the user will be shown and you will be able to guess the method

Some tips: - You can not build a RDN/DN like this "sAMAccountName=username,dc=domain,dc=com". If you would like to do so because the CN is the real name and not the username, it is probably because you have choosen the wrong bind method (it can be an active directory method) - Use always he search scope subtree at the beginning - as soon as you are sure of your parameters use antoher method for performance

How to get the email and other attributes back in tikiwiki

Tiwiki builds another DN to get the attributes. This time, tikiwiki uses a search and not a bind. The DN is userattr=username, userdn, basedn where userattr is the attribute you put in 'User Attribute', username is the username, userdn the value you put in 'User DN' and basedn is the value you put in basedn. This time you can use sAMAccountName in the attribute (it is a search not a bind). Then put the attribute name you see in the DN taht contains the mail

Examples

Unix

These settings should work on most Unix systems that use LDAP for authentication and as information store:

Active Directory

Zimbra LDAP

Debugging

Check the box at "Write LDAP debug Information in Tiki Logs:" and try to authenticate in another browser. Check Tiki Logs (tiki-syslog.php) to see what went wrong.

ATTENTION: Uncheck the debug settings once you managed to set up your connection. Your logs will get flooded else!

If this even does not help, you can use this code to check whats wrong:

<?php
$con = ldap_connect('ldap://my_hostname:389');
ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);
ldap_set_option($con, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($con, LDAP_OPT_REFERRALS, false);
$dn = 'cn=username,dc=domain,dc=tld';
if(ldap_bind($con, $dn,'verrry_secret'))) {
  echo "connec succeeded";
  //and if you want to test the mail
  $filter = '(objectClass=*)';
  $just = array('mail'); // adapt the attribute name
  $sr = ldap_search($con, $dn, $filter, $just);
  $info = ldap_get_entries($con, $sr);
  print_r($info);
} else {
  echo "Oops!";
}
?>

Replace Hostname, Port, binddn and password and run it with php connect.php

Present the output your LDAP Administrator.

Useful tool: Apache Directory studio

Common Problems and Workarounds

Certificate Problems

If you use certificates on LDAP server side where the root certificate is not trusted, you should put the root or CA certificate somewhere at your tiki webserver and let /etc/openldap/ldap.conf know where it is. Use parameters TLS_CACERTDIR and TLS_CACERT to point it to the root or CA certificate.

If you use self signed certificates you can also simply disable certificate checking by setting TLS_REQCERT to "never" in /etc/openldap/ldap.conf.

See the manpage of "ldap.conf" to get more information.

Aliases

• LDAP
• AD
• Active Directory