Re: [Freeipa-users] Centos7, selinux, certmonger, and openldap
On 08/04/2014 07:06 PM, Nordgren, Bryce L -FS wrote: > >> Hmm, sorry for incomplete instructions then. I updated the instructions to >> cope with that situation better (details in >> https://fedorahosted.org/freeipa/ticket/4466#comment:2). Please feel free >> to report more findings or even better help us enhance the page even >> further :-) > > Hmm, I thought it looked like your wiki, but when there was no login in the > upper-right corner, I assumed it was an online version of your manual. That > always gets me, even when I'm looking at a page I know I created myself. Ah, that's a useful UXD feedback as it seems. BTW, to log in, check "Log in / create account with OpenID" in the LOWER right corner... > > In this case, tho, I was definitely not qualified to provide a fix. New to > both certmonger and that Mozilla certificate database thing. Don't worry, you will get there. > Made a comment on the talk page about the related OpenLDAP selinux issues > (more than one cert_t defined). Dunno if you get notifications. Ok. IMO this is a valid bug, system policy should allow certmonger to manage other cert types. Thanks for filing it. Martin -- 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] RHEL 7 Upgrade experience so far
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/04/2014 01:51 PM, Ade Lee wrote: > OK - I suspect you may be running into an issue with serial number > generation. Each time we install a clone, we end up allocating a > new range of serial numbers for the clone. > > The idea is to keep separate ranges for each CA replica so that no > two replicas can issue certs with the same serial number. > > The problem is that you've probably retried the install a whole > bunch of times and now perhaps the serial number range is too > high. > > This is just a guess - but you can see what ranges have been > assigned by looking in : > > 1, ou-ranges, o=ipaca (on the master directory server) 2. CS.cfg > for the master (look for the attributes dbs.* 3. The value of the > attribute nextRange on : ou=certificateRepository, o=ipaca and > ou=Requests, o=ipaca > > Please send me that info, and I'll explain how to clean that up. > > Ade > > On Mon, 2014-08-04 at 12:10 -0700, Erinn Looney-Triggs wrote: >> On 08/04/2014 11:48 AM, Ade Lee wrote: >>> OK - so its not really even getting started on the install. >>> My guess is there is some cruft from previous >>> installs/uninstalls that was not cleaned up. Is there anything >>> in the directory server logs on the RHEL7 machine? What >>> operation is being attempted that the server is refusing to >>> perform? >>> >>> Ade >>> >> >> Ok I moved on past this issue. Problem was minssf was set to 56 >> on the RHEL 7 dirsrv instance, setting it to 0 resolved this >> issue. Thanks for having me check the dir on the RHEL 7 instance >> I was assuming it was hitting against the RHEL 6.5 instance and >> was finding basically nothing there. >> >> >> This run looks like it pulled a lot more information in but it >> still errored out. >> >> ipa : DEBUGstderr=pkispawn: WARNING ... >> unable to validate security domain user/password through REST >> interface. Interface not available pkispawn: ERROR... >> Exception from Java Configuration Servlet: Error in confguring >> system certificatesjava.security.cert.CertificateException: >> Unable to initialize, java.io.IOException: DerInput.getLength(): >> lengthTag=127, too big. >> >> ipa : CRITICAL failed to configure ca instance Command >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpbTnSRM' returned non-zero >> exit status 1 >> >> From the /var/log/pki/pki-tomcat/ca/debug log on the RHEL 7 >> instance: >> >> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: initializing with >> mininum 3 and maximum 15 connections to host ipa2.abaqis.com port >> 389, secure connection, false, authentication type 1 >> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: increasing minimum >> connections by 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: >> new total available connections 3 >> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new number of >> connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: In >> LdapBoundConnFactory::getConn() >> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: masterConn is >> connected: true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: >> getConn: conn is connected true >> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: mNumConns >> now 2 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS: >> param=preop.internaldb.post_ldif >> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif >> file = /usr/share/pki/ca/conf/vlv.ldif >> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif >> file copy to /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): >> LDAP Errors in importing >> /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, >> cn=config:netscape.ldap.LDAPException: error result (32); >> matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allInvalidCerts-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allInValidCertsNotBefore-pki-tomcat, cn=ipaca, cn=ldbm >> database, cn=plugins, cn=config:netscape.ldap.LDAPException: >> error result (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allNonRevokedCerts-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matche
Re: [Freeipa-users] attribute "dnaremotebindmethod" not allowed
On Friday, July 25, 2014 01:43:04 PM Anthony Messina wrote: > On Friday, July 25, 2014 11:00:05 AM Rich Megginson wrote: > > On 07/25/2014 10:43 AM, Anthony Messina wrote: > > On Friday, July 25, 2014 10:26:55 AM Rich Megginson wrote: > > On 07/25/2014 01:46 AM, Anthony Messina wrote: > > On Thursday, July 24, 2014 08:44:34 AM Martin Kosek wrote: > > On 07/23/2014 06:38 PM, Anthony Messina wrote: > > On Monday, July 21, 2014 01:09:43 PM Ludwig Krispenz wrote: > > Looks like the schema file was changed, but not added to the list of > > files to be replaced at upgrade, I will open a 389 ticket and have it in > > > > > > the next release. > > > > > > > > Could you try t copy file manually for now ? > > > > > > > > Manually copying the file from /etc/dirsrv/schema/10dna-plugin.ldif to > > /etc/dirsrv/slapd-EXAMPLE-COM/schema/10dna-plugin.ldif on both of my IPA > > masters and restarting seems to have eliminated the error. > > > > > > > > > > > > Is there anything else that needs to be done? > > > > > > > > > > That should be all. BTW, the schema upgrade error is now fixed in > > https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.20-1.fc20 > > With that update, my dirsrv error logs on both of my masters are flooded > > with the following errors. Issuing 'ipactl restart' several times seems > > to > > > > reduce the incidence: > > > > - Connection is NULL and hence cannot access SLAPI_CONN_ID > > > > > > Sorry about that - this will be fixed in 1.3.2.21. > > Thank you, Rich. > > > > > > > > > > Also, I'm not sure if it's related to the above error, but the following > > are what I find related to the originally reported dnaremotebindmethod > > issue after upgrading both of my masters. > > > > > > > > Should the dnaRemoteBindMethod and dnaRemoteConnProtocol have something > > other than (null) as a value? Should they be the same on each master? > > > > > > > > ~]# ldapsearch -Y GSSAPI -LLL -s sub -b cn=posix- > > ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com > > SASL/GSSAPI authentication started > > SASL username: ad...@example.com > > SASL SSF: 56 > > SASL data security layer installed. > > dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com > > objectClass: nsContainer > > objectClass: top > > cn: posix-ids > > > > > > > > dn: > > dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn > > =etc,dc=example,dc=com > > objectClass: dnaSharedConfig > > objectClass: top > > dnaHostname: ipa1.example.com > > dnaPortNum: 389 > > dnaSecurePortNum: 636 > > dnaRemainingValues: 199972 > > dnaRemoteBindMethod: (null) > > dnaRemoteConnProtocol: (null) > > > > > > > > This looks wrong. Please file a ticket. > > I'm having trouble understanding the problem in order to file a ticket... > > > > > > > > I first upgraded to 389-ds-base-1.3.2.19-1.fc20.x86_64 where I received > > the > > schema errors as well as > > > > > > > > dna-plugin - dna_update_shared_config: Unable to update shared config > > entry: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix- > > ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com [error 65] > > > > > > > > I then upgraded to 389-ds-base-1.3.2.20-1.fc20. Unfortunately, I cannot > > be > > sure what *should* be present for each of dnaRemoteBindMethod and > > dnaRemoteConnProtocol *or* if any original values were deleted when I > > first > > installed 389-ds-base-1.3.2.19-1.fc20.x86_64. If so, how would I know > > what > > the values were? > > > > > > > > I'm not sure. What I think is that these should not be present at all - > > I > > think they are just copied from the replication agreement configuration. > > > > > > > > Also, should the ticket be filed against 389, or against FreeIPA? > > > > > > > > 389 > > Ticket filed: https://fedorahosted.org/389/ticket/47866 > > > > > > > dn: > > dnaHostname=ipa2.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn > > =etc,dc=example,dc=com > > objectClass: dnaSharedConfig > > objectClass: top > > dnaHostname: ipa2.example.com > > dnaPortNum: 389 > > dnaSecurePortNum: 636 > > dnaRemainingValues: 0 > > > > Shouldn't the "second" master also have values for dnaRemoteBindMethod and > > dnaRemoteConnProtocol? For others who may be looking into this issue, I copied the values from the FreeIPA replication agreement: nsDS5ReplicaBindMethod: SASL/GSSAPI nsDS5ReplicaTransportInfo: LDAP and ldapmodify-d as follows: dn: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn =etc,dc=example,dc=com changetype: modify replace: dnaRemoteBindMethod dnaRemoteBindMethod: SASL/GSSAPI - replace: dnaRemoteConnProtocol dnaRemoteConnProtocol: LDAP -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E signature.asc Description: This is a digitally signed message part. -- 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
Re: [Freeipa-users] AD Trusts: Should tcp/389/636 be excluded or not?
On 08/04/2014 04:37 PM, Alexander Bokovoy wrote:
On Mon, 04 Aug 2014, Mark Heslin wrote:
Folks,
Does anyone know the current disposition of $subject? The FreeIPA
documentation:
http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Firewall_configuration
would seem to indicate this is no longer necessary. Is this
"official" or should we block
just the Win/AD server from these ports?
Alexander Bokovoy and I were working together last Friday on a
cross-realm Kerberos trust
to an AD server (Win2012 R2) and noticed replication was not working
because I had
tcp/389 and tcp/636 REJECT configured on the IdM servers. After
removing the rules
everything is working again.
Currently, I still have the rules removed but would like to know
whether to keep them removed
or add them back in but block only the packets from the Win/AD server.
Never ever block tcp/389 and tcp/636 between IPA servers or your
replication will not work at all. The instruction we show at the end of
ipa-adtrust-install is related only to communication with AD DCs for
the sake of their sanity as any attempt to use LDAP(S) over TCP against
IPA servers will most likely confuse Windows machines due to completely
different schema used. LDAP over UDP is required for trusts as
connectionless LDAP (CLDAP) is part of discovery protocol that AD
machines expect to work.
Blocking TCP/389 and TCP/636 between AD DCs and IPA servers should not
hurt.
Good. I can modify the firewalld rules accordingly:
ipv4 filter ipa-server-chain 0 --proto tcp --destination-port 389 !
--source {ad-server-ip} --jump ACCEPT
ipv4 filter ipa-server-chain 0 --proto tcp --destination-port 636 !
--source {ad-server-ip} --jump ACCEPT
Thanks Alexander :-)
-m
--
Red Hat Reference Architectures
Follow Us: https://twitter.com/RedHatRefArch
Plus Us: https://plus.google.com/u/0/b/114152126783830728030/
Like Us: https://www.facebook.com/rhrefarch
--
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] RHEL 7 Upgrade experience so far
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/04/2014 08:46 AM, Rob Crittenden wrote:
> Erinn Looney-Triggs wrote:
>> On 08/04/2014 04:01 AM, Martin Kosek wrote:
>>> On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote:
> Whether related or not I am getting the following in my
> RHEL 6.5 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug
> log:
> [26/Jul/2014:20:23:23 +] slapi_ldap_bind - Error:
> could not send startTLS re quest: error -1 (Can't contact
> LDAP server) errno 107 (Transport endpoint is not
> connected) [26/Jul/2014:20:23:23 +]
> NSMMReplicationPlugin - agmt="cn=masterAgreement1-i
> pa2.example.com-pki-ca" (ipa2:7389): Replication bind with
> SIMPLE auth failed: LD AP error -1 (Can't contact LDAP
> server) ((null)) [26/Jul/2014:20:23:37 +]
> slapi_ldap_bind - Error: could not send startTLS re quest:
> error -1 (Can't contact LDAP server) errno 107 (Transport
> endpoint is not connected) [26/Jul/2014:20:23:48 +]
> slapi_ldap_bind - Error: could not send startTLS re quest:
> error -1 (Can't contact LDAP server) errno 107 (Transport
> endpoint is not connected)
> And these errors just continue to be logged.
> When attempting to run ipa-ca-install -d on the RHEL 7
> replica (all other services are on there running fine) I
> receive the following:
> ipa : CRITICAL failed to configure ca instance
> Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF'
> returned non-zero exit status 1 ipa : DEBUG
> File
> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
>
>>
>
line 638, in run_script
> return_value = main_function()
> File "/usr/sbin/ipa-ca-install", line 179, in main CA =
> cainstance.install_replica_ca(config, postinstall=True)
> File
> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>
>>
>
line 1678, in install_replica_ca
> subject_base=config.subject_base)
> File
> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>
>>
>
line 478, in configure_instance
> self.start_creation(runtime=210)
> File
> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>
>
>>
>
line 364, in start_creation method()
> File
> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>
>>
>
line 604, in __spawn_instance
> raise RuntimeError('Configuration of CA failed')
> ipa : DEBUGThe ipa-ca-install command failed,
> exception: RuntimeError: Configuration of CA failed
> Your system may be partly configured. Run
> /usr/sbin/ipa-server-install --uninstall to clean up.
> Configuration of CA failed
> So this behavior changed after restarting the IPA service
> on the RHEL 6.5 system.
> So at this point I have a RHEL 6.5 system and a RHEL 7
> replica of everything except the CA. The RHEL 6.5 system,
> when the IPA service is restarted throws an error, perhaps
> from schema change?
> Any ideas?
> -Erinn
I went in and debugged this a bit further by changing the
verbosity for nsslapd-errorlog-level. It appears that the
rhel 6.5 system is attempting to connect to the RHEL 7 system
on port 7389 and since the RHEL 7 system does not have the CA
installed this would obviously fail. This leads me to believe
that there is cruft in the directory that is pointing to the
wrong place. I don't think this will fix my second group of
errors, but how does one view the replication agreements
specifically for the ca?
As well I omitted to lines from the ipa-ca-install error
which are probably pertinent:
ERROR: Unable to access directory server: Server is
unwilling to perform
ipa : DEBUGstderr=
-Erinn
>>
>>> This is strange. ipa-ca-install/ipa-replica-install --setup-ca
>>> should create the replication agreement pointing at port 389
>>> on RHEL-7.0, given that the 2 originally separated DS databases
>>> were merged.
>>
>>> It looks like this is some replication agreement left over
>>> from previous tests.
>>
>>> Anyway, to list all hosts with PKI, try:
>>
>>> # ipa-csreplica-manage list Directory Manager password:
>>
>>> vm-089.idm.lab.bos.redhat.com: master
>>> vm-086.idm.lab.bos.redhat.com: master
>>
>>> "master" means that this server has PKI service installed. It
>>> will show different value if there is no PKI service.
>>
>>> To check PKI replication agreements for specific hostname,
>>> run:
>>
>>> # ipa-csreplica-manage list `hostname` Directory Manager
>>> password:
>>
>>> vm-089.idm.lab.bos.redhat.com
>>
>>> Check "man
Re: [Freeipa-users] AD Trusts: Should tcp/389/636 be excluded or not?
On Mon, 04 Aug 2014, Mark Heslin wrote: Folks, Does anyone know the current disposition of $subject? The FreeIPA documentation: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Firewall_configuration would seem to indicate this is no longer necessary. Is this "official" or should we block just the Win/AD server from these ports? Alexander Bokovoy and I were working together last Friday on a cross-realm Kerberos trust to an AD server (Win2012 R2) and noticed replication was not working because I had tcp/389 and tcp/636 REJECT configured on the IdM servers. After removing the rules everything is working again. Currently, I still have the rules removed but would like to know whether to keep them removed or add them back in but block only the packets from the Win/AD server. Never ever block tcp/389 and tcp/636 between IPA servers or your replication will not work at all. The instruction we show at the end of ipa-adtrust-install is related only to communication with AD DCs for the sake of their sanity as any attempt to use LDAP(S) over TCP against IPA servers will most likely confuse Windows machines due to completely different schema used. LDAP over UDP is required for trusts as connectionless LDAP (CLDAP) is part of discovery protocol that AD machines expect to work. Blocking TCP/389 and TCP/636 between AD DCs and IPA servers should not hurt. -- / Alexander Bokovoy -- 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] AD Trusts: Should tcp/389/636 be excluded or not?
Folks, Does anyone know the current disposition of $subject? The FreeIPA documentation: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Firewall_configuration would seem to indicate this is no longer necessary. Is this "official" or should we block just the Win/AD server from these ports? Alexander Bokovoy and I were working together last Friday on a cross-realm Kerberos trust to an AD server (Win2012 R2) and noticed replication was not working because I had tcp/389 and tcp/636 REJECT configured on the IdM servers. After removing the rules everything is working again. Currently, I still have the rules removed but would like to know whether to keep them removed or add them back in but block only the packets from the Win/AD server. Thanks, =m -- Red Hat Reference Architectures Follow Us: https://twitter.com/RedHatRefArch Plus Us: https://plus.google.com/u/0/b/114152126783830728030/ Like Us: https://www.facebook.com/rhrefarch -- 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] RHEL 7 Upgrade experience so far
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/04/2014 11:48 AM, Ade Lee wrote: > OK - so its not really even getting started on the install. My > guess is there is some cruft from previous installs/uninstalls that > was not cleaned up. Is there anything in the directory server logs > on the RHEL7 machine? What operation is being attempted that the > server is refusing to perform? > > Ade > Ok I moved on past this issue. Problem was minssf was set to 56 on the RHEL 7 dirsrv instance, setting it to 0 resolved this issue. Thanks for having me check the dir on the RHEL 7 instance I was assuming it was hitting against the RHEL 6.5 instance and was finding basically nothing there. This run looks like it pulled a lot more information in but it still errored out. ipa : DEBUGstderr=pkispawn: WARNING ... unable to validate security domain user/password through REST interface. Interface not available pkispawn: ERROR... Exception from Java Configuration Servlet: Error in confguring system certificatesjava.security.cert.CertificateException: Unable to initialize, java.io.IOException: DerInput.getLength(): lengthTag=127, too big. ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpbTnSRM' returned non-zero exit status 1 - From the /var/log/pki/pki-tomcat/ca/debug log on the RHEL 7 instance: [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: initializing with mininum 3 and maximum 15 connections to host ipa2.abaqis.com port 389, secure connection, false, authentication type 1 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: increasing minimum connections by 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new total available connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new number of connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: In LdapBoundConnFactory::getConn() [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: masterConn is connected: true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: conn is connected true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: mNumConns now 2 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS: param=preop.internaldb.post_ldif [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif file = /usr/share/pki/ca/conf/vlv.ldif [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif file copy to /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): LDAP Errors in importing /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allInvalidCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allInValidCertsNotBefore-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allNonRevokedCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allRevokedCaCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allRevokedCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allRevokedCertsNotAfter-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allRevokedExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allRevokedOrRevokedExpiredCaCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: e
Re: [Freeipa-users] Centos7, selinux, certmonger, and openldap
> Hmm, sorry for incomplete instructions then. I updated the instructions to > cope with that situation better (details in > https://fedorahosted.org/freeipa/ticket/4466#comment:2). Please feel free > to report more findings or even better help us enhance the page even > further :-) Hmm, I thought it looked like your wiki, but when there was no login in the upper-right corner, I assumed it was an online version of your manual. That always gets me, even when I'm looking at a page I know I created myself. In this case, tho, I was definitely not qualified to provide a fix. New to both certmonger and that Mozilla certificate database thing. Made a comment on the talk page about the related OpenLDAP selinux issues (more than one cert_t defined). Dunno if you get notifications. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- 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] Possible to extract password of ldap
On 08/01/2014 12:23 AM, barry...@gmail.com wrote: Hi : Is it possible to read clear text of password of ipa users by admin ? No. I m facing the issue of half rollout as half vol.of users changed password already. And if i deploy and reset all password then it may make issue for this half and we dont have records which user password sent . -- 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] RHEL 7 Upgrade experience so far
Erinn Looney-Triggs wrote:
> On 08/04/2014 04:01 AM, Martin Kosek wrote:
>> On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote:
>>>
>>>
>>>
>>>
Whether related or not I am getting the following in my RHEL
6.5 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug log:
>>>
[26/Jul/2014:20:23:23 +] slapi_ldap_bind - Error: could
not send startTLS re quest: error -1 (Can't contact LDAP
server) errno 107 (Transport endpoint is not connected)
[26/Jul/2014:20:23:23 +] NSMMReplicationPlugin -
agmt="cn=masterAgreement1-i pa2.example.com-pki-ca"
(ipa2:7389): Replication bind with SIMPLE auth failed: LD AP
error -1 (Can't contact LDAP server) ((null))
[26/Jul/2014:20:23:37 +] slapi_ldap_bind - Error: could
not send startTLS re quest: error -1 (Can't contact LDAP
server) errno 107 (Transport endpoint is not connected)
[26/Jul/2014:20:23:48 +] slapi_ldap_bind - Error: could not
send startTLS re quest: error -1 (Can't contact LDAP server)
errno 107 (Transport endpoint is not connected)
>>>
And these errors just continue to be logged.
>>>
When attempting to run ipa-ca-install -d on the RHEL 7 replica
(all other services are on there running fine) I receive the
following:
>>>
ipa : CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF' returned
non-zero exit status 1 ipa : DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
>>>
>>>
>>>
> line 638, in run_script
return_value = main_function()
>>>
File "/usr/sbin/ipa-ca-install", line 179, in main CA =
cainstance.install_replica_ca(config, postinstall=True)
>>>
File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>>>
>>>
>>>
> line 1678, in install_replica_ca
subject_base=config.subject_base)
>>>
File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>>>
>>>
>>>
> line 478, in configure_instance
self.start_creation(runtime=210)
>>>
File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line 364, in start_creation method()
>>>
File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>>>
>>>
>>>
> line 604, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
>>>
ipa : DEBUGThe ipa-ca-install command failed,
exception: RuntimeError: Configuration of CA failed
>>>
Your system may be partly configured. Run
/usr/sbin/ipa-server-install --uninstall to clean up.
>>>
Configuration of CA failed
>>>
>>>
So this behavior changed after restarting the IPA service on
the RHEL 6.5 system.
>>>
So at this point I have a RHEL 6.5 system and a RHEL 7 replica
of everything except the CA. The RHEL 6.5 system, when the IPA
service is restarted throws an error, perhaps from schema
change?
>>>
Any ideas?
>>>
-Erinn
>>>
>>>
>>>
>>> I went in and debugged this a bit further by changing the
>>> verbosity for nsslapd-errorlog-level. It appears that the rhel
>>> 6.5 system is attempting to connect to the RHEL 7 system on port
>>> 7389 and since the RHEL 7 system does not have the CA installed
>>> this would obviously fail. This leads me to believe that there is
>>> cruft in the directory that is pointing to the wrong place. I
>>> don't think this will fix my second group of errors, but how does
>>> one view the replication agreements specifically for the ca?
>>>
>>> As well I omitted to lines from the ipa-ca-install error which
>>> are probably pertinent:
>>>
>>> ERROR: Unable to access directory server: Server is unwilling to
>>> perform
>>>
>>> ipa : DEBUGstderr=
>>>
>>> -Erinn
>
>> This is strange. ipa-ca-install/ipa-replica-install --setup-ca
>> should create the replication agreement pointing at port 389 on
>> RHEL-7.0, given that the 2 originally separated DS databases were
>> merged.
>
>> It looks like this is some replication agreement left over from
>> previous tests.
>
>> Anyway, to list all hosts with PKI, try:
>
>> # ipa-csreplica-manage list Directory Manager password:
>
>> vm-089.idm.lab.bos.redhat.com: master
>> vm-086.idm.lab.bos.redhat.com: master
>
>> "master" means that this server has PKI service installed. It will
>> show different value if there is no PKI service.
>
>> To check PKI replication agreements for specific hostname, run:
>
>> # ipa-csreplica-manage list `hostname` Directory Manager password:
>
>> vm-089.idm.lab.bos.redhat.com
>
>> Check "man ipa-csreplica-manage" for advise how to delete or create
>> the PKI agreements.
>
>> HTH, Martin
>
>
> Yeah here is what I get:
> ipa-csreplica-manage list
> Directory Manager password:
>
> ipa2.example.com: CA not configured
> ipa.example.com: master
>
> ipa2 is my rhel7 instance, ipa is the rhel 6.5 instance.
>
> ipa-
Re: [Freeipa-users] RHEL 7 Upgrade experience so far
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/04/2014 04:01 AM, Martin Kosek wrote:
> On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote:
>>
>>
>>
>>
>>> Whether related or not I am getting the following in my RHEL
>>> 6.5 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug log:
>>
>>> [26/Jul/2014:20:23:23 +] slapi_ldap_bind - Error: could
>>> not send startTLS re quest: error -1 (Can't contact LDAP
>>> server) errno 107 (Transport endpoint is not connected)
>>> [26/Jul/2014:20:23:23 +] NSMMReplicationPlugin -
>>> agmt="cn=masterAgreement1-i pa2.example.com-pki-ca"
>>> (ipa2:7389): Replication bind with SIMPLE auth failed: LD AP
>>> error -1 (Can't contact LDAP server) ((null))
>>> [26/Jul/2014:20:23:37 +] slapi_ldap_bind - Error: could
>>> not send startTLS re quest: error -1 (Can't contact LDAP
>>> server) errno 107 (Transport endpoint is not connected)
>>> [26/Jul/2014:20:23:48 +] slapi_ldap_bind - Error: could not
>>> send startTLS re quest: error -1 (Can't contact LDAP server)
>>> errno 107 (Transport endpoint is not connected)
>>
>>> And these errors just continue to be logged.
>>
>>> When attempting to run ipa-ca-install -d on the RHEL 7 replica
>>> (all other services are on there running fine) I receive the
>>> following:
>>
>>> ipa : CRITICAL failed to configure ca instance Command
>>> '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF' returned
>>> non-zero exit status 1 ipa : DEBUG File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
>>
>>
>>
>>>
line 638, in run_script
>>> return_value = main_function()
>>
>>> File "/usr/sbin/ipa-ca-install", line 179, in main CA =
>>> cainstance.install_replica_ca(config, postinstall=True)
>>
>>> File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>>
>>
>>
>>>
line 1678, in install_replica_ca
>>> subject_base=config.subject_base)
>>
>>> File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>>
>>
>>
>>>
line 478, in configure_instance
>>> self.start_creation(runtime=210)
>>
>>> File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>>>
>>>
line 364, in start_creation method()
>>
>>> File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>>
>>
>>
>>>
line 604, in __spawn_instance
>>> raise RuntimeError('Configuration of CA failed')
>>
>>> ipa : DEBUGThe ipa-ca-install command failed,
>>> exception: RuntimeError: Configuration of CA failed
>>
>>> Your system may be partly configured. Run
>>> /usr/sbin/ipa-server-install --uninstall to clean up.
>>
>>> Configuration of CA failed
>>
>>
>>> So this behavior changed after restarting the IPA service on
>>> the RHEL 6.5 system.
>>
>>> So at this point I have a RHEL 6.5 system and a RHEL 7 replica
>>> of everything except the CA. The RHEL 6.5 system, when the IPA
>>> service is restarted throws an error, perhaps from schema
>>> change?
>>
>>> Any ideas?
>>
>>> -Erinn
>>
>>
>>
>> I went in and debugged this a bit further by changing the
>> verbosity for nsslapd-errorlog-level. It appears that the rhel
>> 6.5 system is attempting to connect to the RHEL 7 system on port
>> 7389 and since the RHEL 7 system does not have the CA installed
>> this would obviously fail. This leads me to believe that there is
>> cruft in the directory that is pointing to the wrong place. I
>> don't think this will fix my second group of errors, but how does
>> one view the replication agreements specifically for the ca?
>>
>> As well I omitted to lines from the ipa-ca-install error which
>> are probably pertinent:
>>
>> ERROR: Unable to access directory server: Server is unwilling to
>> perform
>>
>> ipa : DEBUGstderr=
>>
>> -Erinn
>
> This is strange. ipa-ca-install/ipa-replica-install --setup-ca
> should create the replication agreement pointing at port 389 on
> RHEL-7.0, given that the 2 originally separated DS databases were
> merged.
>
> It looks like this is some replication agreement left over from
> previous tests.
>
> Anyway, to list all hosts with PKI, try:
>
> # ipa-csreplica-manage list Directory Manager password:
>
> vm-089.idm.lab.bos.redhat.com: master
> vm-086.idm.lab.bos.redhat.com: master
>
> "master" means that this server has PKI service installed. It will
> show different value if there is no PKI service.
>
> To check PKI replication agreements for specific hostname, run:
>
> # ipa-csreplica-manage list `hostname` Directory Manager password:
>
> vm-089.idm.lab.bos.redhat.com
>
> Check "man ipa-csreplica-manage" for advise how to delete or create
> the PKI agreements.
>
> HTH, Martin
>
Yeah here is what I get:
ipa-csreplica-manage list
Directory Manager password:
ipa2.example.com: CA not configured
ipa.example.com: master
ipa2 is my rhel7 instance, ipa is the rhel 6.5 instance.
ipa-csreplica-manage list ipa2.example.com
Directory Manager password:
Can't contact LDAP server
Which I guess
Re: [Freeipa-users] RHEL 7 Upgrade experience so far
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/04/2014 06:36 AM, Ade Lee wrote:
>>
>> Well here is probably the pertinent part of the debug log,
>> though there is a lot more when the clone is setting up:
>> [31/Jul/2014:13:23:53][TP-Processor3]: AuthMgrName:
>> certUserDBAuthMgr [31/Jul/2014:13:23:53][TP-Processor3]:
>> CMSServlet: retrieving SSL certificate
>> [31/Jul/2014:13:23:53][TP-Processor3]: CMSServlet: certUID=CN=CA
>> Subsystem,O=example.COM [31/Jul/2014:13:23:53][TP-Processor3]:
>> CertUserDBAuth: started [31/Jul/2014:13:23:53][TP-Processor3]:
>> CertUserDBAuth: Retrieving client certificate
>> [31/Jul/2014:13:23:53][TP-Processor3]: CertUserDBAuth: Got
>> client certificate [31/Jul/2014:13:23:53][TP-Processor3]: In
>> LdapBoundConnFactory::getConn()
>> [31/Jul/2014:13:23:53][TP-Processor3]: masterConn is connected:
>> true [31/Jul/2014:13:23:53][TP-Processor3]: getConn: conn is
>> connected true [31/Jul/2014:13:23:53][TP-Processor3]: getConn:
>> mNumConns now 2 [31/Jul/2014:13:23:53][TP-Processor3]:
>> returnConn: mNumConns now 3
>> [31/Jul/2014:13:23:53][TP-Processor3]: Authentication: client
>> certificate found [31/Jul/2014:13:23:53][TP-Processor3]: In
>> LdapBoundConnFactory::getConn()
>> [31/Jul/2014:13:23:53][TP-Processor3]: masterConn is connected:
>> true [31/Jul/2014:13:23:53][TP-Processor3]: getConn: conn is
>> connected true [31/Jul/2014:13:23:53][TP-Processor3]: getConn:
>> mNumConns now 2 [31/Jul/2014:13:23:53][TP-Processor3]:
>> returnConn: mNumConns now 3
>> [31/Jul/2014:13:23:53][TP-Processor3]: SignedAuditEventFactory:
>> create()
>> message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=CA
>>
>>
Subsystem,O=example.COM] authentication failure
>>
>> [31/Jul/2014:13:23:53][TP-Processor3]: CMSServlet: curDate=Thu
>> Jul 31 13:23:53 GMT 2014 id=caUpdateDomainXML time=11
>>
> Lets focus on the above error. This says that the master was
> unable to map the certificate that was presented to a user under
> ou=users, o=ipaca.
>
> I would look at the database (for the master) and see what users
> are defined. Check which users have the subsystem certificate
> defined as their certificate, and check the description attribute.
> That attribute should contain a string that includes the
> certificate serial number, subject DN and issuer, delimited by
> semicolons. Check that string and confirm that the certificate for
> that user matches the description delimiter, and that the subsystem
> certificate is the same as the subsystem certificate in the replica
> certdb.
>
> It would also be useful to see what the DS access logs say at the
> time this authentication failure occurs.
>
> Ade
>>
>> -Erinn
>>
>
>
Well unfortunately, after restarting the IPA services on the RHEL 6.5
system I no longer receive this error at all. Using ipa-ca-install
fails in the steps before this error was received.
ipa : DEBUGStarting external process
ipa : DEBUGargs=/usr/sbin/pkispawn -s CA -f /tmp/tmpvByIvk
ipa : DEBUGProcess finished, return code=1
ipa : DEBUGstdout=Loading deployment configuration from
/tmp/tmpvByIvk.
ERROR: Unable to access directory server: Server is unwilling to perform
ipa : DEBUGstderr=
ipa : CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpvByIvk' returned non-zero exit
status 1
ipa : DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 638, in run_script
return_value = main_function()
File "/usr/sbin/ipa-ca-install", line 179, in main
CA = cainstance.install_replica_ca(config, postinstall=True)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 1678, in install_replica_ca
subject_base=config.subject_base)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 478, in configure_instance
self.start_creation(runtime=210)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
364, in start_creation
method()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 604, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
ipa : DEBUGThe ipa-ca-install command failed, exception:
RuntimeError: Configuration of CA failed
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Configuration of CA failed
And the access log from /var/log/dirsrv/slapd-PKI-CA/access on the
RHEL 6.5 master only shows this:
[04/Aug/2014:14:16:25 +] conn=211 fd=74 slot=74 connection from
2001:4870:800e:301:862b:2bff:fe67:704d to
2001:4870:800e:301:f24d:a2ff:fe09:ae0
[04/Aug/2014:14:16:25 +] conn=211 op=0 EXT
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[04/Aug/2014:14:16:25 +] conn=211 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[04/Aug/2014:14:16:25 +] conn=211
Re: [Freeipa-users] RHEL 7 Upgrade experience so far
On Thu, 2014-07-31 at 06:27 -0700, Erinn Looney-Triggs wrote:
> On 07/30/2014 02:31 PM, Ade Lee wrote:
> > On Tue, 2014-07-29 at 17:49 -0700, Erinn Looney-Triggs wrote:
>
> >>
> Ok, well I tried deleting it using certutil it deletes both,
> I tried using keytool to see if it would work any better, no
> dice there. I'll try the rename, but at this point I am not
> holding my breath on that, it seems all operation are a bit
> too coarse. It seems the assumption was being made that there
> would only be one of each nickname. Which frankly makes me
> wonder how any of this kept running after the renewal.
>
> For now I'll see what I can do on a copy of the db using
> python.
> >>>
> >>> It is a little strange that there are multiple 'caSigningCert
> >>> cert-pki-ca' as this is the CA itself. It should be good for
> >>> 20 years and isn't something that the current renewal code
> >>> handles yet.
> >>>
> >>> You probably won't have much luck with python-nss. It can
> >>> handle reading PKCS#12 files but I don't believe it can write
> >>> them (access to key material).
> >>>
> >>> I'm not sure why certutil didn't do the trick. This should
> >>> work, if you want to give it another try. I'm assuming that
> >>> /root/cacert.p12 has the latest exported certs, adjust as
> >>> necessary:
> >>>
> >>> # certutil -N -d /tmp/test # pk12util -i /root/cacert.p12 -d
> >>> /tmp/test # certutil -D -d /tmp/test -n ''
> >>>
> >>> certutil should delete the oldest cert first, it always has
> >>> for me.
> >>>
> >>> rob
> >>>
> >>
> >> Ok folks I managed to clean up the certificate DB so there is
> >> only one valid certificate for each service. Installation
> >> continued pass that step and then failed shortly thereafter on
> >> configuring the ca. So here is my new error:
> >>
> >>
> >> pkispawn: ERROR... Exception from Java Configuration
> >> Servlet: Error while updating security domain:
> >> java.io.IOException: 2 pkispawn: DEBUG... Error Type:
> >> HTTPError pkispawn: DEBUG... Error Message: 500
> >> Server Error: Internal Server Error pkispawn: DEBUG
> >> ... File "/usr/sbin/pkispawn", line 374, in main rv =
> >> instance.spawn() File
> >> "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py",
> >>
> >>
> line 128, in spawn
> >> json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File
> >> "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py",
> >> line 2998, in configure_pki_data response =
> >> client.configure(data) File
> >> "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in
> >> configure r = self.connection.post('/rest/installer/configure',
> >> data, headers) File
> >> "/usr/lib/python2.7/site-packages/pki/client.py", line 64, in
> >> post r.raise_for_status() File
> >> "/usr/lib/python2.7/site-packages/requests/models.py", line 638,
> >> in raise_for_status raise http_error
> >>
> >>
> >> 2014-07-30T00:27:48Z CRITICAL failed to configure ca instance
> >> Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqX9SGx' returned
> >> non-zero exit status 1 2014-07-30T00:27:48Z DEBUG File
> >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
> >>
> >>
> line 638, in run_script
> >> return_value = main_function()
> >>
> >> File "/usr/sbin/ipa-replica-install", line 667, in main CA =
> >> cainstance.install_replica_ca(config)
> >>
> >> File
> >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
> >>
> >>
> line 1678, in install_replica_ca
> >> subject_base=config.subject_base)
> >>
> >> File
> >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
> >>
> >>
> line 478, in configure_instance
> >> self.start_creation(runtime=210)
> >>
> >> File
> >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> >> line 364, in start_creation method()
> >>
> >> File
> >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
> >>
> >>
> line 604, in __spawn_instance
> >> raise RuntimeError('Configuration of CA failed')
> >>
> >> 2014-07-30T00:27:48Z DEBUG The ipa-replica-install command
> >> failed, exception: RuntimeError: Configuration of CA failed
> >>
> >> And from the pki-tomcat/ca debug log: isSDHostDomainMaster():
> >> Getting domain.xml from CA...
> >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML start
> >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML:
> >> status=0 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]:
> >> getDomainXML: domainInfo= >> standalone="no"?>IPAipa.example.com44344344344380FALSEpki-cadTRUE10
> >>
> >>
> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: Cloning a domain master
> >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase
> >> updateDomainXML start hostname=ipa.example.com port=443
> >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]:
> >> updateSecurityDomain: failed to update security domain using
> >> admin po
Re: [Freeipa-users] Centos7, selinux, certmonger, and openldap
On 08/04/2014 01:36 AM, Nordgren, Bryce L -FS wrote: > Spoke too soon. I needed the following "extra" selinux policy module to make > all the AVCs go away. > > BTW: the instructions on http://www.freeipa.org/page/PKI really only work if > you leave the password blank when you create a new database with certutil. > Otherwise, the "ipa-getcert request" command creates tracking requests which > get stuck. Databases with passwords cause certmonger to error with a "Cert > storage slot still needs user PIN to be set.." This took me a couple of hours > to track down. Hmm, sorry for incomplete instructions then. I updated the instructions to cope with that situation better (details in https://fedorahosted.org/freeipa/ticket/4466#comment:2). Please feel free to report more findings or even better help us enhance the page even further :-) HTH, Martin -- 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] RHEL 7 Upgrade experience so far
On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote:
>
>
>
>
>> Whether related or not I am getting the following in my RHEL 6.5
>> IPA instance /var/log/dirsrv/slapd-PKI-CA/debug log:
>
>> [26/Jul/2014:20:23:23 +] slapi_ldap_bind - Error: could not
>> send startTLS re quest: error -1 (Can't contact LDAP server) errno
>> 107 (Transport endpoint is not connected) [26/Jul/2014:20:23:23
>> +] NSMMReplicationPlugin - agmt="cn=masterAgreement1-i
>> pa2.example.com-pki-ca" (ipa2:7389): Replication bind with SIMPLE
>> auth failed: LD AP error -1 (Can't contact LDAP server) ((null))
>> [26/Jul/2014:20:23:37 +] slapi_ldap_bind - Error: could not
>> send startTLS re quest: error -1 (Can't contact LDAP server) errno
>> 107 (Transport endpoint is not connected) [26/Jul/2014:20:23:48
>> +] slapi_ldap_bind - Error: could not send startTLS re quest:
>> error -1 (Can't contact LDAP server) errno 107 (Transport endpoint
>> is not connected)
>
>> And these errors just continue to be logged.
>
>> When attempting to run ipa-ca-install -d on the RHEL 7 replica
>> (all other services are on there running fine) I receive the
>> following:
>
>> ipa : CRITICAL failed to configure ca instance Command
>> '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF' returned non-zero
>> exit status 1 ipa : DEBUG File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
>
>
> line 638, in run_script
>> return_value = main_function()
>
>> File "/usr/sbin/ipa-ca-install", line 179, in main CA =
>> cainstance.install_replica_ca(config, postinstall=True)
>
>> File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>
>
> line 1678, in install_replica_ca
>> subject_base=config.subject_base)
>
>> File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>
>
> line 478, in configure_instance
>> self.start_creation(runtime=210)
>
>> File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>> line 364, in start_creation method()
>
>> File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>
>
> line 604, in __spawn_instance
>> raise RuntimeError('Configuration of CA failed')
>
>> ipa : DEBUGThe ipa-ca-install command failed,
>> exception: RuntimeError: Configuration of CA failed
>
>> Your system may be partly configured. Run
>> /usr/sbin/ipa-server-install --uninstall to clean up.
>
>> Configuration of CA failed
>
>
>> So this behavior changed after restarting the IPA service on the
>> RHEL 6.5 system.
>
>> So at this point I have a RHEL 6.5 system and a RHEL 7 replica of
>> everything except the CA. The RHEL 6.5 system, when the IPA service
>> is restarted throws an error, perhaps from schema change?
>
>> Any ideas?
>
>> -Erinn
>
>
>
> I went in and debugged this a bit further by changing the verbosity
> for nsslapd-errorlog-level. It appears that the rhel 6.5 system is
> attempting to connect to the RHEL 7 system on port 7389 and since the
> RHEL 7 system does not have the CA installed this would obviously
> fail. This leads me to believe that there is cruft in the directory
> that is pointing to the wrong place. I don't think this will fix my
> second group of errors, but how does one view the replication
> agreements specifically for the ca?
>
> As well I omitted to lines from the ipa-ca-install error which are
> probably pertinent:
>
> ERROR: Unable to access directory server: Server is unwilling to perform
>
> ipa : DEBUGstderr=
>
> -Erinn
This is strange. ipa-ca-install/ipa-replica-install --setup-ca should create
the replication agreement pointing at port 389 on RHEL-7.0, given that the 2
originally separated DS databases were merged.
It looks like this is some replication agreement left over from previous tests.
Anyway, to list all hosts with PKI, try:
# ipa-csreplica-manage list
Directory Manager password:
vm-089.idm.lab.bos.redhat.com: master
vm-086.idm.lab.bos.redhat.com: master
"master" means that this server has PKI service installed. It will show
different value if there is no PKI service.
To check PKI replication agreements for specific hostname, run:
# ipa-csreplica-manage list `hostname`
Directory Manager password:
vm-089.idm.lab.bos.redhat.com
Check "man ipa-csreplica-manage" for advise how to delete or create the PKI
agreements.
HTH,
Martin
--
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 Replica does not start Bind but runs Manually
On 08/04/2014 09:40 AM, Matt . wrote: > Hi, > > Yes I did in the past. THe DNS tabs are there and named is installed. You probably installed DNS service on another FreeIPA server. However, there is a configuration space telling which server has which services configured. It seems that it does not see your current server as the DNS server. > Can I run that "over" without any issue ? Yes, If it detects that DNS service was already installed there it will error out. Then we will do different route. > In any other case I just can reinstall the ipa software on the replica > and create a new setup for it... Let's not go this way (yet), simple DNS service installation should be work. Martin -- 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] Users not inheriting groups
On Mon, Aug 04, 2014 at 09:18:11AM +0200, Jakub Hrozek wrote: > On Fri, Aug 01, 2014 at 10:58:14AM -0700, William Graboyes wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Thanks for your help, > > > > The group memberships are propagated properly on the server side: > > > > dn: uid=user,cn=users,cn=accounts,dc=cenic,dc=org > > uid: user > > givenname: userfn > > sn: userln > > cn: userfn userln > > displayname: userfn userln > > initials: uu > > homedirectory: /home/user > > gecos: userfn userln > > loginshell: /bin/bash > > krbprincipalname: u...@org.org > > mail: u...@cenic.org > > uidnumber: 1080 > > gidnumber: 1080 > > nsaccountlock: False > > has_password: True > > has_keytab: True > > ipauniqueid: 2d01b68e-fb38-11e3-9d0d-525400e99b50 > > krbextradata: AALodNFTc3JpYXpAQ0VOSUMuT1JHAA== > > krblastfailedauth: 20140731220341Z > > krblastpwdchange: 20140724210440Z > > krblastsuccessfulauth: 20140731223953Z > > krbloginfailedcount: 0 > > krbpasswordexpiration: 20141022210440Z > > krbpwdpolicyreference: > > cn=global_policy,cn=ORG.ORG,cn=kerberos,dc=org,dc=org > > memberof: cn=ipausers,cn=groups,cn=accounts,dc=org,dc=org > > memberof: cn=games,cn=groups,cn=accounts,dc=org,dc=org > > memberof: > > cn=engineering_core_engineers,cn=groups,cn=accounts,dc=org,dc=org > > memberofindirect: cn=rancid_users,cn=groups,cn=accounts,dc=org,dc=org > > memberofindirect: > > ipauniqueid=696df694-e690-11e3-8fc8-525400e99b50,cn=sudorules,cn=sudo,dc=org,dc=org > > memberofindirect: > > ipauniqueid=a3eb8884-ecdc-11e3-a0df-525400e99b50,cn=ng,cn=alt,dc=org,dc=org > > memberofindirect: cn=rancid,cn=groups,cn=accounts,dc=org,dc=org > > memberofindirect: > > cn=engineering_core,cn=groups,cn=accounts,dc=org,dc=org > > memberofindirect: cn=engineering,cn=groups,cn=accounts,dc=org,dc=org > > memberofindirect: cn=staff,cn=groups,cn=accounts,dc=org,dc=org > > mepmanagedentry: cn=sriaz,cn=groups,cn=accounts,dc=org,dc=org > > objectclass: top > > objectclass: person > > objectclass: organizationalperson > > objectclass: inetorgperson > > objectclass: inetuser > > objectclass: posixaccount > > objectclass: krbprincipalaux > > objectclass: krbticketpolicyaux > > objectclass: ipaobject > > objectclass: ipasshuser > > objectclass: ipaSshGroupOfPubKeys > > objectclass: mepOriginEntry > > > > This has been scrubbed, the group that is not being seen on the client > > side is the rancid group, which is showing up here. > > OK, then we know we're looking at a client side problem. > > Can you: > 1) service sssd stop > 2) edit /etc/sssd/sssd.conf and put debug_level=7 into both [nss] > and [domain] sections > 3) service sssd start > 4) sss_cache -UG > 5) id -G $username > > Then attach the logs found at /var/log/sssd/sssd_$domain.log > > If you feel the logs are too sensitive for a mailing list, you can > send them directly to me and CC: pbrezina -at- redhat -dot- com btw do all the groups have a POSIX ID ? We currently have a bug in SSSD where we don't resolve non-POSIX groups correctly. -- 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 Replica does not start Bind but runs Manually
Hi, Yes I did in the past. THe DNS tabs are there and named is installed. Can I run that "over" without any issue ? In any other case I just can reinstall the ipa software on the replica and create a new setup for it... Cheers, Matt 2014-08-04 1:52 GMT+02:00 Simo Sorce : > On Sun, 2014-08-03 at 22:55 +0200, Matt . wrote: >> Hi Guys, >> >> I have installed a replica with DNS which only starts manually and not >> togother with FreeIPA. >> >> It seems that it doesn't have it in it's list to start it, how can I >> solve this ? >> >> # /etc/init.d/ipa restart >> Restarting Directory Service >> Shutting down dirsrv: >> DOMAIN-LOCAL...[ OK ] >> Starting dirsrv: >> DOMAIN-LOCAL...[ OK ] >> Restarting KDC Service >> Stopping Kerberos 5 KDC: [ OK ] >> Starting Kerberos 5 KDC: [ OK ] >> Restarting KPASSWD Service >> Stopping Kerberos 5 Admin Server: [ OK ] >> Starting Kerberos 5 Admin Server: [ OK ] >> Restarting MEMCACHE Service >> Stopping ipa_memcached:[ OK ] >> Starting ipa_memcached:[ OK ] >> Restarting HTTP Service >> Stopping httpd:[ OK ] >> Starting httpd:[ OK ] >> >> I hope someone can help me out! > > Did you instalkl the replica wioth the --setup-dns switch ? > > If not you could tun ipa-dns-install on the replica I guess. > > Simo. > > > -- > Simo Sorce * Red Hat, Inc * New York > -- 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] Users not inheriting groups
On Fri, Aug 01, 2014 at 10:58:14AM -0700, William Graboyes wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Thanks for your help, > > The group memberships are propagated properly on the server side: > > dn: uid=user,cn=users,cn=accounts,dc=cenic,dc=org > uid: user > givenname: userfn > sn: userln > cn: userfn userln > displayname: userfn userln > initials: uu > homedirectory: /home/user > gecos: userfn userln > loginshell: /bin/bash > krbprincipalname: u...@org.org > mail: u...@cenic.org > uidnumber: 1080 > gidnumber: 1080 > nsaccountlock: False > has_password: True > has_keytab: True > ipauniqueid: 2d01b68e-fb38-11e3-9d0d-525400e99b50 > krbextradata: AALodNFTc3JpYXpAQ0VOSUMuT1JHAA== > krblastfailedauth: 20140731220341Z > krblastpwdchange: 20140724210440Z > krblastsuccessfulauth: 20140731223953Z > krbloginfailedcount: 0 > krbpasswordexpiration: 20141022210440Z > krbpwdpolicyreference: > cn=global_policy,cn=ORG.ORG,cn=kerberos,dc=org,dc=org > memberof: cn=ipausers,cn=groups,cn=accounts,dc=org,dc=org > memberof: cn=games,cn=groups,cn=accounts,dc=org,dc=org > memberof: > cn=engineering_core_engineers,cn=groups,cn=accounts,dc=org,dc=org > memberofindirect: cn=rancid_users,cn=groups,cn=accounts,dc=org,dc=org > memberofindirect: > ipauniqueid=696df694-e690-11e3-8fc8-525400e99b50,cn=sudorules,cn=sudo,dc=org,dc=org > memberofindirect: > ipauniqueid=a3eb8884-ecdc-11e3-a0df-525400e99b50,cn=ng,cn=alt,dc=org,dc=org > memberofindirect: cn=rancid,cn=groups,cn=accounts,dc=org,dc=org > memberofindirect: > cn=engineering_core,cn=groups,cn=accounts,dc=org,dc=org > memberofindirect: cn=engineering,cn=groups,cn=accounts,dc=org,dc=org > memberofindirect: cn=staff,cn=groups,cn=accounts,dc=org,dc=org > mepmanagedentry: cn=sriaz,cn=groups,cn=accounts,dc=org,dc=org > objectclass: top > objectclass: person > objectclass: organizationalperson > objectclass: inetorgperson > objectclass: inetuser > objectclass: posixaccount > objectclass: krbprincipalaux > objectclass: krbticketpolicyaux > objectclass: ipaobject > objectclass: ipasshuser > objectclass: ipaSshGroupOfPubKeys > objectclass: mepOriginEntry > > This has been scrubbed, the group that is not being seen on the client > side is the rancid group, which is showing up here. OK, then we know we're looking at a client side problem. Can you: 1) service sssd stop 2) edit /etc/sssd/sssd.conf and put debug_level=7 into both [nss] and [domain] sections 3) service sssd start 4) sss_cache -UG 5) id -G $username Then attach the logs found at /var/log/sssd/sssd_$domain.log If you feel the logs are too sensitive for a mailing list, you can send them directly to me and CC: pbrezina -at- redhat -dot- com -- 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
