[SSSD-users] Re: SSSD/AD Issues After 1.14 to 1.15 upgrade in CentOS 7
The preffered place is https://pagure.io/SSSD/sssd/new_issue On Fri, Feb 02, 2018 at 05:59:18PM +, Simon Engelbert wrote: > Sure, where is the proper place to file tickets? > > - Simon > On 2018-02-02, 10:20 AM, "Jakub Hrozek" wrote: > > If you can reproduce this with a recent build, please file a ticket.. > > On Fri, Feb 02, 2018 at 05:01:25PM +, 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 > > > > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > > > > root@server: ~$ sss_cache -E > > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > > > > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user > > > > 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 > > > > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > > > > > > ## 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 > > > > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > > > > > > 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" 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)(sAMAccountNam
[SSSD-users] Re: SSSD/AD Issues After 1.14 to 1.15 upgrade in CentOS 7
Sure, where is the proper place to file tickets? - Simon On 2018-02-02, 10:20 AM, "Jakub Hrozek" wrote: If you can reproduce this with a recent build, please file a ticket.. On Fri, Feb 02, 2018 at 05:01:25PM +, 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 > > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > > root@server: ~$ sss_cache -E > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user > > 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 > > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > > > ## 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 > > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > > > 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" 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 :-) s
[SSSD-users] Re: SSSD/AD Issues After 1.14 to 1.15 upgrade in CentOS 7
If you can reproduce this with a recent build, please file a ticket.. On Fri, Feb 02, 2018 at 05:01:25PM +, 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 > > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > > root@server: ~$ sss_cache -E > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user > > 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 > > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > > > ## 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 > > root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad > > > 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" 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] Re: SSSD/AD Issues After 1.14 to 1.15 upgrade in CentOS 7
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 root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad root@server: ~$ sss_cache -E root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad root@server: ~$ /usr/bin/sss_ssh_authorizedkeys user 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 root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad ## 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 root@server: ~$ /usr/bin/sss_ssh_authorizedkeys u...@domain.ad 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" 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] Re: SSSD/AD Issues After 1.14 to 1.15 upgrade in CentOS 7
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
