If you can reproduce this with a recent build, please file a ticket..
On Fri, Feb 02, 2018 at 05:01:25PM +0000, Simon Engelbert wrote: > We updated to the latest copr repo and it does not seem to make a difference, > we are seeing the exact same issues. > > We have noticed a weird pattern that is, honestly, not always consistent but > looks like this… > > ## Login attempt 1 ## > *local* > u...@domain.ad@local: ~$ ssh server > Permission denied (publickey,gssapi-keyex,gssapi-with-mic). > > *on server* > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user > <no keys returned> > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > <no keys returned> > root@server: ~$ sss_cache -E > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > <returns keys> > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user > <returns keys> > root@server: ~$ exit > > ## Login attempt 2 ## > *local* > u...@domain.ad@local: ~$ ssh server > Last login: Fri Feb 2 16:31:23 2018 from local > > user@server: ~$ > > *on server* > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user > <no keys returned> > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > <no keys returned> > > ## Login attempt 3 ## > *local* > u...@domain.ad@local: ~$ ssh server > Permission denied (publickey,gssapi-keyex,gssapi-with-mic). > > *on server* > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user > <no keys returned> > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > <no keys returned> > > It appears as though clearing the cache clears or resets the cache correctly > and then a successful login clears or resets the cache incorrectly. > > Also here are our configs… > > [sssd] > config_file_version = 2 > #wmb - added ssh to the following line > services = ssh, nss, pam > domains = DOMAIN.AD > #wmb added next line > default_domain_suffix = DOMAIN.AD > debug_level = 0x3ff0 > > #wmb added the following line > [ssh] > > [nss] > override_homedir = /users/%u > default_shell = /bin/bash > use_fully_qualified_names = True > fallback_homedir = /users/%u@%d > reconnection_retries = 3 > > [pam] > reconnection_retries = 3 > #wmb added the following line - Keep user credentials in cache for 7 days > offline_credentials_expiration = 7 > > [domain/DOMAIN.AD] > #wmb - added next line > ad_domain = DOMAIN.AD > debug_level = 0x3ff0 > enumerate = false > #wmb - Do not return group members for group lookups. Default false > #ignore_group_members = true > id_provider = ad > chpass_provider = ad > auth_provider = ad > access_provider = simple > #simple_allow_groups = hadoop_admins, hadoop_users > ad_server = ADSERVER1.DOMAIN.AD > #wmb activated next line > ad_backup_server = ADSERVER2.DOMAIN.AD > ldap_schema = ad > ldap_user_principal = sAMAccountName > #wmb added the next 2 lines for SSH keys > ldap_user_extra_attrs = User-sshPublicKey:User-sshPublicKey > ldap_user_ssh_public_key = User-sshPublicKey > ldap_id_mapping = true > ldap_force_upper_case_realm = true > case_sensitive = false > krb5_realm = DOMAIN.AD > #wmb tags stored by the realmd configuration service for this domain > realmd_tags = manages-system joined-with-samba > #wmb Save user passwd if they log in offline. Do kinit when they com online > #krb5_store_password_if_offline = true > ldap_access_order = filter,expire > ldap_account_expire_policy = ad > cache_credentials = true > account_cache_expiration = 15 > enum_cache_timeout = 120 > entry_cache_nowait_percentage = 50 > entry_cache_nowait_timeout = 28800 > #wmb add if you want to restrict access to a certain group > ldap_group_search_base = DC=DOMAIN,DC=AD > ldap_sasl_authid = host/ser...@domain.ad > #wmb - enable AD client to update its DNS record > dyndns_update = True > dyndns_update_ptr = True > dyndns_refresh_interval = 43200 > dyndns_ttl = 3600 > > - Simon > On 2018-02-02, 4:07 AM, "Lukas Slebodnik" <lsleb...@redhat.com> wrote: > > On (02/02/18 11:54), Jakub Hrozek wrote: > >In the non-working cases, I see the name qualified where it shouldn't be > >e.g: > > >[(&(sAMAccountName=u...@domain.ad)(objectclass=user)(sAMAccountName=*)(objectSID=*))][DC=DOMAIN,DC=AD]. > > >while in the working case, the name in the filter is just > 'samaccoutnname=user'. > > > >This is a bug, but at the same time, there's been a number of commits in > >that area that might fix the bug.. > > > >Since you are running CentOS, I guess you are not worried about losing a > >support contract :-) so I'm wondering if you could test the 1.16.x > release > >from our test repos? > > > >That said, I don't see our 1.16 release in the > >https://copr.fedorainfracloud.org/groups/g/sssd/coprs/ repositories. > > > >Lukas, is building the 1.16 release something we just forgot to do? > > > Actually not. > > 1.15 continuously moved to 1.16 and there is not any upstream branch for > 1.15 > Therefore we have 1.16 in copr sssd-1-15 > > https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-15/builds/ > > I know it might be a little bit confusing. > > LS > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > > > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
