[Freeipa-users] Re: Expired certificate problem

2018-01-08 Thread Fraser Tweedale via FreeIPA-users 
On Mon, Jan 08, 2018 at 10:15:29PM +0100, Giulio Casella via FreeIPA-users 
wrote:
> After some time, requests go "CA_UNREACHABLE", caused by "RPC failed at
> server.  Request failed with status 500: Non-2xx response from CA REST API:
> 500." when certmonger tries to renew httpd/dirsrv certificate.
> 
> Any ideas to correctly debug this issue?
> 
Here are some things to check:

What is the validity of /var/lib/ipa/ra-agent.pem at the time you
set the clock back to?  Is it possible that you have gone earlier
than its `notBefore' time?

Is that certificate in sync with the userCertificate attribute of
the `uid=ipara,ou=people,o=ipaca' LDAP entry?

What does the /var/log/pki/pki-tomcat/ca/debug log contain?

Cheers,
Fraser


> 
> 
> Il 08/01/2018 17:56, Giulio Casella via FreeIPA-users ha scritto:
> > 
> > 
> > Il 08/01/2018 17:26, Rob Crittenden ha scritto:
> > > Giulio Casella via FreeIPA-users wrote:
> > > 
> > > You need to stop ntpd, use date to go back when the web server cert is
> > > still valid, then restart certmonger. That generally will do it.
> > 
> > Hi Rob,
> > I already tried with date few hours before expiration, with no luck:
> > certmonger cannot perform cert update.
> > 
> > Queued requests remain in "SUBMITTING" status, I tried to launch
> > certmonger in foreground (-d 10), here's a snippet of the output:
> > 
> > 2018-01-08 01:17:08 [6000] Request9('20171205091409') ends in state
> > 'HAVE_CSR'
> > 2018-01-08 01:17:08 [6000] Stopped Request9('20171205091409').
> > 2018-01-08 01:17:09 [6235] Read value "0" from
> > "/proc/sys/crypto/fips_enabled".
> > 2018-01-08 01:17:09 [6235] Not attempting to set NSS FIPS mode.
> > 2018-01-08 01:17:09 [6235] Skipping NSS internal slot (NSS Generic
> > Crypto Services).
> > 2018-01-08 01:17:09 [6235] Found token 'NSS Certificate DB'.
> > 2018-01-08 01:17:09 [6235] Located a certificate with the key's nickname
> > ("Server-Cert").
> > 2018-01-08 01:17:09 [6235] Located its private key.
> > 2018-01-08 01:17:09 [6235] Recovered public key from private key.
> > 2018-01-08 01:17:09 [6235] Key is an RSA key.
> > 2018-01-08 01:17:09 [6235] Key size is 2048.
> > 2018-01-08 01:17:10 [6251] Read value "0" from
> > "/proc/sys/crypto/fips_enabled".
> > 2018-01-08 01:17:10 [6251] Not attempting to set NSS FIPS mode.
> > 2018-01-08 01:17:10 [6251] Found token 'NSS Generic Crypto Services'.
> > 2018-01-08 01:17:10 [6251] Token is named "NSS Generic Crypto Services",
> > not "NSS Certificate DB", skipping.
> > 2018-01-08 01:17:10 [6251] Found token 'NSS Certificate DB'.
> > 2018-01-08 01:17:10 [6251] Located the certificate "Server-Cert".
> > 2018-01-08 01:17:10 [6251] Read value "0" from
> > "/proc/sys/crypto/fips_enabled".
> > 2018-01-08 01:17:10 [6251] Not attempting to set NSS FIPS mode.
> > 2018-01-08 01:17:10 [6000] Request9('20171205091409') starts in state
> > 'HAVE_KEYINFO'
> > 2018-01-08 01:17:10 [6000] Request9('20171205091409') moved to state
> > 'NEED_CSR'
> > 2018-01-08 01:17:10 [6000] Will revisit Request9('20171205091409') now.
> > 2018-01-08 01:17:10 [6000] Started Request9('20171205091409').
> > 2018-01-08 01:17:10 [6000] Queuing FD 7 for Read for
> > 0x561b59c82750:0x561b59c98940.
> > 2018-01-08 01:17:10 [6000] Request9('20171205091409') moved to state
> > 'GENERATING_CSR'
> > 2018-01-08 01:17:10 [6000] Will revisit Request9('20171205091409') on
> > traffic from 27.
> > 2018-01-08 01:17:11 [6263] Read value "0" from
> > "/proc/sys/crypto/fips_enabled".
> > 2018-01-08 01:17:11 [6263] Not attempting to set NSS FIPS mode.
> > 2018-01-08 01:17:11 [6263] Skipping NSS internal slot (NSS Generic
> > Crypto Services).
> > 2018-01-08 01:17:11 [6263] Found token 'NSS Certificate DB'.
> > 2018-01-08 01:17:11 [6263] Located a certificate with the key's nickname
> > ("Server-Cert").
> > 2018-01-08 01:17:11 [6263] Located its private key.
> > 2018-01-08 01:17:11 [6263] Recovered public key from private key.
> > 2018-01-08 01:17:11 [6000] Request9('20171205091409') moved to state
> > 'HAVE_CSR'
> > 2018-01-08 01:17:11 [6000] Will revisit Request9('20171205091409') now.
> > 2018-01-08 01:17:11 [6000] Request9('20171205091409') moved to state
> > 'NEED_TO_SUBMIT'
> > 2018-01-08 01:17:11 [6000] Will revisit Request9('20171205091409') now.
> > 2018-01-08 01:17:11 [6000] Request9('20171205091409') moved to state
> > 'SUBMITTING'
> > 2018-01-08 01:17:11 [6000] Will revisit Request9('20171205091409') on
> > traffic from 31.
> > ^C2018-01-08 01:17:14 [6000] Got signal 2.
> > 2018-01-08 01:17:14 [6000] Shutting down.
> > 
> > I'm stuck...
> > 
> > Thank you for your time.
> > 
> > > 
> > > rob
> > > 
> > > > 
> > > > Is there a way to force update?
> > > > 
> > > > Here's my output of "getcert list":
> > > > 
> > > > 
> > > > Number of certificates and requests being tracked: 9.
> > > > Request ID '20170915095009':
> > > >  status: MONITORING
> > > >  stuck: no
> > > >  key pair storage:
> > > > type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
>

[Freeipa-users] Re: IPA Password Vault

2018-01-08 Thread Fraser Tweedale via FreeIPA-users 
On Mon, Jan 08, 2018 at 06:48:11PM -0700, Sean Hogan via FreeIPA-users wrote:
> 
> Hi Fraser,
> 
>   Thanks for the reply.  Agreed that a vault stores a secret however when
> that secret is say a pw for a shared ID like for instance root.   While
> a number of people can access the password for root in the vault I might
> not want 20 people using the root pw at the sametime because I am losing
> traceability as to who is using root.  Other vaults use the concept of
> checking in/out the password so while it is checked out no one else can get
> the password leaving the tractability in tact.  When the password is
> checked in then the password is automatically reset so the last person that
> knew it can no longer use it without going thru the check out process again
> which satisfies a lot of regulatory/audit concerns.
> 
> 
>   It would appear those types of features are not available in the IPA
> vault but wanted to confirm it with you all.
> 
Hi Sean,

I can confirm that we don't support that.  It is beyond the scope of
what vault is (a simple secret store).  What you really want is a
system that releases unique one-time credentials to authorised
users, and corresponding components on the target server(s) to
validate these credentials (e.g. a PAM module) and generate relevant
audit events.  FreeIPA does not have this feature.

An alternative is to use HBAC rules and/or Sudo rules to limit who
can log in to target servers, and who can perform particular
privileged operations on target servers.  FreeIPA enables this
approach.

Cheers,
Fraser

> 
> Sean Hogan
> 
> 
> 
> 
> 
> 
> 
> From: Fraser Tweedale via FreeIPA-users
> 
> To:   FreeIPA users list 
> Cc:   Sean Hogan , Fraser Tweedale
> 
> Date: 01/08/2018 06:20 PM
> Subject:  [Freeipa-users] Re: IPA Password Vault
> 
> 
> 
> On Mon, Jan 08, 2018 at 08:44:29AM -0700, Sean Hogan via FreeIPA-users
> wrote:
> >
> >
> >   Hello,
> >
> >  I have recently been looking into the password vault for IPA and would
> > like to implement however I have not been able to find an answer to a
> > compliance question on it yet.
> >
> >
> >Does the IPA PW vault limit checking out the password for a shared id
> to
> > one person at a time?  I am thinking this would ensure that personal
> > accountability of that ID being used instead of allowing multiple people
> > checking out the same id password.
> >
> > RHEL 7.3 IPA 4.4
> >
> I'm not 100% sure what you are asking.  Vault is for storing a
> secret.  A shared vault means more than one person can read the
> vault.  Authorised people can "retrieve" the secret, but the datam
> is the same for each person, and there is no concept of "checking
> out" or "locking".
> 
> Hope that helps,
> Fraser
> 
> >
> >
> > Sean Hogan
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> > ___
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.org
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> 
> 



> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: IPA Password Vault

2018-01-08 Thread Sean Hogan via FreeIPA-users 

Hi Fraser,

  Thanks for the reply.  Agreed that a vault stores a secret however when
that secret is say a pw for a shared ID like for instance root.   While
a number of people can access the password for root in the vault I might
not want 20 people using the root pw at the sametime because I am losing
traceability as to who is using root.  Other vaults use the concept of
checking in/out the password so while it is checked out no one else can get
the password leaving the tractability in tact.  When the password is
checked in then the password is automatically reset so the last person that
knew it can no longer use it without going thru the check out process again
which satisfies a lot of regulatory/audit concerns.


  It would appear those types of features are not available in the IPA
vault but wanted to confirm it with you all.


Sean Hogan







From:   Fraser Tweedale via FreeIPA-users

To: FreeIPA users list 
Cc: Sean Hogan , Fraser Tweedale

Date:   01/08/2018 06:20 PM
Subject:[Freeipa-users] Re: IPA Password Vault



On Mon, Jan 08, 2018 at 08:44:29AM -0700, Sean Hogan via FreeIPA-users
wrote:
>
>
>   Hello,
>
>  I have recently been looking into the password vault for IPA and would
> like to implement however I have not been able to find an answer to a
> compliance question on it yet.
>
>
>Does the IPA PW vault limit checking out the password for a shared id
to
> one person at a time?  I am thinking this would ensure that personal
> accountability of that ID being used instead of allowing multiple people
> checking out the same id password.
>
> RHEL 7.3 IPA 4.4
>
I'm not 100% sure what you are asking.  Vault is for storing a
secret.  A shared vault means more than one person can read the
vault.  Authorised people can "retrieve" the secret, but the datam
is the same for each person, and there is no concept of "checking
out" or "locking".

Hope that helps,
Fraser

>
>
> Sean Hogan
>
>
>
>
>
>




> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to
freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Forwarders don't work when enabled but do work when disabled

2018-01-08 Thread Martin Basti via FreeIPA-users 
Where and how do you have configured forwarders. Is it a global forwarder,
or forward zone forwarder, zone forwarder. Do you have forward zones
configured. etc..

2018-01-08 21:17 GMT+01:00 Matt . via FreeIPA-users <
freeipa-users@lists.fedorahosted.org>:

> HI Martin,
>
> I disabled them from the GUI.
>
> What do you want to know about the config ?
>
> Cheers,
>
> Matt
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>



-- 
S pozdravom Martin Bašti.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ipa-client-install - error - Failed to obtain host TGT: Major (851968)

2018-01-08 Thread Robbie Harwood via FreeIPA-users 
lejeczek via FreeIPA-users 
writes:

> $ ipa-client-install --no-ntp --force-join
>
> krb5kdc[1560686](info): preauth (encrypted_timestamp) verify 
> failure: Preauthentication failed
>
> But after many tries(randomly) suddenly it would succeed. 

Do the clocks match on the client and server?

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Expired certificate problem

2018-01-08 Thread Giulio Casella via FreeIPA-users 
After some time, requests go "CA_UNREACHABLE", caused by "RPC failed at 
server.  Request failed with status 500: Non-2xx response from CA REST 
API: 500." when certmonger tries to renew httpd/dirsrv certificate.


Any ideas to correctly debug this issue?



Il 08/01/2018 17:56, Giulio Casella via FreeIPA-users ha scritto:



Il 08/01/2018 17:26, Rob Crittenden ha scritto:

Giulio Casella via FreeIPA-users wrote:

You need to stop ntpd, use date to go back when the web server cert is
still valid, then restart certmonger. That generally will do it.


Hi Rob,
I already tried with date few hours before expiration, with no luck:
certmonger cannot perform cert update.

Queued requests remain in "SUBMITTING" status, I tried to launch
certmonger in foreground (-d 10), here's a snippet of the output:

2018-01-08 01:17:08 [6000] Request9('20171205091409') ends in state
'HAVE_CSR'
2018-01-08 01:17:08 [6000] Stopped Request9('20171205091409').
2018-01-08 01:17:09 [6235] Read value "0" from
"/proc/sys/crypto/fips_enabled".
2018-01-08 01:17:09 [6235] Not attempting to set NSS FIPS mode.
2018-01-08 01:17:09 [6235] Skipping NSS internal slot (NSS Generic
Crypto Services).
2018-01-08 01:17:09 [6235] Found token 'NSS Certificate DB'.
2018-01-08 01:17:09 [6235] Located a certificate with the key's nickname
("Server-Cert").
2018-01-08 01:17:09 [6235] Located its private key.
2018-01-08 01:17:09 [6235] Recovered public key from private key.
2018-01-08 01:17:09 [6235] Key is an RSA key.
2018-01-08 01:17:09 [6235] Key size is 2048.
2018-01-08 01:17:10 [6251] Read value "0" from
"/proc/sys/crypto/fips_enabled".
2018-01-08 01:17:10 [6251] Not attempting to set NSS FIPS mode.
2018-01-08 01:17:10 [6251] Found token 'NSS Generic Crypto Services'.
2018-01-08 01:17:10 [6251] Token is named "NSS Generic Crypto Services",
not "NSS Certificate DB", skipping.
2018-01-08 01:17:10 [6251] Found token 'NSS Certificate DB'.
2018-01-08 01:17:10 [6251] Located the certificate "Server-Cert".
2018-01-08 01:17:10 [6251] Read value "0" from
"/proc/sys/crypto/fips_enabled".
2018-01-08 01:17:10 [6251] Not attempting to set NSS FIPS mode.
2018-01-08 01:17:10 [6000] Request9('20171205091409') starts in state
'HAVE_KEYINFO'
2018-01-08 01:17:10 [6000] Request9('20171205091409') moved to state
'NEED_CSR'
2018-01-08 01:17:10 [6000] Will revisit Request9('20171205091409') now.
2018-01-08 01:17:10 [6000] Started Request9('20171205091409').
2018-01-08 01:17:10 [6000] Queuing FD 7 for Read for
0x561b59c82750:0x561b59c98940.
2018-01-08 01:17:10 [6000] Request9('20171205091409') moved to state
'GENERATING_CSR'
2018-01-08 01:17:10 [6000] Will revisit Request9('20171205091409') on
traffic from 27.
2018-01-08 01:17:11 [6263] Read value "0" from
"/proc/sys/crypto/fips_enabled".
2018-01-08 01:17:11 [6263] Not attempting to set NSS FIPS mode.
2018-01-08 01:17:11 [6263] Skipping NSS internal slot (NSS Generic
Crypto Services).
2018-01-08 01:17:11 [6263] Found token 'NSS Certificate DB'.
2018-01-08 01:17:11 [6263] Located a certificate with the key's nickname
("Server-Cert").
2018-01-08 01:17:11 [6263] Located its private key.
2018-01-08 01:17:11 [6263] Recovered public key from private key.
2018-01-08 01:17:11 [6000] Request9('20171205091409') moved to state
'HAVE_CSR'
2018-01-08 01:17:11 [6000] Will revisit Request9('20171205091409') now.
2018-01-08 01:17:11 [6000] Request9('20171205091409') moved to state
'NEED_TO_SUBMIT'
2018-01-08 01:17:11 [6000] Will revisit Request9('20171205091409') now.
2018-01-08 01:17:11 [6000] Request9('20171205091409') moved to state
'SUBMITTING'
2018-01-08 01:17:11 [6000] Will revisit Request9('20171205091409') on
traffic from 31.
^C2018-01-08 01:17:14 [6000] Got signal 2.
2018-01-08 01:17:14 [6000] Shutting down.

I'm stuck...

Thank you for your time.



rob



Is there a way to force update?

Here's my output of "getcert list":


Number of certificates and requests being tracked: 9.
Request ID '20170915095009':
 status: MONITORING
 stuck: no
 key pair storage:
type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
 certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
 CA: SelfSign
 issuer:
CN=idc01.linux.unicloudidattica.local,O=LINUX.UNICLOUDIDATTICA.LOCAL
 subject:
CN=idc01.linux.unicloudidattica.local,O=LINUX.UNICLOUDIDATTICA.LOCAL
 expires: 2018-09-15 09:50:10 UTC
 principal name:
krbtgt/LINUX.UNICLOUDIDATTICA.LOCAL@LINUX.UNICLOUDIDATTICA.LOCAL
 certificate template/profile: KDCs_PKINIT_Certs
 pre-save command:
 post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
 track: yes
 auto-renew: yes
Request ID '20171205091347':
 status: MONITORING
 stuck: no
 key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert

cert-pki-ca',token='NSS Certificate DB',pin set
 certificate:

[Freeipa-users] Re: Forwarders don't work when enabled but do work when disabled

2018-01-08 Thread Matt . via FreeIPA-users 
HI Martin,

I disabled them from the GUI.

What do you want to know about the config ?

Cheers,

Matt
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Plugin for simple user attribute / textfield in Gui

2018-01-08 Thread Matt . via FreeIPA-users 
Hi Guys,

Comparing to the great demo of Ab: 
https://github.com/abbra/freeipa-userstatus-plugin I was wondering if someone 
created something like it but for a simple textfield as well.

Reinventing the wheel is not good so maybe someone has a working example/plugin.

Thanks!

Matt
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ipa-client-install - error - Failed to obtain host TGT: Major (851968)

2018-01-08 Thread lejeczek via FreeIPA-users 



On 08/01/18 08:46, Florence Blanc-Renaud wrote:

On 01/06/2018 08:51 PM, lejeczek via FreeIPA-users wrote:


hi everyone

I'm trying a client, when I do:

$ ipa-client-install --no-ntp --force-join
Discovery was successful!
...
Also note that following ports are necessary for 
ipa-client working properly after enrollment:

  TCP: 464
  UDP: 464, 123 (if NTP enabled)
Failed to obtain host TGT: Major (851968): Unspecified 
GSS failure. Minor code may provide more information, 
Minor (2529638936): Preauthentication failed

Installation failed. Rolling back changes.
-- end

At server's end(one single server in domain):
..
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x 
krb5kdc[1560685](info): closing down fd 11
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x 
krb5kdc[1560686](info): AS_REQ (8 etypes {18 17 20 19 16 
23 25 26}) 10.5.6.17: NEEDED_PREAUTH: 
host/dzien.priv.xx.xx.priv.xx.x...@private.xx.xx.private.xx.xx.x 
for 
krbtgt/private.xx.xx.private.xx.x...@private.xx.xx.private.xx.xx.x, 
Additional pre-authentication required
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x 
krb5kdc[1560686](info): closing down fd 11
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x 
krb5kdc[1560686](info): preauth (encrypted_timestamp) 
verify failure: Preauthentication failed
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x 
krb5kdc[1560686](info): AS_REQ (8 etypes {18 17 20 19 16 
23 25 26}) 10.5.6.17: PREAUTH_FAILED: 
host/dzien.priv.xx.xx.priv.xx.x...@private.xx.xx.private.xx.xx.x 
for 
krbtgt/private.xx.xx.private.xx.x...@private.xx.xx.private.xx.xx.x, 
Preauthentication failed
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x 
krb5kdc[1560686](info): closing down fd 11
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x 
krb5kdc[1560681](info): AS_REQ (8 etypes {18 17 20 19 16 
23 25 26}) 10.5.6.17: NEEDED_PREAUTH: 
ad...@private.xx.xx.private.xx.xx.x for 
krbtgt/private.xx.xx.private.xx.x...@private.xx.xx.private.xx.xx.x, 
Additional pre-authentication required
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x 
krb5kdc[1560681](info): closing down fd 11
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x 
krb5kdc[1560686](info): AS_REQ (8 etypes {18 17 20 19 16 
23 25 26}) 10.5.6.17: ISSUE: authtime 1515250943, etypes 
{rep=18 tkt=18 ses=18}, 
ad...@private.xx.xx.private.xx.xx.x for 
krbtgt/private.xx.xx.private.xx.x...@private.xx.xx.private.xx.xx.x 

Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x 
krb5kdc[1560686](info): closing down fd 11
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x 
krb5kdc[1560686](info): TGS_REQ (8 etypes {18 17 20 19 16 
23 25 26}) 10.5.6.17: ISSUE: authtime 1515250943, etypes 
{rep=18 tkt=18 ses=18}, 
ad...@private.xx.xx.private.xx.xx.x for 
ldap/swir.priv.xx.xx.priv.xx.x...@private.xx.xx.private.xx.xx.x 

Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x 
krb5kdc[1560686](info): closing down fd 11
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x 
krb5kdc[1560686](info): TGS_REQ (8 etypes {18 17 20 19 16 
23 25 26}) 10.5.6.17: ISSUE: authtime 1515250943, etypes 
{rep=18 tkt=18 ses=18}, 
ad...@private.xx.xx.private.xx.xx.x for 
HTTP/swir.priv.xx.xx.priv.xx.x...@private.xx.xx.private.xx.xx.x 


-- end

But after many tries(randomly) suddenly it would succeed. 
Client said to use  --force-join.

VERSION: 4.5.0, API_VERSION: 2.228

What can a problem?

regards, L.
___
FreeIPA-users mailing list -- 
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorahosted.org


Hi,

what is the content of /etc/krb5.conf on your client? Does 
it contain "includedir /etc/krb5.conf.d/" and if it is the 
case, what is the content of the included files?


During the client installation, a temp krb5.conf is 
created and also contains "includedir /etc/krb5.conf.d/". 
If there are snippets in this directory which define 
parameters for the IPA realm, then the parameters might be 
conflicting with the ones needed by the installer.


Flo


I try to make sure that I do clean re-install, thus I do first:

$ yum remove -y `rpm -qa ipa* 389*` pki-base krb5-pkinit 
krb5-server krb5-workstation ipa-python certmonger


then I install IPA, at this point there is already a 
/etc/krb5.conf.d/ipa-certauth created, before any -install 
is run, but there is no "include" in /etc/krb5.conf.

In /etc/krb5.conf.d/ipa-certauth

[plugins]
 certauth = {
  module = ipakdb:kdb/ipadb.so
  enable_only = ipakdb
 }

So, should I remove that /etc/krb5.conf.d/ipa-certauth 
before client installation?

I did, even then client installation fails the same way.
Like I said(maybe most importantly), it would 
suddenly(randomly?) succeed after a number of tries - why?


Probably one thing I should mention: I have a IPA 
domain/realm already on the network. I've set up another 
separate server(master fist) for the same domain and now I'm 
trying to install a client to that new "stand-alone" server.
(details on reason of doing something this weird I'd not go 
into just yet)
As I understand it, because

[Freeipa-users] Re: Expired certificate problem

2018-01-08 Thread Giulio Casella via FreeIPA-users 



Il 08/01/2018 17:26, Rob Crittenden ha scritto:

Giulio Casella via FreeIPA-users wrote:

You need to stop ntpd, use date to go back when the web server cert is
still valid, then restart certmonger. That generally will do it.


Hi Rob,
I already tried with date few hours before expiration, with no luck: 
certmonger cannot perform cert update.


Queued requests remain in "SUBMITTING" status, I tried to launch 
certmonger in foreground (-d 10), here's a snippet of the output:


2018-01-08 01:17:08 [6000] Request9('20171205091409') ends in state 
'HAVE_CSR'

2018-01-08 01:17:08 [6000] Stopped Request9('20171205091409').
2018-01-08 01:17:09 [6235] Read value "0" from 
"/proc/sys/crypto/fips_enabled".

2018-01-08 01:17:09 [6235] Not attempting to set NSS FIPS mode.
2018-01-08 01:17:09 [6235] Skipping NSS internal slot (NSS Generic 
Crypto Services).

2018-01-08 01:17:09 [6235] Found token 'NSS Certificate DB'.
2018-01-08 01:17:09 [6235] Located a certificate with the key's nickname 
("Server-Cert").

2018-01-08 01:17:09 [6235] Located its private key.
2018-01-08 01:17:09 [6235] Recovered public key from private key.
2018-01-08 01:17:09 [6235] Key is an RSA key.
2018-01-08 01:17:09 [6235] Key size is 2048.
2018-01-08 01:17:10 [6251] Read value "0" from 
"/proc/sys/crypto/fips_enabled".

2018-01-08 01:17:10 [6251] Not attempting to set NSS FIPS mode.
2018-01-08 01:17:10 [6251] Found token 'NSS Generic Crypto Services'.
2018-01-08 01:17:10 [6251] Token is named "NSS Generic Crypto Services", 
not "NSS Certificate DB", skipping.

2018-01-08 01:17:10 [6251] Found token 'NSS Certificate DB'.
2018-01-08 01:17:10 [6251] Located the certificate "Server-Cert".
2018-01-08 01:17:10 [6251] Read value "0" from 
"/proc/sys/crypto/fips_enabled".

2018-01-08 01:17:10 [6251] Not attempting to set NSS FIPS mode.
2018-01-08 01:17:10 [6000] Request9('20171205091409') starts in state 
'HAVE_KEYINFO'
2018-01-08 01:17:10 [6000] Request9('20171205091409') moved to state 
'NEED_CSR'

2018-01-08 01:17:10 [6000] Will revisit Request9('20171205091409') now.
2018-01-08 01:17:10 [6000] Started Request9('20171205091409').
2018-01-08 01:17:10 [6000] Queuing FD 7 for Read for 
0x561b59c82750:0x561b59c98940.
2018-01-08 01:17:10 [6000] Request9('20171205091409') moved to state 
'GENERATING_CSR'
2018-01-08 01:17:10 [6000] Will revisit Request9('20171205091409') on 
traffic from 27.
2018-01-08 01:17:11 [6263] Read value "0" from 
"/proc/sys/crypto/fips_enabled".

2018-01-08 01:17:11 [6263] Not attempting to set NSS FIPS mode.
2018-01-08 01:17:11 [6263] Skipping NSS internal slot (NSS Generic 
Crypto Services).

2018-01-08 01:17:11 [6263] Found token 'NSS Certificate DB'.
2018-01-08 01:17:11 [6263] Located a certificate with the key's nickname 
("Server-Cert").

2018-01-08 01:17:11 [6263] Located its private key.
2018-01-08 01:17:11 [6263] Recovered public key from private key.
2018-01-08 01:17:11 [6000] Request9('20171205091409') moved to state 
'HAVE_CSR'

2018-01-08 01:17:11 [6000] Will revisit Request9('20171205091409') now.
2018-01-08 01:17:11 [6000] Request9('20171205091409') moved to state 
'NEED_TO_SUBMIT'

2018-01-08 01:17:11 [6000] Will revisit Request9('20171205091409') now.
2018-01-08 01:17:11 [6000] Request9('20171205091409') moved to state 
'SUBMITTING'
2018-01-08 01:17:11 [6000] Will revisit Request9('20171205091409') on 
traffic from 31.

^C2018-01-08 01:17:14 [6000] Got signal 2.
2018-01-08 01:17:14 [6000] Shutting down.

I'm stuck...

Thank you for your time.



rob



Is there a way to force update?

Here's my output of "getcert list":


Number of certificates and requests being tracked: 9.
Request ID '20170915095009':
 status: MONITORING
 stuck: no
 key pair storage:
type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
 certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
 CA: SelfSign
 issuer:
CN=idc01.linux.unicloudidattica.local,O=LINUX.UNICLOUDIDATTICA.LOCAL
 subject:
CN=idc01.linux.unicloudidattica.local,O=LINUX.UNICLOUDIDATTICA.LOCAL
 expires: 2018-09-15 09:50:10 UTC
 principal name:
krbtgt/LINUX.UNICLOUDIDATTICA.LOCAL@LINUX.UNICLOUDIDATTICA.LOCAL
 certificate template/profile: KDCs_PKINIT_Certs
 pre-save command:
 post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
 track: yes
 auto-renew: yes
Request ID '20171205091347':
 status: MONITORING
 stuck: no
 key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
 certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB'
 CA: dogtag-ipa-ca-renew-agent
 issuer: CN=Certificate Authority,O=LINUX.UNICLOUDIDATTICA.LOCAL
 subject: CN=CA Audit,O=LINUX.UNICLOUDIDATTICA.LOCAL
 expires: 2019-11-21 07:19:44 UTC
 key usage:

[Freeipa-users] IPA Password Vault

2018-01-08 Thread Sean Hogan via FreeIPA-users 


  Hello,

 I have recently been looking into the password vault for IPA and would
like to implement however I have not been able to find an answer to a
compliance question on it yet.


   Does the IPA PW vault limit checking out the password for a shared id to
one person at a time?  I am thinking this would ensure that personal
accountability of that ID being used instead of allowing multiple people
checking out the same id password.

RHEL 7.3 IPA 4.4



Sean Hogan






___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Expired certificate problem

2018-01-08 Thread Giulio Casella via FreeIPA-users 

Hi,
I've got a problem with certificate expiration. My setup is a CA-ful IPA 
installation, ipa-server-4.5.0-22 on a CentOS 7 host.


I've been able to run ipa-cacert-manage renew, setting date in the past, 
but server certs (dirsrv and httpd) are not updated.


Is there a way to force update?

Here's my output of "getcert list":


Number of certificates and requests being tracked: 9.
Request ID '20170915095009':
status: MONITORING
stuck: no
key pair storage: 
type=FILE,location='/var/kerberos/krb5kdc/kdc.key'

certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
CA: SelfSign
issuer: 
CN=idc01.linux.unicloudidattica.local,O=LINUX.UNICLOUDIDATTICA.LOCAL
subject: 
CN=idc01.linux.unicloudidattica.local,O=LINUX.UNICLOUDIDATTICA.LOCAL

expires: 2018-09-15 09:50:10 UTC
principal name: 
krbtgt/LINUX.UNICLOUDIDATTICA.LOCAL@LINUX.UNICLOUDIDATTICA.LOCAL

certificate template/profile: KDCs_PKINIT_Certs
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes
Request ID '20171205091347':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert 
cert-pki-ca',token='NSS Certificate DB'

CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=LINUX.UNICLOUDIDATTICA.LOCAL
subject: CN=CA Audit,O=LINUX.UNICLOUDIDATTICA.LOCAL
expires: 2019-11-21 07:19:44 UTC
key usage: digitalSignature,nonRepudiation
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"auditSigningCert cert-pki-ca"

track: yes
auto-renew: yes
Request ID '20171205091349':
status: MONITORING
stuck: no
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'

CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=LINUX.UNICLOUDIDATTICA.LOCAL
subject: CN=OCSP Subsystem,O=LINUX.UNICLOUDIDATTICA.LOCAL
expires: 2019-11-21 07:18:07 UTC
eku: id-kp-OCSPSigning
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"ocspSigningCert cert-pki-ca"

track: yes
auto-renew: yes
Request ID '20171205091350':
status: MONITORING
stuck: no
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'

CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=LINUX.UNICLOUDIDATTICA.LOCAL
subject: CN=CA Subsystem,O=LINUX.UNICLOUDIDATTICA.LOCAL
expires: 2019-11-21 07:19:43 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment

eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"subsystemCert cert-pki-ca"

track: yes
auto-renew: yes
Request ID '20171205091351':
status: MONITORING
stuck: no
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'

CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=LINUX.UNICLOUDIDATTICA.LOCAL
subject: CN=Certificate Authority,O=LINUX.UNICLOUDIDATTICA.LOCAL
expires: 2038-01-08 00:16:58 UTC
key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"caSigningCert cert-pki-ca"

track: yes
auto-renew: yes
Request ID '20171205091352':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key'
certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=LINUX.UNICLOUDIDATTICA.LOCAL
subject: CN=IPA RA,O=LINUX.UNICLOUDIDATTICA.LOCAL
expires: 2019-11-21 07:18:14 UTC

[Freeipa-users] Re: Centos7.4: users not seeing password expired notifications

2018-01-08 Thread Jakub Hrozek via FreeIPA-users 
On Mon, Jan 08, 2018 at 11:27:47AM +0100, Johan Vermeulen wrote:
> Hello All,
> 
> I "ve set up a new machine for this test and increased the log levels to 6.
> Config for Freeipa-client is done with ipa-client-install, I use chrony in
> stead of ntp and Selinux is enabled.
> 
> When user logs in /var/log/secure indicates:
> 
> [root@node1 ~]# tail -f /var/log/secure
> Jan  5 09:27:17 node1 lightdm: pam_sss(lightdm:auth): received for user
> jvanvlasselaer: 7 (Authentication failure)
> Jan  5 09:27:29 node1 lightdm: pam_sss(lightdm:auth): authentication
> failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=jvanvlasselaer
> Jan  5 09:27:29 node1 lightdm: pam_sss(lightdm:auth): received for user
> jvanvlasselaer: 12 (Authentication token is no longer valid; new one
> required)
> Jan  5 09:27:29 node1 lightdm: pam_sss(lightdm:account): User info message:
> Password expired. Change your password now.
> Jan  5 09:27:29 node1 lightdm: pam_unix(lightdm:chauthtok): user
> "jvanvlasselaer" does not exist in /etc/passwd
> 
> But the lightdm gui screen indicates nothing.
> 

> (Fri Jan  5 09:27:29 2018) [sssd[pam]] [pam_dp_process_reply] (0x0200):
> received: [12 (Authenticatietoken is niet langer geldig; nieuwe is
> vereist)][network.cawdekempen.be]
> (Fri Jan  5 09:27:29 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply
> called with result [12]: Authenticatietoken is niet langer geldig; nieuwe
> is vereist.
> (Fri Jan  5 09:27:29 2018) [sssd[pam]] [filter_responses] (0x0100):
> [pam_response_filter] not available, not fatal.
> (Fri Jan  5 09:27:29 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 39

Here I at least see that the message did reach the sssd_pam process and I
don't see anything that would indicate that the message was filtered out
(OTOH, the debugging is not stellar in this area of code..)

I've never used lightdm, did you maybe test with some other login
method, like login to the console or su from another non-root user?

Does it help to increase pam_verbosity in the [pam] section (see man
sssd.conf for a description) ?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Ubuntu -> Fedora and tomcat SetAllPropertiesRule warnings

2018-01-08 Thread David Harvey via FreeIPA-users 
Gentle bump (whilst I remember to nudge this).

TL;DR
Does anyone know the likely implications of error messages such as:

"Setting property 'enableOCSP' to 'false' did not find a matching property."
(then repeated for several other properties)

On 4 January 2018 at 14:52, David Harvey 
wrote:

> Point No.2 Is now sorted. It was the old missing Subject Alternative Name
> extension in certificate problem (which I had only seen with https until
> now!).
> I would still love to know if I need to live in fear of the other errors
> though :)
>
> On 4 January 2018 at 12:25, David Harvey 
> wrote:
>
>> Dear list,
>>
>> In trying to escape from the various issues facing the ubuntu freeipa, I
>> attempted to make the switch to Fedora 26 (same freeipa version 4.4.4).
>>
>> This seemed to go well (adding new replica first, and then replacing the
>> ubuntu based installs), but I notice on my fedora boxes several warnings in
>> /v/l/messages (pasted below).  Firstly, are these harmful, and what might I
>> need to rectify!? I have a half baked theory that this might relate to some
>> of the aspects that were broken in ubuntu and carrying their breakage
>> across to the new platform!
>>
>> Secondly - could they relate to an issue I am seeing where one specific
>> LDAPS client application is failing to verify the ldap server cert (even
>> thought other clients are quite happy talking to it) since the ipa server
>> reinstall?
>>
>> Advice appreciated, thank you in advance!
>>
>> David
>>
>>
>>
>>
>> Jan  4 11:53:09 ipa3 server[1357]: WARNING: Problem with JAR file
>> [/usr/share/pki/server/common/lib/symkey.jar], exists: [false], canRead:
>> [false]
>> Jan  4 11:53:09 ipa3 ntpd[1200]: Soliciting pool server 45.79.111.114
>> Jan  4 11:53:10 ipa3 server[1357]: WARNING: 
>> [SetAllPropertiesRule]{Server/Service/Connector}
>> Setting property 'enableOCSP' to 'false' did not find a matching property.
>> Jan  4 11:53:10 ipa3 server[1357]: WARNING: 
>> [SetAllPropertiesRule]{Server/Service/Connector}
>> Setting property 'ocspResponderURL' to 'http://ipa3.thomac.net:9080/c
>> a/ocsp' did not find a matching property.
>> Jan  4 11:53:10 ipa3 server[1357]: WARNING: 
>> [SetAllPropertiesRule]{Server/Service/Connector}
>> Setting property 'ocspResponderCertNickname' to 'ocspSigningCert
>> cert-pki-ca' did not find a matching property.
>> Jan  4 11:53:10 ipa3 server[1357]: WARNING: 
>> [SetAllPropertiesRule]{Server/Service/Connector}
>> Setting property 'ocspCacheSize' to '1000' did not find a matching property.
>> Jan  4 11:53:10 ipa3 server[1357]: WARNING: 
>> [SetAllPropertiesRule]{Server/Service/Connector}
>> Setting property 'ocspMinCacheEntryDuration' to '60' did not find a
>> matching property.
>> Jan  4 11:53:10 ipa3 server[1357]: WARNING: 
>> [SetAllPropertiesRule]{Server/Service/Connector}
>> Setting property 'ocspMaxCacheEntryDuration' to '120' did not find a
>> matching property.
>> Jan  4 11:53:10 ipa3 server[1357]: WARNING: 
>> [SetAllPropertiesRule]{Server/Service/Connector}
>> Setting property 'ocspTimeout' to '10' did not find a matching property.
>> Jan  4 11:53:10 ipa3 server[1357]: WARNING: 
>> [SetAllPropertiesRule]{Server/Service/Connector}
>> Setting property 'strictCiphers' to 'true' did not find a matching property.
>> Jan  4 11:53:10 ipa3 server[1357]: WARNING: 
>> [SetAllPropertiesRule]{Server/Service/Connector}
>> Setting property 'sslOptions' to 'ssl2=false,ssl3=false,tls=true' did
>> not find a matching property.
>> Jan  4 11:53:10 ipa3 server[1357]: WARNING: 
>> [SetAllPropertiesRule]{Server/Service/Connector}
>> Setting property 'ssl2Ciphers' to '-SSL2_RC4_128_WITH_MD5,-SSL2_
>> RC4_128_EXPORT40_WITH_MD5,-SSL2_RC2_128_CBC_WITH_MD5,-SSL2_
>> RC2_128_CBC_EXPORT40_WITH_MD5,-SSL2_DES_64_CBC_WITH_MD5,-
>> SSL2_DES_192_EDE3_CBC_WITH_MD5' did not find a matching property.
>> Jan  4 11:53:10 ipa3 server[1357]: WARNING: 
>> [SetAllPropertiesRule]{Server/Service/Connector}
>> Setting property 'ssl3Ciphers' to '-SSL3_FORTEZZA_DMS_WITH_NULL_
>> SHA,-SSL3_FORTEZZA_DMS_WITH_RC4_128_SHA,+SSL3_RSA_WITH_RC4_
>> 128_SHA,-SSL3_RSA_EXPORT_WITH_RC4_40_MD5,+SSL3_RSA_WITH_
>> 3DES_EDE_CBC_SHA,-SSL3_RSA_WITH_DES_CBC_SHA,-SSL3_RSA_
>> EXPORT_WITH_RC2_CBC_40_MD5,-SSL3_FORTEZZA_DMS_WITH_FORTEZZ
>> A_CBC_SHA,-SSL_RSA_FIPS_WITH_DES_CBC_SHA,+SSL_RSA_FIPS_
>> WITH_3DES_EDE_CBC_SHA,-SSL3_RSA_WITH_NULL_MD5,-TLS_RSA_
>> EXPORT1024_WITH_RC4_56_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_
>> CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA' did not find a matching
>> property.
>> Jan  4 11:53:10 ipa3 server[1357]: WARNING: 
>> [SetAllPropertiesRule]{Server/Service/Connector}
>> Setting property 'tlsCiphers' to '-TLS_ECDH_ECDSA_WITH_AES_128_
>> CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_
>> WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
>> +TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_
>> AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+
>>

[Freeipa-users] Re: replica install fails: CA_UNREACHABLE

2018-01-08 Thread Florence Blanc-Renaud via FreeIPA-users 

On 01/06/2018 08:54 PM, lejeczek via FreeIPA-users wrote:


hi

I'm trying to install replica, process fails:
..
   [3/5]: creating anonymous principal
   [4/5]: starting the KDC
   [5/5]: configuring KDC to start on boot
Done configuring Kerberos KDC (krb5kdc).
Configuring kadmin
   [1/2]: starting kadmin
   [2/2]: configuring kadmin to start on boot
Done configuring kadmin.
Configuring directory server (dirsrv)
   [1/3]: configuring TLS for DS instance
   [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
Your system may be partly configured.
..
-- end

and in intall log file:
..
2018-01-06T13:50:29Z DEBUG args=/usr/bin/certutil -d 
/etc/dirsrv/slapd-PRIVATE-xx.xx.PRIVATE-CAM-AC-UK/ -A -n 
PRIVATE.xx.xx.PRIVATE.xx.xx.x IPA CA -t CT,C,C -a -f 
/etc/dirsrv/slapd-PRIVATE-xx.xx.PRIVATE-CAM-AC-UK/pwdfile.txt

2018-01-06T13:50:29Z DEBUG Process finished, return code=0
2018-01-06T13:50:29Z DEBUG stdout=
2018-01-06T13:50:29Z DEBUG stderr=
2018-01-06T13:50:30Z DEBUG certmonger request is in state 
dbus.String(u'NEWLY_ADDED_READING_CERT', variant_level=1)
2018-01-06T13:50:35Z DEBUG certmonger request is in state 
dbus.String(u'CA_UNREACHABLE', variant_level=1)

2018-01-06T13:50:35Z DEBUG Traxx.ck (most recent call last):
   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", 
line 504, in start_creation

     run_step(full_msg, method)
   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", 
line 494, in run_step

     method()
   File 
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 
824, in __enable_ssl

     post_command=cmd)
   File "/usr/lib/python2.7/site-packages/ipalib/install/certmonger.py", 
line 317, in request_and_wait_for_cert

     raise RuntimeError("Certificate issuance failed ({})".format(state))
RuntimeError: Certificate issuance failed (CA_UNREACHABLE)

2018-01-06T13:50:35Z DEBUG   [error] RuntimeError: Certificate issuance 
failed (CA_UNREACHABLE)
2018-01-06T13:50:35Z DEBUG   File 
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in 
execute

     return_value = self.run()
   File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", 
line 333, in run

     cfgr.run()
   File "/usr/lib/python2.7/site-
...
-- end

Would this be that new candidate's problem or some communication issues 
with existing server? Client installed (kind of)okey though.

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


Hi,

the replica installer is communicating with the local certmonger daemon 
to request SSL certificates. Then certmonger connects to the IPA master 
(httpd process), and in turn IPA master server communicates with Dogtag 
to request the certificate.


As you can see, there are a lot of processes involved, and the issue 
could come from communication issues between all of them. We need to 
identify which step is failing.


Can you check:
- the output of getcert list on the client? It may contain a more 
detailed message for the certificate issuance failure
- if tomcat is running on the master? systemctl status 
pki-tomcatd@pki-tomcat
- if the client managed to contact IPA master? Look for a line with 
cert_request on the master's log /var/log/httpd/error_log, and for 
possible error messages related. If the line is present, the client 
successfully sent its cert request, meaning that the communication was 
properly established.
- if dogtag received the certificate request? IPA master is using 
/etc/ipa/ca.crt and /var/lib/ipa/ra-agent.{key|pem} to authenticate to 
Dogtag. The authentication logs in /var/log/pki/pki-tomcat/ca/debug 
should display something like:


[date][ajp-bio-127.0.0.1-8009-exec-1]: PKIRealm: Authenticating 
certificate chain:
[date][ajp-bio-127.0.0.1-8009-exec-1]: PKIRealm.getAuditUserfromCert: 
certUID=CN=IPA RA, O=DOMAIN.IPA.COM
[date][ajp-bio-127.0.0.1-8009-exec-1]: PKIRealm:   CN=IPA RA, 
O=DOMAIN.IPA.COM

[date][ajp-bio-127.0.0.1-8009-exec-1]: CertUserDBAuth: started
[date][ajp-bio-127.0.0.1-8009-exec-1]: CertUserDBAuth: Retrieving client 
certificate
[date][ajp-bio-127.0.0.1-8009-exec-1]: CertUserDBAuth: Got client 
certificate


and the cert request:
[date][ajp-bio-127.0.0.1-8009-exec-4]: EnrollProfile: createRequests: begins
[date][ajp-bio-127.0.0.1-8009-exec-4]: Start parsePKCS10(): -BEGIN 
CERTIFICATE REQUEST-


The most common issues are pki-tomcatd not started because of the 
certificate 'subsystemCert cert-pki-ca' that expired, or communication 
issues between IPA server and Dogtag (the cert in 
/var/lib/ipa/ra-agent.{key|pem} is expired).


HTH,
Flo
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ipa-client-install - error - Failed to obtain host TGT: Major (851968)

2018-01-08 Thread Florence Blanc-Renaud via FreeIPA-users 

On 01/06/2018 08:51 PM, lejeczek via FreeIPA-users wrote:


hi everyone

I'm trying a client, when I do:

$ ipa-client-install --no-ntp --force-join
Discovery was successful!
...
Also note that following ports are necessary for ipa-client working 
properly after enrollment:

  TCP: 464
  UDP: 464, 123 (if NTP enabled)
Failed to obtain host TGT: Major (851968): Unspecified GSS failure. 
Minor code may provide more information, Minor (2529638936): 
Preauthentication failed

Installation failed. Rolling back changes.
-- end

At server's end(one single server in domain):
..
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560685](info): 
closing down fd 11
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): 
AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.5.6.17: NEEDED_PREAUTH: 
host/dzien.priv.xx.xx.priv.xx.x...@private.xx.xx.private.xx.xx.x for 
krbtgt/private.xx.xx.private.xx.x...@private.xx.xx.private.xx.xx.x, 
Additional pre-authentication required
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): 
closing down fd 11
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): 
preauth (encrypted_timestamp) verify failure: Preauthentication failed
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): 
AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.5.6.17: PREAUTH_FAILED: 
host/dzien.priv.xx.xx.priv.xx.x...@private.xx.xx.private.xx.xx.x for 
krbtgt/private.xx.xx.private.xx.x...@private.xx.xx.private.xx.xx.x, 
Preauthentication failed
Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): 
closing down fd 11
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560681](info): 
AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.5.6.17: NEEDED_PREAUTH: 
ad...@private.xx.xx.private.xx.xx.x for 
krbtgt/private.xx.xx.private.xx.x...@private.xx.xx.private.xx.xx.x, 
Additional pre-authentication required
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560681](info): 
closing down fd 11
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): 
AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.5.6.17: ISSUE: authtime 
1515250943, etypes {rep=18 tkt=18 ses=18}, 
ad...@private.xx.xx.private.xx.xx.x for 
krbtgt/private.xx.xx.private.xx.x...@private.xx.xx.private.xx.xx.x
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): 
closing down fd 11
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): 
TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.5.6.17: ISSUE: authtime 
1515250943, etypes {rep=18 tkt=18 ses=18}, 
ad...@private.xx.xx.private.xx.xx.x for 
ldap/swir.priv.xx.xx.priv.xx.x...@private.xx.xx.private.xx.xx.x
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): 
closing down fd 11
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): 
TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.5.6.17: ISSUE: authtime 
1515250943, etypes {rep=18 tkt=18 ses=18}, 
ad...@private.xx.xx.private.xx.xx.x for 
HTTP/swir.priv.xx.xx.priv.xx.x...@private.xx.xx.private.xx.xx.x

-- end

But after many tries(randomly) suddenly it would succeed. Client said to 
use  --force-join.

VERSION: 4.5.0, API_VERSION: 2.228

What can a problem?

regards, L.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


Hi,

what is the content of /etc/krb5.conf on your client? Does it contain 
"includedir /etc/krb5.conf.d/" and if it is the case, what is the 
content of the included files?


During the client installation, a temp krb5.conf is created and also 
contains "includedir /etc/krb5.conf.d/". If there are snippets in this 
directory which define parameters for the IPA realm, then the parameters 
might be conflicting with the ones needed by the installer.


Flo
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org