sssd-users July 2018

sssd-users@lists.fedorahosted.org

23 participants
34 discussions

AD user account get Permission denied when trying to login
by Farshid Mahdavipour 25 Jul '18

25 Jul '18

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:35 2018) [sssd[be[corp.example.net]]] [dp_req_destructor] (0x0400): DP Request [PAM Authenticate #6]: Request removed. (Mon Jul 23 21:59:35 2018) [sssd[be[corp.example.net]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Mon Jul 23 21:59:35 2018) [sssd[be[corp.example.net]]] [dp_method_enabled] (0x0400): Target selinux is not configured ==> /var/log/sssd/sssd.log <== (Mon Jul 23 21:59:07 2018) [sssd] [sbus_conn_register_path] (0x0400): Registering object path /org/freedesktop/sssd/monitor with D-Bus connection (Mon Jul 23 21:59:07 2018) [sssd] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Properties with path /org/freedesktop/sssd/monitor (Mon Jul 23 21:59:07 2018) [sssd] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Introspectable with path /org/freedesktop/sssd/monitor (Mon Jul 23 21:59:07 2018) [sssd] [client_registration] (0x0100): Received ID registration: (pam,1) (Mon Jul 23 21:59:07 2018) [sssd] [mark_service_as_started] (0x0200): Marking pam as started. (Mon Jul 23 21:59:07 2018) [sssd] [client_registration] (0x0100): Received ID registration: (nss,1) (Mon Jul 23 21:59:07 2018) [sssd] [mark_service_as_started] (0x0200): Marking nss as started. (Mon Jul 23 21:59:07 2018) [sssd] [mark_service_as_started] (0x0400): All services have successfully started, creating pid file (Mon Jul 23 21:59:07 2018) [sssd] [notify_startup] (0x0400): Sending startup notification to systemd (Mon Jul 23 21:59:12 2018) [sssd] [services_startup_timeout] (0x0400): Handling timeout ==> /var/log/sssd/sssd_nss.log <== (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_prepare_domain_data] (0x0400): CR #1: Preparing input data for domain [corp.example.net] rules (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #1: Looking up mahdavif(a)corp.example.net (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #1: Checking negative cache for [mahdavif(a)corp.example.net] (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #1: [mahdavif(a)corp.example.net] is not present in negative cache (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #1: Looking up [mahdavif(a)corp.example.net] in cache (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #1: Returning [mahdavif(a)corp.example.net] from cache (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_search_ncache_filter] (0x0400): CR #1: This request type does not support filtering result by negative cache (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_create_and_add_result] (0x0400): CR #1: Found 23 entries in domain corp.example.net (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_done] (0x0400): CR #1: Finished: Success (Mon Jul 23 21:59:37 2018) [sssd[nss]] [client_recv] (0x0200): Client disconnected! ==> /var/log/sssd/sssd_pam.log <== (Mon Jul 23 21:59:34 2018) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Jul 23 21:59:34 2018) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Mon Jul 23 21:59:34 2018) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 35831 (Mon Jul 23 21:59:34 2018) [sssd[pam]] [pam_print_data] (0x0100): logon name: mahdavif (Mon Jul 23 21:59:34 2018) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Mon Jul 23 21:59:35 2018) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [6 (Permission denied)][corp.example.net] (Mon Jul 23 21:59:35 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [6]: Permission denied. (Mon Jul 23 21:59:35 2018) [sssd[pam]] [filter_responses] (0x0100): [pam_response_filter] not available, not fatal. (Mon Jul 23 21:59:35 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 33 (Mon Jul 23 21:59:37 2018) [sssd[pam]] [client_recv] (0x0200): Client disconnected! thanks for your help! farshid

2 1

Re: "groups: cannot find name for group ID #####"
by sssdusers.20.retinkab＠spamgourmet.com 25 Jul '18

25 Jul '18

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 <user>` causing the primary group to be cached. On Fri, Jul 20, 2018 at 5:55 PM, Joakim Tjernlund - Joakim.Tjernlund(a)infinera.com < sssdusers.retinkab.d133d58ee0.Joakim.Tjernlund#sssd-users(a)lists.fedorahosted.org> wrote: > Start with replacing compat with files in nsswitch.conf > >

3 2

SSSD on CentOS 7 failing to start when connecting to Samba 4.8.3 AD via LDAP
by Mark Johnson 24 Jul '18

24 Jul '18

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: sssd(a)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] sssd_be: io.c:224: ber_flush2: Assertion `( (sb)->sb_opts.lbo_valid == 0x3 )' failed. (Thu Jul 19 23:40:44 2018) [sssd] [svc_child_info] (0x0040): Child [1570] terminated with signal [6] I get the feeling that the issue is around sudo somehow, but I don't believe I have sudo enabled in my sssd. Here's my sssd.conf from the CentOS 7 server: [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = AD.COMPANY.COM [nss] filter_groups = root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,mail, uucp,man,games,gopher,video,dip,ftp,lock,audio,nobody, users,floppy,vcsa,utmp,utempter,rpc,cdrom,tape,dialout,rpcuser,nfsnobody, sshd,cgred,screen,saslauth,apache,mailnull,smmsp,mysql filter_users = root,bin,daemon,adm,lp,sync,shutdown,halt,mail,uucp, operator,games,gopher,ftp,nobody,vcsa,rpc,rpcuser,nfsnobody,sshd,saslauth, apache,mailnull,smmsp,mysql,apache reconnection_retries = 3 #entry_cache_timeout = 300 entry_cache_nowait_percentage = 75 [domain/AD.COMPANY.COM] enumerate = false cache_credentials = true id_provider = ldap #auth_provider = ldap ldap_schema = rfc2307bis ldap_user_principal = userPrincipalName ldap_user_fullname = displayName ldap_user_name = sAMAccountName ldap_user_object_class = user ldap_user_home_directory = unixHomeDirectory ldap_user_shell = loginShell ldap_group_object_class = group ldap_force_upper_case_realm = True ldap_uri = ldap://192.168.192.50 ldap_search_base = dc=ad,dc=company,dc=com ldap_id_use_start_tls = false ldap_tls_reqcert = never ldap_tls_cacert = /etc/sssd/ca.company.com.crt access_provider = ldap ldap_access_filter = memberOf=cn=ServerAdmins,ou= Groups,dc=ad,dc=company,dc=com ldap_default_authtok_type = password ldap_default_bind_dn = sssd(a)ad.company.com ldap_default_authtok = Password1 [pam] I tried adding the sudo roles schema to active directory to see if it would resolve the sssd not starting issue, but while I was able to successfully import the schema via ldifde and create the sudoers OU in the root, but when it came to adding the sudoRole object via ADSIEdit, I got an Operation Failed error - "An invalid directory pathname was passed". So, I'm not sure if adding this will resolve the issue or not. There was no sudoers entry in nsswitch.conf so I tried specifically adding the following line to explicitly omit sss in case it has become a default setting: sudoers: files But that made no difference. I've tried all of the above twice from scratch to be sure and I got the same results both times. I can successfully query the directory via the same ldapsearch command from both CentOS servers. I don't know if I'm completely barking up the wrong tree. I'm just going around in circles now and I can't think of anything new to try. Oh, and here's my smb.conf... # Global parameters [global] bind interfaces only = Yes dns forwarder = 192.168.192.1 interfaces = lo eth0 netbios name = TUG-SAMBA realm = AD.COMPANY.COM server role = active directory domain controller workgroup = COMPANY idmap_ldb:use rfc2307 = yes dsdb:schema update allowed = yes ldap server require strong auth = no [netlogon] path = /var/lib/samba/sysvol/ad.company.com/scripts read only = No [sysvol] path = /var/lib/samba/sysvol read only = No

3 3

problem login in with AD account after joined to the AD domain
by Farshid Mahdavipour 23 Jul '18

23 Jul '18

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(a)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. 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 sssd --version 1.16.0 I really appreciate if you can help me. Thanks Farshid

3 5

Am I blocked on sssd-users mailing list?
by Spike White 23 Jul '18

23 Jul '18

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. Spike

2 1

Re: \groups: cannot find name for group ID #####\
by jsl6uy js16uy 20 Jul '18

20 Jul '18

roger roger understood. no worries thanks! I will definitely try On Fri, Jul 20, 2018 at 6:19 PM, Joakim Tjernlund <Joakim.Tjernlund(a)infinera.com> wrote: > Yes, that compat. Compat can be a problem, you do not need it. I am on > vacation and only have my phone so no long emails, sorry. > > Skaffa Outlook för Android > > ________________________________ > From: jsl6uy js16uy <js16uy(a)gmail.com> > Sent: Friday, July 20, 2018 6:49:35 PM > To: End-user discussions about the System Security Services Daemon > Subject: [SSSD-users] Re: "groups: cannot find name for group ID #####" > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know the > content is safe. > > > Really? no attitude pure question. We see the same thing. These are AD > groups sssd is complaining about. We use 1.16.1 on Ubu and Centos and > see the same behavior > You're saying below should be files vs compat? > passwd: compat sss > group: compat sss > > Don't get me wrong, thanks for the interaction on this and thanks to > sssdusers asking the original posted question. It really annoys our > users > > > > > On Fri, Jul 20, 2018 at 4:55 PM, Joakim Tjernlund > <Joakim.Tjernlund(a)infinera.com> wrote: >> Start with replacing compat with files in nsswitch.conf >> >> >> >> ________________________________ >> From: sssdusers.20.retinkab(a)spamgourmet.com >> <sssdusers.20.retinkab(a)spamgourmet.com> >> Sent: Friday, July 20, 2018 21:47 >> To: sssd-users(a)lists.fedorahosted.org >> Subject: [SSSD-users] "groups: cannot find name for group ID #####" >> >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you recognize the sender and know >> the >> content is safe. >> >> 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 = 9999 >> 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(a)lists.fedorahosted.org >> To unsubscribe send an email to sssd-users-leave(a)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… >> > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)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… > > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)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… >

1 0

Re: "groups: cannot find name for group ID #####"
by jsl6uy js16uy 20 Jul '18

20 Jul '18

Really? no attitude pure question. We see the same thing. These are AD groups sssd is complaining about. We use 1.16.1 on Ubu and Centos and see the same behavior You're saying below should be files vs compat? passwd: compat sss group: compat sss Don't get me wrong, thanks for the interaction on this and thanks to sssdusers asking the original posted question. It really annoys our users On Fri, Jul 20, 2018 at 4:55 PM, Joakim Tjernlund <Joakim.Tjernlund(a)infinera.com> wrote: > Start with replacing compat with files in nsswitch.conf > > > > ________________________________ > From: sssdusers.20.retinkab(a)spamgourmet.com > <sssdusers.20.retinkab(a)spamgourmet.com> > Sent: Friday, July 20, 2018 21:47 > To: sssd-users(a)lists.fedorahosted.org > Subject: [SSSD-users] "groups: cannot find name for group ID #####" > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know the > content is safe. > > 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 = 9999 > 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(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)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… >

2 2

"groups: cannot find name for group ID #####"
by sssdusers.20.retinkab＠spamgourmet.com 20 Jul '18

20 Jul '18

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 = 9999 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

2 1

"groups: cannot find name for group ID #####"
by sss.retinkab＠spamgourmet.com 20 Jul '18

20 Jul '18

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 = 9999 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

1 0

sss_override and ssh keys
by John Hearns 19 Jul '18

19 Jul '18

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 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.

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users July 2018