Is @UserNamesList unreliable?

HCL Domino Domino Forum
1

I’m seeing erratic behavior with @UserNamesList, on both Domino 5.09 and 6.0.1, and wondering if anyone else has encountered it.

@UserNamesList is supposed to return ALL the groups and roles of the current authenticated user.

When used with Domino for Web access, for most logged-in users, it works correctly. But for users who are in MANY groups, the function’s return list does not include ALL of the user’s groups.

The only way I’ve discovered to force a missing group to appear in @UserNamesList is by editing the group document in names.nsf. I make no changes to the group, just Edit, Save, then push it to the server. After several minutes, @UserNamesList starts including this group in its return list. But it still doesn’t include any of the several other missing groups unless I also manually edit them.

In the pubnames design I don’t see any explicit views (visible or hidden) that contain what @UserNamesList returns, so possibly it uses an internal index (built on the fly for each user?) that is not reliably maintained by Domino.

One clue: The groups that fail to appear are being updated nightly by an LS agent. A simple answer would be that this somehow causes such groups to be ignored by Domino. But for most users these groups are not ignored. For users who are in just one or a few such groups, @UserNamesList works fine. It’s only for the few people who are in MANY groups that it fails.

This problem exists on both Domino 5 and 6 servers. I don’t see it in Notes clients.

Anyone seen this?

2

Subject: I’m not aware of a problem, but … how many cause a problem?

How many entries is @UserNamesList reporting?

3

Subject: RE: I’m not aware of a problem, but … how many cause a problem?

Right now for my test account, @UserNamesList is returning 12 groups, but I’m actually in more than 20.

If I manually edit one of the missing groups, within a few minutes @UserNamesList starts to list it. If I manually edit ALL the missing groups I’m in, they all appear.

This problem is 100% repeatable and happens in at least Domino 5.09a and later, including 6.0.1.

My best guess is that the view or index that @UserNamesList relies on is not reliably maintained by Domino. But why not?

4

Subject: Is @UserNamesList unreliable?

I had a similar problem with 5.010. Refreshing the view ($ServerAccess) in the agent solve it. (In my case). I hope be good for you.

5

Subject: RE: Is @UserNamesList unreliable?

$ServerAccess includes ALL the missing groups I’m in – the groups I can get @UserNamesList to return once I manually edit them.

Actually, this view does not contain any of the groups that @UserNamesList always returns – only the views it usually omits.

6

Subject: The Answer to this problem!

Refreshing the view is not the key… refreshing the group documents within the view, will help. The real solution is to use canonicalized names in your group document. Why?

The ($ServerAccess) view is used for Domino authentication, we know that. But, you MUST be sure all entries in the Members field of the group document are in canonical format: “CN=User Name/OU=Organizational Unit/O=Organization”. If one of the entries is not in this format in the specific group it will give you trouble when authenticating. (got this from another post regarding LDAP and Domino authentication problems)

The reason you’re finding that users are finally able to authenticate when you open and save the group manually, is because your names, upon being saved, are also being converted to the canonical format. Take a look at the document properties for your group doc, and look at the Members field. The user who is not showing all groups, when you use @UserNamesList is likely shown in Abbreviated format: “User Name/Organizational Unit/Organization”. Refresh the document, not the view… and make sure your user’s name now appears in canonical format, and your problem will be fixed.

Good luck.

7

Subject: RE: The Answer to this problem!

Nice answer!

I have to wonder how the names got into there in abbreviated format. I suspect there’s maybe an agent adding entries to groups, which needs to be corrected.

8

Subject: RE: The Answer to this problem!

Here’s a related question/answer with references

My ldapsearch for a direct group member does not return all members

There are two probable reasons for this:

The Group document’s Member list does not list the “distinguished name” of the member (e.g., “Ken Lin/Westford/IBM”), but instead lists some other non-fully qualified name (e.g., “Ken Lin”). Both the LDAP groupOfNames specification and Notes Internet Authentication require distinguished names.

Note When Domino authenticates an Internet user, it uses the “distinguished name,” which is the first name that appears in the Full Name field of a Person document. This name should be used in entries for groups, delegated server administration, database ACLs, and file protection documents.

a. Next, the server compiles a “grouplist,” which contains Andrew’s distinguished name, plus any wildcard entries and any groups of which he is a member on that server.

b. The server then checks the database ACL to determine if Andrew’s name is listed explicitly on the ACL, or if any of the grouplist entries for his name appear in the ACL.

c. If Andrew’s distinguished name, or the name of any group of which is a member, matches an entry in the ACL, then Andrew gets access to the database using the access level specified for that entry in the ACL. Otherwise, he is denied access.

The Group document is a Mail Only group:

LDAPGroupMembership
Syntax: LDAPGroupMembership=value

Description: The LDAP service always searches Domino groups specified as “Multi-purpose,” “Access Control List only,” “Servers only,” or “Deny List only” groups because it can do so quickly. However because searches of Domino Groups specified as “Mail only” groups or of groups that do not have a value for the GroupType attribute can be slow, by default the LDAP service does not always search these types of groups. The LDAP service does not search these types of groups if a search query meets all of the following criteria, indicating a query that is typically used for authentication:

A search query uses the equality filter objectclass=value, where value is one of these object classes: groupOfNames, groupOfUniqueNames, dominoGroup, or group.

A search query uses an equality filter with one of these attributes: member, uniqueMember, or members.

The two filters above are concatenated using the AND operator.

For example, by default the LDAP service does not search Domino “Mail only” groups and groups that do not have values for the GroupType attribute if search queries such as these are specified:

(&(objectclass=dominoGroup)(member=cn=jack brown,o=acme))

(|(&(objectclass=groupOfUniqueNames)(uniqueMember=cn=jack brown,o=acme))(&(objectclass=groupOfNames)(member=cn=jack brown,o=acme)))

However, by default the LDAP service does search these groups if search queries such as these are specified:

(&(objectclass=dominoGroup)(member=br))

(member=cn=jack brown,o=acme)

(|(&(objectclass=dominoGroup)(member=cn=jack brown,o=acme))(cn=groupname))

To change the LDAP service default behavior for group searches, specify one of these values for this setting:

1 - Always search all groups that meet specified search criteria. If you choose this setting, full-text indexing the directory is recommended to improve the speed of searches of Domino “Mail only” groups and groups that do not use the GroupType attribute.

2 - Never search Domino “Mail only” groups or groups that do not use the GroupType attribute.

Note In Domino 5 the name of this setting is LDAP_MailOnlyGroupOption. The name has been changed in Domino 6 for clarity. However, you can use either setting name.