sssd-users May 2019

sssd-users@lists.fedorahosted.org

18 participants
21 discussions

Stupid question on ldap_user_email
by John Hearns 22 May '19

22 May '19

I have a test system which authenticates using sssd and an LDAP provider. So far so good! In my LDAP object there is the field 'mail' which is my correct email address. I know I can get this using an ldapsearch. However I am asking if there is any clean and small utility which will print this out? I am asking as obviously scripts sometimes want to send email. In sssd.conf there s the field ldap_user_email How would this be queried?

2 1

group memberships not updating
by Toby Blake 15 May '19

15 May '19

Hi, We have noticed an issue where group memberships are not being updated on a significant number of our machines. It appears that this has been reported in the following two bug reports: https://pagure.io/SSSD/sssd/issue/3869 https://pagure.io/SSSD/sssd/issue/3886 There hasn't been any activity on these for a few months now, so I thought I would add a me-too, and offer to do any debugging necessary. Thanks Toby Blake School of Informatics University of Edinburgh -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

2 2

authenticate linux using active directory without joined
by Antonio Pena Diaz 15 May '19

15 May '19

Hi, I need to connect by ssh using users centralized on AD, but linux servers client use nslcd to retrieve the users settings and mapping attributes.. I don't want to join linux servers into domain, and not use kerberos... exist the possibility to do this with my settings nslcd ? or how can I do same using sssd.conf to do it? using nscld, the only issue I have is, connecting by ssh .... reach authenticated but can't retrieve the shell and is mapped when get the entries from active directory using ldap protocol. I'm not registered into list so please answer directly to my email. any idea? Thanks in advance. https://pastebin.com/1XmqF6LJ [https://pastebin.com/i/facebook.png]<https://pastebin.com/1XmqF6LJ> [root@centos-manager ~]# cat /etc/nslcd.conf uid nslcd gid ldap uri ldap:// - Pastebin.com Altre info...<https://pastebin.com/1XmqF6LJ> [APK] Antonio Pena Diaz Sistemisti e Sistemi Informativi Interni Area Tecnica APKAPPA s.r.l. sede legale Via F. Albani, 21 20149 Milano | p.iva/vat no. IT-08543640158 sede amministrativa e operativa Reggio Emilia (RE) via M. K. Gandhi, 24/ A 42123 - sede operativa Magenta (MI) via Milano 89/91 20013 tel. 02 94454 000 | fax 02 94454 339 www.apkappa.it<http://www.apkappa.it> Seguici su: [Facebook]<https://www.facebook.com/apkappasrl> [LinkedIn] <https://www.linkedin.com/company/apkappa> Ai sensi e per gli effetti della Legge sulla tutela della riservatezza personale (D.Lgs. 196/03 e collegate), questa mail è destinata unicamente alle persone sopra indicate e le informazioni in essa contenute sono da considerarsi strettamente riservate. This email is confidential, do not use the contents for any purpose whatsoever nor disclose them to anyone else. If you are not the intended recipient, you should not copy, modify, distribute or take any action in reliance on it. If you have received this email in error, please notify the sender and delete this email from your system.

2 1

pam_sssd: reset Samba4/AD password
by Julien TEHERY 15 May '19

15 May '19

Hi there We have a samba4 AD (installed on ubuntu servers) and also ubuntu client workstations. Those ubuntu workstations authenticate themselves to samba4/AD server through pam_sssd. Users authentication against Samba4/AD works well, but i don't know how to allow users to change their own passwords through thios mecanism. I tried several methods like smbpasswd, samba-tool user setpassword, passwd or kpasswd but none of them works. Do some of you know how to proceed to make it work with samba4/AD authentication? The goal is simply to allow a workstation user to change his password whithout using a web interface. Here is the sssd setup of the workstations: /etc/sssd/sssd.conf: [sssd] config_file_version = 2 domains = mydomain.lan services = nss, pam default_domain_suffix = mydomain.lan [domain/mydomain.lan] id_provider = ad auth_provider = ad chpass_provider=ad access_provider = ad ldap_id_mapping = True default_shell = /bin/bash use_fully_qualified_names = False override_homedir = /users/home/%u fallback_homedir = /users/home/%u krb5_use_enterprise_principal=false krb5_validate = False krb5_store_password_if_offline = False ad_domain = mydomain.lan krb5_realm = MYDOMAIN.LAN realmd_tags = manages-system joined-with-samba Thanks

2 2

RHEL8 sssd-kcm can't accept credentials forwarded from sshd?
by James Ralston 15 May '19

15 May '19

Now that RHEL8 is out, our site is again looking at whether it would be feasible to change our default Kerberos credentials storage from the kernel persistent keyring to sssd-kcm. Unfortunately, the answer still seems to be no, as we haven't been able to find a way to get Kerberos ticket forwarding (GSSAPIDelegateCredentials, in OpenSSH parlance) working when using sssd-kcm as the credentials storage mechanism on the target host (the one the credentials are being delegated to). With the target host (the one the credentials are being delegated to) using "default_ccache_name = KEYRING:persistent:%{uid}" in krb5.conf, this is what sshd debugging shows: debug1: temporarily_use_uid: 123456789/987654321 (e=0/0) debug3: ssh_krb5_cc_new_unique: called debug3: ssh_krb5_get_cctemplate: called debug3: ssh_krb5_expand_template: called, template = KEYRING:persistent:%{uid} debug3: ssh_krb5_get_cctemplate: returning with ccname = KEYRING:persistent:123456789 debug3: ssh_krb5_cc_new_unique: setting default ccname to KEYRING:persistent:123456789 debug3: ssh_krb5_cc_new_unique: calling cc_new_unique(KEYRING:persistent:123456789) debug3: ssh_krb5_cc_new_unique: calling cc_switch() debug1: restore_uid: 0/0 In contrast, with "default_ccache_name = KCM:" in /etc/krb5.conf: debug1: temporarily_use_uid: 123456789/987654321 (e=0/0) debug3: ssh_krb5_cc_new_unique: called debug3: ssh_krb5_get_cctemplate: called debug3: ssh_krb5_expand_template: called, template = KCM: debug3: ssh_krb5_get_cctemplate: returning with ccname = KCM: debug3: ssh_krb5_cc_new_unique: setting default ccname to KCM: debug3: ssh_krb5_cc_new_unique: calling cc_new_unique(KCM:) debug3: ssh_krb5_cc_new_unique: calling cc_switch() ssh_krb5_cc_new_unique(): Matching credential not found debug1: restore_uid: 0/0 So, when sssd-kcm is in use, ssh_krb5_expand_template() fails, instead of returning what would be expect in this case, which (based on the kernel persistent keyring case) would be "KCM:123456789". sssd_kcm.log contains: (Fri May 10 12:33:34 2019) [sssd[kcm]] [get_client_cred] (0x4000): Client creds: euid[123456789] egid[987654321] pid[8661]. (Fri May 10 12:33:34 2019) [sssd[kcm]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x560fd598dc10][14] (Fri May 10 12:33:34 2019) [sssd[kcm]] [accept_fd_handler] (0x0400): Client connected! (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_input_parse] (0x1000): Received message with length 4 (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_get_opt] (0x2000): The client requested operation 3 (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_cmd_send] (0x0400): KCM operation GEN_NEW (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_cmd_send] (0x1000): 0 bytes on KCM input (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_queue_send] (0x0200): Adding request by 123456789 to the wait queue (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_queue_get] (0x1000): No existing queue for this ID (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_queue_send] (0x1000): Queue was empty, running the request immediately (Fri May 10 12:33:34 2019) [sssd[kcm]] [ccdb_secdb_nextid_send] (0x1000): Generating a new ID (Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_map_path] (0x1000): Mapping prefix /kcm/ (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_map_url_to_path] (0x1000): User-specific KCM path is [/kcm/persistent/123456789/ccache/] (Fri May 10 12:33:34 2019) [sssd[kcm]] [local_db_dn] (0x2000): Local path for [persistent/123456789/ccache/] is [cn=ccache,cn=123456789,cn=persistent,cn=kcm] (Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_new_req] (0x1000): Local DB path is persistent/123456789/ccache/ (Fri May 10 12:33:34 2019) [sssd[kcm]] [secdb_container_url_req] (0x2000): Created request for URL /kcm/persistent/123456789/ccache/ (Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_list] (0x0400): Listing keys at [persistent/123456789/ccache/] (Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_list] (0x2000): Searching for [(type=simple)] at [cn=ccache,cn=123456789,cn=persistent,cn=kcm] with scope=subtree (Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_list] (0x1000): No secrets found (Fri May 10 12:33:34 2019) [sssd[kcm]] [ccdb_secdb_nextid_send] (0x1000): Generated next ID 39355 (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_ccdb_nextid_done] (0x1000): generated 123456789:39355 (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_gen_new_done] (0x1000): Generated a new ID 123456789:39355 (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_cmd_done] (0x0400): KCM operation GEN_NEW returned [0]: Success (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_send_reply] (0x2000): Sending a reply (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_output_construct] (0x1000): Sending a reply with 20 bytes of payload (Fri May 10 12:33:34 2019) [sssd[kcm]] [queue_removal_cb] (0x0200): Removed queue for 123456789 (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_send] (0x2000): All data sent! (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_input_parse] (0x1000): Received message with length 20 (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_get_opt] (0x2000): The client requested operation 21 (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_cmd_send] (0x0400): KCM operation SET_DEFAULT_CACHE (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_cmd_send] (0x1000): 16 bytes on KCM input (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_queue_send] (0x0200): Adding request by 123456789 to the wait queue (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_queue_get] (0x1000): No existing queue for this ID (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_queue_send] (0x1000): Queue was empty, running the request immediately (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_set_default_ccache_send] (0x1000): Setting default ccache 123456789:39355 (Fri May 10 12:33:34 2019) [sssd[kcm]] [ccdb_secdb_uuid_by_name_send] (0x2000): Translating name to UUID (Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_map_path] (0x1000): Mapping prefix /kcm/ (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_map_url_to_path] (0x1000): User-specific KCM path is [/kcm/persistent/123456789/ccache/] (Fri May 10 12:33:34 2019) [sssd[kcm]] [local_db_dn] (0x2000): Local path for [persistent/123456789/ccache/] is [cn=ccache,cn=123456789,cn=persistent,cn=kcm] (Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_new_req] (0x1000): Local DB path is persistent/123456789/ccache/ (Fri May 10 12:33:34 2019) [sssd[kcm]] [secdb_container_url_req] (0x2000): Created request for URL /kcm/persistent/123456789/ccache/ (Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_list] (0x0400): Listing keys at [persistent/123456789/ccache/] (Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_list] (0x2000): Searching for [(type=simple)] at [cn=ccache,cn=123456789,cn=persistent,cn=kcm] with scope=subtree (Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_list] (0x1000): No secrets found (Fri May 10 12:33:34 2019) [sssd[kcm]] [key_by_name] (0x0080): The container was not found (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_ccdb_uuid_by_name_done] (0x0040): Failed to resolve cache by UUID [1432158218]: No credentials available (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_set_default_ccache_getbyname_done] (0x0040): Cannot get ccache by name [1432158218]: No credentials available (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_cmd_done] (0x0040): op receive function failed [1432158218]: No credentials available (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_cmd_request_done] (0x0040): KCM operation failed [1432158218]: No credentials available (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_reply_error] (0x0040): KCM operation returs failure [1432158218]: No credentials available (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_failbuf_construct] (0x1000): Sent reply with error -1765328243 (Fri May 10 12:33:34 2019) [sssd[kcm]] [queue_removal_cb] (0x0200): Removed queue for 123456789 (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_send] (0x2000): All data sent! (Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_recv] (0x4000): Client closed connection. (Fri May 10 12:33:34 2019) [sssd[kcm]] [client_close_fn] (0x2000): Terminated client [0x560fd598dc10][14] So, sssd-kcm definitely failed. This aligns with what sshd saw. If I pre-create the cache on the target server (e.g., by running kinit against a different principal) and repeat the experiment, sssd-kcm still fails, but the debug output is slightly different: (Fri May 10 12:56:27 2019) [sssd[kcm]] [get_client_cred] (0x4000): Client creds: euid[123456789] egid[987654321] pid[8844]. (Fri May 10 12:56:27 2019) [sssd[kcm]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x5589715428e0][14] (Fri May 10 12:56:27 2019) [sssd[kcm]] [accept_fd_handler] (0x0400): Client connected! (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_input_parse] (0x1000): Received message with length 4 (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_get_opt] (0x2000): The client requested operation 3 (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_cmd_send] (0x0400): KCM operation GEN_NEW (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_cmd_send] (0x1000): 0 bytes on KCM input (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_queue_send] (0x0200): Adding request by 123456789 to the wait queue (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_queue_get] (0x1000): No existing queue for this ID (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_queue_send] (0x1000): Queue was empty, running the request immediately (Fri May 10 12:56:27 2019) [sssd[kcm]] [ccdb_secdb_nextid_send] (0x1000): Generating a new ID (Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_map_path] (0x1000): Mapping prefix /kcm/ (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_map_url_to_path] (0x1000): User-specific KCM path is [/kcm/persistent/123456789/ccache/] (Fri May 10 12:56:27 2019) [sssd[kcm]] [local_db_dn] (0x2000): Local path for [persistent/123456789/ccache/] is [cn=ccache,cn=123456789,cn=persistent,cn=kcm] (Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_new_req] (0x1000): Local DB path is persistent/123456789/ccache/ (Fri May 10 12:56:27 2019) [sssd[kcm]] [secdb_container_url_req] (0x2000): Created request for URL /kcm/persistent/123456789/ccache/ (Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_list] (0x0400): Listing keys at [persistent/123456789/ccache/] (Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_list] (0x2000): Searching for [(type=simple)] at [cn=ccache,cn=123456789,cn=persistent,cn=kcm] with scope=subtree (Fri May 10 12:56:27 2019) [sssd[kcm]] [local_dn_to_path] (0x2000): Secrets path for [cn=2c095c7e-978f-498c-aa46-f1641ac45545-123456789,cn=ccache,cn=123456789,cn=persistent,cn=kcm] is [2c095c7e-978f-498c-aa46-f1641ac45545-123456789] (Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_list] (0x1000): Returning 1 secrets (Fri May 10 12:56:27 2019) [sssd[kcm]] [ccdb_secdb_nextid_send] (0x1000): Generated next ID 39355 (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_ccdb_nextid_done] (0x1000): generated 123456789:39355 (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_gen_new_done] (0x1000): Generated a new ID 123456789:39355 (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_cmd_done] (0x0400): KCM operation GEN_NEW returned [0]: Success (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_send_reply] (0x2000): Sending a reply (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_output_construct] (0x1000): Sending a reply with 20 bytes of payload (Fri May 10 12:56:27 2019) [sssd[kcm]] [queue_removal_cb] (0x0200): Removed queue for 123456789 (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_send] (0x2000): All data sent! (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_input_parse] (0x1000): Received message with length 20 (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_get_opt] (0x2000): The client requested operation 21 (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_cmd_send] (0x0400): KCM operation SET_DEFAULT_CACHE (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_cmd_send] (0x1000): 16 bytes on KCM input (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_queue_send] (0x0200): Adding request by 123456789 to the wait queue (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_queue_get] (0x1000): No existing queue for this ID (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_queue_send] (0x1000): Queue was empty, running the request immediately (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_set_default_ccache_send] (0x1000): Setting default ccache 123456789:39355 (Fri May 10 12:56:27 2019) [sssd[kcm]] [ccdb_secdb_uuid_by_name_send] (0x2000): Translating name to UUID (Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_map_path] (0x1000): Mapping prefix /kcm/ (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_map_url_to_path] (0x1000): User-specific KCM path is [/kcm/persistent/123456789/ccache/] (Fri May 10 12:56:27 2019) [sssd[kcm]] [local_db_dn] (0x2000): Local path for [persistent/123456789/ccache/] is [cn=ccache,cn=123456789,cn=persistent,cn=kcm] (Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_new_req] (0x1000): Local DB path is persistent/123456789/ccache/ (Fri May 10 12:56:27 2019) [sssd[kcm]] [secdb_container_url_req] (0x2000): Created request for URL /kcm/persistent/123456789/ccache/ (Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_list] (0x0400): Listing keys at [persistent/123456789/ccache/] (Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_list] (0x2000): Searching for [(type=simple)] at [cn=ccache,cn=123456789,cn=persistent,cn=kcm] with scope=subtree (Fri May 10 12:56:27 2019) [sssd[kcm]] [local_dn_to_path] (0x2000): Secrets path for [cn=2c095c7e-978f-498c-aa46-f1641ac45545-123456789,cn=ccache,cn=123456789,cn=persistent,cn=kcm] is [2c095c7e-978f-498c-aa46-f1641ac45545-123456789] (Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_list] (0x1000): Returning 1 secrets (Fri May 10 12:56:27 2019) [sssd[kcm]] [key_by_name] (0x2000): No key matched (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_ccdb_uuid_by_name_done] (0x0040): Failed to resolve cache by UUID [1432158218]: No credentials available (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_set_default_ccache_getbyname_done] (0x0040): Cannot get ccache by name [1432158218]: No credentials available (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_cmd_done] (0x0040): op receive function failed [1432158218]: No credentials available (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_cmd_request_done] (0x0040): KCM operation failed [1432158218]: No credentials available (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_reply_error] (0x0040): KCM operation returs failure [1432158218]: No credentials available (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_failbuf_construct] (0x1000): Sent reply with error -1765328243 (Fri May 10 12:56:27 2019) [sssd[kcm]] [queue_removal_cb] (0x0200): Removed queue for 123456789 (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_send] (0x2000): All data sent! (Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_recv] (0x4000): Client closed connection. (Fri May 10 12:56:27 2019) [sssd[kcm]] [client_close_fn] (0x2000): Terminated client [0x5589715428e0][14] Before I dig into this further, or go file a support request with Red Hat, has anyone been able to get sssd-kcm to successfully accept forwarded credentials from sshd on RHEL8? If so, what did you have to set or tweak to get it to work?

2 1

SSSD with SSH key auth + MFA with Radius server
by Nerigal 10 May '19

10 May '19

Hi, I could make sssd work fine with domain authentication with Radius server + Azure MFA through SSH gateway using password So the user enter his creds and then get to prompt on his phone to accept or reject the authentication Everything work as expected so far The problem comes with SSH keys ... i tried the alternate authentication in Active Directory adding users SSH keys in altSecurityIdentities user object attribute and configuring ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities ldap_user_ssh_public_key = altSecurityIdentities ldap_use_tokengroups = True in sssd.conf file and its actually working too well... The "too well" is that it looks like as soon as the user has a working ssh Key in Active Directory, SSSD ingore the configuration auth_provider = proxy proxy_pam_target = sssdproxyradiusauth Note * sshd_config is configured with AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys AuthorizedKeysCommandUser root So is there a way to make SSSD always pass by the Radius regardless of the auth mechanic ? May be the "proxy bypass" with SSH key come from /usr/bin/sss_ssh_authorizedkeys i can't tell at this point

2 6

sssd[be[1320]: Backend is offline
by Harald Dunkel 10 May '19

10 May '19

Hi folks, sssd 1.16.3-1 (rebuilt for Debian 9), systemd At boot time sssd_nss fails to initialize. systemctl status sssd shows root@srvl061:~# systemctl status sssd * sssd.service - System Security Services Daemon Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2018-11-22 11:57:30 CET; 46s ago Main PID: 1312 (sssd) Tasks: 5 (limit: 7372) CGroup: /system.slice/sssd.service |-1312 /usr/sbin/sssd -i --logger=files |-1345 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain example.com --uid 0 --gid 0 --logger=files |-1533 /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --uid 0 --gid 0 --logger=files |-1534 /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --uid 0 --gid 0 --logger=files `-1535 /usr/lib/x86_64-linux-gnu/sssd/sssd_pac --uid 0 --gid 0 --logger=files Nov 22 11:57:25 srvl061.ac.example.com systemd[1]: Starting System Security Services Daemon... Nov 22 11:57:25 srvl061.ac.example.com sssd[1312]: Starting up Nov 22 11:57:25 srvl061.ac.example.com sssd[be[1345]: Starting up Nov 22 11:57:30 srvl061.ac.example.com sssd[1533]: Starting up Nov 22 11:57:30 srvl061.ac.example.com sssd[1534]: Starting up Nov 22 11:57:30 srvl061.ac.example.com sssd[1535]: Starting up Nov 22 11:57:30 srvl061.ac.example.com systemd[1]: Started System Security Services Daemon. Nov 22 11:57:45 srvl061.ac.example.com sssd[be[1345]: Backend is offline Apparently this is a problem of resolvconf generating /etc/\ resolv.conf at boot time. If I replace it by a static file, then the problem is gone. Question is, how can I tell systemd to wait for resolv.conf? Is there some timeout in the backend I could adjust? Does it wait for the network at all? Every helpful comment is highly appreciated Regards Harri

5 7

Curiousity question about 'realm permit <user>'
by Spike White 08 May '19

08 May '19

All, I have sssd set up and doing cross-domain AD authentication. I'm using the simple access provider and conferring login access per group. Occasionally per user. I notice that if I do a basic 'realm permit <user>', that it adds this user to the wrong AD domain: Example: realm permit processehcprofiler adds it to my JAPN.COMPANY.COM AD domain, not my local AD domain (AMER). If I attempt to do to realm permit -R AMER.COMPANY.COM processehcprofiler(a)AMER.COMPANY.COM I get this error: realm: Couldn't find a matching realm Through various experimentation, I find that if I do this: realm permit -R amer.company.com processehcprofiler(a)amer.company.com that it works. As confirmed by 'sssctl user-checks processehcprofiler' I notice my "domain" entries in /etc/sssd/sssd.conf file are all lower case: domains = amer.company.com,apac.company.com,emea.company.com, japn.company.com ... [domain/amer.company.com] ad_domain = amer.company.com ... [domain/apac.company.com] ad_domain = apac.company.com ... [domain/emea.company.com] ad_domain = emea.company.com ... [domain/japn.company.com] ad_domain = japn.company.com ... I'm used to Kerberos where domain names are uc and account names are lc. So to do: realm permit -R AMER.COMPANY.COM processehcprofiler(a)AMER.COMPANY.COM I have to re-write all the domain names in my sssd.conf file to uc? Spike

2 4

Is it possible to use the full username+domain name when using proxy_pam_target ?
by David Fournier 06 May '19

06 May '19

I've been tasked with adding two-factor authentication to one of our servers that will be exposed to the net. Requirements include using an existing 2FA system which uses RADIUS for authentication, and that users from both the client domain (unicorn.local) and the management domain (rainbow.local) can log in. The RADIUS server is the same for both domains. I believed I could use sssd with auth_provider = proxy and then specify my RADIUS pam module in the proxy_pam_target, however after running tests it appears that sssd only provides the username part of the fully qualified username to proxy_pam_target (i.e. if the user is 'stranger(a)rainbow.local', only 'stranger' is passed to the modules specified in proxy_pam_target). Is there a way/switch/configuration option that I would have missed that would allow passing the full username to my pam target? Content of /etc/sssd/sssd.conf ------------------------------- [sssd] domains = unicorn.local,rainbow.local config_file_version = 2 services = nss, pam full_name_format = %1$s@%2$s [domain/unicorn.local] id_provider = ldap ldap_id_mapping = True ldap_schema = AD ldap_group_nesting_level = 8 ldap_uri = ldap://pradad1001.unicorn.local ldap_search_base = dc=unicorn,dc=local ldap_default_bind_dn = CN=linuxldap,CN=Users,DC=unicorn,DC=local ldap_default_authtok_type = password ldap_default_authtok = ************* default_shell = /bin/bash use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = simple simple_allow_groups = L_Unicorn_SSH_Admins auth_provider = proxy proxy_pam_target = sssdauthproxy [domain/rainbow.local] id_provider = ldap ldap_id_mapping = True ldap_schema = AD ldap_group_nesting_level = 8 ldap_uri = ldap://otherad2001.rainbow.local ldap_search_base = dc=rainbow,dc=local ldap_default_bind_dn = CN=linuxldap,CN=Users,DC=rainbow,DC=local ldap_default_authtok_type = password ldap_default_authtok = ************** default_shell = /bin/bash use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = simple simple_allow_groups = L_Rainbow_SSH_Admins auth_provider = proxy proxy_pam_target = sssdauthproxy End Content of /etc/sssd/sssd.conf ------------------------------- Content of sssdauthproxy ------------------------------------- auth required pam_warn.so auth required pam_radius_auth.so End Content of sssdauthproxy ------------------------------------- Note that I added pam_warn.so right before pam_sss.so, the output shows the difference in users: Apr 24 17:16:58 SAclt001 sshd[15553]: pam_warn(sshd:auth): function=[pam_sm_authenticate] service=[sshd] terminal=[ssh] user=[stranger(a)rainbow.local] ruser=[<unknown>] rhost=[bbb.bbb.bbb.bb] Apr 24 17:16:58 SAclt001 proxy_child: pam_warn(sssdauthproxy:auth): function=[pam_sm_authenticate] service=[sssdauthproxy] terminal=[ssh] user=[stranger] ruser=[] rhost=[bbb.bbb.bbb.bb] Thanks for reading that far!

2 2

Local group and AD user mapping
by soham chakraborty 06 May '19

06 May '19

Hi, I have a requirement where human users will be logging in with their AD accounts. However, there are some applications that create local user and group and at times, the AD users may need to work on the application, view/edit files owned by the application user/group, run programs etc. Therefore we need to create some sort of mapping between the AD users and the local group. After coming through this mailing list, I realized that the recommendation is to add the remote AD users into the local group by way of modifying /etc/group file. What I am wondering is that, is this the only way to solve the problem or is there any other way (presumably better way) to handle this? I am using Puppet already. Therefore I think I may use the augeas provider to edit /etc/group file to add the users. I also need to devise a way so that users can be deleted from /etc/group easily in an automated fashion. Has anyone got any tips under their sleeve that can be used to roll out this feature in a lot of servers? Thanks,

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users May 2019