Missing ldap-attributes when using PHP

UCS - Univention Corporate Server
#1

Hi there!

iam trying to modify some values within my ldap using php.
I can connect and query without any issues. But i can’t seem to find a way to get the “univentionFreeAtrributes” as part of my search query.

Using univention-ldapsearch on the cli gives different results then using the ldap_search from php.
No matter if i specifically asking for the attributes, they just don’t get delivered.

Any ideas?

Thanks!
//Christian

#2

On a UCS system there are actually two LDAP servers running: one on port 7389 with the OpenLDAP schema and one on the default LDAP port 389 with the ActiveDirectory schema (provided by Samba). There’s a component called the univention-s4connector which synchronizes entries bidirectionally between the two instances. However, not all objects and attributes are present in both.

The command univention-ldapsearch automatically uses the one on port 7389. You likely used the default settings when connecting from PHP, and therefore ended up on the ActiveDirectory one. Therefore the results are different. The univentionFreeAttribute* attributes are ones that aren’t synchronized between the two instances; they’re only present in the OpenLDAP server on port 7389.

I’ve written more about this in this article if you want more information about it (in German only).

#3

Hi Moritz,
thank you for your quick response!

I’ve tried to confirm what you’ve said, but i failed :slight_smile:

Here is my sample code:

>     private function printAttributes($ldapServer, $baseDN, $reader, $readerPW, $searchUID)
>     {
>         $connection = \ldap_connect($ldapServer);
>         $isBound = false;
>         if (ldap_set_option($connection, LDAP_OPT_PROTOCOL_VERSION, 3)) {
>             if (ldap_set_option($connection, LDAP_OPT_REFERRALS, 0)) {
>                 if (ldap_start_tls($connection)) {
>                     $isBound = ldap_bind($connection, $reader, $readerPW);
>                     if (!$isBound) {
>                         if (ldap_get_option($connection, LDAP_OPT_DIAGNOSTIC_MESSAGE, $extended_error)) {
>                             throw new Exception("Error Binding to LDAP: $extended_error <br />");
>                         }
>                     }
>                 }
>             }
>         }
> 
>         if ($isBound) {
>             $sr = ldap_search($connection, $baseDN, '(cn=' . $searchUID . ')');
>             $ent = ldap_get_entries($connection, $sr);
>             $count = count($ent[0]);
> 
>             print "Printing all attribute types ($count)<br/>";
>             for ($i = 0; $i < $count; $i++) {
>                 if (!isset($ent[0][$i])) {
>                     continue;
>                 }
> 
>                 print $ent[0][$i] . "<br/>";
>             }
>         }
>     }

No matter which port i’am using with ldap_connect, i always get the same results (72 attributes to be specific).

Any ideas?

//Christian

#4

Your code example doesn’t include any port numbers, nor does it show an example how your printAtributes function is called (meaning what $ldapServer is set to). The \ldap_connect function expects the port number as the second argument or as part of a full LDAP URI.

Edit: what I mean is that you’ll have to use \ldap_connect("my.ser.ver", 7389) or \ldap_connect("ldap://my.ser.ver:7389") according to the documentation. It also states that solely using \ldap_connect("my.server.de:7389") won’t work as that isn’t a full LDAP URI.

#5

As i said, example code :wink:

$connection = \ldap_connect($ldapServer);

Uses the default port 389.

I’ve also tried:.

$connection = \ldap_connect($ldapServer, 7389);

$ldapServer contains ‘ldap://fqdn’

//Christian

Edit:
NVM, i fixed it!
After i have read your edit, i realised i mixed 2 things here, specifically the ldap-uri and the default fqdn.

After trying to connect using ldap_connect(“fqnd”, 7389); results are as expected.
Thank you very much!!

//Christian

#6

Sorry to open up an older thread, but I have a similar situation, where a php search gives back fewer attributes, than when i do the same search in command line.
I have read about the ports and double checked that. I feel certain there is a difference in the searches, but don’t know what exactly the problem is. I have removed my actual server name, basedn and username.

Command line univention-ldapsearch -h ldaps://my.ser.ver -p 7636 uid=username gives back what I am searching for, for example the attribute “mailAlternativeAddress”
Note: Command line univention-ldapsearch -h ldaps://my.ser.ver -p 7636 cn=username returns no result.

In php, I have tested with this code now. It returns 38 attributes, but for example not “mailAlternativeAddress”:

<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);
$ldap_conn = ldap_connect( 'ldaps://my.ser.ver', '7636' ) or die("Sorry! Could not connect to LDAP server");
ldap_set_option($ldap_conn, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($ldap_conn, LDAP_OPT_REFERRALS, 0 );
$result = ldap_bind( $ldap_conn, 'Administrator@ser.ver', 'PasswordHere' ) or die("  Error: Couldn't bind to server using provided credentials");
$result = ldap_search($ldap_conn,"dc=ser,dc=ver", "(cn=username)"); //WHY cn
// $result = ldap_search($ldap_conn,"dc=ser,dc=ver", "(uid=username)"); NO RESULT
$info = ldap_get_entries($ldap_conn,$result);
	
		print "info:<pre>";
		print_r($info);
		print "</pre>";
	ldap_close($ldap_conn);
?>

Would be great if anyone can shed a light upon this. Thank you in advance.

EDIT: I don’t think it will make any difference, but the scripts are running (in a mixed environment) on as member with UCS 4.4, querying a primary with UCS 5.

Mastodon