Re: [Freeipa-users] exporting ldap certificate
On 05/07/2013 04:51 AM, Peter Brown wrote: On 6 May 2013 17:07, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: I am glad you made it working. Just for the record, CRL and OCSP revocation URIs in FreeIPA v3.1 were flawed, there are relevant fixes in FreeIPA 3.2 that will make it working again. Thanks for the heads up Martin. I will likely upgrade to 3.2 once Fedora 19 is released. I am going to assume my 3.1 clients will be compatible? Yes, this is a correct assumption. BTW we are just in a process of testing and releasing FreeIPA 3.1.4 bugfixing release for Fedora 18 which will also contain the CRL/OCSP URI fixes (will happen this week). Any help with testing 3.1.4 when it is released is appreciated. Martin More information can be found out in FreeIPA.org wiki: http://www.freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs Relevant upstream ticket: https://fedorahosted.org/freeipa/ticket/3552 Martin On 04/29/2013 06:59 AM, Peter Brown wrote: I finally got this to work. I managed to get an error message that told me it couldn't check the revocation of the certificates against a crl. I tried to find out how to tell java where to find that crl but I these discovered these options instead to tell java to not check a crl. -Dcom.sun.net.ssl.checkRevocation=false -Dcom.sun.security.enableCRLDP=false On 26 April 2013 18:30, Petr Viktorin pvikt...@redhat.com mailto:pvikt...@redhat.com mailto:pvikt...@redhat.com mailto:pvikt...@redhat.com wrote: Hello, On 04/26/2013 07:22 AM, Peter Brown wrote: Hi everyone. I am attempting to get Google Apps to sync with FreeIPA and I am having problems getting the sync utility to talk to freeipa. It complains about the ssl cert. I have it setup so it only accepts ssl or tls encrypted connections and I don't want to turn that off. I have imported the ca cert using the jre's keytool but it still refuses to connect. I am getting the impression I need to import the ssl cert for the ldap server into it as well. The CA cert (/etc/ipa/ca.crt) should be enough, it signs all the other certs. Make sure you import it with the right trust level (SSL certificate signing). Unfortunately I don't know about jre's keytool so I can't be more specific. I have no idea which certificate that is and I have no idea how to export it. Do not do this. You should only explicitly trust the CA cert. For example, if you trust the certs explicitly you'd have to re-import them one by one when they are renewed. Can someone please tell me how to do this? If you really want to: There are two certs, one for httpd (Web UI, XMLRPC JSON APIs), and one for the LDAP server. To export the httpd server certificate (to PEM): $ certutil -L -d /etc/httpd/alias -n Server-Cert -a To export the directory server certificate (to PEM): $ certutil -L -d /etc/dirsrv/slapd-$INSTANCE___NAME/ -n Server-Cert -a But again, you don't need this for what you're trying to do. -- Petrł ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto: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] exporting ldap certificate
On 7 May 2013 16:50, Martin Kosek mko...@redhat.com wrote: On 05/07/2013 04:51 AM, Peter Brown wrote: On 6 May 2013 17:07, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: I am glad you made it working. Just for the record, CRL and OCSP revocation URIs in FreeIPA v3.1 were flawed, there are relevant fixes in FreeIPA 3.2 that will make it working again. Thanks for the heads up Martin. I will likely upgrade to 3.2 once Fedora 19 is released. I am going to assume my 3.1 clients will be compatible? Yes, this is a correct assumption. BTW we are just in a process of testing and releasing FreeIPA 3.1.4 bugfixing release for Fedora 18 which will also contain the CRL/OCSP URI fixes (will happen this week). Any help with testing 3.1.4 when it is released is appreciated. Awesome. I shall install them and let you know how I go. Martin More information can be found out in FreeIPA.org wiki: http://www.freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs Relevant upstream ticket: https://fedorahosted.org/freeipa/ticket/3552 Martin On 04/29/2013 06:59 AM, Peter Brown wrote: I finally got this to work. I managed to get an error message that told me it couldn't check the revocation of the certificates against a crl. I tried to find out how to tell java where to find that crl but I these discovered these options instead to tell java to not check a crl. -Dcom.sun.net.ssl.checkRevocation=false -Dcom.sun.security.enableCRLDP=false On 26 April 2013 18:30, Petr Viktorin pvikt...@redhat.com mailto:pvikt...@redhat.com mailto:pvikt...@redhat.com mailto:pvikt...@redhat.com wrote: Hello, On 04/26/2013 07:22 AM, Peter Brown wrote: Hi everyone. I am attempting to get Google Apps to sync with FreeIPA and I am having problems getting the sync utility to talk to freeipa. It complains about the ssl cert. I have it setup so it only accepts ssl or tls encrypted connections and I don't want to turn that off. I have imported the ca cert using the jre's keytool but it still refuses to connect. I am getting the impression I need to import the ssl cert for the ldap server into it as well. The CA cert (/etc/ipa/ca.crt) should be enough, it signs all the other certs. Make sure you import it with the right trust level (SSL certificate signing). Unfortunately I don't know about jre's keytool so I can't be more specific. I have no idea which certificate that is and I have no idea how to export it. Do not do this. You should only explicitly trust the CA cert. For example, if you trust the certs explicitly you'd have to re-import them one by one when they are renewed. Can someone please tell me how to do this? If you really want to: There are two certs, one for httpd (Web UI, XMLRPC JSON APIs), and one for the LDAP server. To export the httpd server certificate (to PEM): $ certutil -L -d /etc/httpd/alias -n Server-Cert -a To export the directory server certificate (to PEM): $ certutil -L -d /etc/dirsrv/slapd-$INSTANCE___NAME/ -n Server-Cert -a But again, you don't need this for what you're trying to do. -- Petrł ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto: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] Help troubleshooting migrate-ds
On 03/05/13 12:40, Arturo Borrero wrote: Hi there! In a freshly installed FreeIPA server, I try: # ipa migrate-ds LDAP URI: ldaps://ldap.example.com Contraseña: ipa: ERROR: no es posible conectar con u'ldaps://ldap.example.com': LDAP Server Down This is a related line I found in the logfile: [Fri May 03 12:30:53 2013] [error] ipa: INFO: ad...@example.com: migrate_ds(u'ldaps://ldap.example.com', u'', binddn=u'cn=admin,dc=example,dc=com', usercontainer=u'ou=example,ou=users', groupcontainer=u'ou=example,ou=groups', userobjectclass=(u'person',), groupobjectclass=(u'groupOfUniqueNames', u'groupOfNames'), userignoreobjectclass=None, userignoreattribute=None, groupignoreobjectclass=None, groupignoreattribute=None, groupoverwritegid=False, schema=u'RFC2307bis', continue=False, basedn=u'ou=cuentas,dc=example,dc=com', compat=False, exclude_groups=None, exclude_users=None): NetworkError Am I missing something? There is some prerequisites in the DNS server for this to work? Of course, the IPA server has full network contact with the LDAP server (tcp/636), i see some packets doing a tpcdump in the LDAP server. Is there a way to get a more verbose log output of what is going on? I don't have any clue yet. Google seems empty when I search for this error and this operation made by others seems errorfree. Any idea? -- Arturo Borrero González Departamento de Seguridad Informática (n...@cica.es) Centro Informático Científico de Andalucía (CICA) Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain) Tfno.: +34 955 056 600 / FAX: +34 955 056 650 Consejería de Economía, Innovación, Ciencia y Empleo Junta de Andalucía smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Issue IPA: AD Users and IPA Users when using SSS/LDAP with SUDO
On 05/03/2013 12:42 PM, Aly Khimji wrote: Hey Pavel/guys Any luck recreating the problem? Hi, sorry for the delay. I can confirm that sudo does not work with users from trusted domain anymore. I created a ticket: https://fedorahosted.org/sssd/ticket/1912 Patch for 1.9 branch is on sssd-devel list. Thx for the help Aly Thanks Pavel, Very much appreciated Aly On Tue, Apr 30, 2013 at 1:41 PM, Pavel Brezina pbrez...@redhat.com mailto:pbrez...@redhat.com wrote: - Original Message - From: Pavel Březina pbrez...@redhat.com mailto:pbrez...@redhat.com To: Aly Khimji aly.khi...@gmail.com mailto:aly.khi...@gmail.com Cc: freeipa-users@redhat.com mailto:freeipa-users@redhat.com Sent: Monday, April 29, 2013 9:11:25 PM Subject: Re: [Freeipa-users] Issue IPA: AD Users and IPA Users when using SSS/LDAP with SUDO On 04/29/2013 08:31 PM, Aly Khimji wrote: Hey Pavel/Guys, Do you see anything in the new logs that might help? I saw this bug https://bugzilla.redhat.com/show_bug.cgi?id=871160 that reports this issue exactly. However its reported as fixed but I am still having the same issue. I am building out a new test environment and I am also deploying a FC18 client which seems to have newer sssd/libsss_sudo packages that i suppose haven't made it up stream yet Currently installed on my client libsss_sudo-1.9.2-82.7.el6_4.x86_64 sssd-client-1.9.2-82.7.el6_4.x86_64 libsss_idmap-1.9.2-82.7.el6_4.x86_64 libsss_autofs-1.9.2-82.el6.x86_64 sssd-1.9.2-82.7.el6_4.x86_64 I've increased the logging to 10, just incase it helps. here it the sss_sudo log for a login, then sudo attempt Thx Aly Hi, I'm sorry for such a late answer. The logs says, that in the time of using sudo, the user akhimji is not present in the cache, which should not happen if you managed to log in. I will try to reproduce the issue first thing tomorrow and let you know. Hi, I'm sorry, I had some technical diffucilties and didn't manage to get to it today. Will try it as soon as possible. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Announcing FreeIPA 3.1.4
The FreeIPA team is proud to announce version FreeIPA v3.1.4. It can be downloaded from http://www.freeipa.org/page/Downloads. The new version has also been built for Fedora 18 and is on its way to updates-testing: https://admin.fedoraproject.org/updates/freeipa-3.1.4-1.fc18 == Highlights in 3.1.4 == === New features === * Added support for new Dogtag 10.0.2 * Added support for new OpenSSH 6.2 * Added userClass attribute for hosts entries * Server/replica installation now accepts --mkhomedir option === Bug fixes === * New certificates issued by FreeIPA CA now contain correct OCSP/CRL URIs [1] * /etc/ipa directory ownership was fixed * Deprecated HBAC Source host related options were removed from CLI == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Due to changes related to OCSP/CRL URI fix [1], ipa-ca.DOMAIN DNS name is automatically converted from a set of CNAMEs to a set of A/ records pointing to FreeIPA servers with CA configured. Please note, that the referential integrity extension requires an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of hosts, SUDO or HBAC entries may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users == References == [1] http://freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs == Detailed Changelog since 3.1.3 == Alexander Bokovoy (1): * Enhance ipa-adtrust-install for domains with multiple IPA server Ana Krivokapic (8): * Add mkhomedir option to ipa-server-install and ipa-replica-install * Remove CA cert on client uninstall * Remove HBAC source hosts from web UI * Remove any reference to HBAC source hosts from help * Deprecate HBAC source hosts from CLI * Handle missing /etc/ipa in ipa-client-install * Fix the spec file * Add missing permissions to Host Administrators privilege Jan Cholasta (7): * Do actually stop pki_cad in stop_pkicad instead of starting it. * Use only one URL for OCSP and CRL in IPA certificate profile. * Use A/ records instead of CNAME records in ipa-ca. * Delete DNS records in ipa-ca on ipa-csreplica-manage del. * Do not use new LDAP API in old code. * Use correct zone when removing DNS records of a master. * Add support for OpenSSH 6.2. Martin Kosek (4): * Require 389-base-base 1.3.0.5 * Add userClass attribute for hosts * Update pki proxy configuration * Become IPA 3.1.4 Petr Viktorin (2): * Display full command documentation in online help * Use two digits for each part of NUM_VERSION Rob Crittenden (3): * Handle socket.gethostbyaddr() exceptions when verifying hostnames. * Drop uniqueMember mapping with nss-pam-ldapd. * Specify the location for the agent PKCS#12 file so we don't have to move it. Sumit Bose (1): * ipa-pwd-extop: do not use dn until it is really set Tomas Babej (2): * Properly handle ipa-replica-install when its zone is not managed by IPA * Allow underscore in record targets ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Help troubleshooting migrate-ds
On 05/07/2013 07:53 AM, Arturo Borrero wrote: On 03/05/13 12:40, Arturo Borrero wrote: Hi there! In a freshly installed FreeIPA server, I try: # ipa migrate-ds LDAP URI: ldaps://ldap.example.com Contraseña: ipa: ERROR: no es posible conectar con u'ldaps://ldap.example.com': LDAP Server Down This is a related line I found in the logfile: [Fri May 03 12:30:53 2013] [error] ipa: INFO: ad...@example.com: migrate_ds(u'ldaps://ldap.example.com', u'', binddn=u'cn=admin,dc=example,dc=com', usercontainer=u'ou=example,ou=users', groupcontainer=u'ou=example,ou=groups', userobjectclass=(u'person',), groupobjectclass=(u'groupOfUniqueNames', u'groupOfNames'), userignoreobjectclass=None, userignoreattribute=None, groupignoreobjectclass=None, groupignoreattribute=None, groupoverwritegid=False, schema=u'RFC2307bis', continue=False, basedn=u'ou=cuentas,dc=example,dc=com', compat=False, exclude_groups=None, exclude_users=None): NetworkError Am I missing something? There is some prerequisites in the DNS server for this to work? Of course, the IPA server has full network contact with the LDAP server (tcp/636), i see some packets doing a tpcdump in the LDAP server. Is there a way to get a more verbose log output of what is going on? I don't have any clue yet. Google seems empty when I search for this error and this operation made by others seems errorfree. Any idea? Can it be that the certs are not properly configured? What LDAP server you are trying to use? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] users account functionality
On 05/03/2013 03:24 AM, Juan Armario wrote: Sorry for my english. My doubt is about the user's functions. For example when I want to do the login into the web site and I don't remember the pass. I click in a link, button... and I receive a mail with the instructions for reset the pass, or with a temporary pass that I must change... The others functions are when the user want to create a account, and fill in a form with name, surname... and the admin receive a mail and active the account. The same for delete the account. Exist something already implemented or have I to do it? Is not a problem for me do it, but it's better use something already tested and working. I hope now my doubt is more clear. Sorry for delayed reply. Was away for couple days. Yes. Now it is more clear. Let me summarize: 1) Provide a self service password reset capability. https://fedorahosted.org/freeipa/ticket/3611 2) Provide a self service interface to reset forgotten password using some kind of temporary code. https://fedorahosted.org/freeipa/ticket/3612 3) Provide a self service enrollment capability with admin approval and notification workflow https://fedorahosted.org/freeipa/ticket/3613 4) Provide a self service account decommissioning with admin approval https://fedorahosted.org/freeipa/ticket/3614 None of these are implemented so I opened tickets on your behalf. We would be glad if someone would pick it up however please start with the design proposal and get it acked on the list because this area is very security sensitive and we do not want to jeopardize the security and integrity of the system. thanks. On 02/05/13 15:49, John Dennis wrote: On 05/02/2013 04:42 AM, Juan Armario wrote: Hi, I'm Juan and I'm building a freeipa application and need to know if it possible integrate a module or if is already developed, the typical functionality when we want an authentication service for our users, like remember password, create users, and send an email for confirmation, or send a account delete request. We have installed the basic freeipa and we need to incorporate this functionality. Exist this or have I to implement it? It's a little hard to understand exactly what you're looking to accomplish, for instance what does remember password mean? It doesn't sound like what you're looking for requires adding a plugin module, rather you're looking to add a front-end to IPA which is easy to do with scripts. IPA is quite amenable to scripting because we provide a command line interface. You can either call the ipa command from a shell script or you can write your own Python scripts and invoke the IPA API directly. Be careful though, the type of operations you've described all require administrator privileges, it's not something a general user can do. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Help troubleshooting migrate-ds
Arturo Borrero wrote: On 03/05/13 12:40, Arturo Borrero wrote: Hi there! In a freshly installed FreeIPA server, I try: # ipa migrate-ds LDAP URI: ldaps://ldap.example.com Contraseña: ipa: ERROR: no es posible conectar con u'ldaps://ldap.example.com': LDAP Server Down This is a related line I found in the logfile: [Fri May 03 12:30:53 2013] [error] ipa: INFO: ad...@example.com: migrate_ds(u'ldaps://ldap.example.com', u'', binddn=u'cn=admin,dc=example,dc=com', usercontainer=u'ou=example,ou=users', groupcontainer=u'ou=example,ou=groups', userobjectclass=(u'person',), groupobjectclass=(u'groupOfUniqueNames', u'groupOfNames'), userignoreobjectclass=None, userignoreattribute=None, groupignoreobjectclass=None, groupignoreattribute=None, groupoverwritegid=False, schema=u'RFC2307bis', continue=False, basedn=u'ou=cuentas,dc=example,dc=com', compat=False, exclude_groups=None, exclude_users=None): NetworkError Am I missing something? There is some prerequisites in the DNS server for this to work? Of course, the IPA server has full network contact with the LDAP server (tcp/636), i see some packets doing a tpcdump in the LDAP server. Is there a way to get a more verbose log output of what is going on? I don't have any clue yet. Google seems empty when I search for this error and this operation made by others seems errorfree. Any idea? https://fedorahosted.org/freeipa/ticket/3364 rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ipa-client-install: done remotely, DNS discovery and multiple servers
Hi Since EL 6.4, executing ipa-client-install over SSH i.e. 'ssh client ipa-client-install params', results in an issue with the host certificate. The output returns the following error during the: 'ipa-getcert request -d /etc/pki/nssdb' stage: TLS: could not close certdb slot - error -8018:Unknown PKCS #11 error. TLS: could not shutdown NSS - error -8053:NSS could not shutdown The host certificate remains in state: 'status: NEED_CSR' when checking with ipa-getcert list In EL6.2 and EL6.3 this was not an issue. Perhaps you may reproduce this and advise. In order to work around this, I end up having to run ipa-client-install locally on the client. Also, with 6.4, thanks to the --fixed-primary switch we can now statically set specific IPA servers to use for a given client, instead of rely on DNS (SRV records) discovery. Before this feature we would need to patch the sssd.conf manually and restart SSSD, as ipa-client-install would remain stuck since the given client via SRV discovery would attempt using an IPA server it does not have access to. Now we longer have this issue, however ipa-client-install still picks the NTP server with which it should synchronize time during the enrolment process via DNS discovery. In the past ipa-client-install would 'give up' after 3 attempts or so, but now it keeps attempting until it encounters a reachable IPA NTP server. In an environment where there is a significant amount of IPA servers installed and distributed in different places where access is restricted by location, it can take some time until the reachable IPA/NTP server for a given client/location is found. A suggestion would be that if one goes for the --fixed-primary + --server options, then the omission of DNS discovery should not only apply to the IPA service but also for time synchronization. In most cases chances are that if one opts to use specific servers for IPA, one probably also wants to use specific servers for NTP. Or for added flexibility, provide another switch to select a specifc server to synchronize time with during the enrolment process. FYI, use of the --ntp-server switch does not prevent the enrolment process from using DNS discovery to synchronize the time. I suppose that switch is only used for setting the NTP server to use if one wishes to configure NTPD. (Besides not everyone opts to use NTPD on clients - some use an ntpdate job - so fixed-server time synchronization during enrolment should also be possible when using -N/--no-ntp) One last thing is that when using the --server option multiple times, it seems the order in sssd.conf is reversed. Example if I specify --server node1 --server node2, in sssd.conf I will end up with: ipa_server = node2, node1 Therefore I specify the servers to begin with in reverse order, in order to have them configured in the desired order. Regards John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ERROR Update failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed
Hi We found out recently that an IPA server which we upgraded some time ago from EL6.2/IPA 2.1 to EL6.3/IPA 2.2, reported the following errors: ERROR Update failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed ERROR Upgrade failed with attribute idnsAllowQuery not allowed The latter error we resolved by applying the patch found @ https://fedorahosted.org/freeipa/ticket/2440 (in fact we used this fix on another server in the past). Unfortunately we do not have a solution for the first error (related to ipaSELinuxUserMapOrder). Any ideas? We do have plans to upgrade the mentioned server to EL 6.4 / IPA 3.0, but I doubt this would be safe to do before we resolve the above error first. Regards John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install: done remotely, DNS discovery and multiple servers
John Blaut wrote: Hi Since EL 6.4, executing ipa-client-install over SSH i.e. 'ssh client ipa-client-install params', results in an issue with the host certificate. The output returns the following error during the: 'ipa-getcert request -d /etc/pki/nssdb' stage: TLS: could not close certdb slot - error -8018:Unknown PKCS #11 error. TLS: could not shutdown NSS - error -8053:NSS could not shutdown The host certificate remains in state: 'status: NEED_CSR' when checking with ipa-getcert list I'm not able to reproduce this. You might try: ipa-getcert resubmit -i requestid post-install to see if it goes out of NEED_CSR. In EL6.2 and EL6.3 this was not an issue. Perhaps you may reproduce this and advise. In order to work around this, I end up having to run ipa-client-install locally on the client. Also, with 6.4, thanks to the --fixed-primary switch we can now statically set specific IPA servers to use for a given client, instead of rely on DNS (SRV records) discovery. Before this feature we would need to patch the sssd.conf manually and restart SSSD, as ipa-client-install would remain stuck since the given client via SRV discovery would attempt using an IPA server it does not have access to. Now we longer have this issue, however ipa-client-install still picks the NTP server with which it should synchronize time during the enrolment process via DNS discovery. In the past ipa-client-install would 'give up' after 3 attempts or so, but now it keeps attempting until it encounters a reachable IPA NTP server. In an environment where there is a significant amount of IPA servers installed and distributed in different places where access is restricted by location, it can take some time until the reachable IPA/NTP server for a given client/location is found. A suggestion would be that if one goes for the --fixed-primary + --server options, then the omission of DNS discovery should not only apply to the IPA service but also for time synchronization. In most cases chances are that if one opts to use specific servers for IPA, one probably also wants to use specific servers for NTP. Or for added flexibility, provide another switch to select a specifc server to synchronize time with during the enrolment process. FYI, use of the --ntp-server switch does not prevent the enrolment process from using DNS discovery to synchronize the time. I suppose that switch is only used for setting the NTP server to use if one wishes to configure NTPD. (Besides not everyone opts to use NTPD on clients - some use an ntpdate job - so fixed-server time synchronization during enrolment should also be possible when using -N/--no-ntp) We have a number of tickets against NTP. There is some amount of overlap, but it doesn't seem to cove everything. Specifically tickets https://fedorahosted.org/freeipa/ticket/3092, https://fedorahosted.org/freeipa/ticket/2992 and https://fedorahosted.org/freeipa/ticket/1954 If we've missed anything any chance you can open a ticket (or tickets) for the new features? One last thing is that when using the --server option multiple times, it seems the order in sssd.conf is reversed. Example if I specify --server node1 --server node2, in sssd.conf I will end up with: ipa_server = node2, node1 Therefore I specify the servers to begin with in reverse order, in order to have them configured in the desired order. Fixed upstream https://fedorahosted.org/freeipa/ticket/3418 regards rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ERROR Update failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed
John Blaut wrote: Hi We found out recently that an IPA server which we upgraded some time ago from EL6.2/IPA 2.1 to EL6.3/IPA 2.2, reported the following errors: ERROR Update failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed ERROR Upgrade failed with attribute idnsAllowQuery not allowed The latter error we resolved by applying the patch found @ https://fedorahosted.org/freeipa/ticket/2440 (in fact we used this fix on another server in the past). Unfortunately we do not have a solution for the first error (related to ipaSELinuxUserMapOrder). Any ideas? We do have plans to upgrade the mentioned server to EL 6.4 / IPA 3.0, but I doubt this would be safe to do before we resolve the above error first. Updating might be fine, but it shouldn't be too hard to fix first. I'd start by getting the current schema: ldapsearch -x -b cn=schema objectclasses attributetypes /path/to/some/file See if ipaSELinuxUserMapOrder is defined as an attributeType. It looks like there is an error in the update file that adds this attribute, so it may not be there. Look in /usr/share/ipa/updates/10-selinuxusermap.update and you'll see this line duplicated: X-ORIGIN 'IPA v3') If so, I'd try to remove the extra line and run: ipa-ldap-updater /usr/share/ipa/updates/10-selinuxusermap.update That should fix it. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install: done remotely, DNS discovery and multiple servers
Hi Many thanks for the feedback and bringing those tickets to my attention. I tried the 'ipa-getcert resubmit' before posting this, but it did not help. The status remained NEED_CSR. I'll try a few other things which come to mind. Regards John On Tue, May 7, 2013 at 10:50 PM, Rob Crittenden rcrit...@redhat.com wrote: John Blaut wrote: Hi Since EL 6.4, executing ipa-client-install over SSH i.e. 'ssh client ipa-client-install params', results in an issue with the host certificate. The output returns the following error during the: 'ipa-getcert request -d /etc/pki/nssdb' stage: TLS: could not close certdb slot - error -8018:Unknown PKCS #11 error. TLS: could not shutdown NSS - error -8053:NSS could not shutdown The host certificate remains in state: 'status: NEED_CSR' when checking with ipa-getcert list I'm not able to reproduce this. You might try: ipa-getcert resubmit -i requestid post-install to see if it goes out of NEED_CSR. In EL6.2 and EL6.3 this was not an issue. Perhaps you may reproduce this and advise. In order to work around this, I end up having to run ipa-client-install locally on the client. Also, with 6.4, thanks to the --fixed-primary switch we can now statically set specific IPA servers to use for a given client, instead of rely on DNS (SRV records) discovery. Before this feature we would need to patch the sssd.conf manually and restart SSSD, as ipa-client-install would remain stuck since the given client via SRV discovery would attempt using an IPA server it does not have access to. Now we longer have this issue, however ipa-client-install still picks the NTP server with which it should synchronize time during the enrolment process via DNS discovery. In the past ipa-client-install would 'give up' after 3 attempts or so, but now it keeps attempting until it encounters a reachable IPA NTP server. In an environment where there is a significant amount of IPA servers installed and distributed in different places where access is restricted by location, it can take some time until the reachable IPA/NTP server for a given client/location is found. A suggestion would be that if one goes for the --fixed-primary + --server options, then the omission of DNS discovery should not only apply to the IPA service but also for time synchronization. In most cases chances are that if one opts to use specific servers for IPA, one probably also wants to use specific servers for NTP. Or for added flexibility, provide another switch to select a specifc server to synchronize time with during the enrolment process. FYI, use of the --ntp-server switch does not prevent the enrolment process from using DNS discovery to synchronize the time. I suppose that switch is only used for setting the NTP server to use if one wishes to configure NTPD. (Besides not everyone opts to use NTPD on clients - some use an ntpdate job - so fixed-server time synchronization during enrolment should also be possible when using -N/--no-ntp) We have a number of tickets against NTP. There is some amount of overlap, but it doesn't seem to cove everything. Specifically tickets https://fedorahosted.org/**freeipa/ticket/3092https://fedorahosted.org/freeipa/ticket/3092, https://fedorahosted.org/**freeipa/ticket/2992https://fedorahosted.org/freeipa/ticket/2992and https://fedorahosted.org/**freeipa/ticket/1954https://fedorahosted.org/freeipa/ticket/1954 If we've missed anything any chance you can open a ticket (or tickets) for the new features? One last thing is that when using the --server option multiple times, it seems the order in sssd.conf is reversed. Example if I specify --server node1 --server node2, in sssd.conf I will end up with: ipa_server = node2, node1 Therefore I specify the servers to begin with in reverse order, in order to have them configured in the desired order. Fixed upstream https://fedorahosted.org/**freeipa/ticket/3418https://fedorahosted.org/freeipa/ticket/3418 regards rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ERROR Update failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed
Hi Thanks for the feedback. It seems the attributeType was already there. Nevertheless I tried your suggested fix but I did not help. ipa config-show and likewise the UI does not show SELinux related settings. Regards John On Tue, May 7, 2013 at 11:51 PM, Rob Crittenden rcrit...@redhat.com wrote: John Blaut wrote: Hi We found out recently that an IPA server which we upgraded some time ago from EL6.2/IPA 2.1 to EL6.3/IPA 2.2, reported the following errors: ERROR Update failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed ERROR Upgrade failed with attribute idnsAllowQuery not allowed The latter error we resolved by applying the patch found @ https://fedorahosted.org/**freeipa/ticket/2440https://fedorahosted.org/freeipa/ticket/2440(in fact we used this fix on another server in the past). Unfortunately we do not have a solution for the first error (related to ipaSELinuxUserMapOrder). Any ideas? We do have plans to upgrade the mentioned server to EL 6.4 / IPA 3.0, but I doubt this would be safe to do before we resolve the above error first. Updating might be fine, but it shouldn't be too hard to fix first. I'd start by getting the current schema: ldapsearch -x -b cn=schema objectclasses attributetypes /path/to/some/file See if ipaSELinuxUserMapOrder is defined as an attributeType. It looks like there is an error in the update file that adds this attribute, so it may not be there. Look in /usr/share/ipa/updates/10-**selinuxusermap.update and you'll see this line duplicated: X-ORIGIN 'IPA v3') If so, I'd try to remove the extra line and run: ipa-ldap-updater /usr/share/ipa/updates/10-**selinuxusermap.update That should fix it. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ERROR Update failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed
John Blaut wrote: Hi Thanks for the feedback. It seems the attributeType was already there. Nevertheless I tried your suggested fix but I did not help. ipa config-show and likewise the UI does not show SELinux related settings. Ok, can you send me the output of: ipa-ldap-updater -d /usr/share/ipa/updates/10-selinuxusermap.update It is going to be long and ugly. rob Regards John On Tue, May 7, 2013 at 11:51 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: John Blaut wrote: Hi We found out recently that an IPA server which we upgraded some time ago from EL6.2/IPA 2.1 to EL6.3/IPA 2.2, reported the following errors: ERROR Update failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed ERROR Upgrade failed with attribute idnsAllowQuery not allowed The latter error we resolved by applying the patch found @ https://fedorahosted.org/__freeipa/ticket/2440 https://fedorahosted.org/freeipa/ticket/2440 (in fact we used this fix on another server in the past). Unfortunately we do not have a solution for the first error (related to ipaSELinuxUserMapOrder). Any ideas? We do have plans to upgrade the mentioned server to EL 6.4 / IPA 3.0, but I doubt this would be safe to do before we resolve the above error first. Updating might be fine, but it shouldn't be too hard to fix first. I'd start by getting the current schema: ldapsearch -x -b cn=schema objectclasses attributetypes /path/to/some/file See if ipaSELinuxUserMapOrder is defined as an attributeType. It looks like there is an error in the update file that adds this attribute, so it may not be there. Look in /usr/share/ipa/updates/10-__selinuxusermap.update and you'll see this line duplicated: X-ORIGIN 'IPA v3') If so, I'd try to remove the extra line and run: ipa-ldap-updater /usr/share/ipa/updates/10-__selinuxusermap.update That should fix it. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
