We have multiple linux servers configured with SSSD/realmd for authentication to Active Directory. The systems are configured without winbind so using Kerberos to authenticate to the domain. Once SMBv1 was disabled on the domain controller none of the machines could authenticate users. Any idea on why this would happen when we should be configured for kerberos authentication?
**** /etc/sssd/sssd.conf **** [nss] filter_groups = root filter_users = root reconnection_retries = 3 shell_fallback = /bin/bash fallback_homedir = /home/%u
[pam] reconnection_retries = 3
[sssd] domains = internal.example.domain config_file_version = 2 services = nss, pam, ifp
[domain/internal.example.domain] id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad dyndns_update = False ad_domain = internal.example.domain krb5_realm = INTERNAL.EXAMPLE.DOMAIN realmd_tags = manages-system joined-with-adcli cache_credentials = False krb5_store_password_if_offline = False ldap_id_mapping = True use_fully_qualified_names = False ldap_user_home_directory = unixHomeDirectory ldap_user_shell = loginShell entry_cache_timeout = 0 ad_enable_gc = False
**** /etc/krb5.conf **** [libdefaults] default_realm = INTERNAL.EXAMPLE.DOMAIN
**** realm list **** % sudo realm list internal.example.domain type: kerberos realm-name: INTERNAL.EXAMPLE.DOMAIN domain-name: internal.example.domain configured: kerberos-member server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: libnss-sss required-package: libpam-sss required-package: adcli required-package: samba-common-bin login-formats: %U login-policy: allow-realm-logins
-- Brenden
On Tue, Feb 28, 2017 at 01:05:19PM -0600, Brenden Morgenthaler wrote:
We have multiple linux servers configured with SSSD/realmd for authentication to Active Directory. The systems are configured without winbind so using Kerberos to authenticate to the domain. Once SMBv1 was disabled on the domain controller none of the machines could authenticate users. Any idea on why this would happen when we should be configured for kerberos authentication?
No idea, the authentication uses, as you said, Kerberos. Did you already look into SSSD debug logs?
On Tue, Feb 28, 2017 at 09:23:47PM +0100, Jakub Hrozek wrote:
On Tue, Feb 28, 2017 at 01:05:19PM -0600, Brenden Morgenthaler wrote:
We have multiple linux servers configured with SSSD/realmd for authentication to Active Directory. The systems are configured without winbind so using Kerberos to authenticate to the domain. Once SMBv1 was disabled on the domain controller none of the machines could authenticate users. Any idea on why this would happen when we should be configured for kerberos authentication?
No idea, the authentication uses, as you said, Kerberos. Did you already look into SSSD debug logs?
It might be related to reading the GPO files for access control, please check the system logs which PAM step (auth, acct) failed. As Jakub said SSSD debug logs will have more details as well, please see https://fedorahosted.org/sssd/wiki/Troubleshooting for details.
HTH
bye, Sumit
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
It does appear to be GPO access, from the gpo_child.log (getting a tarball up somewhere to download also).
(Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0400): gpo_child started. (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0400): context initialized (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [unpack_buffer] (0x0400): cached_gpt_version: 327788 (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0400): performing smb operations (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://dc2.internal.example.domain/sysvol/internal.example.domain/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [2][No such file or directory] (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [2][No such file or directory] (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0020): perform_smb_operations failed.[2][No such file or directory]. (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0020): gpo_child failed!
-- Brenden
On Mar 1, 2017, at 02:30, Sumit Bose sbose@redhat.com wrote:
On Tue, Feb 28, 2017 at 09:23:47PM +0100, Jakub Hrozek wrote:
On Tue, Feb 28, 2017 at 01:05:19PM -0600, Brenden Morgenthaler wrote:
We have multiple linux servers configured with SSSD/realmd for authentication to Active Directory. The systems are configured without winbind so using Kerberos to authenticate to the domain. Once SMBv1 was disabled on the domain controller none of the machines could authenticate users. Any idea on why this would happen when we should be configured for kerberos authentication?
No idea, the authentication uses, as you said, Kerberos. Did you already look into SSSD debug logs?
It might be related to reading the GPO files for access control, please check the system logs which PAM step (auth, acct) failed. As Jakub said SSSD debug logs will have more details as well, please see https://fedorahosted.org/sssd/wiki/Troubleshooting for details.
HTH
bye, Sumit
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Mon, Mar 06, 2017 at 01:30:25PM -0600, Brenden Morgenthaler wrote:
It does appear to be GPO access, from the gpo_child.log (getting a tarball up somewhere to download also).
(Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0400): gpo_child started. (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0400): context initialized (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [unpack_buffer] (0x0400): cached_gpt_version: 327788 (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0400): performing smb operations (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://dc2.internal.example.domain/sysvol/internal.example.domain/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [2][No such file or directory] (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [2][No such file or directory] (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0020): perform_smb_operations failed.[2][No such file or directory]. (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0020): gpo_child failed!
I'm sorry I didn't notice your e-mail was stuck in moderation.
You can temporarily disable GPO processing if you don't use it with: ad_gpo_access_control = permissive
But honestly I can't tell if this is a bug in SSSD we should handle more gracafully.
On Thu, Mar 09, 2017 at 10:05:33AM +0100, Jakub Hrozek wrote:
On Mon, Mar 06, 2017 at 01:30:25PM -0600, Brenden Morgenthaler wrote:
It does appear to be GPO access, from the gpo_child.log (getting a tarball up somewhere to download also).
(Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0400): gpo_child started. (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0400): context initialized (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [unpack_buffer] (0x0400): cached_gpt_version: 327788 (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0400): performing smb operations (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://dc2.internal.example.domain/sysvol/internal.example.domain/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [2][No such file or directory] (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [2][No such file or directory] (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0020): perform_smb_operations failed.[2][No such file or directory]. (Mon Mar 6 13:18:13 2017) [[sssd[gpo_child[24538]]]] [main] (0x0020): gpo_child failed!
I'm sorry I didn't notice your e-mail was stuck in moderation.
You can temporarily disable GPO processing if you don't use it with: ad_gpo_access_control = permissive
But honestly I can't tell if this is a bug in SSSD we should handle more gracafully.
In general libsmbclient should be capable to handle the newer version of the SMB protocol correctly, but maybe we have to set some other option or use libsmbclient differently?
bye, Sumit
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
Brenden Morgenthaler -
Jakub Hrozek -
Sumit Bose