ID: 25827 User updated by: pennington at rhodes dot edu Reported By: pennington at rhodes dot edu Status: Bogus Bug Type: LDAP related Operating System: Windows 2000 PHP Version: 4.3.3 New Comment:
[EMAIL PROTECTED]: I appreciate you posting your note about the unique way in which the "Domain Users" group is handled (I didn't know that at all - very interesting), I think my problem reported with this bug is actually a different issue. Even if I assumed that the number of groups returned by LDAP query is 1 less than the actual total (such as if the Domain Users group wasn't counted), I still can't get a listing of all AD groups. One of the groups, which seems to be selected at random (i.e. it is not always Domain Users) is simply left out. If I change the array loop to purposefully give me more members of the LDAP group array than the person actually has groups, I still don't get all of that person's groups. In other words, the problem isn't limited to the Domain User's group - LDAP through PHP simply does not let me see every one of the person's groups. For some reason (and it is related to the OpenLDAP libraries PHP uses), one of the groups, randomly selected, is always dropped. Previous Comments: ------------------------------------------------------------------------ [2004-04-20 07:55:33] info at dbnet dot com dot au Hi, I'm seeing your post 6 months too late, but let me alert you to something that I found after similar grief with AD. It turns out that ONE of the AD group memberships, (in our case 'Domain Users', in your case perhaps one of the others), is handled "differently" in AD. It will be the one listed as the "default" group when you look up a user in any AD admin tool, and incredibly it just doesn't get fed back to you by AD when you ask for the memberOf attribute using any standard LDAP technique. I vaguely remember an MSDN KB article describing an astonishingly complex workaround for victims of this behaviour using ADSI.. sorry I have no link to it now. Our solution was to accept that the so-called "default" group for each user is just not treated properly by AD in its LDAP interface. It's a special case. ------------------------------------------------------------------------ [2003-10-14 19:56:48] [EMAIL PROTECTED] We only wrap around the OpenLDAP libraries. So it's definately not PHP bug -> bogus. You should report this to the openldap folks, they propably already know about it or are very willing to fix it if it's not already fixed. Please let us know what the response is so we can possibly update the used openldap libraries in the win32 binaries build. ------------------------------------------------------------------------ [2003-10-14 14:08:51] pennington at rhodes dot edu OK, you're right, after a few minutes, I found an ldapsearch command that would work: ldapsearch -x -b "CN=_some_user_,CN=Users,DC=rhodes,DC=edu" -D "CN=_search_auth_user_,CN=Users,DC=rhodes,DC=edu" -H ldap://someserver.rhodes.edu -W The "memberof" attribute results look like this: memberOf: CN=STAFF_DL,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu memberOf: CN=Planning,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=FACSTAFF,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=Council,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu memberOf: CN=PRESIDENT,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=FACTBOOK,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=INFO_SERVICES,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=CABINET,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=Senior2006,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu memberOf: CN=NT Users,CN=Users,DC=rhodes,DC=edu memberOf: CN=NTSETUP,CN=Users,DC=rhodes,DC=edu memberOf: CN=Domain Users,CN=Users,DC=rhodes,DC=edu Again, only 12 results were returned rather than the 13 that exist there in Active Directory. However, I've started doing a count based on attributes found by ldapsearch and Softerra's LDAPBrowser (which I think also uses openldap) and found that people missing an attibute value in ldapsearch were missing the same value in LDAPBrowser. Anyway, I think what we are down to is one of two possibilities: 1) OpenLDAP's search tool is not receiving all attribute values for a particular search; or 2) Active Directory is not supplying the missing value when queried for it using LDAP but does reply properly when Microsoft admin tools are used. I guess we could solve this if someone knows a good, freely-available, non-openldap-based LDAP search utility. Regardless, this doesn't look like a PHP bug per se, thought it could be a OpenLDAP bug that has found its way into PHP with the rest of the OpenLDAP code... ------------------------------------------------------------------------ [2003-10-14 12:26:58] [EMAIL PROTECTED] There is no kerberos support in PHP ldap either, and that partially works, so why would you need it with the command line binary? ------------------------------------------------------------------------ [2003-10-14 11:59:27] pennington at rhodes dot edu It appears that ldapsearch at that URL is not compiled with Kerberos support, which may be required to search Active Directory LDAP servers. I'm still doing research, however... D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D pennington -k ldapsearch: not compiled with Kerberos support I tried it with just SASL and that wasn't appreciated either: D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D pennington -I ldap_sasl_interactive_bind_s: Unknown authentication method (86) additional info: SASL(-4): no mechanism available: Unable to find a call back: 2 Can anyone verify that Kerberos support is required to search Active Directory LDAP servers? Is anyone using the OpenLDAP ldapsearch program to search Active Directory LDAP servers? If so, what kind of command should I use to get ldapsearch to search Active Directory? I am using "CN=Users,DC=rhodes,DC=edu" for the Base DN, "CN=_search_value_" for the name to search for, and to bind to the Active Directory LDAP server, you have to use this string as the username: "CN=_authorized_user_,CN=Users,DC=rhodes,DC=edu" ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/25827 -- Edit this bug report at http://bugs.php.net/?id=25827&edit=1
