Failed gssapi-with-mic
by Sergei Gerasenko
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
5 years, 4 months
Re: Problem with resolving unqualified group names
by Jakub Hrozek
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..)
5 years, 4 months
Mail problems with new submissions to sssd-users list?
by Spike White
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
5 years, 4 months
Access alternative yubikey slots
by Orion Poplawski
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/
5 years, 4 months
sssd AD authentication working; sssd autofs against LDAP / rfc2307bis not working?
by Spike White
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-sche...
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
5 years, 4 months
Error with subsequent login using AD account
by Peter de Groot
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
5 years, 4 months
