User Denied Access To Files and Wikis

Another PMR this week on a new 5.5 side by side build. Once built everything looked OK except a couple of users in IT who received access denied errors when going to Files or Wikis, everything else worked.  Those two applications have databases with pretty much the same schema so we often see matching problems in both applications.

Checking the application security I could see that both were set to All Authenticated so there was no reason why those users couldn’t get at files.  The browser error contained

Identifier: LC6C54CE35BA4D41BF8CB2461634B9EAE6 EJPVJ9275E: Unable to add a group with the directory ID [E7F267C7-8811-D8EC-8025-7E57004A5278, 4339D1D3-2F37-ACDB-8025-7E57004A5285, C0085F47-7A84-EFD4-8025-7E57004A51FA, 4DB58BD6-77EA-80AC-8525-6B700078923E, A5456CF5-9FA0-E49B-8025-7E57004A5316, 54578802-623A-2E18-8025-7E57004A5289, 4EEFAFD1-A098-4155-8025-7F1D00522430, 0D1FD4C5-F61E-CB15-8025-7E57004A51F6, 5A3E2519-52BE-F072-8025-7E57004A527B, 04CE2967-BD15-B84D-8025-7E57004A52F1, 0D162A8C-223C-33C3-8025-7EB4002F6ADF, 6DCCEAE9-6A16-2A75-8025-7E57004A5377, 2B5D0EBA-B225-BA42-8025-7E57004A52DF, C6B296E2-5D27-0F89-8025-7E57004A532A].

If I count how many directory IDs are listed there, there are 14 which matched the number of groups that user was a member of when doing an LDAP query.  Still we weren’t using groups for any access and this exact configuration was working for the same users in 5.0.

In the SystemOut.log I could also see

CWWIM4546E  Duplicate entries were found in the external identifier ‘d68bb54dea77ac8085256b700078923e’ in repository ‘d68bb54dea77ac8085256b700078923e’.

That ID (formatted in various ways) would not resolve to any group in Files or Wikis never mind to duplicates.

Eventually David McCarthy @ IBM got me to change the wimconfig.xml file on the deployment manager which fixed the problem.  My configuration didn’t exactly match the documentation which said to change

<config:baseEntries name=”o=ORGX” nameInRepository=”o=ORGX”/>
<config:baseEntries name=”” nameInRepository=””/>

my configuration only had <config:baseEntries name=”” – no ORGX and no nameInRepository at all.  I believe that’s because we use  Domino for LDAP and “root” as the base entry so my federated repository looks like this – a configuration that results in no entry for nameInRepository in wimconfig.xml.

Screen Shot 2016-06-29 at 14.52.26

Once more this isn’t a problem in 5.0 but possibly due to a change in WebSphere behaviour in a newer version, I had to manually edit wimconfig.xml to add the nameInRepository=”” value.

At IBM’s request I also added the Group Membership Attribute which is used for resolving nested group memberships.  This customer uses Domino for LDAP and doesn’t really use nested groups in Connections so in 5.0 it was empty and worked fine however 5.5 may have been struggling with resolving group memberships for some individuals.  In 5.5 having it set to empty could have been contributing to the access problem.

The screenshot below is from 5.0. Screen Shot 2016-06-28 at 19.13.56this is how I changed it in 5.5 (same LDAP source, same users, same everything else)

Screen Shot 2016-06-29 at 15.06.31

Resyncing and restarting then fixed the problem and the users concerned could suddenly access Files and Wikis.

Not sure why it didn’t work for those users before the changes but it could have been something to do with one particular group and its nesting or maybe even a replication conflict which I couldn’t find.

Go figure.