In my Active Directory, groups have a member attribute that contains the DNs of all members.

I configured the Groups by entry section with the DN containing all my groups.

Wireshark shows that when this module tries to search the groups DN, it is trying to search for where member attribute is the current user's Drupal username. In my case, the Drupal username corresponds to the sAMAccountName of the user.

The value of the member attribute is DN of the account, not sAMAccountName.

CommentFileSizeAuthor
#29 fix_exploding_of_dn-417892-29.patch789 bytesjohnbarclay

Comments

miglius’s picture

miglius commented
Status: Active » Postponed (maintainer needs more info)
Issue tags: +ldapgroups

Do you use the latest version? The first search is performed on the full DN, and only if no results are found, the search is performed on the username:

190       $entries = $_ldapgroups_ldap->search($branch, $ldapgroups_entries_attribute .'='. $user->ldap_dn, array($ldapgroups_entries_attribute));
191       if (empty($entries) || $entries['count'] == 0)
192         $entries = $_ldapgroups_ldap->search($branch, $ldapgroups_entries_attribute .'='. $user->name, array($ldapgroups_entries_attribute));
aren cambre’s picture

aren cambre commented

I was on dev 3-26 and just now upgraded to dev 3-30.

Here's the order of messages when a user first logs in:

  1. bind using non-anon account
  2. bindResponse success
  3. searchRequest for base OU on sAMAccountName = Drupal user name
  4. searchResEntry with corresponding directory entry
  5. unbind
  6. bind using user's DN
  7. bindResponse success
  8. bind using non-anon account
  9. bindResponse success
  10. search on the groups OU for member=Drupal user name (won't work because the member attribute of groups has DNs, not sAMAccountNames)
  11. searchResDone with 0 results
  12. unbind
  13. bind with non-anon account
  14. bindResponse success
  15. search for the current user's directory entry
  16. searchResEntry returned with the user's directory entry
  17. unbind
  18. unbind (yes, happens twice)
  19. bind with non-anon account
  20. bindResponse success
  21. search for the current user's directory entry
  22. searchResEntry returned with the user's directory entry
  23. unbind
aren cambre’s picture

aren cambre commented

Here's further confirmation: the member attribute of groups uses DNs per Microsoft (link). Look at the "Syntax" field, which is Object(DN-DN) (link), or basically "String that contains a distinguished name (DN)."

This module is searching using the wrong data type for the member attributes.

aren cambre’s picture

aren cambre commented
Status: Postponed (maintainer needs more info) » Active
aren cambre’s picture

aren cambre commented

I just made the following patch recommended by Miglius:

Index: ldapgroups.module
===================================================================
RCS file: /cvs/drupal-contrib/contributions/modules/ldap_integration/ldapgroups.module,v
retrieving revision 1.34
diff -u -r1.34 ldapgroups.module
--- ldapgroups.module	30 Mar 2009 10:32:24 -0000	1.34
+++ ldapgroups.module	31 Mar 2009 20:25:07 -0000
@@ -184,6 +184,7 @@
   if (_ldapgroups_ldap_info($user, 'ldapgroups_as_entries')) {
     foreach (_ldapgroups_ldap_info($user, 'ldapgroups_entries') as $branch) {
       $entries = $_ldapgroups_ldap->search($branch, $ldapgroups_entries_attribute .'='. $user->ldap_dn, array($ldapgroups_entries_attribute));
+var_dump($entries);
       if (empty($entries) || $entries['count'] == 0)
         $entries = $_ldapgroups_ldap->search($branch, $ldapgroups_entries_attribute .'='. $user->name, array($ldapgroups_entries_attribute));
       foreach ($entries as $entry) {

I have Groups exist as LDAP entries where a multivalued attribute contains the members' CNs checked, but the var_dump isn't firing.

miglius’s picture

miglius commented
Status: Active » Postponed (maintainer needs more info)

The module first searches for the user's full DN and if it does not find it, then it tries searching by the username.

Can you paste here your group's LDAP entry containing member attributes? Also can you paste here a full DN od the user you're logging as?

aren cambre’s picture

aren cambre commented
Status: Postponed (maintainer needs more info) » Active

I'll email them to you directly. (Would rather not make public.)

(Email just sent.)

aren cambre’s picture

aren cambre commented

How is this progressing? How may I help?

miglius’s picture

miglius commented
Status: Active » Postponed (maintainer needs more info)

I'm a little confused now. The issue title says that configuration used is "Group by entry", however in the settings caption sent in the email the settings used were "Group by attribute". So which of those two configuration options do you use?

aren cambre’s picture

aren cambre commented

Disregard the email.

I currently have Groups exist as LDAP entries where a multivalued attribute contains the members' CNs selected under Group by entry.

In #2 above, see step 10. I just confirmed with Wireshark that this module is still searching the group's member attribute (specified in Attribute holding group members in admin/settings/ldap/ldapgroups/edit/1) for the value of the attribute specified in UserName attribute at admin/settings/ldap/ldapauth/edit/1.

The problem is the group's member attribute contains the users' DNs, not the value of the attribute specified in UserName attribute at admin/settings/ldap/ldapauth/edit/1.

aren cambre’s picture

aren cambre commented
Status: Postponed (maintainer needs more info) » Active
miglius’s picture

miglius commented
Status: Active » Postponed (maintainer needs more info)

I double checked, it's working fine on my setup, although I'm using openldap.

Again, as I noted in #1, first the code searches for the group's member attribute containing full user's DN. Only if the search fails, the system then searches for group's member attribute containing the username attribute.

If you'd look at the wireshark log, you should see the search for a full user's DN just before the search for a username attribute. Can you find it?

Since the first search for a full user's DN fails, you should inspect the $user object. Does $user->ldap_dn attribute is exactly the same as user's DN saved in the group's members attribute? Look carefully if all the cases and spaces (if any) matches.

aren cambre’s picture

aren cambre commented
Status: Postponed (maintainer needs more info) » Active

I just monitored again. Here's all the searches that are performed when a brand new Active Directory user logs in:

  1. Search the base DN (defined at admin/settings/ldap/ldapauth/edit/1) on where username attribute (defined at admin/settings/ldap/ldapauth/edit/1) for username attribute = sign in ID.
  2. Repeat the previous search.
  3. Search the "LDAP DNs containing gropups" within Group by entry (specified at admin/settings/ldap/ldapgroups/edit/1) on attribute holding group members (specified at admin/settings/ldap/ldapgroups/edit/1) for that attribute = value for username attribute (see step 1 above).
  4. Search tne entire active directory, starting at the AD's base, for the DN of the user account.
  5. Repeat prior search.
  6. Repeat prior search again.

It never searches on the groups OU for the DN of the signed in user.

miglius’s picture

miglius commented

Could you email me your network sniffer log with all that data (without sensitive information if any)?

aren cambre’s picture

aren cambre commented

Just sent.

miglius’s picture

miglius commented
Status: Active » Postponed (maintainer needs more info)

From your output I can see that the Directory is searched as it should be by the member=DN, but no results are found.

You have a comma in your user's CN attribute. CN attribute is used to form a full DN of the user, and since several DN's parts are separated by the comma, the comma in the CN should be escaped.

From your output, I can see that a comma in your case with AD is escaped by the '\,'. When I use comma in the openLDAP, everything works fine, but the comma is escaped as '\2C'. This difference is suspicious for me and might be the root of the problem.

Could you change your CN (also DN and group's member attribute) to not have a comma and then try logging in again to see if you're assigned to the right group and this is the cause of the problem?

aren cambre’s picture

aren cambre commented
Title: "Group by entry" doesn't search by correct attribute value » "Group by entry" breaks when CN has commas
Status: Postponed (maintainer needs more info) » Active

I tried it with an account that has no comma in the CN, and it worked fine.

We have thousands of accounts, and virtually all of them are this way. Any company that uses "lastname, firstname" may be the same way. So far this is the only application I am aware of that doesn't support the CN comma.

miglius’s picture

miglius commented
Status: Active » Needs work
Issue tags: +ad

Well, it does support commas in the openLDAP, I tried CN with comma and it works just fine. It's more like MS is not following standards in its AD implementation.

I think it is possible to use some regexp to change '\,' to a '\2C' or backwards and make it work in both openLDAP and AD, but I don't have an AD in my hands so cannot experiment.

However, if somebody working with AD could write a patch which makes it work with the AD, I would include it in the code.

aren cambre’s picture

aren cambre commented
Status: Needs work » Active

That's not the problem. Look back at the TCP dump I sent you on May 11. You'll notice that every time you query the domain when you use the CN, you are properly escaping the comma with a \ and get the expected response every time.

Packet 175 in the dump is where the module is not working right. It's querying for groups on member = [value of username attribute]. The problem is [value of username attribute] is not the CN.

The problem remains what the module is passing to the directory server, not issues with comma escaping.

miglius’s picture

miglius commented

1. Look at the code quoted in #1, it always first queries the based on the full DN, and only if there is no results it queries based on username. No exceptions.

2. In #17 you said, quote: "I tried it with an account that has no comma in the CN, and it worked fine."

aren cambre’s picture

aren cambre commented

re: "1. Look at the code quoted in #1, it always first queries the based on the full DN, and only if there is no results it queries based on username. No exceptions."

No. Nowhere does it show a query of groups using the DN. The query for groups is broken:groups' member attributes only contain DNs, but the module declines to query member=DN.

re: "I tried it with an account that has no comma in the CN, and it worked fine."

Yes. However, the TCP dump proves that the module declines to use the DN to query the groups. The module is querying the Active Directory in a way that cannot possibly return the correct result.

Look at frame 175 in the TCP dump I sent you. The module is not sending anything resembling a DN in the LDAP query of the groups.

Also, look at line 0010 after frame 165. That's where my Active Directory returns my account information, and it is escaping the comma with a backslash.

Also look at frames 190 and 202. These prove the module is capable of sending a correctly-escaped query to the directory server and get a valid result.

The module itself is the problem. It is not querying groups using DNs.

miglius’s picture

miglius commented

OK, the fact is that when there are commas, it works only with an openLDAP, not with the AD. OpenLDAP and AD escape commas in different ways. I would appreciate if somebody who has an AD could troubleshoot this further.

aren cambre’s picture

aren cambre commented

Miglius: AD escapes commas with a backslash. Please review the responses from my Active Directory environment in the TCP trace that I emailed you. There is a logic error in the software.

However, this is irrelevant. The issue is not comma escaping. The issue is the module is not issuing a proper query. The module is querying on group = username attribute. In my case, I use the mailNickName attribute for the username, and mailNickName is not even a part of the DN.

miglius’s picture

miglius commented

The issue IS comma escaping for AD. You mentioned that everything works fine when there is no comma in CN attribute. In my setup with openLDAP everything works correctly regardless I use comma in CN or don't. I have created ldap entries with a very same DN entries as you use both for users and groups and used the same members attributes. All worked as expected.

So obviously there is an issues with the comma escaping for the AD server. I don't know if something wrong happens at the module layer, php_ldap extension layer or data transmitting layer. The point is I cannot replicate this in my environment and fix it, therefore I asked if somebody having AD could look into it.

aren cambre’s picture

aren cambre commented

Frame 125 of the TCP dump shows the Active Directory returning this to the LDAP module: CN=Cambre\, Aren,OU=xxxxx,OU=xxxxxxxxxxxxxx,OU=xxxxxx,DC=smu,DC=edu (blanked out OUs).

Note that the comma escaping is simple and standard.

Now go down to frame 175. The LDAP module is searching my groups OU, which is OU=Groups,OU=xxxxx,OU=xxxxxxxxxxxxxx,OU=xxxxxx,DC=smu,DC=edu. HOWEVER, it's searching the member attribute for acambre.

Now tell me this: where does acambre appear in my DN? Nowhere! So why is LDAP module declining to search the OU using member=DN?

acambre is the mailNickName attribute of my user account's directory entry, and I told the LDAP module to use mailNickName as the UserName attribute at admin/settings/ldap/ldapauth/edit/1.

There is nothing nonstandard about comma escaping. The problem is the LDAP module is declining to issue a meaningful group query.

miglius’s picture

miglius commented

> The problem is the LDAP module is declining to issue a meaningful group query.

I think we agreed on that and I keep on repeating that the reason is the comma escaping. ldapgroups module DOES issue a ldap search query by calling the appropriate php function, but because of the bad escaping the query might be stop at the php ldap extensions layer and is not sent to the AD server. This is the reason you don't see it in the log. As a prove of that there is a fact that everything works when there a re no commas in the CN.

> There is nothing nonstandard about comma escaping.

openLDAP and AD escapes commas differently.

To query LDAP on the member=DN I'm using the same DN value as was returned form the LDAP server when a user was authenticated. Without any changes it just works in the openLDAP. In the AD it does not. So it looks like the problem is with a comma escaping. I agree that correct escaping should be done in the module's code. But I cannot do that without the AD at my hands.

I find our latest comments meaningless as they do not help to solve the issue.

If you are willing to help me, we could set up a skype or jabber session and we could use your AD + drupal setup to insert a debug statements in the code and look at the logs. I think we could track the problem in an hour or so.

miglius’s picture

miglius commented
Status: Active » Fixed

Thanks Aren to debug the issue. It appeared that AD wants the comma to be escaped by the "\\," rather then the "\,". Fixed in the cvs.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

johnbarclay’s picture

johnbarclay commented
Assigned: Unassigned » johnbarclay
Status: Closed (fixed) » Needs review
StatusFileSize
new fix_exploding_of_dn-417892-29.patch789 bytes

Attached is a patch for this. The DN was being exploded incorrectly. I ran across the same issue in ldap for drupal 7.

change is in ldapgroups.inc

- $pairs = explode(',', $user->ldap_dn);
+ $pairs = ldap_explode_dn($user->ldap_dn, 0);

johnbarclay’s picture

johnbarclay commented
Title: "Group by entry" breaks when CN has commas » ldapgroups "Group by entry" breaks when CN has commas
johnbarclay’s picture

johnbarclay commented
Status: Needs review » Closed (fixed)

I committed this to head. quoting attributes in a dn and escaping commas are both legitimate ways of storing dns in this module.