[SSSD-users] AD user account get Permission denied when trying to login
Hi, Could you please help me to resolve this issue! When i want to login to the RHEL 7.5 machine with AD account, i get permission denied: `Permission denied, please try again.` password for the user is correct, have tried it multiple times. Log for sshd: [root@azrclchefvm01 ~]# tail /var/log/secure Jul 23 21:47:01 azrclchefvm01 sshd[35436]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.17.253.11 user=mahdavif Jul 23 21:47:01 azrclchefvm01 sshd[35436]: pam_sss(sshd:auth): received for user mahdavif: 6 (Permission denied) Jul 23 21:47:03 azrclchefvm01 sshd[35436]: Failed password for mahdavif from 172.17.253.11 port 36262 ssh2 Jul 23 21:47:17 azrclchefvm01 sshd[35436]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.17.253.11 user=mahdavif Jul 23 21:47:17 azrclchefvm01 sshd[35436]: pam_sss(sshd:auth): received for user mahdavif: 6 (Permission denied) Jul 23 21:47:19 azrclchefvm01 sshd[35436]: Failed password for mahdavif from 172.17.253.11 port 36262 ssh2 Jul 23 21:47:25 azrclchefvm01 sshd[35436]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.17.253.11 user=mahdavif Jul 23 21:47:25 azrclchefvm01 sshd[35436]: pam_sss(sshd:auth): received for user mahdavif: 6 (Permission denied) Jul 23 21:47:28 azrclchefvm01 sshd[35436]: Failed password for mahdavif from 172.17.253.11 port 36262 ssh2 Jul 23 21:47:28 azrclchefvm01 sshd[35436]: Connection closed by 172.17.253.11 port 36262 [preauth] Log for sssd: [root@azrclchefvm01 ~]# tail /var/log/sssd/* ==> /var/log/sssd/krb5_child.log <== (Mon Jul 23 21:59:34 2018) [[sssd[krb5_child[35846 [become_user] (0x0200): Trying to become user [39599][59900]. (Mon Jul 23 21:59:34 2018) [[sssd[krb5_child[35846 [set_lifetime_options] (0x0100): No specific renewable lifetime requested. (Mon Jul 23 21:59:34 2018) [[sssd[krb5_child[35846 [set_lifetime_options] (0x0100): No specific lifetime requested. (Mon Jul 23 21:59:34 2018) [[sssd[krb5_child[35846 [set_canonicalize_option] (0x0100): Canonicalization is set to [true] (Mon Jul 23 21:59:34 2018) [[sssd[krb5_child[35846 [main] (0x0400): Will perform online auth (Mon Jul 23 21:59:34 2018) [[sssd[krb5_child[35846 [get_and_save_tgt] (0x0400): Attempting kinit for realm [CORP.example.net] (Mon Jul 23 21:59:35 2018) [[sssd[krb5_child[35846 [get_and_save_tgt] (0x0020): 1544: [-1765328366][Client's credentials have been revoked] (Mon Jul 23 21:59:35 2018) [[sssd[krb5_child[35846 [map_krb5_error] (0x0020): 1657: [-1765328366][Client's credentials have been revoked] (Mon Jul 23 21:59:35 2018) [[sssd[krb5_child[35846 [k5c_send_data] (0x0200): Received error code 1432158272 (Mon Jul 23 21:59:35 2018) [[sssd[krb5_child[35846 [main] (0x0400): krb5_child completed successfully ==> /var/log/sssd/ldap_child.log <== (Mon Jul 23 21:59:07 2018) [[sssd[ldap_child[35808 [prepare_response] (0x0400): Building response for result [0] (Mon Jul 23 21:59:07 2018) [[sssd[ldap_child[35808 [main] (0x0400): ldap_child completed successfully (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835 [main] (0x0400): ldap_child started. (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835 [unpack_buffer] (0x0200): Will run as [0][0]. (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835 [become_user] (0x0200): Trying to become user [0][0]. (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835 [become_user] (0x0200): Already user [0]. (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835 [ldap_child_get_tgt_sync] (0x0100): Principal name is: [AZRCLCHEFVM01$@ CORP.example.net] (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835 [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835 [prepare_response] (0x0400): Building response for result [0] (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835 [main] (0x0400): ldap_child completed successfully ==> /var/log/sssd/sssd_corp.example.net.log <== (Mon Jul 23 21:59:34 2018) [sssd[be[corp.example.net]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' (Mon Jul 23 21:59:34 2018) [sssd[be[corp.example.net]]] [be_resolve_server_process] (0x0200): Found address for server srv_waddcs001: [10.4.20.32] TTL 1200 (Mon Jul 23 21:59:34 2018) [sssd[be[corp.example.net]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon Jul 23 21:59:35 2018) [sssd[be[corp.example.net]]] [child_sig_handler] (0x0100): child [35846] finished successfully. (Mon Jul 23 21:59:35 2018) [sssd[be[corp.example.net]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Jul 23 21:59:35 2018) [sssd[be[corp.example.net]]] [dp_req_done] (0x0400): DP Request [PAM Authenticate #6]: Request handler finished [0]: Success (Mon Jul 23 21:59:35 2018) [sssd[be[corp.example.net]]] [_dp_req_recv] (0x0400): DP Request [PAM Authenticate #6]: Receiving request data. (Mon Jul 23 21:59
[SSSD-users] Re: problem login in with AD account after joined to the AD domain
It is resolved now.
we had some policies in place to prevent users from login in to systems if
they are not part of certain groups.
sssd works fine.
thanks
On Mon, Jul 23, 2018 at 12:07 PM, Jakub Hrozek wrote:
> On Mon, Jul 23, 2018 at 07:33:53AM -0700, Farshid Mahdavipour wrote:
> > thanks Jacob,
> > I set the log level to 6 in sssd.conf. here is the result:
> >
> > [root@azrclchefvm01 ~]# tail /var/log/sssd/*
> >
> > ==> /var/log/sssd/gpo_child.log <==
> >
> > (Mon Jul 23 13:50:58 2018) [[sssd[gpo_child[69656 [main] (0x0020):
> > gpo_child failed!
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888 [main] (0x0400):
> > gpo_child started.
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888 [main] (0x0400):
> > context initialized
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888 [unpack_buffer]
> > (0x0400): cached_gpt_version: -1
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888 [main] (0x0400):
> > performing smb operations
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888
> > [copy_smb_file_to_gpo_cache] (0x0400): smb_uri:
> smb://srv_addcp001/SysVol/
> > corp.example.com/Policies/{58C277F6-1C0E-4357-BFC7-47D7FC679B19}/GPT.INI
> >
> > (Mon Jul 23 14:25:37 2018) [[sssd[gpo_child[70888
> > [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed
> > [13][Permission denied]
> >
> > (Mon Jul 23 14:25:37 2018) [[sssd[gpo_child[70888
> > [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed
> > [13][Permission denied]
> >
> > (Mon Jul 23 14:25:37 2018) [[sssd[gpo_child[70888 [main] (0x0020):
> > perform_smb_operations failed.[13][Permission denied].
>
> Hi Michal, do you have some ideas?
>
> >
> > (Mon Jul 23 14:25:37 2018) [[sssd[gpo_child[70888 [main] (0x0020):
> > gpo_child failed!
> >
> >
> >
> > ==> /var/log/sssd/krb5_child.log <==
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887
> > [set_canonicalize_option] (0x0100): Canonicalization is set to [true]
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [main] (0x0400):
> > Will perform online auth
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [get_and_save_tgt]
> > (0x0400): Attempting kinit for realm [CORP.example.COM]
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [validate_tgt]
> > (0x0400): TGT verified using key for [AZRCLCHEFVM01$@CORP.example.COM].
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [sss_send_pac]
> > (0x0040): sss_pac_make_request failed [-1][2].
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [validate_tgt]
> > (0x0040): sss_send_pac failed, group membership for user with principal
> > [MAHDAVIF\@corp.example@corp.example.com] might not be correct.
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [switch_creds]
> > (0x0200): Switch user to [39599][59900].
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [switch_creds]
> > (0x0200): Already user [39599].
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [k5c_send_data]
> > (0x0200): Received error code 0
> >
> > (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [main] (0x0400):
> > krb5_child completed successfully
> >
> >
> >
> > ==> /var/log/sssd/ldap_child.log <==
> >
> > (Mon Jul 23 14:24:48 2018) [[sssd[ldap_child[70845 [prepare_response]
> > (0x0400): Building response for result [0]
> >
> > (Mon Jul 23 14:24:48 2018) [[sssd[ldap_child[70845 [main] (0x0400):
> > ldap_child completed successfully
> >
> > (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [main] (0x0400):
> > ldap_child started.
> >
> > (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [unpack_buffer]
> > (0x0200): Will run as [0][0].
> >
> > (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [become_user]
> > (0x0200): Trying to become user [0][0].
> >
> > (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [become_user]
> > (0x0200): Already user [0].
> >
> > (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886
> > [ldap_child_get_tgt_sync] (0x0100): Principal name is: [AZRCLCHEFVM01$@
> > CORP.example.COM]
> >
> > (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886
> > [ldap_child_get_tgt_sync] (0x0100): Using keytab
> [MEMORY:/etc/krb5.keytab]
> >
> > (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [prepare_response]
> > (0x0400): Building response for result [0]
> >
> > (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [main] (0x0400):
> > ldap_child completed successfully
> >
> >
> >
> > ==> /var/log/sssd/sssd_corp.example.com.log <==
> >
> > (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> > (0x0100): user: mahda...@corp.example.com
> >
> > (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> > (0x0100): service: sshd
> >
> > (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> > (0x0100): tty: ssh
> >
> > (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.c
[SSSD-users] id: cannot find name for group ID
Hi All! I am running into an issue where groups cannot be resolved upon login. All servers on CentOS 6 work fine, so this is isolated to newer sssd version on CentOS 7. [user@snoopy ~]$ id uid=11012(user) *gid=1001* *groups=1001*,10(wheel),1102 [user@snoopy ~]$ getent -s sss passwd user user:*:11012:1001:User Name:/home/user:/bin/bash However, a quick lookup against the group: [user@snoopy ~]$ *getent -s sss group security* security:*:1001:user Subsequent id lookup works: [user@snoopy ~]$ id uid=11012(user) *gid=1001(security) **groups=1001(security)*,10(wheel),1102 Sudo also complains about the user, even after above command succeeds [user@snoopy ~]$*sudo su -* *sudo: unknown uid 11012: who are you?* A few seconds later sudo is no longer confused: [user@snoopy ~]$*sudo su -* *LDAP OnePassword for **user**:* root@snoopy[~]# SSSD config: [sssd] config_file_version = 2 sbus_timeout = 30 services = nss, pam, sudo, ssh # BOUNCE DEV domains = LOCAL, HOSTOPIA, DOMAIN1, DOMAIN2, DOMAIN3 [nss] filter_users = adm,apache,avahi,bin,daemon,dbus,ecryptfs,ftp,git,games,gopher,haldaemon,halt,hfallback,hdeploy,influxdb,ldap,lp,mail,mailnull,named,news,nfsnobody,nobody,nscd,nslcd,ntp,operator,oprofile,osse c,postfix,puppet,puppet-dashboard,pulse,pulse-access,radiusd,root,rpc,rpcuser,rtkit,saslauth,sfallback,shutdown,slocate,smmsp,sshd,sync,tcpdump,tss,uucp,vcsa filter_groups = adm,apache,audio,bin,cdrom,cgred,daemon,dbus,dialout,dip,disk,ecryptfs,floppy,fuse,git,hfallback,hdeploy,influxdb,kmem,ldap,lock,lp,mail,mailnull,man,mem,nfsnobody,nobody,nscd,ntp,ossec,oprof ile,postdrop,postfix,puppet,puppet-dashboard,pulse,pulse-access,root,rpc,rpcuser,rtkit,saslauth,sfallback,slocate,smmsp,sshd,sys,tape,tcpdump,tss,tty,users,utempter,utmp,vcsa,video [pam] debug_level = 0 reconnection_retries = 3 offline_credentials_expiration = 2 offline_failed_login_attempts = 3 offline_failed_login_delay = 5 pam_verbosity = 1 pam_pwd_expiration_warning = 21 pam_account_expired_message = Your LDAP password has expired, please use selfservice portal to change your LDAP password. [sudo] debug_level = 0 [ssh] # debug_level = 0 [domain/LOCAL] description = LOCAL Users domain id_provider = local enumerate = true min_id = 500 max_id = 999 default_shell = /bin/bash base_directory = /home create_homedir = false remove_homedir = true homedir_umask = 077 skel_dir = /etc/skel mail_dir = /var/spool/mail All domains have the following options set: # SECTION: HOSTOPIA [domain/HOSTOPIA] min_id = 499 debug_level = 0 cache_credentials = True entry_cache_timeout = 864000 auth_provider = ldap id_provider = ldap access_provider = ldap chpass_provider = none sudo_provider = ldap selinux_provider = none autofs_provider = none hostid_provider = none ldap_use_tokengroups = false # https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ #ignore_group_members=True lookup_family_order = ipv4_only # LDAP Search ldap_search_base = dc=hostopia,dc=com ldap_group_search_base = ou=groups,o=Hostopia,dc=hostopia,dc=com?subtree?(|(cn=almighties)(cn=security)(cn=systems)(cn=bounce-development)(cn=development-wholesale)(cn=development-retail)(cn=abuse)) ldap_user_search_base = ou=users,o=hostopia,dc=hostopia,dc=com?subtree?(|(description=cn=bounce-development,ou=groups,o=Hostopia,dc=hostopia,dc=com)(description=cn=almighties,ou=groups,o=Hostopia,dc=hostopia ,dc=com)(description=cn=security,ou=groups,o=Hostopia,dc=hostopia,dc=com)) # LDAP Custom Schema ldap_group_member = hMemberDN ldap_user_member_of = description # ldap_schema can be set to "rfc2307", which stores group member names in the # "memberuid" attribute, or to "rfc2307bis", which stores group member DNs in # the "member" attribute. If you do not know this value, ask your LDAP # administrator. ldap_schema = rfc2307bis ldap_network_timeout = 3 ldap_id_use_start_tls = False ldap_tls_reqcert = never ldap_tls_cacertdir = /etc/openldap/cacerts # Ldap Servers ldap_uri = ldaps://SERVER1, ldaps://SERVER2, ldaps://SERVER3 ldap_backup_uri = ldaps://1.1.1.1 ldap_default_authtok_type = obfuscated_password ldap_default_bind_dn = ldap_default_authtok = ** ldap_user_ssh_public_key = sshPublicKey ldap_pwd_policy = none ldap_account_expire_policy = shadow ldap_user_shadow_expire = shadowExpire # shadowExpire: days since Jan 1, 1970 that account is disabled: $ echo $(($(date --utc --date "$1" +%s)/86400)) ldap_chpass_update_last_change = false ldap_access_order = filter, expire ldap_access_filter = (&(objectClass=posixAccount)(uidNumber=*)(hAccountInitialSetup=1)(|(description=cn=bounce-development,ou=groups,o=Hostopia,dc=hostopia,dc=com)(description=cn=almighties,ou=groups,o=Hosto pia,dc=hostopia,dc=com)(description=cn=security,ou=groups,o=Hostopia,dc=hostopia,dc=com))) # SUDO ldap_sudo_search_base = ou=sudoers,o=Hostopia,dc=hostopia,dc=com ldap_sudo_full_refresh_interval = 86400 ldap_sudo_smart_re
[SSSD-users] Re: "groups: cannot find name for group ID #####"
On Mon, Jul 23, 2018 at 11:08:54AM -0400, sssdusers.20.retin...@spamgourmet.com wrote: > Unfortunately it seems to not be so easy: > rtadmin@ubt18-test:~$ cat /etc/nsswitch.conf > ... > #passwd: compat systemd sss > #group: compat systemd sss > passwd: files sss > group: files sss > shadow: files sss > gshadow:files > ... > rtadmin@ubt18-test:~$ getent passwd user1 > user1:*:30335:33111:User One:/users/user1:/bin/bash > rtadmin@ubt18-test:~$ groups user1 > user1 : unix_users groups: cannot find name for group ID 33118 > 33118 > > Curiously, when I did `getent passwd user1` it seems to have resolved and > cached the primary group, but not any secondary groups. > > Discussing `sss_cache -E`, > rtadmin@ubt18-test:~$ sudo sss_cache -E > rtadmin@ubt18-test:~$ groups user1 > user1 : groups: cannot find name for group ID 33111 > 33111 groups: cannot find name for group ID 33118 > 33118 > rtadmin@ubt18-test:~$ groups user2 > user2 : groups: cannot find name for group ID 33111 > 33111 > rtadmin@ubt18-test:~$ getent passwd user2 > user2:*:30255:33111:User Two:/users/user2:/bin/bash > rtadmin@ubt18-test:~$ groups user2 > user2 : groups: cannot find name for group ID 33111 > 33111 > # (note that user2 is not in group 33118.) There are two issues. One is that initgroups does not find the supplementary groups and the other that the group ID cannot be resolved. For both it would be nice to see the logs, but since you were modifying nsswitch.conf -- is there an initgroups: line there at all? If not, it's fine because libc falls back to the groups: line, but if initgroups: is specified, it must contain sss as well. > > -- and that also shoots down my assumption regarding `getent passwd ` > causing the primary group to be cached. > > > > On Fri, Jul 20, 2018 at 5:55 PM, Joakim Tjernlund - > joakim.tjernl...@infinera.com < > sssdusers.retinkab.d133d58ee0.Joakim.Tjernlund#sssd-users@lists.fedorahosted.org> > wrote: > > > Start with replacing compat with files in nsswitch.conf > > > > > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/WNJZ6NRRSSN5UBVXSP34OUPVNMYDGVX2/ ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/XYYPS4JKVNRLJKOBUNI46A7SDMSA2RCF/
[SSSD-users] Re: problem login in with AD account after joined to the AD domain
On Mon, Jul 23, 2018 at 07:33:53AM -0700, Farshid Mahdavipour wrote:
> thanks Jacob,
> I set the log level to 6 in sssd.conf. here is the result:
>
> [root@azrclchefvm01 ~]# tail /var/log/sssd/*
>
> ==> /var/log/sssd/gpo_child.log <==
>
> (Mon Jul 23 13:50:58 2018) [[sssd[gpo_child[69656 [main] (0x0020):
> gpo_child failed!
>
> (Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888 [main] (0x0400):
> gpo_child started.
>
> (Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888 [main] (0x0400):
> context initialized
>
> (Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888 [unpack_buffer]
> (0x0400): cached_gpt_version: -1
>
> (Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888 [main] (0x0400):
> performing smb operations
>
> (Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888
> [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://srv_addcp001/SysVol/
> corp.example.com/Policies/{58C277F6-1C0E-4357-BFC7-47D7FC679B19}/GPT.INI
>
> (Mon Jul 23 14:25:37 2018) [[sssd[gpo_child[70888
> [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed
> [13][Permission denied]
>
> (Mon Jul 23 14:25:37 2018) [[sssd[gpo_child[70888
> [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed
> [13][Permission denied]
>
> (Mon Jul 23 14:25:37 2018) [[sssd[gpo_child[70888 [main] (0x0020):
> perform_smb_operations failed.[13][Permission denied].
Hi Michal, do you have some ideas?
>
> (Mon Jul 23 14:25:37 2018) [[sssd[gpo_child[70888 [main] (0x0020):
> gpo_child failed!
>
>
>
> ==> /var/log/sssd/krb5_child.log <==
>
> (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887
> [set_canonicalize_option] (0x0100): Canonicalization is set to [true]
>
> (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [main] (0x0400):
> Will perform online auth
>
> (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [get_and_save_tgt]
> (0x0400): Attempting kinit for realm [CORP.example.COM]
>
> (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [validate_tgt]
> (0x0400): TGT verified using key for [AZRCLCHEFVM01$@CORP.example.COM].
>
> (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [sss_send_pac]
> (0x0040): sss_pac_make_request failed [-1][2].
>
> (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [validate_tgt]
> (0x0040): sss_send_pac failed, group membership for user with principal
> [MAHDAVIF\@corp.example@corp.example.com] might not be correct.
>
> (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [switch_creds]
> (0x0200): Switch user to [39599][59900].
>
> (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [switch_creds]
> (0x0200): Already user [39599].
>
> (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [k5c_send_data]
> (0x0200): Received error code 0
>
> (Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [main] (0x0400):
> krb5_child completed successfully
>
>
>
> ==> /var/log/sssd/ldap_child.log <==
>
> (Mon Jul 23 14:24:48 2018) [[sssd[ldap_child[70845 [prepare_response]
> (0x0400): Building response for result [0]
>
> (Mon Jul 23 14:24:48 2018) [[sssd[ldap_child[70845 [main] (0x0400):
> ldap_child completed successfully
>
> (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [main] (0x0400):
> ldap_child started.
>
> (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [unpack_buffer]
> (0x0200): Will run as [0][0].
>
> (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [become_user]
> (0x0200): Trying to become user [0][0].
>
> (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [become_user]
> (0x0200): Already user [0].
>
> (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886
> [ldap_child_get_tgt_sync] (0x0100): Principal name is: [AZRCLCHEFVM01$@
> CORP.example.COM]
>
> (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886
> [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab]
>
> (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [prepare_response]
> (0x0400): Building response for result [0]
>
> (Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [main] (0x0400):
> ldap_child completed successfully
>
>
>
> ==> /var/log/sssd/sssd_corp.example.com.log <==
>
> (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> (0x0100): user: mahda...@corp.example.com
>
> (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> (0x0100): service: sshd
>
> (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> (0x0100): tty: ssh
>
> (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> (0x0100): ruser:
>
> (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> (0x0100): rhost: 172.17.253.11
>
> (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> (0x0100): authtok type: 0
>
> (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
> (0x0100): newauthtok type: 0
>
> (Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]]
[SSSD-users] Re: Missing group memberships with sssd (when using tokengroups)
On Mon, Jul 23, 2018 at 12:05:49PM -0400, Mario Rossi wrote: > > I am seeing similar issues on CentOS 7, where groups, including primary > group, cannot be looked up. This is really bad when other services depend on > group lookups, for example sshd match group statements for enabling > tcpforwarding which otherwise is disable globally, iptables group lookups ( > yes, I use both ). > > [root@snoopy ~]$ rpm -q sssd > sssd-1.16.0-19.el7_5.5.x86_64 > > root@snoopy[/etc/sssd]# service sssd stop; rm -f /var/lib/sss/db/*; service > sssd start > Redirecting to /bin/systemctl stop sssd.service > Redirecting to /bin/systemctl start sssd.service > > root@snoopy[/etc/sssd]# id ezaporozh...@hostopia.com > uid=11158(ezaporozhets)*gid=1004* groups=*1004*,1102 > > > root@snoopy[/etc/sssd]# *getent -s sss group > development-wholes...@hostopia.com* > development-wholesale:*:1004:ezaporozhets,alyubyanitskiy > > root@snoopy[/etc/sssd]# id ezaporozh...@hostopia.com > uid=11158(ezaporozhets)*gid=1004(development-wholesale) > **groups=1004(development-wholesale),1102* > > I tried setting ldap_use_tokengroups = false at domain level, however still > seeing the issue. I use ldap provider. Then tokengroups are not relevant at all, it's an AD provider option primarily. I would suggest to gather the logs (and even better, start a separate thread so the two don't mixed up..) > > Thank you > > On 07/23/2018 04:13 AM, Jakub Hrozek wrote: > > > > > On 22 Jul 2018, at 20:49, Spike White wrote: > > > > > > I can't replicate that "duplicate domains" situation any more. (I > > > thought I'd saved that sssd.conf file, but it doesn't exhibit the same > > > behaviour). > > > > > > Here are the logs for a specific account failing to look up all groups > > > with ldap_use_tokengroups = True. > > > > > > Logs are at this URL: > > > > > > https://www.dropbox.com/sh/l37pj104qkrqxfa/AACuKgaQjWZ4MVr1NdEogbcMa?dl=0 > > > > > > I have included the realmd.conf, sssd.conf and krb5.conf as well. > > > > > > Here's (incorrect) result back from sssd with ldap_use_tokengroups = True > > > > > > [root@spikerealmd02 sssd]# id admpatrick_wheeler > > > uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) > > > groups=2604370(admpatrick_wheeler),1010(amerunixusers) > > > > > Thank you, now the logs are more helpful. What I see is repetition of “cant > > find domain for $SID”. And I believe this is because the subdomains > > provider is disabled, because (quite confusingly) the subdomains provider > > is also responsible for fetching information about the joined domain, like > > its SID or the NetBIOS name. > > > > So I think there are three options: > > 1) add ad_enabled_domains=$self to each of the domains, e.g. add > > ad_enabled_domains=amer.dell.com to the amer.dell.com domain. This should > > make sssd fetch info about that domain only. I know you wrote earlier that > > this gave you some other headaches, but if it does, then there’s another > > bug.. > > 2) try to help sssd by setting the domain SID manually with the > > ldap_idmap_default_domain_sid option > > 3) just use tokengroups=false as a workaround. > > > > > Here is correct result back when ldap_use_tokengropus = False: > > > > > > [root@spikerealmd02 sssd]# id admpatrick_wheeler > > > uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) > > > groups=2604370(admpatrick_wheeler),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport),1010(amerunixusers),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),1033(amer_server_mgmt),1003(amerlinuxsup) > > > > > > this is sssd version 1.16.0 > > > > > > Spike > > > > > > > > > > > Thanks, this is more helpful > > > On Thu, Jul 19, 2018 at 4:15 AM Jakub Hrozek wrote: > > > > > > > > > > On 13 Jul 2018, at 17:40, Spike White wrote: > > > > > > > > Jakub, > > > > > > > > Thank you to answering so promptly. > > > > > > > > We are currently testing this in a lab before full deployment, so I > > > > have some degree of time before we deploy sssd in a bigger context. If > > > > you would prefer for me to work with you directly off-line, please > > > > advise. As an example, the attached sssd_amer.dell.com.log file was > > > > originally 40 MB. (I presume because of debugging level). Out of > > > > respect for others on the mailing list, I severely trimmed the log file > > > > to only the lines of interest (I hope). But it's entirely possible I > > > > may have over-trimmed. > > > > > > > I’m afraid so, because the logs say: > > > > > > (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] [sdap_parse_range] > > > (0x2000): No sub-attributes for [tokenGroups] > > > …. > > > > > > and I’m really interested in this part :-) > > > > > > (Fri Jul 13 09:25:43 2018) [sssd[be[a
[SSSD-users] Re: Missing group memberships with sssd (when using tokengroups)
Perhaps this is a caching issue? I do have several domains configured, and each domain has development-wholesale name with different GID. Is the domains cache configured/hased based on the group name ? Thanks On 07/23/2018 12:05 PM, Mario Rossi wrote: I am seeing similar issues on CentOS 7, where groups, including primary group, cannot be looked up. This is really bad when other services depend on group lookups, for example sshd match group statements for enabling tcpforwarding which otherwise is disable globally, iptables group lookups ( yes, I use both ). [root@snoopy ~]$ rpm -q sssd sssd-1.16.0-19.el7_5.5.x86_64 root@snoopy[/etc/sssd]# service sssd stop; rm -f /var/lib/sss/db/*; service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service root@snoopy[/etc/sssd]# id ezaporozh...@hostopia.com uid=11158(ezaporozhets)*gid=1004* groups=*1004*,1102 root@snoopy[/etc/sssd]# *getent -s sss group development-wholes...@hostopia.com* development-wholesale:*:1004:ezaporozhets,alyubyanitskiy root@snoopy[/etc/sssd]# id ezaporozh...@hostopia.com uid=11158(ezaporozhets)*gid=1004(development-wholesale) **groups=1004(development-wholesale),1102* I tried setting ldap_use_tokengroups = false at domain level, however still seeing the issue. I use ldap provider. Thank you On 07/23/2018 04:13 AM, Jakub Hrozek wrote: On 22 Jul 2018, at 20:49, Spike White wrote: I can't replicate that "duplicate domains" situation any more. (I thought I'd saved that sssd.conf file, but it doesn't exhibit the same behaviour). Here are the logs for a specific account failing to look up all groups with ldap_use_tokengroups = True. Logs are at this URL: https://www.dropbox.com/sh/l37pj104qkrqxfa/AACuKgaQjWZ4MVr1NdEogbcMa?dl=0 I have included the realmd.conf, sssd.conf and krb5.conf as well. Here's (incorrect) result back from sssd with ldap_use_tokengroups = True [root@spikerealmd02 sssd]# id admpatrick_wheeler uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) groups=2604370(admpatrick_wheeler),1010(amerunixusers) Thank you, now the logs are more helpful. What I see is repetition of “cant find domain for $SID”. And I believe this is because the subdomains provider is disabled, because (quite confusingly) the subdomains provider is also responsible for fetching information about the joined domain, like its SID or the NetBIOS name. So I think there are three options: 1) add ad_enabled_domains=$self to each of the domains, e.g. add ad_enabled_domains=amer.dell.com to the amer.dell.com domain. This should make sssd fetch info about that domain only. I know you wrote earlier that this gave you some other headaches, but if it does, then there’s another bug.. 2) try to help sssd by setting the domain SID manually with the ldap_idmap_default_domain_sid option 3) just use tokengroups=false as a workaround. Here is correct result back when ldap_use_tokengropus = False: [root@spikerealmd02 sssd]# id admpatrick_wheeler uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) groups=2604370(admpatrick_wheeler),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport),1010(amerunixusers),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),1033(amer_server_mgmt),1003(amerlinuxsup) this is sssd version 1.16.0 Spike Thanks, this is more helpful On Thu, Jul 19, 2018 at 4:15 AM Jakub Hrozek wrote: On 13 Jul 2018, at 17:40, Spike White wrote: Jakub, Thank you to answering so promptly. We are currently testing this in a lab before full deployment, so I have some degree of time before we deploy sssd in a bigger context. If you would prefer for me to work with you directly off-line, please advise. As an example, the attached sssd_amer.dell.com.log file was originally 40 MB. (I presume because of debugging level). Out of respect for others on the mailing list, I severely trimmed the log file to only the lines of interest (I hope). But it's entirely possible I may have over-trimmed. I’m afraid so, because the logs say: (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [tokenGroups] …. and I’m really interested in this part :-) (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] [sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for [admpatrick_whee...@amer.dell.com] ... (Fri Jul 13 09:25:48 2018) [sssd[be[amer.dell.com]]] [sdap_asq_search_parse_entry] (0x2000): Matched objectclass [user] on DN [CN=AdmPatrick_Wheeler,OU=AdmAccounts,DC=amer,DC=dell,DC=com], will use associated map You asked: Can you send logs for a single lookup of "id username" with tokengroups enabled? Attached are the logs. sssd_amer.dell.com.log and sssd_n
[SSSD-users] Re: Missing group memberships with sssd (when using tokengroups)
I am seeing similar issues on CentOS 7, where groups, including primary group, cannot be looked up. This is really bad when other services depend on group lookups, for example sshd match group statements for enabling tcpforwarding which otherwise is disable globally, iptables group lookups ( yes, I use both ). [root@snoopy ~]$ rpm -q sssd sssd-1.16.0-19.el7_5.5.x86_64 root@snoopy[/etc/sssd]# service sssd stop; rm -f /var/lib/sss/db/*; service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service root@snoopy[/etc/sssd]# id ezaporozh...@hostopia.com uid=11158(ezaporozhets)*gid=1004* groups=*1004*,1102 root@snoopy[/etc/sssd]# *getent -s sss group development-wholes...@hostopia.com* development-wholesale:*:1004:ezaporozhets,alyubyanitskiy root@snoopy[/etc/sssd]# id ezaporozh...@hostopia.com uid=11158(ezaporozhets)*gid=1004(development-wholesale) **groups=1004(development-wholesale),1102* I tried setting ldap_use_tokengroups = false at domain level, however still seeing the issue. I use ldap provider. Thank you On 07/23/2018 04:13 AM, Jakub Hrozek wrote: On 22 Jul 2018, at 20:49, Spike White wrote: I can't replicate that "duplicate domains" situation any more. (I thought I'd saved that sssd.conf file, but it doesn't exhibit the same behaviour). Here are the logs for a specific account failing to look up all groups with ldap_use_tokengroups = True. Logs are at this URL: https://www.dropbox.com/sh/l37pj104qkrqxfa/AACuKgaQjWZ4MVr1NdEogbcMa?dl=0 I have included the realmd.conf, sssd.conf and krb5.conf as well. Here's (incorrect) result back from sssd with ldap_use_tokengroups = True [root@spikerealmd02 sssd]# id admpatrick_wheeler uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) groups=2604370(admpatrick_wheeler),1010(amerunixusers) Thank you, now the logs are more helpful. What I see is repetition of “cant find domain for $SID”. And I believe this is because the subdomains provider is disabled, because (quite confusingly) the subdomains provider is also responsible for fetching information about the joined domain, like its SID or the NetBIOS name. So I think there are three options: 1) add ad_enabled_domains=$self to each of the domains, e.g. add ad_enabled_domains=amer.dell.com to the amer.dell.com domain. This should make sssd fetch info about that domain only. I know you wrote earlier that this gave you some other headaches, but if it does, then there’s another bug.. 2) try to help sssd by setting the domain SID manually with the ldap_idmap_default_domain_sid option 3) just use tokengroups=false as a workaround. Here is correct result back when ldap_use_tokengropus = False: [root@spikerealmd02 sssd]# id admpatrick_wheeler uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) groups=2604370(admpatrick_wheeler),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport),1010(amerunixusers),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),1033(amer_server_mgmt),1003(amerlinuxsup) this is sssd version 1.16.0 Spike Thanks, this is more helpful On Thu, Jul 19, 2018 at 4:15 AM Jakub Hrozek wrote: On 13 Jul 2018, at 17:40, Spike White wrote: Jakub, Thank you to answering so promptly. We are currently testing this in a lab before full deployment, so I have some degree of time before we deploy sssd in a bigger context. If you would prefer for me to work with you directly off-line, please advise. As an example, the attached sssd_amer.dell.com.log file was originally 40 MB. (I presume because of debugging level). Out of respect for others on the mailing list, I severely trimmed the log file to only the lines of interest (I hope). But it's entirely possible I may have over-trimmed. I’m afraid so, because the logs say: (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [tokenGroups] …. and I’m really interested in this part :-) (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] [sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for [admpatrick_whee...@amer.dell.com] ... (Fri Jul 13 09:25:48 2018) [sssd[be[amer.dell.com]]] [sdap_asq_search_parse_entry] (0x2000): Matched objectclass [user] on DN [CN=AdmPatrick_Wheeler,OU=AdmAccounts,DC=amer,DC=dell,DC=com], will use associated map You asked: Can you send logs for a single lookup of "id username" with tokengroups enabled? Attached are the logs. sssd_amer.dell.com.log and sssd_nss.log, for this lookup: [root@spikerealmd02 sssd]# id admpatrick_wheeler uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) groups=2604370(admpatrick_wheeler),1010(amerunixusers) This is with ldap_use_tokengroups = True, so the ab
[SSSD-users] Re: "groups: cannot find name for group ID #####"
Unfortunately it seems to not be so easy: rtadmin@ubt18-test:~$ cat /etc/nsswitch.conf ... #passwd: compat systemd sss #group: compat systemd sss passwd: files sss group: files sss shadow: files sss gshadow:files ... rtadmin@ubt18-test:~$ getent passwd user1 user1:*:30335:33111:User One:/users/user1:/bin/bash rtadmin@ubt18-test:~$ groups user1 user1 : unix_users groups: cannot find name for group ID 33118 33118 Curiously, when I did `getent passwd user1` it seems to have resolved and cached the primary group, but not any secondary groups. Discussing `sss_cache -E`, rtadmin@ubt18-test:~$ sudo sss_cache -E rtadmin@ubt18-test:~$ groups user1 user1 : groups: cannot find name for group ID 33111 33111 groups: cannot find name for group ID 33118 33118 rtadmin@ubt18-test:~$ groups user2 user2 : groups: cannot find name for group ID 33111 33111 rtadmin@ubt18-test:~$ getent passwd user2 user2:*:30255:33111:User Two:/users/user2:/bin/bash rtadmin@ubt18-test:~$ groups user2 user2 : groups: cannot find name for group ID 33111 33111 # (note that user2 is not in group 33118.) -- and that also shoots down my assumption regarding `getent passwd ` causing the primary group to be cached. On Fri, Jul 20, 2018 at 5:55 PM, Joakim Tjernlund - joakim.tjernl...@infinera.com < sssdusers.retinkab.d133d58ee0.Joakim.Tjernlund#sssd-users@lists.fedorahosted.org> wrote: > Start with replacing compat with files in nsswitch.conf > > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/WNJZ6NRRSSN5UBVXSP34OUPVNMYDGVX2/
[SSSD-users] Re: problem login in with AD account after joined to the AD domain
thanks Jacob,
I set the log level to 6 in sssd.conf. here is the result:
[root@azrclchefvm01 ~]# tail /var/log/sssd/*
==> /var/log/sssd/gpo_child.log <==
(Mon Jul 23 13:50:58 2018) [[sssd[gpo_child[69656 [main] (0x0020):
gpo_child failed!
(Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888 [main] (0x0400):
gpo_child started.
(Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888 [main] (0x0400):
context initialized
(Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888 [unpack_buffer]
(0x0400): cached_gpt_version: -1
(Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888 [main] (0x0400):
performing smb operations
(Mon Jul 23 14:25:36 2018) [[sssd[gpo_child[70888
[copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://srv_addcp001/SysVol/
corp.example.com/Policies/{58C277F6-1C0E-4357-BFC7-47D7FC679B19}/GPT.INI
(Mon Jul 23 14:25:37 2018) [[sssd[gpo_child[70888
[copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed
[13][Permission denied]
(Mon Jul 23 14:25:37 2018) [[sssd[gpo_child[70888
[perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed
[13][Permission denied]
(Mon Jul 23 14:25:37 2018) [[sssd[gpo_child[70888 [main] (0x0020):
perform_smb_operations failed.[13][Permission denied].
(Mon Jul 23 14:25:37 2018) [[sssd[gpo_child[70888 [main] (0x0020):
gpo_child failed!
==> /var/log/sssd/krb5_child.log <==
(Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887
[set_canonicalize_option] (0x0100): Canonicalization is set to [true]
(Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [main] (0x0400):
Will perform online auth
(Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [get_and_save_tgt]
(0x0400): Attempting kinit for realm [CORP.example.COM]
(Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [validate_tgt]
(0x0400): TGT verified using key for [AZRCLCHEFVM01$@CORP.example.COM].
(Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [sss_send_pac]
(0x0040): sss_pac_make_request failed [-1][2].
(Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [validate_tgt]
(0x0040): sss_send_pac failed, group membership for user with principal
[MAHDAVIF\@corp.example@corp.example.com] might not be correct.
(Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [switch_creds]
(0x0200): Switch user to [39599][59900].
(Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [switch_creds]
(0x0200): Already user [39599].
(Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [k5c_send_data]
(0x0200): Received error code 0
(Mon Jul 23 14:25:36 2018) [[sssd[krb5_child[70887 [main] (0x0400):
krb5_child completed successfully
==> /var/log/sssd/ldap_child.log <==
(Mon Jul 23 14:24:48 2018) [[sssd[ldap_child[70845 [prepare_response]
(0x0400): Building response for result [0]
(Mon Jul 23 14:24:48 2018) [[sssd[ldap_child[70845 [main] (0x0400):
ldap_child completed successfully
(Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [main] (0x0400):
ldap_child started.
(Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [unpack_buffer]
(0x0200): Will run as [0][0].
(Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [become_user]
(0x0200): Trying to become user [0][0].
(Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [become_user]
(0x0200): Already user [0].
(Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886
[ldap_child_get_tgt_sync] (0x0100): Principal name is: [AZRCLCHEFVM01$@
CORP.example.COM]
(Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886
[ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab]
(Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [prepare_response]
(0x0400): Building response for result [0]
(Mon Jul 23 14:25:35 2018) [[sssd[ldap_child[70886 [main] (0x0400):
ldap_child completed successfully
==> /var/log/sssd/sssd_corp.example.com.log <==
(Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
(0x0100): user: mahda...@corp.example.com
(Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
(0x0100): service: sshd
(Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
(0x0100): tty: ssh
(Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
(0x0100): ruser:
(Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
(0x0100): rhost: 172.17.253.11
(Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
(0x0100): authtok type: 0
(Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
(0x0100): newauthtok type: 0
(Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
(0x0100): priv: 1
(Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
(0x0100): cli_pid: 70882
(Mon Jul 23 14:25:37 2018) [sssd[be[corp.example.com]]] [pam_print_data]
(0x0100): logon name: not set
==> /var/log/sssd/sssd.log <==
(Mon Jul 23 14:24:48 2018) [sssd] [sbus_conn_register_path] (0x0400):
Registering object path /org/freed
[SSSD-users] "groups: cannot find name for group ID #####"
Hi, I was wondering if anyone has successfully fixed this. I'm working on upgrading servers and client machines, and any time I use a newer SSSD package I'm unable to get groups for the users when they log in. (This is SSSD 1.16.1 on ubt18.04). The problem can be summed up as, root@ubt18-test:# sssd --version 1.16.1 root@ubt18-test:# groups user1 user1 : groups: cannot find name for group ID 33111 33111 groups: cannot find name for group ID 33118 33118 root@ubt18-test:# getent group | grep 33111 unix_users:*:33111: root@ubt18-test:# groups user2 user2 : groups: cannot find name for group ID 33111 33111 root@ubt18-test:# su user2 groups: cannot find name for group ID 33111 user2@ubt18-test:$ groups groups: cannot find name for group ID 33111 33111 -- root@ubt18-test:# getent group unix_users unix_users:*:33111: root@ubt18-test:# groups user2 user2 : unix_users root@blair-ubt18-test:/var/log/sssd# groups user1 user1 : unix_users groups: cannot find name for group ID 33118 33118 This is an odd sequence of events, but notice that I can't get the group for a given user. It shows up only as GID. However, that GID _is_ listed in the output of `getent group`, so it's there, the system can see it, and SSSD is aware of it. Trying again, that gid still won't map to a name when I get the user's groups. The odd part is that if I get the group specifically (`getent group unix_users`), then the mapping for that group thereafter succeeds. Does anyone know what's going on? Of course, everything is working as expected with an earlier version -- 1.13.4. The only fix that I've seen is to recreate every LDAP group in the local groups file, but that seems contrary to the point of using LDAP. I'd like to avoid it. /etc/nsswitch.conf: #passwd: compat systemd sss #group: compat systemd sss passwd: compat sss group: compat sss # it's the same with/without systemd /etc/sssd/sssd.conf: [domain/LOCAL] enumerate = True id_provider = local max_id = min_id = 1000 [domain/MYDOMAIN] access_provider = simple auth_provider = krb5 debug_level = 0xFF0 cache_credentials = True chpass_provider = krb5 enumerate = True id_provider = ldap krb5_kpasswd = core-dc1.mydomain.cxm krb5_realm = mydomain.cxm krb5_renewable_lifetime = 7d krb5_server = core-dc1.mydomain.cxm ldap_default_authtok = thepassword ldap_default_authtok_type = password ldap_default_bind_dn = cn=LDAP Bind,ou=ServiceAccounts,ou=_MyDomain,dc=mydomain,dc=cxm ldap_group_object_class = group ldap_group_search_base = OU=_MyDomain,DC=MYDOMAIN,DC=CXM ldap_search_base = DC=MYDOMAIN,DC=CXM ldap_tls_reqcert = never ldap_uri = ldap://core-dc1.mydomain.cxm ldap_user_home_directory = unixHomeDirectory ldap_user_name = sAMAccountName ldap_user_object_class = user ldap_user_search_base = OU=_MyDomain,DC=MYDOMAIN,DC=CXM [nss] filter_groups = root filter_users = root reconnection_retries = 50 [pam] pam_verbosity = 3 reconnection_retries = 50 [sssd] config_file_version = 2 debug_level = 0xFF0 domains = LOCAL, MYDOMAIN reconnection_retries = 50 sbus_timeout = 5 services = nss, pam ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/3TC4P2IWIIIJXFCDMWBQUGY752GZPADW/
[SSSD-users] Re: sss_override and ssh keys
Jakub, again thankyou for your reply. I am still debugging this one. I think I have narrowed it down to a PAM configuration, after I ran sssd with a high debug level. For anyone following this thread: /usr/sbin/ssshd -ddd The failure I get is: PAM: do_pam_account pam_acct_mgmt = 4 (System error) I think (not sure yet) that the problem is in pam.d/common-account where a local user is looked for: account sufficient pam_localuser.so I have been getting different behaviour this morning - I suspect because of sssd cacheing. Am running now with memcache_timeout = 0 On 19 July 2018 at 11:18, Jakub Hrozek wrote: > > > > On 11 Jul 2018, at 15:28, John Hearns wrote: > > > > I have set up an sss_override for my user account > > > > johe:*:1234:1234:John Hearns,,,:/home/johe:/bin/bash > > > > I also have an entry in the locla /etc/passwd file. > > When I ssh to a server running sssd my ssh key is accepted. > > > > When I have no local /etc/passwd > > When I ssh to a server running sssd my ssh key is not used and I am > prompted for a password > > Is that a local SSH key stored in the user’s home or in LDAP? If a local > one, then I think the only important thing is to tell SSH where to look at, > so the homedir must be correct and of course the user must have the correct > UID and GID to be allowed to enter that homedir. > > > > > Can anyone explain please? > > > > The answer will be along the lines of at what stage in the ssh login the > override is being 'honoured' > > However this is a bit of a major problem. I guess also I will be told > that I have done something wrong. > > ___ > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@ > lists.fedorahosted.org/message/ARZQMHUEUBXR53P7XG5QSFMDU6KHBK3O/ > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@ > lists.fedorahosted.org/message/DL67YE2ZEIQ5LY2UCIVRRW5U7DLM7LMZ/ > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/KK6PJAWE3SNSWOX7T6WR4RTGGVTAOTZO/
[SSSD-users] Re: SSSD on CentOS 7 failing to start when connecting to Samba 4.8.3 AD via LDAP
Mark, for information you can increase the mumber of retries by reconnection_retries = N However that does not help you with your problem! On 23 July 2018 at 04:05, Mark Johnson wrote: > I've been going around in circles with this for days and I'm stuck. I'm > trying to run up a new AD environment with only Samba 4.8.3 servers that > we'll authenticate user server access against via SSSD/LDAP using a simple > bind. All of our servers are either CentOS 6 or 7. > > I've created a test environment with a single Samba AD 4.8.3 server as the > AD server, a Windows 7 client to run RSAT and a CentOS 6 and CentOS 7 > server to test user authentication. The Samba server is up and running and > I can manage the directory via RSAT. I've set up the CentOS 6 server and > can successfully authenticate user logins on this via using SSSD/LDAP to > the AD. However, the issue I have is with the CentOS 7 server. I've > basically copied the SSSD config from the CentOS 6 server so everything is > the same. However, when I start SSSD on the CentOS 7 server, it binds > successfully and does an initial searchRequest which it gets a result from > but after doing the subsequent searchRequests on Configuration, > ForestDnsZones and DomainDnsZones I just see a RST from the server and the > whole process starts over again. Over the third failure, SSSD fails to > start and stops trying. > > Comparing packet captures on the AD server when starting SSSD on both > servers, the initial ROOT search request and response are identical as is > the bind request and response. However, the first wholeSubtree search > request is where things start looking different. On the CentOS 6 server, > it shows a filter in the request of: > Filter: (&(&(cn=smtp)(ipServiceProtocol=dccp))(objectclass=ipService)) > and there are 4 attributes in the request - objectClass, cn, > ipServicePort, ipServiceProtocol > > Whereas on the CentOS 7 server, the filter looks like this: > Filter: (&(objectClass=sudoRole)(|(|(|(|(|(|(|(|(|(!(sudoHost=*))(su > doHost=ALL))(sudoHost=ldaptest7.company.com))(sudoHost=ldapt > est7))(sudoHost=192.168.193.62))(sudoHost=192.168.192.0/ > 23))(sudoHost=fe80::5054:ff:fef2:26ed))(sudoHost=fe80::/6 > with 13 attributes - objectClass, cn, and a bunch of sudo attributes. > > The response from the Samba server to each of these is nearly identical. > Both servers then send searchRequests for Configuration, ForestDnsZones and > DomainDnsZones but with the same filter differences above. This is the > point of failure for the CentOS 7 server. The other server gets a > successful response from the Samba server, but the CentOS 7 server just > gets an ACK. When I up the debug level on SSSD on the CentOS 7 server, I > see a few different errors but I'm not sure which of these show cause or > effect. Examples... > > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] > [common_parse_search_base] (0x0100): Search base added: > [SUDO][dc=ad,dc=company,dc=com][SUBTREE][] > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] > [common_parse_search_base] (0x0100): Search base added: > [AUTOFS][dc=ad,dc=company,dc=com][SUBTREE][] > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] > [dp_client_register] (0x0100): Cancel DP ID timeout [0x55941e9a6860] > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] [dp_find_method] > (0x0100): Target [subdomains] is not initialized > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] > [dp_req_reply_gen_error] (0x0080): DP Request [Subdomains #0]: Finished. > Target is not supported with this configuration. > > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [set_server_common_status] (0x0100): Marking server '192.168.192.50' as > 'resolving name' > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [set_server_common_status] (0x0100): Marking server '192.168.192.50' as > 'name resolved' > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility > level to [4] > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [sdap_cli_auth_step] (0x0100): expire timeout is 900 > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [simple_bind_send] > (0x0100): Executing simple bind as: s...@ad.company.com > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [fo_set_port_status] (0x0100): Marking port 389 of server '192.168.192.50' > as 'working' > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [set_server_common_status] (0x0100): Marking server '192.168.192.50' as > 'working' > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [be_run_online_cb] > (0x0080): Going online. Running callbacks. > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [be_ptask_enable] > (0x0080): Task [SUDO Smart Refresh]: already enabled > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]
[SSSD-users] Re: sss_override and ssh keys
Just an update. The fix for me is setting this in the pam stanza pam_response_filter = ENV:KRB5CCNAME On 19 July 2018 at 12:56, John Hearns wrote: > Jakub, > again thankyou for your reply. I am still debugging this one. I think I > have narrowed it down to a PAM configuration, after I ran sssd with a high > debug level. > For anyone following this thread: > > /usr/sbin/ssshd -ddd > > The failure I get is: PAM: do_pam_account pam_acct_mgmt = 4 (System error) > > I think (not sure yet) that the problem is in pam.d/common-account where a > local user is looked for: > account sufficient pam_localuser.so > > I have been getting different behaviour this morning - I suspect because > of sssd cacheing. Am running now with > memcache_timeout = 0 > > > > > > > > > > > > > > > > > > > On 19 July 2018 at 11:18, Jakub Hrozek wrote: > >> >> >> > On 11 Jul 2018, at 15:28, John Hearns wrote: >> > >> > I have set up an sss_override for my user account >> > >> > johe:*:1234:1234:John Hearns,,,:/home/johe:/bin/bash >> > >> > I also have an entry in the locla /etc/passwd file. >> > When I ssh to a server running sssd my ssh key is accepted. >> > >> > When I have no local /etc/passwd >> > When I ssh to a server running sssd my ssh key is not used and I am >> prompted for a password >> >> Is that a local SSH key stored in the user’s home or in LDAP? If a local >> one, then I think the only important thing is to tell SSH where to look at, >> so the homedir must be correct and of course the user must have the correct >> UID and GID to be allowed to enter that homedir. >> >> > >> > Can anyone explain please? >> > >> > The answer will be along the lines of at what stage in the ssh login >> the override is being 'honoured' >> > However this is a bit of a major problem. I guess also I will be told >> that I have done something wrong. >> > ___ >> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org >> > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org >> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> > List Archives: https://lists.fedoraproject.or >> g/archives/list/sssd-users@lists.fedorahosted.org/message/AR >> ZQMHUEUBXR53P7XG5QSFMDU6KHBK3O/ >> ___ >> sssd-users mailing list -- sssd-users@lists.fedorahosted.org >> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedoraproject.or >> g/archives/list/sssd-users@lists.fedorahosted.org/message/DL >> 67YE2ZEIQ5LY2UCIVRRW5U7DLM7LMZ/ >> > > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/OG4J7BNRRMUXXQKJWJQZRWKOQ2P6742U/
[SSSD-users] Re: Problem with kinit
Jakub, thankyou for your reply. > If your configuration is using id_provider=ad I would have expected sssd to prefer the netbiosname$ principal, Indeed. My reading of kinit is that it should take the first principal in the list returned by klist. In my case thsi should be ibis$ # klist -k 11 ibis$@NZWW.NZCORP.NET 11 ibis$@NZWW.NZCORP.NET 11 IBIS$@NZWW.NZCORP.NET 11 IBIS$@NZWW.NZCORP.NET 11 ibis$@NZWW.NZCORP.NET 11 host/i...@nzww.nzcorp.net 11 host/i...@nzww.nzcorp.net 11 IBIS$@NZWW.NZCORP.NET 11 host/i...@nzww.nzcorp.net On 19 July 2018 at 11:09, Jakub Hrozek wrote: > > > > On 16 Jul 2018, at 11:48, John Hearns wrote: > > > > I have had my head inside the ldap_child.c source code all morning. > > I am getting these errors logged: > > > > [ldap_child_get_tgt_sync] (0x0100): Using keytab > [MEMORY:/etc/krb5.keytab] > > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client > 'host/ > > i...@nzww.nzcorp.net' not found in Kerberos database > > This is expected, in AD the host/fqdn principal cannot be used to get a > TGT. As you can see below, you are using the netbiosname$@realm principal > to kinit which works fine. > > If your configuration is using id_provider=ad I would have expected sssd > to prefer the netbiosname$ principal, but if the selection fails or you are > using the ldap provider, you can help sssd with the ldap_sasl_authid > parameter. > > > > > However the dialy ksktutil cron job I have running completes OK, and > msktutil --auto-update tells me the machine password was renewed two days > ago. > > > > Here is what happens when I run kinit from the command line. > > My workstation is called ibis. Please someone hit me with a clue stick. > > > > # kinit -k > > kinit: Client 'host/i...@nzww.nzcorp.net' not found in Kerberos > database while getting initial credentials > > > > # kinit -V -k ibis$ > > Using default cache: /tmp/krb5cc_0 > > Using principal: ibis$@NZWW.NZCORP.NET > > Authenticated to Kerberos v5 > > > > # kinit -V -k IBIS\$@NZWW.NZCORP.NET > > Using default cache: /tmp/krb5cc_0 > > Using principal: IBIS$@NZWW.NZCORP.NET > > Authenticated to Kerberos v5 > > > > > > ___ > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@ > lists.fedorahosted.org/message/4DY3TSRSJBV5AU2P3CQH2UHH7GHXLOLV/ > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@ > lists.fedorahosted.org/message/BPEL355LXLAJ4ZI7UVSFHJ5ZG6CUJIWI/ > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/JMD7PMTGOQAGYKXDANGWFI72X3I6S3DY/
[SSSD-users] Re: Am I blocked on sssd-users mailing list?
> On 19 Jul 2018, at 15:37, Spike White wrote: > > All, > > I fear I may be blocked. I responded to an email thread, with an email that > had two small attachments. > > That was wrong. I read the mailing list by-laws and I realize that was > wrong. I will not repeat that offense. As the guidelines suggest, if I need > to send logs I'll post somewhere publicly and reference those URLs. > > But I fear my transgression seems to have blocked my email address on > sssd-users mailing list. Sending this short email to confirm. You’re not blocked from the list (and I don’t remember anyone being blocked, ever..). What might have happened is that the mail might have gotten stuck in the moderation queue because the attachment was too large.. > > Spike > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/5EMICYRTWWL47SN2RZIMSGIFLSFTUYLB/ ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/BK576KQ4BM65EOMZP2UI5XW6TU43LI7B/
[SSSD-users] Re: SSSD on CentOS 7 failing to start when connecting to Samba 4.8.3 AD via LDAP
> On 23 Jul 2018, at 04:05, Mark Johnson wrote: > > I've been going around in circles with this for days and I'm stuck. I'm > trying to run up a new AD environment with only Samba 4.8.3 servers that > we'll authenticate user server access against via SSSD/LDAP using a simple > bind. All of our servers are either CentOS 6 or 7. > > I've created a test environment with a single Samba AD 4.8.3 server as the AD > server, a Windows 7 client to run RSAT and a CentOS 6 and CentOS 7 server to > test user authentication. The Samba server is up and running and I can > manage the directory via RSAT. I've set up the CentOS 6 server and can > successfully authenticate user logins on this via using SSSD/LDAP to the AD. > However, the issue I have is with the CentOS 7 server. I've basically copied > the SSSD config from the CentOS 6 server so everything is the same. However, > when I start SSSD on the CentOS 7 server, it binds successfully and does an > initial searchRequest which it gets a result from but after doing the > subsequent searchRequests on Configuration, ForestDnsZones and DomainDnsZones > I just see a RST from the server and the whole process starts over again. > Over the third failure, SSSD fails to start and stops trying. > > Comparing packet captures on the AD server when starting SSSD on both > servers, the initial ROOT search request and response are identical as is the > bind request and response. However, the first wholeSubtree search request is > where things start looking different. On the CentOS 6 server, it shows a > filter in the request of: > Filter: (&(&(cn=smtp)(ipServiceProtocol=dccp))(objectclass=ipService)) > and there are 4 attributes in the request - objectClass, cn, ipServicePort, > ipServiceProtocol > > Whereas on the CentOS 7 server, the filter looks like this: > Filter: > (&(objectClass=sudoRole)(|(|(|(|(|(|(|(|(|(!(sudoHost=*))(sudoHost=ALL))(sudoHost=ldaptest7.company.com))(sudoHost=ldaptest7))(sudoHost=192.168.193.62))(sudoHost=192.168.192.0/23))(sudoHost=fe80::5054:ff:fef2:26ed))(sudoHost=fe80::/6 > with 13 attributes - objectClass, cn, and a bunch of sudo attributes. > > The response from the Samba server to each of these is nearly identical. > Both servers then send searchRequests for Configuration, ForestDnsZones and > DomainDnsZones but with the same filter differences above. This is the point > of failure for the CentOS 7 server. The other server gets a successful > response from the Samba server, but the CentOS 7 server just gets an ACK. > When I up the debug level on SSSD on the CentOS 7 server, I see a few > different errors but I'm not sure which of these show cause or effect. > Examples... > > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] > [common_parse_search_base] (0x0100): Search base added: > [SUDO][dc=ad,dc=company,dc=com][SUBTREE][] > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] > [common_parse_search_base] (0x0100): Search base added: > [AUTOFS][dc=ad,dc=company,dc=com][SUBTREE][] > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] [dp_client_register] > (0x0100): Cancel DP ID timeout [0x55941e9a6860] > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] [dp_find_method] > (0x0100): Target [subdomains] is not initialized > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] > [dp_req_reply_gen_error] (0x0080): DP Request [Subdomains #0]: Finished. > Target is not supported with this configuration. > > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [set_server_common_status] (0x0100): Marking server '192.168.192.50' as > 'resolving name' > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [set_server_common_status] (0x0100): Marking server '192.168.192.50' as 'name > resolved' > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level > to [4] > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [sdap_cli_auth_step] > (0x0100): expire timeout is 900 > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [simple_bind_send] > (0x0100): Executing simple bind as: s...@ad.company.com > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [fo_set_port_status] > (0x0100): Marking port 389 of server '192.168.192.50' as 'working' > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [set_server_common_status] (0x0100): Marking server '192.168.192.50' as > 'working' > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [be_run_online_cb] > (0x0080): Going online. Running callbacks. > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [be_ptask_enable] > (0x0080): Task [SUDO Smart Refresh]: already enabled > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [sdap_process_result] > (0x0040): ldap_result error: [Can't contact LDAP server] hmm, I
[SSSD-users] Re: problem login in with AD account after joined to the AD domain
> On 22 Jul 2018, at 22:47, Farshid Mahdavipour wrote: > > Hi, > > I have configured sssd.service to authenticate to AD on RHEL 7.5 and i have > successfully joined the rhel machine to AD. > but i cannot login to the machine with the AD account. > > here is the error when i try to login with the AD credential: > mahdavif@172.17.248.71's password: > Last login: Sun Jul 22 18:59:23 2018 from 172.17.253.11 > This account is currently not available. I honestly don’t know without logs, see e.g. https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html > Connection to 172.17.248.71 closed. > > here is the sssd.conf: > # cat /etc/sssd/sssd.conf > ad_server = srv_addcp001, srv_addcp002 > [sssd] > domains = corp.example.com > config_file_version = 2 > services = nss, pam > [domain/corp.example.com] > ad_domain = corp.example.com > krb5_realm = CORP.example.com > krb5_auth_timeout = 60 > realmd_tags = manages-system joined-with-adcli > cache_credentials = True > id_provider = ad > krb5_store_password_if_offline = True > default_shell = /bin/bash > override_shell = /bin/bash > ldap_id_mapping = False > use_fully_qualified_names = False > fallback_homedir = /home/%u@%d > access_provider = ad > ad_server = srv_addcp001, srv_addcp002 > > here is the output of the realm list: > # realm list > corp.example.com > type: kerberos > realm-name: CORP.example.com > domain-name: corp.example.com > configured: kerberos-member > server-software: active-directory > client-software: sssd > required-package: oddjob > required-package: oddjob-mkhomedir > required-package: sssd > required-package: adcli > required-package: samba-common-tools > login-formats: %U > login-policy: allow-realm-logins > > This is the /var/log/secure when trying to login : > Jul 22 17:13:05 azrlvm003 sshd[7202]: pam_sss(sshd:auth): authentication > success; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.17.253.11 > user=mahdavif > Jul 22 17:13:05 azrlvm003 sshd[7202]: Accepted password for mahdavif from > 172.17.253.11 port 41628 ssh2 > Jul 22 17:13:06 azrlvm003 sshd[7202]: pam_unix(sshd:session): session opened > for user mahdavif by (uid=0) > Jul 22 17:13:06 azrlvm003 sshd[7209]: Received disconnect from 172.17.253.11 > port 41628:11: disconnected by user > Jul 22 17:13:06 azrlvm003 sshd[7209]: Disconnected from 172.17.253.11 port > 41628 > Jul 22 17:13:06 azrlvm003 sshd[7202]: pam_unix(sshd:session): session closed > for user mahdavif And here pam_sss is not even called, but the user seems to be found by pam_unix. This might indicate that the user is also present in the passwd/group files which is not recommended. > > sssd --version > 1.16.0 > > I really appreciate if you can help me. > Thanks > Farshid > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/DFHOAB3FDTP5YTUZAZPUUNHOUN3YNVCM/ ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/ISBQ3ZJWQOPEKQJNYPZDPFB5AAKDVUNN/
[SSSD-users] Re: Missing group memberships with sssd (when using tokengroups)
> On 22 Jul 2018, at 20:49, Spike White wrote: > > I can't replicate that "duplicate domains" situation any more. (I thought > I'd saved that sssd.conf file, but it doesn't exhibit the same behaviour). > > Here are the logs for a specific account failing to look up all groups with > ldap_use_tokengroups = True. > > Logs are at this URL: >https://www.dropbox.com/sh/l37pj104qkrqxfa/AACuKgaQjWZ4MVr1NdEogbcMa?dl=0 > > I have included the realmd.conf, sssd.conf and krb5.conf as well. > > Here's (incorrect) result back from sssd with ldap_use_tokengroups = True > > [root@spikerealmd02 sssd]# id admpatrick_wheeler > uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) > groups=2604370(admpatrick_wheeler),1010(amerunixusers) > Thank you, now the logs are more helpful. What I see is repetition of “cant find domain for $SID”. And I believe this is because the subdomains provider is disabled, because (quite confusingly) the subdomains provider is also responsible for fetching information about the joined domain, like its SID or the NetBIOS name. So I think there are three options: 1) add ad_enabled_domains=$self to each of the domains, e.g. add ad_enabled_domains=amer.dell.com to the amer.dell.com domain. This should make sssd fetch info about that domain only. I know you wrote earlier that this gave you some other headaches, but if it does, then there’s another bug.. 2) try to help sssd by setting the domain SID manually with the ldap_idmap_default_domain_sid option 3) just use tokengroups=false as a workaround. > Here is correct result back when ldap_use_tokengropus = False: > > [root@spikerealmd02 sssd]# id admpatrick_wheeler > uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) > groups=2604370(admpatrick_wheeler),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport),1010(amerunixusers),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),1033(amer_server_mgmt),1003(amerlinuxsup) > > this is sssd version 1.16.0 > > Spike > > > Thanks, this is more helpful > > On Thu, Jul 19, 2018 at 4:15 AM Jakub Hrozek wrote: > > > > On 13 Jul 2018, at 17:40, Spike White wrote: > > > > Jakub, > > > > Thank you to answering so promptly. > > > > We are currently testing this in a lab before full deployment, so I have > > some degree of time before we deploy sssd in a bigger context. If you > > would prefer for me to work with you directly off-line, please advise. As > > an example, the attached sssd_amer.dell.com.log file was originally 40 MB. > > (I presume because of debugging level). Out of respect for others on the > > mailing list, I severely trimmed the log file to only the lines of interest > > (I hope). But it's entirely possible I may have over-trimmed. > > > > I’m afraid so, because the logs say: > > (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] [sdap_parse_range] > (0x2000): No sub-attributes for [tokenGroups] > …. > > and I’m really interested in this part :-) > > (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] > [sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for > [admpatrick_whee...@amer.dell.com] > ... > (Fri Jul 13 09:25:48 2018) [sssd[be[amer.dell.com]]] > [sdap_asq_search_parse_entry] (0x2000): Matched objectclass [user] on DN > [CN=AdmPatrick_Wheeler,OU=AdmAccounts,DC=amer,DC=dell,DC=com], will use > associated map > > > > You asked: > > Can you send logs for a single lookup of "id username" with tokengroups > > enabled? > > > > Attached are the logs. sssd_amer.dell.com.log and sssd_nss.log, for this > > lookup: > > > >[root@spikerealmd02 sssd]# id admpatrick_wheeler > >uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) > > groups=2604370(admpatrick_wheeler),1010(amerunixusers) > > > > This is with ldap_use_tokengroups = True, so the above lookup is incorrect. > > > > What it should show is: > > id admpatrick_wheeler > > uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) > > groups=2604370(admpatrick_wheeler),1033(amer_server_mgmt),1003(amerlinuxsup),1010(amerunixusers) > > > > You asked: > >Why do you disable the subdomains provider? Isn't it easier to just list > >the domains you want to enable using the ad_enabled_domains option? > > > >btw this can actually cause issues because the subdomains provider is > >needed to fetch the joined domain SID at least, among other things. > > > > When I ran with: > > ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com, > > japn.dell.com, dell.com > > > > it broke cross-subdomain authentication. that is, I could resolve accounts > > from the local domain (AMER), but not from any other domain (like apac). > > When I reviewed the logs, I saw the sssd_nss.log would d
[SSSD-users] Re: 1.16.2 test failure: sss_nss_idmap-tests
Unfortunately these tests don’t have an option to raise the debug level so stepping throught them with gdb is the only option I’m afraid.. > On 20 Jul 2018, at 20:56, Andreas Hasenack wrote: > > What I figured out so far is that this is a test that is enabled if > you have cmocka installed, and this is the first time I had that. > On Fri, Jul 20, 2018 at 2:22 PM Andreas Hasenack > wrote: >> >> Hi, >> >> I'm building 1.16.2 with just >> https://pagure.io/SSSD/sssd/c/a2cc554f438c220b3cc73eb93879dd87795a86cd?branch=master >> applied (without it, it doesn't build in Ubuntu currently) and I'm >> seeing this test failure: >> >> [==] Running 2 test(s). >> [ RUN ] test_getsidbyname >> [ ERROR ] --- 0x2 != 0 >> [ LINE ] --- ../src/tests/cmocka/sss_nss_idmap-tests.c:121: error: >> Failure! >> [ FAILED ] test_getsidbyname >> [ RUN ] test_getorigbyname >> [ ERROR ] --- 0x2 != 0 >> [ LINE ] --- ../src/tests/cmocka/sss_nss_idmap-tests.c:140: error: >> Failure! >> [ FAILED ] test_getorigbyname >> [==] 2 test(s) run. >> [ PASSED ] 0 test(s). >> [ FAILED ] 2 test(s), listed below: >> [ FAILED ] test_getsidbyname >> [ FAILED ] test_getorigbyname >> >> 2 FAILED TEST(S) >> FAIL sss_nss_idmap-tests (exit status: 2) >> >> I tried with samba 4.7.6 and 4.8.2 installed, and also with >> --with-smb-idmap-interface-version 5 and 6, same result. Debian is at >> 1.16.2 and the tests pass there just fine, so I think I'm looking at >> some dependency problem. >> ldb is 1.3.1 >> tdb is 1.3.15 >> >> Any pointers? Maybe a way to run just that test, so I can add >> debugging statements? >> >> Thanks! > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/UB32RZUSGRALDIPPDUSJIT6CSTCSM3F6/ ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/J2ZV2J3CFB64BH7SGYR5TB432CIZVF3K/
