[Freeipa-users] easy way to check ipa-client status

2017-10-30 Thread email--- via FreeIPA-users 
Sorarely, a second server is built with the same fqdn, causing an issue 
with the original server kerberos realm membership...thing. 

Is there an easy way to check/confirm this similar to how you'd check the 
computer accounts for M$ AD? 

Thanks in advance! 

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

[Freeipa-users] dirsrv repeatedly hangs

2017-10-30 Thread pgb205 via FreeIPA-users 
We have experienced several cases of end users not being able to authenticate. 
While investigating I've found that I can not obtain kinit credentials on the 
local freeipa replicaipactl however shows all processes including Directory 
Server as running.  Doing ipactl restart hangs but service ipa stop/start does 
help.
In the logs I find the following:cat  errors | grep 
"28/Oct/2017"[28/Oct/2017:01:30:46.931199685 +] NSMMReplicationPlugin - 
agmt="cn=meTomaster.pop1.domain.company" (master:389): Unable to receive the 
response for a startReplication extended operation to consumer (Can't contact 
LDAP server). Will retry later.[28/Oct/2017:01:37:08.323949440 +] 
NSMMReplicationPlugin - agmt="cn=meTomaster.pop1.domain.company" (master:389): 
Replication bind with GSSAPI auth resumed[28/Oct/2017:10:51:48.025975201 +] 
ipa-topology-plugin - ipa_topo_be_state_changebackend userRoot is going 
offline; inactivate plugin[28/Oct/2017:10:51:48.026935974 +] 
NSMMReplicationPlugin - multimaster_be_state_change: replica 
dc=domain,dc=company is going offline; disabling 
replication[28/Oct/2017:10:51:48.263462882 +] WARNING: Import is running 
with nsslapd-db-private-import-mem on; No other process is allowed to access 
the database[28/Oct/2017:10:52:08.300485142 +] import userRoot: Processed 
2042 entries -- average rate 102.1/sec, recent rate 102.0/sec, hit ratio 
0%[28/Oct/2017:10:52:28.330367817 +] import userRoot: Processed 7749 
entries -- average rate 193.7/sec, recent rate 193.7/sec, hit ratio 
100%[28/Oct/2017:10:52:48.360876924 +] import userRoot: Processed 9921 
entries -- average rate 165.3/sec, recent rate 197.0/sec, hit ratio 
100%[28/Oct/2017:10:53:08.391322582 +] import userRoot: Processed 15853 
entries -- average rate 198.2/sec, recent rate 202.6/sec, hit ratio 
100%[28/Oct/2017:10:53:14.802005648 +] import userRoot: Workers finished; 
cleaning up...[28/Oct/2017:10:53:15.002839240 +] import userRoot: Workers 
cleaned up.[28/Oct/2017:10:53:15.003167651 +] import userRoot: Indexing 
complete.  Post-processing...[28/Oct/2017:10:53:15.003384044 +] import 
userRoot: Generating numsubordinates (this may take several minutes to 
complete)...[28/Oct/2017:10:53:15.043991058 +] import userRoot: Generating 
numSubordinates complete.[28/Oct/2017:10:53:15.045232248 +] import 
userRoot: Gathering ancestorid non-leaf IDs...[28/Oct/2017:10:53:15.045698245 
+] import userRoot: Finished gathering ancestorid non-leaf 
IDs.[28/Oct/2017:10:53:15.046529835 +] import userRoot: Creating ancestorid 
index (new idl)...[28/Oct/2017:10:53:15.175418711 +] import userRoot: 
Created ancestorid index (new idl).[28/Oct/2017:10:53:15.175659600 +] 
import userRoot: Flushing caches...[28/Oct/2017:10:53:15.175818325 +] 
import userRoot: Closing files...[28/Oct/2017:10:53:15.243592429 +] import 
userRoot: Import complete.  Processed 16676 entries in 87 seconds. (191.68 
entries/sec)[28/Oct/2017:10:53:15.252306744 +] ipa-topology-plugin - 
ipa_topo_be_state_change - backend userRoot is coming online; checking domain 
level and init shared topology[28/Oct/2017:10:53:15.256378790 +] 
NSMMReplicationPlugin - multimaster_be_state_change: replica 
dc=domain,dc=company is coming online; enabling 
replication[28/Oct/2017:10:53:15.267602128 +] NSMMReplicationPlugin - 
replica_reload_ruv: Warning: new data for replica dc=domain,dc=company does not 
match the data in the changelog.[28/Oct/2017:10:53:15.284118756 +] 
NSMMReplicationPlugin - changelog program - _cl5NewDBFile: PR_DeleteSemaphore: 
/var/lib/dirsrv/slapd-domain-company/cldb/c96bdb0c-7d1a11e7-9c2f9351-ba1966ca.sema;
 NSPR error - -5943[28/Oct/2017:11:08:04.961514521 +] slapd shutting down - 
signaling operation threads - op stack size 81 max work q size 52 max work q 
stack size 52[28/Oct/2017:11:08:04.962208885 +] slapd shutting down - 
waiting for 24 threads to terminate[28/Oct/2017:11:09:42.503084236 +] SSL 
alert: Sending pin request to SVRCore. You may need to run 
systemd-tty-ask-password-agent to provide the 
password.[28/Oct/2017:11:09:42.504400971 +] SSL alert: Security 
Initialization: Enabling default cipher set.[28/Oct/2017:11:09:42.504747723 
+] SSL alert: Configured NSS Ciphers[28/Oct/2017:11:09:42.504975400 +] 
SSL alert:   TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: 
enabled[28/Oct/2017:11:09:42.505157282 +] SSL alert:   
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled[28/Oct/2017:11:09:42.505371032 
+] SSL alert:   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: 
enabled[28/Oct/2017:11:09:42.505521550 +] SSL alert:   
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled[28/Oct/2017:11:09:42.505686484 
+] SSL alert:   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: 
enabled[28/Oct/2017:11:09:42.505907355 +] SSL alert:   
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled[28/Oct/2017:11:09:42.506066798 
+] SSL alert:   

[Freeipa-users] Re: Swiching which FreeIPA server is the main CA

2017-10-30 Thread Kristian Petersen via FreeIPA-users 
OK I think  I got the ldapmodify to work.  I reran the commands to check
the two certs and they appear to match now.  However, when I run an ipactl
restart the system still fails on pki-tomcatd.

On Mon, Oct 30, 2017 at 3:42 AM, Florence Blanc-Renaud 
wrote:

> On 10/28/2017 01:15 AM, Kristian Petersen via FreeIPA-users wrote:
>
>> I forgot to include the results of the commands in case it is helpful:
>>
>> -bash-4.2$ ldapsearch -LLL -D 'cn=directory manager' -W -b
>> uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso
>> Enter LDAP Password:
>> dn: uid=pkidbuser,ou=people,o=ipaca
>> userCertificate:: MIIDdTCCAl2gAwIBAgIBBDANBgkqhk
>> iG9w0BAQsFADA3MRUwEwYDVQQKDAxD
>> SEVNLkJZVS5FRFUxHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xNTEwMTMyMDUwM
>>
>> jhaFw0xNzEwMDIyMDUwMjhaMC4xFTATBgNVBAoMDENIRU0uQllVLkVEVTEVMBMGA1UEAwwMQ0EgU3
>>
>> Vic3lzdGVtMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtW9NKgtthoustZq+bobtAe+
>>
>> z8z82YinNVC9YzOejrRqRHST4ZiJIq2S6pGPUxbDcpit9eBgyjBT5Ale2B1BSN+SfKcBeK+AMjYF0
>>
>> sBM9Aplx/wBu0IIyA4owqw0QxhtSpvTFEAPZ15JJEb5Rakgl/Gb19+GIzt7FR2t6xtozPFjlzH5HX
>>
>> Npiocdl7RvF6UjktsnE/0N5T/8aBPQbunECePUakskUjr0Cv1HjIKsERXtTn0HAc5ETitHkbCCxn+
>>
>> 8oT082PzDmD1gPgtTI86bsuqcJIHVSqVCk3dIRBL0OLeD3tHkfIp4o+NuoAYaWi/hjpgq0ZXa2zM8
>>
>> zIy33h+A+UQIDAQABo4GUMIGRMB8GA1UdIwQYMBaAFB0PNWo+emloojFyMjHrItpaAfVCMD8GCCsG
>>
>> AQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2lwYTEuY2hlbS5ieXUuZWR1OjgwL2NhL29jc
>>
>> 3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w
>>
>> 0BAQsFAAOCAQEAnsZeWq5e0UWJwaJqTiJdm+1jvQJrzOPWRYPfu9MTpfFjyhlNEwMX0azVzTrFbn2
>>
>> 7+JjQpcxH60zNurhjfavdx3S+/Dmz0dZPgX6AKBeZMfKyyfLeXaoCz3AW9uIbiQZZFdQloGGB82Ek
>>
>> M78W6rJVxb5x9Juck4D4GaeqOuHgNPYVnpNkWR4shCnbGdGjrG4kQRO4I91DxYBrKnY8Fmucxq2y1
>>
>> 4Xi29RT9Plx6p4g4E+LjqdZVAPlK/x3IQDxL2Shp/ycQxGEjfmPX8t3gbyi9e4QvHv5EdmrGpHlIQ
>>
>> bicsPmJ3gmDLn+EcIyoxpT7BLmJKPrn0FjF+FTyE/OrzHBkg==
>> description: 2;4;CN=Certificate Authority,O=CHEM.BYU.EDU <
>> http://CHEM.BYU.EDU>;CN=CA Subsystem,O=CHE
>> M.BYU.EDU 
>> seeAlso: CN=CA Subsystem,O=CHEM.BYU.EDU 
>>
>> -bash-4.2$ sudo certutil -L -d /etc/pki/pki-tomcat/alias -n
>> 'subsystemCert cert-pki-ca' -a
>> -BEGIN CERTIFICATE-
>> MIIDdDCCAlygAwIBAgIBMDANBgkqhkiG9w0BAQsFADA3MRUwEwYDVQQKDAxDSEVN
>> LkJZVS5FRFUxHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xNzA5
>> MDQyMDUwNThaFw0xOTA4MjUyMDUwNThaMC4xFTATBgNVBAoMDENIRU0uQllVLkVE
>> VTEVMBMGA1UEAwwMQ0EgU3Vic3lzdGVtMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
>> MIIBCgKCAQEAtW9NKgtthoustZq+bobtAe+z8z82YinNVC9YzOejrRqRHST4ZiJI
>> q2S6pGPUxbDcpit9eBgyjBT5Ale2B1BSN+SfKcBeK+AMjYF0sBM9Aplx/wBu0IIy
>> A4owqw0QxhtSpvTFEAPZ15JJEb5Rakgl/Gb19+GIzt7FR2t6xtozPFjlzH5HXNpi
>> ocdl7RvF6UjktsnE/0N5T/8aBPQbunECePUakskUjr0Cv1HjIKsERXtTn0HAc5ET
>> itHkbCCxn+8oT082PzDmD1gPgtTI86bsuqcJIHVSqVCk3dIRBL0OLeD3tHkfIp4o
>> +NuoAYaWi/hjpgq0ZXa2zM8zIy33h+A+UQIDAQABo4GTMIGQMB8GA1UdIwQYMBaA
>> FB0PNWo+emloojFyMjHrItpaAfVCMD4GCCsGAQUFBwEBBDIwMDAuBggrBgEFBQcw
>> AYYiaHR0cDovL2lwYS1jYS5jaGVtLmJ5dS5lZHUvY2Evb2NzcDAOBgNVHQ8BAf8E
>> BAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEB
>> CwUAA4IBAQC3eGtIqHewdEtW7EagaUGkc4LoCulmhhmTC7lxOYYT+ADBrve6RSOA
>> UpXSNCoetQU0QmXQkEXDtaZpjYFV2DaniwoAB6HuyG7do/BYdJoX8vKP/vCoJJCJ
>> V64BuCE/uipYclGXbKZPkElbfASIAiNa6X+pSvhIqdTHS0dE7DpHK+m7sIlb1AO0
>> yVmCZBIh1OT/sKajOaLA7epksAA1c9M0BSkdgjrIxAKaeHTtadnLPDEGVQor357Z
>> yPyQ+vSM6GNI/Z02z+paX7WxuI/uZRHzD2MoprmUCfv03isv66EUu0EVox3wSEBT
>> zXGp0EVo/JHfrENJKzszJ4qWGhXJfyII
>> -END CERTIFICATE-
>> -bash-4.2$
>>
>>
>> Hi,
>
> so it looks like the certificate 'subsystemCert cert-pki-ca' has been
> renewed, stored in /etc/pki/pki-tomcat/alias but not copied into the LDAP
> server.
>
> The most recent version is the one in /etc/pki/pki-tomcat/alias (we can
> see that by comparing the serial numbers) and needs to be put into the LDAP
> entry. You can perform this using ldapmodify tool or a graphical LDAP
> browser.
>
> With ldapmodify:
> 1/ extract the certificate from /etc/pki/pki-tomcat/alias into a single
> line, without the -BEGIN CERTIFICATE and -END CERTIFICATE-
> delimiters:
> $ sudo certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
> cert-pki-ca' -a | tail -n +2 | head -n -1 | tr -d '\r\n'
> MIIDdDCC...WGhXJfyII
>
> (tail -n +2 removes the -BEGIN CERTIFICATE- and head -n -1 removes
> the -END CERTIFICATE-, while tr -d '\r\n' deletes new line and
> return characters).
>
> 2/ Find the certificate serial number
> sudo certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
> cert-pki-ca' | grep Serial
> Serial Number: 48 (0x30)
>
> 2/ perform ldapmodify with the value obtained above:
> ldapmodify -x -D 'cn=directory manager' -W
> dn: uid=pkidbuser,ou=people,o=ipaca
> changetype: modify
> replace: usercertificate
> usercertificate:: 
> -
> replace: description
> description: 2;48;CN=Certificate Authority,O=CHEM.BYU.EDU,;CN=CA
> Subsystem,O=CHEM.BYU.EDU

[Freeipa-users] Re: Can't create new CA replica

2017-10-30 Thread john.bowman--- via FreeIPA-users 
I've finally had a chance to make this attempt and after running the clean up:

# python /usr/share/pki/scripts/restore-subsystem-user.py -v
Subsystem certificate: 2;4;CN=Certificate Authority,O=DOMAIN.TLD;CN=CA 
Subsystem,O=DOMAIN.TLD
-BEGIN CERTIFICATE-
*snip*
-END CERTIFICATE-
User CA-ipa4.domain.tld-9443 has subsystem certificate
User already in Subsystem Group
User has the correct certificate mapping
Subsystem user CA-ipa4.domain.tld-9443 is OK

It was strange that it listed ipa4 since that is not one of our current CAs 
just a normal replica.  I'm guessing that it was likely a CA at one point but 
was converted.  Perhaps incorrectly?

# ipa-replica-prepare ipa5.domain.tld
Directory Manager (existing master) password:

Preparing replica for ipa5.domain.tld from ipa1.domain.tld
Creating SSL certificate for the Directory Server
ipa : ERRORcert validation failed for 
"CN=ipa1.domain.tld,O=DOMAIN.TLD" ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's 
Certificate has expired.)
preparation of replica failed: cannot connect to 
'https://ipa1.domain.tld:9444/ca/ee/ca/profileSubmitSSLClient': 
(SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.
cannot connect to 
'https://ipa1.domain.tld:9444/ca/ee/ca/profileSubmitSSLClient': 
(SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.
  File "/usr/sbin/ipa-replica-prepare", line 529, in 
main()

  File "/usr/sbin/ipa-replica-prepare", line 400, in main
export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert", 
replica_fqdn, subject_base)

  File "/usr/sbin/ipa-replica-prepare", line 151, in export_certdb

I know the cert wasn't expired prior to running these two commands.   When I 
look at ipa-getcert list all the expiry dates for requests in MONITORING status 
show 2019 unless I'm looking in the wrong area.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Swiching which FreeIPA server is the main CA

2017-10-30 Thread Florence Blanc-Renaud via FreeIPA-users 

On 10/28/2017 01:15 AM, Kristian Petersen via FreeIPA-users wrote:

I forgot to include the results of the commands in case it is helpful:

-bash-4.2$ ldapsearch -LLL -D 'cn=directory manager' -W -b 
uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso

Enter LDAP Password:
dn: uid=pkidbuser,ou=people,o=ipaca
userCertificate:: 
MIIDdTCCAl2gAwIBAgIBBDANBgkqhkiG9w0BAQsFADA3MRUwEwYDVQQKDAxD
SEVNLkJZVS5FRFUxHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xNTEwMTMyMDUwM 

jhaFw0xNzEwMDIyMDUwMjhaMC4xFTATBgNVBAoMDENIRU0uQllVLkVEVTEVMBMGA1UEAwwMQ0EgU3 

Vic3lzdGVtMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtW9NKgtthoustZq+bobtAe+ 

z8z82YinNVC9YzOejrRqRHST4ZiJIq2S6pGPUxbDcpit9eBgyjBT5Ale2B1BSN+SfKcBeK+AMjYF0 

sBM9Aplx/wBu0IIyA4owqw0QxhtSpvTFEAPZ15JJEb5Rakgl/Gb19+GIzt7FR2t6xtozPFjlzH5HX 

Npiocdl7RvF6UjktsnE/0N5T/8aBPQbunECePUakskUjr0Cv1HjIKsERXtTn0HAc5ETitHkbCCxn+ 

8oT082PzDmD1gPgtTI86bsuqcJIHVSqVCk3dIRBL0OLeD3tHkfIp4o+NuoAYaWi/hjpgq0ZXa2zM8 

zIy33h+A+UQIDAQABo4GUMIGRMB8GA1UdIwQYMBaAFB0PNWo+emloojFyMjHrItpaAfVCMD8GCCsG 

AQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2lwYTEuY2hlbS5ieXUuZWR1OjgwL2NhL29jc 

3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w 

0BAQsFAAOCAQEAnsZeWq5e0UWJwaJqTiJdm+1jvQJrzOPWRYPfu9MTpfFjyhlNEwMX0azVzTrFbn2 

7+JjQpcxH60zNurhjfavdx3S+/Dmz0dZPgX6AKBeZMfKyyfLeXaoCz3AW9uIbiQZZFdQloGGB82Ek 

M78W6rJVxb5x9Juck4D4GaeqOuHgNPYVnpNkWR4shCnbGdGjrG4kQRO4I91DxYBrKnY8Fmucxq2y1 

4Xi29RT9Plx6p4g4E+LjqdZVAPlK/x3IQDxL2Shp/ycQxGEjfmPX8t3gbyi9e4QvHv5EdmrGpHlIQ 


bicsPmJ3gmDLn+EcIyoxpT7BLmJKPrn0FjF+FTyE/OrzHBkg==
description: 2;4;CN=Certificate Authority,O=CHEM.BYU.EDU 
;CN=CA Subsystem,O=CHE

M.BYU.EDU 
seeAlso: CN=CA Subsystem,O=CHEM.BYU.EDU 

-bash-4.2$ sudo certutil -L -d /etc/pki/pki-tomcat/alias -n 
'subsystemCert cert-pki-ca' -a

-BEGIN CERTIFICATE-
MIIDdDCCAlygAwIBAgIBMDANBgkqhkiG9w0BAQsFADA3MRUwEwYDVQQKDAxDSEVN
LkJZVS5FRFUxHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xNzA5
MDQyMDUwNThaFw0xOTA4MjUyMDUwNThaMC4xFTATBgNVBAoMDENIRU0uQllVLkVE
VTEVMBMGA1UEAwwMQ0EgU3Vic3lzdGVtMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAtW9NKgtthoustZq+bobtAe+z8z82YinNVC9YzOejrRqRHST4ZiJI
q2S6pGPUxbDcpit9eBgyjBT5Ale2B1BSN+SfKcBeK+AMjYF0sBM9Aplx/wBu0IIy
A4owqw0QxhtSpvTFEAPZ15JJEb5Rakgl/Gb19+GIzt7FR2t6xtozPFjlzH5HXNpi
ocdl7RvF6UjktsnE/0N5T/8aBPQbunECePUakskUjr0Cv1HjIKsERXtTn0HAc5ET
itHkbCCxn+8oT082PzDmD1gPgtTI86bsuqcJIHVSqVCk3dIRBL0OLeD3tHkfIp4o
+NuoAYaWi/hjpgq0ZXa2zM8zIy33h+A+UQIDAQABo4GTMIGQMB8GA1UdIwQYMBaA
FB0PNWo+emloojFyMjHrItpaAfVCMD4GCCsGAQUFBwEBBDIwMDAuBggrBgEFBQcw
AYYiaHR0cDovL2lwYS1jYS5jaGVtLmJ5dS5lZHUvY2Evb2NzcDAOBgNVHQ8BAf8E
BAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEB
CwUAA4IBAQC3eGtIqHewdEtW7EagaUGkc4LoCulmhhmTC7lxOYYT+ADBrve6RSOA
UpXSNCoetQU0QmXQkEXDtaZpjYFV2DaniwoAB6HuyG7do/BYdJoX8vKP/vCoJJCJ
V64BuCE/uipYclGXbKZPkElbfASIAiNa6X+pSvhIqdTHS0dE7DpHK+m7sIlb1AO0
yVmCZBIh1OT/sKajOaLA7epksAA1c9M0BSkdgjrIxAKaeHTtadnLPDEGVQor357Z
yPyQ+vSM6GNI/Z02z+paX7WxuI/uZRHzD2MoprmUCfv03isv66EUu0EVox3wSEBT
zXGp0EVo/JHfrENJKzszJ4qWGhXJfyII
-END CERTIFICATE-
-bash-4.2$



Hi,

so it looks like the certificate 'subsystemCert cert-pki-ca' has been 
renewed, stored in /etc/pki/pki-tomcat/alias but not copied into the 
LDAP server.


The most recent version is the one in /etc/pki/pki-tomcat/alias (we can 
see that by comparing the serial numbers) and needs to be put into the 
LDAP entry. You can perform this using ldapmodify tool or a graphical 
LDAP browser.


With ldapmodify:
1/ extract the certificate from /etc/pki/pki-tomcat/alias into a single 
line, without the -BEGIN CERTIFICATE and -END 
CERTIFICATE- delimiters:
$ sudo certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert 
cert-pki-ca' -a | tail -n +2 | head -n -1 | tr -d '\r\n'

MIIDdDCC...WGhXJfyII

(tail -n +2 removes the -BEGIN CERTIFICATE- and head -n -1 
removes the -END CERTIFICATE-, while tr -d '\r\n' deletes new 
line and return characters).


2/ Find the certificate serial number
sudo certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert 
cert-pki-ca' | grep Serial

Serial Number: 48 (0x30)

2/ perform ldapmodify with the value obtained above:
ldapmodify -x -D 'cn=directory manager' -W
dn: uid=pkidbuser,ou=people,o=ipaca
changetype: modify
replace: usercertificate
usercertificate:: 
-
replace: description
description: 2;48;CN=Certificate Authority,O=CHEM.BYU.EDU,;CN=CA 
Subsystem,O=CHEM.BYU.EDU


(do not forget to type return twice to send the modify command).
In my example, the description field contains "48" as it is the serial 
number of the new subsystemCert cert-pki-ca obtained in the step 2.


After that, you should be able to restart pki-tomcatd. Please tell me if 
you still encounter issues,


Flo.

On Fri, Oct 27, 2017 at 5:08 PM, Kristian Petersen 
> wrote:


I also found that the certs don't match!  LDAP and certutil

[Freeipa-users] Re: Where is the replication configuration hiding?

2017-10-30 Thread Ludwig Krispenz via FreeIPA-users 


On 10/30/2017 03:56 AM, Sergei Gerasenko via FreeIPA-users wrote:

Hi,

When searching for RUVs, agreements, etc, the following ldapsearch 
command can be used:


ldapsearch -xLLL -h HOST -D "cn=directory manager" -W -b cn=config 
cn=replica nsds50ruv -o ldif-wrap=no


That seems to work. The reported dn is 
"cn=replica,cn=dc\3DMY_DOMAIN\2Cdc\3DCOM,cn=mapping tree,cn=config"


However, when I connect to the ldap server using a graphical LDAP 
browser (JXplorer), I can't find any of that information. I.e., I 
can't find the cn=replica, cn=mapping tree or cn=config.


How can see that information using a graphical browser?
cn=config is a special suffix, so it is probably somerthing to configure 
in your browser


Thanks!
  Sergei


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


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

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