Re: [Freeipa-users] Renewing CA certificate
On 10/14/2013 09:32 PM, Erinn Looney-Triggs wrote: On 10/14/2013 10:26 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: Folks, I wanted to touch base with y'all about how/if work is progressing on the ability to replace the CA certificate. My certificate is a subordinate of an AD CS instance and will be expiring in December, after two years. Some how, some way, without rebuilding I would like to be able to replace this subordinate CA. There is a ticket open for this, last I checked not much was said in the ticket: https://fedorahosted.org/freeipa/ticket/3304 http://www.freeipa.org/page/V3/CA_certificate_renewal There was a discussion of this proposal on freeipa-devel, https://www.redhat.com/archives/freeipa-devel/2013-October/msg00073.html rob Rob, Brilliant, thanks for the pointers to the info and the discussion. -Erinn Erinn, I will be talking to my colleague (Jan Cholasta) and even if the referred feature is not released until December, we will provide you either with a tool to do the renewal, or a manual procedure how to do it if the tool is not ready until that time. So, keep in touch. -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time
On Mon, 14 Oct 2013, janice.psyop wrote: Hi, I've been setting up an IPA server (centos 6.4) with AD trust (2008R2 domain) following the FC18 freeipa guide. AD trusts is different from AD sync agreement. What you describe below is use of passsync/winsync (AD sync), not AD trusts. Just to make sure we are on the same level here. Everything has gone smoothly until I ran the ipa-replica-manage connect command to the AD DC and it seems to be running (no errors on std out and ps says it is still running), but it has been running for six hours! We do have ~2000 user entries, but I didn't think it would take this long to sync up. The command I ran was this (see below) and the screen now just displays repeating Update in progress. I'm very tempted to kill it in case something is going horribly wrong (with the AD user accounts...) /usr/sbin/ipa-replica-manage connect --winsync --passsync=MySecretPass --binddn=CN=myipasyncuser,CN=Users,DC=domain,DC=com --bindpw=MySecretPass --cacert=/etc/openldap/cacerts/DC-CA.cer -v dc.domain.com Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Is there any way to check the progress of this in case it is in fact hung up? The last few entries in the ipa/default.log is from six hours ago: 2013-10-14T21:32:45Z2706MainThread ipa INFOAdded new sync agreement, waiting for it to become ready . . . 2013-10-14T21:32:46Z2706MainThread ipa INFOReplication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update started: start: 0: end: 0 2013-10-14T21:32:46Z2706MainThread ipa INFOAgreement is ready, starting replication . . . Try to change some user data on AD side, it would trigger update of the IPA side. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Subsystem certs not renewed
Il 14/10/2013 17:01, Rob Crittenden ha scritto: Federico Nebiolo wrote: Dear IPA users, My IPA 3.0 installation on CentOS 6.4 (coming from a 2.2 upgrade) suddenly stopped working for the CA part. I'm not sure this is the root of all the issues, but subsystem certificates was expired and not renewed: getcert list gives a similar output for all of them, and I don't know how to proceed. []# getcert list -c dogtag-ipa-renew-agent Request ID '20130902075915': status: MONITORING ca-error: No end-entity URL (-E) given, and no default known. stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O= subject: CN=RA Subsystem,O= expires: 2013-10-11 07:44:12 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Do you have any hints on how to solve? Try adding a host=fqdn to the [global] section in /etc/ipa/default.conf where host is the fqdn of your IPA master. I think you'll need to temporarily go back in time to the 11th for the renewal to succeed. You can force certmonger to try the renewal again with: # getcert resubmit -i 20130902075915 You'll want to do this for all certs affected by this. If this works please let us know and we'll make sure that host exists in default.conf when upgrades happen. rob Rob, adding host=fqdn and moving the clock backward partially worked. Now both CN=RA Subsystem and CN=fqdn certificates are renewed, but certmonger is unable to renew CN=CA Subsystem, CN=CA Audit and CN=OCSP Subsystem. Certmonger error is an Error 35 connecting to https://fqdn:9443/ca/agent/ca/profileReview: SSL connect error: it seems to me that selfsigned CA certificate in chain is not accepted by certmonger, thus certificates are not renewed. Is there another parameter I can specify to make dogtag-ipa-renew-agent accept its CA? Many thanks again federico ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time
On 10/15/2013 01:22 AM, Alexander Bokovoy wrote: On Mon, 14 Oct 2013, janice.psyop wrote: Hi, I've been setting up an IPA server (centos 6.4) with AD trust (2008R2 domain) following the FC18 freeipa guide. AD trusts is different from AD sync agreement. What you describe below is use of passsync/winsync (AD sync), not AD trusts. Just to make sure we are on the same level here. Everything has gone smoothly until I ran the ipa-replica-manage connect command to the AD DC and it seems to be running (no errors on std out and ps says it is still running), but it has been running for six hours! We do have ~2000 user entries, but I didn't think it would take this long to sync up. The command I ran was this (see below) and the screen now just displays repeating Update in progress. I'm very tempted to kill it in case something is going horribly wrong (with the AD user accounts...) /usr/sbin/ipa-replica-manage connect --winsync --passsync=MySecretPass --binddn=CN=myipasyncuser,CN=Users,DC=domain,DC=com --bindpw=MySecretPass --cacert=/etc/openldap/cacerts/DC-CA.cer -v dc.domain.com Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Is there any way to check the progress of this in case it is in fact hung up? The last few entries in the ipa/default.log is from six hours ago: 2013-10-14T21:32:45Z2706MainThread ipa INFO Added new sync agreement, waiting for it to become ready . . . 2013-10-14T21:32:46Z2706MainThread ipa INFO Replication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update started: start: 0: end: 0 2013-10-14T21:32:46Z2706MainThread ipa INFO Agreement is ready, starting replication . . . Try to change some user data on AD side, it would trigger update of the IPA side. Take a look at the 389 errors log - /var/log/dirsrv/slapd-YOUR-DOMAIN/errors - anything in there? If not, then you can turn on replication/sync error logging http://port389.org/wiki/FAQ#Troubleshooting ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time
Thanks for the replies. I checked this morning and it was still hung up on Update in progess so I killed it. @Alexander: Yes, I had already established a trust with our AD DC. I was doing step 9.4.2. Creating Synchronization Agreements (FreeIPA_Guide/managing-sync-agmt.html)I've been following the guide step-by-step. Here is the slapd-REALM/errors log (I truncated most of the repeating missing attribute errors, but the last line is really the last line in the log). I don't see any glaring errors: # cat /var/log/dirsrv/slapd-IPANY/errors 389-Directory/1.2.11.15 B2013.240.174 nymipa.ipany.domain.com:636 (/etc/dirsrv/slapd-IPANY) [14/Oct/2013:17:32:43 -0400] - 389-Directory/1.2.11.15 B2013.240.174 starting up [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ipany [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ipany [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ipany [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [14/Oct/2013:17:32:44 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [14/Oct/2013:17:32:44 -0400] - Listening on All Interfaces port 636 for LDAPS requests [14/Oct/2013:17:32:44 -0400] - Listening on /var/run/slapd-IPANY.socket for LDAPI requests [14/Oct/2013:17:32:45 -0400] - Entry cn=meTodc02.domain.com,cn=replica,cn=dc\3Dipany,cn=mapping tree,cn=config -- attribute nsDS5ReplicatedAttributeListTotal not allowed [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - agmt=cn=meTodc02.domain.com (dc02:389): Replica has no update vector. It has never been initialized. [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - agmt=cn=meTodc02.domain.com (dc02:389): Replica has no update vector. It has never been initialized. [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - agmt=cn=meTodc02.domain.com (dc02:389): Replica has no update vector. It has never been initialized. [14/Oct/2013:17:32:47 -0400] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=meTodc02.domain.com (dc02:389). [14/Oct/2013:17:32:49 -0400] - Entry uid=nfsuser,cn=users,cn=accounts,dc=ipany missing attribute sn required by object class person [14/Oct/2013:17:32:49 -0400] - Entry uid=tapeop,cn=users,cn=accounts,dc=ipany missing attribute sn required by object class person [14/Oct/2013:17:33:14 -0400] - Entry uid=nfsuserevs,cn=users,cn=accounts,dc=ipany missing attribute sn required by object class person [14/Oct/2013:17:33:14 -0400] - Entry uid=nfsuserbk01,cn=users,cn=accounts,dc=ipany missing attribute sn required by object class person Should I go ahead and enable a more verbose log level (8192) and re-run the ipa-replica-manage connect --winsync again? I killed the process this morning so would I need to do any type of clean up before re-running? thanks, -J. On Tue, Oct 15, 2013 at 9:26 AM, Rich Megginson rmegg...@redhat.com wrote: On 10/15/2013 01:22 AM, Alexander Bokovoy wrote: On Mon, 14 Oct 2013, janice.psyop wrote: Hi, I've been setting up an IPA server (centos 6.4) with AD trust (2008R2 domain) following the FC18 freeipa guide. AD trusts is different from AD sync agreement. What you describe below is use of passsync/winsync (AD sync), not AD trusts. Just to make sure we are on the same level here. Everything has gone smoothly until I ran the ipa-replica-manage connect command to the AD DC and it seems to be running (no errors on std out and ps says it is still running), but it has been running for six hours! We do have ~2000 user entries, but I didn't think it would take this long to sync up. The command I ran was this (see below) and the screen now just displays repeating Update in progress. I'm very tempted to kill it in case something is going horribly wrong (with the AD user accounts...) /usr/sbin/ipa-replica-manage connect --winsync --passsync=MySecretPass --binddn=CN=myipasyncuser,CN=Users,DC=domain,DC=com --bindpw=MySecretPass --cacert=/etc/openldap/cacerts/DC-CA.cer -v dc.domain.com Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Is there any way to check the progress of this in case it is in fact hung up? The last few entries in the ipa/default.log is from six hours ago: 2013-10-14T21:32:45Z2706MainThread ipa INFO Added new sync agreement, waiting for it to become ready . . . 2013-10-14T21:32:46Z2706MainThread ipa INFO Replication Update in progress: FALSE: status: 0 Replica acquired successfully:
Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time
On 10/15/2013 09:51 AM, janice.psyop wrote: Thanks for the replies. I checked this morning and it was still hung up on Update in progess so I killed it. @Alexander: Yes, I had already established a trust with our AD DC. I was doing step 9.4.2. Creating Synchronization Agreements (FreeIPA_Guide/managing-sync-agmt.html)I've been following the guide step-by-step. Here is the slapd-REALM/errors log (I truncated most of the repeating missing attribute errors, but the last line is really the last line in the log). I don't see any glaring errors: # cat /var/log/dirsrv/slapd-IPANY/errors 389-Directory/1.2.11.15 B2013.240.174 nymipa.ipany.domain.com:636 (/etc/dirsrv/slapd-IPANY) [14/Oct/2013:17:32:43 -0400] - 389-Directory/1.2.11.15 B2013.240.174 starting up [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ipany [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ipany [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ipany [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [14/Oct/2013:17:32:44 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [14/Oct/2013:17:32:44 -0400] - Listening on All Interfaces port 636 for LDAPS requests [14/Oct/2013:17:32:44 -0400] - Listening on /var/run/slapd-IPANY.socket for LDAPI requests [14/Oct/2013:17:32:45 -0400] - Entry cn=meTodc02.domain.com,cn=replica,cn=dc\3Dipany,cn=mapping tree,cn=config -- attribute nsDS5ReplicatedAttributeListTotal not allowed This is odd. Looks like fractional replication is not supported by winsync, but ipa-replica-manage is trying to use it. But this should not cause any problems. [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - agmt=cn=meTodc02.domain.com (dc02:389): Replica has no update vector. It has never been initialized. [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - agmt=cn=meTodc02.domain.com (dc02:389): Replica has no update vector. It has never been initialized. [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - agmt=cn=meTodc02.domain.com (dc02:389): Replica has no update vector. It has never been initialized. This is normal when you first create the winsync agreement but have not yet initialized it. [14/Oct/2013:17:32:47 -0400] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=meTodc02.domain.com (dc02:389). [14/Oct/2013:17:32:49 -0400] - Entry uid=nfsuser,cn=users,cn=accounts,dc=ipany missing attribute sn required by object class person [14/Oct/2013:17:32:49 -0400] - Entry uid=tapeop,cn=users,cn=accounts,dc=ipany missing attribute sn required by object class person [14/Oct/2013:17:33:14 -0400] - Entry uid=nfsuserevs,cn=users,cn=accounts,dc=ipany missing attribute sn required by object class person [14/Oct/2013:17:33:14 -0400] - Entry uid=nfsuserbk01,cn=users,cn=accounts,dc=ipany missing attribute sn required by object class person Should I go ahead and enable a more verbose log level (8192) and re-run the ipa-replica-manage connect --winsync again? I killed the process this morning so would I need to do any type of clean up before re-running? I'm not sure if this winsync update finished - please turn on the 8192 log level and see what it is doing. If that shows nothing, then try ipa-replica-manage re-initialize It looks like winsync is already connected. thanks, -J. On Tue, Oct 15, 2013 at 9:26 AM, Rich Megginson rmegg...@redhat.com wrote: On 10/15/2013 01:22 AM, Alexander Bokovoy wrote: On Mon, 14 Oct 2013, janice.psyop wrote: Hi, I've been setting up an IPA server (centos 6.4) with AD trust (2008R2 domain) following the FC18 freeipa guide. AD trusts is different from AD sync agreement. What you describe below is use of passsync/winsync (AD sync), not AD trusts. Just to make sure we are on the same level here. Everything has gone smoothly until I ran the ipa-replica-manage connect command to the AD DC and it seems to be running (no errors on std out and ps says it is still running), but it has been running for six hours! We do have ~2000 user entries, but I didn't think it would take this long to sync up. The command I ran was this (see below) and the screen now just displays repeating Update in progress. I'm very tempted to kill it in case something is going horribly wrong (with the AD user accounts...) /usr/sbin/ipa-replica-manage connect --winsync --passsync=MySecretPass --binddn=CN=myipasyncuser,CN=Users,DC=domain,DC=com --bindpw=MySecretPass --cacert=/etc/openldap/cacerts/DC-CA.cer -v dc.domain.com Update in progress Update in progress Update
Re: [Freeipa-users] Subsystem certs not renewed
Federico Nebiolo wrote: Il 14/10/2013 17:01, Rob Crittenden ha scritto: Federico Nebiolo wrote: Dear IPA users, My IPA 3.0 installation on CentOS 6.4 (coming from a 2.2 upgrade) suddenly stopped working for the CA part. I'm not sure this is the root of all the issues, but subsystem certificates was expired and not renewed: getcert list gives a similar output for all of them, and I don't know how to proceed. []# getcert list -c dogtag-ipa-renew-agent Request ID '20130902075915': status: MONITORING ca-error: No end-entity URL (-E) given, and no default known. stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O= subject: CN=RA Subsystem,O= expires: 2013-10-11 07:44:12 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Do you have any hints on how to solve? Try adding a host=fqdn to the [global] section in /etc/ipa/default.conf where host is the fqdn of your IPA master. I think you'll need to temporarily go back in time to the 11th for the renewal to succeed. You can force certmonger to try the renewal again with: # getcert resubmit -i 20130902075915 You'll want to do this for all certs affected by this. If this works please let us know and we'll make sure that host exists in default.conf when upgrades happen. rob Rob, adding host=fqdn and moving the clock backward partially worked. Now both CN=RA Subsystem and CN=fqdn certificates are renewed, but certmonger is unable to renew CN=CA Subsystem, CN=CA Audit and CN=OCSP Subsystem. Certmonger error is an Error 35 connecting to https://fqdn:9443/ca/agent/ca/profileReview: SSL connect error: it seems to me that selfsigned CA certificate in chain is not accepted by certmonger, thus certificates are not renewed. Is there another parameter I can specify to make dogtag-ipa-renew-agent accept its CA? I'm not sure why it wouldn't accept the connection. Could it be that you didn't set time back far enough? I think you can simulate things with something like: # echo /tmp/pw # sslget -v -d /etc/pki/nssdb/ -w /tmp/pw -r /ca/ee/ca/getCertChain ipa.example.com:9443 You might try a similar command with curl, you just need to create the sqlite equivalent first: # certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,CT, -a -i /etc/ipa/ca.crt # curl -v https://ipa.example.com:9443/ca/ee/ca/getCertChain Hopefully you'll get a more specific error message out of one of those. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time
Found out that ns-slapd was not running/was dead (No such process not running, but pid file exists) -- discovered that when I tried to do the ldapmodify and got the ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) error. Anyway, I started dirsrv and did the ldapmodify with more verbosity and this is the error log: [15/Oct/2013:14:04:12 -0400] - 389-Directory/1.2.11.15 B2013.240.174 starting up [15/Oct/2013:14:04:12 -0400] - WARNING: userRoot: entry cache size 10485760B is less than db size 10706944B; We recommend to increase the entry cache size nsslapd-cachememsize. [15/Oct/2013:14:04:12 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [15/Oct/2013:14:04:12 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ipany [15/Oct/2013:14:04:13 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ipany [15/Oct/2013:14:04:13 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ipany [15/Oct/2013:14:04:13 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [15/Oct/2013:14:04:14 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [15/Oct/2013:14:04:14 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [15/Oct/2013:14:04:14 -0400] - Listening on All Interfaces port 636 for LDAPS requests [15/Oct/2013:14:04:14 -0400] - Listening on /var/run/slapd-IPAPSYOP.socket for LDAPI requests [15/Oct/2013:14:04:14 -0400] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=meTodc02.domain.com (dc02:389). [15/Oct/2013:14:04:30 -0400] - Entry uid=nfsusercrenshaw,cn=users,cn=accounts,dc=ipany missing attribute sn required by object class person [snip] this is a tail of the slapd-IPNY/access log: [15/Oct/2013:14:24:08 -0400] conn=10 op=2 BIND dn= method=sasl version=3 mech=GSSAPI [15/Oct/2013:14:24:08 -0400] conn=10 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [15/Oct/2013:14:24:08 -0400] conn=10 op=3 SRCH base= scope=0 filter=(objectClass=*) attrs=supportedControl [15/Oct/2013:14:24:08 -0400] conn=10 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2013:14:24:08 -0400] conn=10 op=4 SRCH base=cn=ad,cn=trusts,dc=ipany scope=2 filter=(objectClass=ipaNTTrustedDomain) attrs=ALL [15/Oct/2013:14:24:08 -0400] conn=10 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2013:14:24:08 -0400] conn=10 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn=krbprincipalname=cifs/nymipa.ipany.domain.com@ipany,cn=services,cn=accounts,dc=ipany How can I tell if the winsync update finished? Is there a query command or other log file? Thanks very much for all the help! -J. On Tue, Oct 15, 2013 at 11:58 AM, Rich Megginson rmegg...@redhat.com wrote: On 10/15/2013 09:51 AM, janice.psyop wrote: Thanks for the replies. I checked this morning and it was still hung up on Update in progess so I killed it. @Alexander: Yes, I had already established a trust with our AD DC. I was doing step 9.4.2. Creating Synchronization Agreements (FreeIPA_Guide/managing-sync-agmt.html)I've been following the guide step-by-step. Here is the slapd-REALM/errors log (I truncated most of the repeating missing attribute errors, but the last line is really the last line in the log). I don't see any glaring errors: # cat /var/log/dirsrv/slapd-IPANY/errors 389-Directory/1.2.11.15 B2013.240.174 nymipa.ipany.domain.com:636 (/etc/dirsrv/slapd-IPANY) [14/Oct/2013:17:32:43 -0400] - 389-Directory/1.2.11.15 B2013.240.174 starting up [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ipany [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ipany [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ipany [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [14/Oct/2013:17:32:44 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [14/Oct/2013:17:32:44 -0400] - Listening on All Interfaces port 636 for LDAPS requests [14/Oct/2013:17:32:44 -0400] - Listening on /var/run/slapd-IPANY.socket for LDAPI requests [14/Oct/2013:17:32:45 -0400] - Entry cn=meTodc02.domain.com,cn=replica,cn=dc\3Dipany,cn=mapping tree,cn=config -- attribute nsDS5ReplicatedAttributeListTotal not allowed This is odd. Looks like fractional replication is not supported by winsync,
Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time
On 10/15/2013 12:32 PM, janice.psyop wrote: Found out that ns-slapd was not running/was dead (No such process not running, but pid file exists) -- discovered that when I tried to do the ldapmodify and got the ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) error. Anyway, I started dirsrv and did the ldapmodify with more verbosity and this is the error log: [15/Oct/2013:14:04:12 -0400] - 389-Directory/1.2.11.15 B2013.240.174 starting up [15/Oct/2013:14:04:12 -0400] - WARNING: userRoot: entry cache size 10485760B is less than db size 10706944B; We recommend to increase the entry cache size nsslapd-cachememsize. [15/Oct/2013:14:04:12 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. Hmm - this usually happens after a crash. Please read http://port389.org/wiki/FAQ#Debugging_Crashes to enable the system to produce core files, and to get a stack trace. [15/Oct/2013:14:04:12 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ipany [15/Oct/2013:14:04:13 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ipany [15/Oct/2013:14:04:13 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ipany [15/Oct/2013:14:04:13 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [15/Oct/2013:14:04:14 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [15/Oct/2013:14:04:14 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [15/Oct/2013:14:04:14 -0400] - Listening on All Interfaces port 636 for LDAPS requests [15/Oct/2013:14:04:14 -0400] - Listening on /var/run/slapd-IPAPSYOP.socket for LDAPI requests [15/Oct/2013:14:04:14 -0400] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=meTodc02.domain.com (dc02:389). [15/Oct/2013:14:04:30 -0400] - Entry uid=nfsusercrenshaw,cn=users,cn=accounts,dc=ipany missing attribute sn required by object class person [snip] this is a tail of the slapd-IPNY/access log: [15/Oct/2013:14:24:08 -0400] conn=10 op=2 BIND dn= method=sasl version=3 mech=GSSAPI [15/Oct/2013:14:24:08 -0400] conn=10 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [15/Oct/2013:14:24:08 -0400] conn=10 op=3 SRCH base= scope=0 filter=(objectClass=*) attrs=supportedControl [15/Oct/2013:14:24:08 -0400] conn=10 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2013:14:24:08 -0400] conn=10 op=4 SRCH base=cn=ad,cn=trusts,dc=ipany scope=2 filter=(objectClass=ipaNTTrustedDomain) attrs=ALL [15/Oct/2013:14:24:08 -0400] conn=10 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2013:14:24:08 -0400] conn=10 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn=krbprincipalname=cifs/nymipa.ipany.domain.com@ipany,cn=services,cn=accounts,dc=ipany How can I tell if the winsync update finished? Is there a query command or other log file? If you use the repl (8192) log level, it should tell you. Thanks very much for all the help! -J. On Tue, Oct 15, 2013 at 11:58 AM, Rich Megginson rmegg...@redhat.com wrote: On 10/15/2013 09:51 AM, janice.psyop wrote: Thanks for the replies. I checked this morning and it was still hung up on Update in progess so I killed it. @Alexander: Yes, I had already established a trust with our AD DC. I was doing step 9.4.2. Creating Synchronization Agreements (FreeIPA_Guide/managing-sync-agmt.html)I've been following the guide step-by-step. Here is the slapd-REALM/errors log (I truncated most of the repeating missing attribute errors, but the last line is really the last line in the log). I don't see any glaring errors: # cat /var/log/dirsrv/slapd-IPANY/errors 389-Directory/1.2.11.15 B2013.240.174 nymipa.ipany.domain.com:636 (/etc/dirsrv/slapd-IPANY) [14/Oct/2013:17:32:43 -0400] - 389-Directory/1.2.11.15 B2013.240.174 starting up [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ipany [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ipany [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ipany [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [14/Oct/2013:17:32:44 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [14/Oct/2013:17:32:44 -0400] - Listening on All Interfaces port 636 for LDAPS requests [14/Oct/2013:17:32:44 -0400] - Listening on /var/run/slapd-IPANY.socket for LDAPI requests
[Freeipa-users] stupid question
Newbie I see a lot about DNS built into freeIPA. Im installing via yum on centos6.4 Do I just ignore the DNS part since we have our own DNS servers? Or does freeIPA still need local DNS entries? Also, im not sure I follow clients I see it explains that you can add clients so services and use IPA.. However, does any client that is supposed to authenticate users to freeIPA, need to be added as a client? Or is there just an ldap.conf file that tells the client to auth a user against the freeIPA server. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] stupid question
Mike Calautti wrote: Newbie I see a lot about DNS built into freeIPA. Im installing via yum on centos6.4 Do I just ignore the DNS part since we have our own DNS servers? Or does freeIPA still need local DNS entries? You don't need to run an IPA-specific DNS server, it just makes certain things somewhat easier. Also, im not sure I follow “clients” I see it explains that you can add clients so services and use IPA.. However, does any client that is supposed to authenticate users to freeIPA, need to be added as a client? A client is any machine you want to use the IPA server for authentication (and authorization). A separate enrollment script is provided, ipa-client-install, that is used to provision and configure the client to work against IPA, by default using sssd. Or is there just an ldap.conf file that tells the client to auth a user against the freeIPA server. You are best off using our install script. You can opt to not use sssd if you really want, or you can configure things manually. We recommend sticking with the defaults, and using sssd. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] stupid question
Yes.. thanks !! I just saw that myself.. So I need to install the ipa-client.x86_64 package on the client I take it.. Thanks for the quick response !!! Mike -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Tuesday, October 15, 2013 3:52 PM To: Mike Calautti; freeipa-users@redhat.com Subject: Re: [Freeipa-users] stupid question Mike Calautti wrote: Newbie I see a lot about DNS built into freeIPA. Im installing via yum on centos6.4 Do I just ignore the DNS part since we have our own DNS servers? Or does freeIPA still need local DNS entries? You don't need to run an IPA-specific DNS server, it just makes certain things somewhat easier. Also, im not sure I follow clients I see it explains that you can add clients so services and use IPA.. However, does any client that is supposed to authenticate users to freeIPA, need to be added as a client? A client is any machine you want to use the IPA server for authentication (and authorization). A separate enrollment script is provided, ipa-client-install, that is used to provision and configure the client to work against IPA, by default using sssd. Or is there just an ldap.conf file that tells the client to auth a user against the freeIPA server. You are best off using our install script. You can opt to not use sssd if you really want, or you can configure things manually. We recommend sticking with the defaults, and using sssd. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time
- Original Message - From: janice.psyop janice.ps...@gmail.com To: freeipa-users@redhat.com Sent: Tuesday, October 15, 2013 6:51:42 PM Subject: Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time Thanks for the replies. I checked this morning and it was still hung up on Update in progess so I killed it. @Alexander: Yes, I had already established a trust with our AD DC. I was doing step 9.4.2. Creating Synchronization Agreements (FreeIPA_Guide/managing-sync-agmt.html)I've been following the guide step-by-step. What I was trying to say is that you have misunderstood instructions and are doing wrong configuration that is not supported and never was meant to exist. AD trusts are configured with 'ipa-adtrust-install' tool and trust is established with 'ipa trust-add' command. We don't replicate any user and group related information from AD to IPA LDAP when using AD trusts. AD replication is a totally separate technique and should not be combined with AD trusts. This combination makes no sense, was not designed to be used together, and is not supported. Therefore, your attempt to add AD replication to already configured AD trusts is wrong. You need to chose what approach to take: either trusts or replication. Dmitri Pal presented AD integration options at DevConf.cz this year. His talk is recorded and available at youtube: http://www.youtube.com/watch?v=cS6EJ1L7fRI and slides are here: http://www.devconf.cz/slides/Linux-AD-Integration-Options.odp I'd recommend to watch this talk as it is most detailed explanation of various options how to integrate POSIX and AD environments. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] stupid question
I installed ipa-client.. I get this now. ipa-client-install Traceback (most recent call last): File /usr/sbin/ipa-client-install, line 2323, in module sys.exit(main()) File /usr/sbin/ipa-client-install, line 2309, in main rval = install(options, env, fstore, statestore) File /usr/sbin/ipa-client-install, line 1684, in install ret = ds.search(domain=options.domain, servers=options.server, hostname=hostname, ca_cert_path=get_cert_path(options.ca_cert_file)) File /usr/lib/python2.6/site-packages/ipaclient/ipadiscovery.py, line 242, in search ldapret = self.ipacheckldap(server, self.realm, ca_cert_path=ca_cert_path) File /usr/lib/python2.6/site-packages/ipaclient/ipadiscovery.py, line 339, in ipacheckldap basedn = get_ipa_basedn(lh) File /usr/lib/python2.6/site-packages/ipapython/ipautil.py, line 817, in get_ipa_basedn contexts = entries[0][1]['namingcontexts'] cat /etc/redhat-release CentOS release 6.4 (Final) Linux freeipatest01.dev.com 3.4.61-9.el6.centos.alt.x86_64 #1 SMP Wed Sep 11 15:34:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Mike Calautti Sent: Tuesday, October 15, 2013 3:54 PM To: Rob Crittenden; freeipa-users@redhat.com Subject: Re: [Freeipa-users] stupid question Yes.. thanks !! I just saw that myself.. So I need to install the ipa-client.x86_64 package on the client I take it.. Thanks for the quick response !!! Mike -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Tuesday, October 15, 2013 3:52 PM To: Mike Calautti; freeipa-users@redhat.com Subject: Re: [Freeipa-users] stupid question Mike Calautti wrote: Newbie I see a lot about DNS built into freeIPA. Im installing via yum on centos6.4 Do I just ignore the DNS part since we have our own DNS servers? Or does freeIPA still need local DNS entries? You don't need to run an IPA-specific DNS server, it just makes certain things somewhat easier. Also, im not sure I follow clients I see it explains that you can add clients so services and use IPA.. However, does any client that is supposed to authenticate users to freeIPA, need to be added as a client? A client is any machine you want to use the IPA server for authentication (and authorization). A separate enrollment script is provided, ipa-client-install, that is used to provision and configure the client to work against IPA, by default using sssd. Or is there just an ldap.conf file that tells the client to auth a user against the freeIPA server. You are best off using our install script. You can opt to not use sssd if you really want, or you can configure things manually. We recommend sticking with the defaults, and using sssd. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] stupid question
Mike Calautti wrote: I installed ipa-client.. I get this now. ipa-client-install Traceback (most recent call last): File /usr/sbin/ipa-client-install, line 2323, in module sys.exit(main()) File /usr/sbin/ipa-client-install, line 2309, in main rval = install(options, env, fstore, statestore) File /usr/sbin/ipa-client-install, line 1684, in install ret = ds.search(domain=options.domain, servers=options.server, hostname=hostname, ca_cert_path=get_cert_path(options.ca_cert_file)) File /usr/lib/python2.6/site-packages/ipaclient/ipadiscovery.py, line 242, in search ldapret = self.ipacheckldap(server, self.realm, ca_cert_path=ca_cert_path) File /usr/lib/python2.6/site-packages/ipaclient/ipadiscovery.py, line 339, in ipacheckldap basedn = get_ipa_basedn(lh) File /usr/lib/python2.6/site-packages/ipapython/ipautil.py, line 817, in get_ipa_basedn contexts = entries[0][1]['namingcontexts'] cat /etc/redhat-release CentOS release 6.4 (Final) Hmm. I'd take a look at /var/log/ipaclient-install.log to see what host it is trying to enroll against. I have the feeling it is finding another host. We fixed a bug post-6.4 related to case insensitivity and namingcontents. I have the feeling the LDAP server you're connecting to isn't return it all as lower case as we expect. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] stupid question
Ok..
So I did ad the kerberos stuff to the DNS server..
Then I got further..
But got this..
2013-10-15T20:31:31Z DEBUG Init LDAP connection with: ldap://rdsdev01:389
2013-10-15T20:31:31Z DEBUG LDAP Error: server down
So then I added the fqdn and shortname to the clients host file..
And get this.,
ipa-client-install --server=rdsdev01 --domain=dev.com
Autodiscovery of servers for failover cannot work with this configuration.
If you proceed with the installation, services will be configured to always
access the discovered server for all operations and will not fail over to other
servers in case of failure.
Proceed with fixed values and no DNS discovery? [no]:
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Mike Calautti
Sent: Tuesday, October 15, 2013 4:25 PM
To: Rob Crittenden; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] stupid question
Your awesome
Interesting..
Well for one its claiming it cant contact the LDAP server...
But its calling a machine in our domain that I didn't know existed and
furthermore never mentioned in the ipa setup..
So I see it was searching the network...
Also..when doing research on installing, I saw that someone said to paste the
entries form the example DNS file to your existing DNS db file.
I didn't do that because I am just testing..
Would that affect it ?
Dns is correct for both IPA master/replica
Here is the log.
cat /var/log/ipaclient-install.log
2013-10-15T20:18:11Z DEBUG /usr/sbin/ipa-client-install was invoked with
options: {'domain': None, 'force': False, 'krb5_offline_passwords': True,
'primary': False, 'mkhomedir': False, 'create_sshfp': True, 'conf_sshd': True,
'on_master': False, 'conf_ntp': True, 'ca_cert_file': None, 'ntp_server': None,
'principal': None, 'hostname': None, 'no_ac': False, 'unattended': None,
'sssd': True, 'trust_sshfp': False, 'dns_updates': False, 'realm_name': None,
'conf_ssh': True, 'server': None, 'prompt_password': False, 'permit': False,
'debug': False, 'preserve_sssd': False, 'uninstall': False}
2013-10-15T20:18:11Z DEBUG missing options might be asked for interactively
later 2013-10-15T20:18:11Z DEBUG Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2013-10-15T20:18:11Z DEBUG Loading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
2013-10-15T20:18:11Z DEBUG [IPA Discovery] 2013-10-15T20:18:11Z DEBUG Starting
IPA discovery with domain=None, servers=None, hostname=freeiptest01.dev.com
2013-10-15T20:18:11Z DEBUG Start searching for LDAP SRV record in dev.com
(domain of the hostname) and its sub-domains 2013-10-15T20:18:11Z DEBUG Search
DNS for SRV record of _ldap._tcp.dev.com.
2013-10-15T20:18:11Z DEBUG No DNS record found 2013-10-15T20:18:11Z DEBUG
Search DNS for SRV record of _ldap._tcp.dev.com.
2013-10-15T20:18:11Z DEBUG DNS record found:
DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:hqdc02.dev.com.}
2013-10-15T20:18:11Z DEBUG DNS record found:
DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:hqdc.dev.com.}
2013-10-15T20:18:11Z DEBUG DNS record found:
DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:drdc01.dev.com.}
2013-10-15T20:18:11Z DEBUG [Kerberos realm search] 2013-10-15T20:18:11Z DEBUG
Search DNS for TXT record of _kerberos.dev.com.
2013-10-15T20:18:11Z DEBUG No DNS record found 2013-10-15T20:18:11Z DEBUG [LDAP
server check] 2013-10-15T20:18:11Z DEBUG Verifying that hqdc02.dev.com (realm
None) is an IPA server 2013-10-15T20:18:11Z DEBUG Init LDAP connection with:
ldap://hqdc02.dev.com:389 2013-10-15T20:18:11Z DEBUG Search LDAP server for IPA
base DN
If I specify --server=rdsdev01 --domain=dev.com
I get
Failed to verify that rdsdev01 is an IPA Server.
This may mean that the remote server is not up or is not reachable due to
network or firewall settings.
Please make sure the following ports are opened in the firewall settings:
TCP: 80, 88, 389
UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that
following ports are necessary for ipa-client working properly after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)
Installation failed. Rolling back changes.
IPA client is not configured on this system.
However there is no FW. Iptables is not running.. and I can telnet to each of
those ports.
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Tuesday, October 15, 2013 4:11 PM
To: Mike Calautti; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] stupid question
Mike Calautti wrote:
I installed ipa-client..
I get this now.
ipa-client-install
Traceback (most recent call last):
File /usr/sbin/ipa-client-install, line 2323, in module
sys.exit(main())
File /usr/sbin/ipa-client-install, line 2309, in main
rval =
Re: [Freeipa-users] stupid question
Mike Calautti wrote:
Ok..
So I did ad the kerberos stuff to the DNS server..
Then I got further..
But got this..
2013-10-15T20:31:31Z DEBUG Init LDAP connection with: ldap://rdsdev01:389
2013-10-15T20:31:31Z DEBUG LDAP Error: server down
You need to use FQDNs for things to work properly.
So then I added the fqdn and shortname to the clients host file..
And get this.,
ipa-client-install --server=rdsdev01 --domain=dev.com
Autodiscovery of servers for failover cannot work with this configuration.
If you proceed with the installation, services will be configured to always
access the discovered server for all operations and will not fail over to other
servers in case of failure.
Proceed with fixed values and no DNS discovery? [no]:
By passing in --server you are overriding discovery so we're warning
that you will have manual changes to make in the future if your network
configuration changes.
rob
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Mike Calautti
Sent: Tuesday, October 15, 2013 4:25 PM
To: Rob Crittenden; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] stupid question
Your awesome
Interesting..
Well for one its claiming it cant contact the LDAP server...
But its calling a machine in our domain that I didn't know existed and
furthermore never mentioned in the ipa setup..
So I see it was searching the network...
Also..when doing research on installing, I saw that someone said to paste the
entries form the example DNS file to your existing DNS db file.
I didn't do that because I am just testing..
Would that affect it ?
Dns is correct for both IPA master/replica
Here is the log.
cat /var/log/ipaclient-install.log
2013-10-15T20:18:11Z DEBUG /usr/sbin/ipa-client-install was invoked with
options: {'domain': None, 'force': False, 'krb5_offline_passwords': True,
'primary': False, 'mkhomedir': False, 'create_sshfp': True, 'conf_sshd': True,
'on_master': False, 'conf_ntp': True, 'ca_cert_file': None, 'ntp_server': None,
'principal': None, 'hostname': None, 'no_ac': False, 'unattended': None,
'sssd': True, 'trust_sshfp': False, 'dns_updates': False, 'realm_name': None,
'conf_ssh': True, 'server': None, 'prompt_password': False, 'permit': False,
'debug': False, 'preserve_sssd': False, 'uninstall': False}
2013-10-15T20:18:11Z DEBUG missing options might be asked for interactively
later 2013-10-15T20:18:11Z DEBUG Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2013-10-15T20:18:11Z DEBUG Loading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
2013-10-15T20:18:11Z DEBUG [IPA Discovery] 2013-10-15T20:18:11Z DEBUG Starting IPA
discovery with domain=None, servers=None, hostname=freeiptest01.dev.com
2013-10-15T20:18:11Z DEBUG Start searching for LDAP SRV record in dev.com
(domain of the hostname) and its sub-domains 2013-10-15T20:18:11Z DEBUG Search DNS for
SRV record of _ldap._tcp.dev.com.
2013-10-15T20:18:11Z DEBUG No DNS record found 2013-10-15T20:18:11Z DEBUG
Search DNS for SRV record of _ldap._tcp.dev.com.
2013-10-15T20:18:11Z DEBUG DNS record found:
DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:hqdc02.dev.com.}
2013-10-15T20:18:11Z DEBUG DNS record found:
DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:hqdc.dev.com.}
2013-10-15T20:18:11Z DEBUG DNS record found:
DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:drdc01.dev.com.}
2013-10-15T20:18:11Z DEBUG [Kerberos realm search] 2013-10-15T20:18:11Z DEBUG
Search DNS for TXT record of _kerberos.dev.com.
2013-10-15T20:18:11Z DEBUG No DNS record found 2013-10-15T20:18:11Z DEBUG [LDAP
server check] 2013-10-15T20:18:11Z DEBUG Verifying that hqdc02.dev.com (realm
None) is an IPA server 2013-10-15T20:18:11Z DEBUG Init LDAP connection with:
ldap://hqdc02.dev.com:389 2013-10-15T20:18:11Z DEBUG Search LDAP server for IPA
base DN
If I specify --server=rdsdev01 --domain=dev.com
I get
Failed to verify that rdsdev01 is an IPA Server.
This may mean that the remote server is not up or is not reachable due to
network or firewall settings.
Please make sure the following ports are opened in the firewall settings:
TCP: 80, 88, 389
UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that
following ports are necessary for ipa-client working properly after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)
Installation failed. Rolling back changes.
IPA client is not configured on this system.
However there is no FW. Iptables is not running.. and I can telnet to each of
those ports.
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Tuesday, October 15, 2013 4:11 PM
To: Mike Calautti; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] stupid question
Mike Calautti wrote:
I
Re: [Freeipa-users] Redhat IPA as a SSL CA
Is it http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP about the same? В Пт, 19/07/2013 в 10:56 +0530, M.R Niranjan пишет: On 07/19/2013 06:57 AM, craig.free...@noboost.org wrote: Hi, I've been using Redhat IPA 2.2 as our internal CA quite successfully for a while and managing in it from the IPA management website. I'm struggling to find precise information about the SSL certs and management at a CLI level. 1) Can I submit SSL CSR via cli? Yes, you could using ipa cert-request command Example: 1. Add the host for which you are generating request. # ipa host-add webserver1.example.org 2. Create a CSR (i.e private key and certificate request using openssl command) A. Generate private key: [root@test1 certs]# openssl genrsa 1024 server.key B. Generate CSR: [root@test1 certs]# openssl req -new -key server.key -out server.csr 3. Submit the certificate request: # ipa cert-request /etc/pki/tls/certs/server.csr 4. Get the signed Certificate out using ipa cert-show command Example: [root@test1 certs]# ipa cert-show 12 --out=/etc/pki/tls/certs/server.crt 2) Where are the approved client SSL certs kept in IPA? They are stored in Directory Server in 2 places 1. Domain Suffix tree dn:fqdn=webserver1.example.org,cn=computers,cn=accounts,dc=example,dc=org 2. CA store in DS. Certificate system of IPA stores certificate in it's ldap store (ou=certificateRepository,ou=ca,o=ipaca) cya Craig ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
