Re: [Freeipa-users] another certmonger question

[Natxo Asenjo]

hi,

On Mon, Oct 3, 2016 at 5:32 PM, Rob Crittenden  wrote:

>
> usercertificate is a multi-valued LDAP attribute but IPA 3.0 only really
> operates on the "first" value returned (I didn't look at more recent
> versions). In this case it is the 267976717 cert. The other certs shown
> without details are for the other serial numbers that cert-find is reporting



> I can't see a way that this first usercertificate value isn't revoked and
> removed upon renewal so I can't quite figure out how you got into this
> state (and so easily as I understand it). I wasn't able to reproduce it
> myself. Do you have any idea how wide-spread this is in your infrastructure?
>
> I can see that once in this state that any "extra" certs would just be
> stuck there, never to be revoked.
>

This is happening all over the place.

I guess I will have to script this: retrieve the usercertificate attribute
of the host computers, get their 'not before/not after' and serial number
values, and revoke the oldest valid ones in case there is more than one
valid one. This should not be very hard.


I need to monitor the certmonger status as well, a nagios plugin should do
the trick.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] another certmonger question

[Natxo Asenjo]

On Fri, Sep 30, 2016 at 10:45 AM, Rob Crittenden <rcrit...@redhat.com>
wrote:

> Natxo Asenjo wrote:
>
>>
>>
>> On Thu, Sep 29, 2016 at 1:16 PM, Rob Crittenden <rcrit...@redhat.com
>> <mailto:rcrit...@redhat.com>> wrote:
>>
>> Natxo Asenjo wrote:
>>
>>
>>
>> On Tue, Sep 27, 2016 at 1:42 PM, Rob Crittenden
>> <rcrit...@redhat.com <mailto:rcrit...@redhat.com>
>> <mailto:rcrit...@redhat.com <mailto:rcrit...@redhat.com>>> wrote:
>>
>>
>>  It's hard to say, it may in fact not be a problem.
>>
>>  It is really a matter of what service the certificate(s)
>> are related
>>  to. I'd look at the serial numbers and then correlate those
>> to the
>>  issued certificates.
>>
>>  I'd also do a service-find on the hostname to see if any
>> services
>>  have certificates issued and with what serial numbers.
>>
>>
>> I agree, it could be that. But just for testing I have created a
>> vm,
>> joined it to the domain and resubmitted the certificate.
>>
>> Now there are two valid host certificates with the same subject:
>>
>>
>>$ ipa cert-find --subject=throwaway.unix.iriszorg.nl
>> <http://throwaway.unix.iriszorg.nl>
>> <http://throwaway.unix.iriszorg.nl
>> <http://throwaway.unix.iriszorg.nl>>
>> --
>> 2 certificates matched
>> --
>> Serial number (hex): 0x3FFE0002
>> Serial number: 1073610754
>> Status: VALID
>> Subject: CN=throwaway.unix.iriszorg.nl
>> <http://throwaway.unix.iriszorg.nl>
>> <http://throwaway.unix.iriszorg.nl
>> <http://throwaway.unix.iriszorg.nl>>,O=UNIX.IRISZORG.NL
>> <http://UNIX.IRISZORG.NL>
>> <http://UNIX.IRISZORG.NL>
>>
>> Serial number (hex): 0x3FFE0003
>> Serial number: 1073610755
>> Status: VALID
>> Subject: CN=throwaway.unix.iriszorg.nl
>> <http://throwaway.unix.iriszorg.nl>
>> <http://throwaway.unix.iriszorg.nl
>> <http://throwaway.unix.iriszorg.nl>>,O=UNIX.IRISZORG.NL
>> <http://UNIX.IRISZORG.NL>
>> <http://UNIX.IRISZORG.NL>
>> 
>> Number of entries returned 2
>> 
>>
>>
>> So it certmonger in this centos 6.8 32bit host is renewing but not
>> having the old certificate revoked.
>>
>>
>> I'd check the Apache log to find the cert_request call to see if you
>> can see if there are any issues raised. It should be doing a
>> cert_revoke at the same time.
>>
>> Can you should how this certificate is being tracked?
>>
>>
>> sure:
>>
>> $ sudo getcert list
>> Number of certificates and requests being tracked: 1.
>> Request ID '20160929100945':
>>  status: MONITORING
>>  stuck: no
>>  key pair storage:
>> type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate -
>> throwaway.unix.iriszorg.nl
>> <http://throwaway.unix.iriszorg.nl>',token='NSS Certificate DB'
>>  certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA
>> Machine Certificate - throwaway.unix.iriszorg.nl
>> <http://throwaway.unix.iriszorg.nl>',token='NSS Certificate DB'
>>  CA: IPA
>>  issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL
>> <http://UNIX.IRISZORG.NL>
>>  subject: CN=throwaway.unix.iriszorg.nl
>> <http://throwaway.unix.iriszorg.nl>,O=UNIX.IRISZORG.NL
>> <http://UNIX.IRISZORG.NL>
>>  expires: 2018-09-30 10:13:17 UTC
>>  principal name: host/throwaway.unix.iriszorg...@unix.iriszorg.nl
>> <mailto:throwaway.unix.iriszorg...@unix.iriszorg.nl>
>>  key usage:
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>  eku: id-kp-serverAuth,id-kp-clientAuth
>>  pre-save command:
>>  post-save command:
>>  track: yes
>>  auto-renew: yes
>>
>> now, let's resubmit:
>>
>> $ sudo ipa-getcert resubmit -i 20160929100945
>> Resubmitting "20160929100945" to "IPA".
>> [jose.admin@thro

Re: [Freeipa-users] another certmonger question

[Natxo Asenjo]

On Thu, Sep 29, 2016 at 1:16 PM, Rob Crittenden <rcrit...@redhat.com> wrote:

> Natxo Asenjo wrote:
>
>>
>>
>> On Tue, Sep 27, 2016 at 1:42 PM, Rob Crittenden <rcrit...@redhat.com
>> <mailto:rcrit...@redhat.com>> wrote:
>>
>>
>> It's hard to say, it may in fact not be a problem.
>>
>> It is really a matter of what service the certificate(s) are related
>> to. I'd look at the serial numbers and then correlate those to the
>> issued certificates.
>>
>> I'd also do a service-find on the hostname to see if any services
>> have certificates issued and with what serial numbers.
>>
>>
>> I agree, it could be that. But just for testing I have created a vm,
>> joined it to the domain and resubmitted the certificate.
>>
>> Now there are two valid host certificates with the same subject:
>>
>>
>>   $ ipa cert-find --subject=throwaway.unix.iriszorg.nl
>> <http://throwaway.unix.iriszorg.nl>
>> --
>> 2 certificates matched
>> --
>>Serial number (hex): 0x3FFE0002
>>Serial number: 1073610754
>>Status: VALID
>>Subject: CN=throwaway.unix.iriszorg.nl
>> <http://throwaway.unix.iriszorg.nl>,O=UNIX.IRISZORG.NL
>> <http://UNIX.IRISZORG.NL>
>>
>>Serial number (hex): 0x3FFE0003
>>Serial number: 1073610755
>>Status: VALID
>>Subject: CN=throwaway.unix.iriszorg.nl
>> <http://throwaway.unix.iriszorg.nl>,O=UNIX.IRISZORG.NL
>> <http://UNIX.IRISZORG.NL>
>> 
>> Number of entries returned 2
>> 
>>
>>
>> So it certmonger in this centos 6.8 32bit host is renewing but not
>> having the old certificate revoked.
>>
>
> I'd check the Apache log to find the cert_request call to see if you can
> see if there are any issues raised. It should be doing a cert_revoke at the
> same time.
>
> Can you should how this certificate is being tracked?
>

sure:

$ sudo getcert list
Number of certificates and requests being tracked: 1.
Request ID '20160929100945':
status: MONITORING
stuck: no
key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA
Machine Certificate - throwaway.unix.iriszorg.nl',token='NSS Certificate DB'
certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine
Certificate - throwaway.unix.iriszorg.nl',token='NSS Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL
subject: CN=throwaway.unix.iriszorg.nl,O=UNIX.IRISZORG.NL
expires: 2018-09-30 10:13:17 UTC
principal name: host/throwaway.unix.iriszorg...@unix.iriszorg.nl
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes

now, let's resubmit:

$ sudo ipa-getcert resubmit -i 20160929100945
Resubmitting "20160929100945" to "IPA".
[jose.admin@throwaway ~]$ sudo getcert list
Number of certificates and requests being tracked: 1.
Request ID '20160929100945':
status: MONITORING
stuck: no
key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA
Machine Certificate - throwaway.unix.iriszorg.nl',token='NSS Certificate DB'
certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine
Certificate - throwaway.unix.iriszorg.nl',token='NSS Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL
subject: CN=throwaway.unix.iriszorg.nl,O=UNIX.IRISZORG.NL
expires: 2018-09-30 20:41:28 UTC
principal name: host/throwaway.unix.iriszorg...@unix.iriszorg.nl
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes

so it has been successfully renewed.

In the access_log of the kdc I see this:

172.20.4.228 - - [29/Sep/2016:22:41:27 +0200] "POST
https://kdc03.unix.iriszorg.nl:443/ca/eeca/ca/profileSubmitSSLClient
HTTP/1.1" 200 1913
172.20.6.81 - host/throwaway.unix.iriszorg...@unix.iriszorg.nl
[29/Sep/2016:22:41:27 +0200] "POST /ipa/xml HTTP/1.1" 200 2929

and in the error_log:
[Thu Sep 29 22:41:28.626669 2016] [:error] [pid 4617] ipa: INFO:
[xmlserver] host/throwaway.unix.iriszorg...@unix.iriszorg.nl:
cert_request(u'MIID6DCCAtACAQAwQDEZMBcGA1UEChMQVU5JWC5JUklTWk9SRy5OTDEjMCEGA1UEAxMadGhyb3

Re: [Freeipa-users] Replica created with expired certs

[Natxo Asenjo]

hi,

On Thu, Sep 29, 2016 at 2:11 PM, Rob Crittenden <rcrit...@redhat.com> wrote:

> Natxo Asenjo wrote:
>
>> hi Jim,
>>
>> On Thu, Sep 29, 2016 at 7:37 AM, Jim Richard <jrich...@placeiq.com
>> <mailto:jrich...@placeiq.com>> wrote:
>>
>> Thanks Rob, that worked.
>>
>> Still on the subject of certs, any idea how to solve this error:
>>
>> Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The
>> certificate/key database is in an old, unsupported format.
>>
>> I see that in the gui when querying hosts as well as from cli when I
>> ipa-show or ipa-find
>>
>>
>> I have had this too, and we did not find a solution (search my recent
>> posts on the archives). As a workaround I have created replicas and
>> decommissioned the older replicas.
>>
>
> On the one hand I'm glad this fixed it for you. On the other it is a
> rather unsatisfying answer. Unfortunately NSS doesn't always provide the
> most context with its error messages. This error is usually seen when one
> tries to open a non-existent database, which in this case is a very strange
> thing, especially since it goes from working to non-working in the same
> apache process over a few minutes.
>

I totally agree. I did not have enough time to investigate it further
because I'm changing jobs, so I really wanted to leave a working situation
behind me.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] another certmonger question

[Natxo Asenjo]

On Tue, Sep 27, 2016 at 1:42 PM, Rob Crittenden  wrote:

>
> It's hard to say, it may in fact not be a problem.
>
> It is really a matter of what service the certificate(s) are related to.
> I'd look at the serial numbers and then correlate those to the issued
> certificates.
>
> I'd also do a service-find on the hostname to see if any services have
> certificates issued and with what serial numbers.
>

I agree, it could be that. But just for testing I have created a vm, joined
it to the domain and resubmitted the certificate.

Now there are two valid host certificates with the same subject:


 $ ipa cert-find --subject=throwaway.unix.iriszorg.nl
--
2 certificates matched
--
  Serial number (hex): 0x3FFE0002
  Serial number: 1073610754
  Status: VALID
  Subject: CN=throwaway.unix.iriszorg.nl,O=UNIX.IRISZORG.NL

  Serial number (hex): 0x3FFE0003
  Serial number: 1073610755
  Status: VALID
  Subject: CN=throwaway.unix.iriszorg.nl,O=UNIX.IRISZORG.NL

Number of entries returned 2



So it certmonger in this centos 6.8 32bit host is renewing but not having
the old certificate revoked.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Replica created with expired certs

[Natxo Asenjo]

hi Jim,

On Thu, Sep 29, 2016 at 7:37 AM, Jim Richard  wrote:

> Thanks Rob, that worked.
>
> Still on the subject of certs, any idea how to solve this error:
>
> Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key
> database is in an old, unsupported format.
>
> I see that in the gui when querying hosts as well as from cli when I
> ipa-show or ipa-find
>

I have had this too, and we did not find a solution (search my recent posts
on the archives). As a workaround I have created replicas and
decommissioned the older replicas.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] another certmonger question

[Natxo Asenjo]

hi,

after our upgrade from centos 6.8 to 7.2, when I renew a certificate using
ipa-getcert resubmit -i xx the certificate is properly renewed, but the
info on ipa host-show still shows the old certificate info. Is this normal?

$ sudo getcert list | grep expires
expires: 2018-09-27 19:46:03 UTC

so that certificate has successfully been renewed, but this is the host's
info:

$ ipa host-show hostname | grep -i after
 Not After: Wed Jun 07 14:30:47 2017 UTC

and I see there as well more than one certificate for that host:

$ ipa cert-find --subject=hostname
--
5 certificates matched
--
  Serial number (hex): 0xFF90008
  Serial number: 267976712
  Status: VALID
  Subject: CN=hostname.unix.iriszorg.nl,O=UNIX.IRISZORG.NL

  Serial number (hex): 0xFF90009
  Serial number: 267976713
  Status: VALID
  Subject: CN=hostname.unix.iriszorg.nl,O=UNIX.IRISZORG.NL

  Serial number (hex): 0xFF9000A
  Serial number: 267976714
  Status: VALID
  Subject: CN=hostname.unix.iriszorg.nl,O=UNIX.IRISZORG.NL

  Serial number (hex): 0xFFF001D
  Serial number: 268369949
  Status: REVOKED_EXPIRED
  Subject: CN=hostname.unix.iriszorg.nl,O=UNIX.IRISZORG.NL

  Serial number (hex): 0xFFF0093
  Serial number: 268370067
  Status: REVOKED
  Subject: CN=hostname.unix.iriszorg.nl,O=UNIX.IRISZORG.NL

Number of entries returned 5


And three of them are still valid. As a comparison, another hosts which was
installed about the same time also has 5 certificates, but 4 are revoked
and the expires info of getcert list and of the valid certificate are the
same.

So how do I correct this?
-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] replicas removed, but incorrectly

[Natxo Asenjo]

hi,

or do I need to remove:

dn:
cn=cloneAgreement1-kdc03.unix.iriszorg.nl-pki-tomcat,cn=replica,cn=o\3Dipa
 ca,cn=mapping tree,cn=config

because it has this:
nsds5replicaLastUpdateStatus: -1 Unable to acquire replicaLDAP error: Can't
co
 ntact LDAP server
nsds5replicaUpdateInProgress: FALSE

and this:

dn:
cn=masterAgreement1-kdc04.unix.iriszorg.nl-pki-tomcat,cn=replica,cn=o\3Dip
 aca,cn=mapping tree,cn=config

nsds5replicaLastUpdateStatus: -1 Incremental update has failed and requires
ad
 ministrator actionLDAP error: Can't contact LDAP server



On Mon, Sep 26, 2016 at 3:32 PM, Natxo Asenjo <natxo.ase...@gmail.com>
wrote:

> hi,
>
>
>
> On Mon, Sep 26, 2016 at 3:06 PM, Ludwig Krispenz <lkris...@redhat.com>
> wrote:
>
>>
>> On 09/26/2016 02:56 PM, Natxo Asenjo wrote:
>>
>>
>> so the command has not been successful in the kdc03. in the dirsrv errors
>> log  I see:
>>
>> [26/Sep/2016:14:50:54 +0200] NSMMReplicationPlugin - CleanAllRUV Task
>> (rid 71): Not all replicas online, retrying in 640 seconds...
>>
>> this looks like there is still a replication agreement to one of the no
>> longer existing servers.
>>
>> can you search for "... -b "cn=config" 
>> "objectclass=nsds5replicationagreement"
>>
>>
>> and remove the ones no longer needed.
>>
>
> allow me to post the output of both commands as separate files
>
> I am not really sure which one I need to remove.
>
> --
> Groeten,
> natxo
>



-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] replicas removed, but incorrectly

[Natxo Asenjo]

hi,



On Mon, Sep 26, 2016 at 3:06 PM, Ludwig Krispenz <lkris...@redhat.com>
wrote:

>
> On 09/26/2016 02:56 PM, Natxo Asenjo wrote:
>
>
> so the command has not been successful in the kdc03. in the dirsrv errors
> log  I see:
>
> [26/Sep/2016:14:50:54 +0200] NSMMReplicationPlugin - CleanAllRUV Task (rid
> 71): Not all replicas online, retrying in 640 seconds...
>
> this looks like there is still a replication agreement to one of the no
> longer existing servers.
>
> can you search for "... -b "cn=config" "objectclass=nsds5replicationagreement"
>
>
> and remove the ones no longer needed.
>

allow me to post the output of both commands as separate files

I am not really sure which one I need to remove.

--
Groeten,
natxo
$ ldapsearch -Z -h kdc03.unix.iriszorg.nl -D "cn=Directory Manager" -W -b "cn=config" "objectclass=nsds5replicationagreement" 
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] replicas removed, but incorrectly

[Natxo Asenjo]

On Mon, Sep 26, 2016 at 1:54 PM, Natxo Asenjo <natxo.ase...@gmail.com>
wrote:

>
>
>
> On Mon, Sep 26, 2016 at 1:50 PM, Ludwig Krispenz <lkris...@redhat.com>
> wrote:
>
>>
>> On 09/26/2016 01:36 PM, Natxo Asenjo wrote:
>>
>> And in my example, the replica id would be 66, 96, 71 and 97, correct?
>>
>> no, I don't think so. you searched 2 times the same host "-h
>> kdc04.unix.iriszorg.nl".
>> you need to search on kdc03 to find the current replicaid of kdc03 and
>> you have to keep it.
>>
>
>
> yes, you are right :(
>
>  $ ldapsearch -Z -h kdc03.unix.iriszorg.nl -D "cn=Directory Manager" -W
> -b "o=ipaca" 
> "(&(objectclass=nstombstone)(nsUniqueId=---))"
> | grep "nsds50ruv\|nsDS5ReplicaId"
> Enter LDAP Password:
> nsDS5ReplicaId: 66
> nsds50ruv: {replicageneration} 50c1015c0060
> nsds50ruv: {replica 66 ldap://kdc03.unix.iriszorg.nl:389}
> 57e23f660042
> nsds50ruv: {replica 1095 ldap://kdc04.unix.iriszorg.nl:389}
> 57e4d75a044700
> nsds50ruv: {replica 96 ldap://kdc01.unix.iriszorg.nl:7389}
> 50c1016c006
> nsds50ruv: {replica 71 ldap://kdc03.unix.iriszorg.nl:389}
> 57e140c70047
> nsds50ruv: {replica 97 ldap://kdc02.unix.iriszorg.nl:7389}
> 50c101680061000
>
>
> so I need to keep 66 and 1095, and run the task on 96, 71 and 97, it would
> seem.
>
> Thanks for spotting my error.
>


ok, so I have now run the commands against both ldap hosts (the kdc03 and
the kdc04), and now I have this:

 # ldapsearch -Z -h kdc04.unix.iriszorg.nl -D "cn=Directory Manager" -W -b
"o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
Enter LDAP Password:
nsDS5ReplicaId: 1095
nsds50ruv: {replicageneration} 50c1015c0060
nsds50ruv: {replica 1095 ldap://kdc04.unix.iriszorg.nl:389}
57e4d75a044700
nsds50ruv: {replica 66 ldap://kdc03.unix.iriszorg.nl:389}
57e23f660042

# ldapsearch -Z -h kdc03.unix.iriszorg.nl -D "cn=Directory Manager" -W -b
"o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
Enter LDAP Password:
nsDS5ReplicaId: 66
nsds50ruv: {replicageneration} 50c1015c0060
nsds50ruv: {replica 66 ldap://kdc03.unix.iriszorg.nl:389}
57e23f660042
nsds50ruv: {replica 1095 ldap://kdc04.unix.iriszorg.nl:389}
57e4d75a044700
nsds50ruv: {replica 96 ldap://kdc01.unix.iriszorg.nl:7389}
50c1016c006
nsds50ruv: {replica 71 ldap://kdc03.unix.iriszorg.nl:389}
57e140c70047
nsds50ruv: {replica 97 ldap://kdc02.unix.iriszorg.nl:7389}
50c101680061000

so the command has not been successful in the kdc03. in the dirsrv errors
log  I see:

[26/Sep/2016:14:50:54 +0200] NSMMReplicationPlugin - CleanAllRUV Task (rid
71): Not all replicas online, retrying in 640 seconds...
[26/Sep/2016:14:51:00 +0200] slapi_ldap_bind - Error: could not send
startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport
endpoint is not connected)

but those replicas are gone (decommissioned). So how can I remove them?


-- 
regards,
Natxo





-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] replicas removed, but incorrectly

[Natxo Asenjo]

On Mon, Sep 26, 2016 at 1:50 PM, Ludwig Krispenz <lkris...@redhat.com>
wrote:

>
> On 09/26/2016 01:36 PM, Natxo Asenjo wrote:
>
> hi,
>
> I recently upgraded a centos 6.8 realm to centos 7.2 and it almost went
> correctly.
>
> Now I see some errors in /var/log/dirsrv/slapd-INSTANCENAME/errors
>
> 26/Sep/2016:13:20:15 +0200] attrlist_replace - attr_replace
> (nsslapd-referral, ldap://kdc03.unix.iriszorg.nl:389/o%3Dipaca) failed
>
> and according to http://www.freeipa.org/page/Troubleshooting#Replication_
> issues this points to a ruv problem.
>
> So let's enumerate.
>
> We had kdc01 replicating to kdc02 (both 6.8).
>
> Then I created a replica from kdc01 to kdc03 (running 7.2).
>
> And from kdc03 to kdc04 (both 7.2).
>
> kdc01 and kdc02 are decommissioned, but kdc02 still shows in both kdc03
> and kdc04:
>
> $ ipa-replica-manage list
> kdc02.unix.iriszorg.nl: master
> kdc03.unix.iriszorg.nl: master
> kdc04.unix.iriszorg.nl: master
>
> and in
>
> $ ipa-csreplica-manage list
> Directory Manager password:
> kdc02.unix.iriszorg.nl: master
> kdc03.unix.iriszorg.nl: master
> kdc04.unix.iriszorg.nl: master
>
>
> >From kdc03:
> $ ldapsearch -Z -h kdc04.unix.iriszorg.nl -D "cn=Directory Manager" -W -b
> "o=ipaca" 
> "(&(objectclass=nstombstone)(nsUniqueId=---))"
> | grep "nsds50ruv\|nsDS5ReplicaId"
> Enter LDAP Password:
> nsDS5ReplicaId: 1095
> nsds50ruv: {replicageneration} 50c1015c0060
> nsds50ruv: {replica 1095 ldap://kdc04.unix.iriszorg.nl:389}
> 57e4d75a044700
> nsds50ruv: {replica 66 ldap://kdc03.unix.iriszorg.nl:389}
> 57e23f660042
> nsds50ruv: {replica 96 ldap://kdc01.unix.iriszorg.nl:7389}
> 50c1016c006
> nsds50ruv: {replica 71 ldap://kdc03.unix.iriszorg.nl:389}
> 57e140c70047
> nsds50ruv: {replica 97 ldap://kdc02.unix.iriszorg.nl:7389}
> 50c101680061000
>
> and from kdc04:
>
> # ldapsearch -Z -h kdc04.unix.iriszorg.nl -D "cn=Directory Manager" -W -b
> "o=ipaca" 
> "(&(objectclass=nstombstone)(nsUniqueId=---))"
> | grep "nsds50ruv\|nsDS5ReplicaId"
> Enter LDAP Password:
> nsDS5ReplicaId: 1095
> nsds50ruv: {replicageneration} 50c1015c0060
> nsds50ruv: {replica 1095 ldap://kdc04.unix.iriszorg.nl:389}
> 57e4d75a044700
> nsds50ruv: {replica 66 ldap://kdc03.unix.iriszorg.nl:389}
> 57e23f660042
> nsds50ruv: {replica 96 ldap://kdc01.unix.iriszorg.nl:7389}
> 50c1016c006
> nsds50ruv: {replica 71 ldap://kdc03.unix.iriszorg.nl:389}
> 57e140c70047
> nsds50ruv: {replica 97 ldap://kdc02.unix.iriszorg.nl:7389}
> 50c101680061000
>
>
> So now I have to run a clen ruv task like this (as seen in
> https://www.redhat.com/archives/freeipa-users/2016-May/msg00043.html):
>
> # ldapmodify -ZZ -D "cn=directory manager" -W -a
> dn: cn=clean 13, cn=cleanallruv, cn=tasks, cn=config
> objectclass: extensibleObject
> replica-base-dn: o=ipaca
> replica-id: 13
> cn: clean 13
>
>
> And in my example, the replica id would be 66, 96, 71 and 97, correct?
>
> no, I don't think so. you searched 2 times the same host "-h
> kdc04.unix.iriszorg.nl".
> you need to search on kdc03 to find the current replicaid of kdc03 and you
> have to keep it.
>


yes, you are right :(

 $ ldapsearch -Z -h kdc03.unix.iriszorg.nl -D "cn=Directory Manager" -W -b
"o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
Enter LDAP Password:
nsDS5ReplicaId: 66
nsds50ruv: {replicageneration} 50c1015c0060
nsds50ruv: {replica 66 ldap://kdc03.unix.iriszorg.nl:389}
57e23f660042
nsds50ruv: {replica 1095 ldap://kdc04.unix.iriszorg.nl:389}
57e4d75a044700
nsds50ruv: {replica 96 ldap://kdc01.unix.iriszorg.nl:7389}
50c1016c006
nsds50ruv: {replica 71 ldap://kdc03.unix.iriszorg.nl:389}
57e140c70047
nsds50ruv: {replica 97 ldap://kdc02.unix.iriszorg.nl:7389}
50c101680061000


so I need to keep 66 and 1095, and run the task on 96, 71 and 97, it would
seem.

Thanks for spotting my error.

-- 
regards,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] replicas removed, but incorrectly

[Natxo Asenjo]

hi,

I recently upgraded a centos 6.8 realm to centos 7.2 and it almost went
correctly.

Now I see some errors in /var/log/dirsrv/slapd-INSTANCENAME/errors

26/Sep/2016:13:20:15 +0200] attrlist_replace - attr_replace
(nsslapd-referral, ldap://kdc03.unix.iriszorg.nl:389/o%3Dipaca) failed

and according to
http://www.freeipa.org/page/Troubleshooting#Replication_issues this points
to a ruv problem.

So let's enumerate.

We had kdc01 replicating to kdc02 (both 6.8).

Then I created a replica from kdc01 to kdc03 (running 7.2).

And from kdc03 to kdc04 (both 7.2).

kdc01 and kdc02 are decommissioned, but kdc02 still shows in both kdc03 and
kdc04:

$ ipa-replica-manage list
kdc02.unix.iriszorg.nl: master
kdc03.unix.iriszorg.nl: master
kdc04.unix.iriszorg.nl: master

and in

$ ipa-csreplica-manage list
Directory Manager password:
kdc02.unix.iriszorg.nl: master
kdc03.unix.iriszorg.nl: master
kdc04.unix.iriszorg.nl: master


>From kdc03:
$ ldapsearch -Z -h kdc04.unix.iriszorg.nl -D "cn=Directory Manager" -W -b
"o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
Enter LDAP Password:
nsDS5ReplicaId: 1095
nsds50ruv: {replicageneration} 50c1015c0060
nsds50ruv: {replica 1095 ldap://kdc04.unix.iriszorg.nl:389}
57e4d75a044700
nsds50ruv: {replica 66 ldap://kdc03.unix.iriszorg.nl:389}
57e23f660042
nsds50ruv: {replica 96 ldap://kdc01.unix.iriszorg.nl:7389}
50c1016c006
nsds50ruv: {replica 71 ldap://kdc03.unix.iriszorg.nl:389}
57e140c70047
nsds50ruv: {replica 97 ldap://kdc02.unix.iriszorg.nl:7389}
50c101680061000

and from kdc04:

# ldapsearch -Z -h kdc04.unix.iriszorg.nl -D "cn=Directory Manager" -W -b
"o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
Enter LDAP Password:
nsDS5ReplicaId: 1095
nsds50ruv: {replicageneration} 50c1015c0060
nsds50ruv: {replica 1095 ldap://kdc04.unix.iriszorg.nl:389}
57e4d75a044700
nsds50ruv: {replica 66 ldap://kdc03.unix.iriszorg.nl:389}
57e23f660042
nsds50ruv: {replica 96 ldap://kdc01.unix.iriszorg.nl:7389}
50c1016c006
nsds50ruv: {replica 71 ldap://kdc03.unix.iriszorg.nl:389}
57e140c70047
nsds50ruv: {replica 97 ldap://kdc02.unix.iriszorg.nl:7389}
50c101680061000


So now I have to run a clen ruv task like this (as seen in
https://www.redhat.com/archives/freeipa-users/2016-May/msg00043.html):

# ldapmodify -ZZ -D "cn=directory manager" -W -a
dn: cn=clean 13, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: o=ipaca
replica-id: 13
cn: clean 13

And in my example, the replica id would be 66, 96, 71 and 97, correct?

Thanks for confirming this, never done it before.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] replica added, but clients still try renewing certificates with old master

[Natxo Asenjo]

On Fri, Sep 23, 2016 at 9:29 AM, Petr Vobornik <pvobo...@redhat.com> wrote:

> On 09/21/2016 05:06 PM, Natxo Asenjo wrote:
>
> > So, what should be the correct value for dns discovery for both
> directives using
> > dns discovery?
>
> I don't think there is a support for DNS discovery in Certmonger. CCing
> Rob.
>

Well, as soon as I remove the old replica running centos 6.8, I will create
a dns A record with the old replica host name pointing to the new replica.
So I think that will solve this particular problem.

It would be much more convinient to have dns discovery in certmonger though.

Thanks!

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] replica added, but clients still try renewing certificates with old master

[Natxo Asenjo]

On Wed, Sep 21, 2016 at 5:06 PM, Natxo Asenjo <natxo.ase...@gmail.com>
wrote:

> ok, done.
>
> In fact, change both the domain as the xmlrpc_uri directives in the global
> section was necessary. Now It worked :-)
>

I meant the server, not the domain options obviously.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] replica added, but clients still try renewing certificates with old master

[Natxo Asenjo]

hi Petr,

On Wed, Sep 21, 2016 at 4:38 PM, Petr Vobornik <pvobo...@redhat.com> wrote:

> On 09/21/2016 10:50 AM, Natxo Asenjo wrote:
>
> > When I try to resubmit certificates from certmonger they still hit the
> kdc01 web
> > server, so the requests hang on an status: CA_UNREACHABLE
> >  ca-error: Server failed request, will retry: 4301 (RPC failed at
> server.
> > Certificate operation cannot be completed: Failure decoding Certificate
> Signing
> > Request).
>
> Where does it happen? On arbitrary client which was installed in a past
> against the removed kdc01?
>

yes.


>
> If so could you look into /etc/ipa/default.conf and change host option
> from kdc01 to the 7.2 IPA sever?
>
>
ok, done.

In fact, change both the domain as the xmlrpc_uri directives in the global
section was necessary. Now It worked :-)

So, what should be the correct value for dns discovery for both directives
using dns discovery?

thanks!
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] replica added, but clients still try renewing certificates with old master

[Natxo Asenjo]

hi,

I followed the instructions here:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html

and now after some issues I have a replica with both pki and dns data
running centos 7.

So now I have 3 replicas:

centos 6.8:
kdc01.unix.iriszorg.nl
kdc02.unix.iriszorg.nl

centos 7.2
kdc03.unix.iriszorg.nl

The replica was created with an agreement to kdc01.unix.iriszorg.nl which
was the master for crl updates. I followed the steps to disabled crlcache
and crlupdates on the kdc01 and to enable them on the kdc03.

So in the kdc01 I edited /etc/httpd/conf.d/ipa-pki-proxy.conf and
uncommented

# Only enable this on servers that are not generating a CRL
RewriteRule ^/ipa/crl/MasterCRL.bin
https://kdc03.unix.iriszorg.nl/ca/ee/ca/getCRL?op=getCRL=MasterCRL
[L,R=301,NC]

and on the kdc03 i commented this out:

# Only enable this on servers that are not generating a CRL
#RewriteRule ^/ipa/crl/MasterCRL.bin
https://kdc03.unix.iriszorg.nl/ca/ee/ca/getCRL?op=getCRL=MasterCRL
[L,R=301,NC]


When I try to resubmit certificates from certmonger they still hit the
kdc01 web server, so the requests hang on an status: CA_UNREACHABLE
ca-error: Server failed request, will retry: 4301 (RPC failed at
server.  Certificate operation cannot be completed: Failure decoding
Certificate Signing Request).


Which was the problem on a recent thread on the list (trying to get rid of
this replica now to fix this problem as well).

So something is not redirecting properly and I would appreciate your
assistance.

TIA.
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] certificates not renewing CA_UNREACHEABLE

[Natxo Asenjo]

ok, so all certs are renewed (dogldap and http).

On Tue, Sep 20, 2016 at 11:49 AM, Natxo Asenjo <natxo.ase...@gmail.com>
wrote:

>
>
> On Mon, Sep 19, 2016 at 5:27 PM, Rob Crittenden <rcrit...@redhat.com>
> wrote:
>
>> Natxo Asenjo wrote:
>>
>>> hi,
>>>
>>>
>>> On Fri, Sep 16, 2016 at 4:22 PM, Rob Crittenden <rcrit...@redhat.com
>>>
>> Ok, how about we work around the problem.
>>
>
> Gladly ;-)
>
>
>> Since it is failing on the revocation what you might try is removing the
>> userCertificate value from the ldap/kdc01.unix.iriszorg.nl service entry.
>>
>> I think this will work:
>>
>> $ ipa service-show ldap/kdc01.unix.iriszorg.nl |grep Serial
>> 
>>
>> $ ipa service-mod --certificate= ldap/kdc01.unix.iriszorg.nl
>>
>> If this doesn't work you can use ldapmodify to delete the usercertificate
>> value.
>>
>> This will remove the certificate value so there is nothing to revoke and
>> a new cert will be saved (hopefully).
>>
>> Now try to resubmit the request via certmonger.
>>
>> It if works then you can run ipa cert-revooke 
>>
>> It isn't a great answer long-term because it is really just working
>> around the problem but it should get the certs renewed.
>>
>>
> ok, so I restarted the httpd service then I could use ipa service-show:
>
> $ ipa service-show ldap/kdc01.unix.iriszorg.nl |grep Serial
>   Serial Number: 175
>   Serial Number (hex): 0xAF
> bash-4.1$ ipa service-mod --certificate= ldap/kdc01.unix.iriszorg.nl
> ---
> Modified service "ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl"
> ---
>   Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl
>   Managed by: kdc01.unix.iriszorg.nl
>
>
> bash-4.1$ sudo ipa-getcert resubmit -i 20121107212513
> Resubmitting "20121107212513" to "IPA".
> bash-4.1$ sudo getcert list
> Number of certificates and requests being tracked: 8.
> Request ID '20121107212513':
> status: CA_UNREACHABLE
> ca-error: Server failed request, will retry: 4301 (RPC failed at
> server.  Certificate operation cannot be completed: Failure decoding
> Certificate Signing Request).
> stuck: yes
> key pair storage: type=NSSDB,location='/etc/
> dirsrv/slapd-UNIX-IRISZORG-NL',nickname='Server-Cert',token='NSS
> Certificate DB',pinfile='/etc/dirsrv/slapd-UNIX-IRISZORG-NL/pwdfile.txt'
> certificate: type=NSSDB,location='/etc/
> dirsrv/slapd-UNIX-IRISZORG-NL',nickname='Server-Cert',token='NSS
> Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL
> subject: CN=kdc01.unix.iriszorg.nl,O=UNIX.IRISZORG.NL
> expires: 2016-10-12 10:49:24 UTC
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib/ipa/certmonger/restart_dirsrv
> UNIX-IRISZORG-NL
> track: yes
> auto-renew: yes
>
>
>
> the certificate is gone:
> $ ipa service-show ldap/kdc01.unix.iriszorg.nl
> ipa: ERROR: Could not create log_dir u'/home/jose.admin/.ipa/log'
>   Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl
>   Keytab: True
>   Managed by: kdc01.unix.iriszorg.nl
>
>
> But then I thought, what the hell, let's try again, restarted httpd,
> resubmitted it, and now it did work ;-)
>
> $ ipa service-show ldap/kdc01.unix.iriszorg.nl
>   Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl
>   Certificate: MIIDrDCCApSgAwIBAgICAPUwDQYJKo
> ZIhvcNAQELBQAwOzEZMBcGA1UEChMQVU5JWC5JUklTWk9SRy5OTDEeMBwGA1
> UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDkyMDA4MDY1OFoXDT
> E4MDkyMTA4MDY1OFowPDEZMBcGA1UEChMQVU5JWC5JUklTWk9SRy5OTDEfMB
> 0GA1UEAxMWa2RjMDEudW5peC5pcmlzem9yZy5ubDCCASIwDQYJKoZIhvcNAQ
> EBBQADggEPADCCAQoCggEBAO2QVqrFRb/Q5dhkAi7BK29BJhqTvbaH3bNDLvhe1
> snyChdlr/AIwrJj/53Ti2eJ7u1BtV7u3gSwQ3/xJ0HwUZmOEQHCNDrjcGy+
> iw7lqkC5NaZ8AGt8bSTGWwnJvEGWrb3uEJzVZf+xB5eZa8vFXr+
> Jlcfoq8DbVZhX274pmpVfQOnRckD+AmncuEItHpcJCCHneF0QzA5DQqlTPUFerFm3F/iI/
> k6g9XbHQaNejcUYdhXpy9q0mEuBIIsEzTeNWTTEsUYX5TPVEsN3x2feA0icx
> R6bUTeg2BqSu7ZOuM55iBp3l0d9UAQ7W7yh76FI/Bqz8vIMdS6VsurPS4asLa8CAwEAAaO
> BuDCBtTAfBgNVHSMEGDAWgBSjl+SKLrjPPuoz8ryT1iPeqYQ2aDBEBggr
> BgEFBQcBAQQ4MDYwNAYIKwYBBQUHMAGGKGh0dHA6Ly9rZGMwMS51bml4Lmly
> aXN6b3JnLm5sOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQ
> UFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUBIRsG98GBkIyB/
> BgQKloUlLEJeEwDQYJKoZIhvcNAQELBQADggEBAHN+ggklVf2uzaePwEI9rMObe0WZeOyCLZ
> xEtigDaJIHkq3GzkugxcG8ivD/LnuF0D8m07npfpIMC3QRUJQjFjz6E3rKtqau0QY0BO

Re: [Freeipa-users] certificates not renewing CA_UNREACHEABLE

[Natxo Asenjo]

On Mon, Sep 19, 2016 at 5:27 PM, Rob Crittenden <rcrit...@redhat.com> wrote:

> Natxo Asenjo wrote:
>
>> hi,
>>
>>
>> On Fri, Sep 16, 2016 at 4:22 PM, Rob Crittenden <rcrit...@redhat.com
>>
> Ok, how about we work around the problem.
>

Gladly ;-)


> Since it is failing on the revocation what you might try is removing the
> userCertificate value from the ldap/kdc01.unix.iriszorg.nl service entry.
>
> I think this will work:
>
> $ ipa service-show ldap/kdc01.unix.iriszorg.nl |grep Serial
> 
>
> $ ipa service-mod --certificate= ldap/kdc01.unix.iriszorg.nl
>
> If this doesn't work you can use ldapmodify to delete the usercertificate
> value.
>
> This will remove the certificate value so there is nothing to revoke and a
> new cert will be saved (hopefully).
>
> Now try to resubmit the request via certmonger.
>
> It if works then you can run ipa cert-revooke 
>
> It isn't a great answer long-term because it is really just working around
> the problem but it should get the certs renewed.
>
>
ok, so I restarted the httpd service then I could use ipa service-show:

$ ipa service-show ldap/kdc01.unix.iriszorg.nl |grep Serial
  Serial Number: 175
  Serial Number (hex): 0xAF
bash-4.1$ ipa service-mod --certificate= ldap/kdc01.unix.iriszorg.nl
---
Modified service "ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl"
---
  Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl
  Managed by: kdc01.unix.iriszorg.nl


bash-4.1$ sudo ipa-getcert resubmit -i
20121107212513   Resubmitting "20121107212513" to
"IPA".
bash-4.1$ sudo getcert list
Number of certificates and requests being tracked: 8.
Request ID '20121107212513':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: 4301 (RPC failed at
server.  Certificate operation cannot be completed: Failure decoding
Certificate Signing Request).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-UNIX-IRISZORG-NL',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-UNIX-IRISZORG-NL/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-UNIX-IRISZORG-NL',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL
subject: CN=kdc01.unix.iriszorg.nl,O=UNIX.IRISZORG.NL
expires: 2016-10-12 10:49:24 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib/ipa/certmonger/restart_dirsrv
UNIX-IRISZORG-NL
track: yes
auto-renew: yes



the certificate is gone:
$ ipa service-show ldap/kdc01.unix.iriszorg.nl
ipa: ERROR: Could not create log_dir u'/home/jose.admin/.ipa/log'
  Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl
  Keytab: True
  Managed by: kdc01.unix.iriszorg.nl


But then I thought, what the hell, let's try again, restarted httpd,
resubmitted it, and now it did work ;-)

$ ipa service-show ldap/kdc01.unix.iriszorg.nl
  Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl
  Certificate:
MIIDrDCCApSgAwIBAgICAPUwDQYJKoZIhvcNAQELBQAwOzEZMBcGA1UEChMQVU5JWC5JUklTWk9SRy5OTDEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDkyMDA4MDY1OFoXDTE4MDkyMTA4MDY1OFowPDEZMBcGA1UEChMQVU5JWC5JUklTWk9SRy5OTDEfMB0GA1UEAxMWa2RjMDEudW5peC5pcmlzem9yZy5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO2QVqrFRb/Q5dhkAi7BK29BJhqTvbaH3bNDLvhe1snyChdlr/AIwrJj/53Ti2eJ7u1BtV7u3gSwQ3/xJ0HwUZmOEQHCNDrjcGy+iw7lqkC5NaZ8AGt8bSTGWwnJvEGWrb3uEJzVZf+xB5eZa8vFXr+Jlcfoq8DbVZhX274pmpVfQOnRckD+AmncuEItHpcJCCHneF0QzA5DQqlTPUFerFm3F/iI/k6g9XbHQaNejcUYdhXpy9q0mEuBIIsEzTeNWTTEsUYX5TPVEsN3x2feA0icxR6bUTeg2BqSu7ZOuM55iBp3l0d9UAQ7W7yh76FI/Bqz8vIMdS6VsurPS4asLa8CAwEAAaOBuDCBtTAfBgNVHSMEGDAWgBSjl+SKLrjPPuoz8ryT1iPeqYQ2aDBEBggrBgEFBQcBAQQ4MDYwNAYIKwYBBQUHMAGGKGh0dHA6Ly9rZGMwMS51bml4LmlyaXN6b3JnLm5sOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUBIRsG98GBkIyB/BgQKloUlLEJeEwDQYJKoZIhvcNAQELBQADggEBAHN+ggklVf2uzaePwEI9rMObe0WZeOyCLZxEtigDaJIHkq3GzkugxcG8ivD/LnuF0D8m07npfpIMC3QRUJQjFjz6E3rKtqau0QY0BO+Dwg1TzItQqXxgHtCqcQ7bmahj2AMPRNUXeZck0p/eueG4wj2kbLwTLU6cOfwnT4IOfszAS9GCql6oQIXlOfG6i6DAodBpgWziDfIrRJsJi4ZE+FvJL/ImJDdW+En50UyGp0n31oMSDIxWf1bdWUctSEYhcy9JftzkitNm1FD+a1HzeYyuHthzlHHcSIXN/kXRSGktpe8VHE5XLtKnH92vmkMnyxZvE///2+ExHXIAOkwq3ck=
  Keytab: True
  Managed by: kdc01.unix.iriszorg.nl
  Subject: CN=kdc01.unix.iriszorg.nl,O=UNIX.IRISZORG.NL
  Serial Number: 245
  Serial Number (hex): 0xF5
  Issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL
  Not Before: Tue Sep 20 08:06:58 2016 UTC
  Not After: Fri Sep 21 08:06:58 2018 UTC
  Fingerprint (MD5): f8:d3:cb:6f:4c:ca:e4:f3:47:65:51:d3:2c:69:84:df
  Fingerprint (SHA1):
e3:0a:66:19:d7:36:fe:c

Re: [Freeipa-users] certificates not renewing CA_UNREACHEABLE

[Natxo Asenjo]

hi,


On Fri, Sep 16, 2016 at 10:34 AM, Martin Basti <mba...@redhat.com> wrote:

>
>
> On 16.09.2016 09:38, Natxo Asenjo wrote:
>
> hi,
>
>
> On Thu, Sep 15, 2016 at 1:03 PM, Natxo Asenjo <natxo.asenjo@gmail.c
> <natxo.ase...@gmail.com>
>>
>> On Thu, Sep 15, 2016 at 12:49 PM, Martin Basti <mba...@redhat.com> wrote:
>>
>>>
>>>
>>> On 15.09.2016 12:44, Natxo Asenjo wrote:
>>>
>>> hi,
>>>
>>> On Thu, Sep 15, 2016 at 12:33 PM, Martin Basti <mba...@redhat.com>
>>> wrote:
>>>
>>>>
>>>> Hello,
>>>>
>>>> usually the most information can be found here
>>>> /var/log/pki/pki-tomcat/ca/debug
>>>>
>>>
>>> mmm, in this centos 6.8 system that does not exist:
>>>
>>> # ls -l /var/log/pki/pki-tomcat/ca/debug
>>> ls: cannot access /var/log/pki/pki-tomcat/ca/debug: No such file or
>>> directory
>>>
>>>
>>> I do have a /var/log/pki-ca/debug
>>>
>>>
>>>
>>> Does it contain any information related to your issue?
>>>
>>
>> I have tried renewing the certificate:
>>
>> ipa-getcert resubmit -i 20121107212513
>>
>>
>> If I grep that file for that request id I find nothing recent, just in
>> the ipaserver installation log
>>
>> # cd /var/log
>> # grep -ri 20121107212513 *.log
>> ipaserver-install.log:2012-11-07T21:25:13Z DEBUG stdout=New tracking
>> request "20121107212513" added.
>>
>> # grep -ri 20121107212513 pki-ca
>> #
>>
>>
> Any clues?
>
>
> --
> Groeten,
> natxo
>
>
>
> Sorry, I'm quite lost here, maybe somebody from dogtag can help what might
> be reason of those CA errors
>


do I need to ask in the dogtag list?
-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format.

[Natxo Asenjo]

hi,


On Thu, Sep 15, 2016 at 2:25 PM, Natxo Asenjo <natxo.ase...@gmail.com>
wrote:

> hi,
>
> attached error_log
>


Any clues?

Thanks!

-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] certificates not renewing CA_UNREACHEABLE

[Natxo Asenjo]

hi,


On Thu, Sep 15, 2016 at 1:03 PM, Natxo Asenjo <natxo.asenjo@gmail.c
<natxo.ase...@gmail.com>
>
> On Thu, Sep 15, 2016 at 12:49 PM, Martin Basti <mba...@redhat.com> wrote:
>
>>
>>
>> On 15.09.2016 12:44, Natxo Asenjo wrote:
>>
>> hi,
>>
>> On Thu, Sep 15, 2016 at 12:33 PM, Martin Basti <mba...@redhat.com> wrote:
>>
>>>
>>> Hello,
>>>
>>> usually the most information can be found here
>>> /var/log/pki/pki-tomcat/ca/debug
>>>
>>
>> mmm, in this centos 6.8 system that does not exist:
>>
>> # ls -l /var/log/pki/pki-tomcat/ca/debug
>> ls: cannot access /var/log/pki/pki-tomcat/ca/debug: No such file or
>> directory
>>
>>
>> I do have a /var/log/pki-ca/debug
>>
>>
>>
>> Does it contain any information related to your issue?
>>
>
> I have tried renewing the certificate:
>
> ipa-getcert resubmit -i 20121107212513
>
>
> If I grep that file for that request id I find nothing recent, just in the
> ipaserver installation log
>
> # cd /var/log
> # grep -ri 20121107212513 *.log
> ipaserver-install.log:2012-11-07T21:25:13Z DEBUG stdout=New tracking
> request "20121107212513" added.
>
> # grep -ri 20121107212513 pki-ca
> #
>
>
Any clues?


--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format.

[Natxo Asenjo]

On Thu, Sep 15, 2016 at 1:03 PM, Ben Lipton <blip...@redhat.com> wrote:

>
> On 09/15/2016 03:04 AM, Natxo Asenjo wrote:
>
> Hi Ben,
>
> On Wed, Sep 14, 2016 at 2:45 PM, Ben Lipton <blip...@redhat.com> wrote:
>
> One other note - this could be a permissions issue. NSS seems to produce
>> this confusing error message when it can't access the database, even if the
>> format of the database is actually fine.
>>
>> $ sudo chown root:root /tmp/certs
>> $ certutil -N -d /tmp/certs
>> certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key
>> database is in an old, unsupported format.
>>
>
> Thanks for the tip. What directory should I check? I have checked:
>
>
> [root@kdc01 httpd]$ ls -ltrZ /etc/httpd/alias/
> -rw-r-. root apache unconfined_u:object_r:cert_t:s0  secmod.db.orig
> -rw-r-. root apache unconfined_u:object_r:cert_t:s0  key3.db.orig
> -rw-r-. root apache unconfined_u:object_r:cert_t:s0  cert8.db.orig
> -rw---. root root   unconfined_u:object_r:cert_t:s0  install.log
> -rw-rw. root apache unconfined_u:object_r:cert_t:s0  pwdfile.txt
> -rw-rw. root apache unconfined_u:object_r:cert_t:s0  secmod.db
> -r--r--r--. root root   unconfined_u:object_r:cert_t:s0  cacert.asc.orig
> -r--r--r--. root root   unconfined_u:object_r:cert_t:s0  cacert.asc
> lrwxrwxrwx. root root   system_u:object_r:cert_t:s0  libnssckbi.so ->
> ../../..//usr/lib/libnssckbi.so
> -rw-rw. root apache unconfined_u:object_r:cert_t:s0  key3.db
> -rw-rw. root apache unconfined_u:object_r:cert_t:s0  cert8.db
>
> [root@kdc01 httpd]$ ls -ltrdZ /etc/httpd/alias/
> drwxr-xr-x. root root system_u:object_r:cert_t:s0  /etc/httpd/alias/
>
>
> Those seem ok.
> --
> Groeten,
> natxo
>
>
> The other one I know about is:
> # ls -ltrZ /etc/ipa/nssdb
> total 80
> -rw---. 1 root root unconfined_u:object_r:cert_t:s040 Aug 22
> 13:13 pwdfile.txt
> -rw-r--r--. 1 root root unconfined_u:object_r:cert_t:s0 16384 Aug 22
> 13:13 secmod.db
> -rw-r--r--. 1 root root unconfined_u:object_r:cert_t:s0 16384 Aug 22
> 13:13 key3.db
> -rw-r--r--. 1 root root unconfined_u:object_r:cert_t:s0 65536 Aug 22
> 13:13 cert8.db
> # ls -ltrdZ /etc/ipa/nssdb
> drwxr-xr-x. 2 root root system_u:object_r:cert_t:s0 73 Sep 14 18:08
> /etc/ipa/nssdb
>
> I still don't have any good ideas for why it would work for 5 minutes and
> then give an error. If you manage to get a traceback for the
> CertificateFormatError by enabling debug logging, that could be very
> helpful.
>

I do not have that directory (centos 6.8):

 ls -ltrZ /etc/ipa/
-rw-r--r--. root root unconfined_u:object_r:etc_t:s0   default.conf
-rw-r--r--. root root unconfined_u:object_r:etc_t:s0   ca.crt
drwxr-xr-x. root root system_u:object_r:etc_t:s0   html
-rw-r--r--. root root unconfined_u:object_r:etc_t:s0   server.conf.bak
-rw-r--r--. root root unconfined_u:object_r:etc_t:s0   server.conf


I have enabled debugging:

$ cat /etc/ipa/server.conf
[global]
debug = True

Could I send you the logs privately?


-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] certificates not renewing CA_UNREACHEABLE

[Natxo Asenjo]

On Thu, Sep 15, 2016 at 12:49 PM, Martin Basti <mba...@redhat.com> wrote:

>
>
> On 15.09.2016 12:44, Natxo Asenjo wrote:
>
> hi,
>
> On Thu, Sep 15, 2016 at 12:33 PM, Martin Basti <mba...@redhat.com> wrote:
>
>>
>> Hello,
>>
>> usually the most information can be found here
>> /var/log/pki/pki-tomcat/ca/debug
>>
>
> mmm, in this centos 6.8 system that does not exist:
>
> # ls -l /var/log/pki/pki-tomcat/ca/debug
> ls: cannot access /var/log/pki/pki-tomcat/ca/debug: No such file or
> directory
>
>
> I do have a /var/log/pki-ca/debug
>
>
>
> Does it contain any information related to your issue?
>

I have tried renewing the certificate:

ipa-getcert resubmit -i 20121107212513


If I grep that file for that request id I find nothing recent, just in the
ipaserver installation log

# cd /var/log
# grep -ri 20121107212513 *.log
ipaserver-install.log:2012-11-07T21:25:13Z DEBUG stdout=New tracking
request "20121107212513" added.

# grep -ri 20121107212513 pki-ca
#








-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] certificates not renewing CA_UNREACHEABLE

[Natxo Asenjo]

hi,

On Thu, Sep 15, 2016 at 12:33 PM, Martin Basti  wrote:

>
> Hello,
>
> usually the most information can be found here
> /var/log/pki/pki-tomcat/ca/debug
>

mmm, in this centos 6.8 system that does not exist:

# ls -l /var/log/pki/pki-tomcat/ca/debug
ls: cannot access /var/log/pki/pki-tomcat/ca/debug: No such file or
directory


I do have a /var/log/pki-ca/debug




-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] certificates not renewing CA_UNREACHEABLE

[Natxo Asenjo]

hi,

one of our master servers has a problem with its certificates:

# getcert list

Number of certificates and requests being tracked: 8.
Request ID '20121107212513':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: 907 (RPC failed at
server.  cannot connect to '
https://kdc01.unix.iriszorg.nl:443/ca/agent/ca/doRevoke': (SEC_ERROR_BUSY)
NSS could not shutdown. Objects are still in use.).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-UNIX-IRISZORG-NL',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-UNIX-IRISZORG-NL/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-UNIX-IRISZORG-NL',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL
subject: CN=kdc01.unix.iriszorg.nl,O=UNIX.IRISZORG.NL
expires: 2016-10-12 10:49:24 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib/ipa/certmonger/restart_dirsrv
UNIX-IRISZORG-NL
track: yes
auto-renew: yes
Request ID '20121107212532':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: 4301 (RPC failed at
server.  Certificate operation cannot be completed: Failure decoding
Certificate Signing Request).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL
subject: CN=kdc01.unix.iriszorg.nl,O=UNIX.IRISZORG.NL
expires: 2016-10-12 10:49:25 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20121107212548':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: 4301 (RPC failed at
server.  Certificate operation cannot be completed: Failure decoding
Certificate Signing Request).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL
subject: CN=kdc01.unix.iriszorg.nl,O=UNIX.IRISZORG.NL
expires: 2016-10-12 10:49:24 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes


Where should I start looking?

In /var/log/httpd/error_log there is nothing of consquence.

-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] adding replica centos 7 to centos 6 fails [error] ObjectclassViolation: attribute "unhashed#user#password" not allowed

[Natxo Asenjo]

hi,

the fact the the usercertificate attribute of uid=admin,ou=people,o=ipaca
is expired could this be the cause of these problems as well?

How can I renew this certificate?



--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format.

[Natxo Asenjo]

Hi Ben,

On Wed, Sep 14, 2016 at 2:45 PM, Ben Lipton  wrote:

One other note - this could be a permissions issue. NSS seems to produce
> this confusing error message when it can't access the database, even if the
> format of the database is actually fine.
>
> $ sudo chown root:root /tmp/certs
> $ certutil -N -d /tmp/certs
> certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key
> database is in an old, unsupported format.
>

Thanks for the tip. What directory should I check? I have checked:


[root@kdc01 httpd]$ ls -ltrZ /etc/httpd/alias/
-rw-r-. root apache unconfined_u:object_r:cert_t:s0  secmod.db.orig
-rw-r-. root apache unconfined_u:object_r:cert_t:s0  key3.db.orig
-rw-r-. root apache unconfined_u:object_r:cert_t:s0  cert8.db.orig
-rw---. root root   unconfined_u:object_r:cert_t:s0  install.log
-rw-rw. root apache unconfined_u:object_r:cert_t:s0  pwdfile.txt
-rw-rw. root apache unconfined_u:object_r:cert_t:s0  secmod.db
-r--r--r--. root root   unconfined_u:object_r:cert_t:s0  cacert.asc.orig
-r--r--r--. root root   unconfined_u:object_r:cert_t:s0  cacert.asc
lrwxrwxrwx. root root   system_u:object_r:cert_t:s0  libnssckbi.so ->
../../..//usr/lib/libnssckbi.so
-rw-rw. root apache unconfined_u:object_r:cert_t:s0  key3.db
-rw-rw. root apache unconfined_u:object_r:cert_t:s0  cert8.db

[root@kdc01 httpd]$ ls -ltrdZ /etc/httpd/alias/
drwxr-xr-x. root root system_u:object_r:cert_t:s0  /etc/httpd/alias/


Those seem ok.
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] CA: Cannot add Centos7.2 replica to Centos6.8 ipa server

[Natxo Asenjo]

hi,

On Tue, Sep 13, 2016 at 9:36 PM, Endi Sukma Dewata 
wrote:

> On 9/12/2016 9:35 PM, Endi Sukma Dewata wrote:
>
>> On 9/9/2016 2:46 PM, Georgios Kafataridis wrote:
>>
>>> I've tried that but still the same result.
>>>
>>> [root@ipa-server /]# ldapsearch -D "cn=directory manager" -W -p 389 -h
>>> localhost -b "uid=admin,ou=people,o=ipaca"
>>> Enter LDAP Password:
>>> # extended LDIF
>>> #
>>> # LDAPv3
>>> # base 

Re: [Freeipa-users] adding replica centos 7 to centos 6 fails [error] ObjectclassViolation: attribute "unhashed#user#password" not allowed

[Natxo Asenjo]

On Tue, Sep 13, 2016 at 2:10 PM, Natxo Asenjo <natxo.ase...@gmail.com>
wrote:

> hi,
>
> when trying to add a replica to the Idm environment of a host running
> centos 7 (fully patched) to an existing centos 6.8 realm I get this error:
>

ok, some progress. I found this:

https://fedorahosted.org/389/ticket/470

So I went ahead and rebooted the master 6.8 kdc I was replicating from and
then it failed in the certificate server instance:


ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure
CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpyHV1BW''
returned non-zero exit status 1
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation
logs and the following files/directories for more information:
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
/var/log/pki-ca-install.log
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
/var/log/pki/pki-tomcat
  [error] RuntimeError: CA configuration failed.
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERRORCA configuration
failed.


But there is no /var/log/pki-ca-install.log :

# ls -ltr /var/log/
total 1708
drwx--. 2 root   root  6 Jun 10  2014 ppp
drwxr-xr-x. 2 ntpntp   6 May 31 12:29 ntpstats
drwx--. 2 root   root  6 Jul 18 17:30 httpd
drwxr-x---. 2 sssd   sssd  6 Aug  2 18:58 sssd
-rw---. 1 root   root  0 Sep 13 13:19 tallylog
drwx--. 3 root   root 16 Sep 13 13:19 samba
-rw---. 1 root   root  0 Sep 13 13:20 spooler
drwxr-xr-x. 2 root   root   4096 Sep 13 13:23 anaconda
drwxr-x---. 2 root   root 22 Sep 13 13:23 audit
drwxr-xr-x. 2 root   root 22 Sep 13 13:23 tuned
drwxrwx---. 2 tomcat root 25 Sep 13 13:31 tomcat
-rw---. 1 root   root  15126 Sep 13 13:31 yum.log
-rw---. 1 root   root   8786 Sep 13 13:31 ipaupgrade.log
-rw-r--r--. 1 root   root  94862 Sep 13 13:59 dmesg.old
-rw---. 1 root   root  18112 Sep 13 14:29 ipaclient-install.log
-rw---. 1 root   root  40193 Sep 13 14:29 ipaclient-uninstall.log
-rw---. 1 root   root  35796 Sep 13 14:29 ipaserver-uninstall.log
-rw-r--r--. 1 root   root  94862 Sep 13 14:30 dmesg
-rw-r--r--. 1 root   root   8591 Sep 13 14:30 boot.log
-rw---. 1 root   root   2587 Sep 13 14:30 cron
-rw-r--r--. 1 root   root200 Sep 13 14:30 wpa_supplicant.log
-rw---. 1 root   root958 Sep 13 14:30 maillog
-rw---. 1 root   utmp768 Sep 13 14:30 btmp
-rw-rw-r--. 1 root   utmp  13056 Sep 13 14:30 wtmp
-rw-r--r--. 1 root   root 291416 Sep 13 14:30 lastlog
-rw---. 1 root   root   7318 Sep 13 14:31 ipareplica-conncheck.log
drwxr-xr-x. 3 root   root 35 Sep 13 14:31 dirsrv
drwxr-xr-x. 4 root   root   4096 Sep 13 14:32 pki
-rw---. 1 root   root  87106 Sep 13 14:32 secure
-rw---. 1 root   root 742436 Sep 13 14:32 messages
-rw---. 1 root   root 202169 Sep 13 14:33 ipareplica-install.log

In the ipa-replica-install.log , though, I find this:

pkispawn: ERROR... Exception from Java Configuration Servlet:
500 Server Error: Internal Server Error
pkispawn: ERROR... ParseError: not well-formed (invalid token):
line 1, column 0:
{"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Clone
does not have all the required certificates"}

Any clue?



-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format.

[Natxo Asenjo]

hi,


On Mon, Sep 12, 2016 at 9:48 PM, Rob Crittenden <rcrit...@redhat.com> wrote:

> Natxo Asenjo wrote:
>
>> hi,
>>
>> I can reproduce this everytime. Restarting httpd fixes it for a while,
>> but then ik stops working:
>>
>> $ ipa cert-show 1
>> ipa: ERROR: cannot connect to
>> 'https://kdc01.unix.domain.tld:443/ca/agent/ca/displayBySerial':
>> (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old,
>> unsupported format.
>>
>
> It is very strange that it goes from a working to a non-working state.
>
> I have only two suggestions:
>
> 1. Create /etc/ipa/server.conf with a [global] section and debug=True in
> it, restart httpd. Your log will be quite a bit more verbose but given it
> reproduces so quickly hopefully won't be too big a deal. That might show
> something.
>
> 2. Try brute force with strace. Finding the right httpd process to strace
> can be frustrating but usually there are only 8 and they rotate so
> eventually you should get the right one.
>

Could I send you the log files privately?
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] CA: Cannot add Centos7.2 replica to Centos6.8 ipa server

[Natxo Asenjo]

Hi Giorgios,

On Thu, Sep 8, 2016 at 4:37 PM, Giorgos Kafa 
wrote:

> Hello, I am  trying to migrate and upgrade my main freeipa installation,
> so I decided to replicate it and phase it out of our intranet.
> I manage to get over some obstacles as I had to recreate my cacert.p12
> file, but now I am facing an issue that prevents me from setting up CA on
> the replicated server.
>

first off, did you follow the instructions in
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html

I have tested migrations several times with PKI and they all went fine.

-- 
regards,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format.

[Natxo Asenjo]

On Thu, Sep 8, 2016 at 3:25 PM, Rob Crittenden <rcrit...@redhat.com> wrote:

> Natxo Asenjo wrote:
>
>> I do see these errors:
>> [Wed Sep 07 15:56:13 2016] [error] ipa: INFO:: ping(): SUCCESS
>> [Wed Sep 07 15:56:13 2016] [error] ipa: INFO: : host_find(u'tftp-1801',
>> all=False, raw=False, version=u'2.49', no_members=False,
>> pkey_only=False): CertificateFormatError
>> [Wed Sep 07 15:56:44 2016] [error] ipa: INFO: : ping(): SUCCESS
>> [Wed Sep 07 15:56:44 2016] [error] ipa: INFO: : host_find(u'tftp-1801',
>> all=False, raw=False, version=u'2.49', no_members=False,
>> pkey_only=False): CertificateFormatError
>> [Wed Sep 07 15:57:57 2016] [error] ipa: INFO: : ping(): SUCCESS
>> [Wed Sep 07 15:57:58 2016] [error] ipa: INFO: : host_find(u'tftp-1801',
>> all=False, raw=False, version=u'2.49', no_members=False,
>> pkey_only=False): CertificateFormatErro
>>
>>
>> On Wed, Sep 7, 2016 at 4:01 PM, Natxo Asenjo <natxo.ase...@gmail.com
>> <mailto:natxo.ase...@gmail.com>> wrote:
>>
>>
>> alas, not woriking again.
>>
>> On the one kdc
>>
>> $ ipa host-find tftp-1801
>> ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE)
>> The certificate/key database is in an old, unsupported format.
>>
>> On the other:
>>
>> $ ipa host-find tftp-1801
>> --
>> 1 host matched
>> --
>>Host name: tftp-1801.sub.domain.tld
>> .
>>
>> After rebooting the kdc with the error, no new tracebacks in the
>> error_log
>>
>
> No new tracebacks but still not working?
>
> The CertificateFormatError is the server logging the equivalent of what
> you're seeing in the client.
>
> rob
>


that's right.

Is there anything else I can look at?


-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format.

[Natxo Asenjo]

I do see these errors:
[Wed Sep 07 15:56:13 2016] [error] ipa: INFO:: ping(): SUCCESS
[Wed Sep 07 15:56:13 2016] [error] ipa: INFO: : host_find(u'tftp-1801',
all=False, raw=False, version=u'2.49', no_members=False, pkey_only=False):
CertificateFormatError
[Wed Sep 07 15:56:44 2016] [error] ipa: INFO: : ping(): SUCCESS
[Wed Sep 07 15:56:44 2016] [error] ipa: INFO: : host_find(u'tftp-1801',
all=False, raw=False, version=u'2.49', no_members=False, pkey_only=False):
CertificateFormatError
[Wed Sep 07 15:57:57 2016] [error] ipa: INFO: : ping(): SUCCESS
[Wed Sep 07 15:57:58 2016] [error] ipa: INFO: : host_find(u'tftp-1801',
all=False, raw=False, version=u'2.49', no_members=False, pkey_only=False):
CertificateFormatErro


On Wed, Sep 7, 2016 at 4:01 PM, Natxo Asenjo <natxo.ase...@gmail.com> wrote:

>
> alas, not woriking again.
>
> On the one kdc
>
> $ ipa host-find tftp-1801
> ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The
> certificate/key database is in an old, unsupported format.
>
> On the other:
>
> $ ipa host-find tftp-1801
> --
> 1 host matched
> --
>   Host name: tftp-1801.sub.domain.tld
> .
>
> After rebooting the kdc with the error, no new tracebacks in the error_log
>
> Strange
>
> --
> --
> Groeten,
> natxo
>



-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format.

[Natxo Asenjo]

alas, not woriking again.

On the one kdc

$ ipa host-find tftp-1801
ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The
certificate/key database is in an old, unsupported format.

On the other:

$ ipa host-find tftp-1801
--
1 host matched
--
  Host name: tftp-1801.sub.domain.tld
.

After rebooting the kdc with the error, no new tracebacks in the error_log

Strange

-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format.

[Natxo Asenjo]

On Wed, Sep 7, 2016 at 3:27 PM, Rob Crittenden <rcrit...@redhat.com> wrote:

> Natxo Asenjo wrote:
>
>> hi,
>>
>> using centos 6.8 (server and client), when trying to view some hosts we
>> get this error:
>>
>>
>> $ ipa host-find host-1920.sub.domain.tld
>> ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The
>> certificate/key database is in an old, unsupported format.
>>
>>
>> I saw a thread last year about this, but no solution.
>>
>> Any clues?
>>
>
> /var/log/httpd/error_log may contain a traceback


This made me take a look at a replica and there I could not replicate the
error, I got the info I requested.

In the apache error file I saw indeed a traceback:

 [Sun Sep 04 03:21:31 2016] [error] ipa: ERROR: non-public: XMLSyntaxError:
None
[Sun Sep 04 03:21:31 2016] [error] Traceback (most recent call last):
[Sun Sep 04 03:21:31 2016] [error]   File
"/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 334, in
wsgi_execute
[Sun Sep 04 03:21:31 2016] [error] result = self.Command[name](*args,
**options)
[Sun Sep 04 03:21:31 2016] [error]   File
"/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 438, in __call__
[Sun Sep 04 03:21:31 2016] [error] ret = self.run(*args, **options)
[Sun Sep 04 03:21:31 2016] [error]   File
"/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 750, in run
[Sun Sep 04 03:21:31 2016] [error] return self.execute(*args, **options)
[Sun Sep 04 03:21:31 2016] [error]   File
"/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py", line 362, in
execute
[Sun Sep 04 03:21:31 2016] [error] result =
api.Command['cert_show'](unicode(serial))['result']
[Sun Sep 04 03:21:31 2016] [error]   File
"/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 438, in __call__
[Sun Sep 04 03:21:31 2016] [error] ret = self.run(*args, **options)
[Sun Sep 04 03:21:31 2016] [error]   File
"/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 750, in run
[Sun Sep 04 03:21:31 2016] [error] return self.execute(*args, **options)
[Sun Sep 04 03:21:31 2016] [error]   File
"/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py", line 493, in
execute
[Sun Sep 04 03:21:31 2016] [error]
result=self.Backend.ra.get_certificate(serial_number)
[Sun Sep 04 03:21:31 2016] [error]   File
"/usr/lib/python2.6/site-packages/ipaserver/plugins/dogtag.py", line 1489,
in get_certificate
[Sun Sep 04 03:21:31 2016] [error] parse_result =
self.get_parse_result_xml(http_body, parse_display_cert_xml)
[Sun Sep 04 03:21:31 2016] [error]   File
"/usr/lib/python2.6/site-packages/ipaserver/plugins/dogtag.py", line 1350,
in get_parse_result_xml
[Sun Sep 04 03:21:31 2016] [error] doc = etree.fromstring(xml_text,
parser)
[Sun Sep 04 03:21:31 2016] [error]   File "lxml.etree.pyx", line 2532, in
lxml.etree.fromstring (src/lxml/lxml.etree.c:48270)
[Sun Sep 04 03:21:31 2016] [error]   File "parser.pxi", line 1545, in
lxml.etree._parseMemoryDocument (src/lxml/lxml.etree.c:71812)
[Sun Sep 04 03:21:31 2016] [error]   File "parser.pxi", line 1424, in
lxml.etree._parseDoc (src/lxml/lxml.etree.c:70673)
[Sun Sep 04 03:21:31 2016] [error]   File "parser.pxi", line 938, in
lxml.etree._BaseParser._parseDoc (src/lxml/lxml.etree.c:67442)
[Sun Sep 04 03:21:31 2016] [error]   File "parser.pxi", line 539, in
lxml.etree._ParserContext._handleParseResultDoc
(src/lxml/lxml.etree.c:63824)
[Sun Sep 04 03:21:31 2016] [error]   File "parser.pxi", line 625, in
lxml.etree._handleParseResult (src/lxml/lxml.etree.c:64745)
[Sun Sep 04 03:21:31 2016] [error]   File "parser.pxi", line 576, in
lxml.etree._raiseParseError (src/lxml/lxml.etree.c:64260)
[Sun Sep 04 03:21:31 2016] [error] XMLSyntaxError: None


restarting httpd fixed the issue. Thanks!

Looking into apache never occurred to me, freeipa really is a web service
although it provides infrastructure services.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format.

[Natxo Asenjo]

On Wed, Sep 7, 2016 at 2:10 PM, Natxo Asenjo <natxo.ase...@gmail.com> wrote:

> hi,
>
> using centos 6.8 (server and client), when trying to view some hosts we
> get this error:
>
>
> $ ipa host-find host-1920.sub.domain.tld
> ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The
> certificate/key database is in an old, unsupported format.
>

this is happening wih all the host objects (all enrolled with
certificates). I don't usually look at the hosts objects that much, but
yesterday patches were applied and the ipa-server package was updated
(among other things):

Updated ipa-server-3.0.0-50.el6.centos.1.i686
Update 3.0.0-50.el6.centos.2.i686

So it looks like this is the culprit?


--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format.

[Natxo Asenjo]

hi,

using centos 6.8 (server and client), when trying to view some hosts we get
this error:


$ ipa host-find host-1920.sub.domain.tld
ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The
certificate/key database is in an old, unsupported format.


I saw a thread last year about this, but no solution.

Any clues?

Thanks
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] what is the best way to create a search account

[Natxo Asenjo]

hi Rob,

On Thu, Jun 30, 2016 at 1:22 PM, Rob Verduijn 
wrote:

> Hello,
>
>
> What would be the most appropriate way to create a search account so that
> a third party tool (wildfly) can use it to search the ipa domain for
> credentials ?
>

I just create a normal account. We rotate passwords on a regular basis, but
you could just set the krbpasswordexpiration attribute far in the future.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] multiple ds instances (maybe off-topic)

[Natxo Asenjo]

hi Ludwig,

On Tue, Jun 28, 2016 at 10:03 AM, Ludwig Krispenz <lkris...@redhat.com>
wrote:

>
> On 06/28/2016 09:50 AM, Natxo Asenjo wrote:
>
>
> I'd like to have internally all sort of ldap access, but externally onlly
> certificate based, for example.
>
> If there is a way to do that know that I am not aware of I'd be very
> interested to know it as well ;-). Right now we solve this problems using
> vpn connections with third parties, but ideally one could just open the
> port to the internet if only that kind of access was allowed.
>
> maybe you can achieve this with access control, there are all kind of
> rules to allow access based on client's ip address, domain, security
> strength, authentication method - and combinations of them.
> <https://www.redhat.com/mailman/listinfo/freeipa-users>
>

Do you mean something like explained here:
http://directory.fedoraproject.org/docs/389ds/design/rootdn-access-control.html
?

Thanks!
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] multiple ds instances (maybe off-topic)

[Natxo Asenjo]

On Tue, Jun 28, 2016 at 9:07 AM, Alexander Bokovoy <aboko...@redhat.com>
wrote:

> On Tue, 28 Jun 2016, Natxo Asenjo wrote:
>
>> hi,
>>
>> according to the RHDS documentation (
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html-single/Using_the_Admin_Server/index.html
>> )
>> one can have multiple directory server instances on the same hosts
>>
>> Would it be interesting to offer this functionality in freeipa.org? The
>> business case would be to allow different kinds of authentication per
>> instance/port. So one could block standard ldap connections on port 389 to
>> the internet, for instance, but allow them on another port only if using
>> external/GSSAPI auth, so no passswords would be involved.
>>
> This is not how instances work in 389-ds. Each instance is fully
> independent of another one, including database content and structure.
> You cannot have instance that shares the same content with another one
> unless you enable database chaining (and then there are some
> limitations).
>

ok, thanks for the info.


> We used to have CA instance separate from the main IPA instance, for
> example, but then merged them together in the same instance using two
> different backends.
>
> Standard IPA 389-ds instance already allows its access on the unix domain
> socket with EXTERNAL/GSSAPI authentication. It is visible only within
> the scope of the IPA master host, of course.
>
> I'm still not sure what exactly you would like to achieve. All ports
> that 389-ds listens to do support the same authentication methods except
> LDAPI protocol (unix domain sockets) which supports automapping between
> POSIX ID and a user object that it maps to.
>

I'd like to have internally all sort of ldap access, but externally onlly
certificate based, for example.

If there is a way to do that know that I am not aware of I'd be very
interested to know it as well ;-). Right now we solve this problems using
vpn connections with third parties, but ideally one could just open the
port to the internet if only that kind of access was allowed.


Thanks for your time.

-- 
regards,
Natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] multiple ds instances (maybe off-topic)

[Natxo Asenjo]

hi,

according to the RHDS documentation (
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html-single/Using_the_Admin_Server/index.html)
one can have multiple directory server instances on the same hosts

Would it be interesting to offer this functionality in freeipa.org? The
business case would be to allow different kinds of authentication per
instance/port. So one could block standard ldap connections on port 389 to
the internet, for instance, but allow them on another port only if using
external/GSSAPI auth, so no passswords would be involved.

This would be useful for external services not using saml, for instance.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Install best practice -

[Natxo Asenjo]

On Mon, May 30, 2016 at 7:14 AM, Ben .T.George 
wrote:

> Hi
>
> thanks for the reply.
>
> "the easiest would be to create a zone and delegating that to the ipa
> hosts. No other change necessary."
>
> can you explain little more. You mean need to create separate DNS zone ?
>
>
create a zone in your dns appliances unix.example.com.kw (name it what you
like). Delegate the dns managment of that zone to the freeipa dns
servers/domain controllers. Create glue records so clients can find those
servers.

A normal dns delegated zone, in short.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Install best practice -

[Natxo Asenjo]

On Sun, May 29, 2016 at 7:11 PM, Ben .T.George 
wrote:

> Hi
>
> I would like to know how can i proceed with best practices
>
> My AD domain is : corp.examle.com.kw
> My DNS (appliances ) : kw.test.com
>
> All my clients are pointed to kw.test.com including AD.
>
> How can i proceed with Free IPA installation? where i need to manage DNS
> of freeipa master server?
>
>
> creating new DNS zone in kw.test.com will be little bit difficult.
>
> which will be best configuration with minimal changes in existing setup.
>

the easiest would be to create a zone and delegating that to the ipa hosts.
No other change necessary.

Not sure if this is a 'best practice', but this is how we have been running
our environment for years without any problems.

-- 
regards,
Natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Unexpiring user passwords

[Natxo Asenjo]

On Sun, May 1, 2016 at 4:53 AM, Joshua J. Kugler  wrote:


> We have a situation where the passwords in FreeIPA need to be synchronized
> with another system in the company (a database of users, which is the
> authoritative source for users and passwords).  But, from what I read, the
> documentation is telling me we can't do that, because if we followed this
> work
> flow:
>
> 1. Users goes to "master DB" and changes their password
> 2. master DB runs a script which sets password on FreeIPA system
> 3. User's login is now broken because the password is expired.
>

leaving the design/philosophy aside, you could modify your users'
krbpasswordexpiration ldap attribute in your script that changes the
freeipa password from your master DB password source. It's quite simple
using your ldap tools of choice.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-client-install errors

[Natxo Asenjo]

hi Gady,

On Wed, Apr 20, 2016 at 8:11 PM, Gady Notrica  wrote:

> Any specific command in particular to remove that keytab?
>
> Since these don't work
>
> [root@cprddb1 /]# ipa-rmkeytab -r DOMAIN.COM -k /etc/krb5.keytab
> Kerberos context initialization failed
> [root@prddb1 /]# ipa-rmkeytab -p ldap/prddb1.ipa.domain.com -k
> /etc/krb5.keytab
> Kerberos context initialization failed


I think that you just need to rm /etc/krb5.keytab and remove the host
object in the web interface if it exists.

-- 
groet,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] howto ldapsearch for disabled/enabled users?

[Natxo Asenjo]

hi Harald,
On Fri, Apr 15, 2016 at 1:31 PM, Harald Dunkel 
wrote:

> Hi folks,
>
> I have no luck with the ipa cli, so I wonder if it is
> possible to ldapsearch for disabled or enabled users?
> A command line like
>
> ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=com
> uid=somebody
>
> doesn't show :-(.


I just tested using the public demo1.freeipa.org instance and it works
using the 'hidden' nsaccountlock attribute:

$ ldapsearch -LLL -Y GSSAPI -h ipa.demo1.freeipa.org -b
cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org "(nsaccountlock=TRUE)" uid
SASL/GSSAPI authentication started
SASL username: helpd...@demo1.freeipa.org
SASL SSF: 56
SASL data security layer installed.
dn: uid=test,cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org
uid: test

dn: uid=bladibla,cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org
uid: bladibla

I found out about the nsaccountlock in
https://www.mail-archive.com/search?l=freeipa-de...@redhat.com=subject:%22Re\%3A+\[Freeipa\-devel\]+User+status%22=newest=1
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IPA command to batch create users.

[Natxo Asenjo]

hi,

On Thu, Mar 24, 2016 at 8:14 PM, Armstrong, Jeffrey <
jeffrey.armstr...@gasoc.com> wrote:

> Hello,
>
>
>
> I would like to find out if I can create a large number of users in IPA at
> one time.  If so, what is the command to do that.
>
>
>

you can use ipa user-add command in a bash loop, or read the user names
from a file, feeding that file to ipa user-add.

-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] is it possible to add a value to the group 'mail' attrirbute?

[Natxo Asenjo]

hi,

On Fri, Mar 18, 2016 at 6:14 AM, Alexander Bokovoy <aboko...@redhat.com>
wrote:

> On Thu, 17 Mar 2016, Natxo Asenjo wrote:
>
>> hi,
>>
>> see subject. For user accounts it's possible (even multivalued),
>>
>> Adding it using an ldap client gives me error 65 (attribute 65 not
>> allowed).
>>
> In order to add *any* attribute to *any* LDAP entry you need two
> conditions to be satisfied:
>
> 1. LDAP entry in question should have object class that allows this
>attribute
> 2. Authenticated user should have ACI that allows to add this attribute
>to this entry
>
> 'Attribute not allowed' means condition (1) is not satisfied. FreeIPA
> LDAP server has three object classes by default that allow you to add mail
> attribute to an entry:
>  -- inetOrgPerson
>  -- mailRecipient
>  -- mailGroup
>
> I'd say that if you want to associate mail with a group, mailGroup
> would be a better object class to use. It is an auxiliary object class,
> meaning it only adds some attributes to an entry and there should exist
> more fundamental classes (we have them for group already).
>
> As for (2), admins should have enough rights to modify 'mail' attribute
> and 'objectclass' attribute on group entries
>

thanks for your explanation. I have added the mailGroup objectclass to the
default group objectclasses group options in 'configurarion' and now I can
add the entry. This post helped too:
https://www.redhat.com/archives/freeipa-users/2014-February/msg00050.html

Thanks!


--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] user certificate ldap EXTERNAL authentication

[Natxo Asenjo]

On Mon, Mar 7, 2016 at 9:14 AM, Martin Kosek <mko...@redhat.com> wrote:

> On 03/05/2016 06:00 AM, Rob Crittenden wrote:
> > Natxo Asenjo wrote:
> >>
> >> By the way, revoking the certificate does not block applications using
> >> it from ldap.
> >>
> >> I can still access the ldap server using this cert/key pair *after*
> >> revoking the certificate using ipa cert-revoke . In order to
> >> block it I need to remove the seeAlso value of the user account, or the
> >> certificate attribute.
> >>
> >> I do not know if this is a security issue, but maybe worthwhile
> >> documenting just in case.
> >
> > SSL/TLS servers don't automatically check for cert revocation. You need
> > to add the CRL to the 389-ds NSS database periodically. I don't know for
> > sure but I don't think 389-ds can use OCSP to validate incoming client
> > certs. There is an IPA ticket in the backlog to investigate this for the
> > web and ldap servers: https://fedorahosted.org/freeipa/ticket/3542
> >
> > And yeah, as you discovered, managing the value of CmapLdapAttr is a
> > poor man's revocation.
>
> I saved Natxo's contributed article here:
>
> http://www.freeipa.org/page/Howto/Client_Certificate_Authentication_with_LDAP
> for now.
>


Thanks!


> My take on this is that it probably works, but I am curious actually what
> problem you are solving. Are you interested only in allowing Certificate
> authentication with FreeIPA LDAP or rather in allowing certificate
> authentication in your application, whatever are the means?
>

both :-). Having name/password combinations in application settings is less
desirable than having certificate/key paths. I know both accomplish the
same thing (authenticate to the directory), but having certificates is less
controversial (no need for third parties to know *that* password that is
probably being used somewhere else as well, for instance. Having a simple
way to 'revoke' the access is nice as well.



> If this is the case, would leveraging SSSD Smart Card/certificate
> authentication help? At minimum, it can lookup users by certificate:
>
> https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate
>
> With leveraging SSSD, you should be able to avoid manual user mapping in
> FreeIPA LDAP. I am not sure though how the revocation would work. CCing
> Sumit
> on this one


Interesting, I did not know about this possibility of sssd. I need to read
it through, it might address our needs. Thanks for pointing me to it.

What in my opinion would be really interesting would be to have something
similar to the submission port on smtp servers. A different instance of the
directory where only some kind of authentication are possible.

Right now when using port 389 I can choose between a combination of SASL
mechanisms, and if in dse.ldif anonymous auth and minssf are modified, then
I can force the usage of secure protocols. What I would like is to have a
way to disable password authentication mechanisms on a ldap port, while
keeping it enabled on the other. So we could close one port to the outside
world, and keep it open on the LAN, for instance.

Is this even possible?

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] user certificate ldap EXTERNAL authentication

[Natxo Asenjo]

By the way, revoking the certificate does not block applications using it
from ldap.

I can still access the ldap server using this cert/key pair *after*
revoking the certificate using ipa cert-revoke . In order to
block it I need to remove the seeAlso value of the user account, or the
certificate attribute.

I do not know if this is a security issue, but maybe worthwhile documenting
just in case.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] user certificate ldap EXTERNAL authentication

[Natxo Asenjo]

On Fri, Mar 4, 2016 at 11:00 PM, Simo Sorce <s...@redhat.com> wrote:

> On Fri, 2016-03-04 at 14:34 -0500, Rob Crittenden wrote:
> > Natxo Asenjo wrote:
>
> > > when I go to http://www.freeipa.org/page/Special:OpenIDLogin to login
> > > with the fedora account I get
> > >
> > >
> > >   OpenID error
> > >
> > > An error occurred: an invalid token was found.
> > >
> > > Return to Main Page <http://www.freeipa.org/page/Main_Page>.
> > >
> > >
> > > So, sorry, I cannot edit the contribute to the wiki. I will write
> > > something down in my own wiki and post the link here, search engines
> > > will index this mailing list posts as well, so this knowledge will not
> > > go lost.
> >
> > It's not just you. I can't login either. I think Martin will need to
> > poke at this on Monday.
>
> I tried this just now and it worked, maybe there was an issue that has
> since resolved itself ?
>

no, same error.

O well, I have this howto, just copy paste it from my mediawiki (public
domain):

https://asenjo.nl/wiki/index.php/Client_certificate_authentication_ipa

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] user certificate ldap EXTERNAL authentication

[Natxo Asenjo]

On Fri, Mar 4, 2016 at 4:58 PM, Natxo Asenjo <natxo.ase...@gmail.com> wrote:

>
>
> On Fri, Mar 4, 2016 at 3:43 PM, Rob Crittenden <rcrit...@redhat.com>
> wrote:
>
>> Ah right. Because all the subjects are the same base the same map will
>> be used for both DS and the CA.
>>
>> Any chance you could write up a HOWTO on this?
>
>
> Gladly, but I seem unable to login using my recently created fedora
> account. I will try later in the evening again.
>
>
when I go to http://www.freeipa.org/page/Special:OpenIDLogin to login with
the fedora account I get

OpenID error

An error occurred: an invalid token was found.

Return to Main Page <http://www.freeipa.org/page/Main_Page>.


So, sorry, I cannot edit the contribute to the wiki. I will write something
down in my own wiki and post the link here, search engines will index this
mailing list posts as well, so this knowledge will not go lost.


-- 

regards,

natxo

-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] user certificate ldap EXTERNAL authentication

[Natxo Asenjo]

On Fri, Mar 4, 2016 at 3:43 PM, Rob Crittenden  wrote:

> Ah right. Because all the subjects are the same base the same map will
> be used for both DS and the CA.
>
> Any chance you could write up a HOWTO on this?


Gladly, but I seem unable to login using my recently created fedora
account. I will try later in the evening again.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] user certificate ldap EXTERNAL authentication

[Natxo Asenjo]

hi,


On Thu, Mar 3, 2016 at 10:57 PM, Rob Crittenden <rcrit...@redhat.com> wrote:

> Natxo Asenjo wrote:
>


> > Using EXTERNAL, no cookie:
> > $ ldapsearch -h kdc.sub.domain.tld -ZZ -Y EXTERNAL -LLL
> > objectclass=person -s sub -b dc=sub,dc=domain,dc=tld cn
> > SASL/EXTERNAL authentication started
> > ldap_sasl_interactive_bind_s: Invalid credentials (49)
> > additional info: client certificate mapping failed
> >
> > I came accross this page in the 389 wiki:
> >
> >
> http://directory.fedoraproject.org/docs/389ds/howto/howto-certmapping.html
> >
> > But I am not really sure how to accomplish this.
> >
> > Is this possible in freeipa?
>
> I don't see why not. You just need to be able to map the subject of the
> cert to a single entry. That's what certmap.conf attempts to do.
>
>

ok, I got it working  but it took some effort.

Let's see, in certmap.conf the config is like this out of the box:

certmap default default
#default:DNComps
#default:FilterCompse, uid
#default:verifycert on
#default:CmapLdapAttr   certSubjectDN
#default:library
#default:InitFn 
default:DNComps
default:FilterComps uid
certmap ipaca   CN=Certificate Authority,O=SUB.DOMAIN.TLD
ipaca:CmapLdapAttr  seeAlso
ipaca:verifycerton

So, there is an additional mapping for ipaca, which is handy. But the
CmapLdapAttr points to 'seeAlso', and if you change that to
usercertificate;binary (where the usercertificates are), the tomcat pki
service will no longer start because

DN: uid=pkidbuser,ou=people,o=ipaca

has this seealso attribute: CN=CA Subsystem,O=SUB.DOMAIN.TLD

so we cannot change te cmapldapattr to something else, but we can add a
seealso attribute to the user account, like cn=username,o=SUB.DOMAIN.TLD .
And then it works.

This could be very handy for web applications.

Nice. Thanks for the pointer.

Regards,
Natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] user certificate ldap EXTERNAL authentication

[Natxo Asenjo]

hi,

I am testing certificate authentication to ipa ldap ( centos 7.2 ).

I have generated a user certificate following the instructions on
https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/

After that I modified my $HOME/.ldaprc with these settings:

TLS_CERT /path/to/user10.pem
TLS_KEY /path/to/user10.key

The certificate has this subject:
$ openssl x509 -in user10.pem -subject -noout
subject= /O=SUB.DOMAIN.TLD/CN=user10

Then I try ldapsearch:

using GSSAPI, ldapsearch works fine:
ldapsearch -h kdc1.sub.domain.tld -ZZ -Y GSSAPI objectclass=person -s sub
-b dc=sub,dc=domain,dc=tld cn


# search result
search: 5
result: 0 Success

# numResponses: 1002
# numEntries: 1001

Using EXTERNAL, no cookie:
$ ldapsearch -h kdc.sub.domain.tld -ZZ -Y EXTERNAL -LLL objectclass=person
-s sub -b dc=sub,dc=domain,dc=tld cn
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: client certificate mapping failed

I came accross this page in the 389 wiki:

http://directory.fedoraproject.org/docs/389ds/howto/howto-certmapping.html

But I am not really sure how to accomplish this.

Is this possible in freeipa?

Thanks in advance.

Regards,
Natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Traceback starting pki-cad - ca.subsystem.certreq missing?

[Natxo Asenjo]

On Sat, Feb 20, 2016 at 5:58 PM, Ian Pilcher  wrote:

> I am running IPA 3.0.0 on CentOS 6 (32-bit x86), and I am getting a
> traceback every time pki-cad starts:
>
> Traceback (most recent call last):
>   File "/usr/sbin/pki-server", line 89, in 
> cli.execute(sys.argv)
>   File "/usr/sbin/pki-server", line 84, in execute
> super(PKIServerCLI, self).execute(args)
>   File "/usr/lib/python2.6/site-packages/pki/cli.py", line 195, in execute
> module.execute(module_args)
>   File "/usr/lib/python2.6/site-packages/pki/server/cli/upgrade.py", line
> 103, in execute
> scriptlet.execute()
>   File "/usr/lib/python2.6/site-packages/pki/server/upgrade/__init__.py",
> line 50, in execute
> cert = self.subsystem.get_system_cert('subsystem')
>   File "/usr/lib/python2.6/site-packages/pki/server/__init__.py", line 93,
> in get_system_cert
> cert['request'] = base64.b64decode(self.config['%s.%s.certreq' %
> (self.prefix, tag)])
> KeyError: 'ca.subsystem.certreq'
> Starting pki-ca:   [  OK  ]
>
> As you can see, the daemon does still start successfully, and the
> traceback doesn't appear in any of the pki-cad logs.
>
>
yes, I see this too after the last round of updates. Curiously enough, just
on one of the kdcs, the other does not have this traceback.

Both are centos 6.7 fully patched, 32 bits.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] how to force switch to another kdc

[Natxo Asenjo]

On Tue, Jan 5, 2016 at 7:31 PM, Natxo Asenjo <natxo.ase...@gmail.com> wrote:

> includedir /var/lib/sss/pubconf/krb5.include.d/
> #File modified by ipa-client-install
>
> [libdefaults]
>   default_realm = IPA.DOMAIN.TLD
>   dns_lookup_realm = true
>   dns_lookup_kdc = true
>   rdns = false
>   ticket_lifetime = 24h
>   forwardable = yes
>
> [realms]
>   IPA.DOMAIN.TLD = {
> pkinit_anchors = FILE:/etc/ipa/ca.crt
>   }
>
> [domain_realm]
>   .ipa.domain.tld = IPA.DOMAIN.TLD
>   ipa.domain.tld = IPA.DOMAIN.TLD
>
> ]$ cat /etc/krb5.conf
>

with this config I can reach any realm, by the way, provided it has srv
records. It works for our AD forests as well.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] how to force switch to another kdc

[Natxo Asenjo]

On Tue, Jan 5, 2016 at 7:22 PM, Karl Forner  wrote:

> update:
>
> modifying the /etc/krb5.conf, and replacing the name of my freeipa master
> by the replica fixes the problem.
> So that proves that the kdc is not picked up by discovery.
>
> The problem is that my ubuntu box was enrolled using the
> ipa-client-install script, and so should be properly configured.
>
> Did I miss any critical option ?
> What should the /etc/krb5.conf be like ?
>

Could you post your krb5.conf ?

This is a working example in a centos 6 host:

al-only additions here, put content in /etc/motd-local ##
]$ cat /etc/krb5.conf
includedir /var/lib/sss/pubconf/krb5.include.d/
#File modified by ipa-client-install

[libdefaults]
  default_realm = IPA.DOMAIN.TLD
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes

[realms]
  IPA.DOMAIN.TLD = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
  }

[domain_realm]
  .ipa.domain.tld = IPA.DOMAIN.TLD
  ipa.domain.tld = IPA.DOMAIN.TLD

-- 
regards,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Any recent guides for Postfix and IPA integration?

[Natxo Asenjo]

On Fri, Dec 11, 2015 at 11:32 PM, Ranbir <m3fr...@thesandhufamily.ca> wrote:

> On Fri, 2015-12-11 at 22:13 +0100, Natxo Asenjo wrote:
> > what exactly do you want to achieve? 'Integrate' could mean a couple
> > of things, so please specify.
>




> I would like to move postfix and dovecot to use IPA for sasl auth and
> for managing the virtual mailboxes. I have a good idea of how this is
> all supposed to work together. What I need are the actual steps to get
> it done.
>

so what have you tried?

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Any recent guides for Postfix and IPA integration?

[Natxo Asenjo]

hi Ranbir,


On Fri, Dec 11, 2015 at 9:29 PM, Ranbir  wrote:

> Hi All,
>
> I want to integrate my Postfix server with IPA. I've found a couple of
> documents on how this can be done, but they don't accomplish the feat
> the same way (they're also not discussing the exact same end goal). I'm
> left wondering how exactly to integrate IPA and Postfix.
>
>
what exactly do you want to achieve? 'Integrate' could mean a couple of
things, so please specify.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Squid authentication in FreeIPA

[Natxo Asenjo]

hi holo,


On Fri, Nov 20, 2015 at 11:21 PM, holo  wrote:

> Thank you for your reply.
>
> I think i wasnt clear enough. Clients of proxy server are not kerberized.
> I want to just authenticate them for proxy use in kerberos DB when they are
> trying to use it (just by popup like in NTLM). Is such thing possible with
> kerberos? I saw on yt such thing wasa posible with AD.
>
> //holo
>

did you ask this question in serverfault as well :-) ?

http://serverfault.com/questions/737902/squid-kerberos-authentication-no-popup/737909#737909

If you require ntlm, then you should joing the squid host to an AD realm, I
do not think this will work with freeipa because it does not do ntlm as far
as I know.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] LDAP creditentials for Squid

[Natxo Asenjo]

hi,

On Fri, Nov 20, 2015 at 10:47 PM, holo  wrote:

> Hello
>
> How can i find FreeIPA ldap creditentials? I want to try to configure
> Squid in similar way like it is described here for ejabberd:
>
>
> http://www.freeipa.org/page/EJabberd_Integration_with_FreeIPA_using_LDAP_Group_memberships
>
>
I do not understand the question. Do you want to user ldap with squid?

Then you need to configure an authentication helper in squid. You will find
how to do that in the squid wiki:

http://wiki.squid-cache.org/ConfigExamples/Authenticate/Ldap

And for squid acls dependeing on ldap group membership take a look at the
examples here:

https://workaround.org/squid-ldap/

If you have trouble configuring squid, then you should ask on the squid
mailing list (very active, very helpful).
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7

[Natxo Asenjo]

On Thu, Nov 19, 2015 at 11:03 PM, Ash Alam  wrote:

> Hello All
>
> I am looking for some advice on upgrading. Currently our FreeIPA servers
> are 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7. This
> upgrade path is not possible per IPA documentation. Minimum version
> required is 3.3.x. I have also found that cenos6 does not provide anything
> past 3.0.0.
>
>
do you mean upgrading the systems themselves? Why don't you install a
centos 7 host and join it as domain controller to the existing realm?

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html

I have tested the procedure a couple of times and it works really well. I
just came up with one issue which you can read here:

https://www.redhat.com/archives/freeipa-users/2015-September/thread.html#00161

-- 
groet,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] crl url redirecting to https

[Natxo Asenjo]

hi,

I just noticed some stuff was not functioning properly and it's because the
crl url is being redirected to https (centos 6.7).


$ curl http://kdc01.unix.domain.tld/ipa/crl/


301 Moved Permanently

Moved Permanently
The document has moved https://kdc01.unix.domain.tld/ipa/crl/
">here.

Apache/2.2.15 (CentOS) Server at kdc01.unix.domain.tld Port
80


This is ipa-rewrite.conf, it should not be happening, but it does:

$ cat ipa-rewrite.conf
# VERSION 3 - DO NOT REMOVE THIS LINE

RewriteEngine on

# By default forward all requests to /ipa. If you don't want IPA
# to be the default on your web server comment this line out.
RewriteRule ^/$ https://kdc01.unix.iriszorg.nl/ipa/ui [L,NC,R=301]

# Redirect to the fully-qualified hostname. Not redirecting to secure
# port so configuration files can be retrieved without requiring SSL.
RewriteCond %{HTTP_HOST}!^kdc01.unix.iriszorg.nl$ [NC]
RewriteRule ^/ipa/(.*)  http://kdc01.unix.iriszorg.nl/ipa/$1 [L,R=301]

# Redirect to the secure port if not displaying an error or retrieving
# configuration.
RewriteCond %{SERVER_PORT}  !^443$
RewriteCond %{REQUEST_URI}  !^/ipa/(errors|config)
RewriteRule ^/ipa/(.*)  https://kdc01.unix.iriszorg.nl/ipa/$1
[L,R=301,NC]

Any ideas on how to fix this?

Thanks!
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] crl url redirecting to https

[Natxo Asenjo]

hi,

On Tue, Nov 10, 2015 at 5:02 PM, Rob Crittenden <rcrit...@redhat.com> wrote:

> Natxo Asenjo wrote:> Any ideas on how to fix this?
>
> You should have a sections like these in /etc/httpd/conf.d/ipa.conf:
>
> 
>   SetHandler None
> 
> ...
> # For CRL publishing
> Alias /ipa/crl "/var/lib/ipa/pki-ca/publish"
> 
>   SetHandler None
>   AllowOverride None
>   Options Indexes FollowSymLinks
>   Satisfy Any
>   Allow from all
> 
>

yes, it's all there. I restarted httpd just in case, but it remains the
same. I get a 301 moved permantently to https.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] crl url redirecting to https

[Natxo Asenjo]

but going back to ipa-rewrite.conf, these 2 seem contradictory:

# Redirect to the fully-qualified hostname. Not redirecting to secure
# port so configuration files can be retrieved without requiring SSL.
RewriteCond %{HTTP_HOST}!^kdc01.unix.iriszorg.nl$ [NC]
RewriteRule ^/ipa/(.*)  http://kdc01.unix.iriszorg.nl/ipa/$1 [L,R=301]

# Redirect to the secure port if not displaying an error or retrieving
# configuration.
RewriteCond %{SERVER_PORT}  !^443$
RewriteCond %{REQUEST_URI}  !^/ipa/(errors|config)
RewriteRule ^/ipa/(.*)  https://kdc01.unix.iriszorg.nl/ipa/$1
[L,R=301,NC]

so I modified

RewriteCond %{REQUEST_URI}  !^/ipa/(errors|config)

with

RewriteCond %{REQUEST_URI}  !^/ipa/(errors|config|crl)

and now it works.

Is this ok?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] mastercrl files

[Natxo Asenjo]

hi,

do we need to keep all the MasterCRL-MMDD-HHMMSS.der files or can we
purge them on a regular basis (say, keep 60 days dump the rest)?

$ ls -l | wc -l
3621

this is in a server installed 3 years ago.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] First tests against the REST/JSON API

[Natxo Asenjo]

hi,

On Mon, Nov 9, 2015 at 6:58 PM, Oliver Dörr  wrote:

> Hi,
>
> I'm completly new to this list and the product behind it. I'm trying to
> use perl to get a list from my IPA installation of all users that are on
> the server.
>

unfortunately I cannot help you right now, but have you taken a look at
this blog post:

https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/

It could give you some pointers.

Share your code if you get it to work :-)

Thanks.

--
regards,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] gssapi ssh works, pam user/password does not work

[Natxo Asenjo]

On Thu, Nov 5, 2015 at 10:03 AM, Natxo Asenjo <natxo.ase...@gmail.com>
wrote:

> hi,
>
> since yesterday I have a strange situation in one of our joined hosts.
>
> i can login using a kerberos ticket, but not using name/password.
>
> In /var/log/secure I see this:
>
> sshd[29607]: pam_sss(sshd:auth): received for user username: 4 (System
> error)
>

sorry, sent too early.

how can I troubleshoot this issue?

-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] gssapi ssh works, pam user/password does not work

[Natxo Asenjo]

hi,

since yesterday I have a strange situation in one of our joined hosts.

i can login using a kerberos ticket, but not using name/password.

In /var/log/secure I see this:

sshd[29607]: pam_sss(sshd:auth): received for user username: 4 (System
error)

-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] gssapi ssh works, pam user/password does not work

[Natxo Asenjo]

hi,

this is in a centos host running 6.7, by the way.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] gssapi ssh works, pam user/password does not work

[Natxo Asenjo]

hi,

Fixed, /tmp had the wrong permissions, was not owned by root:root.

Thanks for the debugging tips!



-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] gssapi ssh works, pam user/password does not work

[Natxo Asenjo]

hi Sumit,

On Thu, Nov 5, 2015 at 10:14 AM, Sumit Bose  wrote:

> > how can I troubleshoot this issue?
>
> You should check the SSSD debug logs, see
> https://fedorahosted.org/sssd/wiki/Troubleshooting for details about how
> to enable debug logging and where to find the logs.
>
> My guess is that SSSD has issues reaching a server so the domain log and
> the krb5_child log would be the files I'd check first.
>
> If the logs don't help you feel free to send them directly to me, if
> possible with debug level 10.
>
> HTH
>
> bye,
> Sumit
>


I see this in krb5_child.log:

Thu Nov  5 10:23:50 2015) [[sssd[krb5_child[13083 [main] (0x0400):
krb5_child started.
(Thu Nov  5 10:23:50 2015) [[sssd[krb5_child[13083 [unpack_buffer]
(0x1000): total buffer size: [175]
(Thu Nov  5 10:23:50 2015) [[sssd[krb5_child[13083 [unpack_buffer]
(0x0100): cmd [241] uid [106336] gid [106336] validate [true]
enterprise principal [false] offline [false] UPN [
capitar.ad...@unix.iriszorg.nl]
(Thu Nov  5 10:23:50 2015) [[sssd[krb5_child[13083 [unpack_buffer]
(0x0100): ccname: [FILE:/tmp/krb5cc_106336_XX] old_ccname:
[FILE:/tmp/krb5cc_106336_DKHexY] keytab: [/etc/krb5.keytab]
(Thu Nov  5 10:23:50 2015) [[sssd[krb5_child[13083 [old_ccache_valid]
(0x0400): Saved ccache FILE:/tmp/krb5cc_106336_DKHexY doesn't exist,
ignoring
(Thu Nov  5 10:23:50 2015) [[sssd[krb5_child[13083
[k5c_check_old_ccache] (0x4000): Ccache_file is
[FILE:/tmp/krb5cc_106336_DKHexY] and is not active and TGT is not valid.
(Thu Nov  5 10:23:50 2015) [[sssd[krb5_child[13083
[k5c_precreate_ccache] (0x4000): Recreating ccache
(Thu Nov  5 10:23:50 2015) [[sssd[krb5_child[13083 [check_parent_stat]
(0x0020): Private directory can only be created below a directory belonging
to root or to [106336].
(Thu Nov  5 10:23:50 2015) [[sssd[krb5_child[13083 [create_ccache_dir]
(0x0010): Check the ownership and permissions of krb5_ccachedir: [/tmp].
(Thu Nov  5 10:23:50 2015) [[sssd[krb5_child[13083
[k5c_precreate_ccache] (0x0040): ccache creation failed.
(Thu Nov  5 10:23:50 2015) [[sssd[krb5_child[13083 [k5c_ccache_setup]
(0x0040): Cannot precreate ccache
(Thu Nov  5 10:23:50 2015) [[sssd[krb5_child[13083
[privileged_krb5_setup] (0x0020): k5c_ccache_setup failed.
(Thu Nov  5 10:23:50 2015) [[sssd[krb5_child[13083 [main] (0x0020):
privileged_krb5_setup failed.
(Thu Nov  5 10:23:50 2015) [[sssd[krb5_child[13083 [main] (0x0020):
krb5_child failed!



--
Groeten,
na
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] substitute local system groups by ipa groups

[Natxo Asenjo]

hi,

On Wed, Oct 14, 2015 at 8:35 PM, Rob Crittenden <rcrit...@redhat.com> wrote:

> Natxo Asenjo wrote:
> > hi,
> >
> > can you do something like this?
> >
> > ipa group-add wheel --gid=10
> >
> > to substitute the local group wheel? Of course nsswitch.conf indicates
> > local groups get found first ( group: files sss) but, would it work and
> > is it supported?
>
> What is it you expect or desire to happen in this case?
>

sorry, I thought it was obvious. To create a wheel ipa group. Members of
this group are automatically 'root'  in sudoers in plenty of distributions
( centos 7, just tested):

## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)   ALL

and in policykit I see this as well:

# cat 50-default.rules
/* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */

// DO NOT EDIT THIS FILE, it will be overwritten on update
//
// Default rules for polkit
//
// See the polkit(8) man page for more information
// about configuring polkit.

polkit.addAdminRule(function(action, subject) {
return ["unix-group:wheel"];
});


So there is already an existing infrastructure for the wheel group that is
waiting to be used ;-)

Hopefully this makes it clear.

-- 
regards,
natxo


-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ocsp server not respondig after migrating from centos 6.7 to 7.1

[Natxo Asenjo]

On Sat, Sep 12, 2015 at 9:43 AM, Natxo Asenjo <natxo.ase...@gmail.com>
wrote:

> hi,
>
> In a test network I followed the procedure especified in
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html
> to migrate from a centos 6.7 ipa server to a new centos 7 ipa server.
>
> Everything went fine, I shutdown the centos 6.7 host and i can kinit to
> the test realm like before with everything being handled by the centos 7.1
> ipa server.
>
> Unfortunately, firefox is not loading the web ui with the message:
>
> An error occurred during a connection to kdc2.unix.domain.tld. The OCSP
> server experienced an internal error. (Error code:
> sec_error_ocsp_server_error)
>
>
> Chrome works fine, it does not query the ocsp responder apparently. If I
> turn off the ocsp queries in firefox, everything works.
>
> So how can I troubleshoot this? I have turned off the firewall in the
> centos 7.1 hosts, selinux is permissive.
>

ok, so I found something:

 $ openssl s_client -connect kdc2.unix.domain.tld:443 | openssl x509 -noout
-text | grep -i ocsp
OCSP - URI:http://kdc1.unix.domain.tld:80/ca/ocsp

so it's pointing to the centos 6.7 box, and that one is gone. That's why
it's not working.

Shouldn't the certificates be modified or recreated when decommissioning
replicas? I must have done something wrong when decommissioning the server
...

Anyway, I created an A record for kdc1 pointing to kdc2 and now it's
working, but I wonder if this is the 'right' approach.


-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] ocsp server not respondig after migrating from centos 6.7 to 7.1

[Natxo Asenjo]

hi,

In a test network I followed the procedure especified in
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html
to migrate from a centos 6.7 ipa server to a new centos 7 ipa server.

Everything went fine, I shutdown the centos 6.7 host and i can kinit to the
test realm like before with everything being handled by the centos 7.1 ipa
server.

Unfortunately, firefox is not loading the web ui with the message:

An error occurred during a connection to kdc2.unix.domain.tld. The OCSP
server experienced an internal error. (Error code:
sec_error_ocsp_server_error)


Chrome works fine, it does not query the ocsp responder apparently. If I
turn off the ocsp queries in firefox, everything works.

So how can I troubleshoot this? I have turned off the firewall in the
centos 7.1 hosts, selinux is permissive.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] ipa-client-install --request-cert fails

[Natxo Asenjo]

hi,

on a a centos 7.1 host when enrolling it with (among other) the switch
--request-cert it does not create a host certificate for it. The host is
properly joined but not certificate is present.

In the ipaclient-install.log file I see this:

2015-09-12T09:34:02Z ERROR certmonger request for host certificate failed

but no other clue as to what went wrong.

How can I troubleshoot this?

Thanks!

-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-client-install --request-cert fails

[Natxo Asenjo]

On Sat, Sep 12, 2015 at 12:18 PM, Natxo Asenjo <natxo.ase...@gmail.com>
wrote:

> hi,
>
> on a a centos 7.1 host when enrolling it with (among other) the switch
> --request-cert it does not create a host certificate for it. The host is
> properly joined but not certificate is present.
>
> In the ipaclient-install.log file I see this:
>
> 2015-09-12T09:34:02Z ERROR certmonger request for host certificate failed
>

it's not working when joining a centos 6.7 realm either, same error.

-- 
regards,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] HBAC rules not applying to Solaris clients

[Natxo Asenjo]

On Sat, Aug 15, 2015 at 5:24 PM, Rob Crittenden rcrit...@redhat.com wrote:

 sipazzo wrote:


 and my users are able to authenticate to the directory but the hbac
 rules are not being applied. Any user whether given access or not can
 login to the Solaris systems. The allow-all rule has been disabled, my
 nsswitch.conf file looks good and I have tried different configs of
 pam.d, including the provided example to try to resolve the issue. Am I
 missing some steps?


 HBAC enforcement is provided by sssd so doesn't work in Solaris.


one might try using solaris' RBAC system:

http://www.oracle.com/technetwork/systems/security/custom-roles-rbac-jsp-140865.html

You would have to distribute your changes to all solaris systems.

There is a RBAC ldap schema
http://docs.oracle.com/cd/E19455-01/806-5580/6jej518q5/index.html for
solaris, but I have never tried using it with freeipa.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] OT: https://www.freeipa.org missing intermediate certificate

[Natxo Asenjo]

Hi,


Maybe just one more redirect if people come directly to https://freeipa.org?



$ curl -LIv https://freeipa.org
* Rebuilt URL to: https://freeipa.org/
* Hostname was NOT found in DNS cache
*   Trying 209.132.183.105...
* Connected to freeipa.org (209.132.183.105) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* Server certificate:
* subject: CN=*.redhat.com,OU=Web Operations,O=Red Hat
Inc,L=Raleigh,ST=North
Carolina,C=US,serialNumber=dmox-zPOCChZGgYyWu9xg8JTHSbjFg9P
* start date: Sep 09 18:07:24 2013 GMT
* expire date: Dec 12 02:08:43 2015 GMT
* common name: *.redhat.com
* issuer: CN=GeoTrust SSL CA,O=GeoTrust, Inc.,C=US
* NSS error -12276 (SSL_ERROR_BAD_CERT_DOMAIN)
* Unable to communicate securely with peer: requested domain name does not
match the server's certificate.
* Closing connection 0
curl: (51) Unable to communicate securely with peer: requested domain name
does not match the server's certificate.


$ curl -LIv https://www.freeipa.org
* Rebuilt URL to: https://www.freeipa.org/
* Hostname was NOT found in DNS cache
*   Trying 54.227.25.77...
* Connected to www.freeipa.org (54.227.25.77) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
* Server certificate:
* subject: CN=www.freeipa.org,O=Red Hat Inc.,L=Raleigh,ST=North
Carolina,C=US
* start date: Jul 16 00:00:00 2014 GMT
* expire date: Jul 19 12:00:00 2016 GMT
* common name: www.freeipa.org
* issuer: CN=DigiCert SHA2 High Assurance Server
CA,OU=www.digicert.com,O=DigiCert
Inc,C=US
 HEAD / HTTP/1.1
 User-Agent: curl/7.37.0
 Host: www.freeipa.org
 Accept: */*

 HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
 Date: Fri, 31 Jul 2015 08:09:29 GMT
Date: Fri, 31 Jul 2015 08:09:29 GMT
* Server Apache/2.2.15 (Red Hat) is not blacklisted
 Server: Apache/2.2.15 (Red Hat)
Server: Apache/2.2.15 (Red Hat)
 X-Content-Type-Options: nosniff
X-Content-Type-Options: nosniff
 Vary: Accept-Encoding,Cookie
Vary: Accept-Encoding,Cookie
 Expires: Thu, 01 Jan 1970 00:00:00 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
 Cache-Control: private, must-revalidate, max-age=0
Cache-Control: private, must-revalidate, max-age=0
 Last-Modified: Fri, 31 Jul 2015 08:09:29 GMT
Last-Modified: Fri, 31 Jul 2015 08:09:29 GMT
 Location: https://www.freeipa.org/page/Main_Page
Location: https://www.freeipa.org/page/Main_Page
 Content-Type: text/html; charset=utf-8
Content-Type: text/html; charset=utf-8


* Connection #0 to host www.freeipa.org left intact
* Issue another request to this URL: 'https://www.freeipa.org/page/Main_Page
'
* Found bundle for host www.freeipa.org: 0x1e1d850
* Re-using existing connection! (#0) with host www.freeipa.org
* Connected to www.freeipa.org (54.227.25.77) port 443 (#0)
 HEAD /page/Main_Page HTTP/1.1
 User-Agent: curl/7.37.0
 Host: www.freeipa.org
 Accept: */*

 HTTP/1.1 200 OK
HTTP/1.1 200 OK
 Date: Fri, 31 Jul 2015 08:09:29 GMT
Date: Fri, 31 Jul 2015 08:09:29 GMT
* Server Apache/2.2.15 (Red Hat) is not blacklisted
 Server: Apache/2.2.15 (Red Hat)
Server: Apache/2.2.15 (Red Hat)
 X-Content-Type-Options: nosniff
X-Content-Type-Options: nosniff
 Content-language: en
Content-language: en
 X-UA-Compatible: IE=Edge
X-UA-Compatible: IE=Edge
 Vary: Accept-Encoding,Cookie
Vary: Accept-Encoding,Cookie
 Expires: Thu, 01 Jan 1970 00:00:00 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
 Cache-Control: private, must-revalidate, max-age=0
Cache-Control: private, must-revalidate, max-age=0
 Last-Modified: Thu, 16 Jul 2015 13:22:10 GMT
Last-Modified: Thu, 16 Jul 2015 13:22:10 GMT
 Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8


* Connection #0 to host www.freeipa.org left intact


Thanks!


---

regards,

natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] OT: https://www.freeipa.org missing intermediate certificate

[Natxo Asenjo]

hi,

earlier today I was reading a post about the new freeipa version on my
mobile device and got plenty of warnings about an invalid certificate. On a
fedora laptop no warnings, but this is the problem:

$ curl -LIv  https://www.freeipa.org
* Rebuilt URL to: https://www.freeipa.org/
* Hostname was NOT found in DNS cache
*   Trying 54.227.25.77...
* Connected to www.freeipa.org (54.227.25.77) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* Server certificate:
* subject: CN=www.freeipa.org,O=Red Hat Inc.,L=Raleigh,ST=North
Carolina,C=US
* start date: Jul 16 00:00:00 2014 GMT
* expire date: Jul 19 12:00:00 2016 GMT
* common name: www.freeipa.org
* issuer: CN=DigiCert SHA2 High Assurance Server
CA,OU=www.digicert.com,O=DigiCert
Inc,C=US
* NSS error -8179 (SEC_ERROR_UNKNOWN_ISSUER)
* Peer's Certificate issuer is not recognized.
* Closing connection 0
curl: (60) Peer's Certificate issuer is not recognized.
More details here: http://curl.haxx.se/docs/sslcerts.html

You need to add the intermediate digicert certrificate, it seems.

Thanks!

-- 
regards,
natxo

-- 
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA and Rsyslog

[Natxo Asenjo]

On Fri, Jul 3, 2015 at 7:54 PM, Esdras La-Roque esdras.laro...@gmail.com
wrote:

 Hi guys,

 is it possible utilize freeipa certificate, issued for a machine,
 integrated in Rsyslog for redirection  remotely logs?


not with rsyslog, but with logstash and the logstash forwarder.

I tried with rsyslog and it worked following the rsyslog documentation on
tls/ssl.

-- 
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] hesitate to deploy freeipa

[Natxo Asenjo]

hi,

On Wed, Jun 24, 2015 at 9:06 AM, Harald Dunkel harald.dun...@aixigo.de
wrote:

 Hi folks,

 I have a general problem with freeipa: It is *highly* complex
 and depends upon too many systems working together correctly
 (IMHO).

 My concern is, if there is a problem, then the usual tools
 following the Unix paradigm (do one thing and do it well)
 don't help anymore. I can speak only for my own stomach, but
 it turns upside down when I think about this.


my 2 cents:

any organization growing its linux/unix computer park beneath a certain
threshold will come accross the problem of synchronizing its user and group
information accross the whole computer fleet.

On top of that, organizations are increasingly feeling the need to prove
(compliance, in management terms) that the communication protocols used to
exchange information between the internal systems are secure (this is
specially true in the US because of e-commerce laws, but also in post
Snowden Europe). So you need to use tls and kerberos  in your internal
communications.

You can try and run all that using the stock software by MIT/Heimdal,
coupled to openldap and openssl, but I pretty much doubt you will get a
nicer and easier to use product than what you already can get using freely
available software thanks to the Red Hat folks. I've done it, it worked but
it was complicated for new staff and difficult to delegate because
everything was cli based (not help-desk friendly).

Is it new and daunting at first? Sure, if you have never been exposed to
ldap/kerberos/tls before this is a lot to wrap your head into the first
time. But let me assure you, the protocol knowledge you will gain by
learning this will be a big win for you as an IT professional because you
will come across those systems everywhere (and certainly not only in linux
networks but anywhere where computers are used in an enterprise networks).

Besides these points, freeipa offers so much more. Thanks to sssd you can
actually have laptops leave the network and authenticate while on the road,
for intance, putting it on par with Windows on that point. You can use OTP
and two factor authentication for vpn netwoks. You can have a central
automounter. You can have true role based access control (these users may
login using  those protocols on those hosts, but not on the others). You
have centralized sudo rules. We will soon have subordinate certificate
authorities and user certificates. People are using the native ldap
database for plenty of applications (basically, most things you can used
ldap for), tying it to their configuration management solutions using
'legacy' netgroups databases. And obviously, people are integrating it into
their Windows AD infrastructure using kerberos trusts or plain ldap
replication.

There is room for improvement. I am looking forward to using smartcard
certificates with kerberos (PKINIT) for dumping user passwords (at least
admin passwords). SAML integrations (getting there with ipsilon), kerberos
trusts between ipa realms, ..., etc.

So the question is not really why you hesitate to deploy ipa, but why you
have not deployed it yet ;-)
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] host usercertificate attribute

[Natxo Asenjo]

hi rob,

On Mon, May 18, 2015 at 3:46 PM, Rob Crittenden rcrit...@redhat.com wrote:

 Natxo Asenjo wrote:

 On Sat, May 16, 2015 at 10:24 PM, Natxo Asenjo natxo.ase...@gmail.com
 mailto:natxo.ase...@gmail.com wrote:

 hi,

 If I retrieve the usercertificate attribute for host objects I get
 some gibberish.

 How can I decode the info I get from ldapsearch?


 maybe there is a way to feed that to openssl. What I ended up doing was
 using Perl and Crypt::X509 and I can see all the certificate elements.


 They are DER-encoded files. Something like this will show the contents:

 $ openssl x509 -text -in /tmp/file


$ openssl x509 -text -in ldapsearch-usercertificate-ZWnfJL
unable to load certificate
139637925009264:error:0906D06C:PEM routines:PEM_read_bio:no start
line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE

Apparently it misses some stuff.

As I wrote, I already got what I needed using perl, but maybe there are
other ways.

Thanks!
--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] host usercertificate attribute

[Natxo Asenjo]

hi Rob,

On Wed, May 20, 2015 at 2:08 PM, Rob Crittenden rcrit...@redhat.com wrote:

 Nat
 You could try adding -inform  DER


cool, that works ;-)

Thanks.

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] host usercertificate attribute

[Natxo Asenjo]

On Sat, May 16, 2015 at 10:24 PM, Natxo Asenjo natxo.ase...@gmail.com
wrote:

 hi,

 If I retrieve the usercertificate attribute for host objects I get some
 gibberish.

 How can I decode the info I get from ldapsearch?


maybe there is a way to feed that to openssl. What I ended up doing was
using Perl and Crypt::X509 and I can see all the certificate elements.

-- 
regards,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] host usercertificate attribute

[Natxo Asenjo]

hi,

If I retrieve the usercertificate attribute for host objects I get some
gibberish.

How can I decode the info I get from ldapsearch? The command I used was:

ldapsearch -b cn=computers,cn=accounts,dc=sub,dc=domain,dc=tldl -t -Y
gssapi -Z -h kdc01.sub.dmain.tld usercertificate

which creates individual files on /tmp with the info looking like this:



�0��*�H����0
  0;10U
.

Using the apache directory studio ldap browser I can see the certificate
information (subject, validity, etc), so it must be possible.

Is it base64 encoding?

TIA,

--
regards,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Common Name for the ipa-cacert-manage command

[Natxo Asenjo]

hi,

On Fri, May 1, 2015 at 12:52 AM, William Graboyes wgrabo...@cenic.org
wrote:


 I guess it is time to get deep into API documentation.  This is a hell of
 a lot of hoops to jump through just so that users who don't have shell
 access can easily change their passwords without having to see a scare
 page.  Distributing the IPA CA is not an option at this point, as we have a
 very odd desktop support model.  I thought all of this was to be fixed in
 4.1, which is why I went 4.1... and now nothing has changed... and I am
 back to square 1.


that is unfortunate for you. Most companies have at least AD deployed on
their infrastructure, and using that to deplay CA root certificates to all
domain member computers is very easy. For unix/linux networks system like
cfengine/puppet/whatever make this quite easy as well. So that is something
you need to address and not really IPA's fault in my opinion.

You could also deploy a password reset page using something like
http://ltb-project.org/wiki/documentation/self-service-password behind a
tls site with a certificate signed by one of the standard trusted
authoriteis like verising, digicert, etc. That way your users could reset
their passwords without the certificate errors and you could have the time
to put order in your desktop infrastructure ;-)


 This is the only, and I am serious here, the only gating factor for
 FreeIPA going into production.  The self-signed certs on the UI.  It really
 isn't safe or secure to tell users to Just trust the self signed cert.
 You create an easy vector for users to get sucked into a phishing trap.



Users are trained to just click warnings away, nothing new here.

The certificate system is quite ... special. Just because the standard
stores of the browsers trust a bunch of root CAs, does not mean that those
are safe. Think of diginotar. I trust our IPA root CA much more than
Turktrust Bilgi Iletisim ... (just the first one on the list of root CA's
on firefox now).



 Next question, Has anyone made or documented an external password change
 program for freeipa?


I already pointed this one
http://ltb-project.org/wiki/documentation/self-service-password, but there
are others. I have used gente: https://github.com/sciurus/gente as well,
really easy to set up and does it job. And there are plenty of commercial
solutions out there willing to get your money if you let them :-)

-- 
regards,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Setup of freeipa 4.1.3 failed

[Natxo Asenjo]

On Wed, Apr 8, 2015 at 7:57 AM, Markus Roth mar...@die5roths.de wrote:


 Yersterday I did the installation of freeipa on my banana Pi with
 modifying the source file ipalib/constants.py:('startup_timeout', 300).
 I changed it to 900 s. And the setup process was successful! The start of
 the CA had a duration of 630s! But after the installation freeipa is usable
 on the banana Pi.

 Thanks to Endi for help.


this is really cooll :-) Thanks for sharing,

If only one could get a small ssd on it starting up would be much faster.


--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] upgrade 3.0 - 4.1

[Natxo Asenjo]

hi,

On Fri, Apr 3, 2015 at 4:41 PM, Dmitri Pal d...@redhat.com wrote:

  On 04/03/2015 09:46 AM, Brian Topping wrote:

  On Apr 3, 2015, at 6:48 AM, Tamas Papp tom...@martos.bme.hu 
 tom...@martos.bme.hu wrote:

 hi All,

 I have CentOS 6.6 server and want to upgrade to 7.1.

 What is the upgrade path, can I do it directly or first I need to make it to 
 3.3?
 Also is there any known issue I should expect with workarounds?

  I just did this yesterday, so here's my experience. If you have a simple 
 single-server installation with no custom LDAP DIT modifications, you should 
 find yum upgrade does the right thing.

 If you do have DIT mods, you should ask yourself why they are there and 
 whether the data will still be accessible after the ACLs are changed. In my 
 case, I had Postfix using a LDAP hash and mail delivery stopped working 
 (although the domain data was still there just fine).

 Note that the ACLs will propagate from the 4.1 server to your 3.0 if they are 
 replicated. To be safe, back up all replicas (snapshot or whatnot) before the 
 first upgrade and if you decide to restore any of them, be sure everything is 
 shut down and restore all of them to avoid 4.x schema contaminating 3.0 as 
 they come up.



 The general recommendation for 3.3 - 4.1 migration is to start
 introducing 4.1 replicas into your 3.3 environment and then turn your 3.3
 replicas off. Do not forget to install the CA component with one of your
 4.1 replicas before removing all the 3.3 instanced with CAs. With this
 procedure you would also need to move the CRL generation and cert tracking.

 See details in migration section
 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#migrating-ipa-proc


 Will this excellent documentation work too on the migration from 3.0x
(rhel 6) to 4.1.x (rhel 7.1)?

I will be migrating the coming months to 7.1 or 7.2 (whichever is the
current stable then), so just wondering.

Thanks!

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IPA Client using Source Code

[Natxo Asenjo]

On Mon, Mar 30, 2015 at 10:48 AM, Yogesh Sharma yks0...@gmail.com wrote:

 Hi List,

 We have trying to install IPA-Client using source code. While installing
 we are seeing many error out of which most are resolved but stuck at below
 while doing make.

 Is there any suggestion to get out of it. I will update if I found
 anything.

 gcc -DHAVE_CONFIG_H -I. -I. -I. -DPREFIX=\/usr/local\
 -DBINDIR=\/usr/local/bin\ -DLIBDIR=\/usr/local/lib\
 -DLIBEXECDIR=\/usr/local/libexec\ -DDATADIR=\/usr/local/share\
 -I/usr/include/mozldap -I/usr/include/nspr4 -I/usr/include/nss3
 -DWITH_MOZLDAP-g -O2 -MT ipa-getkeytab.o -MD -MP -MF
 .deps/ipa-getkeytab.Tpo -c -o ipa-getkeytab.o ipa-getkeytab.c
 ipa-getkeytab.c:41:18: fatal error: popt.h: No such file or directory
  #include popt.h



in fedora I get these results:

$ sudo yum whatprovides */popt.h
Loaded plugins: langpacks
golang-src-1.3.3-1.fc21.noarch : Golang compiler source tree
Repo: fedora
Matched from:
Filename: /usr/lib/golang/src/cmd/gc/popt.h



popt-devel-1.16-5.fc21.i686 : Development files for the popt library
Repo: fedora
Matched from:
Filename: /usr/include/popt.h



popt-devel-1.16-5.fc21.x86_64 : Development files for the popt library
Repo: fedora
Matched from:
Filename: /usr/include/popt.h


HTH,

-- 
regards,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Not able to SSH with User Created in IPA Server

[Natxo Asenjo]

On Fri, Mar 27, 2015 at 5:58 AM, Yogesh Sharma yks0...@gmail.com wrote:

 (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sss_krb5_cc_verify_ccache]
 (0x0020): 1078: [-1765328190][Credentials cache permissions incorrect]
 (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [check_old_ccache]
 (0x0040): Cannot check if saved ccache FILE:/tmp/krb5cc_131283_LTtoQU
 is valid
 (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [krb5_auth_send] (0x0020):
 check_if_ccache_file_is_used failed.
 (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [fo_resolve_service_send]
 (0x0100): Trying to resolve service 'IPA'


maybe this? Could you check what the permissions are on the kerberos cache
file for this test user?

-- 
regards,
Natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Not able to SSH with User Created in IPA Server

[Natxo Asenjo]

On Thu, Mar 26, 2015 at 3:12 PM, Yogesh Sharma yks0...@gmail.com wrote:

 Thanks, but when I trying to use admin user (default user created by IPA),
 I am able to login. The issue is happening only with new users we are
 trying to create.

 (Thu Mar 26 19:30:52 2015) [[sssd[krb5_child[13625 [get_and_save_tgt]
 (0x0020): 981: [-1765328361][Password has expired]
 (Thu Mar 26 19:30:55 2015) [[sssd[krb5_child[13625 [map_krb5_error]
 (0x0020): 1043: [-1765328360][Preauthentication failed]


password expired?

-- 
regards,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Unknown Client?

[Natxo Asenjo]

On Tue, Mar 17, 2015 at 4:19 PM, Tevfik Ceydeliler 
tevfik.ceydeli...@astron.yasar.com.tr wrote:

 Hi,
 Altough I have this configuration in client .conf:

 ##
 client 172.30.47.241 {
secret  = 877909
shortname   = VodafonePinarsuAPNYeni1
nastype = other
 }

 client 172.30.47.242 {
secret  = 877909
shortname   = VodafonePinarsuAPNYeni2
nastype = other
 }

 

 Why I get this error?

 
 #

 Tue Mar 17 14:31:55 2015 : Error: Ignoring request to authentication
 address * port 1812 from unknown client 172.30.47.242 port 58312
 Tue Mar 17 14:32:01 2015 : Error: Ignoring request to authentication
 address * port 1812 from unknown client 172.30.47.241 port 6040

 
 #
  https://www.redhat.com/mailman/listinfo/freeipa-users


I think you should post your question to the free*radius* mailing list ;-)

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login

[Natxo Asenjo]

On Wed, Mar 11, 2015 at 8:36 PM, Rob Crittenden rcrit...@redhat.com wrote:

 Ben .T.George wrote:
  HI
 
  thanks for the rply.
 
  even i tried native auto_master file with directory checking script. if
  i feed the user manually to the script, the directory is creating and
  while login request comes, it didn't.
 
  i don't think no one did full solaris integration util now as i asked
  many questions related to that.
 
  now i am little bit confident up to this level. and if everything is
  working fine, i will try to create automated script for IPA join

 automount is not a technology that automatically creates directories, it
 just automatically mounts them on demand.

 I'm not aware of a way to automatically create directories on new-user
 logins in Solaris.


I have not used 'official' solaris but using omnios (open solaris
derivative) I have used this with their automounter:

http://omnios.omniti.com/wiki.php/GeneralAdministration#Addinglocalusers

Quite nifty. It should work with solaris as well (well, maybe with a little
work).

-- 
regards,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO

[Natxo Asenjo]

On Fri, Mar 6, 2015 at 7:06 PM, Rich Megginson rmegg...@redhat.com wrote:

  On 03/06/2015 11:02 AM, Gianluca Cecchi wrote:

  On Fri, Mar 6, 2015 at 6:21 PM, Rich Megginson rmegg...@redhat.com
 wrote:

  On 03/06/2015 09:39 AM, Herwono W Wijaya wrote:

 vCenter SSO works well with Univention LDAP.


  Then set up a wireshark session to capture traffic between vCenter SSO
 and Univention LDAP, then do the same with vCenter SSO and IPA.  Then we
 can compare the TCP traffic dumps.


  And so we can then change the preface that at this moment explicitly
 contains:
 
  Preface
 The environment used to write this document is based on pure vSphere 5.1,
 used in trial mode with vCenter server configured as a virtual appliance.
 
 and update it covering 5.5 and hopefully 6.0 too... ;-)


 I'm sorry - which preface?  Link?

 http://www.freeipa.org/page/HowTo/vsphere5_integration , I think

--
Groeten,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] User certificates with FreeIPA and another question.

[Natxo Asenjo]

On Fri, Feb 6, 2015 at 3:30 PM, Martin Kosek mko...@redhat.com wrote:

 On 02/06/2015 12:53 AM, Christopher Young wrote:
  Obvious next question:  Any plans to implement that functionality or
 advice
  on how one might get some level of functionality for this?  Would it be
  possible to create another command-line based openssl CA that could issue
  these but using IPA as the root CA for those?

 As for FreeIPA plans, we plan to vastly improve our flexibility to process
 certificates in next upstream version - FreeIPA 4.2. In next version, one
 should be able to create other certificate profiles (from FreeIPA default
 service cert profile) or even subCAs to do what you want.


nice. When do all these things land in RHEL?


 As for current workarounds, you would have to issue and sign a for example
 NSS
 or openssl based subCA and then sign user certs there. But I would leave
 Fraser
 or Jan to tell if this would be really possible.


some examples on how to do that would be very helpful. I would love to
authenticate users to mysql using our CA, for instance.

-- 
regards,
natxo
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] certmonger question

[Natxo Asenjo]

hi,

On Tue, Nov 11, 2014 at 7:14 PM, Nalin Dahyabhai na...@redhat.com wrote:
 On Tue, Nov 11, 2014 at 11:13:12AM -0500, Nalin Dahyabhai wrote:
 Since you mention that this seems to be specific to 32-bit boxes, I
 think I need to switch to that one to try to sort out what's happening
 here, since I'm on a 64-bit box.

 Okay, found it, and as 64-bit cleanliness sometimes is, it's a one-line
 change.  The nightlies should have it starting with anything claiming to
 be 0.76.7 or later.  If you can open this in bugzilla, it'll probably
 look less weird to parts of management than if I did it.

:-)

Awesome. I filed it:
https://bugzilla.redhat.com/show_bug.cgi?id=1163023 (very summarily,
if you require me to fill in more information I will be happy to do
it; I added a link to this thread on the mailing list archive).

In the meantime until the fix hits the repositories I have excluded
certmonger from yum update and in an upgraded centos 6.6 32bit host
certmonger keeps working.

Thanks for your support.

--
Groeten,
natxo

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] certmonger question

[Natxo Asenjo]

hi Nali,
On Tue, Nov 11, 2014 at 12:57 PM, Martin Kosek mko...@redhat.com wrote:

 So if the lurking double encoded certificate is in LDAP, and thus Apache DS
 shows is invalid (it shows as OK in my RHEL-7.0 server), maybe the easiest way
 to fix it would be to:

 - Open your Apache DS
 - Back up cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com
 - Delete the cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com entry
 - Run
   # ipa-ldap-updater --upgrade --ldapi --quiet
   on your 6.5+ server and the certificate entry should get regenerated (tested
 with 7.0).

when you write 6.5+ server you mean in the kdc/CA server, right? Just
checking :-)

Thanks!

--
Groeten,
natxo

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] certmonger question

[Natxo Asenjo]

hi,

On Tue, Nov 11, 2014 at 2:13 PM, Martin Kosek mko...@redhat.com wrote:

 I meant IPA server running on RHEL/CentOS 6.5 or older... This is the one that
 can regenerate CAcert entry without double encoding.

ok.

So I removed the cacert object and ran

ipa-ldap-updater --upgrade --ldapi

(it does not know the --quiet switch in this version). And now in he
apache directory studio I see the value of the attribue is X509v3:
CN=Certificate Authority, O=DOMAIN.TLD

So that's fixed. But certmonger on the client still gives me the same errror

Could I send you the full log of certmonger privately (1.1M)?

Thanks.
--
Groeten,
natxo

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project