Re: [Freeipa-users] mastercrl.bin very old
Natxo Asenjo wrote: > hi, > > I have been really busy, apologies for the delay in answering. > > On Wed, Oct 22, 2014 at 5:39 PM, Rob Crittenden wrote: >> Natxo Asenjo wrote: >>> On Mon, Oct 13, 2014 at 9:39 PM, Natxo Asenjo >>> wrote: But if I get it from the crl generator using /ipa/crl/MasterCRL.bin I still get the old crl dated june 28th last year. Should I modify ipa-pki-proxy.conf as well on the CRL generator host to point to the /ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL as well? >>> >>> This morning the /ipa/crl dir still had the lists of 28th June 2013 in >>> the crl generator host. In my test environment running centos 7 the >>> files get updated, so I think a process is nut running. But which one? >>> >>> Going to the /ca/ee/ca/getCRL?op=getCRL& >>> crlIssuingPoint=MasterCRL gives me the up to date CRL. >>> >>> -- >>> Groeten, >>> natxo >>> >> >> To enable CRL generation you need these set: >> >> ca.crl.MasterCRL.enableCRLCache=false >> ca.crl.MasterCRL.enableCRLUpdates=false > > ok, this is in the host holding the CRL, right? (in my case kdc01, the > first one). I followed the guide in > http://www.freeipa.org/page/CVE-2012-4546 where in point 2a of manual > instructions you can read true. I have changed that now. to false and > restarted the pki-cad daemon. ok > >> Given that the CA seems to be generating a new CRL that you can fetch >> directly I'll assume those are set. > >> The CA also needs configuration on how/where to publish a file-based >> CRL. The configuration should look like: >> >> ca.publish.publisher.instance.FileBaseCRLPublisher.crlLinkExt=bin >> ca.publish.publisher.instance.FileBaseCRLPublisher.directory=/var/lib/ipa/pki-ca/publish >> ca.publish.publisher.instance.FileBaseCRLPublisher.latestCrlLink=true >> ca.publish.publisher.instance.FileBaseCRLPublisher.pluginName=FileBasedPublisher >> ca.publish.publisher.instance.FileBaseCRLPublisher.timeStamp=LocalTime >> ca.publish.publisher.instance.FileBaseCRLPublisher.zipCRLs=false >> ca.publish.publisher.instance.FileBaseCRLPublisher.zipLevel=9 >> ca.publish.publisher.instance.FileBaseCRLPublisher.Filename.b64=false >> ca.publish.publisher.instance.FileBaseCRLPublisher.Filename.der=true >> ca.publish.rule.instance.FileCrlRule.publisher=FileBaseCRLPublisher > > These values are correct. > > How often does the crl list get generated? i still do not see recent data. This is controlled by ca.crl.MasterCRL.autoUpdateInterval which by default is 240, so every 4 hours. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Password Change from Gnome Desktop
On Sun, 02 Nov 2014 11:33:42 -0600 Dean Hunter wrote: > Am I blind? When I try to change my own password as an IPA user from > the Users applet Gnome desktop (3.12.2-1.fc20), changes are not > allowed to the password. I can change the language, but not the > password. Sounds like a bug in Gnome Accounts stuff, can you change your password in a terminal using "passwd" ? 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] Multiple organizations on one server
Alexander Bokovoy said the following, on 03-11-14, 7:37: On Mon, 03 Nov 2014, Roman Naumenko wrote: Roman Naumenko said the following, on 02-11-14, 22:20: Hi, Similar question was asked already, " Limiting group/user visibility" at https://www.redhat.com/archives/freeipa-users/2011-November/msg00277.html but other than this I couldn't find any clues if that's possible. If I was to manage separate organizations with own users, computers and other entries in one ipa server - would such scenario be possible? I found relevant information, at least about directory structure, in red hat directory server docs: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Configuring_Directory_Databases.html#Configuring_Directory_Databases-Creating_and_Maintaining_Suffixes Since RH package is based on 389 directory server, which is part of freeipa - I wonder if its possible to maintain independent root suffixes? While 389-ds does support multiple root suffixes, FreeIPA management tools, Kerberos DAL driver, access control setup and other components do not support multi-tenancy. Thank you for clarification. --Roman -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Multiple organizations on one server
On Mon, 03 Nov 2014, Roman Naumenko wrote: Roman Naumenko said the following, on 02-11-14, 22:20: Hi, Similar question was asked already, " Limiting group/user visibility" at https://www.redhat.com/archives/freeipa-users/2011-November/msg00277.html but other than this I couldn't find any clues if that's possible. If I was to manage separate organizations with own users, computers and other entries in one ipa server - would such scenario be possible? I found relevant information, at least about directory structure, in red hat directory server docs: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Configuring_Directory_Databases.html#Configuring_Directory_Databases-Creating_and_Maintaining_Suffixes Since RH package is based on 389 directory server, which is part of freeipa - I wonder if its possible to maintain independent root suffixes? While 389-ds does support multiple root suffixes, FreeIPA management tools, Kerberos DAL driver, access control setup and other components do not support multi-tenancy. -- / 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
Re: [Freeipa-users] Multiple organizations on one server
Roman Naumenko said the following, on 02-11-14, 22:20: Hi, Similar question was asked already, " Limiting group/user visibility" at https://www.redhat.com/archives/freeipa-users/2011-November/msg00277.html but other than this I couldn't find any clues if that's possible. If I was to manage separate organizations with own users, computers and other entries in one ipa server - would such scenario be possible? I found relevant information, at least about directory structure, in red hat directory server docs: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Configuring_Directory_Databases.html#Configuring_Directory_Databases-Creating_and_Maintaining_Suffixes Since RH package is based on 389 directory server, which is part of freeipa - I wonder if its possible to maintain independent root suffixes? --Roman -- 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] mastercrl.bin very old
hi, I have been really busy, apologies for the delay in answering. On Wed, Oct 22, 2014 at 5:39 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: >> On Mon, Oct 13, 2014 at 9:39 PM, Natxo Asenjo wrote: >>> But if I get it from the crl generator using /ipa/crl/MasterCRL.bin I >>> still get the old crl dated june 28th last year. >>> >>> Should I modify ipa-pki-proxy.conf as well on the CRL generator host >>> to point to the /ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>> as well? >> >> This morning the /ipa/crl dir still had the lists of 28th June 2013 in >> the crl generator host. In my test environment running centos 7 the >> files get updated, so I think a process is nut running. But which one? >> >> Going to the /ca/ee/ca/getCRL?op=getCRL& >> crlIssuingPoint=MasterCRL gives me the up to date CRL. >> >> -- >> Groeten, >> natxo >> > > To enable CRL generation you need these set: > > ca.crl.MasterCRL.enableCRLCache=false > ca.crl.MasterCRL.enableCRLUpdates=false ok, this is in the host holding the CRL, right? (in my case kdc01, the first one). I followed the guide in http://www.freeipa.org/page/CVE-2012-4546 where in point 2a of manual instructions you can read true. I have changed that now. to false and restarted the pki-cad daemon. > Given that the CA seems to be generating a new CRL that you can fetch > directly I'll assume those are set. > The CA also needs configuration on how/where to publish a file-based > CRL. The configuration should look like: > > ca.publish.publisher.instance.FileBaseCRLPublisher.crlLinkExt=bin > ca.publish.publisher.instance.FileBaseCRLPublisher.directory=/var/lib/ipa/pki-ca/publish > ca.publish.publisher.instance.FileBaseCRLPublisher.latestCrlLink=true > ca.publish.publisher.instance.FileBaseCRLPublisher.pluginName=FileBasedPublisher > ca.publish.publisher.instance.FileBaseCRLPublisher.timeStamp=LocalTime > ca.publish.publisher.instance.FileBaseCRLPublisher.zipCRLs=false > ca.publish.publisher.instance.FileBaseCRLPublisher.zipLevel=9 > ca.publish.publisher.instance.FileBaseCRLPublisher.Filename.b64=false > ca.publish.publisher.instance.FileBaseCRLPublisher.Filename.der=true > ca.publish.rule.instance.FileCrlRule.publisher=FileBaseCRLPublisher These values are correct. How often does the crl list get generated? i still do not see recent data. Thanks! -- Groeten, natxo -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Third party SSL certificate renewal
Hi Dragan, first of all sorry for the delay, I was on leave last week. Dne 24.10.2014 v 20:31 Dragan Prostran napsal(a): Hi Jan, I'm grateful for your help. I've researched how to follow your recommendations above, but I'm not having a lot of luck. According to old posts in this mailing list, https://www.redhat.com/archives/freeipa-users/2013-May/msg00199.html, the command ipa-server-certinstall is the way to go. That said, I found an issue you've filed to allow for this, and it was implemented in FreeIPA 3.3: https://fedorahosted.org/freeipa/ticket/3641 Unfortunately, this system is running FreeIPA 3.0: # rpm -qa | grep -P "ipa[_-]" ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-client-3.0.0-26.el6_4.4.x86_64 ipa-admintools-3.0.0-26.el6_4.4.x86_64 libipa_hbac-1.9.2-82.10.el6_4.x86_64 libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 ipa-python-3.0.0-26.el6_4.4.x86_64 ipa-server-3.0.0-26.el6_4.4.x86_64 # I've found these instructions: http://www.freeipa.org/page/Howto/CA_Certificate_Renewal. I've read those instructions, and I believe I may have a misconception about this process. The procedure calls to: # cp /root/ipa.crt /usr/share/ipa/html/ca.crt # cp /root/ipa.crt /etc/ipa/ca.crt Can you clear up what /root/ipa.crt ought to contain? I assume it ought to contain *only* the root CA certificate which is the *first* key in the bundle provided by the 3rd party Certificate Authority. Is that correct? The instructions you have found do not apply entirely in your situation. The file /etc/ipa/ca.crt should contain only the *leaf* CA cert, i.e. the one with subject name equal to issuer name in your LDAP/HTTP server certs. The file /usr/share/ipa/html/ca.crt should contain the whole CA cert chain. The files /etc/ip/ca.crt already exists, but it is a single certificate. The file I have, issued alongside with the certificate by GoDaddy, is a CA bundle. It contains 3 public keys in sequence in a single file. Could you please be more detailed as to how to accomplish this: "you need to import the CA certificate to NSS databases at /etc/dirsrv/slapd-DIRSRV_REDACTED, /etc/httpd/alias and /etc/pki/nssdb, copy it to /etc/ipa/ca.crt and /usr/share/ipa/html/ca.crt and update cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com in LDAP with it." Once you have the correct CA cert in /etc/ipa/ca.crt, you can run the following command to import the cert to each NSS database: # certutil -d -A -n -t C,, -a -i /etc/ipa/ca.crt (use any nickname you like) For the LDAP update, see "Update the CA in LDAP" in the instructions you have found. I certainly hope these are not inappropriate questions: I'd just like to ensure this is done correctly. Thank you. Don't worry, these are very appropriate questions ;-) --- Dragan Prostran On Fri, Oct 24, 2014 at 6:12 AM, Jan Cholasta wrote: Hi, Dne 24.10.2014 v 04:36 Dragan Prostran napsal(a): Hello, This is my first time posting to this list, so if I've made a faux pas or mistake, please do correct me. Can anyone please point me to the correct method to renewing 3rd party SSL certificates used by FreeIPA 3.0? I suspect I've not done this correctly. Here is what has worked correctly so far: 1. FreeIPA is installed and configured to work correctly. It uses 3rd party SSL certificates. I have access to the CSR, the certificate, the private key, and the new CA bundle. 2. I have successfully followed these instructions to update the SSL certificates used by Apache to serve the FreeIPA web interface: http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP. Of note is that there are 2 IPA servers, and the procedure has been followed on both. 3. Upon visiting the FreeIPA web interface, I can see that the certificate is valid, and expires in the future. Login to FreeIPA and modifying (for example) an LDAP password, work correctly. 4. 3rd party services that take advantage of LDAP work correctly. I can login and authenticate via LDAP. Here is what does not work correctly: 1. A distinct, 3rd party webservice that takes advantage of LDAP *via SSL* no longer is able to authenticate. Prior to certificate update mentioned, this did work correctly. I must admit I'm unfamiliar with LDAP (via SSL), and so instead of troubleshooting that service, I had a closer look at the FreeIPA instance. The 3rd party webservice needs to trust the CA certificate of the LDAP server certificate in order for this to work. 2. When connected to the FreeIPA instance, and issuing 'ipa user-status username', the following error is returned: ipa: ERROR: cert validation failed for "CN=CERT_CN_REDACTED,OU=Domain Control Validated" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cert validation failed for "CN=CERT_CN_REDACTED,OU=Domain Control Validated" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the use
