[Freeipa-users] Re: SSH Key auth with expired Kerberos password

2018-11-07 Thread Tony Brian Albers via FreeIPA-users 
Morning,

We've had this issue and we found out that it is caused by the fact
that sshd when using key-based auth bypasses PAM authentication which
means that the kerberos server is never contacted.

So, don't use passwordless ssh.

Others might have more info on this, but the above solution(!) is
simple, stable and effective.

/tony

On Wed, 2018-11-07 at 21:53 +, Nathan Harper via FreeIPA-users
wrote:
> 
> Hi all,
> 
> We have noticed some behaviour that we are trying to work out if it
> is expected or not (or if this is an SSSD thing).   We have a pair of
> FreeIPA replicas running on CentOS 7 (v4.5.x), with various CentOS 7
> clients.   Most clients aren't actually enrolled in FreeIPA, but are
> configured with:
> 
> id_provider = ldap
> auth_provider = krb5
> 
> Authentication works as expected, plus password changes etc. 
>  However, if a user has added a public key to authorized_keys, the
> status of the password is not considered and at no point is a user
> prompted to change their password.   More importantly, if a user is
> disabled in FreeIPA, they are still permitted to login using their
> SSH key.
> 
> I have checked the behaviour on a client that is enrolled, and it is
> better (disabling a user does prevent access), but it still does not
> give any indication about failed passwords.
> 
> Under most circumstances this wouldn't be too much of an issue, but
> we make use of one application for remote access that does not know
> what to do with an expired password, and instead just presents
> 'authentication failed'.
> 
> Any suggestions?
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave@lists.fedorahoste
> d.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelin
> es
> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-u
> s...@lists.fedorahosted.org
-- 
Tony Albers
Systems Architect
Systems Director, National Cultural Heritage Cluster
Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
Tel: +45 2566 2383 / +45 8946 2316
___
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://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.fedorahosted.org

[Freeipa-users] Re: Fails to start CA with Basic Auth (and/or SSL)

2018-11-07 Thread Zarko D via FreeIPA-users 
Thank you Fraser for the support. 
'REALM.COM IPA CA' or caSigningCert is valid for 20 years, should be no problem 
here. 
But I am afraid I can't find common date for remaining four certs. As per 
bellow data:

[1] There is common date for auditSigningCert, subsystemCert and Server-Cert
[2] There is common date for Server-Cert and ocspSigningCert
[3] ocspSigningCert CANNOT have common date with auditSigningCert and 
subsystemCert

# certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'auditSigningCert cert-pki-ca'
Not Before: Wed Aug 24 20:49:38 2016
Not After : Tue Aug 14 20:49:38 2018

# certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'caSigningCert cert-pki-ca'
Not Before: Wed Aug 24 20:49:35 2016
Not After : Sun Aug 24 20:49:35 2036

# certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca'
Not Before: Wed Aug 24 20:49:36 2016
Not After : Tue Aug 14 20:49:36 2018

# certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'Server-Cert cert-pki-ca'
Not Before: Sat Nov 12 16:21:33 2016
Not After : Fri Nov 02 15:21:33 2018

# certutil -L -d /etc/pki/pki-tomcat/alias/ -n 'ocspSigningCert cert-pki-ca'
Not Before: Mon Oct 22 20:15:53 2018
Not After : Sun Oct 11 20:15:53 2020

# certutil -L -d /etc/dirsrv/slapd-REALM-COM -n 'REALM.COM IPA CA'
Not Before: Wed Aug 24 20:49:35 2016
Not After : Sun Aug 24 20:49:35 2036


What would you suggest now ? 
___
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://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.fedorahosted.org

[Freeipa-users] Re: Issues installing replica

2018-11-07 Thread Fraser Tweedale via FreeIPA-users 
Hi Alex,

(Cc some other engineers for Dogtag cloning troubleshooting
exposure).

Thanks for the additional logs.  Can we please see [temporally
relevant snippets of] any other log files under
/var/log/pki/pki-tomcat and /var/log/pki/pki-tomcat/ca , as well as
the journal (`journalctl -u pki-tomcatd@pki-tomcat`)?

The original server is returning status 500 upon /updateNumberRange
request from the new replica, but the cause is unknown.  There is
likely to be a stack trace hiding in the journal or one of the other
log files that was not included in the data you provided.

(Which is fair enough; we didn't ask for this extra stuff until
now.)

One more question: is this a replica created from a replica?
I fixed an issue quite recently that can occur under such a
scenario, the symptoms of which are similar to yours.

Thanks,
Fraser

On Wed, Nov 07, 2018 at 08:44:05PM +0100, Alex Corcoles via FreeIPA-users wrote:
> OK, did the whole song and dance again (btw, it takes about 6m, I'm not
> sure if that's normal), and extracted logs again:
> 
> https://gist.github.com/alexpdp7/358626a92a07c787fbf246b2761dddb3
> 
> Thanks for your time, guys,
> 
> Álex
> 
> On Tue, Nov 6, 2018 at 5:17 PM Rob Crittenden  wrote:
> 
> > Alex Corcoles via FreeIPA-users wrote:
> > > So I solved my LXC problems (thanks Rob, again), but now:
> > >
> > > ipa-replica-install -U --setup-ca -N
> > >
> > > fails when rebuilding my replica from scratch, see:
> > >
> > > https://gist.github.com/alexpdp7/4431da5e11afe6029e2baa01bc1f2251
> > >
> > > , where I think I've copied the relevant logs. I think I saw someone
> > > recommending revoking the replica certs, which makes sense as I'm using
> > > the same hostname that I used on the previous replica, but that doesn't
> > > seem to fix things.
> > >
> > > (I'm removing the previous replica via the admin interface, IPA Server
> > > -> Topology -> IPA Servers, select my replica and "Delete Server". This
> > > removes it too from the host list).
> >
> > I don't know what it is but it isn't related to existing entries in IPA
> > (nor un-revoked certs).
> >
> > The dogtag installer is asking for a serial # range and getting a
> > NotFound. Maybe Fraser knows.
> >
> > rob
> >
> 
> 
> -- 
>___
>  {~._.~}
>   ( Y )
>  ()~*~()  mail: alex at corcoles dot net
>  (_)-(_)  http://alex.corcoles.net/

> ___
> 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://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.fedorahosted.org
___
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://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.fedorahosted.org

[Freeipa-users] Re: Testing requested - certificate checking tool

2018-11-07 Thread Fraser Tweedale via FreeIPA-users 
On Wed, Nov 07, 2018 at 01:04:05PM -0500, Rob Crittenden via FreeIPA-users 
wrote:
> William Muriithi via FreeIPA-users wrote:
> > Morning Rob
> >>> What's the process for either removing or making it known?
> >>
> >> I'll add something to the program about this too but for now you can run:
> >>
> >> # getcert list -i 20170919231606
> >>
> >> That will tell us what it is. It is perfectly fine to have certmonger
> >> track other certs on the system. I display unexpected once as a
> >> just-in-case.
> >>
> >> It's supposed to display as just a warning. I'll fix that too since it
> >> is a little alarming.
> > This is the result I got on my end.:
> > 
> > Failures:
> > 
> > Unable to find request for serial 268304424
> > Unable to find request for serial 268304426
> > Unable to find request for serial 268304425
> > Unable to find request for serial 268304423
> 
> I'm not sure if this is an invalid test or a real error. I'm still
> waiting on the dogtag team to respond to
> https://bugzilla.redhat.com/show_bug.cgi?id=1641804 (your results are
> slightly different but of the same theme).
> 
Request IDs are not related to serial numbers of issued
certificates.  They just happen to coincide at the beginning.  I
responded to the BZ with more details.

> > Subject O=ENG.EXAMPLE.COM,CN=zinc.eng.example.com and template subject
> > CN=lithium.eng.example.com,O=ENG.EXAMPLE.COM do not match for serial
> > 77
> 
> Same as above.
> 
> I don't know yet if this is a harbinger of doom or a red herring :-/
> 
Probably an incorrect assumption.  Most likely not a harbinger of
doom.  Rob can you please follow up with details on how this check
is conducted?

Cheers,
Fraser

> > Permissions of /etc/dirsrv/slapd-ENG-EXAMPLE-COM/key3.db are 0600 and
> > should be 0640
> > Permissions of /etc/dirsrv/slapd-ENG-EXAMPLE-COM/cert8.db are 0600 and
> > should be 0640
> > Permissions of /etc/dirsrv/slapd-ENG-EXAMPLE-COM/secmod.db are 0600
> > and should be 0640
> 
> Yeah, this is probably fine. I may need to tweak the test to not look
> for specific permissions but rather check what is required and that it
> isn't too permissive.
> 
> > Warnings:
> > Unknown certmonger ids: 20170812234301
> 
> This one is fine. I may make a note to add more details to this. It is
> basically just a heads-up in case you have something tracked you forgot
> about.
> 
> > [root@lithium bin]#
> > 
> > The system so far seem healthy.  Did these file permission had a
> > stricter access that was relaxed later?  I have never attempted to
> > change them, at least impicitly
> 
> It may be related to different versions of IPA or something. This test
> is intended to ensure the ownership and permissions aren't wildly either
> too permissive or too restrictive. It apparently still needs some work.
> 
> rob
> ___
> 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://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.fedorahosted.org
___
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://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.fedorahosted.org

[Freeipa-users] Re: Vault: Cannot authenticate agent with certificate

2018-11-07 Thread Fraser Tweedale via FreeIPA-users 
On Wed, Nov 07, 2018 at 01:05:24PM -0500, Rob Crittenden via FreeIPA-users 
wrote:
> Peter Oliver via FreeIPA-users wrote:
> > [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: 
> > CertUserDBAuthentication: cannot map certificate to any userUser not found
> > [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: SignedAuditLogger: 
> > event AUTH
> > 
> > Any suggestions?  Has something gone wrong with the setup?
> > 
> 
> I'm not sure, cc'ing a dogtag developer.
> 
> rob
>
Hi Peter,

Please check the LDAP entry 'uid=pkidbuser,ou=people,o=ipaca'.
Do the 'userCertificate', 'description' and 'seeAlso' attributes
match the IPA RA certificate (/var/lib/ipa/ra-agent.pem)?

If not, update the entry to match the certificate.

Note that the second field of the 'description' attribute is the
serial number (decimal), and the first field is always '2'.

Cheers,
Fraser
___
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://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.fedorahosted.org

[Freeipa-users] Re: Removal & clean up certificates from o=ipaca

2018-11-07 Thread Fraser Tweedale via FreeIPA-users 
On Wed, Nov 07, 2018 at 04:29:36PM +0100, David Goudet via FreeIPA-users wrote:
> Hello all,
> 
Hi David,

> I have to clean up lot of useless certificate in dirsrv database.
> Because of resubmit loop on Certmonger client, i have 99,9% of certificate in 
> dirsrv database that are useless and not obsolete (expiration in 2020) (it 
> represent ~85 000 certificates).
> 
Did you already resolve the Certmonger resubmit loop?

> These useless certificates produce some issues on FreeIPA:
>  - decrease FreeIPA performances on CLI and GUI
>  - increase the LDAP size
>  - increase size and time of FreeIPA backup
> ...
> 
> Is it possible to purge these certificates in dirsrv database and how? 
> 
Yes.  You can remove them manually.

> I found two branches in LDAP directory about these certificates:
>
> dn: cn=xxx,ou=ca,ou=requests,o=ipaca
> dn: cn=yyy,ou=certificateRepository,ou=ca,o=ipaca
> 
The certificateRepository contains the issued certificates, the
ou=ca,ou=requests contains data about the certificate requests.
Each certificateRepository entry contains a reference to the request
that produced it.

You'll have to manually work out which certs you don't want, delete
its certificateRepository entry (cn is the serial number), and
delete the corresponding request entry.

> I can remove all requests and certificates entry from dirsrv
> database but how it is supported by PKI manager Dogtag (CRL,
> certificate generation, OCSP)?
> 
CRLs and OCSP responses are generated using the data from the
certificateRepository.  Forgetting about non-expired certificates is
not valid under X.509, but since you have an operational issue, just
choose carefully which ones you keep and which ones you delete.

Don't delete the entry for any certificates in active use, OR any
non-expired but revoked certificate where you want it to appear in
CRLs or want valid OCSP responses for that certificate.

Also, whatever certificate has the highest serial number, do not
delete it.  When using sequential serial number (which is how Dogtag
gets configured by FreeIPA) upon startup Dogtag looks for the
highest serial number to work out what is the next serial number to
use.  So keep the cert with the highest serial number otherwise
serial numbers will be re-used.

Cheers,
Fraser
___
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://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.fedorahosted.org

[Freeipa-users] Re: Fails to start CA with Basic Auth (and/or SSL)

2018-11-07 Thread Fraser Tweedale via FreeIPA-users 
On Wed, Nov 07, 2018 at 06:27:51PM -, Zarko D via FreeIPA-users wrote:
> Okay, we know cert has expired, but I am configuring basic auth for PKI, so 
> why is this relevant now? 
>
The basic/cert auth is related to how Dogtag authenticates to the
the database.

The self-test checks the validity of all Dogtag system certificates,
including its HTTPS certificate ("Server-Cert cert-pki-ca").

Check all the certificates in the /etc/pki/pki-tomcat/alias/ NSSDB,
as well as /etc/dirsrv/slapd-YOUR-REALM/, and set the system clock
to a time when all the certificates are valid.  Then Dogtag's
selftest should pass, it should come up, and you should be able to
renew the certificates (or at least, we can help you solve the next
issue ^_^).

Cheers,
Fraser
___
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://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.fedorahosted.org

[Freeipa-users] SSH Key auth with expired Kerberos password

2018-11-07 Thread Nathan Harper via FreeIPA-users 
Hi all,

We have noticed some behaviour that we are trying to work out if it is
expected or not (or if this is an SSSD thing).   We have a pair of FreeIPA
replicas running on CentOS 7 (v4.5.x), with various CentOS 7 clients.
 Most clients aren't actually enrolled in FreeIPA, but are configured with:

id_provider = ldap
auth_provider = krb5

Authentication works as expected, plus password changes etc.   However, if
a user has added a public key to authorized_keys, the status of the
password is not considered and at no point is a user prompted to change
their password.   More importantly, if a user is disabled in FreeIPA, they
are still permitted to login using their SSH key.

I have checked the behaviour on a client that is enrolled, and it is better
(disabling a user does prevent access), but it still does not give any
indication about failed passwords.

Under most circumstances this wouldn't be too much of an issue, but we make
use of one application for remote access that does not know what to do with
an expired password, and instead just presents 'authentication failed'.

Any suggestions?
___
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://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.fedorahosted.org

[Freeipa-users] Re: Issues installing replica

2018-11-07 Thread Alex Corcoles via FreeIPA-users 
OK, did the whole song and dance again (btw, it takes about 6m, I'm not
sure if that's normal), and extracted logs again:

https://gist.github.com/alexpdp7/358626a92a07c787fbf246b2761dddb3

Thanks for your time, guys,

Álex

On Tue, Nov 6, 2018 at 5:17 PM Rob Crittenden  wrote:

> Alex Corcoles via FreeIPA-users wrote:
> > So I solved my LXC problems (thanks Rob, again), but now:
> >
> > ipa-replica-install -U --setup-ca -N
> >
> > fails when rebuilding my replica from scratch, see:
> >
> > https://gist.github.com/alexpdp7/4431da5e11afe6029e2baa01bc1f2251
> >
> > , where I think I've copied the relevant logs. I think I saw someone
> > recommending revoking the replica certs, which makes sense as I'm using
> > the same hostname that I used on the previous replica, but that doesn't
> > seem to fix things.
> >
> > (I'm removing the previous replica via the admin interface, IPA Server
> > -> Topology -> IPA Servers, select my replica and "Delete Server". This
> > removes it too from the host list).
>
> I don't know what it is but it isn't related to existing entries in IPA
> (nor un-revoked certs).
>
> The dogtag installer is asking for a serial # range and getting a
> NotFound. Maybe Fraser knows.
>
> rob
>


-- 
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/
___
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://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.fedorahosted.org

[Freeipa-users] Re: Fails to start CA with Basic Auth (and/or SSL)

2018-11-07 Thread Zarko D via FreeIPA-users 
The /var/lib/pki/pki-tomcat/logs/ca/selftests.log reads: 


0.localhost-startStop-2 - [06/Nov/2018:15:55:02 PST] [20] [1] 
SelfTestSubsystem: Initializing self test plugins:
0.localhost-startStop-2 - [06/Nov/2018:15:55:02 PST] [20] [1] 
SelfTestSubsystem:  loading all self test plugin logger parameters
0.localhost-startStop-2 - [06/Nov/2018:15:55:02 PST] [20] [1] 
SelfTestSubsystem:  loading all self test plugin instances
0.localhost-startStop-2 - [06/Nov/2018:15:55:02 PST] [20] [1] 
SelfTestSubsystem:  loading all self test plugin instance parameters
0.localhost-startStop-2 - [06/Nov/2018:15:55:02 PST] [20] [1] 
SelfTestSubsystem:  loading self test plugins in on-demand order
0.localhost-startStop-2 - [06/Nov/2018:15:55:02 PST] [20] [1] 
SelfTestSubsystem:  loading self test plugins in startup order
0.localhost-startStop-2 - [06/Nov/2018:15:55:02 PST] [20] [1] 
SelfTestSubsystem: Self test plugins have been successfully loaded!
0.localhost-startStop-2 - [06/Nov/2018:15:55:03 PST] [20] [1] 
SelfTestSubsystem: Running self test plugins specified to be executed at 
startup:
0.localhost-startStop-2 - [06/Nov/2018:15:55:03 PST] [20] [1] CAPresence:  CA 
is present
0.localhost-startStop-2 - [06/Nov/2018:15:55:03 PST] [20] [1] 
SystemCertsVerification: system certs verification failure: Certificate 
Server-Cert cert-pki-ca is invalid: Invalid certificate: (-8181) Peer's 
Certificate has expired.
0.localhost-startStop-2 - [06/Nov/2018:15:55:03 PST] [20] [1] 
SelfTestSubsystem: The CRITICAL self test plugin called 
selftests.container.instance.SystemCertsVerification running at startup FAILED!
0.localhost-startStop-3 - [06/Nov/2018:15:55:17 PST] [20] [1] 
SelfTestSubsystem: Initializing self test plugins:
0.localhost-startStop-3 - [06/Nov/2018:15:55:17 PST] [20] [1] 
SelfTestSubsystem:  loading all self test plugin logger parameters
0.localhost-startStop-3 - [06/Nov/2018:15:55:17 PST] [20] [1] 
SelfTestSubsystem:  loading all self test plugin instances
0.localhost-startStop-3 - [06/Nov/2018:15:55:17 PST] [20] [1] 
SelfTestSubsystem:  loading all self test plugin instance parameters
0.localhost-startStop-3 - [06/Nov/2018:15:55:17 PST] [20] [1] 
SelfTestSubsystem:  loading self test plugins in on-demand order
0.localhost-startStop-3 - [06/Nov/2018:15:55:17 PST] [20] [1] 
SelfTestSubsystem:  loading self test plugins in startup order
0.localhost-startStop-3 - [06/Nov/2018:15:55:17 PST] [20] [1] 
SelfTestSubsystem: Self test plugins have been successfully loaded!
0.localhost-startStop-3 - [06/Nov/2018:15:55:17 PST] [20] [1] 
SelfTestSubsystem: Running self test plugins specified to be executed at 
startup:
0.localhost-startStop-3 - [06/Nov/2018:15:55:17 PST] [20] [1] CAPresence:  CA 
is present
0.localhost-startStop-3 - [06/Nov/2018:15:55:17 PST] [20] [1] 
SystemCertsVerification: system certs verification failure: Certificate 
Server-Cert cert-pki-ca is invalid: Invalid certificate: (-8181) Peer's 
Certificate has expired.
0.localhost-startStop-3 - [06/Nov/2018:15:55:17 PST] [20] [1] 
SelfTestSubsystem: The CRITICAL self test plugin called 
selftests.container.instance.SystemCertsVerification running at startup FAILED!


Okay, we know cert has expired, but I am configuring basic auth for PKI, so why 
is this relevant now? 
___
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://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.fedorahosted.org

[Freeipa-users] Re: Vault: Cannot authenticate agent with certificate

2018-11-07 Thread Rob Crittenden via FreeIPA-users 
Peter Oliver via FreeIPA-users wrote:
> I have a CentOS 7 server running ipa-server-4.5.4, recently installed.  I 
> find that operations related to the vault feature fail.  For example:
> 
>> ipa -v vault-add test --type=standard
> ipa: INFO: trying https://ipa-01.example.com/ipa/session/json
> ipa: INFO: [try 1]: Forwarding 'vault_add_internal/1' to json server 
> 'https://ipa-01.example.com/ipa/session/json'
> ipa: INFO: [try 1]: Forwarding 'vault_show/1' to json server 
> 'https://ipa-01.example.com/ipa/session/json'
> ipa: INFO: [try 1]: Forwarding 'vaultconfig_show/1' to json server 
> 'https://ipa-01.example.com/ipa/session/json'
> ipa: INFO: [try 1]: Forwarding 'vault_archive_internal/1' to json server 
> 'https://ipa-01.example.com/ipa/session/json'
> ipa: ERROR: an internal error has occurred
> 
> In /var/log/pki/pki-tomcat/kra/system I see the following message:
> 
> 0.ajp-bio-127.0.0.1-8009-exec-15 - [02/Nov/2018:14:54:37 GMT] [6] [3] Cannot 
> authenticate agent with certificate Serial 0x7 Subject DN CN=IPA 
> RA,O=IPA.EXAMPLE.COM. Error: User not found
> 
> In /var/log/pki/pki-tomcat/kra/debug is see the following messages:
> 
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: 
> SessionContextInterceptor: SystemCertResource.getTransportCert()
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: 
> SessionContextInterceptor: Not authenticated.
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: 
> AuthMethodInterceptor: SystemCertResource.getTransportCert()
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: 
> AuthMethodInterceptor: mapping: default
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: 
> AuthMethodInterceptor: required auth methods: [*]
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: 
> AuthMethodInterceptor: anonymous access allowed
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: ACLInterceptor: 
> SystemCertResource.getTransportCert()
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: 
> ACLInterceptor.filter: no authorization required
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: ACLInterceptor: No 
> ACL mapping; authz not required.
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: SignedAuditLogger: 
> event AUTHZ
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: 
> MessageFormatInterceptor: SystemCertResource.getTransportCert()
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: 
> MessageFormatInterceptor: content-type: application/json
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: 
> MessageFormatInterceptor: accept: [application/json]
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: 
> MessageFormatInterceptor: request format: application/json
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: 
> MessageFormatInterceptor: response format: application/json
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: PKIRealm: 
> Authenticating certificate chain:
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: 
> PKIRealm.getAuditUserfromCert: certUID=CN=IPA RA, O=IPA.EXAMPLE.COM
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: PKIRealm:   CN=IPA 
> RA, O=IPA.EXAMPLE.COM
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: CertUserDBAuth: 
> started
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: CertUserDBAuth: 
> Retrieving client certificate
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: CertUserDBAuth: Got 
> client certificate
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: Authentication: 
> client certificate found
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: In 
> LdapBoundConnFactory::getConn()
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is 
> connected: true
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is 
> connected true
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns 
> now 2
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns 
> now 3
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: 
> CertUserDBAuthentication: cannot map certificate to any userUser not found
> [02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: SignedAuditLogger: 
> event AUTH
> 
> Any suggestions?  Has something gone wrong with the setup?
> 

I'm not sure, cc'ing a dogtag developer.

rob
___
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://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.fedorahosted.org

[Freeipa-users] Re: Testing requested - certificate checking tool

2018-11-07 Thread Rob Crittenden via FreeIPA-users 
William Muriithi via FreeIPA-users wrote:
> Morning Rob
>>> What's the process for either removing or making it known?
>>
>> I'll add something to the program about this too but for now you can run:
>>
>> # getcert list -i 20170919231606
>>
>> That will tell us what it is. It is perfectly fine to have certmonger
>> track other certs on the system. I display unexpected once as a
>> just-in-case.
>>
>> It's supposed to display as just a warning. I'll fix that too since it
>> is a little alarming.
> This is the result I got on my end.:
> 
> Failures:
> 
> Unable to find request for serial 268304424
> Unable to find request for serial 268304426
> Unable to find request for serial 268304425
> Unable to find request for serial 268304423

I'm not sure if this is an invalid test or a real error. I'm still
waiting on the dogtag team to respond to
https://bugzilla.redhat.com/show_bug.cgi?id=1641804 (your results are
slightly different but of the same theme).

> Subject O=ENG.EXAMPLE.COM,CN=zinc.eng.example.com and template subject
> CN=lithium.eng.example.com,O=ENG.EXAMPLE.COM do not match for serial
> 77

Same as above.

I don't know yet if this is a harbinger of doom or a red herring :-/

> Permissions of /etc/dirsrv/slapd-ENG-EXAMPLE-COM/key3.db are 0600 and
> should be 0640
> Permissions of /etc/dirsrv/slapd-ENG-EXAMPLE-COM/cert8.db are 0600 and
> should be 0640
> Permissions of /etc/dirsrv/slapd-ENG-EXAMPLE-COM/secmod.db are 0600
> and should be 0640

Yeah, this is probably fine. I may need to tweak the test to not look
for specific permissions but rather check what is required and that it
isn't too permissive.

> Warnings:
> Unknown certmonger ids: 20170812234301

This one is fine. I may make a note to add more details to this. It is
basically just a heads-up in case you have something tracked you forgot
about.

> [root@lithium bin]#
> 
> The system so far seem healthy.  Did these file permission had a
> stricter access that was relaxed later?  I have never attempted to
> change them, at least impicitly

It may be related to different versions of IPA or something. This test
is intended to ensure the ownership and permissions aren't wildly either
too permissive or too restrictive. It apparently still needs some work.

rob
___
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://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.fedorahosted.org

[Freeipa-users] Re: Fails to start CA with Basic Auth (and/or SSL)

2018-11-07 Thread Rob Crittenden via FreeIPA-users 
Zarko D via FreeIPA-users wrote:
> Hi, this is the part of troubleshooting expired certificates (it's in another 
> post). I can't successfully renew certs after going back in time and I 
> believe the reason is that CA is not starting. Some of posts and Bugzilla 
> bugs suggest using PKI basic authentication, that I try without success, so 
> I'd like to see if I do something wrong. 
> 
> ipa-server is 4.4.0 and pki-server is 10.3.3

Nov  6 15:55:03 ca-ldap04 server: SelfTestSubsystem: Disabling "ca"
subsystem due to selftest failure.

Check out the selftest log for details.

rob
___
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://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.fedorahosted.org

[Freeipa-users] Fails to start CA with Basic Auth (and/or SSL)

2018-11-07 Thread Zarko D via FreeIPA-users 
Hi, this is the part of troubleshooting expired certificates (it's in another 
post). I can't successfully renew certs after going back in time and I believe 
the reason is that CA is not starting. Some of posts and Bugzilla bugs suggest 
using PKI basic authentication, that I try without success, so I'd like to see 
if I do something wrong. 

ipa-server is 4.4.0 and pki-server is 10.3.3


[1] "internaldb" added to /etc/pki/pki-tomcat/password.conf hence it reads:

internal=264530051944
replicationdb=-1979518752
internaldb=directory-manager-password

[2] Edited /etc/pki/pki-tomcat/ca/CS.cfg so diff is:

61c61
< authz.instance.DirAclAuthz.ldap.ldapauth.authtype=BasicAuth
---
> authz.instance.DirAclAuthz.ldap.ldapauth.authtype=SslClientAuth
63,64c63,64
< authz.instance.DirAclAuthz.ldap.ldapconn.port=389
< authz.instance.DirAclAuthz.ldap.ldapconn.secureConn=false
---
> authz.instance.DirAclAuthz.ldap.ldapconn.port=636
> authz.instance.DirAclAuthz.ldap.ldapconn.secureConn=true
784,786c784,785
< internaldb.ldapauth.authtype=BasicAuth
< internaldb.ldapauth.bindDN=cn=Directory Manager
< internaldb.ldapauth.bindPWPrompt=internaldb
---
> internaldb.ldapauth.authtype=SslClientAuth
> internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipaca
791c790
< internaldb.ldapconn.port=389
---
> internaldb.ldapconn.port=636
793c792

< internaldb.ldapconn.secureConn=false
---
> internaldb.ldapconn.secureConn=true


[3] Restart pki-tomcatd@pki-tomcat.service


Please let me know if you need some additional logs, these are the ones I 
believe can help and are relevant.  

[4] /var/log/pki/pki-tomcat/catalina.2018-11-06.log

WARNING: Problem with JAR file [/usr/share/pki/server/common/lib/symkey.jar], 
exists: [false], canRead: [false]
Nov 06, 2018 3:54:35 PM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'enableOCSP' to 'false' did not find a matching property.
Nov 06, 2018 3:54:35 PM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspResponderURL' to 'http://ca-ldap04.internal.com:9080/ca/ocsp' did not find 
a matching property.
Nov 06, 2018 3:54:35 PM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not find a 
matching property.
Nov 06, 2018 3:54:35 PM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspCacheSize' to '1000' did not find a matching property.
Nov 06, 2018 3:54:35 PM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspMinCacheEntryDuration' to '60' did not find a matching property.
Nov 06, 2018 3:54:35 PM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspMaxCacheEntryDuration' to '120' did not find a matching property.
Nov 06, 2018 3:54:35 PM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspTimeout' to '10' did not find a matching property.
Nov 06, 2018 3:54:35 PM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'strictCiphers' to 'true' did not find a matching property.
Nov 06, 2018 3:54:35 PM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'sslOptions' to 'ssl2=false,ssl3=false,tls=true' did not find a matching 
property.
... shortened INFO messages ... 
Nov 06, 2018 3:55:13 PM org.apache.catalina.loader.WebappClassLoaderBase 
clearReferencesThreads
SEVERE: The web application [/ca] appears to have started a thread named 
[LDAPConnThread-9 ldap://ca-ldap04.internal.com:389] but has failed to stop it. 
This is very likely to create a memory leak.
Nov 06, 2018 3:55:13 PM org.apache.catalina.loader.WebappClassLoaderBase 
clearReferencesThreads
SEVERE: The web application [/ca] appears to have started a thread named 
[profileChangeMonitor] but has failed to stop it. This is very likely to create 
a memory leak.



[5] /var/log/pki/pki-tomcat/ca/debug


[06/Nov/2018:15:55:28][ContainerBackgroundProcessor[StandardEngine[Catalina]]]: 
CMSEngine.shutdown()
[06/Nov/2018:15:55:28][ContainerBackgroundProcessor[StandardEngine[Catalina]]]: 
Destroying LdapBoundConnFactory(CrossCertPairSubsystem)
[06/Nov/2018:15:55:28][ContainerBackgroundProcessor[StandardEngine[Catalina]]]: 
Destroying RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/selftests.log)
[06/Nov/2018:15:55:28][ContainerBackgroundProcessor[StandardEngine[Catalina]]]: 
Destroying LogFile(/var/lib/pki/pki-tomcat/logs/ca/selftests.log)

[Freeipa-users] Removal & clean up certificates from o=ipaca

2018-11-07 Thread David Goudet via FreeIPA-users 
Hello all,

I have to clean up lot of useless certificate in dirsrv database.
Because of resubmit loop on Certmonger client, i have 99,9% of certificate in 
dirsrv database that are useless and not obsolete (expiration in 2020) (it 
represent ~85 000 certificates).

These useless certificates produce some issues on FreeIPA:
 - decrease FreeIPA performances on CLI and GUI
 - increase the LDAP size
 - increase size and time of FreeIPA backup
...

Is it possible to purge these certificates in dirsrv database and how? 

I found two branches in LDAP directory about these certificates:
dn: cn=xxx,ou=ca,ou=requests,o=ipaca
dn: cn=yyy,ou=certificateRepository,ou=ca,o=ipaca

I can remove all requests and certificates entry from dirsrv database but how 
it is supported by PKI manager Dogtag (CRL, certificate generation, OCSP)?

(This topic has already been discuss on 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/RPF5XY3SXFIJFZG4FXLBZTXOQHWTDK4D/)

Thank you for you help

-- 
David GOUDET 

LYRA NETWORK 
IT Operations service
Tel : +33 (0)5 32 09 09 74 | Poste : 574
___
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://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.fedorahosted.org

[Freeipa-users] Re: sftp file broswer causes 4 (System Error)

2018-11-07 Thread Alexander Bokovoy via FreeIPA-users 

On ke, 07 marras 2018, Alfredo De Luca via FreeIPA-users wrote:

Hi all. I wonder who and how this is been resolved?
I have centos 7 where an sftp server is running. Authentication is with
freeIPA 4.5.4.
all the users connect to the sftp server normally but when there are
multiple connections  randomly I got this error

Nov  7 08:30:09 sftp sshd[23487]: pam_sss(sshd:account): Access denied for
user nifi_sftp: 4 (System error)

Not sure why. The same user doesn't have any issue connecting manually but
when different connections from 3 nodes (running a open source sftp client
called NIFI from apache.org) I got that error.
I have to say that I tried to reproduce with a script running multiple
connections at the same time and I get the same errors. If I use
controlmaster mechanism on ssh client I dont' get the error at all.

Any idea?

Use sssd debugging to demonstrate why pam_sss is denying access.
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html

You'd need logs from the sssd_.log and sssd_pam.log related to
the time when there is an attempt to connect with NIFI. Use
debug_level=9 in domain and pam sections to show all logs and provide
them somewhere we can look up.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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://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.fedorahosted.org

[Freeipa-users] Re: Replica install on RPI3

2018-11-07 Thread Rob Crittenden via FreeIPA-users 
Winfried de Heiden via FreeIPA-users wrote:
> Hi all,
> 
> See https://www.freeipa.org/page/ARM
> 
> 
> As mentioned earlier: I applied these settings but it wasn't enough. The
> startup_timeout was set at a huge 1200 but somewhere during a restart,
> it will complain:
> 
> ... server did not start after 60s\npkispawn    : ERROR   
> 
> ... server failed to restart\n')
> 
> 
> It's complaining about 60 seconds, not 1200 so I guess there's sme other 
> value to set, somewhere

You updated /etc/ipa/default.conf and you need to use
/etc/ipa/installer.conf

rob

> 
> 
> Winfried
> 
> 
> 
> -Oorspronkelijk bericht-
> *Van*: Rob Crittenden via FreeIPA-users
>  >
> *Antwoord-naar*: FreeIPA users list
>  >
> *Aan*: FreeIPA users list  >
> *Cc*: Winfried de Heiden  >, Fraser Tweedale
>  >, Rob Crittenden
> mailto:rob%20crittenden%20%3crcrit...@redhat.com%3e>>
> *Onderwerp*: [Freeipa-users] Re: Replica install on RPI3
> *Datum*: Mon, 5 Nov 2018 11:25:21 -0500
> 
> Winfried de Heiden via FreeIPA-users wrote:
> 
> Hi all,
> 
> 
> Believe me, after modifying "startup_timeout" in
> 
> /usr/lib/python3.7/site-packages/ipalib/constants.py and
> 
> /etc/ipa/default.conf is does run on a Pi as a Master but obviously this
> 
> is not enough fiir the Replica.
> 
> 
> See https://www.freeipa.org/page/ARM
> 
> 
> I did not add this post to discuss whether it is usefull to run on a P,
> 
> I try to find out which install parameter (I guess) to modify in which
> 
> file. I had FreeIPA running Master running for months on a Pi. It ran
> 
> stable :)
> 
> 
> There are multiple reports of it (and related hardware like the banana
> 
> pi) running fine. How much of a good idea it is is up for debate ;-)
> 
> 
> TBH I'm glad you're creating a replica with a CA so you don't have a
> 
> single point-of-failure.
> 
> 
> rob
> 
> 
> Winfried
> 
> 
> 
> 
> Fraser Tweedale via FreeIPA-users schreef op 05-11-2018 0:37:
> 
> Dogtag CA is a massive enterprise Java program.  Can't do much about
> 
> it.  Run a CA-less deployment, or run a CA-ful deployment with
> 
> RaspberryPi replicas having no CA, and CA replicas running on
> 
> machines with more memory and more grunt.
> 
> 
> Cheers,
> 
> Fraser
> 
> 
> On Sun, Nov 04, 2018 at 04:04:27PM +0100, Winfried de Heiden via
> 
> FreeIPA-users wrote:
> 
> Hi all,
> 
> can't tell it's the only issue. Installing the replica without CA
> 
> works well. The error happens during a restart during installation
> 
> wich take too much time. Don't know what will go wrong after fixing
> 
> this issue
> 
> Winfried
> 
> John Keates via FreeIPA-users schreef op za 03-11-2018 om 16:41 [+0100]:
> 
> Ah, so the install went fine but the CA startup is the only
> 
> remaining issue?
> 
> John
> 
> 
> On 3 Nov 2018, at 16:39, Winfried de Heiden via FreeIPA-users
> 
>  > wrote:
> 
> 
> Hi all,
> 
> Yes, the Pi is too slow but funny enough it can work perfectly.
> 
> The DogTag CA server just takes a painfull time to start. I had a Pi
> 
> running as just a master for months quite well, but start Dogtag took
> 
> a very long time, but afterwards it all ran well in a small
> 
> environment (@home...)
> 
> As mentioned, just for the sake of trying and Pi are so cheap, I'
> 
> m trying to setup a Pi Replica but default setup timeout settings
> 
> need a modification...
> 
> Winfried
> 
> 
> 
> John Keates schreef op za 03-11-2018 om 16:26 [+0100]:
> 
> My suggestion would be: don’t run it on a Pi, it’s not fast
> 
> enough. But you came to that conclusion already, so I guess the next
> 
> issue would be: where does it fail?I’m assuming the rpm install works
> 
> out but ipa-server-install doesn’t? Or does that work but does the
> 
> starting of all the components time out?
> 
> 
> If it’s just the installation that’s failing, you can get
> 
> around that by running the install in an emulated ARM machine first,
> 
> and then copying the filesystem over to the Pi.
> 
> 
> John
> 
> 
> 
> On 3 Nov 2018, at 15:53, Winfried de Heiden via FreeIPA-users
> 
>  > wrote:
> 
> 
> Hi all,
> 
> Just because we can and a Rapsberry Pi 3 is cheap, I'm trying
> 
> to install a FreeIPA replica on Fedora 29 ARM. It looks like the
> 
> Raspberry is a bit too slow for default installation settings:
> 
> 018-11-03T12:27:12Z DEBUG stderr=WARNING: Password was
> 
> garbage collected before it was cleared.password file contains no
> 
> datapkispawn    : ERROR    ... server did not start after
> 
> 60spkispawn    : ERROR    ... server failed to restart
> 
>

[Freeipa-users] Re: sftp file broswer causes 4 (System Error)

2018-11-07 Thread Alfredo De Luca via FreeIPA-users 
Hi all. I wonder who and how this is been resolved?
I have centos 7 where an sftp server is running. Authentication is with
freeIPA 4.5.4.
all the users connect to the sftp server normally but when there are
multiple connections  randomly I got this error

Nov  7 08:30:09 sftp sshd[23487]: pam_sss(sshd:account): Access denied for
user nifi_sftp: 4 (System error)

Not sure why. The same user doesn't have any issue connecting manually but
when different connections from 3 nodes (running a open source sftp client
called NIFI from apache.org) I got that error.
I have to say that I tried to reproduce with a script running multiple
connections at the same time and I get the same errors. If I use
controlmaster mechanism on ssh client I dont' get the error at all.

Any idea?
cheers


On Mon, Sep 17, 2018 at 3:43 AM Aaron Hicks via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hi Simo,
>
> Yes, we recognise this as a client side issue. This was as much a FYI post
> for people in the future searching for similar issues to latch onto. I've
> also made similar comments back to the developers of the MobaXterm client
> we observed this with. We now ask our users to switch the file browser
> protocol to SCP which I think uses the master connection method you've
> recommended.
>
> Regards,
>
> Aaron
>
> -Original Message-
> From: Simo Sorce 
> Sent: Thursday, 13 September 2018 4:20 AM
> To: FreeIPA users list 
> Cc: Aaron Hicks 
> Subject: Re: [Freeipa-users] sftp file broswer causes 4 (System Error)
>
> On Tue, 2018-09-11 at 14:10 +1200, Aaron Hicks via FreeIPA-users wrote:
> > Hello the list,
> >
> >
> >
> > We just had a bit of fuss involved user logins. We're using sssd
> > 1.16.1 on a client and FreeIPA 4.5.4 (ok, it's really RHIdM)
> >
> >
> >
> > We had a lot of users having issues logging and/or resetting their
> > passwords on a host with 2FA enabled, and it turns out when they're
> > using an advanced SSH client (e.g. MobaXterm) that also starts a SFTP
> > session they can't login and we see error like:
> >
> >
> >
> > Sep 11 00:09:05 lander sshd[27408]: pam_sss(sshd:auth): received for
> > user
> > testuser: 4 (System error)
> >
> > Sep 11 00:09:06 lander sshd[27380]: error: PAM: Authentication failure
> > for testuser from remote.local
> >
> >
> >
> > If the SFTP file browser is disabled, or it's protocol is set to use
> > SCP then logins progress normally.
> >
> >
> >
> > In FreeIPA we've enabled 2FA on a per-host basis and the HBAC rule
> > only allows sshd services, so if these were the cause of the '4 (System
> error)'
> > failures then it'd be much better if the error reports were more
> meaningful.
> >
> >
> >
> > Does anyone have any advice on setting up SFTP so that it works (and
> > ideally, doesn't need repeated entry of credentials).
>
> You should find out if your client supports using a master connection for
> SSH, instead of trying to open multiple different connection for SSH and
> SFTP. In the end it is a client issue if it can't properly prompt for
> credentials when it uses multiple different authenticated connections (I
> assume this client is caching passwords and trying to resubmit old 2FA
> codes in the process ? [Caching of password seem already bad in itself if
> that's the case, how long does it hold onto your creds? will it leak them?])
>
> HTH,
> Simo.
>
> --
> Simo Sorce
> Sr. Principal Software Engineer
> Red Hat, Inc
>
> ___
> 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://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.fedorahosted.org
>


-- 
*Alfredo*
___
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://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.fedorahosted.org

[Freeipa-users] Re: Replica install on RPI3

2018-11-07 Thread Winfried de Heiden via FreeIPA-users 
Hi all,

See https://www.freeipa.org/page/ARM
As mentioned earlier: I applied these settings but it wasn't enough. The 
startup_timeout was set at a huge 1200 but somewhere during a restart, it will 
complain:

... server did not start after 60s\npkispawn: ERROR   ... 
server failed to restart\n')
It's complaining about 60 seconds, not 1200 so I guess there's sme other value 
to set, somewhere
Winfried


-Oorspronkelijk bericht-
Van: Rob Crittenden via FreeIPA-users 
Antwoord-naar: FreeIPA users list 
Aan: FreeIPA users list 
Cc: Winfried de Heiden , Fraser Tweedale , 
Rob Crittenden 
Onderwerp: [Freeipa-users] Re: Replica install on RPI3
Datum: Mon, 5 Nov 2018 11:25:21 -0500

Winfried de Heiden via FreeIPA-users wrote:
Hi all,
Believe me, after modifying "startup_timeout" 
in/usr/lib/python3.7/site-packages/ipalib/constants.py and/etc/ipa/default.conf 
is does run on a Pi as a Master but obviously thisis not enough fiir the 
Replica.
See https://www.freeipa.org/page/ARM
I did not add this post to discuss whether it is usefull to run on a P,I try to 
find out which install parameter (I guess) to modify in whichfile. I had 
FreeIPA running Master running for months on a Pi. It ranstable :)
There are multiple reports of it (and related hardware like the bananapi) 
running fine. How much of a good idea it is is up for debate ;-)
TBH I'm glad you're creating a replica with a CA so you don't have asingle 
point-of-failure.
rob
Winfried


Fraser Tweedale via FreeIPA-users schreef op 05-11-2018 0:37:
Dogtag CA is a massive enterprise Java program.  Can't do much aboutit.  Run a 
CA-less deployment, or run a CA-ful deployment withRaspberryPi replicas having 
no CA, and CA replicas running onmachines with more memory and more grunt.
Cheers,Fraser
On Sun, Nov 04, 2018 at 04:04:27PM +0100, Winfried de Heiden viaFreeIPA-users 
wrote:
Hi all,can't tell it's the only issue. Installing the replica without CAworks 
well. The error happens during a restart during installationwich take too much 
time. Don't know what will go wrong after fixingthis issueWinfriedJohn 
Keates via FreeIPA-users schreef op za 03-11-2018 om 16:41 [+0100]:
Ah, so the install went fine but the CA startup is the onlyremaining issue?
John
On 3 Nov 2018, at 16:39, Winfried de Heiden via 
FreeIPA-users wrote:

Hi all,Yes, the Pi is too slow but funny enough it can work perfectly.The 
DogTag CA server just takes a painfull time to start. I had a Pirunning as just 
a master for months quite well, but start Dogtag tooka very long time, but 
afterwards it all ran well in a smallenvironment (@home...)
As mentioned, just for the sake of trying and Pi are so cheap, I'm trying to 
setup a Pi Replica but default setup timeout settingsneed a modification...
Winfried

John Keates schreef op za 03-11-2018 om 16:26 [+0100]:
My suggestion would be: don’t run it on a Pi, it’s not fastenough. But you came 
to that conclusion already, so I guess the nextissue would be: where does it 
fail?I’m assuming the rpm install worksout but ipa-server-install doesn’t? Or 
does that work but does thestarting of all the components time out?

If it’s just the installation that’s failing, you can getaround that by running 
the install in an emulated ARM machine first,and then copying the filesystem 
over to the Pi.

John

On 3 Nov 2018, at 15:53, Winfried de Heiden via 
FreeIPA-users wrote:

Hi all,Just because we can and a Rapsberry Pi 3 is cheap, I'm tryingto install 
a FreeIPA replica on Fedora 29 ARM. It looks like theRaspberry is a bit too 
slow for default installation settings:
018-11-03T12:27:12Z DEBUG stderr=WARNING: Password wasgarbage collected before 
it was cleared.password file contains nodatapkispawn: ERROR... 
server did not start after60spkispawn: ERROR... server failed to 
restart
2018-11-03T12:27:12Z CRITICAL Failed to configure CAinstance: 
CalledProcessError(Command ['/usr/sbin/pkispawn', '-s','CA', '-f', 
'/tmp/tmpv2y32e9l'] returned non-zero exit status 1:'WARNING: Password was 
garbage collected before it wascleared.\npassword file contains no 
data\npkispawn: ERROR   ... server did not start after 
60s\npkispawn: ERROR   ... server failed to 
restart\n')2018-11-03T12:27:12Z CRITICAL Seethe installation logs and the 
following files/directories for moreinformation:2018-11-03T12:27:12Z CRITICAL  
/var/log/pki/pki-tomcat2018-11-03T12:27:12Z DEBUG Traceback (mostrecent call 
last):  
File"/usr/lib/python3.7/site-packages/ipaserver/install/dogtaginstance.py",line 
164, in spawn_instanceipautil.run(args, nolog=nolog_list) File 
"/usr/lib/python3.7/site-packages/ipapython/ipautil.py", line573, in run
p.returncode, arg_string, output_log, 
error_logipapython.ipautil.CalledProcessError: 
CalledProcessError(Command['/usr/sbin/pkispawn', '-s', 'CA', '-f', 
'/tmp/tmpv2y32e9l'] returnednon-zero exit status 1: 'WARNING: Password was 
garbage collected beforeit was cleared.\npassword