[Freeipa-users] Re: Another Expired Certs Issue

2020-11-04 Thread Sean McLennan via FreeIPA-users

On 2020-11-03 2:30 p.m., Rob Crittenden via FreeIPA-users wrote:
> I'd suggest stopping certmonger and looking for the actual request file
> in /var/lib/certmonger/request (grep for id=).
>
> Make sure that the value in key_pin matches the value in
> /etc/pki/pki-tomcat/alias/pwdfile.txt

I observed something that feels relevant. I was following the
instructions here:
https://floblanc.wordpress.com/2016/12/19/troubleshooting-certmonger-issues-with-freeipa/

The log files don't show exactly what he says—I'm not sure if that's a
version issue or something else. Not really finding errors (see below)

I don't seem to have 'ipaCert' anywhere?

certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca'

fails with

certutil: Could not find cert: subsystemCert cert-pki-ca
: PR_FILE_NOT_FOUND_ERROR: File not found

as do all the others that are stuck in that location.

certutil -L -d /etc/pki/pki-tomcat/alias/

produces:

Certificate Nickname Trust
Attributes

SSL,S/MIME,JAR/XPI

auditSigningCert cert-pki-ca u,u,u

Even if they were expired, shouldn't the others show up in the list? And
of course, that date is rolled back so they shouldn't be expired...


More details and a summary of the state of things:

restarting certmonger and/or resubmitting certs does not cause
certmonger to throw any errors; pki-tomcatd has too messages when it
starts that don't stop it from starting:
usr/share/pki/scripts/config: line 41: break: only meaningful in a
`for', `while', or `until' loop
cat: /usr/share/tomcat/conf/catalina.policy: No such file or directory

Nothing shows up with respect to the renewals shows up in
/var/log/ipa/renew.log even when I modified the ca with
'dogtag-ipa-ca-renew-agent-submit -vv'
There are a couple of things:
ipalib.plugable    DEBUG    ipaserver.plugins.virtual is not a valid
plugin module
ipalib.plugable    DEBUG    ipaserver.plugins.sudo is not a valid plugin
module

If there are other errors elsewhere, I'm not sure where to look.

The passwords in /etc/pki/pki-tomcat/alias/pwdfile.txt (PIN1) and
/var/lib/ipa/passwds/ipa01.mydomain.com-443-RSA (PIN2) are /not/ the
same. A third (different) password is in
/etc/dirsrv/slapd-MYREALM-COM/pwdfile.txt (PIN3). Notes about key_pin
and key_pin_file are from the individual request files in
/var/lib/certmonger/requests/

These certs are now fine:
type=FILE,location='/var/lib/ipa/*ra-agent.pem*' (no PIN in request)
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='*auditSigningCert
cert-pki-ca*',token='NSS Certificate DB' (request uses PIN1)
type=NSSDB,location='/etc/dirsrv/*slapd-MYREALM-COM',nickname='Server-Cert'*,token='NSS
Certificate DB' (PIN3)
type=FILE,location='/var/lib/krb5kdc/*kdc.crt*'

These are broken:

Request ID '20181021083405':
    status: NEED_CSR_GEN_TOKEN
    stuck: yes
    key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
    certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB'
    key_pin:PIN1

Request ID '20181021083406':
    status: NEED_CSR_GEN_TOKEN
    stuck: yes
    key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB',pin set
    certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB'
    key_pin:PIN1

Request ID '20181021083407':
    status: NEED_CSR_GEN_TOKEN
    stuck: yes
    key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
    certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB'
    key_pin:PIN1

Request ID '20181021083408':
    status: NEED_CSR_GEN_TOKEN
    stuck: yes
    key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB',pin set
    certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB'
    key_pin:PIN1

Request ID '20181021083714':
    status: NEED_CSR_GEN_PIN
    stuck: yes
    key pair storage:
type=FILE,location='/var/lib/ipa/private/httpd.key',pinfile='/var/lib/ipa/passwds/ipa01.mydomain.com-443-RSA'
    certificate: type=FILE,location='/var/lib/ipa/certs/httpd.crt'
    key_pin:PIN2

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedora

[Freeipa-users] Kerberos behaviour when OTP is used

2020-11-04 Thread Radoslaw Kujawa via FreeIPA-users

Hi list.

I have 2FA enabled for many users in my organization, however some of 
these users work on their own private devices and manually run kinit to 
obtain the TGT.


I was wondering why does kinit ask to:
"Enter OTP Token Value: "

This message is slightly confusing. In fact, the user is supposed to 
enter password+OTP here.


I've attempted reading RFC 6560. If I understand correctly, OTP is not 
really supposed to be used as a 2nd factor with Kerberos?


Another minor trouble with BYOD setups is that the OTP user has to 
manually obtain anonymous ticket for FAST, before being able to run kinit.


Interestingly, FAST is not required for Smart Card PKINIT to work.

None of this is really a big problem, it's just troublesome to explain 
in one sentence "how does Kerberos authentication work in our organization".


Of course with Linux clients joined to the IPA domain, all of these 
details are abstracted by sssd and therefore a non-issue from the user's 
perspective.



Best regards,
Radoslaw
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org


[Freeipa-users] Re: Another Expired Certs Issue

2020-11-04 Thread Sean McLennan via FreeIPA-users

> Where did you get this? 4.6.9 was never in ubuntu, 18.04 shipped with
> a 4.7.0 pre-release version.. 

Oh. I have only ever installed from the repositories. The 4.6.9 came from:

ipa --version
VERSION: 4.6.90.pre1+git20180411, API_VERSION: 2.229

but as soon as you said that I checked apt show and all the freeipa
packages are:

4.7.0~pre1+git20180411-2ubuntu2

I'm sorry, it didn't occur to me that they would be different. :(  That
likely explains why the trace-back line-numbers were not working for Rob.

Sean
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org