4:23 a.m.
hi,
I can successfully login using a smartcard (fedora 29 client, centos 7
kdcs, latest patch level).
However, when I try to access a kerberized service, I need to kinit first,
because I don't have a ticket:
$ klist
klist: Credentials cache 'KCM:1006000001' not found
I already have krb5-pkinit in de client and if I kinit -n I get a
wellknown/anonymous ticket from the kdcs, but this is obviously not what I
had in mind :-)
Am I doing something wrong or is this to be expected?
--
regards,
Natxo
4:43 a.m.
hi,
I found this blog post:
https://floblanc.wordpress.com/2017/06/02/troubleshooting-authentication-...
$ ipa certmap-match user.pem
successfully matches my user in the realm.
If I run
$ kinit -X X509_user_identity='PKCS11:opensc-pkcs11.so'
user PIN:
Password for user(a)SUB.DOMAIN.TLD:
$ klist
Ticket cache: KCM:1006000001
Default principal: USER(a)SUB.DOMAIN.TLD
Valid starting Expires Service principal
15-11-18 11:34:24 16-11-18 11:34:06 krbtgt/SUB.DOMAIN.TLD(a)SUB.DOMAIN.TLD
I enter the pin code, but must enter the password as well. Then I get a
ticket. Is this normal behaviour? I would expect not to enter a password
and have my ticket, but I must admit I have no experience with pkinit so
maybe this is to be expected.
Thanks to Florence Blanc for the blog posts, by the way, very informative.
--
regards,
Natxo
7:36 a.m.
On Thu, Nov 15, 2018 at 11:43:22AM +0100, Natxo Asenjo via FreeIPA-users wrote:
hi,
I found this blog post:
https://floblanc.wordpress.com/2017/06/02/troubleshooting-authentication-...
$ ipa certmap-match user.pem
successfully matches my user in the realm.
If I run
$ kinit -X X509_user_identity='PKCS11:opensc-pkcs11.so'
user PIN:
Password for user(a)SUB.DOMAIN.TLD:
$ klist
Ticket cache: KCM:1006000001
Default principal: USER(a)SUB.DOMAIN.TLD
Valid starting Expires Service principal
15-11-18 11:34:24 16-11-18 11:34:06 krbtgt/SUB.DOMAIN.TLD(a)SUB.DOMAIN.TLD
I enter the pin code, but must enter the password as well. Then I get a
ticket. Is this normal behaviour? I would expect not to enter a password
and have my ticket, but I must admit I have no experience with pkinit so
maybe this is to be expected.
No, the PIN should be sufficient. If kinit asks for a password it means
that pkinit failed and that "normal" kinit with password is tried.
bye,
Sumit
Thanks to Florence Blanc for the blog posts, by the way, very informative.
--
regards,
Natxo
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-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.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
4:49 a.m.
On to, 15 marras 2018, Natxo Asenjo via FreeIPA-users wrote:
hi,
I can successfully login using a smartcard (fedora 29 client, centos 7
kdcs, latest patch level).
However, when I try to access a kerberized service, I need to kinit first,
because I don't have a ticket:
$ klist
klist: Credentials cache 'KCM:1006000001' not found
I already have krb5-pkinit in de client and if I kinit -n I get a
wellknown/anonymous ticket from the kdcs, but this is obviously not what I
had in mind :-)
Am I doing something wrong or is this to be expected?
Enable debug_level=9 in sssd
configuration (domain section) and try to
login with smartcard, then provide krb5_child.log to see what's
happening.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
5:10 a.m.
On Thu, Nov 15, 2018 at 12:49:26PM +0200, Alexander Bokovoy via FreeIPA-users wrote:
On to, 15 marras 2018, Natxo Asenjo via FreeIPA-users wrote:
> hi,
>
> I can successfully login using a smartcard (fedora 29 client, centos 7
> kdcs, latest patch level).
>
> However, when I try to access a kerberized service, I need to kinit first,
> because I don't have a ticket:
>
> $ klist
> klist: Credentials cache 'KCM:1006000001' not found
>
> I already have krb5-pkinit in de client and if I kinit -n I get a
> wellknown/anonymous ticket from the kdcs, but this is obviously not what I
> had in mind :-)
>
> Am I doing something wrong or is this to be expected?
Enable debug_level=9 in sssd configuration (domain section) and try to
login with smartcard, then provide krb5_child.log to see what's
happening.
Additionally, how did you try to log in? If you are using ssh with
Smartcard support it is expected that there is no Kerberos ticket.
'kinit -n' is for anonymous processing. If you want to use the Smartcard
with manual kinit you you to call something like:
kinit -X 'X509_user_identity=PKCS11:module_name=opensc-pkcs11.so'
user(a)KRB5.REALM
more options might be needed to if there are multiple certificates on
you Smartcard.
Did you call the ipa-advise helper script for Smartcard authentication
on IPA clients?
bye,
Sumit
>
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-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.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
6:23 a.m.
On Thu, Nov 15, 2018 at 11:49 AM Alexander Bokovoy <abokovoy(a)redhat.com>
wrote:
>Am I doing something wrong or is this to be expected?
Enable debug_level=9 in sssd configuration (domain section) and try to
login with smartcard, then provide krb5_child.log to see what's
happening.
ok, here comes (anonymized) as attachment.
What's curious is that when running sudo -i and entering the pin code, root
does get a ticket for my user account (no password prompt).
@Sumit Bose <sbose(a)redhat.com> , I am logging in locally (console or gdm)
to a fedora 29 client. I tried using the advise scripts, but there are
several changes to the way smart cards work in fedora 29 compared to
rhel/centos 7, so the scripts do not work properly. I solved those problems
in an earlier thread.
--
regards,
Natxo
6:43 a.m.
On Thu, Nov 15, 2018 at 01:23:37PM +0100, Natxo Asenjo wrote:
On Thu, Nov 15, 2018 at 11:49 AM Alexander Bokovoy
<abokovoy(a)redhat.com>
wrote:
>
> >Am I doing something wrong or is this to be expected?
> Enable debug_level=9 in sssd configuration (domain section) and try to
> login with smartcard, then provide krb5_child.log to see what's
> happening.
>
ok, here comes (anonymized) as attachment.
What's curious is that when running sudo -i and entering the pin code, root
does get a ticket for my user account (no password prompt).
@Sumit Bose <sbose(a)redhat.com> , I am logging in locally (console or gdm)
to a fedora 29 client. I tried using the advise scripts, but there are
several changes to the way smart cards work in fedora 29 compared to
rhel/centos 7, so the scripts do not work properly. I solved those problems
in an earlier thread.
The pkinit plugin cannot find a valid certificate 'PKINIT client has no
configured identity; giving up'.
One reason (and that's why I ask for the advise script) are missing CA
certificates. Do you have something like
pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
in the section from the SUB.DOMAIN.TLD realm or in the [libdefaults]
section? Those files should contain the IPA CA certificates so that the
KDC certificate can be validated and the CA certificates of the issuer
of the certificate from the Smartcard.
Additionally please check if there are SELinux AVCs which might indicate
that krb5_child is not allowed to read the files with the CA
certificates.
If the CA certificates are available calling
KRB5_TRACE=/dev/stdout kinit -X
'X509_user_identity=PKCS11:module_name=/usr/lib64/pkcs11/opensc-pkcs11.so:token=userxx:certid=01
userxx(a)SUB.DOMAIN.TLD
should correspond to what SSSD is trying to do. If you run this with
strace it might give some hints if there are other issues.
If strace does not help, I can prepare a special debug version of the
pkinit plugin which adds lots of additional debug output. For this
please let me know the package version of krb5-pkinit you are using.
bye,
Sumit
--
regards,
Natxo
8:14 a.m.
On Thu, Nov 15, 2018 at 1:43 PM Sumit Bose <sbose(a)redhat.com> wrote:
The pkinit plugin cannot find a valid certificate 'PKINIT client has no
configured identity; giving up'.
One reason (and that's why I ask for the advise script) are missing CA
certificates. Do you have something like
pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
yes, in the krb5.conf file I see:
[realms]
SUB.DOMAIN.TLD = {
pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
}
and the files look ok.
in the section from the SUB.DOMAIN.TLD realm or in the [libdefaults]
section? Those files should contain the IPA CA certificates so that
the
KDC certificate can be validated and the CA certificates of the issuer
of the certificate from the Smartcard.
Additionally please check if there are SELinux AVCs which might indicate
that krb5_child is not allowed to read the files with the CA
certificates.
If the CA certificates are available calling
KRB5_TRACE=/dev/stdout kinit -X
'X509_user_identity=PKCS11:module_name=/usr/lib64/pkcs11/opensc-pkcs11.so:token=userxx:certid=01
userxx(a)SUB.DOMAIN.TLD
I should have thought of this myself. A little modification showed one
problem (running your command would not prompt for the pin in the card):
$ KRB5_TRACE=/dev/stdout kinit -X
X509_user_identity='PKCS11:opensc-pkcs11.so'
[7385] 1542287227.941537: Getting initial credentials for
user(a)SUB.DOMAIN.TLD
[7385] 1542287227.941539: Sending unauthenticated request
[7385] 1542287227.941540: Sending request (184 bytes) to SUB.DOMAIN.TLD
[7385] 1542287227.941541: Initiating TCP connection to stream kdc1:88
[7385] 1542287227.941542: Sending TCP request to stream kdc1:88
[7385] 1542287227.941543: Received answer (300 bytes) from stream kdc1:88
[7385] 1542287227.941544: Terminating TCP connection to stream kdc1:88
[7385] 1542287227.941545: Response was from master KDC
[7385] 1542287227.941546: Received error from KDC: -1765328359/Additional
pre-authentication required
[7385] 1542287227.941549: Preauthenticating using KDC method data
[7385] 1542287227.941550: Processing preauth types: PA-PK-AS-REQ (16),
PA-PK-AS-REP_OLD (15), PA-PK-AS-REQ_OLD (14), PA-FX-FAST (136),
PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147), PA-ENC-TIMESTAMP (2), PA-FX-COOKIE
(133)
[7385] 1542287227.941551: Selected etype info: etype aes256-cts, salt
")9z]I\1%cH8C@<}B", params ""
[7385] 1542287227.941552: Received cookie: MIT
[7385] 1542287228.624131: Preauth module pkinit (147) (info) returned:
0/Success
user PIN:
[7385] 1542287231.885613: PKINIT error: There are 2 certs, but there must
be exactly one.
[7385] 1542287231.885614: PKINIT client has no configured identity; giving
up
I am testing with a yubikey wich has several slots, and apparently this is
a problem with pkinit. Which is a pity, because the other certificate has a
completely different cn subject and domain, so why it tries to use it is
unclear.
So I removed the other certificate and now I can successfully kinit without
the password prompt, but after kdestroy, rebooting and logging in again, I
still don't have a ticket.
Nearly there.
This is the sssd.conf (maybe the error is in here):
[domain/sub.domain.tld]
id_provider = ipa
ipa_server = _srv_, kdc1.sub.domain.tld
ipa_domain = sub.domain.tld
ipa_hostname = myhost.sub.domain.tld
auth_provider = ipa
chpass_provider = ipa
access_provider = ipa
cache_credentials = True
ldap_tls_cacert = /etc/ipa/ca.crt
dyndns_update = True
dyndns_iface = eno1
krb5_store_password_if_offline = True
debug_level = 9
[sssd]
services = nss, pam, ssh, sudo
domains = sub.domain.tld
[pam]
pam_cert_auth = True
[ssh]
[sudo]
And I see these selinux denies:
# ausearch -m AVC -ts recent
time->Thu Nov 15 14:55:43 2018
type=AVC msg=audit(1542290143.544:224): avc: denied { execute } for
pid=2035 comm="p11_child"
path=2F746D702F6666694176784B6538202864656C6574656429 dev="tmpfs" ino=36791
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=1
----
time->Thu Nov 15 14:56:10 2018
type=AVC msg=audit(1542290170.644:243): avc: denied { execute } for
pid=2960 comm="p11_child"
path=2F746D702F6666696B77705A636C202864656C6574656429 dev="tmpfs" ino=47916
scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=1
But even with selinux in enforcing mode, I can sucessfully get a ticket:
$ kdestroy
$ klist
klist: Credentials cache 'KCM:1006000001' not found
$ kinit -X 'X509_user_identity='PKCS11:opensc-pkcs11.so'
user PIN:
]$ klist
Ticket cache: KCM:1006000001
Default principal: user(a)SUB.DOMAIN.TLD
Valid starting Expires Service principal
15-11-18 15:08:16 16-11-18 15:08:10 krbtgt/SUB.DOMAIN.TLD(a)SUB.DOMAIN.TLD
When I sudo, and authenticate with a pin, I get a ticket for root in the
context of my realm user. That works.
Any ideas?
--
Regards,
Natxo
9:17 a.m.
hi,
for posterity's sake, this appears to be a problem with kcm (whatever that
is, don't know yet, will look it up later).
I turned it off in /etc/krb5.conf.d/kcm_default_ccache (just comment the
two not comment lines) and after restart sssd or rebooting, with selinux
enabled, it works.
the ticket cache falls back to a keyring one and after logging in with just
a pin code and the certificate in the card, I have a token.
I have learnt a lot about how this works ;-), thanks Sumit, Alexander and,
indirectly through her blogpost, Florence.
Would it be possible to allow two or more certificates in the smart-card?
We plan on using yubikeys, and that is just one of its strengths: several
slots to keep different keys.
--
Groeten,
natxo
11:06 a.m.
On Thu, Nov 15, 2018 at 04:17:20PM +0100, Natxo Asenjo via FreeIPA-users wrote:
hi,
for posterity's sake, this appears to be a problem with kcm (whatever that
is, don't know yet, will look it up later).
I turned it off in /etc/krb5.conf.d/kcm_default_ccache (just comment the
two not comment lines) and after restart sssd or rebooting, with selinux
enabled, it works.
ah, sorry, I should have thought of this earlier. This is most probably
https://pagure.io/SSSD/sssd/issue/3376.
SSSD'd krb5_child runs as root with the IPA provider, e.g. to be
able to read the keytab for the Kerberos ticket validation. Due to the
issue from above it cannot save the TGT for the user.
bye,
Sumit
the ticket cache falls back to a keyring one and after logging in with just
a pin code and the certificate in the card, I have a token.
I have learnt a lot about how this works ;-), thanks Sumit, Alexander and,
indirectly through her blogpost, Florence.
Would it be possible to allow two or more certificates in the smart-card?
We plan on using yubikeys, and that is just one of its strengths: several
slots to keep different keys.
--
Groeten,
natxo
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-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.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
3:14 p.m.
On Thu, Nov 15, 2018 at 06:06:01PM +0100, Sumit Bose via FreeIPA-users wrote:
On Thu, Nov 15, 2018 at 04:17:20PM +0100, Natxo Asenjo via
FreeIPA-users wrote:
> hi,
>
> for posterity's sake, this appears to be a problem with kcm (whatever that
> is, don't know yet, will look it up later).
>
> I turned it off in /etc/krb5.conf.d/kcm_default_ccache (just comment the
> two not comment lines) and after restart sssd or rebooting, with selinux
> enabled, it works.
ah, sorry, I should have thought of this earlier. This is most probably
https://pagure.io/SSSD/sssd/issue/3376.
Thank you for digging into this.
While the root access itself is easy to fix, there would be another
problem. MIT, unlike Heimdal doesn't allow you to refer to a collection
with KCM:%{uid}. You can either use KCM: and then libkrb5 should do the
right thing and either create a new subsidiary cache for this principal
or switch to an existing one. Alternatively you can point to a residual
cache with KCM:%{uid}:xyz
I thought this was a bug in MIT, but upstream disagreed.
SSSD'd krb5_child runs as root with the IPA provider, e.g. to be
able to read the keytab for the Kerberos ticket validation. Due to the
issue from above it cannot save the TGT for the user.
looking at the code it's not running as root in general, but only in the
SC case:
3323 /* pkinit needs access to pcscd */
3324 if ((sss_authtok_get_type(kr->pd->authtok) != SSS_AUTHTOK_TYPE_SC_PIN
3325 && sss_authtok_get_type(kr->pd->authtok)
3326 != SSS_AUTHTOK_TYPE_SC_KEYPAD)) {
3327 kerr = k5c_become_user(kr->uid, kr->gid, kr->posix_domain);
3328 if (kerr != 0) {
3329 DEBUG(SSSDBG_CRIT_FAILURE, "become_user failed.\n");
3330 ret = EFAULT;
3331 goto done;
3332 }
3333 }
I hope we would have heard someone complaining quite sooner if no IPA
logins were possible with KCM :)
1989
days inactive
1989
days old
freeipa-users@lists.fedorahosted.org
10 comments
4 participants
participants (4)
-
Alexander Bokovoy -
Jakub Hrozek -
Natxo Asenjo -
Sumit Bose