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
