"Group by entry" breaks when CN has commas

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:

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

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.

I just made the following patch recommended by Miglius:

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

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?

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

(Email just sent.)

How is this progressing? How may I help?

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?

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.

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.

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.

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

Just sent.

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?

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.

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.

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.

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."

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.

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.

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.

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.

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.

> 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.

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.

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