User name/account issues with LDAP

Hello,

I have some trouble setting up Foswiki with SSO authentication against Active Directory. My configuration uses Apache 2.4 with mod_auth_gssapi for authentication, LdapApacheLogin and LdapUserMapping. There is no WikiUsers topic.

Users are correctly authenticated, and the WebLeftBar shows the correct name (the user's real name, with spaces in it). WIkiGroups shows the expected groups, with nested groups correctly expanded.

There are some spots where things aren't working as nicely:

If I Set ALLOWWEBVIEW = DsysSomeGroup, users in this group can view the topics in that web, but not their history. Instead, they get Action: "VIEW": access not allowed.
Each newly saved topic shows up as last modified by what I think is a cUID. The login name is the Kerberos UPN, say, [email protected], and what shows up as the last editor is randomuser_40mydomain_2edc.

I managed to work around the second issue by hacking on LdapContrib.pm a bit. Since I know my login names always have a "@" in them, I reverse their conversion to cUIDs until it appears:

@@ -137,7 +139,7 @@

   # SMELL: disabled this to allow underscores in login names
   use bytes;
-  $cUID =~ s/_([0-9a-f][0-9a-f])/chr(hex($1))/gei;
+  $cUID =~ s/_([0-9a-f][0-9a-f])/chr(hex($1))/gei while ($cUID =~ m/_40/ || $cUID =~ m/_5f/);
   no bytes;

   return $cUID;

That "_5f" part is because in the debug output I'm seeing double-encoded cUIDs where the underscore has been itself converted.

I'm sure this is merely a configuration issue, but I can't figure it out. This is my LdapContrib configuration:

$Foswiki::cfg{Ldap}{AllowChangePassword} = 0;
$Foswiki::cfg{Ldap}{Base} = 'dc=mydomain,dc=dc';
$Foswiki::cfg{Ldap}{BindDN} = 'CN=Foswiki (docs) LDAP Client,OU=Service Accounts,DC=mydomain,DC=dc';
$Foswiki::cfg{Ldap}{CaseSensitiveLogin} = 0;
$Foswiki::cfg{Ldap}{CharSet} = 'utf-8';
$Foswiki::cfg{Ldap}{Debug} = 1;
$Foswiki::cfg{Ldap}{Exclude} = 'WikiGuest, ProjectContributor, RegistrationAgent, UnknownUser, AdminGroup, NobodyGroup, AdminUser, admin, guest';
$Foswiki::cfg{Ldap}{GroupAttribute} = 'cn';
$Foswiki::cfg{Ldap}{GroupBase} = [
  'dc=mydomain,dc=dc'
];
$Foswiki::cfg{Ldap}{GroupFilter} = '(objectClass=group)';
$Foswiki::cfg{Ldap}{GroupScope} = 'sub';
$Foswiki::cfg{Ldap}{Host} = 'ldaps://dc.mydomain.dc';
$Foswiki::cfg{Ldap}{IPv6} = 0;
$Foswiki::cfg{Ldap}{IgnorePrivateGroups} = 1;
$Foswiki::cfg{Ldap}{IgnoreReferrals} = 1;
$Foswiki::cfg{Ldap}{InnerGroupAttribute} = 'member';
$Foswiki::cfg{Ldap}{KerberosKeyTab} = '';
$Foswiki::cfg{Ldap}{LoginAttribute} = 'userPrincipalName';
$Foswiki::cfg{Ldap}{LoginFilter} = '(&(objectclass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))';
$Foswiki::cfg{Ldap}{MailAttribute} = 'mail';
$Foswiki::cfg{Ldap}{MapGroups} = 1;
$Foswiki::cfg{Ldap}{MaxCacheAge} = 86400;
$Foswiki::cfg{Ldap}{MemberAttribute} = 'member';
$Foswiki::cfg{Ldap}{MemberIndirection} = 1;
$Foswiki::cfg{Ldap}{MergeGroups} = 0;
$Foswiki::cfg{Ldap}{NormalizeGroupNames} = 1;
$Foswiki::cfg{Ldap}{NormalizeLoginNames} = 0;
$Foswiki::cfg{Ldap}{NormalizeWikiNames} = 1;
$Foswiki::cfg{Ldap}{PageSize} = 500;
$Foswiki::cfg{Ldap}{Port} = '636';
$Foswiki::cfg{Ldap}{Precache} = 1;
$Foswiki::cfg{Ldap}{PrimaryGroupAttribute} = 'primaryGroupID';
$Foswiki::cfg{Ldap}{RewriteGroups} = {
  '^Dsys(.*)$' => 'Dsys$1Group'
};
$Foswiki::cfg{Ldap}{RewriteLoginNames} = {};
$Foswiki::cfg{Ldap}{RewriteWikiNames} = {
  '^(.*)@.*$' => '$1'
};
$Foswiki::cfg{Ldap}{SASLMechanism} = 'DIGEST-MD5 CRAM-MD5';
$Foswiki::cfg{Ldap}{SecondaryPasswordManager} = 'none';
$Foswiki::cfg{Ldap}{TLSCAFile} = '/usr/local/etc/ssl/mydomain-ca.cer';
$Foswiki::cfg{Ldap}{TLSCAPath} = '';
$Foswiki::cfg{Ldap}{TLSClientCert} = '';
$Foswiki::cfg{Ldap}{TLSClientKey} = '';
$Foswiki::cfg{Ldap}{TLSSSLVersion} = 'tlsv1';
$Foswiki::cfg{Ldap}{TLSVerify} = 'require';
$Foswiki::cfg{Ldap}{UseSASL} = 0;
$Foswiki::cfg{Ldap}{UseTLS} = 1;
$Foswiki::cfg{Ldap}{UserBase} = [
  'dc=mydomain,dc=dc'
];
$Foswiki::cfg{Ldap}{UserMappingTopic} = '';
$Foswiki::cfg{Ldap}{UserScope} = 'sub';
$Foswiki::cfg{Ldap}{Version} = '3';
$Foswiki::cfg{Ldap}{WikiGroupsBackoff} = 1;
$Foswiki::cfg{Ldap}{WikiNameAliases} = '';
$Foswiki::cfg{Ldap}{WikiNameAttributes} = 'cn';

-- ChrUllrich - 30 Sep 2016

For the "History" access, please check your configuration for the following settings:

$Foswiki::cfg{FeatureAccess}{AllowHistory} = 'authenticated';
$Foswiki::cfg{FeatureAccess}{AllowRaw} = 'authenticated';

They are found on the "Security And Authentication" section of configure, under the "Access Control" tab. They are "Expert" settings, so you will have to click on the show expert settings tab.

They can have 3 values: all, acl or authenticated (the default). As long as a user is logged in, then they should have access with the default settings. But maybe there is a bug here - I don't have an LDAP / Active Directory system available to test against. You could try setting it to all, which would allow anyone access to the history assuming they can view the topic. When set to acl you would have to configure "ALLOWWEBHISTORY ACLs in the web preferences.

Regarding the rest of your questions, I'm not all that familiar with LDAP.

-- GeorgeClark - 30 Sep 2016

The "FeatureAccess" options are set as you quoted, both to "authenticated". I set "AllowHistory" to "raw", and the error message remained the same. On the other hand, "raw" (that is the "Edit wiki text" link at the bottom, right?) works fine while still set to "authenticated".

I just read up on what these options actually do, and it says they control access to the "rev" and "raw" URL parameters. This is interesting, because just appending "?rev=1" does work. It's only the "History" link that leads to the error message.

-- ChrUllrich - 30 Sep 2016

You are right. Sorry for the red herring. As you say, the ALLOWTOPICHISTORY actually controls rev= access for viewing topic contents. The HistoryPlugin only shows the who/what/when of history and is not restricted. I completely mis-remembered the implementation in my prior answer.

I just dug through the code a bit. The HistoryPlugin HISTORY macro checks the session user for VIEW access to the topic. So this might also be due to some encoding issue with your userid's in the LDAP plugin. I don't see any obvious difference in how View vs. History checks for access.

-- GeorgeClark - 01 Oct 2016

The recent update to LdapContrib apparently fixes this. The new option "UseCanonicalUserIDs" sounds like leaving it disabled should give the same behavior as before it was introduced, but in my case, the problem went away that way.

-- ChrUllrich - 21 Jan 2017