No accounts found. You have no attached accounts.

[mikephung]

we are using afp-core as STS for our company to login into the AWS Console. The setup was built with puppet and the afp was deployed automatically which everything is fine.

From time to time we observed that someone got the error message "No accounts found. You have no attached accounts." even he entered the corrected password and the username was already configured properly.

The error message is not easy to reproducible, for example i tried 2 hours today and it doesn't come, but yesterday twice.

We setup afp-core + apache + sssd as the description.

an investigation in the source code i found that the function getAccountList return Errormessage but didn't understand why the login is working, it still return the Error Message

afp-web/js/service/userMessageService.js

` function getAccountList(callback) {
var error = {};

  $http.get(appVars.afpApiEndpoint + "account")
    .success(function (response, status, headers) {
      callback(null, getLoginstatus(headers), createAccountArray(response));
    })
    .error(function (response, status, headers) {
      error.message = getErrorMessage(status, response);
      callback(error, getLoginstatus(headers));
    });
}

return {
  getLoginstatus: getLoginstatus,
  getErrorMessage: getErrorMessage,
  getAccountList: getAccountList
};`

afp-web/js/controller/AccountlistController.js

` userMessageService.getAccountList(function (err, loginstatus, accounts) {
$scope.loginstatus = loginstatus;

  if (err) {
    $scope.error = err.message;
    $scope.showError = true;

    return;
  }

  $scope.favoriteCount = favouritesService.readFavorites(accounts);
  $scope.accounts = accounts;
  $scope.showError = false;
  focusQueryInput();
});`

afp-web/templates/resultlist.html

`<div class="align-center" ng-show="accounts.length == 0">
     <div class="alert alert-info" role="alert" >
        <b>No accounts found.</b>
             You have no attached accounts.
    </div>
 </div>`

[snordhausen]

Is there anything in the log file of afp-core/Apache when this happens? You can get debug logging for afp-core as shown here. I think you also had to configure rsyslog to log debug messages, otherwise rsyslog receives the messages but discards them.

I cannot really speak for the JavaScript part, though. @SebastianStiehl would be the expert for that.

[Mortinke]

It looks like that NSS and the grp-provider is the problem.

We use the following configuration

/etc/sssd/sssd.conf

[sssd]
services = nss, pam
config_file_version = 2
domains = LDAP
reconnection_retries = 3
debug_level = 5

[domain/LDAP]
enumerate = false
ldap_tls_reqcert = never
id_provider = ldap
auth_provider = ldap
cache_credentials = false
debug_level = 5
entry_cache_timeout = 86400

ldap_uri = ldap://****
ldap_backup_uri = ldap://****
ldap_search_base = ou=***,dc=***
ldap_default_bind_dn = <ldap_user>@ *****
ldap_default_authtok_type = password
ldap_default_authtok = *****
ldap_id_use_start_tls = false
ldap_force_upper_case_realm = false
ldap_user_uuid = objectGUID
ldap_user_objectsid = objectSid
ldap_user_object_class = user
ldap_user_name = sAMAccountName
ldap_user_gid_number = primaryGroupID
ldap_group_object_class = group
ldap_group_name = SAMAccountName
ldap_group_member = member
ldap_group_uuid = objectGUID
ldap_group_objectsid = objectSid
ldap_group_modify_timestamp = whenChanged
ldap_id_mapping = true
ldap_schema = ad
ldap_referrals = false

[nss]
debug_level = 5
reconnection_retries = 3
entry_cache_nowait_percentage = 75
filter_groups = root,postfix
filter_users = root,postfix

[pam]
debug_level = 5
reconnection_retries = 3

/etc/nsswitch.conf

passwd:     files sss
shadow:     files sss
group:      files sss

/etc/pam.d/httpd-auth

#%PAM-1.0

auth    required pam_sss.so
account required pam_sss.so

apache.conf

<VirtualHost ******>
  ServerName <hostname>.<domain>
  ServerAdmin <admin_email>@*****

  ## Vhost docroot
  DocumentRoot "/var/www/afp-web"

  ## Directories, there should at least be a declaration for /var/www/afp-web

  <Directory "/var/www/afp-core">
    AllowOverride None
    Require all granted
  </Directory>

  <Directory "/var/www/afp-core/*">
    AllowOverride None
    Require valid-user
    AuthType Basic
    AuthName "Please authenticate for federation login"
    AuthBasicProvider PAM

    AuthPAMService httpd-auth
  </Directory>

  ## Logging
  ErrorLog "/var/log/httpd/<hostname>.<domain>_error.log"
  LogLevel info
  ServerSignature Off
  CustomLog "/var/log/httpd/<hostname>.<domain>_access.log" combined

  ## Server aliases
  ServerAlias <hostname>.<domain>

  ## SetEnv/SetEnvIf for environment variables
  SetEnv ACCOUNT_CONFIG_PATH "/etc/afp-core/accounts/"
  SetEnv CONFIG_PATH "/etc/afp-core/humans/"
  WSGIScriptAlias /afp-api/latest "/var/www/afp-core/wsgi/api.wsgi"
  WSGIScriptAlias /api/latest/machine "/var/www/afp-core/wsgi/api.wsgi"
</VirtualHost>

After we have increased the log level for sssd, pam and nss to 9 we could see that the grp-provider execute NSS to get the groups from the user. NSS breaks the request always with the following error message, but replied a success.

(Wed Apr 12 16:38:04:106841 2017) [sssd[nss]] [cache_req_set_plugin] (0x2000): CR #31: Setting "Enumerate groups" plugin
(Wed Apr 12 16:38:04:106867 2017) [sssd[nss]] [cache_req_send] (0x0400): CR #31: New request 'Enumerate groups'
(Wed Apr 12 16:38:04:106879 2017) [sssd[nss]] [cache_req_select_domains] (0x0400): CR #31: Performing a multi-domain search
(Wed Apr 12 16:38:04:106885 2017) [sssd[nss]] [cache_req_search_domains] (0x0400): CR #31: Search will bypass the cache and check the data provider
(Wed Apr 12 16:38:04:106891 2017) [sssd[nss]] [cache_req_validate_domain] (0x0400): CR #31: Domain LDAP does not support enumeration, skipping...
(Wed Apr 12 16:38:04:106897 2017) [sssd[nss]] [cache_req_global_ncache_add] (0x2000): CR #31: This request type does not support global negative cache
(Wed Apr 12 16:38:04:106906 2017) [sssd[nss]] [cache_req_done] (0x0400): CR #31: Finished: Not found
(Wed Apr 12 16:38:04:106914 2017) [sssd[nss]] [nss_protocol_done] (0x4000): Sending reply: success

We suppose that the NSS requested the files-modul (the local files) and NSS breaks up the request as a consequence of "Domain LDAP does not support enumeration" error. However, since NSS replied a success the sss-modul isn't used to request LDAP for the groups.

I will investigate the problem again next week!

[Mortinke]

Currently, I can't configure NSS that it works with the grp_provider when enumerate is disabled.
I tried to change the order of modules in nsswitch.conf, added the ldap module, added the initgroups database but it doesn't work.

I tried the following nsswitch.conf configurations:

passwd:     sss files 
shadow:     sss files
group:      sss files

passwd:     files sss 
shadow:     files sss 
group:      sss files

passwd:     sss files 
shadow:     sss files
group:      sss files

passwd:     sss ldap files 
shadow:     sss ldap files
group:      sss ldap files

passwd:     sss files 
shadow:     sss files
group:      sss files
initgroups: sss files

The authentication with apache works well, PAM triggers LDAP to receive the user and group information and all data are also received by LDAP. The wsgi-script with all their classes are successfully initialized but the grp_provider only received the local groups.

Env:

# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
# yum list installed | grep group_sssd-sssd-1-15
libipa_hbac.x86_64              1.15.2-1.el7.centos        @group_sssd-sssd-1-15
libsss_autofs.x86_64            1.15.2-1.el7.centos        @group_sssd-sssd-1-15
libsss_idmap.x86_64             1.15.2-1.el7.centos        @group_sssd-sssd-1-15
libsss_nss_idmap.x86_64         1.15.2-1.el7.centos        @group_sssd-sssd-1-15
libsss_sudo.x86_64              1.15.2-1.el7.centos        @group_sssd-sssd-1-15
python2-sss.x86_64              1.15.2-1.el7.centos        @group_sssd-sssd-1-15
python2-sssdconfig.noarch       1.15.2-1.el7.centos        @group_sssd-sssd-1-15
sssd.x86_64                     1.15.2-1.el7.centos        @group_sssd-sssd-1-15
sssd-ad.x86_64                  1.15.2-1.el7.centos        @group_sssd-sssd-1-15
sssd-client.x86_64              1.15.2-1.el7.centos        @group_sssd-sssd-1-15
sssd-common.x86_64              1.15.2-1.el7.centos        @group_sssd-sssd-1-15
sssd-common-pac.x86_64          1.15.2-1.el7.centos        @group_sssd-sssd-1-15
sssd-ipa.x86_64                 1.15.2-1.el7.centos        @group_sssd-sssd-1-15
sssd-krb5.x86_64                1.15.2-1.el7.centos        @group_sssd-sssd-1-15
sssd-krb5-common.x86_64         1.15.2-1.el7.centos        @group_sssd-sssd-1-15
sssd-ldap.x86_64                1.15.2-1.el7.centos        @group_sssd-sssd-1-15
sssd-proxy.x86_64               1.15.2-1.el7.centos        @group_sssd-sssd-1-15

[snordhausen]

Should be fixed, see #7

[mikephung]

it's fixed!