[Freeipa-users] Certificate format error reported by GUI

[Jim Richard]

When I try to look at hosts under the hosts tab. ipactl restart or just 
restarting httpd seems to clear it up for a short period.

Three replicas in the environment, it only happens when I look at hosts using 
the GUI at one of the three replicas.


Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key 
database is in an old, unsupported format.


     
Jim Richard    
    
    

SYSTEM ADMINISTRATOR III
(646) 338-8905  

 

 

 

 

 

 

 

 

 

 

 

 



-- 
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 created with expired certs

[Jim Richard]

I have a master with apparently correct, non expired certs but when I create a 
new replica master I end up with expired certs.
How is this possible, why and of course, how do I fix?

first set is the original master and the second is the certs I get on the new 
replica

[root@sso-110:(NYM) nssdb]$ getcert list
Number of certificates and requests being tracked: 8.
Request ID '20140923213643':
status: MONITORING
stuck: no
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=PLACEIQ.NET
subject: CN=sso-110.nym1.placeiq.net,O=PLACEIQ.NET
expires: 2018-08-28 10:36:04 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA
track: yes
auto-renew: yes
Request ID '20140923213732':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert 
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=PLACEIQ.NET
subject: CN=sso-110.nym1.placeiq.net,O=PLACEIQ.NET
expires: 2018-08-06 10:36:02 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20140923213814':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/dirsrv/slapd-PLACEIQ-NET',nickname='Server-Cert',token='NSS
 Certificate DB',pinfile='/etc/dirsrv/slapd-PLACEIQ-NET
/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/dirsrv/slapd-PLACEIQ-NET',nickname='Server-Cert',token='NSS
 Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=PLACEIQ.NET
subject: CN=sso-110.nym1.placeiq.net,O=PLACEIQ.NET
expires: 2018-08-28 10:36:04 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PLACEIQ-NET
track: yes
auto-renew: yes
Request ID '20140923213856':
status: MONITORING
stuck: no
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=PLACEIQ.NET
subject: CN=sso-110.nym1.placeiq.net,O=PLACEIQ.NET
expires: 2018-08-28 10:36:04 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes
Request ID '20160119021025':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert 
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=PLACEIQ.NET
subject: CN=CA Audit,O=PLACEIQ.NET
expires: 2017-10-26 04:38:19 UTC
key usage: digitalSignature,nonRepudiation
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert 
"auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20160119021038':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert 
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=PLACEIQ.NET
subject: CN=OCSP Subsystem,O=PLACEIQ.NET
expires: 2017-10-26 04:37:19 UTC
eku: id-kp-OCSPSigning
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert 

[Freeipa-users] Possibly revoked my CA?

[Mike K]

We have several IPA servers, recently they got out of sync and in the
course of fixing things, I think we inadvertently revoked the CA.

When I try to get to ipa01 (the first one we built) in Firefox I get this
error:

An error occurred during a connection to ipa01-reston.xco.qq. Peer's
Certificate has been revoked. Error code: SEC_ERROR_REVOKED_CERTIFICATE

I can login to 02 & 03 just fine. But when I try to administer anything
certificate related under the GUI I get this error:

IPA Error 4301: CertificateOperationError

Certificate operation cannot be completed: Unable to communicate with CMS
(Internal Server Error)


===

2016-09-23T18:53:54Z7241MainThread  ipa INFODeleting
schedule 2358-2359 0 from agreement
cn=meToipa01,cn=replica,cn=dc\=xxx\,dc\=xx,cn=mapping tree,cn=config
2016-09-23T18:53:55Z7241MainThread  ipa INFOReplication
Update in progress: FALSE: status: -1 Incremental update has failed and
requires administrator actionLDAP error: Can't contact LDAP server: start:
0: end: 0
2016-09-27T18:23:10Z30695   MainThread  ipa INFOGetting
ldap service principals for conversion:
(krbprincipalname=ldap/ipa01-...@xxx.xx) and
(krbprincipalname=ldap/ipa04.xxx...@xxx.xx)


I'm thinking the cert is only revoked on 01, it should be replicated to
02-09. Is there any way to make sure that it doesn't fully replicate
revokation and bring it back to 01? If that's even the problem!


Thanks much,

Mike
-- 
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 get a new cert

[Bret Wortman]

That looks like it worked, but I have a follow-on question:

I need to provide my RabbitMQ instance with a cacert file, a cert, and a 
key file. These seem to be .pem files. Is there an easy way to gather 
these 3 files from a typical IPA client node?


Merci!


Bret


On 09/27/2016 11:28 AM, Florence Blanc-Renaud wrote:

Hi Bret,

would the following be helpful? In "Linux Domain Identity, 
Authentication, and Policy Guide", Chapter 17.1.1 Requesting New 
Certificates for a User, Host, or Service [1]


Flo.

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/certificates.html#certificate-request


On 09/27/2016 04:20 PM, Bret Wortman wrote:

Is there a guide anywhere for how to obtain an SSL certificate for a new
server & service from the IPA CA master? Most of the guides I'm seeing
online use web pages at the major CAs to do this and I'd like to keep it
in the family.

Thanks!


--
*Bret Wortman*

http://wrapbuddies.co/






--
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] Distributing user keytabs for non-interactive auth question

[Matthew Sellers]

Hi Guys,

I found docs on roles and was able to permission my IPA DNS scripts as follows:


ipa role-add "DNS Admin"
ipa role-add-privilege "DNS Admin" --privileges="DNS Administrator"
ipa role-add-member "DNS Admin" --services="buildslave/host.domain@realm.com

Now I am able to authenticate with this service principal and access
LDAP attributes from IPA as you suggested.   I was a little caught
off-guard as it seems even the built-in 'admin type' roles do not have
access to read DNS ?   Adding this role puts a smile on my face.

ipa-getkeytab -s myipahost  -p buildslave/host.domain@realm.com -k
/etc/named/ipa_automation.keytab -r
export KRB5_CLIENT_KTNAME=ipa_automation.keytab
export KRB5_KTNAME=ipa_automation.keytab
./buildslave.py


Thanks,
Matt


On Mon, Sep 26, 2016 at 6:01 PM, Matthew Sellers  wrote:
> Hi Alexander,
>
> Thanks for the hint, I was able to create a keytab and authenticate as
> a service, but using this method IPA returns zero results ( u'result'
> : [] ) for calls like "dnszone_find()".  I tried adding some of the
> predefined ROLES to the service principal, but no luck there.  Any
> hints are greatly appreciated.
>
> Thank You!
> Matt
>
>
>
> On Mon, Sep 26, 2016 at 9:59 AM, Alexander Bokovoy  
> wrote:
>> On ma, 26 syys 2016, Matthew Sellers wrote:
>>>
>>> Hi Martin,
>>>
>>> Thank you for clarification.   In my example I am configuring
>>> 'unprivileged' service users.   Specifically, I wrote a script to pull
>>> data from IPA from its wonderful REST interface that will run on a
>>> group of hosts.  Since this has to run non-interactively I would like
>>> to use a keytab.
>>>
>>> I initially went down the road of grabbing an initial keytab with
>>> ipa-getkeytab and then distributing the 'service user keytab' with
>>> Puppet.I see the security implications here the same as
>>> un-encrypted ssh keys for service users.
>>>
>>> My second option was to jump on the host, grab a TGT for the service
>>> user with kinit, and download the lastest KVNO of my service user
>>> keytab using ipa-getkeytab with '-r' option.
>>>
>>> This seemed pretty cool and solved the issue of asking the KDC 'give
>>> me the lastest keytab for service user abc_service'.   What is the
>>> best way to do this?
>>>
>>>
>>> If anybody can share similar deployment stories that would be great.
>>
>> If you are not tied to POSIX users, you can create actual Kerberos
>> services and use them to talk to IPA framework. To the framework there
>> is no difference whether it is a user or a kerberos service that is
>> authenticating. You can create roles that reference Kerberos services
>> instead of users when assigning permissions to access certain objects
>> and their attributes.
>>
>> For services there is already a good way to delegate retrieval rights
>> for keytabs.
>>
>>
>>
>>>
>>> Thank You!
>>> Matt
>>>
>>>
>>>
>>> On Mon, Sep 26, 2016 at 2:22 AM, Martin Babinsky 
>>> wrote:

 On 09/26/2016 04:22 AM, Matthew Sellers wrote:
>
>
> Hey Mike,
>
> Thanks for the reply.  I did use this originally when deploying my
> 'kerberized' service on my first host.   What I am trying to do is use
> ipa-getkeytab for keytab distribution on say...100 hosts, without
> having to copy around keytabs from host to host.
>
> Since using ipa-getkeytab without the '-r' option just creates a new
> keytab with bumped KVNO ..and.. when I do use '-r' I recieve a message
> for 'Insufficient access rights' I am still fuzzy
>
> Can ipa-getkeytab be used for mass distribution of user keytabs with
> the -r option?
>
> Thanks Again!
> Matt
>
>
>
> On Sun, Sep 25, 2016 at 9:03 PM, Michael ORourke
>  wrote:
>>
>>
>> Matt,
>>
>> Try the following...
>>
>> # Get admin TGT
>> kinit ad...@realm.com
>>
>> # Get keytab for user account
>> ipa-getkeytab -s coipa100 -p cron_run...@realm.com -k
>> ipa_cron_runner.keytab
>>
>> # Clear tickets
>> kdestroy
>>
>> # Request TGT using the keytab
>> kinit -k -t ./cron_runner.keytab cron_run...@realm.com
>>
>> # List tickets
>> klist
>>
>> I recommend including the username somewhere in the name of the keytab
>> file itself which makes it easier to remember.  Of course be careful
>> with
>> the permissions on the keytab file, because anyone that has read access
>> to
>> the keytab can get a TGT as that user.
>>
>> -Mike
>>
>> -Original Message-
>>>
>>>
>>> From: Matthew Sellers 
>>> Sent: Sep 25, 2016 8:37 PM
>>> To: freeipa-users@redhat.com
>>> Subject: [Freeipa-users] Distributing user keytabs for non-interactive
>>> authquestion
>>>
>>> Hi Guys,
>>>
>>> What is the best way to distribute a 'user' keytab to distribute
>>> 

Re: [Freeipa-users] Replication broken

[thierry bordaz]

Hi Timothy,

When you say username do you mean 'User login' (uid) ?
I can create such entry (with heading '1') on 4.2 and after. I see no 
reason why the uid value ('1' is valid in uid syntax) would trigger that 
failure when adding an entry 'cn=changelog'.


I think something wrong happened to the retroCL counter and hoping to 
see what in the error log.
Is it possible you send me the error log between the time 
changenumber=112697 was created and when DSRetroclPlugin reports a failure ?



thanks
thierry

On 09/27/2016 05:28 PM, Timothy Geier wrote:

On Tue, 2016-09-27 at 12:47 +0200, thierry bordaz wrote:

Hi Timothy,

The changenumber counter is protected by a lock and we should not see
duplicate value.. except if there is a bug :-(

Retrieving the time when changenumber=112697,cn=changelog was created
and the time when you saw the error, can you see any error in
operations (access log) or in the error log ?

Or did you disabled/enable retorCL between those two times ?

regards
thiery

Unfortunately, the issue appears to be a certain username that starts
with a '1'..in both cases, trying to delete this user caused (and is
causing) the exact same issue.  Are there any known bugs relating to
this?




On 09/27/2016 12:37 AM, Timothy Geier wrote:


On Sep 26, 2016, at 4:07 PM, Timothy Geier 
wrote:


On Sep 26, 2016, at 2:17 PM, Timothy Geier
 wrote:

This issue started when trying to remove a user; ipa user-del
showed “operation failed” and the user was not removed.  The
same ipa user-del command was performed on a replica and
completed successfully, but it was then immediately apparent
that this change did not replicate anywhere else.  All of the
replicas then were re-initalized using "ipa-replica-manage
re-initialize” and now the LDAP trees/users are consistent
though no further changes have been made.

The slapd error logs are showing repeated instances of

DSRetroclPlugin - replog: an error occured while adding change
number 112697, dn = changenumber=112697,cn=changelog: Already
exists.
retrocl-plugin - retrocl_postob: operation failure [68]

Package versions are
ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64
and
389-ds-base-1.3.4.0-29.el7_2.x86_64

ipa-replica-manage list-ruv
ipa: WARNING: session memcached servers not running
unable to decode: {replica 11} 56044ef5000b
56044ef5000b
unable to decode: {replica 7} 561f17ba00080007
561f17ba00080007
unable to decode: {replica 5} 561f17bc00030005
561f17bc00030005
unable to decode: {replica 9} 561f17ba000a0009
561f17ba000a0009
unable to decode: {replica 4} 561f17ba00030004
561f17ba00030004
(These are likely leftovers from the previous incarnation of
these servers on a RHEL6-like setup)
ipa07:389: 16
ipa02:389: 13
ipa03:389: 14
ipa01:389: 12
ipa04:389: 15
ipa05:389: 17

Thanks much,

After not taking any action, this error has stopped but has been
replaced with

[26/Sep/2016:15:54:54 -0500] NSMMReplicationPlugin -
agmt="cn=meToipa03" (ipa03:389): Missing data encountered
[26/Sep/2016:15:54:54 -0500] NSMMReplicationPlugin -
agmt="cn=meToipa03" (ipa03:389): Incremental update failed and
requires administrator action

for all of the replicas and things are slightly out of sync
everywhere.

Is the best course of action here to declare one a new master and
do a ipa-replica-manage re-initialize to all of the others from
that one?





After doing some testing, that’s exactly what we did and replication
is now working again.  It is odd that the DSRetroclPlugin errors
stopped on their own (after approximately 3 hours); the only action
taken there was looking at the cn=changelog base using ldapvi to see
what number it was on but that has to be a sheer coincidence;
absolutely no changes were made.


We’re also still unsure what caused this; our best theory at the
moment is a race condition where everything that could have gone
wrong at that exact moment did..is there any validity to this?


Thanks,
"This message and any attachments may contain confidential information. If you
have received this  message in error, any use or distribution is prohibited.
Please notify us by reply e-mail if you have mistakenly received this message,
and immediately and permanently delete it and any attachments. Thank you."




--
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] Server replication stopped working

[Ludwig Krispenz]

On 09/27/2016 06:04 PM, Youenn PIOLET wrote:

Hi Ludwig,

Version:
389-ds-base-1.3.4.0-33.el7_2.x86_64
we have identified an issue with this version, it includes a fix for 
389-ds ticket #48766, which was incomplete and resolved shortly after 
the release of this version (it is missing the latest patch for #49766 
and for #48954).
You can try to go back to 1.3.4.0-32 or if you have support get a hotfix 
from our support.


Sorry for this,
Ludwig


The timestamp probably matches the last time I've done a 
ipa-replica-manage re-initialize.
I have to do it every day (many times a day actually!), as replication 
is broken, This CSN changes all the time.


My main goal is to rebuilt everything from a clean base.
I've got no master without errors.

What is the easiest way to rebuilt everything?
ipa-[cs]replica-manage re-initialize isn't very effective.

Thanks by advance,
Regards

--
Youenn Piolet
piole...@gmail.com 
/
/

2016-09-26 9:42 GMT+02:00 Ludwig Krispenz >:



On 09/25/2016 09:35 PM, Youenn PIOLET wrote:

Hi there,

Same issue for me in a my 15 ipa-servers multi-master grid just
after the update.
The replication is completely broken except on 3/15 nodes.

This is the second time I have to fully reinitialize the whole
cluster for similar reason. I don't know what to do to clean this
mess...
For more information: this cluster has been initialized on a
fedora 4.1.4 more than one year ago then complemetely migrated to
Centos 7, IPA 4.2.

what is the exact version of 389-ds-base you are running ?

did these errors come out of the blue or are they related to some
activities ? The csn which is not found has a timestamp of "Thu,
22 Sep 2016 15:59:08 GMT" did anything happen around this time ?



Example on fr-master03 error logs:

[25/Sep/2016:19:27:31 +] NSMMReplicationPlugin - changelog
program - agmt="cn=meTofr-master01.domain" (fr-master01:389): CSN
57e3ffcc0003001a not found, we aren't as up to date, or we purged
[25/Sep/2016:19:27:31 +] NSMMReplicationPlugin -
agmt="cn=meTofr-master01.domain" (fr-master01:389): Data required
to update replica has been purged. The replica must be reinitialized.
[25/Sep/2016:19:27:31 +] NSMMReplicationPlugin -
agmt="cn=meTofr-master01.domain" (fr-master01:389): Incremental
update failed and requires administrator action
ipa: INFO: The ipactl command was successful
[25/Sep/2016:19:27:35 +] agmt="cn=meTofr-master02.domain"
(fr-master02:389) - Can't locate CSN 57e3ffcc0003001a in the
changelog (DB rc=-30988). If replication stops, the consumer may
need to be reinitialized.
[25/Sep/2016:19:27:35 +] NSMMReplicationPlugin - changelog
program - agmt="cn=meTofr-master02.domain" (fr-master02:389): CSN
57e3ffcc0003001a not found, we aren't as up to date, or we purged
[25/Sep/2016:19:27:35 +] NSMMReplicationPlugin -
agmt="cn=meTofr-master02.domain" (fr-master02:389): Data required
to update replica has been purged. The replica must be reinitialized.
[25/Sep/2016:19:27:35 +] NSMMReplicationPlugin -
agmt="cn=meTofr-master02.domain" (fr-master02:389): Incremental
update failed and requires administrator action

Regards,

--
Youenn Piolet
piole...@gmail.com 
/
/

2016-09-23 17:51 GMT+02:00 Mike Driscoll
>:

Hello.  I have four IPA servers replicating in full mesh. 
All four servers are running

ipa-server-4.2.0-15.0.1.el7_2.19.x86_64.

This was working for some time but now I see that no
replication is occurring automatically at present.

When I update a user attribute on an IPA server, I see errors
like these:
[22/Sep/2016:16:53:49 -0700] attrlist_replace - attr_replace
(nsslapd-referral, ldap://ldap03.xx.com:389/o%3Dipaca) failed.
[22/Sep/2016:16:58:56 -0700] NSMMReplicationPlugin -
agmt="cn=masterAgreement1-ldap03.xx.com
-pki-tomcat" (ldap03:389):
Incremental update failed and requires administrator action

I can reinitialize without errors.
ipa-csreplica-manage re-initialize --from=ldap01.xx.com

ipa-replica-manage re-initialize --from=ldap01.xx.com

Afterwards I see my attribute (and other) changes are
replicated on each server I re-initialize from.  But
subsequently, replication doesn’t seem to be happening.

I reinitialized according to the steps in Table 8.7,
“Replication Errors”, but subsequent replication isn’t
occurring. Any suggestions?  Is it safe to identify one of my
four servers as containing 

Re: [Freeipa-users] Server replication stopped working

[Youenn PIOLET]

Hi Ludwig,

Version:
389-ds-base-1.3.4.0-33.el7_2.x86_64

The timestamp probably matches the last time I've done a ipa-replica-manage
re-initialize.
I have to do it every day (many times a day actually!), as replication is
broken, This CSN changes all the time.

My main goal is to rebuilt everything from a clean base.
I've got no master without errors.

What is the easiest way to rebuilt everything?
ipa-[cs]replica-manage re-initialize isn't very effective.

Thanks by advance,
Regards

--
Youenn Piolet
piole...@gmail.com


2016-09-26 9:42 GMT+02:00 Ludwig Krispenz :

>
> On 09/25/2016 09:35 PM, Youenn PIOLET wrote:
>
> Hi there,
>
> Same issue for me in a my 15 ipa-servers multi-master grid just after the
> update.
> The replication is completely broken except on 3/15 nodes.
>
> This is the second time I have to fully reinitialize the whole cluster for
> similar reason. I don't know what to do to clean this mess...
> For more information: this cluster has been initialized on a fedora 4.1.4
> more than one year ago then complemetely migrated to Centos 7, IPA 4.2.
>
> what is the exact version of 389-ds-base you are running ?
>
> did these errors come out of the blue or are they related to some
> activities ? The csn which is not found has a timestamp of "Thu, 22 Sep
> 2016 15:59:08 GMT" did anything happen around this time ?
>
>
> Example on fr-master03 error logs:
>
> [25/Sep/2016:19:27:31 +] NSMMReplicationPlugin - changelog program -
> agmt="cn=meTofr-master01.domain" (fr-master01:389): CSN
> 57e3ffcc0003001a not found, we aren't as up to date, or we purged
> [25/Sep/2016:19:27:31 +] NSMMReplicationPlugin -
> agmt="cn=meTofr-master01.domain" (fr-master01:389): Data required to
> update replica has been purged. The replica must be reinitialized.
> [25/Sep/2016:19:27:31 +] NSMMReplicationPlugin -
> agmt="cn=meTofr-master01.domain" (fr-master01:389): Incremental update
> failed and requires administrator action
> ipa: INFO: The ipactl command was successful
> [25/Sep/2016:19:27:35 +] agmt="cn=meTofr-master02.domain"
> (fr-master02:389) - Can't locate CSN 57e3ffcc0003001a in the changelog
> (DB rc=-30988). If replication stops, the consumer may need to be
> reinitialized.
> [25/Sep/2016:19:27:35 +] NSMMReplicationPlugin - changelog program -
> agmt="cn=meTofr-master02.domain" (fr-master02:389): CSN
> 57e3ffcc0003001a not found, we aren't as up to date, or we purged
> [25/Sep/2016:19:27:35 +] NSMMReplicationPlugin -
> agmt="cn=meTofr-master02.domain" (fr-master02:389): Data required to
> update replica has been purged. The replica must be reinitialized.
> [25/Sep/2016:19:27:35 +] NSMMReplicationPlugin -
> agmt="cn=meTofr-master02.domain" (fr-master02:389): Incremental update
> failed and requires administrator action
>
> Regards,
>
> --
> Youenn Piolet
> piole...@gmail.com
>
>
> 2016-09-23 17:51 GMT+02:00 Mike Driscoll :
>
>> Hello.  I have four IPA servers replicating in full mesh.  All four
>> servers are running ipa-server-4.2.0-15.0.1.el7_2.19.x86_64.
>>
>> This was working for some time but now I see that no replication is
>> occurring automatically at present.
>>
>> When I update a user attribute on an IPA server, I see errors like these:
>> [22/Sep/2016:16:53:49 -0700] attrlist_replace - attr_replace
>> (nsslapd-referral, ldap://ldap03.xx.com:389/o%3Dipaca) failed.
>> [22/Sep/2016:16:58:56 -0700] NSMMReplicationPlugin - agmt="cn=
>> masterAgreement1-ldap03.xx.com 
>> -pki-tomcat" (ldap03:389): Incremental update failed and requires
>> administrator action
>>
>> I can reinitialize without errors.
>> ipa-csreplica-manage re-initialize --from=ldap01.xx.com
>> 
>> ipa-replica-manage re-initialize --from=ldap01.xx.com
>> Afterwards I see my attribute (and other) changes are replicated on each
>> server I re-initialize from.  But subsequently, replication doesn’t seem to
>> be happening.
>>
>> I reinitialized according to the steps in Table 8.7, “Replication
>> Errors”, but subsequent replication isn’t occurring.  Any suggestions?  Is
>> it safe to identify one of my four servers as containing up-to-date data,
>> then sever and reinstate replication relationships with the other three?
>>
>> Mike
>>
>>
>>
>>
>>
>>
>> --
>> 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
>>
>
>
>
>
> --
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, 
> Eric Shander
>
>
> --
> 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
>
-- 
Manage your subscription for the 

Re: [Freeipa-users] Replication broken

[Timothy Geier]

On Tue, 2016-09-27 at 12:47 +0200, thierry bordaz wrote:
> Hi Timothy,
> 
> The changenumber counter is protected by a lock and we should not see
> duplicate value.. except if there is a bug :-(
> 
> Retrieving the time when changenumber=112697,cn=changelog was created
> and the time when you saw the error, can you see any error in
> operations (access log) or in the error log ?
> 
> Or did you disabled/enable retorCL between those two times ?
> 
> regards
> thiery

Unfortunately, the issue appears to be a certain username that starts
with a '1'..in both cases, trying to delete this user caused (and is
causing) the exact same issue.  Are there any known bugs relating to
this?

> 
> 
> 
> On 09/27/2016 12:37 AM, Timothy Geier wrote:
> 
> > 
> > > On Sep 26, 2016, at 4:07 PM, Timothy Geier 
> > > wrote:
> > > 
> > > > 
> > > > On Sep 26, 2016, at 2:17 PM, Timothy Geier
> > > >  wrote:
> > > > 
> > > > This issue started when trying to remove a user; ipa user-del
> > > > showed “operation failed” and the user was not removed.  The
> > > > same ipa user-del command was performed on a replica and
> > > > completed successfully, but it was then immediately apparent
> > > > that this change did not replicate anywhere else.  All of the
> > > > replicas then were re-initalized using "ipa-replica-manage
> > > > re-initialize” and now the LDAP trees/users are consistent
> > > > though no further changes have been made.
> > > > 
> > > > The slapd error logs are showing repeated instances of
> > > > 
> > > > DSRetroclPlugin - replog: an error occured while adding change
> > > > number 112697, dn = changenumber=112697,cn=changelog: Already
> > > > exists.
> > > > retrocl-plugin - retrocl_postob: operation failure [68]
> > > > 
> > > > Package versions are
> > > > ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64
> > > > and 
> > > > 389-ds-base-1.3.4.0-29.el7_2.x86_64
> > > > 
> > > > ipa-replica-manage list-ruv
> > > > ipa: WARNING: session memcached servers not running
> > > > unable to decode: {replica 11} 56044ef5000b
> > > > 56044ef5000b
> > > > unable to decode: {replica 7} 561f17ba00080007
> > > > 561f17ba00080007
> > > > unable to decode: {replica 5} 561f17bc00030005
> > > > 561f17bc00030005
> > > > unable to decode: {replica 9} 561f17ba000a0009
> > > > 561f17ba000a0009
> > > > unable to decode: {replica 4} 561f17ba00030004
> > > > 561f17ba00030004 
> > > > (These are likely leftovers from the previous incarnation of
> > > > these servers on a RHEL6-like setup)
> > > > ipa07:389: 16
> > > > ipa02:389: 13
> > > > ipa03:389: 14
> > > > ipa01:389: 12
> > > > ipa04:389: 15
> > > > ipa05:389: 17
> > > > 
> > > > Thanks much,
> > > 
> > > After not taking any action, this error has stopped but has been
> > > replaced with
> > > 
> > > [26/Sep/2016:15:54:54 -0500] NSMMReplicationPlugin -
> > > agmt="cn=meToipa03" (ipa03:389): Missing data encountered
> > > [26/Sep/2016:15:54:54 -0500] NSMMReplicationPlugin -
> > > agmt="cn=meToipa03" (ipa03:389): Incremental update failed and
> > > requires administrator action
> > > 
> > > for all of the replicas and things are slightly out of sync
> > > everywhere.  
> > > 
> > > Is the best course of action here to declare one a new master and
> > > do a ipa-replica-manage re-initialize to all of the others from
> > > that one?
> > > 
> > > 
> > > 
> > 
> > 
> > After doing some testing, that’s exactly what we did and replication
> > is now working again.  It is odd that the DSRetroclPlugin errors
> > stopped on their own (after approximately 3 hours); the only action
> > taken there was looking at the cn=changelog base using ldapvi to see
> > what number it was on but that has to be a sheer coincidence;
> > absolutely no changes were made. 
> > 
> > 
> > We’re also still unsure what caused this; our best theory at the
> > moment is a race condition where everything that could have gone
> > wrong at that exact moment did..is there any validity to this?
> > 
> > 
> > Thanks,
> > "This message and any attachments may contain confidential information. If 
> > you
> > have received this  message in error, any use or distribution is 
> > prohibited. 
> > Please notify us by reply e-mail if you have mistakenly received this 
> > message,
> > and immediately and permanently delete it and any attachments. Thank you."
> > 
> > 
> 

-- 
Timothy R. Geier 
Sr. Linux Systems Administrator 
Accertify, Inc. an American Express Company 
2 Pierce Place
Suite 900
Itasca, IL 60143 
Office: + 1 (630) 735-4785 
tge...@accertify.com





"This message and any attachments may contain confidential information. If you
have received this  message in error, any use or distribution is prohibited. 
Please notify us by reply e-mail if you have mistakenly received this message,
and immediately and permanently delete it and any attachments. Thank you."

-- 
Manage your subscription for the Freeipa-users mailing list:

Re: [Freeipa-users] How to get a new cert

[Florence Blanc-Renaud]

Hi Bret,

would the following be helpful? In "Linux Domain Identity, 
Authentication, and Policy Guide", Chapter 17.1.1 Requesting New 
Certificates for a User, Host, or Service [1]


Flo.

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/certificates.html#certificate-request


On 09/27/2016 04:20 PM, Bret Wortman wrote:

Is there a guide anywhere for how to obtain an SSL certificate for a new
server & service from the IPA CA master? Most of the guides I'm seeing
online use web pages at the major CAs to do this and I'd like to keep it
in the family.

Thanks!


--
*Bret Wortman*

http://wrapbuddies.co/




--
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] RBAC - User Administrator - OTP tokens

[Prashant Bapat]

RBAC Role "User Administrator" should have access to all users OTP tokens.
Specifically to remove if some one has lost their token. We get this a lot.

I found no permissions that give this access.

Can someone explain if this can be added easily either from the WebUI or
CLI.

Thanks.
--Prashant
-- 
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] How to get a new cert

[Bret Wortman]

Is there a guide anywhere for how to obtain an SSL certificate for a new 
server & service from the IPA CA master? Most of the guides I'm seeing 
online use web pages at the major CAs to do this and I'd like to keep it 
in the family.


Thanks!


--
*Bret Wortman*

http://wrapbuddies.co/
-- 
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

[Rob Crittenden]

Natxo Asenjo wrote:

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?


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.


rob

--
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] Replication broken

[thierry bordaz]

Hi Timothy,

The changenumber counter is protected by a lock and we should not see 
duplicate value.. except if there is a bug :-(


Retrieving the time when changenumber=112697,cn=changelog was created 
and the time when you saw the error, can you see any error in operations 
(access log) or in the error log ?


Or did you disabled/enable retorCL between those two times ?

regards
thiery



On 09/27/2016 12:37 AM, Timothy Geier wrote:


On Sep 26, 2016, at 4:07 PM, Timothy Geier > wrote:




On Sep 26, 2016, at 2:17 PM, Timothy Geier > wrote:


This issue started when trying to remove a user; ipa user-del showed 
“operation failed” and the user was not removed.  The same ipa 
user-del command was performed on a replica and completed 
successfully, but it was then immediately apparent that this change 
did not replicate anywhere else.  All of the replicas then were 
re-initalized using "ipa-replica-manage re-initialize” and now the 
LDAP trees/users are consistent though no further changes have been 
made.


The slapd error logs are showing repeated instances of

DSRetroclPlugin - replog: an error occured while adding change 
number 112697, dn = changenumber=112697,cn=changelog: Already exists.

retrocl-plugin - retrocl_postob: operation failure [68]

Package versions are
ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64
and
389-ds-base-1.3.4.0-29.el7_2.x86_64

ipa-replica-manage list-ruv
ipa: WARNING: session memcached servers not running
unable to decode: {replica 11} 56044ef5000b 56044ef5000b
unable to decode: {replica 7} 561f17ba00080007 561f17ba00080007
unable to decode: {replica 5} 561f17bc00030005 561f17bc00030005
unable to decode: {replica 9} 561f17ba000a0009 561f17ba000a0009
unable to decode: {replica 4} 561f17ba00030004 561f17ba00030004
(These are likely leftovers from the previous incarnation of these 
servers on a RHEL6-like setup)

ipa07:389: 16
ipa02:389: 13
ipa03:389: 14
ipa01:389: 12
ipa04:389: 15
ipa05:389: 17

Thanks much,


After not taking any action, this error has stopped but has been 
replaced with


[26/Sep/2016:15:54:54 -0500] NSMMReplicationPlugin - 
agmt="cn=meToipa03" (ipa03:389): Missing data encountered
[26/Sep/2016:15:54:54 -0500] NSMMReplicationPlugin - 
agmt="cn=meToipa03" (ipa03:389): Incremental update failed and 
requires administrator action


for all of the replicas and things are slightly out of sync everywhere.

Is the best course of action here to declare one a new master and do 
a ipa-replica-manage re-initialize to all of the others from that one?





After doing some testing, that’s exactly what we did and replication 
is now working again.  It is odd that the DSRetroclPlugin errors 
stopped on their own (after approximately 3 hours); the only action 
taken there was looking at the cn=changelog base using ldapvi to see 
what number it was on but that has to be a sheer coincidence; 
absolutely no changes were made.


We’re also still unsure what caused this; our best theory at the 
moment is a race condition where everything that could have gone wrong 
at that exact moment did..is there any validity to this?


Thanks,
"This message and any attachments may contain confidential information. If you
have received this  message in error, any use or distribution is prohibited.
Please notify us by reply e-mail if you have mistakenly received this message,
and immediately and permanently delete it and any attachments. Thank you."




-- 
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