sssd-users December 2018

sssd-users@lists.fedorahosted.org

12 participants
16 discussions

Failed gssapi-with-mic
by Sergei Gerasenko 10 Dec '18

10 Dec '18

Hi, I've run into a dead end debugging a case of passwordless authentication between two IPA'd hosts. Running `sshd -p 5000 -d` on the receiving host (let's call it HOST_B), I see this: ``` Postponed gssapi-with-mic for postgres from x.x.x.x port 57607 ssh2 [preauth] debug1: Received some client credentials debug1: ssh_gssapi_k5login_exists: Checking existence of file /home/USER/.k5login Failed gssapi-with-mic for postgres from x.x.x.x port 57607 ssh2 ``` The client then gets an interactive password prompt. Here are some facts and things I've tried: * If I put the user into `.k5login` on the receiving host and it works. * The receiving host is correctly enrolled into IPA. I can ssh from it to other hosts using GSSAPI. * I can issue `kvno host/HOST_B` on the connecting host and I get a service ticket. * It looks like all this happens before any pam stuff kicks in (?). So I'm ruling PAM issues out. * No errors in the logs of the KDCs. * The ticket from the connecting host is not expired. * The sssd version is 1.16.0. * Turning up the debugging in sssd with `debug_level = 7` for the domain section doesn't reveal anything obvious. What else could I check? Thanks for any ideas, SG

2 1

Re: Problem with resolving unqualified group names
by Jakub Hrozek 10 Dec '18

10 Dec '18

On Fri, Nov 23, 2018 at 10:16:26AM +0000, Ondrej Valousek wrote: > Hi List, > > > I have noticed that in my case both > > getent passwd <username>@<domain> and getent passwd <username> > > works, but > > getent group <groupname>@<domain> > > does not, only: > > getent group <groupname> > > works. > > > Is that expected behavior? No (but I don't know what else to add except worksforme..)

1 0

Mail problems with new submissions to sssd-users list?
by Spike White 09 Dec '18

09 Dec '18

Is there any problem with new email messages going to to this sssd-users mailing list? I sent an email 6 days ago and again re-submitted it 4 days ago, about sssd auth against AD working; sssd autofs against LDAP / rfc2307bis not working. to date, I have not seen it appear in this sssd-users mailbox yet. I'm flummoxed on the problem and need help from people more knowledgeable than me. The mail message wasn't in violation of any mailing list policies (wasn't excessively long, etc). The above subject line might be slightly long, but I don't think that'd be a problem. I realize these sssd-user mailing list maintainers are frequently out for 2-3 days, due to their job roles, but I've seen other email responses on this mailing list since then. Spike White

2 2

Access alternative yubikey slots
by Orion Poplawski 04 Dec '18

04 Dec '18

I configured a YubiKey on Windows using the YubiKey minidriver with the following certificates: - my "orion" certificate - went into slot 9a PIV Auth - A MacOS keychain cert per their docs - when into slot 9d Key Management - Another auth certificate for "orion-admin" - went into slot 82 I'm able to authenticate on Windows as either orion or orion-admin, but on Linux with sssd it does not see the orion-admin certificate. What needs to happen to support this? Thanks! -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

2 10

sssd AD authentication working; sssd autofs against LDAP / rfc2307bis not working?
by Spike White 03 Dec '18

03 Dec '18

Sssd experts, This is all on RHEL7. I have sssd properly authenticating against AD for my multi-domain forest. All good – even cross-domain auth (as long as I don’t use tokengroups.) Our company’s AD implementation is RFC2307bis schema-extended. Now – for complicated reasons – I’m told I need to get nis automaps and nis netgroups in AD and also working on the clients (via sssd) also. As a first testing step, I’ve stood up an openLDAP server on another RHEL7 server. And schema extended it with RFC 2307 bis. http://bubblesorted.raab.link/content/replace-nis-rfc2307-rfc2307bis-schema… I added an initial automap. When I query via ldapsearch, all looks good: [root@spikerealmd02 sssd]# ldapsearch -LLL -x -H ldap:// austgcore17.us.example.com -b 'ou=automount,ou=admin,dc=itzgeek,dc=local' -s sub -D 'cn=ldapadm,dc=itzgeek,dc=local' -w ldppassword 'objectClass=automountMap' dn: automountMapName=auto.master,ou=automount,ou=admin,dc=itzgeek,dc=local objectClass: top objectClass: automountMap automountMapName: auto.master dn: automountMapName=auto.home,ou=automount,ou=admin,dc=itzgeek,dc=local objectClass: top objectClass: automountMap automountMapName: auto.home [root@spikerealmd02 sssd]# ldapsearch -LLL -x -H ldap:// austgcore17.us.example.com -b 'ou=automount,ou=admin,dc=itzgeek,dc=local' -s sub -D 'cn=ldapadm,dc=itzgeek,dc=local' -w ldppassword 'objectClass=automount' dn: automountKey=/home2,automountMapName=auto.master,ou=automount,ou=admin,dc= itzgeek,dc=local objectClass: top objectClass: automount automountKey: /home2 automountInformation: ldap:automountMapName=auto.home,ou=automount,ou=admin,dc =itzgeek,dc=local --timeout=60 --ghost dn: automountKey=/,automountMapName=auto.home,ou=automount,ou=admin,dc=itzgeek ,dc=local objectClass: top objectClass: automount automountKey: / automountInformation: -fstype=nfs,rw,hard,intr,nodev,exec,nosuid,rsize=8192,ws ize=8192 austgcore17.us.example.com:/export/& [root@spikerealmd02 sssd]# Next, the sssd client configuration. In my good sssd client’s sssd.conf file, I added “autofs” to my services line and added an “autofs” section. That is, I have changed my /etc/sssd/sssd.conf file as so: [sssd] … services = nss,pam,autofs … [autofs] debug_level = 9 autofs_provider = ldap ldap_uri= ldap://austgcore17.us.example.com ldap_schema = rfc2307bis ldap_default_bind_dn = cn=ldapadm,dc=itzgeek,dc=local ldap_default_authtok = ldppassword ldap_autofs_search_base = ou=automount,ou=admin,dc=itzgeek,dc=local ldap_autofs_map_object_class = automountMap ldap_autofs_map_name = automountMapName ldap_autofs_entry_object_class = automount ldap_autofs_entry_key = automountKey ldap_autofs_entry_value = automountInformation [nss] debug_level = 9 I appended sss to automount line in /etc/nsswitch.conf file: automount: files sss Yet, when I try to restart autofs service it (eventually) times out: [root@spikerealmd02 sssd]# systemctl restart sssd [root@spikerealmd02 sssd]# systemctl restart autofs Job for autofs.service failed because a timeout was exceeded. See "systemctl status autofs.service" and "journalctl -xe" for details. Journalctl –xe reports this: Dec 03 11:14:09 spikerealmd02.us.example.com [sssd[ldap_child[9653]]][9653]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection. … Dec 03 11:14:15 spikerealmd02.us.example.com [sssd[ldap_child[9680]]][9680]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication faile Dec 03 11:14:22 spikerealmd02.us.example.com systemd[1]: autofs.service start operation timed out. Terminating. Dec 03 11:14:22 spikerealmd02.us.example.com systemd[1]: Failed to start Automounts filesystems on demand. -- Subject: Unit autofs.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit autofs.service has failed. -- -- The result is failed. Dec 03 11:14:22 spikerealmd02.us.example.com systemd[1]: Unit autofs.service entered failed state. Dec 03 11:14:22 spikerealmd02.us.example.com systemd[1]: autofs.service failed. Dec 03 11:14:22 spikerealmd02.us.example.com polkitd[897]: Unregistered Authentication Agent for unix-process:9073:241010 (system bus :1.132, object path /org/freedeskt /var/log/sssd/ssd_nss.log looks like this: (Mon Dec 3 11:11:13 2018) [sssd[autofs]] [sysdb_get_certmap] (0x0020): Failed to read certmap config, skipping. (Mon Dec 3 11:11:13 2018) [sssd[autofs]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55f7263a1fc0 (Mon Dec 3 11:11:13 2018) [sssd[autofs]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55f7263a2080 (Mon Dec 3 11:11:13 2018) [sssd[autofs]] [ldb] (0x4000): Running timer event 0x55f7263a1fc0 "ltdb_callback" (Mon Dec 3 11:11:13 2018) [sssd[autofs]] [ldb] (0x4000): Destroying timer event 0x55f7263a2080 "ltdb_timeout" (Mon Dec 3 11:11:13 2018) [sssd[autofs]] [ldb] (0x4000): Ending timer event 0x55f7263a1fc0 "ltdb_callback" (Mon Dec 3 11:11:13 2018) [sssd[autofs]] [sysdb_get_certmap] (0x0400): No certificate maps found. What is wrong? BTW, for now – I don’t care about a GSSAPI SASL LDAP binding; a simple binding is what I want. BTW, I have not modified the /etc/autofs.conf file. I considered this, but it seems that if I did – it’d be bypassing nss / sssd. Also, I’d have another SASL creds hanging out there that’d I’d have to periodically rotate on all clients, instead of relying on SSSD’s machine account that’s auto-rotated every 30 days. Spike White

1 0

Error with subsequent login using AD account
by Peter de Groot 03 Dec '18

03 Dec '18

Please help.. desperate.. Installed sssd (version 1.16.1) on ubuntu authing against AD. Problem .. and this appears to be only one user.. 1. Login with the user.. No trouble 2. log out and try to login again. 3. Before even asking for a password, it comes up with access denied. The only way I can fix this is to do a sssctl cache-remove. And then I can log in again. Rinse and repeat. It seems to be a dud entry in the cache ? After days of trawling the logs... the only thing that seem to leap out is this in the krb5 logs. That entry in the salt is e4182s01sv023. The machine is called e418201sv025 ??? Where is it getting the 23 from ? We do have a host with that name on the network.. but not this one... (Mon Dec 3 15:29:29 2018) [[sssd[krb5_child[11596]]]] [sss_child_krb5_trace_cb] (0x4000): [11596] 1543822169.407460: Selected etype info: etype aes256-cts, salt "ORANGE.SCHOOLS.INTERNALpeter.de.groot", params "" (Mon Dec 3 15:29:29 2018) [[sssd[krb5_child[11596]]]] [sss_child_krb5_trace_cb] (0x4000): [11596] 1543822169.407479: Selected etype info: etype aes256-cts, salt "ORANGE.SCHOOLS.INTERNALpeter.de.groot", params "" (Mon Dec 3 15:30:13 2018) [[sssd[krb5_child[11746]]]] [sss_child_krb5_trace_cb] (0x4000): [11746] 1543822213.745198: Selected etype info: etype aes256-cts, salt "ORANGE.SCHOOLS.INTERNALhoste4182s01sv023.orange.schools.internal", params "" (Mon Dec 3 15:30:13 2018) [[sssd[krb5_child[11746]]]] [sss_child_krb5_trace_cb] (0x4000): [11746] 1543822213.745213: Selected etype info: etype aes256-cts, salt "ORANGE.SCHOOLS.INTERNALhoste4182s01sv023.orange.schools.internal", params "" (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851028: Selected etype info: etype aes256-cts, salt "ORANGE.SCHOOLS.INTERNALhoste4182s01sv023.orange.schools.internal", params "" (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851043: Selected etype info: etype aes256-cts, salt "ORANGE.SCHOOLS.INTERNALhoste4182s01sv023.orange.schools.internal", params "" The bottom of the log file (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851023: Received error from KDC: -1765328359/Additional pre-authenticat ion required (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851026: Preauthenticating using KDC method data (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851027: Processing preauth types: 16, 15, 19, 2 (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851028: Selected etype info: etype aes256-cts, salt "ORANGE.SCHOOLS.INT ERNALhoste4182s01sv023.orange.schools.internal", params "" (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_krb5_responder] (0x4000): Got question [password]. (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851029: AS key obtained for encrypted timestamp: aes256-cts/BBF9 (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851031: Encrypted timestamp (for 1543822221.598566): plain 301AA011180F 32303138313230333037333032315AA1050203092226, encrypted 89607EC763BD323A282F20C7ED58C75EA84F1638692A5CBCBF13BCF6F079891B1E2D140825C5E518334D7B138560D6E8ACA09F77315D131B (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851032: Preauth module encrypted_timestamp (2) (real) returned: 0/Succe ss (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851033: Produced preauth for next request: 2 (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851034: Sending request (302 bytes) to ORANGE.SCHOOLS.INTERNAL (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851035: Sending initial UDP request to dgram 10.251.17.2:88 (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851036: Received answer (221 bytes) from dgram 10.251.17.2:88 (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851037: Response was from master KDC (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851038: Received error from KDC: -1765328360/Preauthentication failed (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851041: Preauthenticating using KDC method data (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851042: Processing preauth types: 19 (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_child_krb5_trace_cb] (0x4000): [11747] 1543822219.851043: Selected etype info: etype aes256-cts, salt "ORANGE.SCHOOLS.INT ERNALhoste4182s01sv023.orange.schools.internal", params "" (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [sss_krb5_get_init_creds_password] (0x0020): 1618: [-1765328360][Preauthentication failed] (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [get_and_save_tgt] (0x0020): 1695: [-1765328360][Preauthentication failed] (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [map_krb5_error] (0x0020): 1808: [-1765328360][Preauthentication failed] (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [k5c_send_data] (0x0200): Received error code 1432158221 (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [pack_response_packet] (0x2000): response packet size: [4] (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [k5c_send_data] (0x4000): Response sent. (Mon Dec 3 15:30:19 2018) [[sssd[krb5_child[11747]]]] [main] (0x0400): krb5_child completed successfully roo

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users December 2018