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*
user@DOMAIN.AD(a)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 user(a)DOMAIN.AD
<no keys returned>
root@server: ~$ sss_cache -E
root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user(a)DOMAIN.AD
<returns keys>
root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user
<returns keys>
root@server: ~$ exit
## Login attempt 2 ##
*local*
user@DOMAIN.AD(a)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 user(a)DOMAIN.AD
<no keys returned>
## Login attempt 3 ##
*local*
user@DOMAIN.AD(a)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 user(a)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/server(a)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" <lslebodn(a)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=user@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(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org