From rcritten at redhat.com Tue Jan 1 23:42:06 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Jan 2013 18:42:06 -0500 Subject: [Freeipa-users] Fedora 18 + FreeIPA 3.1 In-Reply-To: <50DF401C.7020401@themacartneyclan.com> References: <50DF1A64.90702@themacartneyclan.com> <50DF38AE.8040307@redhat.com> <50DF401C.7020401@themacartneyclan.com> Message-ID: <50E3744E.10207@redhat.com> Dale Macartney wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 12/29/2012 06:38 PM, Rob Crittenden wrote: >> Dale Macartney wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Afternoon all >>> >>> using Fedora 18 Beta and attempting to install FreeIPA 3.1 >>> >>> when running through the install of "ipa-server-install --setup-dns" I >>> end up with a failure with the below output >>> >>> >>> [root at ds01 ~]# ipa-server-install --setup-dns >>> ..... >>> ..... >>> Done configuring directory server (dirsrv). >>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes >>> 30 seconds >>> [1/20]: creating certificate server user >>> [2/20]: configuring certificate server instance >>> [3/20]: disabling nonces >>> [4/20]: creating RA agent certificate database >>> [5/20]: importing CA chain to RA certificate database >>> [6/20]: fixing RA database permissions >>> [7/20]: setting up signing cert profile >>> [8/20]: set up CRL publishing >>> [9/20]: set certificate subject base >>> [10/20]: enabling Subject Key Identifier >>> [11/20]: enabling CRL and OCSP extensions for certificates >>> [12/20]: setting audit signing renewal to 2 years >>> [13/20]: configuring certificate server to start on boot >>> [14/20]: restarting certificate server >>> [15/20]: requesting RA certificate from CA >>> [16/20]: issuing RA agent certificate >>> Unexpected error - see /var/log/ipaserver-install.log for details: >>> CalledProcessError: Command '/usr/bin/sslget -v -n ipa-ca-agent -p >>> XXXXXXXX -d /tmp/tmp-kUFAyN -r /ca/agent/ca/profileReview?requestId=7 >>> ds01.domain.com:8443' returned non-zero exit status 6 >>> >>> >>> there is absolutely nothing in any logs at all apart from a few selinux >>> audit logs (system running in permissive mode). >>> >>> Any thoughts? >> >> This usually means a problem with DNS. > Hmm... normally I set a dns forwarder of 10.0.0.254... This time I tried > it with no forwarder at all... Same error occurs... Not really sure. The errors out of sslget are not particularly helpful. I'd check /etc/hosts to be sure it is sane, and perhaps dig/host to be sure that the forward and reverse entries match up. rob From dale at themacartneyclan.com Wed Jan 2 00:32:12 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Wed, 02 Jan 2013 00:32:12 +0000 Subject: [Freeipa-users] Fedora 18 + FreeIPA 3.1 In-Reply-To: <50E3744E.10207@redhat.com> References: <50DF1A64.90702@themacartneyclan.com> <50DF38AE.8040307@redhat.com> <50DF401C.7020401@themacartneyclan.com> <50E3744E.10207@redhat.com> Message-ID: <50E3800C.4090900@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/01/2013 11:42 PM, Rob Crittenden wrote: > Dale Macartney wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> On 12/29/2012 06:38 PM, Rob Crittenden wrote: >>> Dale Macartney wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Afternoon all >>>> >>>> using Fedora 18 Beta and attempting to install FreeIPA 3.1 >>>> >>>> when running through the install of "ipa-server-install --setup-dns" I >>>> end up with a failure with the below output >>>> >>>> >>>> [root at ds01 ~]# ipa-server-install --setup-dns >>>> ..... >>>> ..... >>>> Done configuring directory server (dirsrv). >>>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes >>>> 30 seconds >>>> [1/20]: creating certificate server user >>>> [2/20]: configuring certificate server instance >>>> [3/20]: disabling nonces >>>> [4/20]: creating RA agent certificate database >>>> [5/20]: importing CA chain to RA certificate database >>>> [6/20]: fixing RA database permissions >>>> [7/20]: setting up signing cert profile >>>> [8/20]: set up CRL publishing >>>> [9/20]: set certificate subject base >>>> [10/20]: enabling Subject Key Identifier >>>> [11/20]: enabling CRL and OCSP extensions for certificates >>>> [12/20]: setting audit signing renewal to 2 years >>>> [13/20]: configuring certificate server to start on boot >>>> [14/20]: restarting certificate server >>>> [15/20]: requesting RA certificate from CA >>>> [16/20]: issuing RA agent certificate >>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>> CalledProcessError: Command '/usr/bin/sslget -v -n ipa-ca-agent -p >>>> XXXXXXXX -d /tmp/tmp-kUFAyN -r /ca/agent/ca/profileReview?requestId=7 >>>> ds01.domain.com:8443' returned non-zero exit status 6 >>>> >>>> >>>> there is absolutely nothing in any logs at all apart from a few selinux >>>> audit logs (system running in permissive mode). >>>> >>>> Any thoughts? >>> >>> This usually means a problem with DNS. >> Hmm... normally I set a dns forwarder of 10.0.0.254... This time I tried >> it with no forwarder at all... Same error occurs... > > Not really sure. The errors out of sslget are not particularly helpful. > > I'd check /etc/hosts to be sure it is sane, and perhaps dig/host to be sure that the forward and reverse entries match up. that'll teach me for using non-kickstarted systems... error is caused by mis or unconfigured /etc/hosts > > rob > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ44ADAAoJEAJsWS61tB+qo9cP/RR+zhZ4tX7lSmeD5MOK1ACa aci0s9HfROU2K/deiS8qLFKtxVdvm8itc2lda4TVwTHbhVompKi3mpp3KBlB8te/ 6WLpuC2agQeSPSlxlaDi6+6ue9/5c0bLogf5EJDEjGae/hsC3AJfYiW661WgAnZg qrU3X0rn00giy+sAOd0oFuqeBo+Hu/KZF3sDHF/YVK8fDMtajnZcj7C6zy1zOmdP bWj7flqZSZA3LlsOyq0e77U0VW5aFnEGE87ywNyCiXvuZjI/02iOijpPKpppk1If 9zVLPncDDU2smyGbEBE4/aylNbwzXa4izWQ9KwjqU2kWLd+tIq/74/gu7dDVjeOP dTnQuGWsSJlrEEuLlwks09BmOl2kIBr/EB/EZt1R31ldL+d1vK8aV3pBmXgptVsG l3R8rAvhu5WoJCKG4gtQVGSn1HkoSPHjc5FGIw/UjXbANcZlIONwujh6gdNHm2vk syk47+7ThamYTx3Hpq+dggxFcEekq+z1MWLP5gv5Odt/Vc810ziTn+QK97gY5UMM OD1kR34QN1FQsjn5qsjX9TumU4xvtvnuqgpj+0RTWGFk+55HFfdcTr+8rJKLsxrW g+Runt3DCu3YlUU+7Nc1FNLfwzjh227OzX1NxsMNTUYyCoOAHM85Ty6nGmFdkoBG XJeYI5r3FYZ1e/9Jtysq =TlwR -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc Type: application/pgp-keys Size: 8187 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 2 00:42:02 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Jan 2013 19:42:02 -0500 Subject: [Freeipa-users] Fedora 18 + FreeIPA 3.1 In-Reply-To: <50E3800C.4090900@themacartneyclan.com> References: <50DF1A64.90702@themacartneyclan.com> <50DF38AE.8040307@redhat.com> <50DF401C.7020401@themacartneyclan.com> <50E3744E.10207@redhat.com> <50E3800C.4090900@themacartneyclan.com> Message-ID: <50E3825A.1020806@redhat.com> Dale Macartney wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 01/01/2013 11:42 PM, Rob Crittenden wrote: >> Dale Macartney wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> >>> On 12/29/2012 06:38 PM, Rob Crittenden wrote: >>>> Dale Macartney wrote: >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Afternoon all >>>>> >>>>> using Fedora 18 Beta and attempting to install FreeIPA 3.1 >>>>> >>>>> when running through the install of "ipa-server-install --setup-dns" I >>>>> end up with a failure with the below output >>>>> >>>>> >>>>> [root at ds01 ~]# ipa-server-install --setup-dns >>>>> ..... >>>>> ..... >>>>> Done configuring directory server (dirsrv). >>>>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes >>>>> 30 seconds >>>>> [1/20]: creating certificate server user >>>>> [2/20]: configuring certificate server instance >>>>> [3/20]: disabling nonces >>>>> [4/20]: creating RA agent certificate database >>>>> [5/20]: importing CA chain to RA certificate database >>>>> [6/20]: fixing RA database permissions >>>>> [7/20]: setting up signing cert profile >>>>> [8/20]: set up CRL publishing >>>>> [9/20]: set certificate subject base >>>>> [10/20]: enabling Subject Key Identifier >>>>> [11/20]: enabling CRL and OCSP extensions for certificates >>>>> [12/20]: setting audit signing renewal to 2 years >>>>> [13/20]: configuring certificate server to start on boot >>>>> [14/20]: restarting certificate server >>>>> [15/20]: requesting RA certificate from CA >>>>> [16/20]: issuing RA agent certificate >>>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>>> CalledProcessError: Command '/usr/bin/sslget -v -n ipa-ca-agent -p >>>>> XXXXXXXX -d /tmp/tmp-kUFAyN -r /ca/agent/ca/profileReview?requestId=7 >>>>> ds01.domain.com:8443' returned non-zero exit status 6 >>>>> >>>>> >>>>> there is absolutely nothing in any logs at all apart from a few selinux >>>>> audit logs (system running in permissive mode). >>>>> >>>>> Any thoughts? >>>> >>>> This usually means a problem with DNS. >>> Hmm... normally I set a dns forwarder of 10.0.0.254... This time I tried >>> it with no forwarder at all... Same error occurs... >> >> Not really sure. The errors out of sslget are not particularly helpful. >> >> I'd check /etc/hosts to be sure it is sane, and perhaps dig/host to be > sure that the forward and reverse entries match up. > that'll teach me for using non-kickstarted systems... > > error is caused by mis or unconfigured /etc/hosts It's hard to programmatically check for some things but I was pretty sure we did some /etc/hosts sanity checking. What was the problem, and I guess more importantly, is it something we can/should check for prior to starting the install? thanks rob From janfrode at tanso.net Wed Jan 2 10:26:11 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Wed, 2 Jan 2013 11:26:11 +0100 Subject: [Freeipa-users] re-sync passwords after migration from LDAP to IPA ? Message-ID: Too long ago I ran "ipa migrate-ds" to migrate my users into IPA, but unfortunately haven't been able to roll out IPA as our main identity platform yet. Now many users has probably changed passwords in the old directory, and switching to an IPA with their old password will be confusing. Is there any way to tell "ipa migrate-ds" to re-sync/re-migrate LDAP passwords ? -jf From sgallagh at redhat.com Wed Jan 2 13:00:58 2013 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 02 Jan 2013 08:00:58 -0500 Subject: [Freeipa-users] Joining Fedora 18 (FreeIPA 3.1.0) to CentOS 6.3 (FreeIPA 2.1.90rc1) In-Reply-To: References: <50D9B1B5.3020206@redhat.com> <1356483191.2894.156.camel@willson.li.ssimo.org> <50DA4AC9.1070901@naunetcorp.com> <1356535422.2894.160.camel@willson.li.ssimo.org> <1356703009.2894.186.camel@willson.li.ssimo.org> Message-ID: <50E42F8A.3060008@redhat.com> On 12/28/2012 10:23 AM, Michael B. Trausch wrote: > On 12/28/2012 08:56 AM, Simo Sorce wrote: >> However re-reading the ticket made me wonder. Is this happening on the >> F18 machine or on the Centos 6.3 machine ? > > The sigsegv is happening on the Fedora 18 box, the one running FreeIPA > 3.1.0. > > I am completely unable to install debug symbols for the following libraries: > > ======================================================================= > Missing separate debuginfos, use: debuginfo-install > cyrus-sasl-gssapi-2.1.25-2.fc18.x86_64 > cyrus-sasl-lib-2.1.25-2.fc18.x86_64 cyrus-sasl-md5-2.1.25-2.fc18.x86_64 > cyrus-sasl-plain-2.1.25-2.fc18.x86_64 glibc-2.16-28.fc18.x86_64 > pcre-8.31-3.fc18.x86_64 sssd-client-1.9.3-1.fc18.x86_64 > ======================================================================= > > When I run that command, I get the following message: > > ======================================================================= > No debuginfo packages available to install > ======================================================================= > > Which of course, is unhelpful. > > --- Mike > That's the problem with running Fedora pre-releases. If you don't remember to disable the updates-testing repo, you get untested packages. The latest version of cyrus-sasl that is in the stable repo is cyrus-sasl-gssapi-2.1.23-36.fc18.x86_64. The reason you can't get the debuginfo packages for cyrus-sasl is because the update was yanked from the testing repo due to *drumroll* segfaults. I strongly recommend that you do the following: 'yum clean all' (Purges your yum cache completely, so we don't get stale data) 'yum update fedora-release' (The latest version that is now in stable disables updates-testing) 'yum distro-sync' (This upgrades and downgrades all packages so that they match what is in the enabled repositories, in this case it will guarantee that you have the latest stable versions of all packages). Alternately you can wait until next week (January 8th) when Fedora 18 stable is expected to be released (assuming that tomorrow's Go/No-Go meeting does not delay it for another week) and install fresh from there. From dpal at redhat.com Wed Jan 2 15:11:35 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 02 Jan 2013 10:11:35 -0500 Subject: [Freeipa-users] re-sync passwords after migration from LDAP to IPA ? In-Reply-To: References: Message-ID: <50E44E27.3090205@redhat.com> On 01/02/2013 05:26 AM, Jan-Frode Myklebust wrote: > Too long ago I ran "ipa migrate-ds" to migrate my users into IPA, but > unfortunately haven't been able to roll out IPA as our main identity > platform yet. Now many users has probably changed passwords in the old > directory, and switching to an IPA with their old password will be > confusing. Is there any way to tell "ipa migrate-ds" to > re-sync/re-migrate LDAP passwords ? Would it be simpler and cleaner to start with a fresh install? > > -jf > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ From simo at redhat.com Wed Jan 2 16:35:08 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 02 Jan 2013 11:35:08 -0500 Subject: [Freeipa-users] Joining Fedora 18 (FreeIPA 3.1.0) to CentOS 6.3 (FreeIPA 2.1.90rc1) In-Reply-To: <50E42F8A.3060008@redhat.com> References: <50D9B1B5.3020206@redhat.com> <1356483191.2894.156.camel@willson.li.ssimo.org> <50DA4AC9.1070901@naunetcorp.com> <1356535422.2894.160.camel@willson.li.ssimo.org> <1356703009.2894.186.camel@willson.li.ssimo.org> <50E42F8A.3060008@redhat.com> Message-ID: <1357144508.2894.204.camel@willson.li.ssimo.org> On Wed, 2013-01-02 at 08:00 -0500, Stephen Gallagher wrote: > On 12/28/2012 10:23 AM, Michael B. Trausch wrote: > > On 12/28/2012 08:56 AM, Simo Sorce wrote: > >> However re-reading the ticket made me wonder. Is this happening on the > >> F18 machine or on the Centos 6.3 machine ? > > > > The sigsegv is happening on the Fedora 18 box, the one running FreeIPA > > 3.1.0. > > > > I am completely unable to install debug symbols for the following libraries: > > > > ======================================================================= > > Missing separate debuginfos, use: debuginfo-install > > cyrus-sasl-gssapi-2.1.25-2.fc18.x86_64 > > cyrus-sasl-lib-2.1.25-2.fc18.x86_64 cyrus-sasl-md5-2.1.25-2.fc18.x86_64 > > cyrus-sasl-plain-2.1.25-2.fc18.x86_64 glibc-2.16-28.fc18.x86_64 > > pcre-8.31-3.fc18.x86_64 sssd-client-1.9.3-1.fc18.x86_64 > > ======================================================================= > > > > When I run that command, I get the following message: > > > > ======================================================================= > > No debuginfo packages available to install > > ======================================================================= > > > > Which of course, is unhelpful. > > > > --- Mike > > > > > That's the problem with running Fedora pre-releases. If you don't > remember to disable the updates-testing repo, you get untested packages. > The latest version of cyrus-sasl that is in the stable repo is > cyrus-sasl-gssapi-2.1.23-36.fc18.x86_64. The reason you can't get the > debuginfo packages for cyrus-sasl is because the update was yanked from > the testing repo due to *drumroll* segfaults. > > I strongly recommend that you do the following: > 'yum clean all' (Purges your yum cache completely, so we don't get stale > data) > 'yum update fedora-release' (The latest version that is now in stable > disables updates-testing) > 'yum distro-sync' (This upgrades and downgrades all packages so that > they match what is in the enabled repositories, in this case it will > guarantee that you have the latest stable versions of all packages). > > Alternately you can wait until next week (January 8th) when Fedora 18 > stable is expected to be released (assuming that tomorrow's Go/No-Go > meeting does not delay it for another week) and install fresh from there. Thanks Stephen, I'll close the bug as invalid. Simo. -- Simo Sorce * Red Hat, Inc * New York From janfrode at tanso.net Wed Jan 2 17:36:39 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Wed, 2 Jan 2013 18:36:39 +0100 Subject: [Freeipa-users] re-sync passwords after migration from LDAP to IPA ? In-Reply-To: <50E44E27.3090205@redhat.com> References: <50E44E27.3090205@redhat.com> Message-ID: On Wed, Jan 2, 2013 at 4:11 PM, Dmitri Pal wrote: > Would it be simpler and cleaner to start with a fresh install? Unfortunately some systems are already using IPA so I can't easily start fresh.. but yes, I can probably just delete the accounts with different LDAP password in IPA and OLD-system, and then do a new migration of these few. But... where do I find the LDAP passwords in IPA ? I see there's no "userPassword" attribute on each user as I was expecting.., so where is this hidden? And can it be compared against the SSHA from the old directory ? -jf From sigbjorn at nixtra.com Wed Jan 2 18:12:54 2013 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 02 Jan 2013 19:12:54 +0100 Subject: [Freeipa-users] re-sync passwords after migration from LDAP to IPA ? In-Reply-To: References: <50E44E27.3090205@redhat.com> Message-ID: <62021118-0a0c-46b8-b67f-f94fa98e2294@email.android.com> Try to browse the user again after you've authenticated using the directory manager account. Rgds Siggi Jan-Frode Myklebust wrote: >On Wed, Jan 2, 2013 at 4:11 PM, Dmitri Pal wrote: >> Would it be simpler and cleaner to start with a fresh install? > > >Unfortunately some systems are already using IPA so I can't easily >start fresh.. but yes, I can probably just delete the accounts with >different LDAP password in IPA and OLD-system, and then do a new >migration of these few. > >But... where do I find the LDAP passwords in IPA ? I see there's no >"userPassword" attribute on each user as I was expecting.., so where >is this hidden? And can it be compared against the SSHA from the old >directory ? > > > -jf > >_______________________________________________ >Freeipa-users mailing list >Freeipa-users at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-users -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Jan 2 20:09:50 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 02 Jan 2013 15:09:50 -0500 Subject: [Freeipa-users] re-sync passwords after migration from LDAP to IPA ? In-Reply-To: References: <50E44E27.3090205@redhat.com> Message-ID: <1357157390.2894.247.camel@willson.li.ssimo.org> On Wed, 2013-01-02 at 18:36 +0100, Jan-Frode Myklebust wrote: > But... where do I find the LDAP passwords in IPA ? I see there's no > "userPassword" attribute on each user as I was expecting.., so where > is this hidden? And can it be compared against the SSHA from the old > directory ? Passwords are stored in both the userPassword attribute (SHA256 hash by deault) and the krbPrincipalKey attribute an opaque and encrypted object containing Kerberos Keys (RC4/3DES/AES keys). If you enabled trusts or samba integration you will also have RC4 hashes in the sambaNTpassword or ipaNThash attributes. None of these attributes are readable, so you will not see them. Only 'cn=Directory Manager' can retrieve them, because that account has super powers. Simo. -- Simo Sorce * Red Hat, Inc * New York From janfrode at tanso.net Wed Jan 2 21:17:21 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Wed, 2 Jan 2013 22:17:21 +0100 Subject: [Freeipa-users] re-sync passwords after migration from LDAP to IPA ? In-Reply-To: <1357157390.2894.247.camel@willson.li.ssimo.org> References: <50E44E27.3090205@redhat.com> <1357157390.2894.247.camel@willson.li.ssimo.org> Message-ID: Ok, thanks all! I'll compare the userPassword attributes between old directory and IPA, and either delete the account from IPA and re-run ds-migrate, or contact the individual users to let them know how to handle this. -jf From rcritten at redhat.com Wed Jan 2 21:54:22 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Jan 2013 16:54:22 -0500 Subject: [Freeipa-users] re-sync passwords after migration from LDAP to IPA ? In-Reply-To: <1357157390.2894.247.camel@willson.li.ssimo.org> References: <50E44E27.3090205@redhat.com> <1357157390.2894.247.camel@willson.li.ssimo.org> Message-ID: <50E4AC8E.7050200@redhat.com> Simo Sorce wrote: > On Wed, 2013-01-02 at 18:36 +0100, Jan-Frode Myklebust wrote: >> But... where do I find the LDAP passwords in IPA ? I see there's no >> "userPassword" attribute on each user as I was expecting.., so where >> is this hidden? And can it be compared against the SSHA from the old >> directory ? > > Passwords are stored in both the userPassword attribute (SHA256 hash by > deault) and the krbPrincipalKey attribute an opaque and encrypted object > containing Kerberos Keys (RC4/3DES/AES keys). > If you enabled trusts or samba integration you will also have RC4 hashes > in the sambaNTpassword or ipaNThash attributes. > > None of these attributes are readable, so you will not see them. Only > 'cn=Directory Manager' can retrieve them, because that account has super > powers. > > Simo. > Right, so you can probably tell who has migrated and already set their password in IPA by looking for users with both userPassword and krbPrincipalKey set. If just userPassword is set then they were migrated but have not set their password yet. I don't believe there is a way to re-sync just the password entry using migrate-ds. It will skip over users already loaded. You would have to either write a small sync routine yourself or delete this subset of users from ipa and re-migrate. rob From chris.natter at destinationrewards.com Wed Jan 2 22:47:40 2013 From: chris.natter at destinationrewards.com (Chris Natter) Date: Wed, 2 Jan 2013 17:47:40 -0500 Subject: [Freeipa-users] User's Cannot Reset Expire Passwords Without Password Being Reset First in WebUI Message-ID: <20130102224740.GD1284@mobility.troy.dr.local> Hello, My users are running into a bit of a problem with password expiry and the reset prompts. When they attempt to reset their password they end up recieving access denied messages after going through the prompts to reset their password and entering their new desired passwords. The interesting thing is that if I reset the password via the Web UI to anything, and then have the user try again with the new password, they are able to successfully reset their password with no issues. Log snippets are below, I've sanitized them so the user in question is 'juser'. Any help or guidance would be very appreciated. Thank you! sshd[26945]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.20.1.108 user=juser sshd[26945]: pam_sss(sshd:auth): system info: [Password has expired] sshd[26945]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.20.1.108 user=juser sshd[26945]: pam_sss(sshd:auth): received for user juser: 12 (Authentication token is no longer valid; new one required) sshd[26945]: pam_sss(sshd:account): User info message: Password expired. Change your password now. sshd[26945]: pam_unix(sshd:chauthtok): user "juser" does not exist in /etc/passwd sshd[26945]: pam_unix(sshd:chauthtok): user "juser" does not exist in /etc/passwd sshd[26945]: pam_sss(sshd:chauthtok): system info: [Generic error (see e-text)] sshd[26945]: pam_sss(sshd:chauthtok): User info message: Password change failed. Server message: Password change rejected sshd[26945]: pam_sss(sshd:chauthtok): Password change failed for user juser: 20 (Authentication token manipulation error) sshd[26977]: pam_unix(sshd:auth): conversation failed sshd[26977]: pam_unix(sshd:auth): auth could not identify password for [juser] sshd[26977]: pam_sss(sshd:auth): system info: [Cannot read password] sshd[26977]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.22.1.108 user=juser sshd[26977]: pam_sss(sshd:auth): received for user juser: 4 (System error) sshd[26977]: error: ssh_msg_send: write [[sssd[krb5_child[26452]]]] [validate_tgt] (5): TGT verified using key for [host/devbox3.lnx.foo.local at LNX.FOO.LOCAL]. [[sssd[krb5_child[26949]]]] [krb5_child_setup] (7): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. [[sssd[krb5_child[26949]]]] [krb5_child_setup] (7): Cannot read [SSSD_KRB5_LIFETIME] from environment. [[sssd[krb5_child[26949]]]] [sss_krb5_get_init_creds_opt_set_expire_callback] (5): krb5_get_init_creds_opt_set_expire_callback not available. [[sssd[krb5_child[26949]]]] [get_and_save_tgt] (1): 721: [-1765328361][Password has expired] [[sssd[krb5_child[26949]]]] [sss_krb5_get_init_creds_opt_set_expire_callback] (5): krb5_get_init_creds_opt_set_expire_callback not available. [[sssd[krb5_child[26949]]]] [tgt_req_child] (1): 980: [-1765328361][Password has expired] [[sssd[krb5_child[26958]]]] [krb5_child_setup] (7): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. [[sssd[krb5_child[26958]]]] [krb5_child_setup] (7): Cannot read [SSSD_KRB5_LIFETIME] from environment. [[sssd[krb5_child[26976]]]] [krb5_child_setup] (7): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. [[sssd[krb5_child[26976]]]] [krb5_child_setup] (7): Cannot read [SSSD_KRB5_LIFETIME] from environment. [[sssd[krb5_child[26976]]]] [changepw_child] (1): krb5_change_password failed [4][Password change rejected]. krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: CLIENT KEY EXPIRED: juser at LNX.FOO.LOCAL for krbtgt/LNX.FOO.LOCAL at LNX.FOO.LOCAL, Password has expired krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: NEEDED_PREAUTH: juser at LNX.FOO.LOCAL for kadmin/changepw at LNX.FOO.LOCAL, Additional pre-authentication required krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: ISSUE: authtime 1357163914, etypes {rep=18 tkt=18 ses=18}, juser at LNX.FOO.LOCAL for kadmin/changepw at LNX.FOO.LOCAL krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: NEEDED_PREAUTH: juser at LNX.FOO.LOCAL for kadmin/changepw at LNX.FOO.LOCAL, Additional pre-authentication required krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: ISSUE: authtime 1357163921, etypes {rep=18 tkt=18 ses=18}, juser at LNX.FOO.LOCAL for kadmin/changepw at LNX.FOO.LOCAL krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: NEEDED_PREAUTH: juser at LNX.FOO.LOCAL for kadmin/changepw at LNX.FOO.LOCAL, Additional pre-authentication required krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: ISSUE: authtime 1357163949, etypes {rep=18 tkt=18 ses=18}, juser at LNX.FOO.LOCAL for kadmin/changepw at LNX.FOO.LOCAL krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: CLIENT KEY EXPIRED: juser at LNX.FOO.LOCAL for krbtgt/LNX.FOO.LOCAL at LNX.FOO.LOCAL, Password has expired krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: NEEDED_PREAUTH: juser at LNX.FOO.LOCAL for kadmin/changepw at LNX.FOO.LOCAL, Additional pre-authentication required From dpal at redhat.com Thu Jan 3 00:07:21 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 02 Jan 2013 19:07:21 -0500 Subject: [Freeipa-users] User's Cannot Reset Expire Passwords Without Password Being Reset First in WebUI In-Reply-To: <20130102224740.GD1284@mobility.troy.dr.local> References: <20130102224740.GD1284@mobility.troy.dr.local> Message-ID: <50E4CBB9.5070400@redhat.com> On 01/02/2013 05:47 PM, Chris Natter wrote: > Hello, > > My users are running into a bit of a problem with password expiry and > the reset prompts. > > When they attempt to reset their password they end up recieving access > denied messages after going through the prompts to reset their password > and entering their new desired passwords. > > The interesting thing is that if I reset the password via the Web UI to anything, > and then have the user try again with the new password, they are able to > successfully reset their password with no issues. > > Log snippets are below, I've sanitized them so the user in question is 'juser'. > > Any help or guidance would be very appreciated. Thank you! > > sshd[26945]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.20.1.108 user=juser > sshd[26945]: pam_sss(sshd:auth): system info: [Password has expired] > sshd[26945]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.20.1.108 user=juser > sshd[26945]: pam_sss(sshd:auth): received for user juser: 12 (Authentication token is no longer valid; new one required) > sshd[26945]: pam_sss(sshd:account): User info message: Password expired. Change your password now. > sshd[26945]: pam_unix(sshd:chauthtok): user "juser" does not exist in /etc/passwd > sshd[26945]: pam_unix(sshd:chauthtok): user "juser" does not exist in /etc/passwd > sshd[26945]: pam_sss(sshd:chauthtok): system info: [Generic error (see e-text)] > sshd[26945]: pam_sss(sshd:chauthtok): User info message: Password change failed. Server message: Password change rejected > sshd[26945]: pam_sss(sshd:chauthtok): Password change failed for user juser: 20 (Authentication token manipulation error) > sshd[26977]: pam_unix(sshd:auth): conversation failed > sshd[26977]: pam_unix(sshd:auth): auth could not identify password for [juser] > sshd[26977]: pam_sss(sshd:auth): system info: [Cannot read password] > sshd[26977]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.22.1.108 user=juser > sshd[26977]: pam_sss(sshd:auth): received for user juser: 4 (System error) > sshd[26977]: error: ssh_msg_send: write > > [[sssd[krb5_child[26452]]]] [validate_tgt] (5): TGT verified using key for [host/devbox3.lnx.foo.local at LNX.FOO.LOCAL]. > [[sssd[krb5_child[26949]]]] [krb5_child_setup] (7): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > [[sssd[krb5_child[26949]]]] [krb5_child_setup] (7): Cannot read [SSSD_KRB5_LIFETIME] from environment. > [[sssd[krb5_child[26949]]]] [sss_krb5_get_init_creds_opt_set_expire_callback] (5): krb5_get_init_creds_opt_set_expire_callback not available. > [[sssd[krb5_child[26949]]]] [get_and_save_tgt] (1): 721: [-1765328361][Password has expired] > [[sssd[krb5_child[26949]]]] [sss_krb5_get_init_creds_opt_set_expire_callback] (5): krb5_get_init_creds_opt_set_expire_callback not available. > [[sssd[krb5_child[26949]]]] [tgt_req_child] (1): 980: [-1765328361][Password has expired] > [[sssd[krb5_child[26958]]]] [krb5_child_setup] (7): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > [[sssd[krb5_child[26958]]]] [krb5_child_setup] (7): Cannot read [SSSD_KRB5_LIFETIME] from environment. > [[sssd[krb5_child[26976]]]] [krb5_child_setup] (7): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > [[sssd[krb5_child[26976]]]] [krb5_child_setup] (7): Cannot read [SSSD_KRB5_LIFETIME] from environment. > [[sssd[krb5_child[26976]]]] [changepw_child] (1): krb5_change_password failed [4][Password change rejected]. > > krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: CLIENT KEY EXPIRED: juser at LNX.FOO.LOCAL for krbtgt/LNX.FOO.LOCAL at LNX.FOO.LOCAL, Password has expired > krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: NEEDED_PREAUTH: juser at LNX.FOO.LOCAL for kadmin/changepw at LNX.FOO.LOCAL, Additional pre-authentication required > krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: ISSUE: authtime 1357163914, etypes {rep=18 tkt=18 ses=18}, juser at LNX.FOO.LOCAL for kadmin/changepw at LNX.FOO.LOCAL > krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: NEEDED_PREAUTH: juser at LNX.FOO.LOCAL for kadmin/changepw at LNX.FOO.LOCAL, Additional pre-authentication required > krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: ISSUE: authtime 1357163921, etypes {rep=18 tkt=18 ses=18}, juser at LNX.FOO.LOCAL for kadmin/changepw at LNX.FOO.LOCAL > krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: NEEDED_PREAUTH: juser at LNX.FOO.LOCAL for kadmin/changepw at LNX.FOO.LOCAL, Additional pre-authentication required > krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: ISSUE: authtime 1357163949, etypes {rep=18 tkt=18 ses=18}, juser at LNX.FOO.LOCAL for kadmin/changepw at LNX.FOO.LOCAL > krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: CLIENT KEY EXPIRED: juser at LNX.FOO.LOCAL for krbtgt/LNX.FOO.LOCAL at LNX.FOO.LOCAL, Password has expired > krb5kdc[9594](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.120.100.100: NEEDED_PREAUTH: juser at LNX.FOO.LOCAL for kadmin/changepw at LNX.FOO.LOCAL, Additional pre-authentication required What version are we talking about? Look at the KDC side logs they might shed some light. Do you have any special password policies configured (length, complexity, did it change) ? Does it happen for all users of just a subset? > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ From dale at themacartneyclan.com Thu Jan 3 01:18:48 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Thu, 03 Jan 2013 01:18:48 +0000 Subject: [Freeipa-users] Fedora 18 + FreeIPA 3.1 In-Reply-To: <50E3825A.1020806@redhat.com> References: <50DF1A64.90702@themacartneyclan.com> <50DF38AE.8040307@redhat.com> <50DF401C.7020401@themacartneyclan.com> <50E3744E.10207@redhat.com> <50E3800C.4090900@themacartneyclan.com> <50E3825A.1020806@redhat.com> Message-ID: <50E4DC78.2070601@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/02/2013 12:42 AM, Rob Crittenden wrote: > Dale Macartney wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> On 01/01/2013 11:42 PM, Rob Crittenden wrote: >>> Dale Macartney wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> >>>> On 12/29/2012 06:38 PM, Rob Crittenden wrote: >>>>> Dale Macartney wrote: >>>>>> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Afternoon all >>>>>> >>>>>> using Fedora 18 Beta and attempting to install FreeIPA 3.1 >>>>>> >>>>>> when running through the install of "ipa-server-install --setup-dns" I >>>>>> end up with a failure with the below output >>>>>> >>>>>> >>>>>> [root at ds01 ~]# ipa-server-install --setup-dns >>>>>> ..... >>>>>> ..... >>>>>> Done configuring directory server (dirsrv). >>>>>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes >>>>>> 30 seconds >>>>>> [1/20]: creating certificate server user >>>>>> [2/20]: configuring certificate server instance >>>>>> [3/20]: disabling nonces >>>>>> [4/20]: creating RA agent certificate database >>>>>> [5/20]: importing CA chain to RA certificate database >>>>>> [6/20]: fixing RA database permissions >>>>>> [7/20]: setting up signing cert profile >>>>>> [8/20]: set up CRL publishing >>>>>> [9/20]: set certificate subject base >>>>>> [10/20]: enabling Subject Key Identifier >>>>>> [11/20]: enabling CRL and OCSP extensions for certificates >>>>>> [12/20]: setting audit signing renewal to 2 years >>>>>> [13/20]: configuring certificate server to start on boot >>>>>> [14/20]: restarting certificate server >>>>>> [15/20]: requesting RA certificate from CA >>>>>> [16/20]: issuing RA agent certificate >>>>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>>>> CalledProcessError: Command '/usr/bin/sslget -v -n ipa-ca-agent -p >>>>>> XXXXXXXX -d /tmp/tmp-kUFAyN -r /ca/agent/ca/profileReview?requestId=7 >>>>>> ds01.domain.com:8443' returned non-zero exit status 6 >>>>>> >>>>>> >>>>>> there is absolutely nothing in any logs at all apart from a few selinux >>>>>> audit logs (system running in permissive mode). >>>>>> >>>>>> Any thoughts? >>>>> >>>>> This usually means a problem with DNS. >>>> Hmm... normally I set a dns forwarder of 10.0.0.254... This time I tried >>>> it with no forwarder at all... Same error occurs... >>> >>> Not really sure. The errors out of sslget are not particularly helpful. >>> >>> I'd check /etc/hosts to be sure it is sane, and perhaps dig/host to be >> sure that the forward and reverse entries match up. >> that'll teach me for using non-kickstarted systems... >> >> error is caused by mis or unconfigured /etc/hosts > > It's hard to programmatically check for some things but I was pretty sure we did some /etc/hosts sanity checking. What was the problem, and I guess more importantly, is it something we can/should check for prior to starting the install? so.. i've just deployed a new guest to test it.. with no entries in /etc/hosts with the exception of localhost... the below appears as part of the ipa-server-install process.. (i am using "ipa-server-install --setup-dns) Server host name [ds01.domain.com]: Warning: skipping DNS resolution of host ds01.domain.com The domain name has been determined based on the host name. Please confirm the domain name [domain.com]: The server hostname resolves to more than one address: fe80::21a:4aff:fe00:a8%eth0 10.0.3.11 Please provide the IP address to be used for this host name: 10.0.3.11 The kerberos protocol requires a Realm name to be defined. This is typically the domain name converted to uppercase. Please provide a realm name [DOMAIN.COM]: If I configure the host details in /etc/hosts.... (10.0.3.11 ds01.domain.com ds01), then the above selection process is not prompted.... so in short.... no hosts file config = no can has IPA install... is the above selection process meant to be configuring /etc/hosts by any chance? > > thanks > > rob > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ5Nx2AAoJEAJsWS61tB+qgFEQAKzL0V/Se3ci5+CUoExsYx2k 5z393OC734hhtkbxY+35BNjcjICfZGn49KHtevfA2DuZLIsyG1PvhynwZidr67Ci BX72Ye1JcAhxD0iMOncO3mC6aCODfdva12kDCxUQXbGt8WOcSHQtinuSsx9oYyjM HaMRxuGdzNcDVNRTOMRfwHWgZJwf6N7iM47pP3BPw4yCbCi+lBGaot43EQgVUVWS ZWrZhZ2y8m+Bz9lMSk/0M1HZtwYCLgMmg+DcNHr3z0wjdaW5NEX9eRPbuPdx6DiI BVl4s2Z4JBue8AurcNth0XD0uAynG62hsTNIxU5xL4n9chILaV7xz9bZ6epdWnWv UAM1zwkDj/yyWAucIQGSu3IC96gCfopxWBlFNMveRP1IDt71iqada99J+T0/FQaL aFy3e7rzIn8PpNu92Xh9kR5TcBKow+bLj5Q4YBwkI+SXNIxhpKk7EPbThc1siZfq heZQPPFUuAV8omYGJY7jwF0XJv1MWfAhv/V62Jn2+OuV457o5qNrA59hHmI+S8d0 7JbQI06KcBZqI9Kmo9bc1FdxLbYM450m1eK7aYCIPlMvZ7mIGefhVnfcM9IdxPm/ 1RpIVUgqu2VOR9ir7WBffCXul/awwl+f6RYzpsYQwK8YOgG0sdUKt28aeI/89+14 KOQiJm5E5rCDv8Ywx62P =1l7O -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc Type: application/pgp-keys Size: 8187 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xB5B41FAA.asc.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From hboetes at gmail.com Thu Jan 3 09:37:37 2013 From: hboetes at gmail.com (Han Boetes) Date: Thu, 3 Jan 2013 10:37:37 +0100 Subject: [Freeipa-users] gotcha for windows hosts: hostnames should not exceed 15 chars Message-ID: Perhaps it's worth mentioning that hostnames for windows client can not exceed 15 chars on this page. http://freeipa.org/page/Windows_authentication_against_FreeIPA I ran into it and it costed me a day trying to fix it. I had to reinstall my test machine to make it work properly. # Han -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Jan 3 11:28:00 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jan 2013 12:28:00 +0100 Subject: [Freeipa-users] AD permissions needed for setting up AD trusts In-Reply-To: <20121221121928.GB22856@localhost.localdomain> References: <20121221113033.41120@gmx.com> <20121221121928.GB22856@localhost.localdomain> Message-ID: <50E56B40.8070309@redhat.com> On 12/21/2012 01:19 PM, Sumit Bose wrote: > On Fri, Dec 21, 2012 at 12:30:33PM +0100, James Findley wrote: >> Hi >> >> What permission level is needed for the AD user when creating an AD trust? Can a regular domain user account do it, or is a domain admin needed? > > The account used here must be a member of the Domain Admins group. > >> >> If write access to the AD server is needed, then could someone please tell me what the command will actually change in the AD server? >> > > 'ipa trust-add' will only use LSA calls on the AD server. The most > important one is CreateTrustedDomainEx2 > (http://msdn.microsoft.com/en-us/library/cc234380.aspx) to create the > trust between the two domains. Additionally QueryTrustedDomainInfoByName > (http://msdn.microsoft.com/en-us/library/cc234376.aspx) to check if the > trust is already added and SetInformationTrustedDomain > (http://msdn.microsoft.com/en-us/library/cc234385.aspx) to tell the AD > server that the IPA server can handled AES encryption are used. Should we add this information to AD trusts documentation? >> The windows team at my place of work will want to know exactly what the tool will do before they grant permission. -- Petr^2 Spacek From pspacek at redhat.com Thu Jan 3 11:31:40 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jan 2013 12:31:40 +0100 Subject: [Freeipa-users] Fwd: user sync works, passsync eludes me In-Reply-To: References: Message-ID: <50E56C1C.1070209@redhat.com> Hello, can you please open a bug against passsync and describe what exactly you did? Log message should clearly mention problem with certificate when it happens. Thank you. Petr^2 Spacek On 12/21/2012 03:41 PM, Nate Marks wrote: > Nevermind. I was mucking up the certificate. got it fixed. > > ---------- Forwarded message ---------- > From: *Nate Marks* > > Date: Fri, Dec 21, 2012 at 6:36 AM > Subject: user sync works, passsync eludes me > To: freeipa-users at redhat.com > > > Here's what the log says: > > LDAP bind error in connect > 81: Can't contact LDAP server > Can not connect to ldap server in SyncPasswords > > > I keep changing the passsync config values by re-running the msi with the > modify option. I'm not sure if that's the way to do this, but my current > options are: > > hostname: IPA server FQDN. it seems to resolve fine > port number: 636 > username: (i checked this in > ldap:uid=passsync,cn=sysaccounts,cn=etc,dc=,dc= > password: matches the one set in ipa-replica-manage connect --passsync option > certtoken: string copied from the IPA server > (/etc/dirsrv/slapd-/pwdfile.txt) > search base : same as win-subtree value > > > so close, but stuck. thanks in advance for any help ! > > nate From pspacek at redhat.com Thu Jan 3 11:57:57 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jan 2013 12:57:57 +0100 Subject: [Freeipa-users] Kerberos and Cisco In-Reply-To: <1356287494.2894.154.camel@willson.li.ssimo.org> References: <50D4EF60.6090409@redhat.com> <1356287494.2894.154.camel@willson.li.ssimo.org> Message-ID: <50E57245.7060909@redhat.com> On 12/23/2012 07:31 PM, Simo Sorce wrote: > On Fri, 2012-12-21 at 18:23 -0500, Dmitri Pal wrote: >> On 12/21/2012 05:40 PM, Mike Mercier wrote: >>> Hi Bret, >>> >>> >>> I tried this once in the past with no success. If I recall >>> correctly (I can't find the reference anymore), Cisco (at least in >>> IOS 12.4 that I tested) only supports the DES-CBC-CRC enctype. This >>> enctype disabled by default in FreeIPA. >> >> allow_weak_crypto = true >> >> in krb5.conf to enable it. > > These instructions are relevant only for a Linux based client. > > Bret, > on top of changing the above on the server and restarting it, > you need to add DES as an allowed enctype in the IPA server LDAP > attribute that controls it(*) as well as explicitly specify you want a > DES key when you use ipa-getkeytab to get a keytab for you device. > > > (*) This attribute is called krbSupportedEncSaltTypes and is stored in > cn=,cn=kerberos,cn= in your LDAP server. > > You probably want to add the value: des-cbc-crc:normal I would add: DES + CRC is considered insecure, weight it in your use case carefully. -- Petr^2 Spacek From simo at redhat.com Thu Jan 3 15:31:46 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 03 Jan 2013 10:31:46 -0500 Subject: [Freeipa-users] User's Cannot Reset Expire Passwords Without Password Being Reset First in WebUI In-Reply-To: <20130102224740.GD1284@mobility.troy.dr.local> References: <20130102224740.GD1284@mobility.troy.dr.local> Message-ID: <1357227106.2894.269.camel@willson.li.ssimo.org> On Wed, 2013-01-02 at 17:47 -0500, Chris Natter wrote: > Hello, > > My users are running into a bit of a problem with password expiry and > the reset prompts. > > When they attempt to reset their password they end up recieving access > denied messages after going through the prompts to reset their > password > and entering their new desired passwords. > > The interesting thing is that if I reset the password via the Web UI > to anything, > and then have the user try again with the new password, they are able > to > successfully reset their password with no issues. > > Log snippets are below, I've sanitized them so the user in question is > 'juser'. > > Any help or guidance would be very appreciated. Thank you! > > They are probably failing to meet password policies but sshd is not using pam conversations. Set ChallengeResponseAuthentication yes in sshd_config, this should allow conversations and proper errors to show up. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Jan 3 15:36:10 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 03 Jan 2013 10:36:10 -0500 Subject: [Freeipa-users] gotcha for windows hosts: hostnames should not exceed 15 chars In-Reply-To: References: Message-ID: <1357227370.2894.270.camel@willson.li.ssimo.org> On Thu, 2013-01-03 at 10:37 +0100, Han Boetes wrote: > Perhaps it's worth mentioning that hostnames for windows client can > not exceed 15 chars on this page. > > > http://freeipa.org/page/Windows_authentication_against_FreeIPA > > > > I ran into it and it costed me a day trying to fix it. I had to > reinstall my test machine to make it work properly. > Thanks a lot, I added a note to the page. Simo. -- Simo Sorce * Red Hat, Inc * New York From Johan.Petersson at sscspace.com Fri Jan 4 10:27:40 2013 From: Johan.Petersson at sscspace.com (Johan Petersson) Date: Fri, 4 Jan 2013 10:27:40 +0000 Subject: [Freeipa-users] Does Solaris 11 work as client to IPA server? In-Reply-To: <50D9CBC6.7080907@redhat.com> References: <558C15177F5E714F83334217C9A197DF5DB4175B@SSC-MBX2.ssc.internal> <20801.213.225.75.97.1355821569.squirrel@www.nixtra.com>, <50D09ED3.3030102@redhat.com> <558C15177F5E714F83334217C9A197DF5DB82294@SSC-MBX2.ssc.internal>, <51748.188.244.64.7.1355994836.squirrel@www.nixtra.com> <558C15177F5E714F83334217C9A197DF5DB822D5@SSC-MBX2.ssc.internal>, <55800.188.244.64.7.1356013244.squirrel@www.nixtra.com>, <558C15177F5E714F83334217C9A197DF5DB8231A@SSC-MBX2.ssc.internal> <558C15177F5E714F83334217C9A197DF5DB8234C@SSC-MBX2.ssc.internal>, <50D4E50A.3060109@redhat.com>, <558C15177F5E714F83334217C9A197DF5DB8241D@SSC-MBX2.ssc.internal> <558C15177F5E714F83334217C9A197DF5DB82483@SSC-MBX2.ssc.internal>, <50D9CBC6.7080907@redhat.com> Message-ID: <558C15177F5E714F83334217C9A197DF5DB83674@SSC-MBX2.ssc.internal> Hi, Here is the instructions for a IPA Server Solaris 11 client configuration with secure bind and a custom DUAProfile. Everything works as far as i have been able to test. Console login works, su - and ssh. Configuration done on the IPA Server. Create a DUAConfigProfile solaris_authssl.ldif dn: cn=solaris_authssl,ou=profile,dc=example,dc=com objectClass: top objectClass: DUAConfigProfile cn: solaris_authssl authenticationMethod: tls:simple bindTimeLimit: 5 credentialLevel: proxy defaultSearchBase: dc=example,dc=com defaultSearchScope: one defaultServerList: ipaserver.example.com followReferrals: TRUE objectclassMap: shadow:shadowAccount=posixAccount objectclassMap: printers:sunPrinter=printerService profileTTL: 6000 searchTimeLimit: 10 serviceSearchDescriptor: passwd:cn=users,cn=accounts,dc=example,dc=com serviceSearchDescriptor: group:cn=groups,cn=compat,dc=example,dc=com serviceSearchDescriptor: netgroup:cn=ng,cn=compat,dc=example,dc=com serviceSearchDescriptor: ethers:cn=computers,cn=accounts,dc=example,dc=com serviceSearchDescriptor: automount:cn=default,cn=automount,dc=example,dc=com serviceSearchDescriptor:auto_master:automountMapName=auto.master,cn=default,cn=automount,dc=example,dc=com Add the ldif to ipaserver: ldapadd -h ipaserver.example.com -x -W -D "cn=Directory Manager" -vvv -f solaris_authssl.ldif Create an account to use for authentication: ldapmodify -a -h ipaserver.example.com -D "cn=Directory Manager" -W dn: uid=solaris,cn=sysaccounts,cn=etc,dc=example,dc=com objectClass: account objectClass: simpleSecurityObject objectClass: top uid: solaris userPassword: setyourpasswordhere ipa host-add --force --ip-address=192.168.0.1 solaris.example.com ipa host-add-managedby --host ipaserver.example.com solaris.example.com ipa-getkeytab -s ipaserver.example.com -p host/solaris.example.com -k /tmp/solaris.keytab Make sure that the automount maps in ipaserver is named auto_* and NOT auto.* so they are compatible with Solaris name standards. certutil -N -d . openssl x509 -in /etc/ipa/ca.crt -outform pem -out /etc/ipa/ca.pem certutil -A -n "ca-cert" -i /etc/ipa/ca.pem -a -t CT -d /(directory of generated cert8.db and key3.db) scp the keytab to the solaris host /etc/krb5/krb5.keytab and scp the *.db to the solaris host /var/ldap/ Solaris host configuration: Make sure to secure the krb5.keytab properly. chown root:sys krb5.keytab chmod 600 krb5.keytab Secure the *.db files created by certutil on IPA Server earlier. chown root:staff /var/ldap/*.db chmod 444 /var/ldap/*.db Edit /etc/nsswitch.ldap, replace "ldap" with "dns" from the "hosts" and "ipnodes" lines: hosts: files dns ipnodes: files dns ldapclient -v init \ -a profileName=solaris_authssl \ -a domainName=example.com \ -a proxyDN="uid=solaris,cn=sysaccounts,cn=etc,dc=example,dc=com" \ -a proxyPassword="setyourpasswordhere" \ -D uid=solaris,cn=sysaccounts,cn=etc,dc=example,dc=com \ -w yourpasswordagain \ ipaserver.example.com Enable ntp client: Add serverlist to /etc/inet/ntp.client and rename it to ntp.conf Example: server ipaserver.example.com iburst svcadm restart ntp To see it is running properly: svcs ntp To see what servers you are using: ntpq -p Edit /etc/krb5/krb5.conf: krb5.conf: [libdefaults] default_realm = EXAMPLE.COM verify_ap_req_nofail = false [realms] EXAMPLE.COM = { kdc = ipaserver.example.com admin_server = ipaserver.example.com [domain_realm] example.com = EXAMPLE.COM .example.com = EXAMPLE.COM Pam configuration changed slightly in Solaris 11.1. It is still possible to use /etc/pam.conf as before if preferable. Pam configuration in /etc/pam.d/ login: login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 try_first_pass login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1 other: auth definitive pam_user_policy.so.1 auth requisite pam_authtok_get.so.1 auth required pam_dhkeys.so.1 auth required pam_unix_cred.so.1 auth sufficient pam_krb5.so.1 auth required pam_unix_auth.so.1 account requisite pam_roles.so.1 account definitive pam_user_policy.so.1 account required pam_unix_account.so.1 account required pam_krb5.so.1 account required pam_tsol_account.so.1 password include pam_authtok_common password sufficient pam_krb5.so.1 password required pam_authtok_store.so.1 For NFS: /etc/nfssec.conf enable these: krb5 390003 kerberos_v5 default - # RPCSEC_GSS krb5i 390004 kerberos_v5 default integrity # RPCSEC_GSS krb5p 390005 kerberos_v5 default privacy # RPCSEC_GSS Do not forget to set nfsmapid_domain to your domain to avoid nobody:nobody permission issues with NFS. sharectl set -p nfsmapid_domain=home nfs To see if it is properly set: sharectl get nfs Regards, Johan. ________________________________________ From: Dmitri Pal [dpal at redhat.com] Sent: Tuesday, December 25, 2012 16:52 To: Johan Petersson Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Does Solaris 11 work as client to IPA server? On 12/24/2012 05:27 PM, Johan Petersson wrote: > Here is a step by step instruction for a Solaris 11 machine as client to a IPA server based on the default DUAProfile. > Console login works, su - and ssh. > Home directories automounted have the correct permissions. > The automount does not use wildcards since i had issues of the whole /home being grabbed by autofs and thus making local users home directories unavalable. > This can probably be solved by someone with more extensive experience of Solaris autofs. > I am working on a instruction based on Sigbjorn Lie's DUAProfile and added security and will post it too shortly. > > First make sure that the Solaris 11 machine are using the proper DNS and NTP servers. > > On the IPA server or Client run: > > ipa host-add --force --ip-address=192.168.0.1 solaris.example.com > > ipa-getkeytab -s ipaserver.example.com -p host/solaris.example.com -k /tmp/solaris.keytab > > Move the keytab to the Solaris machine /etc/krb5/krb5.keytab > > Make sure it have the proper owner and permissions: > > chown root:sys /etc/krb5/krb5.keytab > chmod 700 /etc/krb5/krb5.keytab > > Edit /etc/nsswitch.ldap, replace "ldap" with "dns" from the "hosts" and "ipnodes" lines: > > hosts: files dns > ipnodes: files dns > > Edit /etc/krb5/krb5.conf: > > [libdefaults] > default_realm = EXAMPLE.COM > verify_ap_req_nofail = false > [realms] > EXAMPLE.COM = { > kdc = ipaserver.example.com > admin_server = ipaserver.example.com > } > > [domain_realm] > example.com = EXAMPLE.COM > .example.com = EXAMPLE.COM > > > Run the ldapclient with the default DUAProfile. > The -a domainName= example.com is needed so that ldapclient does not stop and complain about missing nisdomain name. > > ldapclient -v init -a profilename=default -a domainName=example.com ipaserver.example.com > > In Solaris 11.1 the pam configuration have changed but for simplicity i still use the /etc/pam.conf: > > login auth requisite pam_authtok_get.so.1 > login auth required pam_dhkeys.so.1 > login auth required pam_unix_cred.so.1 > login auth sufficient pam_krb5.so.1 try_first_pass > login auth required pam_unix_auth.so.1 > login auth required pam_dial_auth.so.1 > > other auth requisite pam_authtok_get.so.1 > other auth required pam_dhkeys.so.1 > other auth required pam_unix_cred.so.1 > other auth sufficient pam_krb5.so.1 > other auth required pam_unix_auth.so.1 > > other account requisite pam_roles.so.1 > other account required pam_unix_account.so.1 > other account required pam_krb5.so.1 > > other password requisite pam_authtok_check.so.1 force_check > other password sufficient pam_krb5.so.1 > other password required pam_authtok_store.so.1 > > For NFS and automount to work: > > In /etc/nfssec.conf enable these: > > krb5 390003 kerberos_v5 default - # RPCSEC_GSS > krb5i 390004 kerberos_v5 default integrity # RPCSEC_GSS > krb5p 390005 kerberos_v5 default privacy # RPCSEC_GSS > > sharectl set -p nfsmapid_domain=example.com nfs > > If autofs is not on: > > svcadm enable system/filesystem/autofs:default > > In /etc/auto_home: > > testuser ipaserver.example.com:/home/testuser Thank you! Dmitri From hboetes at gmail.com Fri Jan 4 13:31:33 2013 From: hboetes at gmail.com (Han Boetes) Date: Fri, 4 Jan 2013 14:31:33 +0100 Subject: [Freeipa-users] authentication with latest putty fails Message-ID: I've set up windows with the instructions given over here: http://freeipa.com/page/Windows_authentication_against_FreeIPA And all seems to be working fine. After I run klist I see valid tickets: Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten. C:\Users\fh>klist Aktuelle Anmelde-ID ist 0:0x153b25 Zwischengespeicherte Tickets: (1) #0> Client: fh @ REALM Server: krbtgt/REALM @ REALM KerbTicket (Verschl?sselungstyp): AES-256-CTS-HMAC-SHA1-96 Ticketkennzeichen 0x40e10000 -> forwardable renewable initial pre_authen t name_canonicalize Startzeit: 1/4/2013 14:03:11 (lokal) Endzeit: 1/5/2013 14:03:11 (lokal) Erneuerungszeit: 1/11/2013 14:03:11 (lokal) Sitzungsschl?sseltyp: AES-256-CTS-HMAC-SHA1-96 I can do a passwordless login with the latest putty with kerberos authentication, I disabled password and key logins. And then on the host I checked klist and got this: [fh at test-server-ipa ~]$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1554800011) sudo also doesn't work. To test the setup I did the same from linux host and login in, sudo, klist etc etc all work fine. So I checked the sshd -d output difference and the only difference I see is: -Postponed gssapi-with-mic for fh from 192.168.2.73 port 50334 ssh2 -debug1: Received some client credentials +Postponed gssapi-with-mic for fh from 192.168.2.56 port 49168 ssh2 +debug1: Got no client credentials Where .73 is the linux host and .56 is the windows host. What am I missing here? -- # Han -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Jan 4 14:58:29 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 04 Jan 2013 09:58:29 -0500 Subject: [Freeipa-users] authentication with latest putty fails In-Reply-To: References: Message-ID: <50E6EE15.1020908@redhat.com> Han Boetes wrote: > I've set up windows with the instructions given over here: > > http://freeipa.com/page/Windows_authentication_against_FreeIPA > > And all seems to be working fine. After I run klist I see valid tickets: > > Microsoft Windows [Version 6.1.7601] > Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten. > > C:\Users\fh>klist > > Aktuelle Anmelde-ID ist 0:0x153b25 > > Zwischengespeicherte Tickets: (1) > > #0> Client: fh @ REALM > Server: krbtgt/REALM @ REALM > KerbTicket (Verschl?sselungstyp): AES-256-CTS-HMAC-SHA1-96 > Ticketkennzeichen 0x40e10000 -> forwardable renewable initial > pre_authen > t name_canonicalize > Startzeit: 1/4/2013 14:03:11 (lokal) > Endzeit: 1/5/2013 14:03:11 (lokal) > Erneuerungszeit: 1/11/2013 14:03:11 (lokal) > Sitzungsschl?sseltyp: AES-256-CTS-HMAC-SHA1-96 > > > I can do a passwordless login with the latest putty with kerberos > authentication, I disabled password and key logins. And then on the > host I checked klist and got this: > > [fh at test-server-ipa ~]$ klist > klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1554800011) > > sudo also doesn't work. To test the setup I did the same from linux host > and login in, sudo, klist etc etc all work fine. So I checked the sshd > -d output difference and the only difference I see is: > > -Postponed gssapi-with-mic for fh from 192.168.2.73 port 50334 ssh2 > -debug1: Received some client credentials > +Postponed gssapi-with-mic for fh from 192.168.2.56 port 49168 ssh2 > +debug1: Got no client credentials > > Where .73 is the linux host and .56 is the windows host. > > What am I missing here? The problem isn't that authentication fails, it is that the credentials aren't forwarded, right? Does putty support this? rob From hboetes at gmail.com Fri Jan 4 15:14:36 2013 From: hboetes at gmail.com (Han Boetes) Date: Fri, 4 Jan 2013 16:14:36 +0100 Subject: [Freeipa-users] authentication with latest putty fails In-Reply-To: <50E6EE15.1020908@redhat.com> References: <50E6EE15.1020908@redhat.com> Message-ID: You are absolutely right; the credentials aren't forwarded. I have enabled the option "allow gssapi credential delegation". So one would expect that it should work. I just installed the mit kerberos tools and I can see all the options and forwarding tickets is allowed according to the interface. Also putty is now using the mit kerberos dll; gssapi32.dll and still I get the same results. So the proper question is: how do I get putty to really forward the credentials? On Fri, Jan 4, 2013 at 3:58 PM, Rob Crittenden wrote: > Han Boetes wrote: > >> I've set up windows with the instructions given over here: >> >> http://freeipa.com/page/**Windows_authentication_**against_FreeIPA >> >> And all seems to be working fine. After I run klist I see valid tickets: >> >> Microsoft Windows [Version 6.1.7601] >> Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten. >> >> C:\Users\fh>klist >> >> Aktuelle Anmelde-ID ist 0:0x153b25 >> >> Zwischengespeicherte Tickets: (1) >> >> #0> Client: fh @ REALM >> Server: krbtgt/REALM @ REALM >> KerbTicket (Verschl?sselungstyp): AES-256-CTS-HMAC-SHA1-96 >> Ticketkennzeichen 0x40e10000 -> forwardable renewable initial >> pre_authen >> t name_canonicalize >> Startzeit: 1/4/2013 14:03:11 (lokal) >> Endzeit: 1/5/2013 14:03:11 (lokal) >> Erneuerungszeit: 1/11/2013 14:03:11 (lokal) >> Sitzungsschl?sseltyp: AES-256-CTS-HMAC-SHA1-96 >> >> >> I can do a passwordless login with the latest putty with kerberos >> authentication, I disabled password and key logins. And then on the >> host I checked klist and got this: >> >> [fh at test-server-ipa ~]$ klist >> klist: No credentials cache found (ticket cache >> FILE:/tmp/krb5cc_1554800011) >> >> sudo also doesn't work. To test the setup I did the same from linux host >> and login in, sudo, klist etc etc all work fine. So I checked the sshd >> -d output difference and the only difference I see is: >> >> -Postponed gssapi-with-mic for fh from 192.168.2.73 port 50334 ssh2 >> -debug1: Received some client credentials >> +Postponed gssapi-with-mic for fh from 192.168.2.56 port 49168 ssh2 >> +debug1: Got no client credentials >> >> Where .73 is the linux host and .56 is the windows host. >> >> What am I missing here? >> > > The problem isn't that authentication fails, it is that the credentials > aren't forwarded, right? > > Does putty support this? > > rob > > -- # Han -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Fri Jan 4 15:25:46 2013 From: sbose at redhat.com (Sumit Bose) Date: Fri, 4 Jan 2013 16:25:46 +0100 Subject: [Freeipa-users] authentication with latest putty fails In-Reply-To: References: <50E6EE15.1020908@redhat.com> Message-ID: <20130104152546.GB2210@localhost.localdomain> On Fri, Jan 04, 2013 at 04:14:36PM +0100, Han Boetes wrote: > You are absolutely right; the credentials aren't forwarded. > > I have enabled the option "allow gssapi credential delegation". So one > would expect that it should work. > > I just installed the mit kerberos tools and I can see all the options and > forwarding tickets is allowed according to the interface. Also putty is now > using the mit kerberos dll; gssapi32.dll and still I get the same results. > > So the proper question is: how do I get putty to really forward the > credentials? This might be an issue with your putty version. Can you try Quest's version of putty http://rc.quest.com/topics/putty/ , if you are not already using it? HTH bye, Sumit > > > On Fri, Jan 4, 2013 at 3:58 PM, Rob Crittenden wrote: > > > Han Boetes wrote: > > > >> I've set up windows with the instructions given over here: > >> > >> http://freeipa.com/page/**Windows_authentication_**against_FreeIPA > >> > >> And all seems to be working fine. After I run klist I see valid tickets: > >> > >> Microsoft Windows [Version 6.1.7601] > >> Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten. > >> > >> C:\Users\fh>klist > >> > >> Aktuelle Anmelde-ID ist 0:0x153b25 > >> > >> Zwischengespeicherte Tickets: (1) > >> > >> #0> Client: fh @ REALM > >> Server: krbtgt/REALM @ REALM > >> KerbTicket (Verschl?sselungstyp): AES-256-CTS-HMAC-SHA1-96 > >> Ticketkennzeichen 0x40e10000 -> forwardable renewable initial > >> pre_authen > >> t name_canonicalize > >> Startzeit: 1/4/2013 14:03:11 (lokal) > >> Endzeit: 1/5/2013 14:03:11 (lokal) > >> Erneuerungszeit: 1/11/2013 14:03:11 (lokal) > >> Sitzungsschl?sseltyp: AES-256-CTS-HMAC-SHA1-96 > >> > >> > >> I can do a passwordless login with the latest putty with kerberos > >> authentication, I disabled password and key logins. And then on the > >> host I checked klist and got this: > >> > >> [fh at test-server-ipa ~]$ klist > >> klist: No credentials cache found (ticket cache > >> FILE:/tmp/krb5cc_1554800011) > >> > >> sudo also doesn't work. To test the setup I did the same from linux host > >> and login in, sudo, klist etc etc all work fine. So I checked the sshd > >> -d output difference and the only difference I see is: > >> > >> -Postponed gssapi-with-mic for fh from 192.168.2.73 port 50334 ssh2 > >> -debug1: Received some client credentials > >> +Postponed gssapi-with-mic for fh from 192.168.2.56 port 49168 ssh2 > >> +debug1: Got no client credentials > >> > >> Where .73 is the linux host and .56 is the windows host. > >> > >> What am I missing here? > >> > > > > The problem isn't that authentication fails, it is that the credentials > > aren't forwarded, right? > > > > Does putty support this? > > > > rob > > > > > > > -- > > > > # Han > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From hboetes at gmail.com Fri Jan 4 15:56:18 2013 From: hboetes at gmail.com (Han Boetes) Date: Fri, 4 Jan 2013 16:56:18 +0100 Subject: [Freeipa-users] authentication with latest putty fails In-Reply-To: <20130104152546.GB2210@localhost.localdomain> References: <50E6EE15.1020908@redhat.com> <20130104152546.GB2210@localhost.localdomain> Message-ID: Your information about the quest putty version seems to be outdated. ;-) Quest Softare no longer maintains recent releases of PuTTY. To obtain the latest stable release of PuTTY please goto PuTTY Download Page * The functionality that was provided by Quest Software's PuTTY packages have now been included in the latest releases of PuTTY, making Quest PuTTY obsolete. I'm testdriving the centrify version at the moment and... ~/debug% cat ~/out Using Kerberos authentication Using principal fh at REALM Got host ticket host/test-server-ipa.domain at REALM login as fh at REALM Kerberos authentication failed. Please check 1) Unix login name is correct 2) Target service principal name is correct 3) Kerberos authentication is enabled in SSH server 4) Clock in the host is syncrhonized with the clock in AD fh at REALM@test-server-ipa's password: Last login: Fri Jan 4 14:51:25 2013 from ipa-w7.domain [fh at test-server-ipa ~]$ klist Ticket cache: FILE:/tmp/krb5cc_1554800011_JDgpIu5465 Default principal: fh at REALM Valid starting Expires Service principal 01/04/13 14:52:49 01/05/13 14:52:49 krbtgt/REALM at REALM [fh at test-server-ipa ~]$ That's does provide a valid ticket but not a passwordless login. Actually I have to enter a pass twice here! On Fri, Jan 4, 2013 at 4:25 PM, Sumit Bose wrote: > On Fri, Jan 04, 2013 at 04:14:36PM +0100, Han Boetes wrote: > > You are absolutely right; the credentials aren't forwarded. > > > > I have enabled the option "allow gssapi credential delegation". So one > > would expect that it should work. > > > > I just installed the mit kerberos tools and I can see all the options and > > forwarding tickets is allowed according to the interface. Also putty is > now > > using the mit kerberos dll; gssapi32.dll and still I get the same > results. > > > > So the proper question is: how do I get putty to really forward the > > credentials? > > This might be an issue with your putty version. Can you try Quest's > version of putty http://rc.quest.com/topics/putty/ , if you are not > already using it? > > HTH > > bye, > Sumit > > > > > > > On Fri, Jan 4, 2013 at 3:58 PM, Rob Crittenden > wrote: > > > > > Han Boetes wrote: > > > > > >> I've set up windows with the instructions given over here: > > >> > > >> http://freeipa.com/page/**Windows_authentication_**against_FreeIPA< > http://freeipa.com/page/Windows_authentication_against_FreeIPA> > > >> > > >> And all seems to be working fine. After I run klist I see valid > tickets: > > >> > > >> Microsoft Windows [Version 6.1.7601] > > >> Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten. > > >> > > >> C:\Users\fh>klist > > >> > > >> Aktuelle Anmelde-ID ist 0:0x153b25 > > >> > > >> Zwischengespeicherte Tickets: (1) > > >> > > >> #0> Client: fh @ REALM > > >> Server: krbtgt/REALM @ REALM > > >> KerbTicket (Verschl?sselungstyp): AES-256-CTS-HMAC-SHA1-96 > > >> Ticketkennzeichen 0x40e10000 -> forwardable renewable initial > > >> pre_authen > > >> t name_canonicalize > > >> Startzeit: 1/4/2013 14:03:11 (lokal) > > >> Endzeit: 1/5/2013 14:03:11 (lokal) > > >> Erneuerungszeit: 1/11/2013 14:03:11 (lokal) > > >> Sitzungsschl?sseltyp: AES-256-CTS-HMAC-SHA1-96 > > >> > > >> > > >> I can do a passwordless login with the latest putty with kerberos > > >> authentication, I disabled password and key logins. And then on the > > >> host I checked klist and got this: > > >> > > >> [fh at test-server-ipa ~]$ klist > > >> klist: No credentials cache found (ticket cache > > >> FILE:/tmp/krb5cc_1554800011) > > >> > > >> sudo also doesn't work. To test the setup I did the same from linux > host > > >> and login in, sudo, klist etc etc all work fine. So I checked the sshd > > >> -d output difference and the only difference I see is: > > >> > > >> -Postponed gssapi-with-mic for fh from 192.168.2.73 port 50334 ssh2 > > >> -debug1: Received some client credentials > > >> +Postponed gssapi-with-mic for fh from 192.168.2.56 port 49168 ssh2 > > >> +debug1: Got no client credentials > > >> > > >> Where .73 is the linux host and .56 is the windows host. > > >> > > >> What am I missing here? > > >> > > > > > > The problem isn't that authentication fails, it is that the credentials > > > aren't forwarded, right? > > > > > > Does putty support this? > > > > > > rob > > > > > > > > > > > > -- > > > > > > > > # Han > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- # Han -------------- next part -------------- An HTML attachment was scrubbed... URL: From erinn.looneytriggs at gmail.com Fri Jan 4 17:25:53 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Fri, 04 Jan 2013 08:25:53 -0900 Subject: [Freeipa-users] authentication with latest putty fails In-Reply-To: References: <50E6EE15.1020908@redhat.com> <20130104152546.GB2210@localhost.localdomain> Message-ID: <50E710A1.40308@gmail.com> On 01/04/13 06:56, Han Boetes wrote: > Your information about the quest putty version seems to be outdated. ;-) > > Quest Softare no longer maintains recent releases of PuTTY. To obtain > the latest stable release of PuTTY please goto PuTTY Download Page > * The functionality that was provided by Quest Software's PuTTY packages > have now been included in the latest releases of PuTTY, making Quest > PuTTY obsolete. > > > I'm testdriving the centrify version at the moment and... > > ~/debug% cat ~/out > Using Kerberos authentication > Using principal fh at REALM > Got host ticket host/test-server-ipa.domain at REALM > login as fh at REALM > > Kerberos authentication failed. Please check > 1) Unix login name is correct > 2) Target service principal name is correct > 3) Kerberos authentication is enabled in SSH server > 4) Clock in the host is syncrhonized with the clock in AD > > fh at REALM@test-server-ipa's password: > Last login: Fri Jan 4 14:51:25 2013 from ipa-w7.domain > [fh at test-server-ipa ~]$ klist > Ticket cache: FILE:/tmp/krb5cc_1554800011_JDgpIu5465 > Default principal: fh at REALM > > Valid starting Expires Service principal > 01/04/13 14:52:49 01/05/13 14:52:49 krbtgt/REALM at REALM > [fh at test-server-ipa ~]$ > > That's does provide a valid ticket but not a passwordless login. > Actually I have to enter a pass twice here! > > > > > > On Fri, Jan 4, 2013 at 4:25 PM, Sumit Bose > wrote: > > On Fri, Jan 04, 2013 at 04:14:36PM +0100, Han Boetes wrote: > > You are absolutely right; the credentials aren't forwarded. > > > > I have enabled the option "allow gssapi credential delegation". So one > > would expect that it should work. > > > > I just installed the mit kerberos tools and I can see all the > options and > > forwarding tickets is allowed according to the interface. Also > putty is now > > using the mit kerberos dll; gssapi32.dll and still I get the same > results. > > > > So the proper question is: how do I get putty to really forward the > > credentials? > > This might be an issue with your putty version. Can you try Quest's > version of putty http://rc.quest.com/topics/putty/ , if you are not > already using it? > > HTH > > bye, > Sumit > > > > > > > On Fri, Jan 4, 2013 at 3:58 PM, Rob Crittenden > > wrote: > > > > > Han Boetes wrote: > > > > > >> I've set up windows with the instructions given over here: > > >> > > >> > http://freeipa.com/page/**Windows_authentication_**against_FreeIPA > > >> > > >> And all seems to be working fine. After I run klist I see valid > tickets: > > >> > > >> Microsoft Windows [Version 6.1.7601] > > >> Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten. > > >> > > >> C:\Users\fh>klist > > >> > > >> Aktuelle Anmelde-ID ist 0:0x153b25 > > >> > > >> Zwischengespeicherte Tickets: (1) > > >> > > >> #0> Client: fh @ REALM > > >> Server: krbtgt/REALM @ REALM > > >> KerbTicket (Verschl?sselungstyp): AES-256-CTS-HMAC-SHA1-96 > > >> Ticketkennzeichen 0x40e10000 -> forwardable renewable > initial > > >> pre_authen > > >> t name_canonicalize > > >> Startzeit: 1/4/2013 14:03:11 (lokal) > > >> Endzeit: 1/5/2013 14:03:11 (lokal) > > >> Erneuerungszeit: 1/11/2013 14:03:11 (lokal) > > >> Sitzungsschl?sseltyp: AES-256-CTS-HMAC-SHA1-96 > > >> > > >> > > >> I can do a passwordless login with the latest putty with kerberos > > >> authentication, I disabled password and key logins. And then > on the > > >> host I checked klist and got this: > > >> > > >> [fh at test-server-ipa ~]$ klist > > >> klist: No credentials cache found (ticket cache > > >> FILE:/tmp/krb5cc_1554800011) > > >> > > >> sudo also doesn't work. To test the setup I did the same from > linux host > > >> and login in, sudo, klist etc etc all work fine. So I checked > the sshd > > >> -d output difference and the only difference I see is: > > >> > > >> -Postponed gssapi-with-mic for fh from 192.168.2.73 port 50334 ssh2 > > >> -debug1: Received some client credentials > > >> +Postponed gssapi-with-mic for fh from 192.168.2.56 port 49168 ssh2 > > >> +debug1: Got no client credentials > > >> > > >> Where .73 is the linux host and .56 is the windows host. > > >> > > >> What am I missing here? > > >> > > > > > > The problem isn't that authentication fails, it is that the > credentials > > > aren't forwarded, right? > > > > > > Does putty support this? > > > > > > rob > > > > > > > > > > > > -- > > > > > > > > # Han > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > > > > # Han > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > Just as a data point here, this can be done with the stock version of putty and windows 7 or 8 with MIT kerberos. I have been doing exactly this for a good while now, ever since the official puty integrated kerb support. However, I am not working with Windows right now so I can't give you any settings or pointers, all I can tell you is it can be done :). -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From sbose at redhat.com Fri Jan 4 17:52:45 2013 From: sbose at redhat.com (Sumit Bose) Date: Fri, 4 Jan 2013 18:52:45 +0100 Subject: [Freeipa-users] authentication with latest putty fails In-Reply-To: References: <50E6EE15.1020908@redhat.com> <20130104152546.GB2210@localhost.localdomain> Message-ID: <20130104175245.GE2210@localhost.localdomain> On Fri, Jan 04, 2013 at 04:56:18PM +0100, Han Boetes wrote: > Your information about the quest putty version seems to be outdated. ;-) > > Quest Softare no longer maintains recent releases of PuTTY. To obtain the > latest stable release of PuTTY please goto PuTTY Download Page > * The functionality that was provided by Quest Software's PuTTY packages > have now been included in the latest releases of PuTTY, making Quest PuTTY > obsolete. > > > I'm testdriving the centrify version at the moment and... I just downloaded Centrify's version of putty and it is working fine for me. About delegating credentials, you might need to set the ok_as_delegate flag on the host/* service ticket. To do this you can call kadmin.local on the IPA server and then use modprinc +ok_as_delegate host/test-server-ipa.realm at REALM to set the flag. bye, Sumit > > ~/debug% cat ~/out > Using Kerberos authentication > Using principal fh at REALM > Got host ticket host/test-server-ipa.domain at REALM > login as fh at REALM > > Kerberos authentication failed. Please check > 1) Unix login name is correct > 2) Target service principal name is correct > 3) Kerberos authentication is enabled in SSH server > 4) Clock in the host is syncrhonized with the clock in AD > > fh at REALM@test-server-ipa's password: > Last login: Fri Jan 4 14:51:25 2013 from ipa-w7.domain > [fh at test-server-ipa ~]$ klist > Ticket cache: FILE:/tmp/krb5cc_1554800011_JDgpIu5465 > Default principal: fh at REALM > > Valid starting Expires Service principal > 01/04/13 14:52:49 01/05/13 14:52:49 krbtgt/REALM at REALM > [fh at test-server-ipa ~]$ > > That's does provide a valid ticket but not a passwordless login. Actually I > have to enter a pass twice here! > > > > > > On Fri, Jan 4, 2013 at 4:25 PM, Sumit Bose wrote: > > > On Fri, Jan 04, 2013 at 04:14:36PM +0100, Han Boetes wrote: > > > You are absolutely right; the credentials aren't forwarded. > > > > > > I have enabled the option "allow gssapi credential delegation". So one > > > would expect that it should work. > > > > > > I just installed the mit kerberos tools and I can see all the options and > > > forwarding tickets is allowed according to the interface. Also putty is > > now > > > using the mit kerberos dll; gssapi32.dll and still I get the same > > results. > > > > > > So the proper question is: how do I get putty to really forward the > > > credentials? > > > > This might be an issue with your putty version. Can you try Quest's > > version of putty http://rc.quest.com/topics/putty/ , if you are not > > already using it? > > > > HTH > > > > bye, > > Sumit > > > > > > > > > > > On Fri, Jan 4, 2013 at 3:58 PM, Rob Crittenden > > wrote: > > > > > > > Han Boetes wrote: > > > > > > > >> I've set up windows with the instructions given over here: > > > >> > > > >> http://freeipa.com/page/**Windows_authentication_**against_FreeIPA< > > http://freeipa.com/page/Windows_authentication_against_FreeIPA> > > > >> > > > >> And all seems to be working fine. After I run klist I see valid > > tickets: > > > >> > > > >> Microsoft Windows [Version 6.1.7601] > > > >> Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten. > > > >> > > > >> C:\Users\fh>klist > > > >> > > > >> Aktuelle Anmelde-ID ist 0:0x153b25 > > > >> > > > >> Zwischengespeicherte Tickets: (1) > > > >> > > > >> #0> Client: fh @ REALM > > > >> Server: krbtgt/REALM @ REALM > > > >> KerbTicket (Verschl?sselungstyp): AES-256-CTS-HMAC-SHA1-96 > > > >> Ticketkennzeichen 0x40e10000 -> forwardable renewable initial > > > >> pre_authen > > > >> t name_canonicalize > > > >> Startzeit: 1/4/2013 14:03:11 (lokal) > > > >> Endzeit: 1/5/2013 14:03:11 (lokal) > > > >> Erneuerungszeit: 1/11/2013 14:03:11 (lokal) > > > >> Sitzungsschl?sseltyp: AES-256-CTS-HMAC-SHA1-96 > > > >> > > > >> > > > >> I can do a passwordless login with the latest putty with kerberos > > > >> authentication, I disabled password and key logins. And then on the > > > >> host I checked klist and got this: > > > >> > > > >> [fh at test-server-ipa ~]$ klist > > > >> klist: No credentials cache found (ticket cache > > > >> FILE:/tmp/krb5cc_1554800011) > > > >> > > > >> sudo also doesn't work. To test the setup I did the same from linux > > host > > > >> and login in, sudo, klist etc etc all work fine. So I checked the sshd > > > >> -d output difference and the only difference I see is: > > > >> > > > >> -Postponed gssapi-with-mic for fh from 192.168.2.73 port 50334 ssh2 > > > >> -debug1: Received some client credentials > > > >> +Postponed gssapi-with-mic for fh from 192.168.2.56 port 49168 ssh2 > > > >> +debug1: Got no client credentials > > > >> > > > >> Where .73 is the linux host and .56 is the windows host. > > > >> > > > >> What am I missing here? > > > >> > > > > > > > > The problem isn't that authentication fails, it is that the credentials > > > > aren't forwarded, right? > > > > > > > > Does putty support this? > > > > > > > > rob > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > # Han > > > > > _______________________________________________ > > > Freeipa-users mailing list > > > Freeipa-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > > > > # Han From akrivoka at redhat.com Fri Jan 4 18:04:24 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 04 Jan 2013 19:04:24 +0100 Subject: [Freeipa-users] AD permissions needed for setting up AD trusts In-Reply-To: <50E56B40.8070309@redhat.com> References: <20121221113033.41120@gmx.com> <20121221121928.GB22856@localhost.localdomain> <50E56B40.8070309@redhat.com> Message-ID: <50E719A8.2090103@redhat.com> On 01/03/2013 12:28 PM, Petr Spacek wrote: > On 12/21/2012 01:19 PM, Sumit Bose wrote: >> On Fri, Dec 21, 2012 at 12:30:33PM +0100, James Findley wrote: >>> Hi >>> >>> What permission level is needed for the AD user when creating an AD >>> trust? Can a regular domain user account do it, or is a domain >>> admin needed? >> >> The account used here must be a member of the Domain Admins group. >> >>> >>> If write access to the AD server is needed, then could someone >>> please tell me what the command will actually change in the AD server? >>> >> >> 'ipa trust-add' will only use LSA calls on the AD server. The most >> important one is CreateTrustedDomainEx2 >> (http://msdn.microsoft.com/en-us/library/cc234380.aspx) to create the >> trust between the two domains. Additionally QueryTrustedDomainInfoByName >> (http://msdn.microsoft.com/en-us/library/cc234376.aspx) to check if the >> trust is already added and SetInformationTrustedDomain >> (http://msdn.microsoft.com/en-us/library/cc234385.aspx) to tell the AD >> server that the IPA server can handled AES encryption are used. > > Should we add this information to AD trusts documentation? > >>> The windows team at my place of work will want to know exactly what >>> the tool will do before they grant permission. > I have added this information to the AD trusts wiki page: http://www.freeipa.org/page/IPAv3_AD_trust_setup#Add_trust_with_AD_domain -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From dpal at redhat.com Sat Jan 5 16:22:44 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 05 Jan 2013 11:22:44 -0500 Subject: [Freeipa-users] Does Solaris 11 work as client to IPA server? In-Reply-To: <558C15177F5E714F83334217C9A197DF5DB83674@SSC-MBX2.ssc.internal> References: <558C15177F5E714F83334217C9A197DF5DB4175B@SSC-MBX2.ssc.internal> <20801.213.225.75.97.1355821569.squirrel@www.nixtra.com>, <50D09ED3.3030102@redhat.com> <558C15177F5E714F83334217C9A197DF5DB82294@SSC-MBX2.ssc.internal>, <51748.188.244.64.7.1355994836.squirrel@www.nixtra.com> <558C15177F5E714F83334217C9A197DF5DB822D5@SSC-MBX2.ssc.internal>, <55800.188.244.64.7.1356013244.squirrel@www.nixtra.com>, <558C15177F5E714F83334217C9A197DF5DB8231A@SSC-MBX2.ssc.internal> <558C15177F5E714F83334217C9A197DF5DB8234C@SSC-MBX2.ssc.internal>, <50D4E50A.3060109@redhat.com>, <558C15177F5E714F83334217C9A197DF5DB8241D@SSC-MBX2.ssc.internal> <558C15177F5E714F83334217C9A197DF5DB82483@SSC-MBX2.ssc.internal>, <50D9CBC6.7080907@redhat.com> <558C15177F5E714F83334217C9A197DF5DB83674@SSC-MBX2.ssc.internal> Message-ID: <50E85354.3030004@redhat.com> On 01/04/2013 05:27 AM, Johan Petersson wrote: > Here is the instructions for a IPA Server Solaris 11 client configuration with secure bind and a custom DUAProfile. > Everything works as far as i have been able to test. Console login works, su - and ssh. Thank you Johan! We will put it onto the wiki. It seems that it is a good opportunity to refine our client configuration guide a bit. Thanks Dmitri > > Configuration done on the IPA Server. > > Create a DUAConfigProfile solaris_authssl.ldif > > dn: cn=solaris_authssl,ou=profile,dc=example,dc=com > objectClass: top > objectClass: DUAConfigProfile > cn: solaris_authssl > authenticationMethod: tls:simple > bindTimeLimit: 5 > credentialLevel: proxy > defaultSearchBase: dc=example,dc=com > defaultSearchScope: one > defaultServerList: ipaserver.example.com > followReferrals: TRUE > objectclassMap: shadow:shadowAccount=posixAccount > objectclassMap: printers:sunPrinter=printerService > profileTTL: 6000 > searchTimeLimit: 10 > serviceSearchDescriptor: passwd:cn=users,cn=accounts,dc=example,dc=com > serviceSearchDescriptor: group:cn=groups,cn=compat,dc=example,dc=com > serviceSearchDescriptor: netgroup:cn=ng,cn=compat,dc=example,dc=com > serviceSearchDescriptor: ethers:cn=computers,cn=accounts,dc=example,dc=com > serviceSearchDescriptor: automount:cn=default,cn=automount,dc=example,dc=com > serviceSearchDescriptor:auto_master:automountMapName=auto.master,cn=default,cn=automount,dc=example,dc=com > > Add the ldif to ipaserver: > > ldapadd -h ipaserver.example.com -x -W -D "cn=Directory Manager" -vvv -f solaris_authssl.ldif > > Create an account to use for authentication: > > ldapmodify -a -h ipaserver.example.com -D "cn=Directory Manager" -W > > dn: uid=solaris,cn=sysaccounts,cn=etc,dc=example,dc=com > objectClass: account > objectClass: simpleSecurityObject > objectClass: top > uid: solaris > userPassword: setyourpasswordhere > > ipa host-add --force --ip-address=192.168.0.1 solaris.example.com > > ipa host-add-managedby --host ipaserver.example.com solaris.example.com > > ipa-getkeytab -s ipaserver.example.com -p host/solaris.example.com -k /tmp/solaris.keytab > > Make sure that the automount maps in ipaserver is named auto_* and NOT auto.* so they are compatible with Solaris name standards. > > certutil -N -d . > > openssl x509 -in /etc/ipa/ca.crt -outform pem -out /etc/ipa/ca.pem > > certutil -A -n "ca-cert" -i /etc/ipa/ca.pem -a -t CT -d /(directory of generated cert8.db and key3.db) > > scp the keytab to the solaris host /etc/krb5/krb5.keytab and scp the *.db to the solaris host /var/ldap/ > > > > Solaris host configuration: > > Make sure to secure the krb5.keytab properly. > chown root:sys krb5.keytab > chmod 600 krb5.keytab > > Secure the *.db files created by certutil on IPA Server earlier. > > chown root:staff /var/ldap/*.db > chmod 444 /var/ldap/*.db > > Edit /etc/nsswitch.ldap, replace "ldap" with "dns" from the "hosts" and "ipnodes" lines: > > hosts: files dns > ipnodes: files dns > > ldapclient -v init \ > -a profileName=solaris_authssl \ > -a domainName=example.com \ > -a proxyDN="uid=solaris,cn=sysaccounts,cn=etc,dc=example,dc=com" \ > -a proxyPassword="setyourpasswordhere" \ > -D uid=solaris,cn=sysaccounts,cn=etc,dc=example,dc=com \ > -w yourpasswordagain \ > ipaserver.example.com > > Enable ntp client: > > Add serverlist to /etc/inet/ntp.client and rename it to ntp.conf > > Example: > server ipaserver.example.com iburst > > svcadm restart ntp > > To see it is running properly: > > svcs ntp > > To see what servers you are using: > > ntpq -p > > Edit /etc/krb5/krb5.conf: > > krb5.conf: > > [libdefaults] > default_realm = EXAMPLE.COM > verify_ap_req_nofail = false > [realms] > EXAMPLE.COM = { > kdc = ipaserver.example.com > admin_server = ipaserver.example.com > > [domain_realm] > example.com = EXAMPLE.COM > .example.com = EXAMPLE.COM > > > Pam configuration changed slightly in Solaris 11.1. > It is still possible to use /etc/pam.conf as before if preferable. > > Pam configuration in /etc/pam.d/ > > login: > > login auth requisite pam_authtok_get.so.1 > login auth required pam_dhkeys.so.1 > login auth required pam_unix_cred.so.1 > login auth sufficient pam_krb5.so.1 try_first_pass > login auth required pam_unix_auth.so.1 > login auth required pam_dial_auth.so.1 > > > other: > > auth definitive pam_user_policy.so.1 > auth requisite pam_authtok_get.so.1 > auth required pam_dhkeys.so.1 > auth required pam_unix_cred.so.1 > auth sufficient pam_krb5.so.1 > auth required pam_unix_auth.so.1 > > account requisite pam_roles.so.1 > account definitive pam_user_policy.so.1 > account required pam_unix_account.so.1 > account required pam_krb5.so.1 > account required pam_tsol_account.so.1 > > password include pam_authtok_common > password sufficient pam_krb5.so.1 > password required pam_authtok_store.so.1 > > > For NFS: > > /etc/nfssec.conf enable these: > > krb5 390003 kerberos_v5 default - # RPCSEC_GSS > krb5i 390004 kerberos_v5 default integrity # RPCSEC_GSS > krb5p 390005 kerberos_v5 default privacy # RPCSEC_GSS > > Do not forget to set nfsmapid_domain to your domain to avoid nobody:nobody permission issues with NFS. > > sharectl set -p nfsmapid_domain=home nfs > > To see if it is properly set: > sharectl get nfs -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hboetes at gmail.com Mon Jan 7 08:15:41 2013 From: hboetes at gmail.com (Han Boetes) Date: Mon, 7 Jan 2013 09:15:41 +0100 Subject: [Freeipa-users] authentication with latest putty fails In-Reply-To: <20130104175245.GE2210@localhost.localdomain> References: <50E6EE15.1020908@redhat.com> <20130104152546.GB2210@localhost.localdomain> <20130104175245.GE2210@localhost.localdomain> Message-ID: On Fri, Jan 4, 2013 at 6:52 PM, Sumit Bose wrote: > About delegating credentials, you might need to set the ok_as_delegate > flag on the host/* service ticket. To do this you can call kadmin.local > on the IPA server and then use > > modprinc +ok_as_delegate host/test-server-ipa.realm at REALM > > to set the flag. > I don't know why this host would have this flag set differently from other hosts. And I get this error while trying to set or unset this flag. kadmin.local: modprinc +ok_as_delegate host/ipa-w7.domain at REALM modify_principal: Kerberos database internal error while modifying "host/ipa-w7.domain at REALM For any other host as well BTW. I can't find anything relevant in the log files. -- # Han -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Jan 7 08:38:14 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 7 Jan 2013 09:38:14 +0100 Subject: [Freeipa-users] authentication with latest putty fails In-Reply-To: References: <50E6EE15.1020908@redhat.com> <20130104152546.GB2210@localhost.localdomain> <20130104175245.GE2210@localhost.localdomain> Message-ID: <20130107083814.GF2210@localhost.localdomain> On Mon, Jan 07, 2013 at 09:15:41AM +0100, Han Boetes wrote: > On Fri, Jan 4, 2013 at 6:52 PM, Sumit Bose wrote: > > > About delegating credentials, you might need to set the ok_as_delegate > > flag on the host/* service ticket. To do this you can call kadmin.local > > on the IPA server and then use > > > > modprinc +ok_as_delegate host/test-server-ipa.realm at REALM > > > > to set the flag. > > > > I don't know why this host would have this flag set differently from other Does it mean there are other windows hosts where delegation already works as expected? AFAIK the Linux OpenSSH client does not check this flag and forwards the credentials depending on the command line options, but it looks like putty on Windows checks this flag. > hosts. And I get this error while trying to set or unset this flag. > > kadmin.local: modprinc +ok_as_delegate host/ipa-w7.domain at REALM > modify_principal: Kerberos database internal error while modifying > "host/ipa-w7.domain at REALM > > For any other host as well BTW. I can't find anything relevant in the log > files. Which version of FreeIPA are you using? There are issues in older version which prevents kadmin.local from working. bye, Sumit > > -- > > > > # Han From hboetes at gmail.com Mon Jan 7 08:56:42 2013 From: hboetes at gmail.com (Han Boetes) Date: Mon, 7 Jan 2013 09:56:42 +0100 Subject: [Freeipa-users] authentication with latest putty fails In-Reply-To: <20130107083814.GF2210@localhost.localdomain> References: <50E6EE15.1020908@redhat.com> <20130104152546.GB2210@localhost.localdomain> <20130104175245.GE2210@localhost.localdomain> <20130107083814.GF2210@localhost.localdomain> Message-ID: There was something going on with a firewall blocking something and that windows host didn't have a cert yet. But still: Using Kerberos authentication Using principal fh at REALM Got host ticket host/test-server-ipa.domain at REALM Using username "fh". Successful Kerberos connection Last login: Mon Jan 7 07:38:19 2013 from ipa-w7.domain [fh at test-server-ipa ~]$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1554800011) klist on the host shows all tickets are forwordable and the forwarding option in both putty versions is on. Which version of FreeIPA are you using? There are issues in older > version which prevents kadmin.local from working. > The default stable: [root at auth-ipa ssl_for_ipa-w7]# rpm -qa |grep ipa- ipa-client-2.2.0-16.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-2.2.0-16.el6.x86_64 ipa-server-selinux-2.2.0-16.el6.x86_64 ipa-server-2.2.0-16.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-python-2.2.0-16.el6.x86_64 On Mon, Jan 7, 2013 at 9:38 AM, Sumit Bose wrote: > On Mon, Jan 07, 2013 at 09:15:41AM +0100, Han Boetes wrote: > > On Fri, Jan 4, 2013 at 6:52 PM, Sumit Bose wrote: > > > > > About delegating credentials, you might need to set the ok_as_delegate > > > flag on the host/* service ticket. To do this you can call kadmin.local > > > on the IPA server and then use > > > > > > modprinc +ok_as_delegate host/test-server-ipa.realm at REALM > > > > > > to set the flag. > > > > > > > I don't know why this host would have this flag set differently from > other > > Does it mean there are other windows hosts where delegation already > works as expected? AFAIK the Linux OpenSSH client does not check > this flag and forwards the credentials depending on the command line > options, but it looks like putty on Windows checks this flag. > > > hosts. And I get this error while trying to set or unset this flag. > > > > kadmin.local: modprinc +ok_as_delegate host/ipa-w7.domain at REALM > > modify_principal: Kerberos database internal error while modifying > > "host/ipa-w7.domain at REALM > > > > For any other host as well BTW. I can't find anything relevant in the log > > files. > > Which version of FreeIPA are you using? There are issues in older > version which prevents kadmin.local from working. > > bye, > Sumit > > > > > -- > > > > > > > > # Han > -- # Han -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Jan 7 09:21:29 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 7 Jan 2013 10:21:29 +0100 Subject: [Freeipa-users] authentication with latest putty fails In-Reply-To: References: <50E6EE15.1020908@redhat.com> <20130104152546.GB2210@localhost.localdomain> <20130104175245.GE2210@localhost.localdomain> <20130107083814.GF2210@localhost.localdomain> Message-ID: <20130107092129.GG2210@localhost.localdomain> On Mon, Jan 07, 2013 at 09:56:42AM +0100, Han Boetes wrote: > There was something going on with a firewall blocking something and that > windows host didn't have a cert yet. But still: > > Using Kerberos authentication > Using principal fh at REALM > Got host ticket host/test-server-ipa.domain at REALM > Using username "fh". > Successful Kerberos connection > Last login: Mon Jan 7 07:38:19 2013 from ipa-w7.domain > [fh at test-server-ipa ~]$ klist > klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1554800011) > > klist on the host shows all tickets are forwordable and the forwarding > option in both putty versions is on. yes, but the other flag is used by Windows to check if the target service can be trusted, see e.g. the 'How do I use delegation?' section on http://support.microsoft.com/kb/266080 . > > Which version of FreeIPA are you using? There are issues in older > > version which prevents kadmin.local from working. > > > > The default stable: > > [root at auth-ipa ssl_for_ipa-w7]# rpm -qa |grep ipa- > ipa-client-2.2.0-16.el6.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-admintools-2.2.0-16.el6.x86_64 > ipa-server-selinux-2.2.0-16.el6.x86_64 > ipa-server-2.2.0-16.el6.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-python-2.2.0-16.el6.x86_64 > I'll set up a server and check why kadmin.local is not working. bye, Sumit From natxo.asenjo at gmail.com Mon Jan 7 10:00:20 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 7 Jan 2013 11:00:20 +0100 Subject: [Freeipa-users] ipa admin tool error "ipa: ERROR: Client is not configured. Run ipa-client-install." Message-ID: hi, on a workstation *not* joined to the IPA domain but with the the ipa admin tools installed I get this error when trying to modify dns settings and I have a kerberos ticket of an admin user: $ kinit user.admin at UNIX.DOMAIN.TLD Password for user.admin at UNIX.DOMAIN.TLD $ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: user.admin at UNIX.DOMAIN.TLD Valid starting Expires Service principal 01/07/13 10:47:09 01/08/13 10:47:06 krbtgt/UNIX.DOMAIN.TLD at UNIX.DOMAIN.TLD renew until 01/14/13 10:47:06 $ ipa dnsrecord-mod unix.domain.tld ipaclient01 --ttl=300 ipa: ERROR: Client is not configured. Run ipa-client-install. Is this 'by design'? This limitation on the cli tool does not apply to the web interface, by the way, that is, I can login the web interface without being joined to the domain and modify all kind of stuff there ;-). To be more specific: this is not a problem, I can run this command on a joined host, but I was just curious. TIA. -- Groeten, natxo From natxo.asenjo at gmail.com Mon Jan 7 11:18:12 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 7 Jan 2013 12:18:12 +0100 Subject: [Freeipa-users] problems with netgroups cached values Message-ID: hi, in sssd.conf I have this regarding netgroup caching info: entry_cache_netgroup_timeout = 300 After the file was modified, the sssd daemon was reloaded. However, the values are still being cached for 90 minutes (default entry_cache_timeout value). Running sss_cache --netgroup does not help either. How could I troubleshoot this? -- Groeten, natxo From pviktori at redhat.com Mon Jan 7 11:21:29 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Jan 2013 12:21:29 +0100 Subject: [Freeipa-users] ipa admin tool error "ipa: ERROR: Client is not configured. Run ipa-client-install." In-Reply-To: References: Message-ID: <50EAAFB9.4030608@redhat.com> On 01/07/2013 11:00 AM, Natxo Asenjo wrote: > hi, > > on a workstation *not* joined to the IPA domain but with the the ipa > admin tools installed I get this error when trying to modify dns > settings and I have a kerberos ticket of an admin user: > > $ kinit user.admin at UNIX.DOMAIN.TLD > Password for user.admin at UNIX.DOMAIN.TLD > $ klist > Ticket cache: FILE:/tmp/krb5cc_500 > Default principal: user.admin at UNIX.DOMAIN.TLD > > Valid starting Expires Service principal > 01/07/13 10:47:09 01/08/13 10:47:06 krbtgt/UNIX.DOMAIN.TLD at UNIX.DOMAIN.TLD > renew until 01/14/13 10:47:06 > > $ ipa dnsrecord-mod unix.domain.tld ipaclient01 --ttl=300 > ipa: ERROR: Client is not configured. Run ipa-client-install. > > Is this 'by design'? This limitation on the cli tool does not apply to > the web interface, by the way, that is, I can login the web interface > without being joined to the domain and modify all kind of stuff there > ;-). > > To be more specific: this is not a problem, I can run this command on > a joined host, but I was just curious. > Create a config file in /etc/ipa/default.conf or ~/.ipa/default.conf (or somewhere else and point ipa to it using the -c option). Copy the `xmlrpc_uri` line from a config on a master or joined machine there. ipa should work then. -- Petr? From natxo.asenjo at gmail.com Mon Jan 7 11:48:54 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 7 Jan 2013 12:48:54 +0100 Subject: [Freeipa-users] problems with netgroups cached values In-Reply-To: References: Message-ID: On Mon, Jan 7, 2013 at 12:18 PM, Natxo Asenjo wrote: > How could I troubleshoot this? i have upped the debugging on sssd.conf debug_level = 9 en reloaded sssd. When I run # getent netgroup nagios nagios [root at ipaclient01 ~]# grep -i nagios /var/log/sssd/*.log /var/log/sssd/sssd_unix.domain.tld.log:(Mon Jan 7 12:27:37 2013) [sssd[be[unix.domain.tld]]] [be_get_account_info] (0x0100): Got request for [4100][1][name=nagios] /var/log/sssd/sssd_unix.domain.tld.log:(Mon Jan 7 12:27:38 2013) [sssd[be[unix.domain.tld]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(cn=nagios)(objectclass=ipaNisNetgroup))][cn=ng,cn=alt,dc=unix,dc=domain,dc=tld]. /var/log/sssd/sssd_unix.domain.tld.log:(Mon Jan 7 12:27:38 2013) [sssd[be[unix.domain.tld]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=nagios,cn=ng,cn=alt,dc=unix,dc=domain,dc=tld]. /var/log/sssd/sssd_unix.domain.tld.log:(Mon Jan 7 12:27:38 2013) [sssd[be[unix.domain.tld]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(memberOf=cn=nagios,cn=ng,cn=alt,dc=unix,dc=domain,dc=tld))(objectclass=ipaHost))][cn=accounts,dc=unix,dc=domain,dc=tld]. /var/log/sssd/sssd_unix.domain.tld.log:(Mon Jan 7 12:27:38 2013) [sssd[be[unix.domain.tld]]] [ipa_save_netgroup] (0x2000): Storing netgroup nagios /var/log/sssd/sssd_unix.domain.tld.log:(Mon Jan 7 12:27:38 2013) [sssd[be[unix.domain.tld]]] [ipa_save_netgroup] (0x1000): Adding original DN [cn=nagios,cn=ng,cn=alt,dc=unix,dc=domain,dc=tld] to attributes of [nagios]. /var/log/sssd/sssd_unix.domain.tld.log:(Mon Jan 7 12:27:38 2013) [sssd[be[unix.domain.tld]]] [ipa_save_netgroup] (0x2000): No netgroup triples for netgroup [nagios]. /var/log/sssd/sssd_unix.domain.tld.log:(Mon Jan 7 12:27:38 2013) [sssd[be[unix.domain.tld]]] [ipa_save_netgroup] (0x1000): No original members for netgroup [nagios] /var/log/sssd/sssd_unix.domain.tld.log:(Mon Jan 7 12:27:38 2013) [sssd[be[unix.domain.tld]]] [ipa_save_netgroup] (0x1000): No members for netgroup [nagios] /var/log/sssd/sssd_unix.domain.tld.log:(Mon Jan 7 12:27:38 2013) [sssd[be[unix.domain.tld]]] [ipa_save_netgroup] (0x0400): Storing info for netgroup nagios But when searching ldap directly: $ ldapsearch -h kdc01.unix.domain.tld -b "dc=unix,dc=domain,dc=tld" "(cn=nagios)" -Y GSSAPI SASL/GSSAPI authentication started SASL username: jose.admin at unix.domain.tld SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (cn=nagios) # requesting: ALL # # nagios, ng, compat, unix.domain.tld dn: cn=nagios,cn=ng,cn=compat,dc=unix,dc=domain,dc=tld objectClass: nisNetgroup objectClass: top nisNetgroupTriple: (solr01.unix.domain.tld,-,unix.domain.tld) nisNetgroupTriple: (mrepo.unix.domain.tld,-,unix.domain.tld) nisNetgroupTriple: (radius01.unix.domain.tld,-,unix.domain.tld) nisNetgroupTriple: (kdc02.unix.domain.tld,-,unix.domain.tld) nisNetgroupTriple: (kdc01.unix.domain.tld,-,unix.domain.tld) nisNetgroupTriple: (ipaclient01.unix.domain.tld,-,unix.domain.tld) cn: nagios # nagios, hostgroups, accounts, unix.domain.tld dn: cn=nagios,cn=hostgroups,cn=accounts,dc=unix,dc=domain,dc=tld objectClass: ipaobject objectClass: ipahostgroup objectClass: nestedGroup objectClass: groupOfNames objectClass: top objectClass: mepOriginEntry cn: nagios description: members of this hostgroup get cfengine policy to install the nagi os agent and the snmp server ipaUniqueID: 4b95dbea-3e27-11e2-b9f4-005056806151 memberOf: cn=nagios,cn=ng,cn=alt,dc=unix,dc=domain,dc=tld mepManagedEntry: cn=nagios,cn=ng,cn=alt,dc=unix,dc=domain,dc=tld member: fqdn=solr01.unix.domain.tld,cn=computers,cn=accounts,dc=unix,dc=domain,dc=tld member: fqdn=mrepo.unix.domain.tld,cn=computers,cn=accounts,dc=unix,dc=domain,dc=tld member: fqdn=radius01.unix.domain.tld,cn=computers,cn=accounts,dc=unix,dc=domain,dc=tld member: fqdn=kdc02.unix.domain.tld,cn=computers,cn=accounts,dc=unix,dc=domain,dc=tld member: fqdn=kdc01.unix.domain.tld,cn=computers,cn=accounts,dc=unix,dc=domain,dc=tld member: fqdn=ipaclient01.unix.domain.tld,cn=computers,cn=accounts,dc=unix,dc=domain,dc=tld # nagios, ng, alt, unix.domain.tld dn: cn=nagios,cn=ng,cn=alt,dc=unix,dc=domain,dc=tld objectClass: ipanisnetgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: ipaAssociation objectClass: top nisDomainName: unix.domain.tld cn: nagios memberHost: cn=nagios,cn=hostgroups,cn=accounts,dc=unix,dc=domain,dc=tld description: ipaNetgroup nagios mepManagedBy: cn=nagios,cn=hostgroups,cn=accounts,dc=unix,dc=domain,dc=tld ipaUniqueID: 4b97c932-3e27-11e2-b9f4-005056806151 # search result search: 4 result: 0 Success So the values are there. After the cache times out, I get results with getent netgroup. Any clues as to how to prevent this? TIA, -- natxo From jhrozek at redhat.com Mon Jan 7 12:07:06 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 7 Jan 2013 13:07:06 +0100 Subject: [Freeipa-users] problems with netgroups cached values In-Reply-To: References: Message-ID: <20130107120706.GN28190@hendrix.redhat.com> On Mon, Jan 07, 2013 at 12:18:12PM +0100, Natxo Asenjo wrote: > hi, > > in sssd.conf I have this regarding netgroup caching info: > > entry_cache_netgroup_timeout = 300 > > After the file was modified, the sssd daemon was reloaded. > > However, the values are still being cached for 90 minutes (default > entry_cache_timeout value). > > Running sss_cache --netgroup does not help either. > > How could I troubleshoot this? Which sssd version is this? From natxo.asenjo at gmail.com Mon Jan 7 12:17:21 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 7 Jan 2013 13:17:21 +0100 Subject: [Freeipa-users] problems with netgroups cached values In-Reply-To: <20130107120706.GN28190@hendrix.redhat.com> References: <20130107120706.GN28190@hendrix.redhat.com> Message-ID: On Mon, Jan 7, 2013 at 1:07 PM, Jakub Hrozek wrote: > On Mon, Jan 07, 2013 at 12:18:12PM +0100, Natxo Asenjo wrote: >> hi, >> >> in sssd.conf I have this regarding netgroup caching info: >> >> entry_cache_netgroup_timeout = 300 >> >> After the file was modified, the sssd daemon was reloaded. >> >> However, the values are still being cached for 90 minutes (default >> entry_cache_timeout value). >> >> Running sss_cache --netgroup does not help either. >> >> How could I troubleshoot this? > > Which sssd version is this? 1.8.0, the client is centos 6.3 -- natxo From jhrozek at redhat.com Mon Jan 7 14:20:56 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 7 Jan 2013 15:20:56 +0100 Subject: [Freeipa-users] problems with netgroups cached values In-Reply-To: References: <20130107120706.GN28190@hendrix.redhat.com> Message-ID: <20130107142056.GS28190@hendrix.redhat.com> On Mon, Jan 07, 2013 at 01:17:21PM +0100, Natxo Asenjo wrote: > On Mon, Jan 7, 2013 at 1:07 PM, Jakub Hrozek wrote: > > On Mon, Jan 07, 2013 at 12:18:12PM +0100, Natxo Asenjo wrote: > >> hi, > >> > >> in sssd.conf I have this regarding netgroup caching info: > >> > >> entry_cache_netgroup_timeout = 300 > >> > >> After the file was modified, the sssd daemon was reloaded. > >> > >> However, the values are still being cached for 90 minutes (default > >> entry_cache_timeout value). > >> > >> Running sss_cache --netgroup does not help either. > >> > >> How could I troubleshoot this? > > > > Which sssd version is this? > > 1.8.0, the client is centos 6.3 If this is not a super-stable-production system, can you try test packages for 6.3? There's been a number of fixes for the native ipa netgroups in 6.4.. From natxo.asenjo at gmail.com Mon Jan 7 14:55:49 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 7 Jan 2013 15:55:49 +0100 Subject: [Freeipa-users] problems with netgroups cached values In-Reply-To: <20130107142056.GS28190@hendrix.redhat.com> References: <20130107120706.GN28190@hendrix.redhat.com> <20130107142056.GS28190@hendrix.redhat.com> Message-ID: hi, On Mon, Jan 7, 2013 at 3:20 PM, Jakub Hrozek wrote: > On Mon, Jan 07, 2013 at 01:17:21PM +0100, Natxo Asenjo wrote: >> On Mon, Jan 7, 2013 at 1:07 PM, Jakub Hrozek wrote: >> > On Mon, Jan 07, 2013 at 12:18:12PM +0100, Natxo Asenjo wrote: >> > Which sssd version is this? >> >> 1.8.0, the client is centos 6.3 > > If this is not a super-stable-production system, can you try test > packages for 6.3? There's been a number of fixes for the native ipa > netgroups in 6.4.. unfortunately it is. -- natxo From hboetes at gmail.com Mon Jan 7 16:00:09 2013 From: hboetes at gmail.com (Han Boetes) Date: Mon, 7 Jan 2013 17:00:09 +0100 Subject: [Freeipa-users] authentication with latest putty fails In-Reply-To: <20130107092129.GG2210@localhost.localdomain> References: <50E6EE15.1020908@redhat.com> <20130104152546.GB2210@localhost.localdomain> <20130104175245.GE2210@localhost.localdomain> <20130107083814.GF2210@localhost.localdomain> <20130107092129.GG2210@localhost.localdomain> Message-ID: I just had a long and fruitfull debugging session with Sumit and this is what we discovered. The default settings do run fine for linux machines but for windows hosts they do not suffice. Sumit is submitting bug reports and hopefully they will be applied to the next 2.2.x release. This problem does not exist with version 3.x The workaround for 2.2.x releases is: For any target machine you want to enable forwarding tickets which have to be accessible with putty you will have to add the ok_as_delegate flag. To do that run the following commands on the ipa-server: # ipa host-mod --addattr='objectclass=krbTicketPolicyAux' destinationhost.domain # kadmin.local -q 'modprinc +ok_as_delegate host/destinationhost.domain at REALM' So far I working tickets on the destination machine if I used centrify putty to log in. This didn't work with the stock version of putty allas. # Han -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Jan 7 17:17:22 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 7 Jan 2013 18:17:22 +0100 Subject: [Freeipa-users] authentication with latest putty fails In-Reply-To: References: <50E6EE15.1020908@redhat.com> <20130104152546.GB2210@localhost.localdomain> <20130104175245.GE2210@localhost.localdomain> <20130107083814.GF2210@localhost.localdomain> <20130107092129.GG2210@localhost.localdomain> Message-ID: <20130107171722.GH2210@localhost.localdomain> On Mon, Jan 07, 2013 at 05:00:09PM +0100, Han Boetes wrote: > I just had a long and fruitfull debugging session with Sumit and this is > what we discovered. Thank you for your patience and help to debug this issue. > > The default settings do run fine for linux machines but for windows hosts > they do not suffice. Sumit is submitting bug reports and hopefully they > will be applied to the next 2.2.x release. This problem does not exist with > version 3.x > > The workaround for 2.2.x releases is: > > For any target machine you want to enable forwarding tickets which have to > be accessible with putty you will have to add the ok_as_delegate flag. To > do that run the following commands on the ipa-server: > > # ipa host-mod --addattr='objectclass=krbTicketPolicyAux' > destinationhost.domain Ticket https://fedorahosted.org/freeipa/ticket/3328 covers the missing objectclass. > # kadmin.local -q 'modprinc +ok_as_delegate > host/destinationhost.domain at REALM' https://fedorahosted.org/freeipa/ticket/3329 is a RFE to think about how we want to handle this flag (and maybe Kerberos flags in general). bye, Sumit > > So far I working tickets on the destination machine if I used centrify > putty to log in. This didn't work with the stock version of putty allas. > > > > # Han From jhrozek at redhat.com Mon Jan 7 19:20:51 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 7 Jan 2013 20:20:51 +0100 Subject: [Freeipa-users] problems with netgroups cached values In-Reply-To: References: <20130107120706.GN28190@hendrix.redhat.com> <20130107142056.GS28190@hendrix.redhat.com> Message-ID: <20130107192051.GB28190@hendrix.redhat.com> On Mon, Jan 07, 2013 at 03:55:49PM +0100, Natxo Asenjo wrote: > hi, > > On Mon, Jan 7, 2013 at 3:20 PM, Jakub Hrozek wrote: > > On Mon, Jan 07, 2013 at 01:17:21PM +0100, Natxo Asenjo wrote: > >> On Mon, Jan 7, 2013 at 1:07 PM, Jakub Hrozek wrote: > >> > On Mon, Jan 07, 2013 at 12:18:12PM +0100, Natxo Asenjo wrote: > > >> > Which sssd version is this? > >> > >> 1.8.0, the client is centos 6.3 > > > > If this is not a super-stable-production system, can you try test > > packages for 6.3? There's been a number of fixes for the native ipa > > netgroups in 6.4.. > > unfortunately it is. OK..I couldn't reproduce the problem myself with git head, but I've asked one of my colleagues to try and reproduce with 6.3. From natxo.asenjo at gmail.com Mon Jan 7 19:34:04 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 7 Jan 2013 20:34:04 +0100 Subject: [Freeipa-users] problems with netgroups cached values In-Reply-To: <20130107192051.GB28190@hendrix.redhat.com> References: <20130107120706.GN28190@hendrix.redhat.com> <20130107142056.GS28190@hendrix.redhat.com> <20130107192051.GB28190@hendrix.redhat.com> Message-ID: On Mon, Jan 7, 2013 at 8:20 PM, Jakub Hrozek wrote: > On Mon, Jan 07, 2013 at 03:55:49PM +0100, Natxo Asenjo wrote: >> hi, >> >> On Mon, Jan 7, 2013 at 3:20 PM, Jakub Hrozek wrote: >> > On Mon, Jan 07, 2013 at 01:17:21PM +0100, Natxo Asenjo wrote: >> >> On Mon, Jan 7, 2013 at 1:07 PM, Jakub Hrozek wrote: >> >> > On Mon, Jan 07, 2013 at 12:18:12PM +0100, Natxo Asenjo wrote: >> >> >> > Which sssd version is this? >> >> >> >> 1.8.0, the client is centos 6.3 >> > >> > If this is not a super-stable-production system, can you try test >> > packages for 6.3? There's been a number of fixes for the native ipa >> > netgroups in 6.4.. >> >> unfortunately it is. > > OK..I couldn't reproduce the problem myself with git head, but I've asked > one of my colleagues to try and reproduce with 6.3. Thanks for your time. If you need any input just ask. In the meantime, I have seen that creating pure netgroups instead of hostgroups works around this problem. -- natxo From okos at redhat.com Tue Jan 8 13:48:28 2013 From: okos at redhat.com (Ondrej Kos) Date: Tue, 08 Jan 2013 14:48:28 +0100 Subject: [Freeipa-users] problems with netgroups cached values In-Reply-To: References: <20130107120706.GN28190@hendrix.redhat.com> <20130107142056.GS28190@hendrix.redhat.com> <20130107192051.GB28190@hendrix.redhat.com> Message-ID: <50EC23AC.8020502@redhat.com> On 07/01/13 20:34, Natxo Asenjo wrote: > On Mon, Jan 7, 2013 at 8:20 PM, Jakub Hrozek wrote: >> On Mon, Jan 07, 2013 at 03:55:49PM +0100, Natxo Asenjo wrote: >>> hi, >>> >>> On Mon, Jan 7, 2013 at 3:20 PM, Jakub Hrozek wrote: >>>> On Mon, Jan 07, 2013 at 01:17:21PM +0100, Natxo Asenjo wrote: >>>>> On Mon, Jan 7, 2013 at 1:07 PM, Jakub Hrozek wrote: >>>>>> On Mon, Jan 07, 2013 at 12:18:12PM +0100, Natxo Asenjo wrote: >>> >>>>>> Which sssd version is this? >>>>> >>>>> 1.8.0, the client is centos 6.3 >>>> >>>> If this is not a super-stable-production system, can you try test >>>> packages for 6.3? There's been a number of fixes for the native ipa >>>> netgroups in 6.4.. >>> >>> unfortunately it is. >> >> OK..I couldn't reproduce the problem myself with git head, but I've asked >> one of my colleagues to try and reproduce with 6.3. > > Thanks for your time. > > If you need any input just ask. > > In the meantime, I have seen that creating pure netgroups instead of > hostgroups works around this problem. > Hi, could you please provide more logs? I tried to set up same environment, with sssd-1.8.0-32.el6.x86_64, and everything works fine, so you might be hitting some race condition. -- Ondrej Kos Associate Software Engineer Identity Management Red Hat Czech phone: +420-532-294-558 cell: +420-736-417-909 ext: 82-62558 loc: 1013 Brno 1 office irc: okos @ #brno From natxo.asenjo at gmail.com Tue Jan 8 14:32:26 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 8 Jan 2013 15:32:26 +0100 Subject: [Freeipa-users] problems with netgroups cached values In-Reply-To: <50EC23AC.8020502@redhat.com> References: <20130107120706.GN28190@hendrix.redhat.com> <20130107142056.GS28190@hendrix.redhat.com> <20130107192051.GB28190@hendrix.redhat.com> <50EC23AC.8020502@redhat.com> Message-ID: On Tue, Jan 8, 2013 at 2:48 PM, Ondrej Kos wrote: > could you please provide more logs? I tried to set up same environment, with > sssd-1.8.0-32.el6.x86_64, and everything works fine, so you might be hitting > some race condition. sure, I will send you debug 9 logs to your corporate address. TIA, -- groet, natxo From orion at cora.nwra.com Tue Jan 8 18:55:49 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 08 Jan 2013 11:55:49 -0700 Subject: [Freeipa-users] Setting up single domain but with dns subdomains Message-ID: <50EC6BB5.50409@cora.nwra.com> I'm looking into migrating our 389ds ldap + kerberos to FreeIPA and I'm wondering how to setup DNS autodiscovery (if possible) in a way to point to different servers in different locations. We have two major offices, one that uses the "nwra.com" dnsdomain and one that uses the "cora.nwra.com" dns subdomain. We're planning on using the NWRA.COM domain for IPA/kerberos. I'd like to have the hosts is the "cora" office use the local servers instead of the one at the main office. Is this possible? While I can have: _ldap._tcp.cora.nwra.com. SRV 0 0 636 ipa.cora.nwra.com. If I have: _kerberos.cora.nwra.com. TXT "NWRA.COM" it will then automatically look for: _kerberos._udp.nwra.com. SRV Which will hold the servers for the other office. Any suggestions? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From rcritten at redhat.com Tue Jan 8 19:06:05 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Jan 2013 14:06:05 -0500 Subject: [Freeipa-users] Setting up single domain but with dns subdomains In-Reply-To: <50EC6BB5.50409@cora.nwra.com> References: <50EC6BB5.50409@cora.nwra.com> Message-ID: <50EC6E1D.30605@redhat.com> Orion Poplawski wrote: > I'm looking into migrating our 389ds ldap + kerberos to FreeIPA and I'm > wondering how to setup DNS autodiscovery (if possible) in a way to point > to different servers in different locations. > > We have two major offices, one that uses the "nwra.com" dnsdomain and > one that uses the "cora.nwra.com" dns subdomain. We're planning on > using the NWRA.COM domain for IPA/kerberos. I'd like to have the hosts > is the "cora" office use the local servers instead of the one at the > main office. Is this possible? While I can have: > > _ldap._tcp.cora.nwra.com. SRV 0 0 636 ipa.cora.nwra.com. > > If I have: > > _kerberos.cora.nwra.com. TXT "NWRA.COM" > > it will then automatically look for: > > _kerberos._udp.nwra.com. SRV > > Which will hold the servers for the other office. > > Any suggestions? > We don't have a good solution for region-specific enrollment right now. There is ticket open, https://fedorahosted.org/freeipa/ticket/2008 In 3.0 we added better capabilities for bypassing discovery using --server and --fixed-primary in ipa-client-install. rob From Steven.Jones at vuw.ac.nz Tue Jan 8 19:31:40 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 8 Jan 2013 19:31:40 +0000 Subject: [Freeipa-users] Aiisues to wathc out fro / anticipate when upgrading RHEL6.3 and IPA 2 to 6.4 and IPA 3 Message-ID: <833D8E48405E064EBC54C84EC6B36E40547A12B2@STAWINCOX10MBX1.staff.vuw.ac.nz> HI, I assume RHEL 6.4 is GA shortly just how straigh forward is the upgrade from one IPA version to another please? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From simo at redhat.com Tue Jan 8 20:20:28 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 08 Jan 2013 15:20:28 -0500 Subject: [Freeipa-users] Aiisues to wathc out fro / anticipate when upgrading RHEL6.3 and IPA 2 to 6.4 and IPA 3 In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40547A12B2@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40547A12B2@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <1357676428.29147.39.camel@willson.li.ssimo.org> On Tue, 2013-01-08 at 19:31 +0000, Steven Jones wrote: > HI, > > I assume RHEL 6.4 is GA shortly just how straigh forward is the upgrade from one IPA version to another please? > regards Should just require an rpm upgrade and a restart and nothing else. Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Tue Jan 8 20:30:50 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 8 Jan 2013 20:30:50 +0000 Subject: [Freeipa-users] I found this great little video on SSSD, maybe of interest. Message-ID: <833D8E48405E064EBC54C84EC6B36E40547A1707@STAWINCOX10MBX1.staff.vuw.ac.nz> http://www.youtube.com/user/opensourceidm?feature=watch regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From rcritten at redhat.com Tue Jan 8 20:44:25 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Jan 2013 15:44:25 -0500 Subject: [Freeipa-users] Aiisues to wathc out fro / anticipate when upgrading RHEL6.3 and IPA 2 to 6.4 and IPA 3 In-Reply-To: <1357676428.29147.39.camel@willson.li.ssimo.org> References: <833D8E48405E064EBC54C84EC6B36E40547A12B2@STAWINCOX10MBX1.staff.vuw.ac.nz> <1357676428.29147.39.camel@willson.li.ssimo.org> Message-ID: <50EC8529.3090200@redhat.com> Simo Sorce wrote: > On Tue, 2013-01-08 at 19:31 +0000, Steven Jones wrote: >> HI, >> >> I assume RHEL 6.4 is GA shortly just how straigh forward is the upgrade from one IPA version to another please? >> regards > > Should just require an rpm upgrade and a restart and nothing else. > > Simo. > If you have multiple servers you'll want to upgrade them one at a time in a short period (days, not weeks). rob From erinn.looneytriggs at gmail.com Tue Jan 8 20:49:11 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 08 Jan 2013 11:49:11 -0900 Subject: [Freeipa-users] Aiisues to wathc out fro / anticipate when upgrading RHEL6.3 and IPA 2 to 6.4 and IPA 3 In-Reply-To: <50EC8529.3090200@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40547A12B2@STAWINCOX10MBX1.staff.vuw.ac.nz> <1357676428.29147.39.camel@willson.li.ssimo.org> <50EC8529.3090200@redhat.com> Message-ID: <50EC8647.104@gmail.com> On 01/08/13 11:44, Rob Crittenden wrote: > Simo Sorce wrote: >> On Tue, 2013-01-08 at 19:31 +0000, Steven Jones wrote: >>> HI, >>> >>> I assume RHEL 6.4 is GA shortly just how straigh forward is the >>> upgrade from one IPA version to another please? >>> regards >> >> Should just require an rpm upgrade and a restart and nothing else. >> >> Simo. >> > > If you have multiple servers you'll want to upgrade them one at a time > in a short period (days, not weeks). > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Is this the release where SELinux mapping in IPA actually starts working? If so that is definitely something to watch out for (I realize this is more of an SSSD thing, but still). If you aren't careful and you have your users mapped to something like guest_u, well the upgrade can be very inconvenient for them. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From jhrozek at redhat.com Tue Jan 8 20:55:08 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 8 Jan 2013 21:55:08 +0100 Subject: [Freeipa-users] Aiisues to wathc out fro / anticipate when upgrading RHEL6.3 and IPA 2 to 6.4 and IPA 3 In-Reply-To: <50EC8647.104@gmail.com> References: <833D8E48405E064EBC54C84EC6B36E40547A12B2@STAWINCOX10MBX1.staff.vuw.ac.nz> <1357676428.29147.39.camel@willson.li.ssimo.org> <50EC8529.3090200@redhat.com> <50EC8647.104@gmail.com> Message-ID: <20130108205508.GP3008@hendrix.brq.redhat.com> On Tue, Jan 08, 2013 at 11:49:11AM -0900, Erinn Looney-Triggs wrote: > On 01/08/13 11:44, Rob Crittenden wrote: > > Simo Sorce wrote: > >> On Tue, 2013-01-08 at 19:31 +0000, Steven Jones wrote: > >>> HI, > >>> > >>> I assume RHEL 6.4 is GA shortly just how straigh forward is the > >>> upgrade from one IPA version to another please? > >>> regards > >> > >> Should just require an rpm upgrade and a restart and nothing else. > >> > >> Simo. > >> > > > > If you have multiple servers you'll want to upgrade them one at a time > > in a short period (days, not weeks). > > > > rob > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Is this the release where SELinux mapping in IPA actually starts working? > Yes (famous last words..) > If so that is definitely something to watch out for (I realize this is > more of an SSSD thing, but still). If you aren't careful and you have > your users mapped to something like guest_u, well the upgrade can be > very inconvenient for them. > > -Erinn I realize that the SELinux mapping was very bad for users and I'm very sorry I let it through. The SELinux support was pretty much completely rewritten in 6.4, there are still things I'd like to improve but functionality-wise, I closed the last known SELinux bug today. From erinn.looneytriggs at gmail.com Tue Jan 8 21:17:55 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 08 Jan 2013 12:17:55 -0900 Subject: [Freeipa-users] Aiisues to wathc out fro / anticipate when upgrading RHEL6.3 and IPA 2 to 6.4 and IPA 3 In-Reply-To: <20130108205508.GP3008@hendrix.brq.redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40547A12B2@STAWINCOX10MBX1.staff.vuw.ac.nz> <1357676428.29147.39.camel@willson.li.ssimo.org> <50EC8529.3090200@redhat.com> <50EC8647.104@gmail.com> <20130108205508.GP3008@hendrix.brq.redhat.com> Message-ID: <50EC8D03.2030908@gmail.com> On 01/08/13 11:55, Jakub Hrozek wrote: > On Tue, Jan 08, 2013 at 11:49:11AM -0900, Erinn Looney-Triggs wrote: >> On 01/08/13 11:44, Rob Crittenden wrote: >>> Simo Sorce wrote: >>>> On Tue, 2013-01-08 at 19:31 +0000, Steven Jones wrote: >>>>> HI, >>>>> >>>>> I assume RHEL 6.4 is GA shortly just how straigh forward is the >>>>> upgrade from one IPA version to another please? >>>>> regards >>>> >>>> Should just require an rpm upgrade and a restart and nothing else. >>>> >>>> Simo. >>>> >>> >>> If you have multiple servers you'll want to upgrade them one at a time >>> in a short period (days, not weeks). >>> >>> rob >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> Is this the release where SELinux mapping in IPA actually starts working? >> > > Yes (famous last words..) > >> If so that is definitely something to watch out for (I realize this is >> more of an SSSD thing, but still). If you aren't careful and you have >> your users mapped to something like guest_u, well the upgrade can be >> very inconvenient for them. >> >> -Erinn > > I realize that the SELinux mapping was very bad for users and I'm very > sorry I let it through. The SELinux support was pretty much completely > rewritten in 6.4, there are still things I'd like to improve but > functionality-wise, I closed the last known SELinux bug today. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > Eh, stuff breaks, it is the nature of the beast. I was one of the folks that submitted a bug, I know there was talk about putting out notes for the default SELinux user mapping etc. The only thing I would say is make some noise about this. It might be a good idea to send a note to freeipa-announce (which I think exists) and any place else pertinent too, because it was a rather painful learning experience when I was running as guest_u in Fedora 18, it was also pretty hard to diagnose because the utilities at that time didn't reflect what was happening. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Tue Jan 8 21:45:48 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Jan 2013 16:45:48 -0500 Subject: [Freeipa-users] Aiisues to wathc out fro / anticipate when upgrading RHEL6.3 and IPA 2 to 6.4 and IPA 3 In-Reply-To: <50EC8647.104@gmail.com> References: <833D8E48405E064EBC54C84EC6B36E40547A12B2@STAWINCOX10MBX1.staff.vuw.ac.nz> <1357676428.29147.39.camel@willson.li.ssimo.org> <50EC8529.3090200@redhat.com> <50EC8647.104@gmail.com> Message-ID: <50EC938C.2020603@redhat.com> Erinn Looney-Triggs wrote: > On 01/08/13 11:44, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Tue, 2013-01-08 at 19:31 +0000, Steven Jones wrote: >>>> HI, >>>> >>>> I assume RHEL 6.4 is GA shortly just how straigh forward is the >>>> upgrade from one IPA version to another please? >>>> regards >>> >>> Should just require an rpm upgrade and a restart and nothing else. >>> >>> Simo. >>> >> >> If you have multiple servers you'll want to upgrade them one at a time >> in a short period (days, not weeks). >> >> rob >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > Is this the release where SELinux mapping in IPA actually starts working? > > If so that is definitely something to watch out for (I realize this is > more of an SSSD thing, but still). If you aren't careful and you have > your users mapped to something like guest_u, well the upgrade can be > very inconvenient for them. I believe this was fixed. rob From rcritten at redhat.com Tue Jan 8 22:10:42 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Jan 2013 17:10:42 -0500 Subject: [Freeipa-users] Announcing FreeIPA v3.1.1 Release Message-ID: <50EC9962.9060309@redhat.com> The FreeIPA team is proud to announce version FreeIPA v3.1.1. It can be downloaded from http://www.freeipa.org/page/Downloads. == Highlights in 3.1.1 == * Increase default maxbersize so new replica installs won't fail if the CRL becomes very large. * Do not crash in ipa-client-install in DNS discovery when a TXT record was configured, but the referred domain did not contain any Kerberos SRV record. * Cookie Expires date should be locale insensitive * Enable SSSD on installation in client installes. We had relied on authconfig to enable it but it no longer does so when passed the --enablesssd flag. It just configures SSSD in the PAM stack. == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. 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-devel mailing list: http://www.redhat.com/mailman/listinfo/freeipa-devel == Detailed Changelog since 3.1.0 == JR Aquino (1): * Allow PKI-CA Replica Installs when CRL exceeds default maxber value John Dennis (1): * Cookie Expires date should be locale insensitive Lynn Root (2): * Fixed the catch of the hostname option during ipa-server-install * Raise ValidationError when CSR does not have a subject hostname Martin Kosek (4): * Add Lynn Root to Contributors.txt * Enable SSSD on client install * Fix delegation-find command --group handling * Do not crash when Kerberos SRV record is not found Rob Crittenden (1): * Become IPA 3.1.1 Simo Sorce (1): * Log info on failure to connect Tomas Babej (2): * Relax restriction for leading/trailing whitespaces in *-find commands * Forbid overlapping rid ranges for the same id range From erinn.looneytriggs at gmail.com Tue Jan 8 22:20:50 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 08 Jan 2013 13:20:50 -0900 Subject: [Freeipa-users] Aiisues to wathc out fro / anticipate when upgrading RHEL6.3 and IPA 2 to 6.4 and IPA 3 In-Reply-To: <50EC938C.2020603@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40547A12B2@STAWINCOX10MBX1.staff.vuw.ac.nz> <1357676428.29147.39.camel@willson.li.ssimo.org> <50EC8529.3090200@redhat.com> <50EC8647.104@gmail.com> <50EC938C.2020603@redhat.com> Message-ID: <50EC9BC2.8090204@gmail.com> On 01/08/13 12:45, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> On 01/08/13 11:44, Rob Crittenden wrote: >>> Simo Sorce wrote: >>>> On Tue, 2013-01-08 at 19:31 +0000, Steven Jones wrote: >>>>> HI, >>>>> >>>>> I assume RHEL 6.4 is GA shortly just how straigh forward is the >>>>> upgrade from one IPA version to another please? >>>>> regards >>>> >>>> Should just require an rpm upgrade and a restart and nothing else. >>>> >>>> Simo. >>>> >>> >>> If you have multiple servers you'll want to upgrade them one at a time >>> in a short period (days, not weeks). >>> >>> rob >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> Is this the release where SELinux mapping in IPA actually starts working? >> >> If so that is definitely something to watch out for (I realize this is >> more of an SSSD thing, but still). If you aren't careful and you have >> your users mapped to something like guest_u, well the upgrade can be >> very inconvenient for them. > > I believe this was fixed. > > rob Ok I am just going off of this: https://bugzilla.redhat.com/show_bug.cgi?id=887193 which makes it appear like it will be documented but there isn't much you can do about the default being set to guest_u. However, if it is fixed that is great news. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From dpal at redhat.com Tue Jan 8 22:32:15 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 08 Jan 2013 17:32:15 -0500 Subject: [Freeipa-users] Aiisues to wathc out fro / anticipate when upgrading RHEL6.3 and IPA 2 to 6.4 and IPA 3 In-Reply-To: <50EC9BC2.8090204@gmail.com> References: <833D8E48405E064EBC54C84EC6B36E40547A12B2@STAWINCOX10MBX1.staff.vuw.ac.nz> <1357676428.29147.39.camel@willson.li.ssimo.org> <50EC8529.3090200@redhat.com> <50EC8647.104@gmail.com> <50EC938C.2020603@redhat.com> <50EC9BC2.8090204@gmail.com> Message-ID: <50EC9E6F.8090105@redhat.com> On 01/08/2013 05:20 PM, Erinn Looney-Triggs wrote: > On 01/08/13 12:45, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> On 01/08/13 11:44, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> On Tue, 2013-01-08 at 19:31 +0000, Steven Jones wrote: >>>>>> HI, >>>>>> >>>>>> I assume RHEL 6.4 is GA shortly just how straigh forward is the >>>>>> upgrade from one IPA version to another please? >>>>>> regards >>>>> Should just require an rpm upgrade and a restart and nothing else. >>>>> >>>>> Simo. >>>>> >>>> If you have multiple servers you'll want to upgrade them one at a time >>>> in a short period (days, not weeks). >>>> >>>> rob >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Is this the release where SELinux mapping in IPA actually starts working? >>> >>> If so that is definitely something to watch out for (I realize this is >>> more of an SSSD thing, but still). If you aren't careful and you have >>> your users mapped to something like guest_u, well the upgrade can be >>> very inconvenient for them. >> I believe this was fixed. >> >> rob > Ok I am just going off of this: > https://bugzilla.redhat.com/show_bug.cgi?id=887193 which makes it appear > like it will be documented but there isn't much you can do about the > default being set to guest_u. > > However, if it is fixed that is great news. You are right. People should prepare for the update by changing the default SELinux user mapping setting in the existing deployments as mentioned in the bug. There will be a release note. > > -Erinn > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Jan 9 07:59:02 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 09 Jan 2013 08:59:02 +0100 Subject: [Freeipa-users] Setting up single domain but with dns subdomains In-Reply-To: <50EC6E1D.30605@redhat.com> References: <50EC6BB5.50409@cora.nwra.com> <50EC6E1D.30605@redhat.com> Message-ID: <50ED2346.8010503@redhat.com> On 8.1.2013 20:06, Rob Crittenden wrote: > Orion Poplawski wrote: >> I'm looking into migrating our 389ds ldap + kerberos to FreeIPA and I'm >> wondering how to setup DNS autodiscovery (if possible) in a way to point >> to different servers in different locations. >> >> We have two major offices, one that uses the "nwra.com" dnsdomain and >> one that uses the "cora.nwra.com" dns subdomain. We're planning on >> using the NWRA.COM domain for IPA/kerberos. I'd like to have the hosts >> is the "cora" office use the local servers instead of the one at the >> main office. Is this possible? While I can have: >> >> _ldap._tcp.cora.nwra.com. SRV 0 0 636 ipa.cora.nwra.com. >> >> If I have: >> >> _kerberos.cora.nwra.com. TXT "NWRA.COM" >> >> it will then automatically look for: >> >> _kerberos._udp.nwra.com. SRV >> >> Which will hold the servers for the other office. >> >> Any suggestions? >> > > We don't have a good solution for region-specific enrollment right now. There > is ticket open, https://fedorahosted.org/freeipa/ticket/2008 > > In 3.0 we added better capabilities for bypassing discovery using --server and > --fixed-primary in ipa-client-install. You could use BIND views to return different SRV records to each location, but it will work only if you don't use IPA-integrated DNS (bind-dyndb-ldap). Unfortunately there is no good solution with IPA integrated DNS. -- Petr^2 Spacek From mkosek at redhat.com Wed Jan 9 09:02:19 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Jan 2013 10:02:19 +0100 Subject: [Freeipa-users] Aiisues to wathc out fro / anticipate when upgrading RHEL6.3 and IPA 2 to 6.4 and IPA 3 In-Reply-To: <50EC9BC2.8090204@gmail.com> References: <833D8E48405E064EBC54C84EC6B36E40547A12B2@STAWINCOX10MBX1.staff.vuw.ac.nz> <1357676428.29147.39.camel@willson.li.ssimo.org> <50EC8529.3090200@redhat.com> <50EC8647.104@gmail.com> <50EC938C.2020603@redhat.com> <50EC9BC2.8090204@gmail.com> Message-ID: <50ED321B.6090004@redhat.com> On 01/08/2013 11:20 PM, Erinn Looney-Triggs wrote: > On 01/08/13 12:45, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> On 01/08/13 11:44, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> On Tue, 2013-01-08 at 19:31 +0000, Steven Jones wrote: >>>>>> HI, >>>>>> >>>>>> I assume RHEL 6.4 is GA shortly just how straigh forward is the >>>>>> upgrade from one IPA version to another please? regards >>>>> >>>>> Should just require an rpm upgrade and a restart and nothing >>>>> else. >>>>> >>>>> Simo. >>>>> >>>> >>>> If you have multiple servers you'll want to upgrade them one at a >>>> time in a short period (days, not weeks). >>>> >>>> rob >>>> >>>> _______________________________________________ Freeipa-users >>>> mailing list Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> Is this the release where SELinux mapping in IPA actually starts >>> working? >>> >>> If so that is definitely something to watch out for (I realize this >>> is more of an SSSD thing, but still). If you aren't careful and you >>> have your users mapped to something like guest_u, well the upgrade can >>> be very inconvenient for them. >> >> I believe this was fixed. >> >> rob > > Ok I am just going off of this: > https://bugzilla.redhat.com/show_bug.cgi?id=887193 which makes it appear > like it will be documented but there isn't much you can do about the > default being set to guest_u. > > However, if it is fixed that is great news. > > -Erinn Hello Erinn, Just to make things clear, it is "fixed" by means that it is documented and the new default SELinux user is unconfined_u:s0-s0:c0.c1023. But this only applies for new IPA server installations. As for the upgraded installs, you want to check default SELinux user to ensure that it is set to a value that you want (probably unconfined_u:s0-s0:c0.c1023). We could not forcefully change it from guest_u to unconfined_u:s0-s0:c0.c1023 in the upgrade process as we cannot know if some user does not have it set to guest_u on purpose. Thanks for understanding, Martin From umarzuki at gmail.com Wed Jan 9 14:27:19 2013 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Wed, 9 Jan 2013 22:27:19 +0800 Subject: [Freeipa-users] how do i apply patch? Message-ID: i'm interested on patch https://fedorahosted.org/freeipa/changeset/1eab43d29244f6e0b8d6f3146317624715d84af7/ so i can have user to be able to reset own password do i manually edit each listed files or is there any specific step(s) needed? -- Regards, Umarzuki Mochlis http://debmal.my From pvoborni at redhat.com Wed Jan 9 15:39:49 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 09 Jan 2013 16:39:49 +0100 Subject: [Freeipa-users] how do i apply patch? In-Reply-To: References: Message-ID: <50ED8F45.6030204@redhat.com> On 01/09/2013 03:27 PM, Umarzuki Mochlis wrote: > i'm interested on patch > https://fedorahosted.org/freeipa/changeset/1eab43d29244f6e0b8d6f3146317624715d84af7/ > so i can have user to be able to reset own password > > do i manually edit each listed files or is there any specific step(s) needed? > These patches (in a form sent to freeipa-devel-list) are generated by using 'git format-patch' command and are supposed to be applied using 'git am' or 'git apply' command. They can be also applied on source codes using 'patch' utility. http://stackoverflow.com/questions/3418277/how-to-apply-git-diff-patch-without-git-installed If you work with our git repository the easiest way might be 'git cherry-pick'. From your question isn't clear whether you want to patch source codes of some release (ie. 2.2) and then build a custom build or you want to modify already installed server. I suspect the latter. In both cases you might run into a problem that the patch does not apply because it depends on some modifications done by some previous patch. It seems that you want to add password reset functionality to FreeIPA 2.2. If that is the case you should also look at https://fedorahosted.org/freeipa/attachment/ticket/2276/freeipa-mkosek-274-password-change-capability-for-form-based-auth.patch because this one adds the core functionality which the UI page uses. If you manage to incorporate Martin's patch, you should just use install/ui/reset_password.html and install/ui/reset_password.js and the modifications in install/ui/ipa.css from the changeset you linked. In any case I do not recommend to such modifications. They have high potential to break things. HTH -- Petr Vobornik From mkosek at redhat.com Wed Jan 9 16:30:46 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Jan 2013 17:30:46 +0100 Subject: [Freeipa-users] how do i apply patch? In-Reply-To: <50ED8F45.6030204@redhat.com> References: <50ED8F45.6030204@redhat.com> Message-ID: <50ED9B36.3030909@redhat.com> On 01/09/2013 04:39 PM, Petr Vobornik wrote: > On 01/09/2013 03:27 PM, Umarzuki Mochlis wrote: >> i'm interested on patch >> https://fedorahosted.org/freeipa/changeset/1eab43d29244f6e0b8d6f3146317624715d84af7/ >> >> so i can have user to be able to reset own password >> >> do i manually edit each listed files or is there any specific step(s) needed? >> > > These patches (in a form sent to freeipa-devel-list) are generated by using > 'git format-patch' command and are supposed to be applied using 'git am' or > 'git apply' command. They can be also applied on source codes using 'patch' > utility. > > http://stackoverflow.com/questions/3418277/how-to-apply-git-diff-patch-without-git-installed > > > If you work with our git repository the easiest way might be 'git cherry-pick'. > > From your question isn't clear whether you want to patch source codes of some > release (ie. 2.2) and then build a custom build or you want to modify already > installed server. I suspect the latter. > > In both cases you might run into a problem that the patch does not apply > because it depends on some modifications done by some previous patch. > > It seems that you want to add password reset functionality to FreeIPA 2.2. If > that is the case you should also look at > https://fedorahosted.org/freeipa/attachment/ticket/2276/freeipa-mkosek-274-password-change-capability-for-form-based-auth.patch > because this one adds the core functionality which the UI page uses. If you > manage to incorporate Martin's patch, you should just use > install/ui/reset_password.html and install/ui/reset_password.js and the > modifications in install/ui/ipa.css from the changeset you linked. In any case > I do not recommend to such modifications. They have high potential to break > things. > > HTH Hello Umarzuki, You can use the steps that Petr suggested. Just please be cautious about my patch 274 that Petr sent an URL to. This was a first proposal of the patch, the resulting patch crafted after the review process is much different. This is the correct link: https://fedorahosted.org/freeipa/changeset/d1e695b5d0323167d37eee340718eb5e65138716/ If you want to do a custom build, you can either use a fedpkg and create a scratch build of IPA with the patches applied or do a custom build from git tree. Using the fedpkg tool + build in koji may be the safest way to build such rpm that contain only the official build + chosen patches. Martin From erinn.looneytriggs at gmail.com Wed Jan 9 19:33:23 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 09 Jan 2013 10:33:23 -0900 Subject: [Freeipa-users] Aiisues to wathc out fro / anticipate when upgrading RHEL6.3 and IPA 2 to 6.4 and IPA 3 In-Reply-To: <50ED321B.6090004@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40547A12B2@STAWINCOX10MBX1.staff.vuw.ac.nz> <1357676428.29147.39.camel@willson.li.ssimo.org> <50EC8529.3090200@redhat.com> <50EC8647.104@gmail.com> <50EC938C.2020603@redhat.com> <50EC9BC2.8090204@gmail.com> <50ED321B.6090004@redhat.com> Message-ID: <50EDC603.4020507@gmail.com> On 01/09/13 00:02, Martin Kosek wrote: > On 01/08/2013 11:20 PM, Erinn Looney-Triggs wrote: >> On 01/08/13 12:45, Rob Crittenden wrote: >>> Erinn Looney-Triggs wrote: >>>> On 01/08/13 11:44, Rob Crittenden wrote: >>>>> Simo Sorce wrote: >>>>>> On Tue, 2013-01-08 at 19:31 +0000, Steven Jones wrote: >>>>>>> HI, >>>>>>> >>>>>>> I assume RHEL 6.4 is GA shortly just how straigh forward is the >>>>>>> upgrade from one IPA version to another please? regards >>>>>> >>>>>> Should just require an rpm upgrade and a restart and nothing >>>>>> else. >>>>>> >>>>>> Simo. >>>>>> >>>>> >>>>> If you have multiple servers you'll want to upgrade them one at a >>>>> time in a short period (days, not weeks). >>>>> >>>>> rob >>>>> >>>>> _______________________________________________ Freeipa-users >>>>> mailing list Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> Is this the release where SELinux mapping in IPA actually starts >>>> working? >>>> >>>> If so that is definitely something to watch out for (I realize this >>>> is more of an SSSD thing, but still). If you aren't careful and you >>>> have your users mapped to something like guest_u, well the upgrade can >>>> be very inconvenient for them. >>> >>> I believe this was fixed. >>> >>> rob >> >> Ok I am just going off of this: >> https://bugzilla.redhat.com/show_bug.cgi?id=887193 which makes it appear >> like it will be documented but there isn't much you can do about the >> default being set to guest_u. >> >> However, if it is fixed that is great news. >> >> -Erinn > > Hello Erinn, > Just to make things clear, it is "fixed" by means that it is documented and > the new default SELinux user is unconfined_u:s0-s0:c0.c1023. But this only > applies for new IPA server installations. As for the upgraded installs, you > want to check default SELinux user to ensure that it is set to a value that > you want (probably unconfined_u:s0-s0:c0.c1023). > > We could not forcefully change it from guest_u to unconfined_u:s0-s0:c0.c1023 > in the upgrade process as we cannot know if some user does not have it set to > guest_u on purpose. > > Thanks for understanding, > Martin > Yep I understood all that and the reasoning behind it. The only thing I was trying to say was that while documenting it in the release notes is a nice and necessary step, if there are other channels to let folks know about this, like say an e-mail list, it might be worthwhile as well. This is just a suggestion. Not all folks read the release notes, which of course they all should, and this change can lead to some rather surprising results for those of us who ended up with guest_u by default. As I said I just got lucky in some ways by running Fedora 18 against my IPA servers I was able to only cause issues for myself. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From pspacek at redhat.com Thu Jan 10 13:15:09 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 10 Jan 2013 14:15:09 +0100 Subject: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be? Message-ID: <50EEBEDD.5040306@redhat.com> Hello, is there any user of CSV support built-in to IPA administration tools ("ipa" command)? Do you consider it sane or even useful? Please reply. I wanted to add single TXT record with double quotation marks (") inside the TXT data. I spent some time figuring out how it is supposed to work ... and with help of Petr^3 I managed to write the command. The resulting command (for BASH) is absolutely crazy: ipa dnsrecord-add example.test. newrec --txt-rec='"""created on 13:01:23"""' Do we really need support for this piece of insanity? Shells can do the same thing with much less pain :-) IPA with CSV support can add multiple attributes at once, e.g. ipa dnsrecord-add example.test. newrec --txt-rec=1,2,3,4,5,6,7,8,9 will add TXT records with value 1, 2, 3 etc. BASH can do the same thing (without the escaping hell): ipa dnsrecord-add example.test. newrec --txt-rec={1,2,3,4,5,6,7,8,9} and ipa dnsrecord-add example.test. newrec --txt-rec={1..9} BASH would expand to ipa dnsrecord-add example.test. newrec --txt-rec=1 --txt-rec=2 --txt-rec=3 --txt-rec=4 --txt-rec=5 --txt-rec=6 --txt-rec=7 --txt-rec=8 --txt-rec=9 -- Petr^2 Spacek From jdennis at redhat.com Thu Jan 10 16:00:20 2013 From: jdennis at redhat.com (John Dennis) Date: Thu, 10 Jan 2013 11:00:20 -0500 Subject: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be? In-Reply-To: <50EEBEDD.5040306@redhat.com> References: <50EEBEDD.5040306@redhat.com> Message-ID: <50EEE594.3070300@redhat.com> On 01/10/2013 08:15 AM, Petr Spacek wrote: > Hello, > > is there any user of CSV support built-in to IPA administration tools ("ipa" > command)? Do you consider it sane or even useful? Please reply. I've always disliked our use of CSV values on both the command line and internally. They're just weird, nothing else in Unix works like this and as you point out below there are easier better alternatives. Plus with the use of CSV's there is a lot of awkward quoting in a variety of places. On the command line I always thought multiple values should be specified multiple times and internally they should be encapsulated in lists rather than parsing a CSV string (if it's logically a list then why isn't it a list?) However at this juncture I'm not sure we can make such a change, we have a published API that we would be violating. But perhaps we're not so far down the road we can't make such a change and we're better off doing it now while there is even a chance. It's not clear to me how much the command line is being used and specifically with CSV values. Do I think CSV's are sane and useful? No. Can we change that? That's a whole other story. > I wanted to add single TXT record with double quotation marks (") inside the > TXT data. > > I spent some time figuring out how it is supposed to work ... and with help of > Petr^3 I managed to write the command. > > The resulting command (for BASH) is absolutely crazy: > ipa dnsrecord-add example.test. newrec --txt-rec='"""created on 13:01:23"""' > > Do we really need support for this piece of insanity? Shells can do the same > thing with much less pain :-) > > IPA with CSV support can add multiple attributes at once, e.g. > ipa dnsrecord-add example.test. newrec --txt-rec=1,2,3,4,5,6,7,8,9 > will add TXT records with value 1, 2, 3 etc. > > BASH can do the same thing (without the escaping hell): > ipa dnsrecord-add example.test. newrec --txt-rec={1,2,3,4,5,6,7,8,9} > and > ipa dnsrecord-add example.test. newrec --txt-rec={1..9} > BASH would expand to > ipa dnsrecord-add example.test. newrec --txt-rec=1 --txt-rec=2 --txt-rec=3 > --txt-rec=4 --txt-rec=5 --txt-rec=6 --txt-rec=7 --txt-rec=8 --txt-rec=9 > -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From orion at cora.nwra.com Thu Jan 10 21:59:55 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 10 Jan 2013 14:59:55 -0700 Subject: [Freeipa-users] db2bak.pl and db2ldif utils Message-ID: <50EF39DB.9030609@cora.nwra.com> With our current 389ds installs we are making use of the db2bak.pl and db2ldif utilities to backup the ds database. Looking at my ipa 2.2.0 install these scripts were create for the PKI-IPA ds server in /usr/lib64/dirsrv/slapd-PKI-IPA but not for the domain ds instance. I suppose this is already address in 3.1 since it only creates a single instance. Are there any IPA backup utilities on the horizon? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From rmeggins at redhat.com Thu Jan 10 22:22:04 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 10 Jan 2013 15:22:04 -0700 Subject: [Freeipa-users] db2bak.pl and db2ldif utils In-Reply-To: <50EF39DB.9030609@cora.nwra.com> References: <50EF39DB.9030609@cora.nwra.com> Message-ID: <50EF3F0C.3030701@redhat.com> On 01/10/2013 02:59 PM, Orion Poplawski wrote: > With our current 389ds installs we are making use of the db2bak.pl and > db2ldif utilities to backup the ds database. Looking at my ipa 2.2.0 > install these scripts were create for the PKI-IPA ds server in > /usr/lib64/dirsrv/slapd-PKI-IPA but not for the domain ds instance. They are in /var/lib/dirsrv/scripts-INSTANCE > I suppose this is already address in 3.1 since it only creates a > single instance. > > Are there any IPA backup utilities on the horizon? > From orion at cora.nwra.com Thu Jan 10 22:29:35 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 10 Jan 2013 15:29:35 -0700 Subject: [Freeipa-users] db2bak.pl and db2ldif utils In-Reply-To: <50EF3F0C.3030701@redhat.com> References: <50EF39DB.9030609@cora.nwra.com> <50EF3F0C.3030701@redhat.com> Message-ID: <50EF40CF.5060009@cora.nwra.com> On 01/10/2013 03:22 PM, Rich Megginson wrote: > On 01/10/2013 02:59 PM, Orion Poplawski wrote: >> With our current 389ds installs we are making use of the db2bak.pl and >> db2ldif utilities to backup the ds database. Looking at my ipa 2.2.0 >> install these scripts were create for the PKI-IPA ds server in >> /usr/lib64/dirsrv/slapd-PKI-IPA but not for the domain ds instance. > > They are in /var/lib/dirsrv/scripts-INSTANCE Hah, that's funny. I just didn't check after seeing the /usr/lib64/dirsrv/slapd-PKI-IPA directory. Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From orion at cora.nwra.com Thu Jan 10 22:45:08 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 10 Jan 2013 15:45:08 -0700 Subject: [Freeipa-users] db2bak.pl and db2ldif utils In-Reply-To: <50EF40CF.5060009@cora.nwra.com> References: <50EF39DB.9030609@cora.nwra.com> <50EF3F0C.3030701@redhat.com> <50EF40CF.5060009@cora.nwra.com> Message-ID: <50EF4474.9090707@cora.nwra.com> On 01/10/2013 03:29 PM, Orion Poplawski wrote: > On 01/10/2013 03:22 PM, Rich Megginson wrote: >> On 01/10/2013 02:59 PM, Orion Poplawski wrote: >>> With our current 389ds installs we are making use of the db2bak.pl and >>> db2ldif utilities to backup the ds database. Looking at my ipa 2.2.0 >>> install these scripts were create for the PKI-IPA ds server in >>> /usr/lib64/dirsrv/slapd-PKI-IPA but not for the domain ds instance. >> >> They are in /var/lib/dirsrv/scripts-INSTANCE > > Hah, that's funny. I just didn't check after seeing the > /usr/lib64/dirsrv/slapd-PKI-IPA directory. Thanks! > > FWIW - Here's my current backup script (in /etc/cron.daily/dirsrv-backup). Did this: mv /usr/lib64/dirsrv/slapd-PKI-IPA /var/lib/dirsrv/scripts-PKI-IPA ln -s /var/lib/dirsrv/scripts-PKI-IPA /usr/lib64/dirsrv/slapd-PKI-IPA To make the two installs similar. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com -------------- next part -------------- #!/bin/bash # Backup each instance for dirsrv in /etc/dirsrv/slapd-* do name=${dirsrv/*slapd-/} vardir=/var/lib/dirsrv/slapd-${name} scriptdir=/var/lib/dirsrv/scripts-${name} ${scriptdir}/db2bak.pl -D 'cn=Directory Manager' -j /etc/ldap.secret -a ${vardir}/bak/${name}-`date +%Y_%m_%d_%H_%M_%S` > /dev/null /usr/sbin/tmpwatch -mM 240 ${vardir}/bak dbdir=${vardir}/db for dbentry in ${dbdir}/* do if [ -d ${dbentry} ] then dbname=$(basename ${dbentry}) ${scriptdir}/db2ldif -n ${dbname} > /dev/null fi done /usr/sbin/tmpwatch -mM 240 ${vardir}/ldif done From rmeggins at redhat.com Thu Jan 10 22:50:55 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 10 Jan 2013 15:50:55 -0700 Subject: [Freeipa-users] db2bak.pl and db2ldif utils In-Reply-To: <50EF4474.9090707@cora.nwra.com> References: <50EF39DB.9030609@cora.nwra.com> <50EF3F0C.3030701@redhat.com> <50EF40CF.5060009@cora.nwra.com> <50EF4474.9090707@cora.nwra.com> Message-ID: <50EF45CF.80504@redhat.com> On 01/10/2013 03:45 PM, Orion Poplawski wrote: > On 01/10/2013 03:29 PM, Orion Poplawski wrote: >> On 01/10/2013 03:22 PM, Rich Megginson wrote: >>> On 01/10/2013 02:59 PM, Orion Poplawski wrote: >>>> With our current 389ds installs we are making use of the db2bak.pl and >>>> db2ldif utilities to backup the ds database. Looking at my ipa 2.2.0 >>>> install these scripts were create for the PKI-IPA ds server in >>>> /usr/lib64/dirsrv/slapd-PKI-IPA but not for the domain ds instance. >>> >>> They are in /var/lib/dirsrv/scripts-INSTANCE >> >> Hah, that's funny. I just didn't check after seeing the >> /usr/lib64/dirsrv/slapd-PKI-IPA directory. Thanks! >> >> > > FWIW - > > Here's my current backup script (in /etc/cron.daily/dirsrv-backup). > Did this: > > mv /usr/lib64/dirsrv/slapd-PKI-IPA /var/lib/dirsrv/scripts-PKI-IPA > ln -s /var/lib/dirsrv/scripts-PKI-IPA /usr/lib64/dirsrv/slapd-PKI-IPA > > To make the two installs similar. > I don't recommend doing that as it may break upgrades and/or cause problems with selinux. But YMMV. From orion at cora.nwra.com Thu Jan 10 22:57:34 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 10 Jan 2013 15:57:34 -0700 Subject: [Freeipa-users] db2bak.pl and db2ldif utils In-Reply-To: <50EF45CF.80504@redhat.com> References: <50EF39DB.9030609@cora.nwra.com> <50EF3F0C.3030701@redhat.com> <50EF40CF.5060009@cora.nwra.com> <50EF4474.9090707@cora.nwra.com> <50EF45CF.80504@redhat.com> Message-ID: <50EF475E.3020302@cora.nwra.com> On 01/10/2013 03:50 PM, Rich Megginson wrote: > On 01/10/2013 03:45 PM, Orion Poplawski wrote: >> >> FWIW - >> >> Here's my current backup script (in /etc/cron.daily/dirsrv-backup). Did this: >> >> mv /usr/lib64/dirsrv/slapd-PKI-IPA /var/lib/dirsrv/scripts-PKI-IPA >> ln -s /var/lib/dirsrv/scripts-PKI-IPA /usr/lib64/dirsrv/slapd-PKI-IPA >> >> To make the two installs similar. >> > I don't recommend doing that as it may break upgrades and/or cause problems > with selinux. But YMMV. Okay, right you are. Here's a new script. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com -------------- next part -------------- #!/bin/bash # Backup each instance for dirsrv in /etc/dirsrv/slapd-* do name=${dirsrv/*slapd-/} vardir=/var/lib/dirsrv/slapd-${name} [ -d /var/lib/dirsrv/scripts-${name} ] && scriptdir=/var/lib/dirsrv/scripts-${name} [ -d /usr/lib64/dirsrv/slapd-${name} ] && scriptdir=/usr/lib64/dirsrv/slapd-${name} [ -d /usr/lib/dirsrv/slapd-${name} ] && scriptdir=/usr/lib/dirsrv/slapd-${name} ${scriptdir}/db2bak.pl -D 'cn=Directory Manager' -j /etc/ldap.secret -a ${vardir}/bak/${name}-`date +%Y_%m_%d_%H_%M_%S` > /dev/null /usr/sbin/tmpwatch -mM 240 ${vardir}/bak dbdir=${vardir}/db for dbentry in ${dbdir}/* do if [ -d ${dbentry} ] then dbname=$(basename ${dbentry}) ${scriptdir}/db2ldif -n ${dbname} > /dev/null fi done /usr/sbin/tmpwatch -mM 240 ${vardir}/ldif done From djuran at redhat.com Fri Jan 11 09:14:09 2013 From: djuran at redhat.com (David Juran) Date: Fri, 11 Jan 2013 10:14:09 +0100 Subject: [Freeipa-users] AD permissions needed for setting up AD trusts In-Reply-To: <50E719A8.2090103@redhat.com> References: <20121221113033.41120@gmx.com> <20121221121928.GB22856@localhost.localdomain> <50E56B40.8070309@redhat.com> <50E719A8.2090103@redhat.com> Message-ID: <1357895649.16998.18.camel@localhost.localdomain> On fre, 2013-01-04 at 19:04 +0100, Ana Krivokapic wrote: > On 01/03/2013 12:28 PM, Petr Spacek wrote: > > On 12/21/2012 01:19 PM, Sumit Bose wrote: > >> On Fri, Dec 21, 2012 at 12:30:33PM +0100, James Findley wrote: > >>> Hi > >>> > >>> What permission level is needed for the AD user when creating an AD > >>> trust? Can a regular domain user account do it, or is a domain > >>> admin needed? > >> > >> The account used here must be a member of the Domain Admins group. > >> > >>> > >>> If write access to the AD server is needed, then could someone > >>> please tell me what the command will actually change in the AD server? > >>> > >> > >> 'ipa trust-add' will only use LSA calls on the AD server. The most > >> important one is CreateTrustedDomainEx2 > >> (http://msdn.microsoft.com/en-us/library/cc234380.aspx) to create the > >> trust between the two domains. Additionally QueryTrustedDomainInfoByName > >> (http://msdn.microsoft.com/en-us/library/cc234376.aspx) to check if the > >> trust is already added and SetInformationTrustedDomain > >> (http://msdn.microsoft.com/en-us/library/cc234385.aspx) to tell the AD > >> server that the IPA server can handled AES encryption are used. > > > > Should we add this information to AD trusts documentation? > > > >>> The windows team at my place of work will want to know exactly what > >>> the tool will do before they grant permission. > > > I have added this information to the AD trusts wiki page: > http://www.freeipa.org/page/IPAv3_AD_trust_setup#Add_trust_with_AD_domain That link only gets me to an empty wiki page... -- David Juran Sr. Consultant Red Hat +46-725-345801 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From abokovoy at redhat.com Fri Jan 11 09:19:31 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 11 Jan 2013 11:19:31 +0200 Subject: [Freeipa-users] AD permissions needed for setting up AD trusts In-Reply-To: <1357895649.16998.18.camel@localhost.localdomain> References: <20121221113033.41120@gmx.com> <20121221121928.GB22856@localhost.localdomain> <50E56B40.8070309@redhat.com> <50E719A8.2090103@redhat.com> <1357895649.16998.18.camel@localhost.localdomain> Message-ID: <20130111091931.GE8651@redhat.com> On Fri, 11 Jan 2013, David Juran wrote: >On fre, 2013-01-04 at 19:04 +0100, Ana Krivokapic wrote: >> On 01/03/2013 12:28 PM, Petr Spacek wrote: >> > On 12/21/2012 01:19 PM, Sumit Bose wrote: >> >> On Fri, Dec 21, 2012 at 12:30:33PM +0100, James Findley wrote: >> >>> Hi >> >>> >> >>> What permission level is needed for the AD user when creating an AD >> >>> trust? Can a regular domain user account do it, or is a domain >> >>> admin needed? >> >> >> >> The account used here must be a member of the Domain Admins group. >> >> >> >>> >> >>> If write access to the AD server is needed, then could someone >> >>> please tell me what the command will actually change in the AD server? >> >>> >> >> >> >> 'ipa trust-add' will only use LSA calls on the AD server. The most >> >> important one is CreateTrustedDomainEx2 >> >> (http://msdn.microsoft.com/en-us/library/cc234380.aspx) to create the >> >> trust between the two domains. Additionally QueryTrustedDomainInfoByName >> >> (http://msdn.microsoft.com/en-us/library/cc234376.aspx) to check if the >> >> trust is already added and SetInformationTrustedDomain >> >> (http://msdn.microsoft.com/en-us/library/cc234385.aspx) to tell the AD >> >> server that the IPA server can handled AES encryption are used. >> > >> > Should we add this information to AD trusts documentation? >> > >> >>> The windows team at my place of work will want to know exactly what >> >>> the tool will do before they grant permission. >> > >> I have added this information to the AD trusts wiki page: >> http://www.freeipa.org/page/IPAv3_AD_trust_setup#Add_trust_with_AD_domain > >That link only gets me to an empty wiki page... It is moved to HOWTOs: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Add_trust_with_AD_domain -- / Alexander Bokovoy From pspacek at redhat.com Fri Jan 11 09:52:32 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 11 Jan 2013 10:52:32 +0100 Subject: [Freeipa-users] AD permissions needed for setting up AD trusts In-Reply-To: <20130111091931.GE8651@redhat.com> References: <20121221113033.41120@gmx.com> <20121221121928.GB22856@localhost.localdomain> <50E56B40.8070309@redhat.com> <50E719A8.2090103@redhat.com> <1357895649.16998.18.camel@localhost.localdomain> <20130111091931.GE8651@redhat.com> Message-ID: <50EFE0E0.7040404@redhat.com> On 11.1.2013 10:19, Alexander Bokovoy wrote: > On Fri, 11 Jan 2013, David Juran wrote: >> On fre, 2013-01-04 at 19:04 +0100, Ana Krivokapic wrote: >>> On 01/03/2013 12:28 PM, Petr Spacek wrote: >>> > On 12/21/2012 01:19 PM, Sumit Bose wrote: >>> >> On Fri, Dec 21, 2012 at 12:30:33PM +0100, James Findley wrote: >>> >>> Hi >>> >>> >>> >>> What permission level is needed for the AD user when creating an AD >>> >>> trust? Can a regular domain user account do it, or is a domain >>> >>> admin needed? >>> >> >>> >> The account used here must be a member of the Domain Admins group. >>> >> >>> >>> >>> >>> If write access to the AD server is needed, then could someone >>> >>> please tell me what the command will actually change in the AD server? >>> >>> >>> >> >>> >> 'ipa trust-add' will only use LSA calls on the AD server. The most >>> >> important one is CreateTrustedDomainEx2 >>> >> (http://msdn.microsoft.com/en-us/library/cc234380.aspx) to create the >>> >> trust between the two domains. Additionally QueryTrustedDomainInfoByName >>> >> (http://msdn.microsoft.com/en-us/library/cc234376.aspx) to check if the >>> >> trust is already added and SetInformationTrustedDomain >>> >> (http://msdn.microsoft.com/en-us/library/cc234385.aspx) to tell the AD >>> >> server that the IPA server can handled AES encryption are used. >>> > >>> > Should we add this information to AD trusts documentation? >>> > >>> >>> The windows team at my place of work will want to know exactly what >>> >>> the tool will do before they grant permission. >>> > >>> I have added this information to the AD trusts wiki page: >>> http://www.freeipa.org/page/IPAv3_AD_trust_setup#Add_trust_with_AD_domain >> >> That link only gets me to an empty wiki page... > It is moved to HOWTOs: > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Add_trust_with_AD_domain Should we create a redirection? At least for users digging in archives? -- Petr^2 Spacek From abokovoy at redhat.com Fri Jan 11 10:03:04 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 11 Jan 2013 12:03:04 +0200 Subject: [Freeipa-users] AD permissions needed for setting up AD trusts In-Reply-To: <50EFE0E0.7040404@redhat.com> References: <20121221113033.41120@gmx.com> <20121221121928.GB22856@localhost.localdomain> <50E56B40.8070309@redhat.com> <50E719A8.2090103@redhat.com> <1357895649.16998.18.camel@localhost.localdomain> <20130111091931.GE8651@redhat.com> <50EFE0E0.7040404@redhat.com> Message-ID: <20130111100304.GF8651@redhat.com> On Fri, 11 Jan 2013, Petr Spacek wrote: >On 11.1.2013 10:19, Alexander Bokovoy wrote: >>On Fri, 11 Jan 2013, David Juran wrote: >>>On fre, 2013-01-04 at 19:04 +0100, Ana Krivokapic wrote: >>>>On 01/03/2013 12:28 PM, Petr Spacek wrote: >>>>> On 12/21/2012 01:19 PM, Sumit Bose wrote: >>>>>> On Fri, Dec 21, 2012 at 12:30:33PM +0100, James Findley wrote: >>>>>>> Hi >>>>>>> >>>>>>> What permission level is needed for the AD user when creating an AD >>>>>>> trust? Can a regular domain user account do it, or is a domain >>>>>>> admin needed? >>>>>> >>>>>> The account used here must be a member of the Domain Admins group. >>>>>> >>>>>>> >>>>>>> If write access to the AD server is needed, then could someone >>>>>>> please tell me what the command will actually change in the AD server? >>>>>>> >>>>>> >>>>>> 'ipa trust-add' will only use LSA calls on the AD server. The most >>>>>> important one is CreateTrustedDomainEx2 >>>>>> (http://msdn.microsoft.com/en-us/library/cc234380.aspx) to create the >>>>>> trust between the two domains. Additionally QueryTrustedDomainInfoByName >>>>>> (http://msdn.microsoft.com/en-us/library/cc234376.aspx) to check if the >>>>>> trust is already added and SetInformationTrustedDomain >>>>>> (http://msdn.microsoft.com/en-us/library/cc234385.aspx) to tell the AD >>>>>> server that the IPA server can handled AES encryption are used. >>>>> >>>>> Should we add this information to AD trusts documentation? >>>>> >>>>>>> The windows team at my place of work will want to know exactly what >>>>>>> the tool will do before they grant permission. >>>>> >>>>I have added this information to the AD trusts wiki page: >>>>http://www.freeipa.org/page/IPAv3_AD_trust_setup#Add_trust_with_AD_domain >>> >>>That link only gets me to an empty wiki page... >>It is moved to HOWTOs: >>http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Add_trust_with_AD_domain > >Should we create a redirection? At least for users digging in archives? Yes, please do that. -- / Alexander Bokovoy From simo at redhat.com Fri Jan 11 13:21:51 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 11 Jan 2013 08:21:51 -0500 Subject: [Freeipa-users] AD permissions needed for setting up AD trusts In-Reply-To: <50EFE0E0.7040404@redhat.com> References: <20121221113033.41120@gmx.com> <20121221121928.GB22856@localhost.localdomain> <50E56B40.8070309@redhat.com> <50E719A8.2090103@redhat.com> <1357895649.16998.18.camel@localhost.localdomain> <20130111091931.GE8651@redhat.com> <50EFE0E0.7040404@redhat.com> Message-ID: <1357910511.15136.27.camel@willson.li.ssimo.org> On Fri, 2013-01-11 at 10:52 +0100, Petr Spacek wrote: > On 11.1.2013 10:19, Alexander Bokovoy wrote: > > On Fri, 11 Jan 2013, David Juran wrote: > >> On fre, 2013-01-04 at 19:04 +0100, Ana Krivokapic wrote: > >>> On 01/03/2013 12:28 PM, Petr Spacek wrote: > >>> > On 12/21/2012 01:19 PM, Sumit Bose wrote: > >>> >> On Fri, Dec 21, 2012 at 12:30:33PM +0100, James Findley wrote: > >>> >>> Hi > >>> >>> > >>> >>> What permission level is needed for the AD user when creating an AD > >>> >>> trust? Can a regular domain user account do it, or is a domain > >>> >>> admin needed? > >>> >> > >>> >> The account used here must be a member of the Domain Admins group. > >>> >> > >>> >>> > >>> >>> If write access to the AD server is needed, then could someone > >>> >>> please tell me what the command will actually change in the AD server? > >>> >>> > >>> >> > >>> >> 'ipa trust-add' will only use LSA calls on the AD server. The most > >>> >> important one is CreateTrustedDomainEx2 > >>> >> (http://msdn.microsoft.com/en-us/library/cc234380.aspx) to create the > >>> >> trust between the two domains. Additionally QueryTrustedDomainInfoByName > >>> >> (http://msdn.microsoft.com/en-us/library/cc234376.aspx) to check if the > >>> >> trust is already added and SetInformationTrustedDomain > >>> >> (http://msdn.microsoft.com/en-us/library/cc234385.aspx) to tell the AD > >>> >> server that the IPA server can handled AES encryption are used. > >>> > > >>> > Should we add this information to AD trusts documentation? > >>> > > >>> >>> The windows team at my place of work will want to know exactly what > >>> >>> the tool will do before they grant permission. > >>> > > >>> I have added this information to the AD trusts wiki page: > >>> http://www.freeipa.org/page/IPAv3_AD_trust_setup#Add_trust_with_AD_domain > >> > >> That link only gets me to an empty wiki page... > > It is moved to HOWTOs: > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Add_trust_with_AD_domain > > Should we create a redirection? At least for users digging in archives? I actually explicitly removed it to avoid clutter in the root :) Simo. -- Simo Sorce * Red Hat, Inc * New York From natxo.asenjo at gmail.com Fri Jan 11 14:15:23 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 11 Jan 2013 15:15:23 +0100 Subject: [Freeipa-users] error adding replica In-Reply-To: <50CA7472.5000706@redhat.com> References: <50BCCA3D.6070807@redhat.com> <50C20B07.3040805@redhat.com> <50C92552.3080908@redhat.com> <50CA7472.5000706@redhat.com> Message-ID: On Fri, Dec 14, 2012 at 1:36 AM, Dmitri Pal wrote: > On 12/13/2012 03:48 AM, Natxo Asenjo wrote: >> hi, >> >> On Thu, Dec 13, 2012 at 1:46 AM, Dmitri Pal wrote: >>> The holidays are coming. It is unlikely that we would be able to look >>> into it till Jan. >> that is no problem at all, we have the same issues ;-) >> >> Do you want me to keep the vm's around for troubleshooting the issue >> when there is time? >> > Would be great if you would be able to start this thread over after the > holidays to draw our attention. > So at that time every detail would be handy. hi, I just tried again to create a replica and had exactly the same error as on the thread's first post. in ipareplica-install.log I get "The pkcs12 file is not correct." error. -- groet, natxo From rcritten at redhat.com Fri Jan 11 14:51:59 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Jan 2013 09:51:59 -0500 Subject: [Freeipa-users] error adding replica In-Reply-To: References: <50BCCA3D.6070807@redhat.com> <50C20B07.3040805@redhat.com> <50C92552.3080908@redhat.com> <50CA7472.5000706@redhat.com> Message-ID: <50F0270F.6010701@redhat.com> Natxo Asenjo wrote: > On Fri, Dec 14, 2012 at 1:36 AM, Dmitri Pal wrote: >> On 12/13/2012 03:48 AM, Natxo Asenjo wrote: >>> hi, >>> >>> On Thu, Dec 13, 2012 at 1:46 AM, Dmitri Pal wrote: >>>> The holidays are coming. It is unlikely that we would be able to look >>>> into it till Jan. >>> that is no problem at all, we have the same issues ;-) >>> >>> Do you want me to keep the vm's around for troubleshooting the issue >>> when there is time? >>> >> Would be great if you would be able to start this thread over after the >> holidays to draw our attention. >> So at that time every detail would be handy. > > hi, > > I just tried again to create a replica and had exactly the same error > as on the thread's first post. > > in ipareplica-install.log I get "The pkcs12 file is not correct." error. > Can you send me the log file /var/log/pki-ca/debug out-of-band? I'll pass that long to the dogtag guys who can hopefully tell us what is going on. I'd need the log from both the IPA Master that you are installing and the one that generated the replica file. The files can be big, gzipping is appreciate :-) thanks rob From john at ox-consulting.com Fri Jan 11 16:05:25 2013 From: john at ox-consulting.com (Johnathan Phan) Date: Fri, 11 Jan 2013 16:05:25 +0000 Subject: [Freeipa-users] openldap to ipa Message-ID: Hi There, This is driving me up the wall. I have two servers. 1 is a live openldap/kerberous AAA server running on RHEL6. The LDAP service has SSL/TS support. The second server is a test environment running on fedora and has 3.1 IPA installed. As a last step of my POC I need to migrate the users and passwords from the LDAP server to IPA server. I ran this command perfectly fine. ipa config-mod --enable-migration=TRUE However the next step was where my issues began. In the end after a lot of IRC communication and troubleshooting I now run the following command. ipa migrate-ds --bind-dn="cn=admin,dc=example,dc=com" --user-container="ou=users,ou=live,dc=example,dc=com" --group-container="ou=groups,ou=live,dc=example,dc=com" ldaps:// ldap1.live.example.com I get the following error. ipa: DEBUG: Caught fault 4203 from server http://fedoraipaserver.test.example.com/ipa/xml: Can't contact LDAP server: TLS error -8179:Peer's Certificate issuer is not recognized. ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: Can't contact LDAP server: TLS error -8179:Peer's Certificate issuer is not recognized. I have summarized that the IPA server does not trust the cert served by the openldap or the other way around. Does anyone know how to get around this? Or allow me to finish the migration of user data. Regards John -- Johnathan Phan T: +44 (0)784 118 7080 -------------- next part -------------- An HTML attachment was scrubbed... URL: From umarzuki at gmail.com Fri Jan 11 16:25:33 2013 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Sat, 12 Jan 2013 00:25:33 +0800 Subject: [Freeipa-users] how do i apply patch? In-Reply-To: <50ED9B36.3030909@redhat.com> References: <50ED8F45.6030204@redhat.com> <50ED9B36.3030909@redhat.com> Message-ID: 2013/1/10 Martin Kosek : > If you want to do a custom build, you can either use a fedpkg and create a > scratch build of IPA with the patches applied or do a custom build from git > tree. Using the fedpkg tool + build in koji may be the safest way to build > such rpm that contain only the official build + chosen patches. > > Martin Hi, what I want to do is simply patch free ipa with that patch from ipa-server 2.2.0 on my centos 6 any method that would retain current configuration? -- Regards, Umarzuki Mochlis http://debmal.my From jdennis at redhat.com Fri Jan 11 17:12:39 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 11 Jan 2013 12:12:39 -0500 Subject: [Freeipa-users] how do i apply patch? In-Reply-To: References: <50ED8F45.6030204@redhat.com> <50ED9B36.3030909@redhat.com> Message-ID: <50F04807.7080507@redhat.com> On 01/11/2013 11:25 AM, Umarzuki Mochlis wrote: > 2013/1/10 Martin Kosek : > >> If you want to do a custom build, you can either use a fedpkg and create a >> scratch build of IPA with the patches applied or do a custom build from git >> tree. Using the fedpkg tool + build in koji may be the safest way to build >> such rpm that contain only the official build + chosen patches. >> >> Martin > > Hi, what I want to do is simply patch free ipa with that patch from > ipa-server 2.2.0 on my centos 6 > > any method that would retain current configuration? > You can do one of two things. 1) Download the source rpm matching the version you have installed, add the patch, rebuild the rpm locally, install the locally built rpm. 2) Apply the patch to the installed code, this is manual, there are opportunities to mess up a running system unless you're careful and it's not reproducible. But it can be faster and more expedient, most IPA devs do this all the time to try out potential fixes because it's so easy to edit installed Python code. However, if the patch in question depends on post install update run by the RPM install this won't (easily) work. The safest thing is option 1, build a patched RPM. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From JR.Aquino at citrix.com Fri Jan 11 17:55:35 2013 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 11 Jan 2013 17:55:35 +0000 Subject: [Freeipa-users] openldap to ipa In-Reply-To: References: Message-ID: <3817AE3D-3005-4B2A-830D-2140865B0DFD@citrixonline.com> Try editing /etc/openldap/ldap.conf: TLS_CACERT /etc/ipa/ca.crt TLS_REQCERT allow See if that helps "Keeping your head in the cloud" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jr Aquino | Sr. Information Security Specialist GIAC Exploit Researcher and Advanced Penetration Tester | GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 C: +1 805.717.0365 jr.aquino at citrix.com http://www.citrixonline.com On Jan 11, 2013, at 8:05 AM, Johnathan Phan > wrote: Hi There, This is driving me up the wall. I have two servers. 1 is a live openldap/kerberous AAA server running on RHEL6. The LDAP service has SSL/TS support. The second server is a test environment running on fedora and has 3.1 IPA installed. As a last step of my POC I need to migrate the users and passwords from the LDAP server to IPA server. I ran this command perfectly fine. ipa config-mod --enable-migration=TRUE However the next step was where my issues began. In the end after a lot of IRC communication and troubleshooting I now run the following command. ipa migrate-ds --bind-dn="cn=admin,dc=example,dc=com" --user-container="ou=users,ou=live,dc=example,dc=com" --group-container="ou=groups,ou=live,dc=example,dc=com" ldaps://ldap1.live.example.com I get the following error. ipa: DEBUG: Caught fault 4203 from server http://fedoraipaserver.test.example.com/ipa/xml: Can't contact LDAP server: TLS error -8179:Peer's Certificate issuer is not recognized. ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: Can't contact LDAP server: TLS error -8179:Peer's Certificate issuer is not recognized. I have summarized that the IPA server does not trust the cert served by the openldap or the other way around. Does anyone know how to get around this? Or allow me to finish the migration of user data. Regards John -- Johnathan Phan T: +44 (0)784 118 7080 _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Fri Jan 11 20:10:55 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 11 Jan 2013 15:10:55 -0500 Subject: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be? In-Reply-To: <50EEE594.3070300@redhat.com> References: <50EEBEDD.5040306@redhat.com> <50EEE594.3070300@redhat.com> Message-ID: <50F071CF.4020305@redhat.com> On 01/10/2013 11:00 AM, John Dennis wrote: > On 01/10/2013 08:15 AM, Petr Spacek wrote: >> Hello, >> >> is there any user of CSV support built-in to IPA administration tools >> ("ipa" >> command)? Do you consider it sane or even useful? Please reply. > > I've always disliked our use of CSV values on both the command line > and internally. They're just weird, nothing else in Unix works like > this and as you point out below there are easier better alternatives. > Plus with the use of CSV's there is a lot of awkward quoting in a > variety of places. > > On the command line I always thought multiple values should be > specified multiple times and internally they should be encapsulated in > lists rather than parsing a CSV string (if it's logically a list then > why isn't it a list?) > > However at this juncture I'm not sure we can make such a change, we > have a published API that we would be violating. But perhaps we're not > so far down the road we can't make such a change and we're better off > doing it now while there is even a chance. It's not clear to me how > much the command line is being used and specifically with CSV values. > > Do I think CSV's are sane and useful? No. Can we change that? That's a > whole other story. > > >> I wanted to add single TXT record with double quotation marks (") >> inside the >> TXT data. >> >> I spent some time figuring out how it is supposed to work ... and >> with help of >> Petr^3 I managed to write the command. >> >> The resulting command (for BASH) is absolutely crazy: >> ipa dnsrecord-add example.test. newrec --txt-rec='"""created on >> 13:01:23"""' >> >> Do we really need support for this piece of insanity? Shells can do >> the same >> thing with much less pain :-) >> >> IPA with CSV support can add multiple attributes at once, e.g. >> ipa dnsrecord-add example.test. newrec --txt-rec=1,2,3,4,5,6,7,8,9 >> will add TXT records with value 1, 2, 3 etc. >> >> BASH can do the same thing (without the escaping hell): >> ipa dnsrecord-add example.test. newrec --txt-rec={1,2,3,4,5,6,7,8,9} >> and >> ipa dnsrecord-add example.test. newrec --txt-rec={1..9} >> BASH would expand to >> ipa dnsrecord-add example.test. newrec --txt-rec=1 --txt-rec=2 >> --txt-rec=3 >> --txt-rec=4 --txt-rec=5 --txt-rec=6 --txt-rec=7 --txt-rec=8 --txt-rec=9 >> > > Do we already have CSV support? Where is it used? It is not clear to me if BASH example above requires the CSV support or it does expansion on its own. Please explain. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Fri Jan 11 20:27:58 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 11 Jan 2013 15:27:58 -0500 Subject: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be? In-Reply-To: <50F071CF.4020305@redhat.com> References: <50EEBEDD.5040306@redhat.com> <50EEE594.3070300@redhat.com> <50F071CF.4020305@redhat.com> Message-ID: <50F075CE.5040905@redhat.com> On 01/11/2013 03:10 PM, Dmitri Pal wrote: > On 01/10/2013 11:00 AM, John Dennis wrote: >> On 01/10/2013 08:15 AM, Petr Spacek wrote: >>> Hello, >>> >>> is there any user of CSV support built-in to IPA administration tools >>> ("ipa" >>> command)? Do you consider it sane or even useful? Please reply. >> >> I've always disliked our use of CSV values on both the command line >> and internally. They're just weird, nothing else in Unix works like >> this and as you point out below there are easier better alternatives. >> Plus with the use of CSV's there is a lot of awkward quoting in a >> variety of places. >> >> On the command line I always thought multiple values should be >> specified multiple times and internally they should be encapsulated in >> lists rather than parsing a CSV string (if it's logically a list then >> why isn't it a list?) >> >> However at this juncture I'm not sure we can make such a change, we >> have a published API that we would be violating. But perhaps we're not >> so far down the road we can't make such a change and we're better off >> doing it now while there is even a chance. It's not clear to me how >> much the command line is being used and specifically with CSV values. >> >> Do I think CSV's are sane and useful? No. Can we change that? That's a >> whole other story. >> >> >>> I wanted to add single TXT record with double quotation marks (") >>> inside the >>> TXT data. >>> >>> I spent some time figuring out how it is supposed to work ... and >>> with help of >>> Petr^3 I managed to write the command. >>> >>> The resulting command (for BASH) is absolutely crazy: >>> ipa dnsrecord-add example.test. newrec --txt-rec='"""created on >>> 13:01:23"""' >>> >>> Do we really need support for this piece of insanity? Shells can do >>> the same >>> thing with much less pain :-) >>> >>> IPA with CSV support can add multiple attributes at once, e.g. >>> ipa dnsrecord-add example.test. newrec --txt-rec=1,2,3,4,5,6,7,8,9 >>> will add TXT records with value 1, 2, 3 etc. >>> >>> BASH can do the same thing (without the escaping hell): >>> ipa dnsrecord-add example.test. newrec --txt-rec={1,2,3,4,5,6,7,8,9} >>> and >>> ipa dnsrecord-add example.test. newrec --txt-rec={1..9} >>> BASH would expand to >>> ipa dnsrecord-add example.test. newrec --txt-rec=1 --txt-rec=2 >>> --txt-rec=3 >>> --txt-rec=4 --txt-rec=5 --txt-rec=6 --txt-rec=7 --txt-rec=8 --txt-rec=9 >>> >> >> > Do we already have CSV support? > Where is it used? > It is not clear to me if BASH example above requires the CSV support or > it does expansion on its own. Please explain. > We already have CSV support. It's a mechanism that allows multiple values to be passed for one command line argument. The alternate approach is rather than having one command line arg that takes multiple values is to allow multiple command line args, each one taking a single value. This is the UNIX methodology. I believe the original thinking was who would want to type out multiple command line args, it's too verbose. However the shell expansion illustrated above shows how with simple shell syntax one can have succicent args and allow the shell to expand them into the preferred verbose form. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Jan 11 20:52:23 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 11 Jan 2013 15:52:23 -0500 Subject: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be? In-Reply-To: <50F075CE.5040905@redhat.com> References: <50EEBEDD.5040306@redhat.com> <50EEE594.3070300@redhat.com> <50F071CF.4020305@redhat.com> <50F075CE.5040905@redhat.com> Message-ID: <50F07B87.4010102@redhat.com> On 01/11/2013 03:27 PM, John Dennis wrote: > On 01/11/2013 03:10 PM, Dmitri Pal wrote: >> On 01/10/2013 11:00 AM, John Dennis wrote: >>> On 01/10/2013 08:15 AM, Petr Spacek wrote: >>>> Hello, >>>> >>>> is there any user of CSV support built-in to IPA administration tools >>>> ("ipa" >>>> command)? Do you consider it sane or even useful? Please reply. >>> >>> I've always disliked our use of CSV values on both the command line >>> and internally. They're just weird, nothing else in Unix works like >>> this and as you point out below there are easier better alternatives. >>> Plus with the use of CSV's there is a lot of awkward quoting in a >>> variety of places. >>> >>> On the command line I always thought multiple values should be >>> specified multiple times and internally they should be encapsulated in >>> lists rather than parsing a CSV string (if it's logically a list then >>> why isn't it a list?) >>> >>> However at this juncture I'm not sure we can make such a change, we >>> have a published API that we would be violating. But perhaps we're not >>> so far down the road we can't make such a change and we're better off >>> doing it now while there is even a chance. It's not clear to me how >>> much the command line is being used and specifically with CSV values. >>> >>> Do I think CSV's are sane and useful? No. Can we change that? That's a >>> whole other story. >>> >>> >>>> I wanted to add single TXT record with double quotation marks (") >>>> inside the >>>> TXT data. >>>> >>>> I spent some time figuring out how it is supposed to work ... and >>>> with help of >>>> Petr^3 I managed to write the command. >>>> >>>> The resulting command (for BASH) is absolutely crazy: >>>> ipa dnsrecord-add example.test. newrec --txt-rec='"""created on >>>> 13:01:23"""' >>>> >>>> Do we really need support for this piece of insanity? Shells can do >>>> the same >>>> thing with much less pain :-) >>>> >>>> IPA with CSV support can add multiple attributes at once, e.g. >>>> ipa dnsrecord-add example.test. newrec --txt-rec=1,2,3,4,5,6,7,8,9 >>>> will add TXT records with value 1, 2, 3 etc. >>>> >>>> BASH can do the same thing (without the escaping hell): >>>> ipa dnsrecord-add example.test. newrec --txt-rec={1,2,3,4,5,6,7,8,9} >>>> and >>>> ipa dnsrecord-add example.test. newrec --txt-rec={1..9} >>>> BASH would expand to >>>> ipa dnsrecord-add example.test. newrec --txt-rec=1 --txt-rec=2 >>>> --txt-rec=3 >>>> --txt-rec=4 --txt-rec=5 --txt-rec=6 --txt-rec=7 --txt-rec=8 >>>> --txt-rec=9 >>>> >>> >>> >> Do we already have CSV support? >> Where is it used? >> It is not clear to me if BASH example above requires the CSV support or >> it does expansion on its own. Please explain. >> > > We already have CSV support. It's a mechanism that allows multiple > values to be passed for one command line argument. The alternate > approach is rather than having one command line arg that takes > multiple values is to allow multiple command line args, each one > taking a single value. This is the UNIX methodology. I believe the > original thinking was who would want to type out multiple command line > args, it's too verbose. However the shell expansion illustrated above > shows how with simple shell syntax one can have succicent args and > allow the shell to expand them into the preferred verbose form. > So both are already supported and we want to stop using CSV and deprecate it over time? This makes sense if there are good examples of how to use bash expansion. I suggest we create a page and describe preferred method of dealing with the lists and document it. Also do the same with the manual, i.e. review it to make sure we do not show CSV syntax in the docs, same with the man pages. On the project page we will say that CSV will not be added to the new and existing commands and will be deprecated over time (probably by IPA version 4). Do I get it right? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Fri Jan 11 20:57:28 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 11 Jan 2013 15:57:28 -0500 Subject: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be? In-Reply-To: <50F07B87.4010102@redhat.com> References: <50EEBEDD.5040306@redhat.com> <50EEE594.3070300@redhat.com> <50F071CF.4020305@redhat.com> <50F075CE.5040905@redhat.com> <50F07B87.4010102@redhat.com> Message-ID: <50F07CB8.2070205@redhat.com> On 01/11/2013 03:52 PM, Dmitri Pal wrote: > On 01/11/2013 03:27 PM, John Dennis wrote: >> On 01/11/2013 03:10 PM, Dmitri Pal wrote: >>> On 01/10/2013 11:00 AM, John Dennis wrote: >>>> On 01/10/2013 08:15 AM, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> is there any user of CSV support built-in to IPA administration tools >>>>> ("ipa" >>>>> command)? Do you consider it sane or even useful? Please reply. >>>> >>>> I've always disliked our use of CSV values on both the command line >>>> and internally. They're just weird, nothing else in Unix works like >>>> this and as you point out below there are easier better alternatives. >>>> Plus with the use of CSV's there is a lot of awkward quoting in a >>>> variety of places. >>>> >>>> On the command line I always thought multiple values should be >>>> specified multiple times and internally they should be encapsulated in >>>> lists rather than parsing a CSV string (if it's logically a list then >>>> why isn't it a list?) >>>> >>>> However at this juncture I'm not sure we can make such a change, we >>>> have a published API that we would be violating. But perhaps we're not >>>> so far down the road we can't make such a change and we're better off >>>> doing it now while there is even a chance. It's not clear to me how >>>> much the command line is being used and specifically with CSV values. >>>> >>>> Do I think CSV's are sane and useful? No. Can we change that? That's a >>>> whole other story. >>>> >>>> >>>>> I wanted to add single TXT record with double quotation marks (") >>>>> inside the >>>>> TXT data. >>>>> >>>>> I spent some time figuring out how it is supposed to work ... and >>>>> with help of >>>>> Petr^3 I managed to write the command. >>>>> >>>>> The resulting command (for BASH) is absolutely crazy: >>>>> ipa dnsrecord-add example.test. newrec --txt-rec='"""created on >>>>> 13:01:23"""' >>>>> >>>>> Do we really need support for this piece of insanity? Shells can do >>>>> the same >>>>> thing with much less pain :-) >>>>> >>>>> IPA with CSV support can add multiple attributes at once, e.g. >>>>> ipa dnsrecord-add example.test. newrec --txt-rec=1,2,3,4,5,6,7,8,9 >>>>> will add TXT records with value 1, 2, 3 etc. >>>>> >>>>> BASH can do the same thing (without the escaping hell): >>>>> ipa dnsrecord-add example.test. newrec --txt-rec={1,2,3,4,5,6,7,8,9} >>>>> and >>>>> ipa dnsrecord-add example.test. newrec --txt-rec={1..9} >>>>> BASH would expand to >>>>> ipa dnsrecord-add example.test. newrec --txt-rec=1 --txt-rec=2 >>>>> --txt-rec=3 >>>>> --txt-rec=4 --txt-rec=5 --txt-rec=6 --txt-rec=7 --txt-rec=8 >>>>> --txt-rec=9 >>>>> >>>> >>>> >>> Do we already have CSV support? >>> Where is it used? >>> It is not clear to me if BASH example above requires the CSV support or >>> it does expansion on its own. Please explain. >>> >> >> We already have CSV support. It's a mechanism that allows multiple >> values to be passed for one command line argument. The alternate >> approach is rather than having one command line arg that takes >> multiple values is to allow multiple command line args, each one >> taking a single value. This is the UNIX methodology. I believe the >> original thinking was who would want to type out multiple command line >> args, it's too verbose. However the shell expansion illustrated above >> shows how with simple shell syntax one can have succicent args and >> allow the shell to expand them into the preferred verbose form. >> > > So both are already supported and we want to stop using CSV and > deprecate it over time? > This makes sense if there are good examples of how to use bash expansion. > I suggest we create a page and describe preferred method of dealing with > the lists and document it. > Also do the same with the manual, i.e. review it to make sure we do not > show CSV syntax in the docs, same with the man pages. > On the project page we will say that CSV will not be added to the new > and existing commands and will be deprecated over time (probably by IPA > version 4). > Do I get it right? > I'm not sure both are currently supported. I'm not sure we permit multiple args with the same name and aggregate them, I thought that was part of the proposal. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From fvzwieten at vxcompany.com Sat Jan 12 08:28:30 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Sat, 12 Jan 2013 09:28:30 +0100 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart Message-ID: Hi there, We are in the process of implementing Satellite and want to automate server installations 100% using kickstart, cobbler, satellite. IPA clients can be scripted enrolled using kickstart. Plenty of documentation about that. However, how to "re"-enroll IPA clients? Satellite gives me the option to re-install a server. In this case, there are still host and possibly service records for this host present in IPA and DNS. One way to think about this is, that it's actually OK to keep those records there, because it is a "re"-installation, so why remove and re-enroll? However, there is the krb5.keytab in /etc. I could save that file during redeployment, but I'm not sure if that will work. And iare there any other gotcha's. So, the question is, how to re-install an IPA client using kickstart (silent re-install)? Regards, Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Sat Jan 12 14:17:59 2013 From: jdennis at redhat.com (John Dennis) Date: Sat, 12 Jan 2013 09:17:59 -0500 Subject: [Freeipa-users] how do i apply patch? In-Reply-To: References: <50ED8F45.6030204@redhat.com> <50ED9B36.3030909@redhat.com> <50F04807.7080507@redhat.com> Message-ID: <50F17097.5060909@redhat.com> On 01/12/2013 06:52 AM, Umarzuki Mochlis wrote: > 2013/1/12 John Dennis : >> 1) Download the source rpm matching the version you have installed, add the >> patch, rebuild the rpm locally, install the locally built rpm. > > how do i 'add the patch' to source rpm? any documentation that i can > follow to do this? > There is a ton of documentation on the web on how to work with RPM. I could write out the steps but it would be inferior to the extensive doc you can look-up on Google. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From shelltoesuperstar at gmail.com Sat Jan 12 20:46:13 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Sat, 12 Jan 2013 20:46:13 +0000 Subject: [Freeipa-users] Cmd-line Unprovision & OTP setting for a host In-Reply-To: <50C5EA44.40502@redhat.com> References: <1996182256.1044935.1347936809705.JavaMail.root@redhat.com> <1FB7AD4E-C6CC-4B40-A9C9-0A88F991938E@citrixonline.com> <56343345B145C043AE990701E3D193952B5644@EXVS2.nrplc.localnet> <5058882A.6010208@redhat.com> <50C5EA44.40502@redhat.com> Message-ID: Again apologies for the late reply, I've just discovered a new issue regarding this but I'll answer the original question before asking a new one. Yes being able to set the OTP without disabling the host is one of the ways we could solve this problem and yes the longer we can keep a server enrolled the better. The reason why it would be hard to change the order to something similar to what you described above is due to the batch nature of kickstarting servers. Your new sequence "uninstall client, recreate the host and OTP on the server side, re-install the client" effectively translates to "log on to the client but don't do anything yet, log onto the provisioning server and recreate the host and set the OTP, return to your client session and reboot it thus starting the automated provisioning process" which doesn't work very well when trying to provision multiple servers or automating things. The other option of being able to backup and restore the config in a clean way is still a viable option as far as I'm concerned. I just thought the OTP route would be easier to implement. I just noticed someone else asked a similar question which prompted me to trawl back through my e-mails to find this thread. The other issue that affects automated provisioning is we have just upgraded from IPA 2.1.3 to 2.2.0 and found that OTP password reuse has been disabled. Is there any way around this as it has broken our automated build process? Regards, Charlie On Mon, Dec 10, 2012 at 1:57 PM, Dmitri Pal wrote: > On 12/07/2012 10:15 PM, Charlie Derwent wrote: > > Sorry for the extremely late reply, rebuilds of clients, keytab and > configuration primarily but certs too would be nice. > > What we currently do during our provisioning process is disable the host > and reset the password (as previously mentioned) during the kickstart setup > process so the server can successfully enroll (or in the situation I'm > thinking of re-enroll) later on. The problem that causes is when you need > to log onto the server to reboot it but you've just removed your account. > So we have to use a shared local account to log on, limiting the need to do > things like that was the exact reason we installed IPA on our network in > the first place. > > So if there was a command like ipa-client-backup or ipa-client-restore > that you could run to generate/restore a gpg file with your clients info we > could safely restore the config after disk had been wiped. Another possibly > simpler option would be being able to reset the OTP without having to > disable the host first, so the first time the IPA server sees a new > ipa-client-install request with the right OTP it automatically disables the > host server side then enrolls the client that made the request. (Or even > simpler if there's any documentation on what files you would need to back > up) > > I prefer option 2 :-) > > > > I am trying to understand the sequence of the operations here. > You have a client that you need to periodically re-install or re-deploy it. > > Before you re-install you need to set the OTP (because it is OTP) anyways. > This means you need some software to run a command against IPA. > OK so at that moment you can remove the host and then re-create it again > in IPA and set the OTP there. > On the client side you run ipa-client-install providing OTP and it creates > the host keytab and does all configuration steps. > After that you can log with any user account you have into that client > (unless you prohibited this user from logging in via HBAC). > > It seems that what you are asking above is the ability to set OTP without > disabling the host... > Is the problem with sequencing? Are you saying that while the client is > still working you already need to prepare it for the next re-enrollment > without disrupting current operations? > I can understand that. > But what prevents you from doing operations in sequence: uninstall client, > recreate the host and OTP on the server side, re-install the client? > > > > > > Thanks, > Charlie > > > On Tue, Sep 18, 2012 at 3:41 PM, Dmitri Pal wrote: > >> On 09/18/2012 07:34 AM, Charlie Derwent wrote: >> >> Hi >> >> I've used "ipa host-disable ${HOST}; ipa host-mod --password=${PASS} >> ${HOST}" In the past and that seems to work quite well. The ideal for me >> would be a situation where the IPA information could persist between >> rebuilds. >> >> >> >> Can you please elaborate more? >> Between rebuilds of what client or server? >> And what information you want to persist: cert, keytab, OTP? >> >> Thanks >> Dmitri >> >> >> >> Cheers, >> Charlie >> On Tue, Sep 18, 2012 at 12:05 PM, Innes, Duncan < >> Duncan.Innes at virginmoney.com> wrote: >> >>> Folks, >>> >>> Juggling a problem here that perhaps doesn't have a perfect solution. >>> I'm looking at systems that get re-provisioned by a >>> Satellite/Spacewalk/Installation method. For full (Free)IPA >>> integration, we normally delete the old entry from IPA, create a new one >>> from scratch and set the OTP to match what we put in our post-install >>> script called by the kickstart file. >>> >>> Just noticed that I can do the same thing by Unprovisioning the system >>> via the WebUI and then setting the OTP. >>> >>> Is there a way to Unprovision a registered host and set a OTP via the >>> command line? I was looking at 'ipa host-mod --setattr' but not getting >>> too far with the Unprovisioning aspect. >>> >>> Duncan Innes | Linux Architect | Virgin Money | +44 1603 215476<%2B44%201603%20215476>| +44 >>> 7801 134507 | duncan.innes at virginmoney.com >>> >>> >>> >>> > -----Original Message----- >>> > From: freeipa-users-bounces at redhat.com >>> > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of JR Aquino >>> > Sent: 18 September 2012 03:58 >>> > To: Tim Hildred >>> > Cc: freeipa-users >>> > Subject: Re: [Freeipa-users] Password requirements too stringent >>> > >>> > >>> > On Sep 17, 2012, at 7:53 PM, Tim Hildred wrote: >>> > >>> > > JR >>> > > >>> > > I had that line. I commented it out. Thank you. >>> > > >>> > > Now, what do I have to restart? >>> > >>> > I believe it should take effect in real time, but you may >>> > need to test to be sure. If it is still happening, you may >>> > need to double check that some other pam cfg doesn't also >>> > have it present: $ cd /etc/pam.d/ && grep pam_cracklib * >>> > >>> > If you have removed it from everything and it is still giving >>> > you the same error, then I would try a reboot... perhaps >>> > getty needs to reinitialize or something. But I'd try those >>> > steps before a reboot! >>> > >>> > ;) >>> > >>> > > Tim Hildred, RHCE >>> > > Content Author II - Engineering Content Services, Red Hat, Inc. >>> > > Brisbane, Australia >>> > > Email: thildred at redhat.com >>> > > Internal: 8588287 >>> > > Mobile: +61 4 666 25242 <%2B61%204%20666%2025242> >>> > > IRC: thildred >>> > > >>> > > ----- Original Message ----- >>> > >> From: "JR Aquino" >>> > >> To: "Tim Hildred" >>> > >> Cc: "freeipa-users" >>> > >> Sent: Tuesday, September 18, 2012 12:37:48 PM >>> > >> Subject: Re: [Freeipa-users] Password requirements too stringent >>> > >> >>> > >> Tim, please check your /etc/pam.d/system-auth with the password >>> > >> block. If you see password requisite pam_cracklib.so, then >>> > >> this is why you are having a problem. >>> > >> >>> > >> $ man pam_cracklib >>> > >> >>> > >> It is a local security library for enforcing strong password >>> > >> practices from the unix cli. >>> > >> >>> > >> ProTip: >>> > >> If you don't need this, you can remove it from pam If you want to >>> > >> work around this, set your password from the IPA webui or via the >>> > >> cli: "ipa passwd username" >>> > >> >>> > >> Hope this info helps! >>> > >> >>> > >> "Keeping your head in the cloud" >>> > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> > >> JR Aquino >>> > >> >>> > >> Senior Information Security Specialist, Technical Operations >>> > >> T: +1 805 690 3478 <%2B1%20805%20690%203478> | F: +1 805 879 3730<%2B1%20805%20879%203730>| M: +1 >>> 805 717 0365 <%2B1%20805%20717%200365> GIAC >>> > >> Certified Incident Handler | GIAC WebApplication >>> > Penetration Tester >>> > >> JR.Aquino at citrix.com >>> > >> >>> > >> >>> > >> [cid:image002.jpg at 01CD4A37.5451DC00] >>> > >> >>> > >> Powering mobile workstyles and cloud services >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> On Sep 17, 2012, at 6:25 PM, Tim Hildred wrote: >>> > >> >>> > >> Hey all; >>> > >> >>> > >> I'm running IPA internally to control access to our cloud >>> > >> environment. >>> > >> >>> > >> I must admit, I do not understand the password >>> > requirements. I have >>> > >> had them set to the defaults. I read this: >>> > >> >>> > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Lin >>> > >> ux/6/html/Identity_Management_Guide/user-pwdpolicy.html >>> > >> >>> > >> I have the minimum character classes set to 0. When people >>> > use SSH to >>> > >> change their passwords, they get "Based on a dictionary word" for >>> > >> passwords that have nothing to do with dictionary words. >>> > >> >>> > >> I can't find anywhere in the documentation a break down of >>> > what makes >>> > >> an unacceptable versus acceptable password. >>> > >> >>> > >> Can anyone help me figure out what to tell my users? I >>> > think people >>> > >> would get a lot less frustrated if they knew why >>> > "C679V375" was "too >>> > >> simple" when the password policy has 0 required classes. >>> > >> >>> > >> Tim Hildred, RHCE >>> > >> Content Author II - Engineering Content Services, Red Hat, Inc. >>> > >> Brisbane, Australia >>> > >> Email: thildred at redhat.com >>> > >> Internal: 8588287 >>> > >> Mobile: +61 4 666 25242 <%2B61%204%20666%2025242> >>> > >> IRC: thildred >>> > >> >>> > >> ps: funny exchange with user: >>> > >> Jul 12 14:12:33 i feel like im being punked Jul 12 >>> > 14:12:40 >>> > >> it is based on a dictionary word Jul 12 14:12:43 >>> > it >>> > >> is too short Jul 12 14:12:49 is does not have >>> > enough unique >>> > >> letters Jul 12 14:12:51 etc >>> > >> >>> > >> _______________________________________________ >>> > >> Freeipa-users mailing list >>> > >> Freeipa-users at redhat.com >>> > >> https://www.redhat.com/mailman/listinfo/freeipa-users >>> > >> >>> > >> >>> > >>> > >>> > _______________________________________________ >>> > Freeipa-users mailing list >>> > Freeipa-users at redhat.com >>> > https://www.redhat.com/mailman/listinfo/freeipa-users >>> > >>> > This message has been checked for viruses and spam by the >>> > Virgin Money email scanning system powered by Messagelabs. >>> > >>> >>> >>> Northern Rock plc is part of the Virgin Money group of companies. >>> >>> This e-mail is intended to be confidential to the recipient. If you >>> receive a copy in error, please inform the sender and then delete this >>> message. >>> >>> Virgin Money Personal Financial Service Limited is authorised and >>> regulated by the Financial Services Authority. Company no. 3072766. >>> >>> Virgin Money Unit Trust Managers Limited is authorised and regulated by >>> the Financial Services Authority. Company no. 3000482. >>> >>> Virgin Money Cards Limited. Introducer appointed representative only of >>> Virgin Money Personal Financial Service Limited. Company no. 4232392. >>> >>> Virgin Money Management Services Limited. Company no. 3072772. >>> >>> Virgin Money Holdings (UK) Limited. Company no. 3087587. >>> >>> Each of the above companies is registered in England and Wales and has >>> its registered office at Discovery House, Whiting Road, Norwich NR4 6EJ. >>> >>> Northern Rock plc. Authorised and regulated by the Financial Services >>> Authority. Registered in England and Wales (Company no. 6952311) with its >>> registered office at Northern Rock House, Gosforth, Newcastle upon Tyne NE3 >>> 4PL. >>> >>> The above companies use the trading name Virgin Money. >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://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 at 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/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sat Jan 12 21:06:50 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 12 Jan 2013 16:06:50 -0500 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: References: Message-ID: <50F1D06A.9080205@redhat.com> On 01/12/2013 03:28 AM, Fred van Zwieten wrote: > Hi there, > > We are in the process of implementing Satellite and want to automate > server installations 100% using kickstart, cobbler, satellite. > > IPA clients can be scripted enrolled using kickstart. Plenty of > documentation about that. > > However, how to "re"-enroll IPA clients? > > Satellite gives me the option to re-install a server. In this case, > there are still host and possibly service records for this host > present in IPA and DNS. > > One way to think about this is, that it's actually OK to keep those > records there, because it is a "re"-installation, so why remove and > re-enroll? However, there is the krb5.keytab in /etc. I could save > that file during redeployment, but I'm not sure if that will work. And > iare there any other gotcha's. > > So, the question is, how to re-install an IPA client using kickstart > (silent re-install)? The question is how/do you remove the client? Based on what you say above you use the same system so there are some leftovers. If you can run ipa-client-install --uninstall it should clean things like keytab and certs (there have been bugs fixed in freeIPA 3.0). If the client has access to the server it will clean (not remove) the host entry too. Then you can re-run the install. If you use OTP you would need to reset OTP first. > > Regards, > > Fred > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sat Jan 12 21:24:19 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 12 Jan 2013 16:24:19 -0500 Subject: [Freeipa-users] Cmd-line Unprovision & OTP setting for a host In-Reply-To: References: <1996182256.1044935.1347936809705.JavaMail.root@redhat.com> <1FB7AD4E-C6CC-4B40-A9C9-0A88F991938E@citrixonline.com> <56343345B145C043AE990701E3D193952B5644@EXVS2.nrplc.localnet> <5058882A.6010208@redhat.com> <50C5EA44.40502@redhat.com> Message-ID: <50F1D483.90307@redhat.com> On 01/12/2013 03:46 PM, Charlie Derwent wrote: > Again apologies for the late reply, I've just discovered a new issue > regarding this but I'll answer the original question before asking a > new one. Yes being able to set the OTP without disabling the host is > one of the ways we could solve this problem and yes the longer we can > keep a server enrolled the better. > Can you please file an RFE about it? https://fedorahosted.org/freeipa/newticket > The reason why it would be hard to change the order to something > similar to what you described above is due to the batch nature of > kickstarting servers. Your new sequence "uninstall client, recreate > the host and OTP on the server side, re-install the client" > effectively translates to "log on to the client but don't do anything > yet, log onto the provisioning server and recreate the host and set > the OTP, return to your client session and reboot it thus starting the > automated provisioning process" which doesn't work very well when > trying to provision multiple servers or automating things. There might be some problems with our understanding of how bulk provisioning works. I assume (and might be wrongly) that there is a reasonable amount of time between the moment the client is uninstalled and the moment the client is re-provisioned again. If this is not the case then in fact there is a problem as you describe. But what is the reason for recycling the systems like that? What is the use case? How common it is? I think JR solved this by redeploying the systems with different name and using auto member plugin to automatically place the hosts into the right groups. Would that approach work for you? > > The other option of being able to backup and restore the config in a > clean way is still a viable option as far as I'm concerned. I just > thought the OTP route would be easier to implement. I just noticed > someone else asked a similar question which prompted me to trawl back > through my e-mails to find this thread. > > The other issue that affects automated provisioning is we have just > upgraded from IPA 2.1.3 to 2.2.0 and found that OTP password reuse has > been disabled. Is there any way around this as it has broken our > automated build process? Can you file a bug about it? https://fedorahosted.org/freeipa/newticket That would be the fastest way for us to react. > > Regards, > Charlie > > > > > On Mon, Dec 10, 2012 at 1:57 PM, Dmitri Pal > wrote: > > On 12/07/2012 10:15 PM, Charlie Derwent wrote: >> Sorry for the extremely late reply, rebuilds of clients, keytab >> and configuration primarily but certs too would be nice. >> >> What we currently do during our provisioning process is disable >> the host and reset the password (as previously mentioned) during >> the kickstart setup process so the server can successfully enroll >> (or in the situation I'm thinking of re-enroll) later on. The >> problem that causes is when you need to log onto the server >> to reboot it but you've just removed your account. So we have to >> use a shared local account to log on, limiting the need to do >> things like that was the exact reason we installed IPA on our >> network in the first place. >> >> So if there was a command like ipa-client-backup or >> ipa-client-restore that you could run to generate/restore a gpg >> file with your clients info we could safely restore the config >> after disk had been wiped. Another possibly simpler option would >> be being able to reset the OTP without having to disable the host >> first, so the first time the IPA server sees a new >> ipa-client-install request with the right OTP it automatically >> disables the host server side then enrolls the client that made >> the request. (Or even simpler if there's any documentation on >> what files you would need to back up) >> >> I prefer option 2 :-) > > > I am trying to understand the sequence of the operations here. > You have a client that you need to periodically re-install or > re-deploy it. > > Before you re-install you need to set the OTP (because it is OTP) > anyways. This means you need some software to run a command > against IPA. > OK so at that moment you can remove the host and then re-create it > again in IPA and set the OTP there. > On the client side you run ipa-client-install providing OTP and it > creates the host keytab and does all configuration steps. > After that you can log with any user account you have into that > client (unless you prohibited this user from logging in via HBAC). > > It seems that what you are asking above is the ability to set OTP > without disabling the host... > Is the problem with sequencing? Are you saying that while the > client is still working you already need to prepare it for the > next re-enrollment without disrupting current operations? > I can understand that. > But what prevents you from doing operations in sequence: uninstall > client, recreate the host and OTP on the server side, re-install > the client? > > > > >> >> Thanks, >> Charlie >> >> >> On Tue, Sep 18, 2012 at 3:41 PM, Dmitri Pal > > wrote: >> >> On 09/18/2012 07:34 AM, Charlie Derwent wrote: >>> Hi >>> >>> I've used "ipa host-disable ${HOST}; ipa host-mod >>> --password=${PASS} ${HOST}" In the past and that seems to >>> work quite well. The ideal for me would be a situation where >>> the IPA information could persist between rebuilds. >> >> >> Can you please elaborate more? >> Between rebuilds of what client or server? >> And what information you want to persist: cert, keytab, OTP? >> >> Thanks >> Dmitri >> >> >>> >>> Cheers, >>> Charlie >>> On Tue, Sep 18, 2012 at 12:05 PM, Innes, Duncan >>> >> > wrote: >>> >>> Folks, >>> >>> Juggling a problem here that perhaps doesn't have a >>> perfect solution. >>> I'm looking at systems that get re-provisioned by a >>> Satellite/Spacewalk/Installation method. For full (Free)IPA >>> integration, we normally delete the old entry from IPA, >>> create a new one >>> from scratch and set the OTP to match what we put in our >>> post-install >>> script called by the kickstart file. >>> >>> Just noticed that I can do the same thing by >>> Unprovisioning the system >>> via the WebUI and then setting the OTP. >>> >>> Is there a way to Unprovision a registered host and set >>> a OTP via the >>> command line? I was looking at 'ipa host-mod --setattr' >>> but not getting >>> too far with the Unprovisioning aspect. >>> >>> Duncan Innes | Linux Architect | Virgin Money | +44 1603 >>> 215476 | +44 >>> 7801 134507 | duncan.innes at virginmoney.com >>> >>> >>> >>> >>> > -----Original Message----- >>> > From: freeipa-users-bounces at redhat.com >>> >>> > [mailto:freeipa-users-bounces at redhat.com >>> ] On Behalf Of >>> JR Aquino >>> > Sent: 18 September 2012 03:58 >>> > To: Tim Hildred >>> > Cc: freeipa-users >>> > Subject: Re: [Freeipa-users] Password requirements too >>> stringent >>> > >>> > >>> > On Sep 17, 2012, at 7:53 PM, Tim Hildred wrote: >>> > >>> > > JR >>> > > >>> > > I had that line. I commented it out. Thank you. >>> > > >>> > > Now, what do I have to restart? >>> > >>> > I believe it should take effect in real time, but you may >>> > need to test to be sure. If it is still happening, >>> you may >>> > need to double check that some other pam cfg doesn't also >>> > have it present: $ cd /etc/pam.d/ && grep pam_cracklib * >>> > >>> > If you have removed it from everything and it is still >>> giving >>> > you the same error, then I would try a reboot... perhaps >>> > getty needs to reinitialize or something. But I'd try >>> those >>> > steps before a reboot! >>> > >>> > ;) >>> > >>> > > Tim Hildred, RHCE >>> > > Content Author II - Engineering Content Services, >>> Red Hat, Inc. >>> > > Brisbane, Australia >>> > > Email: thildred at redhat.com >>> > > Internal: 8588287 >>> > > Mobile: +61 4 666 25242 >>> > > IRC: thildred >>> > > >>> > > ----- Original Message ----- >>> > >> From: "JR Aquino" >> > >>> > >> To: "Tim Hildred" >> > >>> > >> Cc: "freeipa-users" >> > >>> > >> Sent: Tuesday, September 18, 2012 12:37:48 PM >>> > >> Subject: Re: [Freeipa-users] Password requirements >>> too stringent >>> > >> >>> > >> Tim, please check your /etc/pam.d/system-auth with >>> the password >>> > >> block. If you see password requisite >>> pam_cracklib.so, then >>> > >> this is why you are having a problem. >>> > >> >>> > >> $ man pam_cracklib >>> > >> >>> > >> It is a local security library for enforcing strong >>> password >>> > >> practices from the unix cli. >>> > >> >>> > >> ProTip: >>> > >> If you don't need this, you can remove it from pam >>> If you want to >>> > >> work around this, set your password from the IPA >>> webui or via the >>> > >> cli: "ipa passwd username" >>> > >> >>> > >> Hope this info helps! >>> > >> >>> > >> "Keeping your head in the cloud" >>> > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> > >> JR Aquino >>> > >> >>> > >> Senior Information Security Specialist, Technical >>> Operations >>> > >> T: +1 805 690 3478 | >>> F: +1 805 879 3730 | M: +1 >>> 805 717 0365 GIAC >>> > >> Certified Incident Handler | GIAC WebApplication >>> > Penetration Tester >>> > >> JR.Aquino at citrix.com >>> > >>> > >> >>> > >> >>> > >> [cid:image002.jpg at 01CD4A37.5451DC00] >>> > >> >>> > >> Powering mobile workstyles and cloud services >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> On Sep 17, 2012, at 6:25 PM, Tim Hildred wrote: >>> > >> >>> > >> Hey all; >>> > >> >>> > >> I'm running IPA internally to control access to our >>> cloud >>> > >> environment. >>> > >> >>> > >> I must admit, I do not understand the password >>> > requirements. I have >>> > >> had them set to the defaults. I read this: >>> > >> >>> > >>> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Lin >>> > >> ux/6/html/Identity_Management_Guide/user-pwdpolicy.html >>> > >> >>> > >> I have the minimum character classes set to 0. When >>> people >>> > use SSH to >>> > >> change their passwords, they get "Based on a >>> dictionary word" for >>> > >> passwords that have nothing to do with dictionary >>> words. >>> > >> >>> > >> I can't find anywhere in the documentation a break >>> down of >>> > what makes >>> > >> an unacceptable versus acceptable password. >>> > >> >>> > >> Can anyone help me figure out what to tell my users? I >>> > think people >>> > >> would get a lot less frustrated if they knew why >>> > "C679V375" was "too >>> > >> simple" when the password policy has 0 required >>> classes. >>> > >> >>> > >> Tim Hildred, RHCE >>> > >> Content Author II - Engineering Content Services, >>> Red Hat, Inc. >>> > >> Brisbane, Australia >>> > >> Email: thildred at redhat.com >>> > >> Internal: 8588287 >>> > >> Mobile: +61 4 666 25242 >>> > >> IRC: thildred >>> > >> >>> > >> ps: funny exchange with user: >>> > >> Jul 12 14:12:33 i feel like im being punked >>> Jul 12 >>> > 14:12:40 >>> > >> it is based on a dictionary word Jul 12 >>> 14:12:43 >>> > it >>> > >> is too short Jul 12 14:12:49 is does not have >>> > enough unique >>> > >> letters Jul 12 14:12:51 etc >>> > >> >>> > >> _______________________________________________ >>> > >> Freeipa-users mailing list >>> > >> Freeipa-users at redhat.com >>> >>> > >> https://www.redhat.com/mailman/listinfo/freeipa-users >>> > >> >>> > >> >>> > >>> > >>> > _______________________________________________ >>> > Freeipa-users mailing list >>> > Freeipa-users at redhat.com >>> > https://www.redhat.com/mailman/listinfo/freeipa-users >>> > >>> > This message has been checked for viruses and spam by the >>> > Virgin Money email scanning system powered by Messagelabs. >>> > >>> >>> >>> Northern Rock plc is part of the Virgin Money group of >>> companies. >>> >>> This e-mail is intended to be confidential to the >>> recipient. If you receive a copy in error, please inform >>> the sender and then delete this message. >>> >>> Virgin Money Personal Financial Service Limited is >>> authorised and regulated by the Financial Services >>> Authority. Company no. 3072766. >>> >>> Virgin Money Unit Trust Managers Limited is authorised >>> and regulated by the Financial Services Authority. >>> Company no. 3000482. >>> >>> Virgin Money Cards Limited. Introducer appointed >>> representative only of Virgin Money Personal Financial >>> Service Limited. Company no. 4232392. >>> >>> Virgin Money Management Services Limited. Company no. >>> 3072772. >>> >>> Virgin Money Holdings (UK) Limited. Company no. 3087587. >>> >>> Each of the above companies is registered in England and >>> Wales and has its registered office at Discovery House, >>> Whiting Road, Norwich NR4 6EJ. >>> >>> Northern Rock plc. Authorised and regulated by the >>> Financial Services Authority. Registered in England and >>> Wales (Company no. 6952311) with its registered office >>> at Northern Rock House, Gosforth, Newcastle upon Tyne >>> NE3 4PL. >>> >>> The above companies use the trading name Virgin Money. >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at 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 at 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/ > > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dale at themacartneyclan.com Sun Jan 13 00:17:50 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Sun, 13 Jan 2013 00:17:50 +0000 Subject: [Freeipa-users] FreeIPA + Yubikey conditional login process Message-ID: <50F1FD2E.50205@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Evening all So, basis of my testing environment is as follows RHEL 6 running IPA 2.2 or 3.0 (Will be looking to test on both versions) RHEL 6 and Fedora 18 workstations connected as ipa clients to IPA domain. I am using this article in place with my testing environment. https://www.dalemacartney.com/2012/12/19/integrating-yubikey-token-details-within-ldap-with-freeipa-and-red-hat-enterprise-linux-6/ What I would like to achieve is: Scenario 1: - From IPA client workstation remote SSH session authenticates using current TGT from workstation session. No password or yubikey prompt. This should be completely SSO. Scenario 2: - From Non-IPA client workstation remote SSH session authenticates via password AND yubikey prompt as no TGT is available. What I don't know how to achieve is Scenario 2. Is this possible? I'm processing it in my mind of pam having a conditional required option, but I don't know of a way to make it happen. Thanks all Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ8f0sAAoJEAJsWS61tB+qxLkQAL/mb1gIUpAocHwZBLoM6T0q bsuDnaMMr80J96q5loPLHyMBDf32VphE9oqVjzh81MIm0Xl2OBrO2egVyvtGFlo9 W71Vy1eoGZzPnrrhnQP3bBWrBXWk0Kbld99boZBv6v9QX/gS9AX3U4WyBrqGCy/7 3ia8agNAmZI+8ZNmELk2/ObvkvFwrcQlj+L4I8EmwwwiZSTsSVm9xKVd/1mcvj1f h87nnrmxHpOFjZ74YnA71AOWMzie8w3Yuodnpr90vngFCMxfGfVTeU90HQheItAV /Ls8bR7Ks3aTr+XwEkVl3b4c1gFEu9SIMOGXtQidl/FVx7cMHGLsBzaVZ9jTCw6K RS0dUuX8nOVBwYWxFYTwjaI0Ypv54xmZvplynlp7f4jsj3WzWC2GZmdBFYk4iQju XLuJWXCgOkDdgDIkMEdu1Pv6f8VX7EkKFUp3amlibgSKfNdDQ2KMdT85beRcab4N 2on6lL6QzEB7AjZ0qIF/p+LGOItP0evl+tpWhcgXXICGWb1OBAp/MwjpO16Yyp8K AA8/vJT2/aUsxImzOmAdG19RzmdZQlN6+l8tLJAmh2UzKpaRc8Lm6klMUnsI1T5Q Hge5t+Tn+zqeUb8It5xExJnkhCzQGNaNZvEAPskO2y0p5qUabBENF133e7HR9Pub 2BqtI2Je1Mg1PmPxSwI+ =+lqh -----END PGP SIGNATURE----- From dpal at redhat.com Sun Jan 13 21:32:51 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 13 Jan 2013 16:32:51 -0500 Subject: [Freeipa-users] FreeIPA + Yubikey conditional login process In-Reply-To: <50F1FD2E.50205@themacartneyclan.com> References: <50F1FD2E.50205@themacartneyclan.com> Message-ID: <50F32803.9000708@redhat.com> On 01/12/2013 07:17 PM, Dale Macartney wrote: > > Evening all > > So, basis of my testing environment is as follows > > RHEL 6 running IPA 2.2 or 3.0 (Will be looking to test on both versions) > RHEL 6 and Fedora 18 workstations connected as ipa clients to IPA domain. > > I am using this article in place with my testing environment. > https://www.dalemacartney.com/2012/12/19/integrating-yubikey-token-details-within-ldap-with-freeipa-and-red-hat-enterprise-linux-6/ > > What I would like to achieve is: > > Scenario 1: > - From IPA client workstation > remote SSH session authenticates using current TGT from workstation > session. No password or yubikey prompt. This should be completely SSO. > > Scenario 2: > - From Non-IPA client workstation > remote SSH session authenticates via password AND yubikey prompt as no > TGT is available. > > > What I don't know how to achieve is Scenario 2. > > Is this possible? I'm processing it in my mind of pam having a > conditional required option, but I don't know of a way to make it happen. > >From my past experience it was possible if the pam modules you want to stack support the right PAM flags and conditions. I do not remember the details, it was quite some time ago but I know that something like this can be accomplished if pam_yubikey (I assume something like this exists) and pam_sss are stacked in the right way. > Thanks all > > Dale > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Jan 14 08:09:41 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 14 Jan 2013 09:09:41 +0100 Subject: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be? In-Reply-To: <50F07CB8.2070205@redhat.com> References: <50EEBEDD.5040306@redhat.com> <50EEE594.3070300@redhat.com> <50F071CF.4020305@redhat.com> <50F075CE.5040905@redhat.com> <50F07B87.4010102@redhat.com> <50F07CB8.2070205@redhat.com> Message-ID: <50F3BD45.7030805@redhat.com> On 01/11/2013 09:57 PM, John Dennis wrote: > On 01/11/2013 03:52 PM, Dmitri Pal wrote: >> On 01/11/2013 03:27 PM, John Dennis wrote: >>> On 01/11/2013 03:10 PM, Dmitri Pal wrote: >>>> On 01/10/2013 11:00 AM, John Dennis wrote: >>>>> On 01/10/2013 08:15 AM, Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> is there any user of CSV support built-in to IPA administration tools >>>>>> ("ipa" >>>>>> command)? Do you consider it sane or even useful? Please reply. >>>>> >>>>> I've always disliked our use of CSV values on both the command line >>>>> and internally. They're just weird, nothing else in Unix works like >>>>> this and as you point out below there are easier better alternatives. >>>>> Plus with the use of CSV's there is a lot of awkward quoting in a >>>>> variety of places. >>>>> >>>>> On the command line I always thought multiple values should be >>>>> specified multiple times and internally they should be encapsulated in >>>>> lists rather than parsing a CSV string (if it's logically a list then >>>>> why isn't it a list?) >>>>> >>>>> However at this juncture I'm not sure we can make such a change, we >>>>> have a published API that we would be violating. But perhaps we're not >>>>> so far down the road we can't make such a change and we're better off >>>>> doing it now while there is even a chance. It's not clear to me how >>>>> much the command line is being used and specifically with CSV values. >>>>> >>>>> Do I think CSV's are sane and useful? No. Can we change that? That's a >>>>> whole other story. >>>>> >>>>> >>>>>> I wanted to add single TXT record with double quotation marks (") >>>>>> inside the >>>>>> TXT data. >>>>>> >>>>>> I spent some time figuring out how it is supposed to work ... and >>>>>> with help of >>>>>> Petr^3 I managed to write the command. >>>>>> >>>>>> The resulting command (for BASH) is absolutely crazy: >>>>>> ipa dnsrecord-add example.test. newrec --txt-rec='"""created on >>>>>> 13:01:23"""' >>>>>> >>>>>> Do we really need support for this piece of insanity? Shells can do >>>>>> the same >>>>>> thing with much less pain :-) >>>>>> >>>>>> IPA with CSV support can add multiple attributes at once, e.g. >>>>>> ipa dnsrecord-add example.test. newrec --txt-rec=1,2,3,4,5,6,7,8,9 >>>>>> will add TXT records with value 1, 2, 3 etc. >>>>>> >>>>>> BASH can do the same thing (without the escaping hell): >>>>>> ipa dnsrecord-add example.test. newrec --txt-rec={1,2,3,4,5,6,7,8,9} >>>>>> and >>>>>> ipa dnsrecord-add example.test. newrec --txt-rec={1..9} >>>>>> BASH would expand to >>>>>> ipa dnsrecord-add example.test. newrec --txt-rec=1 --txt-rec=2 >>>>>> --txt-rec=3 >>>>>> --txt-rec=4 --txt-rec=5 --txt-rec=6 --txt-rec=7 --txt-rec=8 >>>>>> --txt-rec=9 >>>>>> >>>>> >>>>> >>>> Do we already have CSV support? >>>> Where is it used? >>>> It is not clear to me if BASH example above requires the CSV support or >>>> it does expansion on its own. Please explain. >>>> >>> >>> We already have CSV support. It's a mechanism that allows multiple >>> values to be passed for one command line argument. The alternate >>> approach is rather than having one command line arg that takes >>> multiple values is to allow multiple command line args, each one >>> taking a single value. This is the UNIX methodology. I believe the >>> original thinking was who would want to type out multiple command line >>> args, it's too verbose. However the shell expansion illustrated above >>> shows how with simple shell syntax one can have succicent args and >>> allow the shell to expand them into the preferred verbose form. >>> >> >> So both are already supported and we want to stop using CSV and >> deprecate it over time? >> This makes sense if there are good examples of how to use bash expansion. >> I suggest we create a page and describe preferred method of dealing with >> the lists and document it. >> Also do the same with the manual, i.e. review it to make sure we do not >> show CSV syntax in the docs, same with the man pages. >> On the project page we will say that CSV will not be added to the new >> and existing commands and will be deprecated over time (probably by IPA >> version 4). >> Do I get it right? >> > > I'm not sure both are currently supported. I'm not sure we permit > multiple args with the same name and aggregate them, I thought that was > part of the proposal. > We do support multiple arguments. The trouble with CSV is that to put commas (or in some cases double quotes) in the data, they need to be escaped in a way that's not intuitive. The proposal is to change this, so that instead of --txt-rec='"""created on 13:01:23"""' you can use just --txt-rec='"created on 13:01:23"' and instead of --txt-rec='Record one, record two' you need to say --txt-rec={'Record one','record two'} The assumption is that this makes more sense to a sysadmin, who is much more likely to know bash scripting than our flavor of CSV escaping. -- Petr? From mkosek at redhat.com Mon Jan 14 08:19:33 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Jan 2013 09:19:33 +0100 Subject: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be? In-Reply-To: <50F3BD45.7030805@redhat.com> References: <50EEBEDD.5040306@redhat.com> <50EEE594.3070300@redhat.com> <50F071CF.4020305@redhat.com> <50F075CE.5040905@redhat.com> <50F07B87.4010102@redhat.com> <50F07CB8.2070205@redhat.com> <50F3BD45.7030805@redhat.com> Message-ID: <50F3BF95.2060108@redhat.com> On 01/14/2013 09:09 AM, Petr Viktorin wrote: > On 01/11/2013 09:57 PM, John Dennis wrote: >> On 01/11/2013 03:52 PM, Dmitri Pal wrote: >>> On 01/11/2013 03:27 PM, John Dennis wrote: >>>> On 01/11/2013 03:10 PM, Dmitri Pal wrote: >>>>> On 01/10/2013 11:00 AM, John Dennis wrote: >>>>>> On 01/10/2013 08:15 AM, Petr Spacek wrote: >>>>>>> Hello, >>>>>>> >>>>>>> is there any user of CSV support built-in to IPA administration tools >>>>>>> ("ipa" >>>>>>> command)? Do you consider it sane or even useful? Please reply. >>>>>> >>>>>> I've always disliked our use of CSV values on both the command line >>>>>> and internally. They're just weird, nothing else in Unix works like >>>>>> this and as you point out below there are easier better alternatives. >>>>>> Plus with the use of CSV's there is a lot of awkward quoting in a >>>>>> variety of places. >>>>>> >>>>>> On the command line I always thought multiple values should be >>>>>> specified multiple times and internally they should be encapsulated in >>>>>> lists rather than parsing a CSV string (if it's logically a list then >>>>>> why isn't it a list?) >>>>>> >>>>>> However at this juncture I'm not sure we can make such a change, we >>>>>> have a published API that we would be violating. But perhaps we're not >>>>>> so far down the road we can't make such a change and we're better off >>>>>> doing it now while there is even a chance. It's not clear to me how >>>>>> much the command line is being used and specifically with CSV values. >>>>>> >>>>>> Do I think CSV's are sane and useful? No. Can we change that? That's a >>>>>> whole other story. >>>>>> >>>>>> >>>>>>> I wanted to add single TXT record with double quotation marks (") >>>>>>> inside the >>>>>>> TXT data. >>>>>>> >>>>>>> I spent some time figuring out how it is supposed to work ... and >>>>>>> with help of >>>>>>> Petr^3 I managed to write the command. >>>>>>> >>>>>>> The resulting command (for BASH) is absolutely crazy: >>>>>>> ipa dnsrecord-add example.test. newrec --txt-rec='"""created on >>>>>>> 13:01:23"""' >>>>>>> >>>>>>> Do we really need support for this piece of insanity? Shells can do >>>>>>> the same >>>>>>> thing with much less pain :-) >>>>>>> >>>>>>> IPA with CSV support can add multiple attributes at once, e.g. >>>>>>> ipa dnsrecord-add example.test. newrec --txt-rec=1,2,3,4,5,6,7,8,9 >>>>>>> will add TXT records with value 1, 2, 3 etc. >>>>>>> >>>>>>> BASH can do the same thing (without the escaping hell): >>>>>>> ipa dnsrecord-add example.test. newrec --txt-rec={1,2,3,4,5,6,7,8,9} >>>>>>> and >>>>>>> ipa dnsrecord-add example.test. newrec --txt-rec={1..9} >>>>>>> BASH would expand to >>>>>>> ipa dnsrecord-add example.test. newrec --txt-rec=1 --txt-rec=2 >>>>>>> --txt-rec=3 >>>>>>> --txt-rec=4 --txt-rec=5 --txt-rec=6 --txt-rec=7 --txt-rec=8 >>>>>>> --txt-rec=9 >>>>>>> >>>>>> >>>>>> >>>>> Do we already have CSV support? >>>>> Where is it used? >>>>> It is not clear to me if BASH example above requires the CSV support or >>>>> it does expansion on its own. Please explain. >>>>> >>>> >>>> We already have CSV support. It's a mechanism that allows multiple >>>> values to be passed for one command line argument. The alternate >>>> approach is rather than having one command line arg that takes >>>> multiple values is to allow multiple command line args, each one >>>> taking a single value. This is the UNIX methodology. I believe the >>>> original thinking was who would want to type out multiple command line >>>> args, it's too verbose. However the shell expansion illustrated above >>>> shows how with simple shell syntax one can have succicent args and >>>> allow the shell to expand them into the preferred verbose form. >>>> >>> >>> So both are already supported and we want to stop using CSV and >>> deprecate it over time? >>> This makes sense if there are good examples of how to use bash expansion. >>> I suggest we create a page and describe preferred method of dealing with >>> the lists and document it. >>> Also do the same with the manual, i.e. review it to make sure we do not >>> show CSV syntax in the docs, same with the man pages. >>> On the project page we will say that CSV will not be added to the new >>> and existing commands and will be deprecated over time (probably by IPA >>> version 4). >>> Do I get it right? >>> >> >> I'm not sure both are currently supported. I'm not sure we permit >> multiple args with the same name and aggregate them, I thought that was >> part of the proposal. >> > > We do support multiple arguments. > > The trouble with CSV is that to put commas (or in some cases double quotes) in > the data, they need to be escaped in a way that's not intuitive. The proposal > is to change this, so that instead of > --txt-rec='"""created on 13:01:23"""' > you can use just > --txt-rec='"created on 13:01:23"' > and instead of > --txt-rec='Record one, record two' > you need to say > --txt-rec={'Record one','record two'} > The assumption is that this makes more sense to a sysadmin, who is much more > likely to know bash scripting than our flavor of CSV escaping. > Right. I also think this would a good step, there were too many issues related to CSV parsing in our commands. As Dmitri said, we would just need to carefully go through our Documentation and fix all uses of CSV-style. In some cases, people may be confused at the beginning (I know I will) until they get used to the new {} style, e.g. when adding self-service permissions: # ipa selfservice-mod --attrs=street,postalCode,l,c,st,telephoneNumber "Users manage their own address" and now they would need to carefully add {...} everywhere to avoid unexpected issues: # ipa selfservice-add --permissions={read,write} --attrs={street,postalCode,l,c,st} "Users manage their own address" Martin From john at ox-consulting.com Mon Jan 14 09:19:06 2013 From: john at ox-consulting.com (Johnathan Phan) Date: Mon, 14 Jan 2013 09:19:06 +0000 Subject: [Freeipa-users] openldap to ipa In-Reply-To: <3817AE3D-3005-4B2A-830D-2140865B0DFD@citrixonline.com> References: <3817AE3D-3005-4B2A-830D-2140865B0DFD@citrixonline.com> Message-ID: Hi Aquino, thanks for the input, however. There is a CRT in there already and it was set to allow on both the IPA server and the target openldap server. the core of the issue seems to be that IPA does not accept the cert either locally or remotely as it does not trust it. anyone know how I can troubleshot this. I have reviewed the dirsrv logs for ldap and I can't spot anything/. Regards John On Fri, Jan 11, 2013 at 5:55 PM, JR Aquino wrote: > Try editing /etc/openldap/ldap.conf: > > TLS_CACERT /etc/ipa/ca.crt > TLS_REQCERT allow > > > See if that helps > > "Keeping your head in the cloud" > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Jr Aquino | Sr. Information Security Specialist > GIAC Exploit Researcher and Advanced Penetration Tester | > GIAC Certified Incident Handler | GIAC WebApp Penetration Tester > Citrix Online | 7408 Hollister Avenue | Goleta, CA > 93117 > T: +1 805.690.3478 > C: +1 805.717.0365 > jr.aquino at citrix.com > http://www.citrixonline.com > > On Jan 11, 2013, at 8:05 AM, Johnathan Phan > wrote: > > Hi There, > > This is driving me up the wall. > > I have two servers. 1 is a live openldap/kerberous AAA server running on > RHEL6. The LDAP service has SSL/TS support. The second server is a test > environment running on fedora and has 3.1 IPA installed. > > As a last step of my POC I need to migrate the users and passwords from > the LDAP server to IPA server. > > I ran this command perfectly fine. > > ipa config-mod --enable-migration=TRUE > > However the next step was where my issues began. > > In the end after a lot of IRC communication and troubleshooting I now run > the following command. > > ipa migrate-ds --bind-dn="cn=admin,dc=example,dc=com" > --user-container="ou=users,ou=live,dc=example,dc=com" > --group-container="ou=groups,ou=live,dc=example,dc=com" ldaps:// > ldap1.live.example.com > > I get the following error. > > ipa: DEBUG: Caught fault 4203 from server > http://fedoraipaserver.test.example.com/ipa/xml: Can't contact LDAP > server: TLS error -8179:Peer's Certificate issuer is not recognized. > ipa: DEBUG: Destroyed connection context.xmlclient > ipa: ERROR: Can't contact LDAP server: TLS error -8179:Peer's Certificate > issuer is not recognized. > > I have summarized that the IPA server does not trust the cert served by > the openldap or the other way around. Does anyone know how to get around > this? Or allow me to finish the migration of user data. > > Regards > > John > > -- > Johnathan Phan > > T: +44 (0)784 118 7080 > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Johnathan Phan ox-consulting T: +44 (0)784 118 7080 john at ox-consulting.com www.ox-consulting.com OX CONSULTING Ltd is registered in England & Wales, number: 07113039, registered address as above. The information contained in this email message may be privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this transmission is strictly prohibited. If you have received this communication in error, or if any problems occur with transmission, please notify the sender immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From umarzuki at gmail.com Sat Jan 12 11:52:51 2013 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Sat, 12 Jan 2013 19:52:51 +0800 Subject: [Freeipa-users] how do i apply patch? In-Reply-To: <50F04807.7080507@redhat.com> References: <50ED8F45.6030204@redhat.com> <50ED9B36.3030909@redhat.com> <50F04807.7080507@redhat.com> Message-ID: 2013/1/12 John Dennis : > 1) Download the source rpm matching the version you have installed, add the > patch, rebuild the rpm locally, install the locally built rpm. how do i 'add the patch' to source rpm? any documentation that i can follow to do this? -- Regards, Umarzuki Mochlis http://debmal.my From john at ox-consulting.com Mon Jan 14 17:04:25 2013 From: john at ox-consulting.com (Johnathan Phan) Date: Mon, 14 Jan 2013 17:04:25 +0000 Subject: [Freeipa-users] openldap to ipa In-Reply-To: References: <3817AE3D-3005-4B2A-830D-2140865B0DFD@citrixonline.com> Message-ID: Anyone know the details of the low level system steps for the migration script to work? so I can try and backwards engineer or troubleshoot each system as I go along so I can actually migrate the data from openldap to ipa? Regards John On Mon, Jan 14, 2013 at 9:19 AM, Johnathan Phan wrote: > Hi Aquino, > > thanks for the input, however. There is a CRT in there already and it was > set to allow on both the IPA server and the target openldap server. > the core of the issue seems to be that IPA does not accept the cert either > locally or remotely as it does not trust it. > > anyone know how I can troubleshot this. I have reviewed the dirsrv logs > for ldap and I can't spot anything/. > > Regards > John > > > On Fri, Jan 11, 2013 at 5:55 PM, JR Aquino wrote: > >> Try editing /etc/openldap/ldap.conf: >> >> TLS_CACERT /etc/ipa/ca.crt >> TLS_REQCERT allow >> >> >> See if that helps >> >> "Keeping your head in the cloud" >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Jr Aquino | Sr. Information Security Specialist >> GIAC Exploit Researcher and Advanced Penetration Tester | >> GIAC Certified Incident Handler | GIAC WebApp Penetration Tester >> Citrix Online | 7408 Hollister Avenue | Goleta, CA >> 93117 >> T: +1 805.690.3478 >> C: +1 805.717.0365 >> jr.aquino at citrix.com >> http://www.citrixonline.com >> >> On Jan 11, 2013, at 8:05 AM, Johnathan Phan > > wrote: >> >> Hi There, >> >> This is driving me up the wall. >> >> I have two servers. 1 is a live openldap/kerberous AAA server running on >> RHEL6. The LDAP service has SSL/TS support. The second server is a test >> environment running on fedora and has 3.1 IPA installed. >> >> As a last step of my POC I need to migrate the users and passwords from >> the LDAP server to IPA server. >> >> I ran this command perfectly fine. >> >> ipa config-mod --enable-migration=TRUE >> >> However the next step was where my issues began. >> >> In the end after a lot of IRC communication and troubleshooting I now run >> the following command. >> >> ipa migrate-ds --bind-dn="cn=admin,dc=example,dc=com" >> --user-container="ou=users,ou=live,dc=example,dc=com" >> --group-container="ou=groups,ou=live,dc=example,dc=com" ldaps:// >> ldap1.live.example.com >> >> I get the following error. >> >> ipa: DEBUG: Caught fault 4203 from server >> http://fedoraipaserver.test.example.com/ipa/xml: Can't contact LDAP >> server: TLS error -8179:Peer's Certificate issuer is not recognized. >> ipa: DEBUG: Destroyed connection context.xmlclient >> ipa: ERROR: Can't contact LDAP server: TLS error -8179:Peer's Certificate >> issuer is not recognized. >> >> I have summarized that the IPA server does not trust the cert served by >> the openldap or the other way around. Does anyone know how to get around >> this? Or allow me to finish the migration of user data. >> >> Regards >> >> John >> >> -- >> Johnathan Phan >> >> T: +44 (0)784 118 7080 >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > > -- > Johnathan Phan > ox-consulting > > > T: +44 (0)784 118 7080 > john at ox-consulting.com > > www.ox-consulting.com > > OX CONSULTING Ltd is registered in England & Wales, number: 07113039, > registered address as above. > > The information contained in this email message may be privileged, > confidential or exempt from disclosure under applicable law. If you are not > the intended recipient, you are hereby notified that any use, > dissemination, distribution or copying of this transmission is strictly > prohibited. If you have received this communication in error, or if any > problems occur with transmission, please notify the sender immediately. > -- Johnathan Phan ox-consulting T: +44 (0)784 118 7080 john at ox-consulting.com www.ox-consulting.com OX CONSULTING Ltd is registered in England & Wales, number: 07113039, registered address as above. The information contained in this email message may be privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this transmission is strictly prohibited. If you have received this communication in error, or if any problems occur with transmission, please notify the sender immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Jan 14 18:09:50 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Jan 2013 13:09:50 -0500 Subject: [Freeipa-users] openldap to ipa In-Reply-To: References: <3817AE3D-3005-4B2A-830D-2140865B0DFD@citrixonline.com> Message-ID: <50F449EE.5090708@redhat.com> Johnathan Phan wrote: > Anyone know the details of the low level system steps for the migration > script to work? so I can try and backwards engineer or troubleshoot each > system as I go along so I can actually migrate the data from openldap to > ipa? The migration is taking place in the context of the web server. So any trust needs to be added to /etc/httpd/alias (and the httpd service restarted). It needs to trust the signer of the remote LDAP server. What I don't know is how you add trust in NSS for a self-signed server certificate. You might be best off issuing new SSL certs for your openldap server which uses a CA to issue the server cert in order to perform the migration. rob > > Regards > > John > > > On Mon, Jan 14, 2013 at 9:19 AM, Johnathan Phan > wrote: > > Hi Aquino, > > thanks for the input, however. There is a CRT in there already and > it was set to allow on both the IPA server and the target openldap > server. > the core of the issue seems to be that IPA does not accept the cert > either locally or remotely as it does not trust it. > > anyone know how I can troubleshot this. I have reviewed the dirsrv > logs for ldap and I can't spot anything/. > > Regards > John > > > On Fri, Jan 11, 2013 at 5:55 PM, JR Aquino > wrote: > > Try editing /etc/openldap/ldap.conf: > > TLS_CACERT /etc/ipa/ca.crt > TLS_REQCERT allow > > > See if that helps > > "Keeping your head in the cloud" > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Jr Aquino | Sr. Information Security Specialist > GIAC Exploit Researcher and Advanced Penetration Tester | > GIAC Certified Incident Handler | GIAC WebApp Penetration Tester > Citrix Online | 7408 Hollister Avenue | Goleta, CA > 93117 > T: +1 805.690.3478 > > C: +1 805.717.0365 > jr.aquino at citrix.com > > > http://www.citrixonline.com > > On Jan 11, 2013, at 8:05 AM, Johnathan Phan > >> wrote: > > Hi There, > > This is driving me up the wall. > > I have two servers. 1 is a live openldap/kerberous AAA server > running on RHEL6. The LDAP service has SSL/TS support. The > second server is a test environment running on fedora and has > 3.1 IPA installed. > > As a last step of my POC I need to migrate the users and > passwords from the LDAP server to IPA server. > > I ran this command perfectly fine. > > ipa config-mod --enable-migration=TRUE > > However the next step was where my issues began. > > In the end after a lot of IRC communication and troubleshooting > I now run the following command. > > ipa migrate-ds --bind-dn="cn=admin,dc=example,dc=com" > --user-container="ou=users,ou=live,dc=example,dc=com" > --group-container="ou=groups,ou=live,dc=example,dc=com" > ldaps://ldap1.live.example.com > > > I get the following error. > > ipa: DEBUG: Caught fault 4203 from server > http://fedoraipaserver.test.example.com/ipa/xml: Can't contact > LDAP server: TLS error -8179:Peer's Certificate issuer is not > recognized. > ipa: DEBUG: Destroyed connection context.xmlclient > ipa: ERROR: Can't contact LDAP server: TLS error -8179:Peer's > Certificate issuer is not recognized. > > I have summarized that the IPA server does not trust the cert > served by the openldap or the other way around. Does anyone know > how to get around this? Or allow me to finish the migration of > user data. > > Regards > > John > > -- > Johnathan Phan > > T: +44 (0)784 118 7080 > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > Johnathan Phan > ox-consulting > > > T: +44 (0)784 118 7080 > john at ox-consulting.com > > www.ox-consulting.com > > OX CONSULTING Ltd is registered in England & Wales, number: > 07113039, registered address as above. > > The information contained in this email message may be privileged, > confidential or exempt from disclosure under applicable law. If you > are not the intended recipient, you are hereby notified that any > use, dissemination, distribution or copying of this transmission is > strictly prohibited. If you have received this communication in > error, or if any problems occur with transmission, please notify the > sender immediately. > > > > > -- > Johnathan Phan > ox-consulting > > T: +44 (0)784 118 7080 > john at ox-consulting.com > > www.ox-consulting.com > > OX CONSULTING Ltd is registered in England & Wales, number: 07113039, > registered address as above. > > The information contained in this email message may be privileged, > confidential or exempt from disclosure under applicable law. If you are > not the intended recipient, you are hereby notified that any use, > dissemination, distribution or copying of this transmission is strictly > prohibited. If you have received this communication in error, or if any > problems occur with transmission, please notify the sender immediately. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From orion at cora.nwra.com Mon Jan 14 19:06:35 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 14 Jan 2013 12:06:35 -0700 Subject: [Freeipa-users] compat and ou=People Message-ID: <50F4573B.9030701@cora.nwra.com> We're looking at migrating from 389ds to ipa. Currently our users are in ou=People with rfc2307 attributes. Is there any way to provide an ou=people,dc=nwra,dc=com compatibility group in IPA? Or does everything have to remain under cn=compat? We have a lot of references to ou=People,dc=nwra,dc=com in clients. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From nalin at redhat.com Mon Jan 14 20:40:56 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 14 Jan 2013 15:40:56 -0500 Subject: [Freeipa-users] compat and ou=People In-Reply-To: <50F4573B.9030701@cora.nwra.com> References: <50F4573B.9030701@cora.nwra.com> Message-ID: <20130114204056.GG29792@redhat.com> On Mon, Jan 14, 2013 at 12:06:35PM -0700, Orion Poplawski wrote: > We're looking at migrating from 389ds to ipa. Currently our users > are in ou=People with rfc2307 attributes. Is there any way to > provide an ou=people,dc=nwra,dc=com compatibility group in IPA? Or > does everything have to remain under cn=compat? We have a lot of > references to ou=People,dc=nwra,dc=com in clients. Things show up under cn=compat because the Schema Compatibility plugin is configured to put them there. With a bit of manual configuration, the compatibility user entries can show up under ou=People, too. Here's an initial guess at how that'd look, mostly copy/pasted from the compat configuration: dn: ou=people,cn=Schema Compatibility,cn=plugins,cn=config schema-compat-entry-attribute: objectclass=posixAccount schema-compat-entry-attribute: gecos=%{cn} schema-compat-entry-attribute: cn=%{cn} schema-compat-entry-attribute: uidNumber=%{uidNumber} schema-compat-entry-attribute: gidNumber=%{gidNumber} schema-compat-entry-attribute: loginShell=%{loginShell} schema-compat-entry-attribute: homeDirectory=%{homeDirectory} ou: people objectClass: top objectClass: extensibleObject schema-compat-search-filter: objectclass=posixAccount schema-compat-entry-rdn: uid=%{uid} schema-compat-search-base: cn=users, cn=accounts, dc=nwra,dc=com schema-compat-container-group: ou=people,dc=nwra,dc=com You'd need to stop the directory server, add this to its dse.ldif file, and start it up again. HTH, Nalin From orion at cora.nwra.com Mon Jan 14 22:23:50 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 14 Jan 2013 15:23:50 -0700 Subject: [Freeipa-users] compat and ou=People In-Reply-To: <20130114204056.GG29792@redhat.com> References: <50F4573B.9030701@cora.nwra.com> <20130114204056.GG29792@redhat.com> Message-ID: <50F48576.3030403@cora.nwra.com> On 01/14/2013 01:40 PM, Nalin Dahyabhai wrote: > On Mon, Jan 14, 2013 at 12:06:35PM -0700, Orion Poplawski wrote: >> We're looking at migrating from 389ds to ipa. Currently our users >> are in ou=People with rfc2307 attributes. Is there any way to >> provide an ou=people,dc=nwra,dc=com compatibility group in IPA? Or >> does everything have to remain under cn=compat? We have a lot of >> references to ou=People,dc=nwra,dc=com in clients. > > Things show up under cn=compat because the Schema Compatibility plugin > is configured to put them there. With a bit of manual configuration, > the compatibility user entries can show up under ou=People, too. Here's > an initial guess at how that'd look, mostly copy/pasted from the compat > configuration: > > dn: ou=people,cn=Schema Compatibility,cn=plugins,cn=config > schema-compat-entry-attribute: objectclass=posixAccount > schema-compat-entry-attribute: gecos=%{cn} > schema-compat-entry-attribute: cn=%{cn} > schema-compat-entry-attribute: uidNumber=%{uidNumber} > schema-compat-entry-attribute: gidNumber=%{gidNumber} > schema-compat-entry-attribute: loginShell=%{loginShell} > schema-compat-entry-attribute: homeDirectory=%{homeDirectory} > ou: people > objectClass: top > objectClass: extensibleObject > schema-compat-search-filter: objectclass=posixAccount > schema-compat-entry-rdn: uid=%{uid} > schema-compat-search-base: cn=users, cn=accounts, dc=nwra,dc=com > schema-compat-container-group: ou=people,dc=nwra,dc=com > > You'd need to stop the directory server, add this to its dse.ldif file, > and start it up again. > > HTH, > > Nalin > Great, that seems to work well. Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From william.muriithi at gmail.com Mon Jan 14 22:59:49 2013 From: william.muriithi at gmail.com (William Muriithi) Date: Mon, 14 Jan 2013 17:59:49 -0500 Subject: [Freeipa-users] Process conflict issue when restarting IPA Message-ID: Hello When I restart IPA through ipactl, I get the following message. All seem to be working despite the message. I think it is pki-ca that is running on tomcat Starting httpd: [Fri Jan 11 16:13:25 2013] [warn] worker ajp://localhost:9447/ already used by another worker [Fri Jan 11 16:13:25 2013] [warn] worker ajp://localhost:9447/ already used by another worker I assume there may be a bug on the ipactl script, is this a correct assumption? Regards William From dpal at redhat.com Tue Jan 15 01:11:06 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 14 Jan 2013 20:11:06 -0500 Subject: [Freeipa-users] Process conflict issue when restarting IPA In-Reply-To: References: Message-ID: <50F4ACAA.2030407@redhat.com> On 01/14/2013 05:59 PM, William Muriithi wrote: > Hello > > When I restart IPA through ipactl, I get the following message. All > seem to be working despite the message. I think it is pki-ca that is > running on tomcat > > Starting httpd: [Fri Jan 11 16:13:25 2013] [warn] worker > ajp://localhost:9447/ already used by another worker > [Fri Jan 11 16:13:25 2013] [warn] worker ajp://localhost:9447/ already > used by another worker > > I assume there may be a bug on the ipactl script, is this a correct assumption? > > Regards > > William > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Which version you are on? This issue seems to be addressed quite some time ago https://fedorahosted.org/freeipa/ticket/2333 https://bugzilla.redhat.com/show_bug.cgi?id=785791 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From brs at usf.edu Tue Jan 15 01:16:41 2013 From: brs at usf.edu (Brian Smith) Date: Mon, 14 Jan 2013 20:16:41 -0500 Subject: [Freeipa-users] JSON-RPC documentation? Message-ID: Before I pester the dev list, I was wondering if anyone here could point me to documentation on the JSON-RPC interface to FreeIPA. I'm not doing anything fancy, just adding users and updating passwords, so my requirements are pretty tame. I've gone through the Python code and have somewhat pieced it together myself, but would be more comfortable if there were official docs. Thanks, -- Brian Smith Assistant Director Research Computing, University of South Florida 4202 E. Fowler Ave. SVC4010 Office Phone: +1 813 974-1467 Organization URL: http://rc.usf.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Jan 15 01:48:12 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 14 Jan 2013 20:48:12 -0500 Subject: [Freeipa-users] JSON-RPC documentation? In-Reply-To: References: Message-ID: <50F4B55C.4040507@redhat.com> On 01/14/2013 08:16 PM, Brian Smith wrote: > Before I pester the dev list, I was wondering if anyone here could > point me to documentation on the JSON-RPC interface to FreeIPA. I'm > not doing anything fancy, just adding users and updating passwords, so > my requirements are pretty tame. I've gone through the Python code > and have somewhat pieced it together myself, but would be more > comfortable if there were official docs. > I do not remember us having documentation about XML-RPC but I will check. We are actually debating deprecating XML-RPC over time in favor of JSON. > Thanks, > > -- > Brian Smith > Assistant Director > Research Computing, University of South Florida > 4202 E. Fowler Ave. SVC4010 > Office Phone: +1 813 974-1467 > Organization URL: http://rc.usf.edu > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Jan 15 02:35:53 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Jan 2013 21:35:53 -0500 Subject: [Freeipa-users] JSON-RPC documentation? In-Reply-To: <50F4B55C.4040507@redhat.com> References: <50F4B55C.4040507@redhat.com> Message-ID: <50F4C089.90801@redhat.com> Dmitri Pal wrote: > On 01/14/2013 08:16 PM, Brian Smith wrote: >> Before I pester the dev list, I was wondering if anyone here could >> point me to documentation on the JSON-RPC interface to FreeIPA. I'm >> not doing anything fancy, just adding users and updating passwords, so >> my requirements are pretty tame. I've gone through the Python code >> and have somewhat pieced it together myself, but would be more >> comfortable if there were official docs. >> > I do not remember us having documentation about XML-RPC but I will check. > We are actually debating deprecating XML-RPC over time in favor of JSON. There is no official documentation on either XML-RPC or JSON. The format is rather straightforward once you get the hang of things. Each command is effectively an RPC function (e.g ipa user-add -> user_add). The arguments consist of positional arguments followed by named arguments (there is usually only one positional arg). For XML-RPC it is generally fairly easy to work out what it's doing by adding -vv option to the command-line to see the raw request and response. I personally haven't done a lot of raw JSON work. The final option is to skip all that and use the ipalib to do the work for you. For example, to add a user you'd do something like: from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.xmlclient.connect() try: api.Command['user_add'](u'newuser', loginshell=u'/bin/something', givenname=u'New', sn=u'User') except errors.DuplicateEntry: print "user already exists" else: print "user added" From brs at usf.edu Tue Jan 15 02:55:23 2013 From: brs at usf.edu (Brian Smith) Date: Mon, 14 Jan 2013 21:55:23 -0500 Subject: [Freeipa-users] JSON-RPC documentation? In-Reply-To: <50F4C089.90801@redhat.com> References: <50F4B55C.4040507@redhat.com> <50F4C089.90801@redhat.com> Message-ID: That helps a lot. Thanks! I would use ipalib, but I'm developing a Rails application, so the JSON interface is the quickest (and since XML may be deprecated) best way forward (unless you know a way to use it in Ruby :). I'm guessing in JSON, the structure would look something like this: { "method": "user_add", "params": [ [], { "uid":"testuser", "givenname":"Test", "sn":"User", "userpassword":"mySecretPasswordBlahBlah" ... } ] } Maybe I'll try to compile some documentation. I know that this page helped a lot, to cook up a quick ruby client with Curb: http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ On Mon, Jan 14, 2013 at 9:35 PM, Rob Crittenden wrote: > Dmitri Pal wrote: > >> On 01/14/2013 08:16 PM, Brian Smith wrote: >> >>> Before I pester the dev list, I was wondering if anyone here could >>> point me to documentation on the JSON-RPC interface to FreeIPA. I'm >>> not doing anything fancy, just adding users and updating passwords, so >>> my requirements are pretty tame. I've gone through the Python code >>> and have somewhat pieced it together myself, but would be more >>> comfortable if there were official docs. >>> >>> I do not remember us having documentation about XML-RPC but I will >> check. >> We are actually debating deprecating XML-RPC over time in favor of JSON. >> > > There is no official documentation on either XML-RPC or JSON. The format > is rather straightforward once you get the hang of things. Each command is > effectively an RPC function (e.g ipa user-add -> user_add). The arguments > consist of positional arguments followed by named arguments (there is > usually only one positional arg). > > For XML-RPC it is generally fairly easy to work out what it's doing by > adding -vv option to the command-line to see the raw request and response. > I personally haven't done a lot of raw JSON work. > > The final option is to skip all that and use the ipalib to do the work for > you. > > For example, to add a user you'd do something like: > > from ipalib import api > from ipalib import errors > > api.bootstrap(context='cli') > api.finalize() > api.Backend.xmlclient.connect(**) > > try: > api.Command['user_add'](u'**newuser', > loginshell=u'/bin/something', > givenname=u'New', sn=u'User') > except errors.DuplicateEntry: > print "user already exists" > else: > print "user added" > > > ______________________________**_________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/**mailman/listinfo/freeipa-users > -- Brian Smith Assistant Director Research Computing, University of South Florida 4202 E. Fowler Ave. SVC4010 Office Phone: +1 813 974-1467 Organization URL: http://rc.usf.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From thildred at redhat.com Tue Jan 15 04:29:47 2013 From: thildred at redhat.com (Tim Hildred) Date: Mon, 14 Jan 2013 23:29:47 -0500 (EST) Subject: [Freeipa-users] DNS chages made from the WebUI take a long time to be recognized. Message-ID: <1042161063.19637817.1358224187778.JavaMail.root@redhat.com> Should it take several hours for me to be able to ping a host at it's new IP address when I update the DNS record in the WebUI? I deleted the old records (A and PTR), and added new records for the same FQDN, with a different IP address. But I can't ping the host using the FQDN. Tim Hildred, RHCE Content Author II - Engineering Content Services, Red Hat, Inc. Brisbane, Australia Email: thildred at redhat.com Internal: 8588287 Mobile: +61 4 666 25242 IRC: thildred From mkosek at redhat.com Tue Jan 15 08:34:22 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 15 Jan 2013 09:34:22 +0100 Subject: [Freeipa-users] DNS chages made from the WebUI take a long time to be recognized. In-Reply-To: <1042161063.19637817.1358224187778.JavaMail.root@redhat.com> References: <1042161063.19637817.1358224187778.JavaMail.root@redhat.com> Message-ID: <50F5148E.10906@redhat.com> On 01/15/2013 05:29 AM, Tim Hildred wrote: > Should it take several hours for me to be able to ping a host at it's new IP address when I update the DNS record in the WebUI? > > I deleted the old records (A and PTR), and added new records for the same FQDN, with a different IP address. But I can't ping the host using the FQDN. > > Tim Hildred, RHCE > Content Author II - Engineering Content Services, Red Hat, Inc. > Brisbane, Australia > Email: thildred at redhat.com > Internal: 8588287 > Mobile: +61 4 666 25242 > IRC: thildred > Hello Tim, Isn't DNS caching taking place in your situation? I would check TTL of the records you try to change and retrieve. Do you hit the same issue when you add a new record (a new FQDN)? I would also check if nscd in your client box is not running, it may cache these DNS records. Martin From john at ox-consulting.com Tue Jan 15 09:35:50 2013 From: john at ox-consulting.com (Johnathan Phan) Date: Tue, 15 Jan 2013 09:35:50 +0000 Subject: [Freeipa-users] openldap to ipa In-Reply-To: <50F449EE.5090708@redhat.com> References: <3817AE3D-3005-4B2A-830D-2140865B0DFD@citrixonline.com> <50F449EE.5090708@redhat.com> Message-ID: Hi Rcrit, As Outlined in the IRC channel. Please find the ldap.conf from the open ldap server below. URI ldap://ldap.example.com ldap://ldap1.example.com BASE dc=example,dc=com TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt I then copy the file /etc/pki/tls/certs/ca-bundle.crt from the openldap server over to the test IPA server and on the IPA server I run the following command. certutil -A -d /etc/httpd/alias -n 'openldap CA' -t CT,, -a -i ca-bundle.crt The openldap server is using a certificate signed by a CA. The IPA server is using the self signed certificate it generated when starting up. I still get the error after adding the CA bundle for openldap server to the apache cert db on IPA server. After explaining all this, I feel that the problem lies with the self signed cert on the IPA server. Can I confirm with someone the process in which the migration of data occurs? I gather the it something like this. 1 >IPA binds/creates a connection to the remote server via SSL/TSL and creates a connection 2> It then binds to a socket locally 3> Then contacts the apache server for some reason (no idea why this is contacting apache on 443?) Regards John On Mon, Jan 14, 2013 at 6:09 PM, Rob Crittenden wrote: > Johnathan Phan wrote: > >> Anyone know the details of the low level system steps for the migration >> script to work? so I can try and backwards engineer or troubleshoot each >> system as I go along so I can actually migrate the data from openldap to >> ipa? >> > > The migration is taking place in the context of the web server. So any > trust needs to be added to /etc/httpd/alias (and the httpd service > restarted). It needs to trust the signer of the remote LDAP server. What I > don't know is how you add trust in NSS for a self-signed server > certificate. You might be best off issuing new SSL certs for your openldap > server which uses a CA to issue the server cert in order to perform the > migration. > > rob > > >> Regards >> >> John >> >> >> On Mon, Jan 14, 2013 at 9:19 AM, Johnathan Phan > > wrote: >> >> Hi Aquino, >> >> thanks for the input, however. There is a CRT in there already and >> it was set to allow on both the IPA server and the target openldap >> server. >> the core of the issue seems to be that IPA does not accept the cert >> either locally or remotely as it does not trust it. >> >> anyone know how I can troubleshot this. I have reviewed the dirsrv >> logs for ldap and I can't spot anything/. >> >> Regards >> John >> >> >> On Fri, Jan 11, 2013 at 5:55 PM, JR Aquino > > wrote: >> >> Try editing /etc/openldap/ldap.conf: >> >> TLS_CACERT /etc/ipa/ca.crt >> TLS_REQCERT allow >> >> >> See if that helps >> >> "Keeping your head in the cloud" >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~**~~~~~~~ >> Jr Aquino | Sr. Information Security Specialist >> GIAC Exploit Researcher and Advanced Penetration Tester | >> GIAC Certified Incident Handler | GIAC WebApp Penetration Tester >> Citrix Online | 7408 Hollister Avenue | Goleta, CA >> 93117 >> T: +1 805.690.3478 >> >> C: +1 805.717.0365 > +1%20805.717.0365> >> jr.aquino at citrix.com >> <**mailto:jr.aquino at citrixonline.** >> com >> >> >> >> >> http://www.citrixonline.com >> > >> >> On Jan 11, 2013, at 8:05 AM, Johnathan Phan >> > >> >> >> wrote: >> >> Hi There, >> >> This is driving me up the wall. >> >> I have two servers. 1 is a live openldap/kerberous AAA server >> running on RHEL6. The LDAP service has SSL/TS support. The >> second server is a test environment running on fedora and has >> 3.1 IPA installed. >> >> As a last step of my POC I need to migrate the users and >> passwords from the LDAP server to IPA server. >> >> I ran this command perfectly fine. >> >> ipa config-mod --enable-migration=TRUE >> >> However the next step was where my issues began. >> >> In the end after a lot of IRC communication and troubleshooting >> I now run the following command. >> >> ipa migrate-ds --bind-dn="cn=admin,dc=**example,dc=com" >> --user-container="ou=users,ou=**live,dc=example,dc=com" >> --group-container="ou=groups,**ou=live,dc=example,dc=com" >> ldaps://ldap1.live.example.com >> > com/ > >> >> >> I get the following error. >> >> ipa: DEBUG: Caught fault 4203 from server >> http://fedoraipaserver.test.**example.com/ipa/xml: >> Can't contact >> LDAP server: TLS error -8179:Peer's Certificate issuer is not >> recognized. >> ipa: DEBUG: Destroyed connection context.xmlclient >> ipa: ERROR: Can't contact LDAP server: TLS error -8179:Peer's >> Certificate issuer is not recognized. >> >> I have summarized that the IPA server does not trust the cert >> served by the openldap or the other way around. Does anyone know >> how to get around this? Or allow me to finish the migration of >> user data. >> >> Regards >> >> John >> >> -- >> Johnathan Phan >> >> T: +44 (0)784 118 7080 >> >> >> >> >> ______________________________**_________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> >> > > Freeipa-users at redhat.**com >> >> >> https://www.redhat.com/**mailman/listinfo/freeipa-users >> >> >> >> >> -- >> Johnathan Phan >> ox-consulting >> >> >> T: +44 (0)784 118 7080 >> john at ox-consulting.com >> >> www.ox-consulting.com >> >> >> OX CONSULTING Ltd is registered in England & Wales, number: >> 07113039, registered address as above. >> >> The information contained in this email message may be privileged, >> confidential or exempt from disclosure under applicable law. If you >> are not the intended recipient, you are hereby notified that any >> use, dissemination, distribution or copying of this transmission is >> strictly prohibited. If you have received this communication in >> error, or if any problems occur with transmission, please notify the >> sender immediately. >> >> >> >> >> -- >> Johnathan Phan >> ox-consulting >> >> T: +44 (0)784 118 7080 >> john at ox-consulting.com >> >> www.ox-consulting.com >> >> >> OX CONSULTING Ltd is registered in England & Wales, number: 07113039, >> registered address as above. >> >> The information contained in this email message may be privileged, >> confidential or exempt from disclosure under applicable law. If you are >> not the intended recipient, you are hereby notified that any use, >> dissemination, distribution or copying of this transmission is strictly >> prohibited. If you have received this communication in error, or if any >> problems occur with transmission, please notify the sender immediately. >> >> >> ______________________________**_________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/**mailman/listinfo/freeipa-users >> >> > -- Johnathan Phan ox-consulting T: +44 (0)784 118 7080 john at ox-consulting.com www.ox-consulting.com OX CONSULTING Ltd is registered in England & Wales, number: 07113039, registered address as above. The information contained in this email message may be privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this transmission is strictly prohibited. If you have received this communication in error, or if any problems occur with transmission, please notify the sender immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Tue Jan 15 11:37:02 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 15 Jan 2013 12:37:02 +0100 Subject: [Freeipa-users] JSON-RPC documentation? In-Reply-To: References: <50F4B55C.4040507@redhat.com> <50F4C089.90801@redhat.com> Message-ID: <50F53F5E.8030702@redhat.com> Hello Brian, On 01/15/2013 03:55 AM, Brian Smith wrote: > That helps a lot. Thanks! I would use ipalib, but I'm developing a > Rails application, so the JSON interface is the quickest (and since XML > may be deprecated) While XML may be deprecated, it'll stick around for a long time. But JSON is a good choice. > best way forward (unless you know a way to use it in > Ruby :). I'm guessing in JSON, the structure would look something like > this: > > { > "method": "user_add", > "params": [ > [], > { > "uid":"testuser", > "givenname":"Test", > "sn":"User", > "userpassword":"mySecretPasswordBlahBlah" > ... > } > ] > } > > Maybe I'll try to compile some documentation. I know that this page > helped a lot, to cook up a quick ruby client with Curb: > http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ > I've just CC-d you on a patch to the devel list that switches the IPA client to JSON-RPC. To use it: - Check out the git master and apply the patch - Copy /etc/ipa/default.conf to ~/.ipa/default.conf - Now a command like `./ipa -vv user-find` will print out the JSON it sends & receives. It dumps the whole request/response so the output is not ideal for your use, but I'm sure you can handle it. It works from the source tree, no build/installation required. You probably found out that the CLI options and API options/LDAP attributes sometimes have different names. The `ipa show-mappings` command can give you a mapping table. One more thing: please add the API version to your requests to prevent surprises down the road. The official client doesn't currently always do that; this is a bug. You can get the current version with `ipa ping`: $ ipa ping ------------------------------------------ IPA server version 3.1.0. API version 2.47 ------------------------------------------ { "method": "user_add", "params": [ [], { "uid":"testuser", "givenname":"Test", "sn":"User", "userpassword":"mySecretPasswordBlahBlah" ... "version": "2.47", } ] } -- Petr? From pvoborni at redhat.com Tue Jan 15 11:55:15 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 15 Jan 2013 12:55:15 +0100 Subject: [Freeipa-users] JSON-RPC documentation? In-Reply-To: References: <50F4B55C.4040507@redhat.com> <50F4C089.90801@redhat.com> Message-ID: <50F543A3.9000701@redhat.com> Spying Web UI might be another way how to learn the API. Web UI uses JSON interface for everything it does. You can open developer tools in Chrome (hit F12) and watch communication (network tab). Do something and then look for requests named 'json' a inspect the request payload. To inspect the API alone you can go through metadata (in console tab) which are stored in IPA.metadata object but I guess inspecting python code might be easier. HTH On 01/15/2013 03:55 AM, Brian Smith wrote: > That helps a lot. Thanks! I would use ipalib, but I'm developing a Rails > application, so the JSON interface is the quickest (and since XML may be > deprecated) best way forward (unless you know a way to use it in Ruby :). > I'm guessing in JSON, the structure would look something like this: > > { > "method": "user_add", > "params": [ > [], > { > "uid":"testuser", > "givenname":"Test", > "sn":"User", > "userpassword":"mySecretPasswordBlahBlah" > ... > } > ] > } > > Maybe I'll try to compile some documentation. I know that this page helped > a lot, to cook up a quick ruby client with Curb: > http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ > > > On Mon, Jan 14, 2013 at 9:35 PM, Rob Crittenden wrote: > >> Dmitri Pal wrote: >> >>> On 01/14/2013 08:16 PM, Brian Smith wrote: >>> >>>> Before I pester the dev list, I was wondering if anyone here could >>>> point me to documentation on the JSON-RPC interface to FreeIPA. I'm >>>> not doing anything fancy, just adding users and updating passwords, so >>>> my requirements are pretty tame. I've gone through the Python code >>>> and have somewhat pieced it together myself, but would be more >>>> comfortable if there were official docs. >>>> >>>> I do not remember us having documentation about XML-RPC but I will >>> check. >>> We are actually debating deprecating XML-RPC over time in favor of JSON. >>> >> >> There is no official documentation on either XML-RPC or JSON. The format >> is rather straightforward once you get the hang of things. Each command is >> effectively an RPC function (e.g ipa user-add -> user_add). The arguments >> consist of positional arguments followed by named arguments (there is >> usually only one positional arg). >> >> For XML-RPC it is generally fairly easy to work out what it's doing by >> adding -vv option to the command-line to see the raw request and response. >> I personally haven't done a lot of raw JSON work. >> >> The final option is to skip all that and use the ipalib to do the work for >> you. >> >> For example, to add a user you'd do something like: >> >> from ipalib import api >> from ipalib import errors >> >> api.bootstrap(context='cli') >> api.finalize() >> api.Backend.xmlclient.connect(**) >> >> try: >> api.Command['user_add'](u'**newuser', >> loginshell=u'/bin/something', >> givenname=u'New', sn=u'User') >> except errors.DuplicateEntry: >> print "user already exists" >> else: >> print "user added" >> >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Petr Vobornik From mmercier at gmail.com Tue Jan 15 14:15:51 2013 From: mmercier at gmail.com (Michael Mercier) Date: Tue, 15 Jan 2013 09:15:51 -0500 Subject: [Freeipa-users] Process conflict issue when restarting IPA In-Reply-To: <50F4ACAA.2030407@redhat.com> References: <50F4ACAA.2030407@redhat.com> Message-ID: <6BD2A6F4-B466-4110-9B92-729683073F81@gmail.com> On 2013-01-14, at 8:11 PM, Dmitri Pal wrote: > On 01/14/2013 05:59 PM, William Muriithi wrote: >> Hello >> >> When I restart IPA through ipactl, I get the following message. All >> seem to be working despite the message. I think it is pki-ca that is >> running on tomcat >> >> Starting httpd: [Fri Jan 11 16:13:25 2013] [warn] worker >> ajp://localhost:9447/ already used by another worker >> [Fri Jan 11 16:13:25 2013] [warn] worker ajp://localhost:9447/ already >> used by another worker >> >> I assume there may be a bug on the ipactl script, is this a correct assumption? >> >> Regards >> >> William >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > Which version you are on? > > This issue seems to be addressed quite some time ago > https://fedorahosted.org/freeipa/ticket/2333 > https://bugzilla.redhat.com/show_bug.cgi?id=785791 I see the same issue as William on CentOS6.3 fully up-to-date... [root at test-1 ~]# rpm -qa|grep ipa ipa-client-2.2.0-16.el6.x86_64 ipa-server-selinux-2.2.0-16.el6.x86_64 libipa_hbac-1.8.0-32.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch python-iniparse-0.3.1-2.1.el6.noarch ipa-python-2.2.0-16.el6.x86_64 ipa-admintools-2.2.0-16.el6.x86_64 ipa-server-2.2.0-16.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.8.0-32.el6.x86_64 [root at test-1 ~]# yum update Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile base | 3.7 kB 00:00 extras | 3.5 kB 00:00 updates | 3.5 kB 00:00 Setting up Update Process No Packages marked for Update [root at service-1 ~]# ipactl restart Restarting Directory Service Shutting down dirsrv: TEST-LOCAL... [ OK ] PKI-IPA... [ OK ] Starting dirsrv: TEST-LOCAL... [ OK ] PKI-IPA... [ OK ] Restarting KDC Service Stopping Kerberos 5 KDC: [ OK ] Starting Kerberos 5 KDC: [ OK ] Restarting KPASSWD Service Stopping Kerberos 5 Admin Server: [ OK ] Starting Kerberos 5 Admin Server: [ OK ] Restarting DNS Service Stopping named: .... [ OK ] Starting named: [ OK ] Restarting MEMCACHE Service Stopping ipa_memcached: [ OK ] Starting ipa_memcached: [ OK ] Restarting HTTP Service Stopping httpd: [ OK ] Starting httpd: [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker [ OK ] Restarting CA Service Stopping pki-ca: [ OK ] Starting pki-ca: [ OK ] [root at test-1 ~]# Thanks, Mike > > -- > 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 at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From simo at redhat.com Tue Jan 15 14:36:25 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 15 Jan 2013 09:36:25 -0500 Subject: [Freeipa-users] Process conflict issue when restarting IPA In-Reply-To: <6BD2A6F4-B466-4110-9B92-729683073F81@gmail.com> References: <50F4ACAA.2030407@redhat.com> <6BD2A6F4-B466-4110-9B92-729683073F81@gmail.com> Message-ID: <1358260585.15136.125.camel@willson.li.ssimo.org> On Tue, 2013-01-15 at 09:15 -0500, Michael Mercier wrote: > On 2013-01-14, at 8:11 PM, Dmitri Pal wrote: > > > On 01/14/2013 05:59 PM, William Muriithi wrote: > >> Hello > >> > >> When I restart IPA through ipactl, I get the following message. All > >> seem to be working despite the message. I think it is pki-ca that is > >> running on tomcat > >> > >> Starting httpd: [Fri Jan 11 16:13:25 2013] [warn] worker > >> ajp://localhost:9447/ already used by another worker > >> [Fri Jan 11 16:13:25 2013] [warn] worker ajp://localhost:9447/ already > >> used by another worker > >> > >> I assume there may be a bug on the ipactl script, is this a correct assumption? > >> > >> Regards > >> > >> William > >> > >> _______________________________________________ > >> Freeipa-users mailing list > >> Freeipa-users at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-users > > Which version you are on? > > > > This issue seems to be addressed quite some time ago > > https://fedorahosted.org/freeipa/ticket/2333 > > https://bugzilla.redhat.com/show_bug.cgi?id=785791 > > I see the same issue as William on CentOS6.3 fully up-to-date... > > [root at test-1 ~]# rpm -qa|grep ipa > ipa-client-2.2.0-16.el6.x86_64 > ipa-server-selinux-2.2.0-16.el6.x86_64 > libipa_hbac-1.8.0-32.el6.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > python-iniparse-0.3.1-2.1.el6.noarch > ipa-python-2.2.0-16.el6.x86_64 > ipa-admintools-2.2.0-16.el6.x86_64 > ipa-server-2.2.0-16.el6.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > libipa_hbac-python-1.8.0-32.el6.x86_64 > [root at test-1 ~]# yum update > Loaded plugins: fastestmirror > Loading mirror speeds from cached hostfile > base | 3.7 kB 00:00 > extras | 3.5 kB 00:00 > updates | 3.5 kB 00:00 > Setting up Update Process > No Packages marked for Update > [root at service-1 ~]# ipactl restart > Restarting Directory Service > Shutting down dirsrv: > TEST-LOCAL... [ OK ] > PKI-IPA... [ OK ] > Starting dirsrv: > TEST-LOCAL... [ OK ] > PKI-IPA... [ OK ] > Restarting KDC Service > Stopping Kerberos 5 KDC: [ OK ] > Starting Kerberos 5 KDC: [ OK ] > Restarting KPASSWD Service > Stopping Kerberos 5 Admin Server: [ OK ] > Starting Kerberos 5 Admin Server: [ OK ] > Restarting DNS Service > Stopping named: .... [ OK ] > Starting named: [ OK ] > Restarting MEMCACHE Service > Stopping ipa_memcached: [ OK ] > Starting ipa_memcached: [ OK ] > Restarting HTTP Service > Stopping httpd: [ OK ] > Starting httpd: [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker > [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker > [ OK ] > Restarting CA Service > Stopping pki-ca: [ OK ] > Starting pki-ca: [ OK ] > [root at test-1 ~]# AFAIK it is a know harmless bug in that version of apache/ajp and can be safely ignored. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Jan 15 15:14:41 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Jan 2013 10:14:41 -0500 Subject: [Freeipa-users] Process conflict issue when restarting IPA In-Reply-To: <1358260585.15136.125.camel@willson.li.ssimo.org> References: <50F4ACAA.2030407@redhat.com> <6BD2A6F4-B466-4110-9B92-729683073F81@gmail.com> <1358260585.15136.125.camel@willson.li.ssimo.org> Message-ID: <50F57261.3030709@redhat.com> Simo Sorce wrote: > On Tue, 2013-01-15 at 09:15 -0500, Michael Mercier wrote: >> On 2013-01-14, at 8:11 PM, Dmitri Pal wrote: >> >>> On 01/14/2013 05:59 PM, William Muriithi wrote: >>>> Hello >>>> >>>> When I restart IPA through ipactl, I get the following message. All >>>> seem to be working despite the message. I think it is pki-ca that is >>>> running on tomcat >>>> >>>> Starting httpd: [Fri Jan 11 16:13:25 2013] [warn] worker >>>> ajp://localhost:9447/ already used by another worker >>>> [Fri Jan 11 16:13:25 2013] [warn] worker ajp://localhost:9447/ already >>>> used by another worker >>>> >>>> I assume there may be a bug on the ipactl script, is this a correct assumption? >>>> >>>> Regards >>>> >>>> William >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Which version you are on? >>> >>> This issue seems to be addressed quite some time ago >>> https://fedorahosted.org/freeipa/ticket/2333 >>> https://bugzilla.redhat.com/show_bug.cgi?id=785791 >> >> I see the same issue as William on CentOS6.3 fully up-to-date... >> >> [root at test-1 ~]# rpm -qa|grep ipa >> ipa-client-2.2.0-16.el6.x86_64 >> ipa-server-selinux-2.2.0-16.el6.x86_64 >> libipa_hbac-1.8.0-32.el6.x86_64 >> ipa-pki-common-theme-9.0.3-7.el6.noarch >> python-iniparse-0.3.1-2.1.el6.noarch >> ipa-python-2.2.0-16.el6.x86_64 >> ipa-admintools-2.2.0-16.el6.x86_64 >> ipa-server-2.2.0-16.el6.x86_64 >> ipa-pki-ca-theme-9.0.3-7.el6.noarch >> libipa_hbac-python-1.8.0-32.el6.x86_64 >> [root at test-1 ~]# yum update >> Loaded plugins: fastestmirror >> Loading mirror speeds from cached hostfile >> base | 3.7 kB 00:00 >> extras | 3.5 kB 00:00 >> updates | 3.5 kB 00:00 >> Setting up Update Process >> No Packages marked for Update >> [root at service-1 ~]# ipactl restart >> Restarting Directory Service >> Shutting down dirsrv: >> TEST-LOCAL... [ OK ] >> PKI-IPA... [ OK ] >> Starting dirsrv: >> TEST-LOCAL... [ OK ] >> PKI-IPA... [ OK ] >> Restarting KDC Service >> Stopping Kerberos 5 KDC: [ OK ] >> Starting Kerberos 5 KDC: [ OK ] >> Restarting KPASSWD Service >> Stopping Kerberos 5 Admin Server: [ OK ] >> Starting Kerberos 5 Admin Server: [ OK ] >> Restarting DNS Service >> Stopping named: .... [ OK ] >> Starting named: [ OK ] >> Restarting MEMCACHE Service >> Stopping ipa_memcached: [ OK ] >> Starting ipa_memcached: [ OK ] >> Restarting HTTP Service >> Stopping httpd: [ OK ] >> Starting httpd: [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker >> [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker >> [ OK ] >> Restarting CA Service >> Stopping pki-ca: [ OK ] >> Starting pki-ca: [ OK ] >> [root at test-1 ~]# > > AFAIK it is a know harmless bug in that version of apache/ajp and can be > safely ignored. > > Simo. > That is correct, it is a red herring. It is fixed upstream in httpd and should be fixed in the next release of RHEL. rob That From brs at usf.edu Tue Jan 15 15:20:02 2013 From: brs at usf.edu (Brian Smith) Date: Tue, 15 Jan 2013 10:20:02 -0500 Subject: [Freeipa-users] JSON-RPC documentation? In-Reply-To: <50F543A3.9000701@redhat.com> References: <50F4B55C.4040507@redhat.com> <50F4C089.90801@redhat.com> <50F543A3.9000701@redhat.com> Message-ID: These posts have all been really helpful (especially -vv... its mostly trivial to translate to JSON from the XML). Thanks a lot for the suggestions! I do have one question that might be a new thread, but for me its related. I've added a service account user to the passSyncManagersDNs multi-valued list to avoid the initial account expiration, but it seems to put a 3 month expiration on the account despite the fact that my global password policy is 180 days. Anyone know what gives? Thanks again! -Brian On Tue, Jan 15, 2013 at 6:55 AM, Petr Vobornik wrote: > Spying Web UI might be another way how to learn the API. > > Web UI uses JSON interface for everything it does. You can open developer > tools in Chrome (hit F12) and watch communication (network tab). Do > something and then look for requests named 'json' a inspect the request > payload. > > To inspect the API alone you can go through metadata (in console tab) > which are stored in IPA.metadata object but I guess inspecting python code > might be easier. > > HTH > > > On 01/15/2013 03:55 AM, Brian Smith wrote: > >> That helps a lot. Thanks! I would use ipalib, but I'm developing a Rails >> application, so the JSON interface is the quickest (and since XML may be >> deprecated) best way forward (unless you know a way to use it in Ruby :). >> I'm guessing in JSON, the structure would look something like this: >> >> { >> "method": "user_add", >> "params": [ >> [], >> { >> "uid":"testuser", >> "givenname":"Test", >> "sn":"User", >> "userpassword":"**mySecretPasswordBlahBlah" >> ... >> } >> ] >> } >> >> Maybe I'll try to compile some documentation. I know that this page >> helped >> a lot, to cook up a quick ruby client with Curb: >> http://adam.younglogic.com/**2010/07/talking-to-freeipa-** >> json-web-api-via-curl/ >> >> >> On Mon, Jan 14, 2013 at 9:35 PM, Rob Crittenden >> wrote: >> >> Dmitri Pal wrote: >>> >>> On 01/14/2013 08:16 PM, Brian Smith wrote: >>>> >>>> Before I pester the dev list, I was wondering if anyone here could >>>>> point me to documentation on the JSON-RPC interface to FreeIPA. I'm >>>>> not doing anything fancy, just adding users and updating passwords, so >>>>> my requirements are pretty tame. I've gone through the Python code >>>>> and have somewhat pieced it together myself, but would be more >>>>> comfortable if there were official docs. >>>>> >>>>> I do not remember us having documentation about XML-RPC but I will >>>>> >>>> check. >>>> We are actually debating deprecating XML-RPC over time in favor of JSON. >>>> >>>> >>> There is no official documentation on either XML-RPC or JSON. The format >>> is rather straightforward once you get the hang of things. Each command >>> is >>> effectively an RPC function (e.g ipa user-add -> user_add). The arguments >>> consist of positional arguments followed by named arguments (there is >>> usually only one positional arg). >>> >>> For XML-RPC it is generally fairly easy to work out what it's doing by >>> adding -vv option to the command-line to see the raw request and >>> response. >>> I personally haven't done a lot of raw JSON work. >>> >>> The final option is to skip all that and use the ipalib to do the work >>> for >>> you. >>> >>> For example, to add a user you'd do something like: >>> >>> from ipalib import api >>> from ipalib import errors >>> >>> api.bootstrap(context='cli') >>> api.finalize() >>> api.Backend.xmlclient.connect(****) >>> >>> try: >>> api.Command['user_add'](u'****newuser', >>> >>> loginshell=u'/bin/something', >>> givenname=u'New', sn=u'User') >>> except errors.DuplicateEntry: >>> print "user already exists" >>> else: >>> print "user added" >>> >>> >>> >> ______________________________**_________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/**mailman/listinfo/freeipa-users >> >> > > -- > Petr Vobornik > -- Brian Smith Assistant Director Research Computing, University of South Florida 4202 E. Fowler Ave. SVC4010 Office Phone: +1 813 974-1467 Organization URL: http://rc.usf.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hboetes at gmail.com Tue Jan 15 15:39:53 2013 From: hboetes at gmail.com (Han Boetes) Date: Tue, 15 Jan 2013 16:39:53 +0100 Subject: [Freeipa-users] freeipa radius cisco Message-ID: Hi, Since most of our cisco images do not support encryption the apparent way to go is using radius which is supported by most cisco devices. What is the current status for making this wonderful idea work in the real world. Thanks in advance. # Han -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Tue Jan 15 16:09:23 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 15 Jan 2013 11:09:23 -0500 Subject: [Freeipa-users] freeipa radius cisco In-Reply-To: References: Message-ID: <1358266163.15136.145.camel@willson.li.ssimo.org> On Tue, 2013-01-15 at 16:39 +0100, Han Boetes wrote: > Hi, > > > Since most of our cisco images do not support encryption the apparent > way to go is using radius which is supported by most cisco devices. > > > What is the current status for making this wonderful idea work in the > real world. > We haven;t resumed work to integrate radius as a full feature component of FreeIPA yet, sorry. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Jan 15 20:32:55 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 15 Jan 2013 15:32:55 -0500 Subject: [Freeipa-users] freeipa radius cisco In-Reply-To: <1358266163.15136.145.camel@willson.li.ssimo.org> References: <1358266163.15136.145.camel@willson.li.ssimo.org> Message-ID: <50F5BCF7.3040509@redhat.com> On 01/15/2013 11:09 AM, Simo Sorce wrote: > On Tue, 2013-01-15 at 16:39 +0100, Han Boetes wrote: >> Hi, >> >> >> Since most of our cisco images do not support encryption the apparent >> way to go is using radius which is supported by most cisco devices. >> >> >> What is the current status for making this wonderful idea work in the >> real world. >> > We haven;t resumed work to integrate radius as a full feature component > of FreeIPA yet, sorry. > > Simo. > But this does not mean that you can't use freeradius with LDAP, Kerberos or PAM plugin. You do not need to have integrated radius to get auth from IPA. http://wiki.freeradius.org/modules/Rlm_ldap http://wiki.freeradius.org/modules/Rlm_krb5 http://wiki.freeradius.org/modules/Rlm_pam Just configure freeradius to use one of those authentication methods and you can use it with freeIPA. http://deployingradius.com/documents/protocols/oracles.html We recommend to configure EAP-TTLS if your infrustucture supports it and use PAP as an inner method. If this is not possible you would have to use PAP so you need to use pretty long secrets (i would say 20 bytes at least). Keep in mind that not tunneled PAP is based on MD5 which would be a problem if your environment needs to comply with different compliance acts; tunneling would be a must. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sylvainangers at gmail.com Tue Jan 15 22:57:34 2013 From: sylvainangers at gmail.com (Sylvain Angers) Date: Tue, 15 Jan 2013 17:57:34 -0500 Subject: [Freeipa-users] error: Realm not local to KDC Message-ID: Hello Please help me troubleshot this following issue, thank you in advance! Some rhel6.2 have problem with authenticating against IPA v2.2 while some others on same domain do not have issue but still get the same error "Failed to init credentials: Realm not local to KDC" hostname of client that work = mtl-vdi02d.cnppd.lab hostname of client that does not work = mtl-vdi08d.cnppd.lab all vm on RHEV ipa server (mtl-ipa01d.unix.cnppd.lab) is on unix.cnppd.lab because we have AD ip client are on cnppd.lab Windows machine are also on cnppd.lab connected to "Active directory" so we have a stub that redirect request for unix.cnppd.lab onto our ipa client can resolve ipa and vice versa [root at mtl-vdi08d log]# nslookup mtl-ipa01d.unix.cnppd.lab Server: 165.115.58.16 Address: 165.115.58.16#53 Non-authoritative answer: Name: mtl-ipa01d.unix.cnppd.lab Address: 165.115.118.21 [root at mtl-vdi08d log]# nslookup unix.cnppd.lab Server: 165.115.58.16 Address: 165.115.58.16#53 Non-authoritative answer: Name: unix.cnppd.lab Address: 165.115.118.21 [root at mtl-vdi08d log]# cat /etc/resolv.conf # Generated by NetworkManager domain cnppd.lab search cnppd.lab cn.ca nameserver 165.115.58.16 we all get this message in our logs (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1943]]]] [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1944]]]] [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1945]]]] [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1946]]]] [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1947]]]] [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:12:55 2013) [[sssd[ldap_child[1954]]]] [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:12:55 2013) [[sssd[ldap_child[1955]]]] [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1956]]]] [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1957]]]] [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1958]]]] [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC while I can reinstall ipa-client on mtl-vdi02d and it will still work if I do the same with mtl-vdi08d, it will still not work [root at mtl-vdi08d ~]# ipa-client-install --server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB --mkhomedir Discovery was successful! Hostname: mtl-vdi08d.cnppd.lab Realm: UNIX.CNPPD.LAB DNS Domain: UNIX.CNPPD.LAB IPA Server: mtl-ipa01d.unix.cnppd.lab BaseDN: dc=unix,dc=cnppd,dc=lab Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Password for admin at UNIX.CNPPD.LAB: Enrolled in IPA realm UNIX.CNPPD.LAB Created /etc/ipa/default.conf Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB SSSD enabled Unable to find 'admin' user with 'getent passwd admin'! Recognized configuration: SSSD NTP enabled Client configuration complete. [root at mtl-vdi08d ~]# see the "Unable to find 'admin' user with 'getent passwd admin'!" message [root at mtl-vdi08d log]# getent passwd t154793 [root at mtl-vdi08d log]# [root at mtl-vdi02d t154793]# getent passwd t154793 t154793:*:1947600004:1947600004:Sylvain Angers:/home/t154793:/bin/bash [root at mtl-vdi02d t154793]# What could be the cause? Any assistance would be appreciate Thank you! -- Sylvain Angers -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Jan 15 23:55:15 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 15 Jan 2013 18:55:15 -0500 Subject: [Freeipa-users] error: Realm not local to KDC In-Reply-To: References: Message-ID: <50F5EC63.1000602@redhat.com> On 01/15/2013 05:57 PM, Sylvain Angers wrote: > Hello > > Please help me troubleshot this following issue, thank you in advance! > > Some rhel6.2 have problem with authenticating against IPA v2.2 > while some others on same domain do not have issue but still get the > same error "Failed to init credentials: Realm not local to KDC" > > hostname of client that work = mtl-vdi02d.cnppd.lab > hostname of client that does not work = mtl-vdi08d.cnppd.lab > all vm on RHEV > > ipa server (mtl-ipa01d.unix.cnppd.lab) is on unix.cnppd.lab because > we have AD > ip client are on cnppd.lab > Windows machine are also on cnppd.lab connected to "Active directory" > Issues like this are usually related to DNS. We recommend that you delegate a zone from AD to IPA and install IPA with DNS to manage this zone. With the setup like yours you have a high chance of AD responding to the UNIX client requests. You can avoid this but it would require a bit of manual configuration. The following recommendation is written for trusts but AFAIU it is applicable to this use case too. There are two main options: take advantage of the IPA'sown DNS or not. Configuration with IPA DNS: * The recommended configuration is to take advantage of the IPA DNS and to delegate a zone from the DNS server (most likely AD DNS) to IPA. It should be possible to resolve the names in the AD domain via forwarders. This configuration does not differ from the normal DNS configuration we recommend and can be fully automated. Linux clients in this case become machines in the IPA DNS domain. * The alternative can be that IPA would be in the completely separate namespace.In this case the AD DNS server needs a conditional forwarder to resolve IPA names and the IPA DNS server needs a forwarder to resolve AD names. * An alternative solution, which would scale better in environments with many domains, would be a common forwarder as described in http://freeipa.org/page/IPAv3_testing_AD_trust#Adding_a_common_forwarder) .Cross forwarding is the only solution unless a common higher level DNS server delegates both the AD and IPA zones to the respective servers. * dns-a.example.com has a forwarder for example.net -> dns-b.example.net * dns-b.example.net has a forwader for example.com -> dna-a.example.com Configuration without IPA DNS: * It is possible to use an AD DNS for the deployment and not configure IPA DNS. In this case: * The AD DNS should be updated to have all the names of the IPA servers registered as Arecords(PTR records are not mandatory but are useful). * The IPA clients (SSSD) should be configured not to use service discovery but rather use the list of the IPA server names explicitely. * Client entries would also have to be added to the AD domain * If you prefer to use service discovery a subdomain can be allocated for IPA servers. Service (SRV) records can be created for that domain that would point to the list of the IPA servers. The clients can be then configured to use service discovery but every client would have to be added to the AD DNS directly too. * DNS-based service discovery should be seen as a preferred way for configuration without IPA DNS. There are too many places in both Windows and on Linux where default assumptions are made when resolving services that manual configuration should be discouraged. HTH > so we have a stub that redirect request for unix.cnppd.lab onto our ipa > > client can resolve ipa and vice versa > > [root at mtl-vdi08d log]# nslookup mtl-ipa01d.unix.cnppd.lab > Server: 165.115.58.16 > Address: 165.115.58.16#53 > > Non-authoritative answer: > Name: mtl-ipa01d.unix.cnppd.lab > Address: 165.115.118.21 > > [root at mtl-vdi08d log]# nslookup unix.cnppd.lab > Server: 165.115.58.16 > Address: 165.115.58.16#53 > > Non-authoritative answer: > Name: unix.cnppd.lab > Address: 165.115.118.21 > > [root at mtl-vdi08d log]# cat /etc/resolv.conf > # Generated by NetworkManager > domain cnppd.lab > search cnppd.lab cn.ca > nameserver 165.115.58.16 > > > > we all get this message in our logs > > (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1943]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1944]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1945]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1946]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1947]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:12:55 2013) [[sssd[ldap_child[1954]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:12:55 2013) [[sssd[ldap_child[1955]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1956]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1957]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1958]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > > > while I can reinstall ipa-client on mtl-vdi02d and it will still work > > if I do the same with mtl-vdi08d, it will still not work > > > > > [root at mtl-vdi08d ~]# ipa-client-install > --server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB --mkhomedir > Discovery was successful! > Hostname: mtl-vdi08d.cnppd.lab > Realm: UNIX.CNPPD.LAB > DNS Domain: UNIX.CNPPD.LAB > IPA Server: mtl-ipa01d.unix.cnppd.lab > BaseDN: dc=unix,dc=cnppd,dc=lab > > > Continue to configure the system with these values? [no]: yes > User authorized to enroll computers: admin > Synchronizing time with KDC... > Password for admin at UNIX.CNPPD.LAB: > > Enrolled in IPA realm UNIX.CNPPD.LAB > Created /etc/ipa/default.conf > Configured /etc/sssd/sssd.conf > Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB > SSSD enabled > Unable to find 'admin' user with 'getent passwd admin'! > Recognized configuration: SSSD > NTP enabled > Client configuration complete. > [root at mtl-vdi08d ~]# > > > > > see the "Unable to find 'admin' user with 'getent passwd admin'!" message > > [root at mtl-vdi08d log]# getent passwd t154793 > [root at mtl-vdi08d log]# > > > [root at mtl-vdi02d t154793]# getent passwd t154793 > t154793:*:1947600004:1947600004:Sylvain Angers:/home/t154793:/bin/bash > [root at mtl-vdi02d t154793]# > > > What could be the cause? > Any assistance would be appreciate > > Thank you! > > > -- > Sylvain Angers > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.muriithi at gmail.com Wed Jan 16 01:37:02 2013 From: william.muriithi at gmail.com (William Muriithi) Date: Tue, 15 Jan 2013 20:37:02 -0500 Subject: [Freeipa-users] Process conflict issue when restarting IPA Message-ID: > I see the same issue as William on CentOS6.3 fully up-to-date... > > [root at test-1 ~]# rpm -qa|grep ipa > ipa-client-2.2.0-16.el6.x86_64 > ipa-server-selinux-2.2.0-16.el6.x86_64 > libipa_hbac-1.8.0-32.el6.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > python-iniparse-0.3.1-2.1.el6.noarch > ipa-python-2.2.0-16.el6.x86_64 > ipa-admintools-2.2.0-16.el6.x86_64 > ipa-server-2.2.0-16.el6.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > libipa_hbac-python-1.8.0-32.el6.x86_64 > [root at test-1 ~]# yum update > Loaded plugins: fastestmirror > Loading mirror speeds from cached hostfile > base | 3.7 kB 00:00 > extras | 3.5 kB 00:00 > updates | 3.5 kB 00:00 > Setting up Update Process > No Packages marked for Update > [root at service-1 ~]# ipactl restart > Restarting Directory Service > Shutting down dirsrv: > TEST-LOCAL... [ OK ] > PKI-IPA... [ OK ] > Starting dirsrv: > TEST-LOCAL... [ OK ] > PKI-IPA... [ OK ] > Restarting KDC Service > Stopping Kerberos 5 KDC: [ OK ] > Starting Kerberos 5 KDC: [ OK ] > Restarting KPASSWD Service > Stopping Kerberos 5 Admin Server: [ OK ] > Starting Kerberos 5 Admin Server: [ OK ] > Restarting DNS Service > Stopping named: .... [ OK ] > Starting named: [ OK ] > Restarting MEMCACHE Service > Stopping ipa_memcached: [ OK ] > Starting ipa_memcached: [ OK ] > Restarting HTTP Service > Stopping httpd: [ OK ] > Starting httpd: [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker > [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker > [ OK ] > Restarting CA Service > Stopping pki-ca: [ OK ] > Starting pki-ca: [ OK ] > [root at test-1 ~]# > > Thanks, > Mike > > > That is the same version of IPA I am also using. When I came across it initially, I turned off tomcat as I initially thought it may have come up by mistake but soon noticed errors in the logs. Restarting it a second time and noticed it complained the certificate system was not running. It was then that I guessed it was a script bug and ignored it > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager for IdM portfolio > > Red Hat Inc. > > > > William > > ------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Jan 16 08:11:10 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 16 Jan 2013 09:11:10 +0100 Subject: [Freeipa-users] error: Realm not local to KDC In-Reply-To: <50F5EC63.1000602@redhat.com> References: <50F5EC63.1000602@redhat.com> Message-ID: <50F6609E.6030106@redhat.com> Hello, as Dmitri said, this problem is probably related to DNS. I would recommend to run tcpdump/wireshark on the client, capture all network traffic during client enrolment and check IP addresses. You will probably see IP address of AD server more often than you should ... Petr^2 Spacek On 16.1.2013 00:55, Dmitri Pal wrote: > On 01/15/2013 05:57 PM, Sylvain Angers wrote: >> Hello >> >> Please help me troubleshot this following issue, thank you in advance! >> >> Some rhel6.2 have problem with authenticating against IPA v2.2 >> while some others on same domain do not have issue but still get the same >> error "Failed to init credentials: Realm not local to KDC" >> >> hostname of client that work = mtl-vdi02d.cnppd.lab >> hostname of client that does not work = mtl-vdi08d.cnppd.lab >> all vm on RHEV >> >> ipa server (mtl-ipa01d.unix.cnppd.lab) is on unix.cnppd.lab because we have AD >> ip client are on cnppd.lab >> Windows machine are also on cnppd.lab connected to "Active directory" >> > > Issues like this are usually related to DNS. > We recommend that you delegate a zone from AD to IPA and install IPA with DNS > to manage this zone. > With the setup like yours you have a high chance of AD responding to the UNIX > client requests. > You can avoid this but it would require a bit of manual configuration. > > The following recommendation is written for trusts but AFAIU it is applicable > to this use case too. > > > There are two main options: take advantage of the IPA'sown DNS or not. > > Configuration with IPA DNS: > > * The recommended configuration is to take advantage of the IPA DNS and to > delegate a zone from the DNS server (most likely AD DNS) to IPA. It > should be possible to resolve the names in the AD domain via forwarders. > This configuration does not differ from the normal DNS configuration we > recommend and can be fully automated. Linux clients in this case become > machines in the IPA DNS domain. > > * The alternative can be that IPA would be in the completely separate > namespace.In this case the AD DNS server needs a conditional forwarder to > resolve IPA names and the IPA DNS server needs a forwarder to resolve AD > names. > > > * An alternative solution, which would scale better in environments with > many domains, would be a common forwarder as described in > http://freeipa.org/page/IPAv3_testing_AD_trust#Adding_a_common_forwarder) > .Cross > forwarding is the only solution unless a common higher level DNS server > delegates both the AD and IPA zones to the respective servers. > > * dns-a.example.com has a forwarder for example.net -> dns-b.example.net > > * dns-b.example.net has a forwader for example.com -> dna-a.example.com > > > > Configuration without IPA DNS: > > * It is possible to use an AD DNS for the deployment and not configure IPA > DNS. In this case: > > * The AD DNS should be updated to have all the names of the IPA servers > registered as Arecords(PTR records are not mandatory but are useful). > > * The IPA clients (SSSD) should be configured not to use service > discovery but rather use the list of the IPA server names explicitely. > > * Client entries would also have to be added to the AD domain > > * If you prefer to use service discovery a subdomain can be allocated for > IPA servers. Service (SRV) records can be created for that domain that > would point to the list of the IPA servers. The clients can be then > configured to use service discovery but every client would have to be > added to the AD DNS directly too. > > * DNS-based service discovery should be seen as a preferred way for > configuration without IPA DNS. There are too many places in both Windows > and on Linux where default assumptions are made when resolving services > that manual configuration should be discouraged. > > > HTH > >> so we have a stub that redirect request for unix.cnppd.lab onto our ipa >> >> client can resolve ipa and vice versa >> >> [root at mtl-vdi08d log]# nslookup mtl-ipa01d.unix.cnppd.lab >> Server: 165.115.58.16 >> Address: 165.115.58.16#53 >> >> Non-authoritative answer: >> Name: mtl-ipa01d.unix.cnppd.lab >> Address: 165.115.118.21 >> >> [root at mtl-vdi08d log]# nslookup unix.cnppd.lab >> Server: 165.115.58.16 >> Address: 165.115.58.16#53 >> >> Non-authoritative answer: >> Name: unix.cnppd.lab >> Address: 165.115.118.21 >> >> [root at mtl-vdi08d log]# cat /etc/resolv.conf >> # Generated by NetworkManager >> domain cnppd.lab >> search cnppd.lab cn.ca >> nameserver 165.115.58.16 >> >> >> >> we all get this message in our logs >> >> (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1943]]]] >> [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local >> to KDC >> (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1944]]]] >> [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local >> to KDC >> (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1945]]]] >> [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local >> to KDC >> (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1946]]]] >> [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local >> to KDC >> (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1947]]]] >> [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local >> to KDC >> (Tue Jan 15 17:12:55 2013) [[sssd[ldap_child[1954]]]] >> [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local >> to KDC >> (Tue Jan 15 17:12:55 2013) [[sssd[ldap_child[1955]]]] >> [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local >> to KDC >> (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1956]]]] >> [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local >> to KDC >> (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1957]]]] >> [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local >> to KDC >> (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1958]]]] >> [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local >> to KDC >> >> >> while I can reinstall ipa-client on mtl-vdi02d and it will still work >> >> if I do the same with mtl-vdi08d, it will still not work >> >> >> >> >> [root at mtl-vdi08d ~]# ipa-client-install --server=mtl-ipa01d.unix.cnppd.lab >> --domain=UNIX.CNPPD.LAB --mkhomedir >> Discovery was successful! >> Hostname: mtl-vdi08d.cnppd.lab >> Realm: UNIX.CNPPD.LAB >> DNS Domain: UNIX.CNPPD.LAB >> IPA Server: mtl-ipa01d.unix.cnppd.lab >> BaseDN: dc=unix,dc=cnppd,dc=lab >> >> >> Continue to configure the system with these values? [no]: yes >> User authorized to enroll computers: admin >> Synchronizing time with KDC... >> Password for admin at UNIX.CNPPD.LAB: >> >> Enrolled in IPA realm UNIX.CNPPD.LAB >> Created /etc/ipa/default.conf >> Configured /etc/sssd/sssd.conf >> Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB >> SSSD enabled >> Unable to find 'admin' user with 'getent passwd admin'! >> Recognized configuration: SSSD >> NTP enabled >> Client configuration complete. >> [root at mtl-vdi08d ~]# >> >> >> >> >> see the "Unable to find 'admin' user with 'getent passwd admin'!" message >> >> [root at mtl-vdi08d log]# getent passwd t154793 >> [root at mtl-vdi08d log]# >> >> >> [root at mtl-vdi02d t154793]# getent passwd t154793 >> t154793:*:1947600004:1947600004:Sylvain Angers:/home/t154793:/bin/bash >> [root at mtl-vdi02d t154793]# >> >> >> What could be the cause? >> Any assistance would be appreciate From simo at redhat.com Wed Jan 16 13:55:58 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 16 Jan 2013 08:55:58 -0500 Subject: [Freeipa-users] error: Realm not local to KDC In-Reply-To: References: Message-ID: <1358344558.4590.36.camel@willson.li.ssimo.org> On Tue, 2013-01-15 at 17:57 -0500, Sylvain Angers wrote: > Some rhel6.2 have problem with authenticating against IPA v2.2 > while some others on same domain do not have issue but still get the > same > error "Failed to init credentials: Realm not local to KDC" > Because you are putting machines in the top domain I suspect your client is trying to resolve the realm via SRV records and finds those of the AD server. You may want to statically configure the default _realm and the [domain_realm] section in your client krb5.conf and turn off dns discovery in krb5.conf for those client. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Wed Jan 16 14:11:20 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 16 Jan 2013 09:11:20 -0500 Subject: [Freeipa-users] error: Realm not local to KDC In-Reply-To: <1358344558.4590.36.camel@willson.li.ssimo.org> References: <1358344558.4590.36.camel@willson.li.ssimo.org> Message-ID: <50F6B508.2050209@redhat.com> On 01/16/2013 08:55 AM, Simo Sorce wrote: > On Tue, 2013-01-15 at 17:57 -0500, Sylvain Angers wrote: >> Some rhel6.2 have problem with authenticating against IPA v2.2 >> while some others on same domain do not have issue but still get the >> same >> error "Failed to init credentials: Realm not local to KDC" >> > Because you are putting machines in the top domain I suspect your client > is trying to resolve the realm via SRV records and finds those of the AD > server. You may want to statically configure the default _realm and the > [domain_realm] section in your client krb5.conf and turn off dns > discovery in krb5.conf for those client. > > Simo. > Not only that. The fact that getent failed might mean that LDAP connection was not established or was attempted against the wrong server. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From umarzuki at gmail.com Tue Jan 15 10:04:10 2013 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Tue, 15 Jan 2013 18:04:10 +0800 Subject: [Freeipa-users] SSO page FreeIPAv3 Message-ID: problem: -using Zimbra Collaboration Suite 8 -3000 users -only have license for 2500 users (ZCS Network Edition, users on freeipa) -500 users on OSS Edition, openldap want to achieve: -single sign-on / login page to log in users on both NE & OSS servers e.g: user A on NE logs in via webmail.domain.com, user B on OSS also can log in from webmail.domain.com is there any way that I could achieve this with freeipa 3.0? -- Regards, Umarzuki Mochlis http://debmal.my From hboetes at gmail.com Wed Jan 16 16:44:56 2013 From: hboetes at gmail.com (Han Boetes) Date: Wed, 16 Jan 2013 17:44:56 +0100 Subject: [Freeipa-users] freeipa radius cisco In-Reply-To: <50F5BCF7.3040509@redhat.com> References: <1358266163.15136.145.camel@willson.li.ssimo.org> <50F5BCF7.3040509@redhat.com> Message-ID: This might be somewhat off-topic but I'll ask anyway. First my questions: How do I get the cisco device -- a 3750 with the latest software image -- to use EAP-TTLS and what am I missing for the rest. I've set up radius to use kerberos: kerberos seems to like it when I log on with ssh on the cisco: Jan 16 17:33:34 auth-ipa.domain.at krb5kdc[9251](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.2.74: NEEDED_PREAUTH: hb at domain.AT for krbtgt/domain.AT at domain.AT, Additional pre-authentication required Jan 16 17:33:34 auth-ipa.domain.at krb5kdc[9251](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.2.74: ISSUE: authtime 1358354014, etypes {rep=18 tkt=18 ses=18}, hb at domain.AT for krbtgt/domain.AT at domain.AT Allas radius does not. rad_recv: Access-Request packet from host 192.168.2.99 port 1645, id=14, length=91 User-Name = "hb at REALM.AT" User-Password = "hidden" NAS-Port = 1 NAS-Port-Id = "tty1" NAS-Port-Type = Virtual Calling-Station-Id = "192.168.2.73" NAS-IP-Address = 192.168.2.99 # Executing section authorize from file /etc/raddb//sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] Looking up realm "REALM.AT" for User-Name = "hb at REALM.AT" [suffix] Found realm "REALM.AT" [suffix] Adding Stripped-User-Name = "hb" [suffix] Adding Realm = "REALM.AT" [suffix] Proxying request from user hb to realm REALM.AT [suffix] Preparing to proxy authentication request to realm "REALM.AT" ++[suffix] returns updated [eap] No EAP-Message, not doing EAP ++[eap] returns noop [files] users: Matched entry DEFAULT at line 206 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop WARNING: Empty pre-proxy section. Using default return values. Sending Access-Request of id 149 to 127.0.0.1 port 1812 User-Name = "hb" User-Password = "hidden" NAS-Port = 1 NAS-Port-Id = "tty1" NAS-Port-Type = Virtual Calling-Station-Id = "192.168.2.73" NAS-IP-Address = 192.168.2.99 Message-Authenticator := 0x00000000000000000000000000000000 Proxy-State = 0x3134 Proxying request 9 to home server 127.0.0.1 port 1812 Sending Access-Request of id 149 to 127.0.0.1 port 1812 User-Name = "hb" User-Password = "hidden" NAS-Port = 1 NAS-Port-Id = "tty1" NAS-Port-Type = Virtual Calling-Station-Id = "192.168.2.73" NAS-IP-Address = 192.168.2.99 Message-Authenticator := 0x00000000000000000000000000000000 Proxy-State = 0x3134 Going to the next request Waking up in 0.9 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 1814, id=149, length=102 User-Name = "hb" User-Password = "hidden" NAS-Port = 1 NAS-Port-Id = "tty1" NAS-Port-Type = Virtual Calling-Station-Id = "192.168.2.73" NAS-IP-Address = 192.168.2.99 Message-Authenticator = 0xf42c5bcf8d1c09945833967ce22f9690 Proxy-State = 0x3134 # Executing section authorize from file /etc/raddb//sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "hb", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop [files] users: Matched entry DEFAULT at line 206 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = Kerberos # Executing group from file /etc/raddb//sites-enabled/default +- entering group Kerberos {...} rlm_krb5: [hb] krb5_sname_to_principal failed: Hostname cannot be canonicalized ++[krb5] returns reject Failed to authenticate the user. Using Post-Auth-Type Reject # Executing group from file /etc/raddb//sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> hb attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 10 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 10 Sending Access-Reject of id 149 to 127.0.0.1 port 1814 Proxy-State = 0x3134 Waking up in 4.9 seconds. rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=149, length=24 Proxy-State = 0x3134 # Executing section post-proxy from file /etc/raddb//sites-enabled/default +- entering group post-proxy {...} [eap] No pre-existing handler found ++[eap] returns noop Using Post-Auth-Type Reject # Executing group from file /etc/raddb//sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> hb at REALM.AT attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Sending Access-Reject of id 14 to 192.168.2.99 port 1645 Finished request 9. Going to the next request Waking up in 4.9 seconds. Cleaning up request 10 ID 149 with timestamp +2998 Cleaning up request 9 ID 14 with timestamp +2998 Ready to process requests. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Jan 16 16:56:44 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 16 Jan 2013 11:56:44 -0500 Subject: [Freeipa-users] freeipa radius cisco In-Reply-To: References: <1358266163.15136.145.camel@willson.li.ssimo.org> <50F5BCF7.3040509@redhat.com> Message-ID: <1358355404.4590.46.camel@willson.li.ssimo.org> On Wed, 2013-01-16 at 17:44 +0100, Han Boetes wrote: > +- entering group Kerberos {...} > rlm_krb5: [hb] krb5_sname_to_principal failed: Hostname cannot be > canonicalized Something's wrong in your configuration Probably the host name is not a fqdn or similar Simo. -- Simo Sorce * Red Hat, Inc * New York From jdennis at redhat.com Wed Jan 16 17:13:57 2013 From: jdennis at redhat.com (John Dennis) Date: Wed, 16 Jan 2013 12:13:57 -0500 Subject: [Freeipa-users] freeipa radius cisco In-Reply-To: References: <1358266163.15136.145.camel@willson.li.ssimo.org> <50F5BCF7.3040509@redhat.com> Message-ID: <50F6DFD5.80901@redhat.com> On 01/16/2013 11:44 AM, Han Boetes wrote: > This might be somewhat off-topic but I'll ask anyway. > > First my questions: > > How do I get the cisco device -- a 3750 with the latest software image > -- to use EAP-TTLS and what am I missing for the rest. Sorry, I can't help you with cisco configuration, maybe others can. But I can help with FreeRADIUS. > # Executing group from file /etc/raddb//sites-enabled/default > +- entering group Kerberos {...} > rlm_krb5: [hb] krb5_sname_to_principal failed: Hostname cannot be It's failing because it's finding a bogus value for the service principal. This is configured in /etc/raddb/modules/krb5, by default it's krb5 { keytab = /path/to/keytab service_principal = name_of_principle } How did you configure these? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Jan 16 18:59:01 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 16 Jan 2013 13:59:01 -0500 Subject: [Freeipa-users] freeipa radius cisco In-Reply-To: References: <1358266163.15136.145.camel@willson.li.ssimo.org> <50F5BCF7.3040509@redhat.com> Message-ID: <50F6F875.80309@redhat.com> On 01/16/2013 11:44 AM, Han Boetes wrote: > This might be somewhat off-topic but I'll ask anyway. > > First my questions: > > How do I get the cisco device -- a 3750 with the latest software image > -- to use EAP-TTLS and what am I missing for the rest. My memory about all this is a bit rusty. I was hoping that latest cisco switches support EAP-TTLS but it does not seem to be the case. It seems that it supports EAP-TLS that might be as good. You effectively need to fins a tunneling protocol that both ends i.e switch and radius server support. You would have to match docs on the two. The protocols you are looking for are EAP-TTLS, PEAP. As far as I remember EAP-TLS and LEAP might work to but I do not remember the details so you need to do a bit of reading on those. > > I've set up radius to use kerberos: kerberos seems to like it when I > log on with ssh on the cisco: > > Jan 16 17:33:34 auth-ipa.domain.at > krb5kdc[9251](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.2.74 > : NEEDED_PREAUTH: hb at domain.AT for > krbtgt/domain.AT at domain.AT, Additional pre-authentication required > Jan 16 17:33:34 auth-ipa.domain.at > krb5kdc[9251](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.2.74 > : ISSUE: authtime 1358354014, etypes {rep=18 > tkt=18 ses=18}, hb at domain.AT for krbtgt/domain.AT at domain.AT > > Allas radius does not. > > rad_recv: Access-Request packet from host 192.168.2.99 port 1645, > id=14, length=91 > User-Name = "hb at REALM.AT " > User-Password = "hidden" > NAS-Port = 1 > NAS-Port-Id = "tty1" > NAS-Port-Type = Virtual > Calling-Station-Id = "192.168.2.73" > NAS-IP-Address = 192.168.2.99 > # Executing section authorize from file /etc/raddb//sites-enabled/default > +- entering group authorize {...} > ++[preprocess] returns ok > ++[chap] returns noop > ++[mschap] returns noop > ++[digest] returns noop > [suffix] Looking up realm "REALM.AT " for User-Name = > "hb at REALM.AT " > [suffix] Found realm "REALM.AT " > [suffix] Adding Stripped-User-Name = "hb" > [suffix] Adding Realm = "REALM.AT " > [suffix] Proxying request from user hb to realm REALM.AT > [suffix] Preparing to proxy authentication request to realm "REALM.AT > " > ++[suffix] returns updated > [eap] No EAP-Message, not doing EAP > ++[eap] returns noop > [files] users: Matched entry DEFAULT at line 206 > ++[files] returns ok > ++[expiration] returns noop > ++[logintime] returns noop > ++[pap] returns noop > WARNING: Empty pre-proxy section. Using default return values. > Sending Access-Request of id 149 to 127.0.0.1 port 1812 > User-Name = "hb" > User-Password = "hidden" > NAS-Port = 1 > NAS-Port-Id = "tty1" > NAS-Port-Type = Virtual > Calling-Station-Id = "192.168.2.73" > NAS-IP-Address = 192.168.2.99 > Message-Authenticator := 0x00000000000000000000000000000000 > Proxy-State = 0x3134 > Proxying request 9 to home server 127.0.0.1 port 1812 > Sending Access-Request of id 149 to 127.0.0.1 port 1812 > User-Name = "hb" > User-Password = "hidden" > NAS-Port = 1 > NAS-Port-Id = "tty1" > NAS-Port-Type = Virtual > Calling-Station-Id = "192.168.2.73" > NAS-IP-Address = 192.168.2.99 > Message-Authenticator := 0x00000000000000000000000000000000 > Proxy-State = 0x3134 > Going to the next request > Waking up in 0.9 seconds. > rad_recv: Access-Request packet from host 127.0.0.1 port 1814, id=149, > length=102 > User-Name = "hb" > User-Password = "hidden" > NAS-Port = 1 > NAS-Port-Id = "tty1" > NAS-Port-Type = Virtual > Calling-Station-Id = "192.168.2.73" > NAS-IP-Address = 192.168.2.99 > Message-Authenticator = 0xf42c5bcf8d1c09945833967ce22f9690 > Proxy-State = 0x3134 > # Executing section authorize from file /etc/raddb//sites-enabled/default > +- entering group authorize {...} > ++[preprocess] returns ok > ++[chap] returns noop > ++[mschap] returns noop > ++[digest] returns noop > [suffix] No '@' in User-Name = "hb", looking up realm NULL > [suffix] No such realm "NULL" > ++[suffix] returns noop > [eap] No EAP-Message, not doing EAP > ++[eap] returns noop > [files] users: Matched entry DEFAULT at line 206 > ++[files] returns ok > ++[expiration] returns noop > ++[logintime] returns noop > [pap] WARNING! No "known good" password found for the user. > Authentication may fail because of this. > ++[pap] returns noop > Found Auth-Type = Kerberos > # Executing group from file /etc/raddb//sites-enabled/default > +- entering group Kerberos {...} > rlm_krb5: [hb] krb5_sname_to_principal failed: Hostname cannot be > canonicalized > ++[krb5] returns reject > Failed to authenticate the user. > Using Post-Auth-Type Reject > # Executing group from file /etc/raddb//sites-enabled/default > +- entering group REJECT {...} > [attr_filter.access_reject] expand: %{User-Name} -> hb > attr_filter: Matched entry DEFAULT at line 11 > ++[attr_filter.access_reject] returns updated > Delaying reject of request 10 for 1 seconds > Going to the next request > Waking up in 0.9 seconds. > Sending delayed reject for request 10 > Sending Access-Reject of id 149 to 127.0.0.1 port 1814 > Proxy-State = 0x3134 > Waking up in 4.9 seconds. > rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=149, > length=24 > Proxy-State = 0x3134 > # Executing section post-proxy from file /etc/raddb//sites-enabled/default > +- entering group post-proxy {...} > [eap] No pre-existing handler found > ++[eap] returns noop > Using Post-Auth-Type Reject > # Executing group from file /etc/raddb//sites-enabled/default > +- entering group REJECT {...} > [attr_filter.access_reject] expand: %{User-Name} -> hb at REALM.AT > > attr_filter: Matched entry DEFAULT at line 11 > ++[attr_filter.access_reject] returns updated > Sending Access-Reject of id 14 to 192.168.2.99 port 1645 > Finished request 9. > Going to the next request > Waking up in 4.9 seconds. > Cleaning up request 10 ID 149 with timestamp +2998 > Cleaning up request 9 ID 14 with timestamp +2998 > Ready to process requests. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Wed Jan 16 23:28:20 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 16 Jan 2013 16:28:20 -0700 Subject: [Freeipa-users] CA cert issues Message-ID: <50F73794.8070902@cora.nwra.com> I've installed ipa 2.2 on EL6. I initially simply did an ipa-server-install. Then I changed the cert used via ipa-server-certinstall to use a wildcard SSL cert issued by Comodo. This has led to a lot of grief and needing to install the Comodo CA chain into lots of SSL dbs. Now I'm looking at replicating the server with: ipa-replica-prepare ipapub.cora.nwra.com --dirsrv_pkcs12=STAR_cora_nwra_com.p12 --dirsrv_pin=xxxxx --http_pkcs12=STAR_cora_nwra_com.p12 --http_pin=xxxxxx But I get: Preparing replica for ipapub.cora.nwra.com from ipa.cora.nwra.com Copying SSL certificate for the Directory Server from STAR_cora_nwra_com.p12 Creating SSL certificate for the dogtag Directory Server ipa: ERROR: cert validation failed for "CN=ipa.cora.nwra.com,O=NWRA.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) preparation of replica failed: cannot connect to 'https://ipa.cora.nwra.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno -8172] (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user. cannot connect to 'https://ipa.cora.nwra.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno -8172] (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user. File "/usr/sbin/ipa-replica-prepare", line 459, in main() File "/usr/sbin/ipa-replica-prepare", line 353, in main export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dogtagcert", replica_fqdn, subject_base) File "/usr/sbin/ipa-replica-prepare", line 143, in export_certdb raise e Any suggestions? I don't really understand how the dogtag ca fits in with this scenario. Should I just get rid of it? Can I? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From orion at cora.nwra.com Wed Jan 16 23:52:24 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 16 Jan 2013 16:52:24 -0700 Subject: [Freeipa-users] CA cert issues In-Reply-To: <50F73794.8070902@cora.nwra.com> References: <50F73794.8070902@cora.nwra.com> Message-ID: <50F73D38.7020001@cora.nwra.com> On 01/16/2013 04:28 PM, Orion Poplawski wrote: > I've installed ipa 2.2 on EL6. I initially simply did an ipa-server-install. > Then I changed the cert used via ipa-server-certinstall to use a wildcard > SSL cert issued by Comodo. This has led to a lot of grief and needing to > install the Comodo CA chain into lots of SSL dbs. > > Now I'm looking at replicating the server with: > > ipa-replica-prepare ipapub.cora.nwra.com > --dirsrv_pkcs12=STAR_cora_nwra_com.p12 --dirsrv_pin=xxxxx > --http_pkcs12=STAR_cora_nwra_com.p12 --http_pin=xxxxxx > > But I get: > > Preparing replica for ipapub.cora.nwra.com from ipa.cora.nwra.com > Copying SSL certificate for the Directory Server from STAR_cora_nwra_com.p12 > Creating SSL certificate for the dogtag Directory Server > ipa: ERROR: cert validation failed for "CN=ipa.cora.nwra.com,O=NWRA.COM" > ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not > trusted by the user.) > preparation of replica failed: cannot connect to > 'https://ipa.cora.nwra.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno > -8172] (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked > as not trusted by the user. > cannot connect to > 'https://ipa.cora.nwra.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno > -8172] (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked > as not trusted by the user. > File "/usr/sbin/ipa-replica-prepare", line 459, in > main() > > File "/usr/sbin/ipa-replica-prepare", line 353, in main > export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dogtagcert", > replica_fqdn, subject_base) > > File "/usr/sbin/ipa-replica-prepare", line 143, in export_certdb > raise e > > Any suggestions? > > I don't really understand how the dogtag ca fits in with this scenario. Should > I just get rid of it? Can I? > I (re?) added the dogtag ca cert to the /etc/httpd/alias db: certutil -d /var/lib/pki-ca/alias/ -L -n 'caSigningCert cert-pki-ca' -a > IPACA.asc certutil -d /etc/httpd/alias -A -n 'IPA CA' -i IPACA.asc -t CTu,Cu,Cu Now I get: Preparing replica for ipapub.cora.nwra.com from ipa.cora.nwra.com Copying SSL certificate for the Directory Server from STAR_cora_nwra_com.p12 Creating SSL certificate for the dogtag Directory Server Certificate issuance failed /var/log/pki-ca/debug shows: [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet Input Parameter requestor_name='IPA Installer' [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet Input Parameter xmlOutput='true' [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet Input Parameter profileId='caIPAserviceCert' [16/Jan/2013:16:46:35][http-9444-2]: End of ProfileSubmitServlet Input Parameters [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: start serving [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: SubId=profile [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: isRenewal false [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: profileId caIPAserviceCert [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: authenticator raCertAuth found [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet:setCredentialsIntoContext() authIds` null [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmistServlet: set Inputs into profile Context [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: set sslClientCertProvider [16/Jan/2013:16:46:35][http-9444-2]: AgentCertAuthentication: start [16/Jan/2013:16:46:35][http-9444-2]: authenticator instance name is raCertAuth [16/Jan/2013:16:46:35][http-9444-2]: AgentCertAuthenticator: got provider [16/Jan/2013:16:46:35][http-9444-2]: AgentCertAuthenticator: retrieving client certificate [16/Jan/2013:16:46:35][http-9444-2]: AgentCertAuthentication: No SSL Client Certs Found [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: authentication error Invalid Credential. What cert needs to be created? Aren't I already specifying the certs for the new server? Thanks. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From william.muriithi at gmail.com Thu Jan 17 00:30:10 2013 From: william.muriithi at gmail.com (William Muriithi) Date: Wed, 16 Jan 2013 19:30:10 -0500 Subject: [Freeipa-users] Managing jboss through sudo Message-ID: Hello I am trying to set up dev systems and want to only allow developers to modify the jboss directory tree, shutdown and restarting jboss. This is mainly so that they dev system don't deviate from the qa and production machines. The directory permissions are fine, but I am having a problem with stopping and restarting jboss. (We are running jboss on port 80, so they would need root permission for it to bind on port 80). My other problem is that the jboss directory path is not the same across servers. The directory path is something like this: /opt/xyz/application/jboss/bin/ Where xyz is the different for every server. So to restart jboss, I would do the following: cd /opt/xyz/application/jboss-4.2.3.GA/bin/ sudo ./shutdown -S sudo nohup ./run.sh -b 0.0.0.0 > /dev/null 2>&1 & These is what I get when I run the command below from a test account with same permission as the developers account. sudo -l User taccount may run the following commands on this host: (root, %developers) ./shutdown.sh -S, nohup ./run.sh -b 0.0.0.0 > /dev/null 2>&1 & However, if I try to run either of the two commands, I get an error that the account is not allowed to run this command [taccount at dev4-yyz-int bin]$ pwd /opt/xyz/application/jboss/bin [taccount at dev4-yyz-int bin]$ sudo ./shutdown.sh -S Sorry, user taccount is not allowed to execute './shutdown.sh -S' as root on dev4-yyz-int.example.com. [taccount at dev4-yyz-int bin]$ hostname dev4-yyz-int.example.com What am I missing? Or how would you go about it? For your information, I can restart it using sudo under another account with full permission sudo -l User williamm may run the following commands on this host: (root) ALL Thanks for assistance Regards. William From dpal at redhat.com Thu Jan 17 01:18:12 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 16 Jan 2013 20:18:12 -0500 Subject: [Freeipa-users] Managing jboss through sudo In-Reply-To: References: Message-ID: <50F75154.10900@redhat.com> On 01/16/2013 07:30 PM, William Muriithi wrote: > Hello > > I am trying to set up dev systems and want to only allow developers to > modify the jboss directory tree, shutdown and restarting jboss. This > is mainly so that they dev system don't deviate from the qa and > production machines. > > The directory permissions are fine, but I am having a problem with > stopping and restarting jboss. (We are running jboss on port 80, so > they would need root permission for it to bind on port 80). My other > problem is that the jboss directory path is not the same across > servers. > > The directory path is something like this: > > /opt/xyz/application/jboss/bin/ Where xyz is the different for every server. > > So to restart jboss, I would do the following: > > cd /opt/xyz/application/jboss-4.2.3.GA/bin/ > sudo ./shutdown -S > sudo nohup ./run.sh -b 0.0.0.0 > /dev/null 2>&1 & > > These is what I get when I run the command below from a test account > with same permission as the developers account. > sudo -l > > User taccount may run the following commands on this host: > (root, %developers) ./shutdown.sh -S, nohup ./run.sh -b 0.0.0.0 > > /dev/null 2>&1 & > > However, if I try to run either of the two commands, I get an error > that the account is not allowed to run this command > > [taccount at dev4-yyz-int bin]$ pwd > /opt/xyz/application/jboss/bin > [taccount at dev4-yyz-int bin]$ sudo ./shutdown.sh -S > Sorry, user taccount is not allowed to execute './shutdown.sh -S' as > root on dev4-yyz-int.example.com. > [taccount at dev4-yyz-int bin]$ hostname > dev4-yyz-int.example.com > > What am I missing? Or how would you go about it? > > For your information, I can restart it using sudo under another > account with full permission > > sudo -l > > User williamm may run the following commands on this host: > (root) ALL > > Thanks for assistance > > Regards. > > William > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users You need to give us a bit more info about your setup. Are you using centrally manged sudo rules from IPA? What version of IPA? What is on your client? What does sudo log show for the failed command? What is the sudo configuration? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Thu Jan 17 01:50:00 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Jan 2013 20:50:00 -0500 Subject: [Freeipa-users] CA cert issues In-Reply-To: <50F73D38.7020001@cora.nwra.com> References: <50F73794.8070902@cora.nwra.com> <50F73D38.7020001@cora.nwra.com> Message-ID: <50F758C8.5040800@redhat.com> Orion Poplawski wrote: > On 01/16/2013 04:28 PM, Orion Poplawski wrote: >> I've installed ipa 2.2 on EL6. I initially simply did an >> ipa-server-install. >> Then I changed the cert used via ipa-server-certinstall to use a >> wildcard >> SSL cert issued by Comodo. This has led to a lot of grief and needing to >> install the Comodo CA chain into lots of SSL dbs. >> >> Now I'm looking at replicating the server with: >> >> ipa-replica-prepare ipapub.cora.nwra.com >> --dirsrv_pkcs12=STAR_cora_nwra_com.p12 --dirsrv_pin=xxxxx >> --http_pkcs12=STAR_cora_nwra_com.p12 --http_pin=xxxxxx >> >> But I get: >> >> Preparing replica for ipapub.cora.nwra.com from ipa.cora.nwra.com >> Copying SSL certificate for the Directory Server from >> STAR_cora_nwra_com.p12 >> Creating SSL certificate for the dogtag Directory Server >> ipa: ERROR: cert validation failed for "CN=ipa.cora.nwra.com,O=NWRA.COM" >> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been >> marked as not >> trusted by the user.) >> preparation of replica failed: cannot connect to >> 'https://ipa.cora.nwra.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno >> -8172] (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been >> marked >> as not trusted by the user. >> cannot connect to >> 'https://ipa.cora.nwra.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno >> -8172] (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been >> marked >> as not trusted by the user. >> File "/usr/sbin/ipa-replica-prepare", line 459, in >> main() >> >> File "/usr/sbin/ipa-replica-prepare", line 353, in main >> export_certdb(api.env.realm, ds_dir, dir, passwd_fname, >> "dogtagcert", >> replica_fqdn, subject_base) >> >> File "/usr/sbin/ipa-replica-prepare", line 143, in export_certdb >> raise e >> >> Any suggestions? >> >> I don't really understand how the dogtag ca fits in with this >> scenario. Should >> I just get rid of it? Can I? >> > > I (re?) added the dogtag ca cert to the /etc/httpd/alias db: > > certutil -d /var/lib/pki-ca/alias/ -L -n 'caSigningCert cert-pki-ca' -a > > IPACA.asc > > certutil -d /etc/httpd/alias -A -n 'IPA CA' -i IPACA.asc -t CTu,Cu,Cu > > Now I get: > > Preparing replica for ipapub.cora.nwra.com from ipa.cora.nwra.com > Copying SSL certificate for the Directory Server from > STAR_cora_nwra_com.p12 > Creating SSL certificate for the dogtag Directory Server > Certificate issuance failed > > /var/log/pki-ca/debug shows: > > [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet Input > Parameter requestor_name='IPA Installer' > [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet Input > Parameter xmlOutput='true' > [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet Input > Parameter profileId='caIPAserviceCert' > [16/Jan/2013:16:46:35][http-9444-2]: End of ProfileSubmitServlet Input > Parameters > [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: start serving > [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: SubId=profile > [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: isRenewal false > [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: profileId > caIPAserviceCert > [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: authenticator > raCertAuth found > [16/Jan/2013:16:46:35][http-9444-2]: > ProfileSubmitServlet:setCredentialsIntoContext() authIds` null > [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmistServlet: set Inputs > into profile Context > [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: set > sslClientCertProvider > [16/Jan/2013:16:46:35][http-9444-2]: AgentCertAuthentication: start > [16/Jan/2013:16:46:35][http-9444-2]: authenticator instance name is > raCertAuth > [16/Jan/2013:16:46:35][http-9444-2]: AgentCertAuthenticator: got provider > [16/Jan/2013:16:46:35][http-9444-2]: AgentCertAuthenticator: retrieving > client certificate > [16/Jan/2013:16:46:35][http-9444-2]: AgentCertAuthentication: No SSL > Client Certs Found > [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: > authentication error Invalid Credential. > > What cert needs to be created? Aren't I already specifying the certs > for the new server? > > Thanks. > We really need to put a big fat warning on this too: there be dragons. It is really meant for v1 servers where we didn't have a full CA. The CA is really integrated into IPA v2+ such that replacing certs is going to cause some amount of grief (as you've seen). I didn't think we blew away the existing NSS database using the tool, though it certainly sounds like we are. What you're missing in the ipaCert in /etc/httpd/alias. This is used to authenticate to dogtag. Can you poke around in /etc/httpd to see if a backup was made, or use certutil to get a list of the nicknames in there? I'm guessing it is trying to issue an SSL cert for the CA 389-ds instance. There are no cli options for providing that. Even if you did manage to get a prepared file you'd likely run into a whole new batch of install problems. Sorry about that. We really need to decide whether this tool is worth supporting at all and fix it (or make it safer) or simply do away with it. Right now it's just a really sharp tool waiting to cut someone. rob From orion at cora.nwra.com Thu Jan 17 03:29:50 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 16 Jan 2013 20:29:50 -0700 Subject: [Freeipa-users] CA cert issues In-Reply-To: <50F758C8.5040800@redhat.com> References: <50F73794.8070902@cora.nwra.com> <50F73D38.7020001@cora.nwra.com> <50F758C8.5040800@redhat.com> Message-ID: <50F7702E.7040707@cora.nwra.com> On 01/16/2013 06:50 PM, Rob Crittenden wrote: > Orion Poplawski wrote: >> On 01/16/2013 04:28 PM, Orion Poplawski wrote: >>> I've installed ipa 2.2 on EL6. I initially simply did an >>> ipa-server-install. >>> Then I changed the cert used via ipa-server-certinstall to use a >>> wildcard >>> SSL cert issued by Comodo. This has led to a lot of grief and >>> needing to >>> install the Comodo CA chain into lots of SSL dbs. >>> >>> Now I'm looking at replicating the server with: >>> >>> ipa-replica-prepare ipapub.cora.nwra.com >>> --dirsrv_pkcs12=STAR_cora_nwra_com.p12 --dirsrv_pin=xxxxx >>> --http_pkcs12=STAR_cora_nwra_com.p12 --http_pin=xxxxxx >>> >>> But I get: >>> >>> Preparing replica for ipapub.cora.nwra.com from ipa.cora.nwra.com >>> Copying SSL certificate for the Directory Server from >>> STAR_cora_nwra_com.p12 >>> Creating SSL certificate for the dogtag Directory Server >>> ipa: ERROR: cert validation failed for "CN=ipa.cora.nwra.com,O=NWRA.COM" >>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been >>> marked as not >>> trusted by the user.) >>> preparation of replica failed: cannot connect to >>> 'https://ipa.cora.nwra.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno >>> -8172] (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been >>> marked >>> as not trusted by the user. >>> cannot connect to >>> 'https://ipa.cora.nwra.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno >>> -8172] (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been >>> marked >>> as not trusted by the user. >>> File "/usr/sbin/ipa-replica-prepare", line 459, in >>> main() >>> >>> File "/usr/sbin/ipa-replica-prepare", line 353, in main >>> export_certdb(api.env.realm, ds_dir, dir, passwd_fname, >>> "dogtagcert", >>> replica_fqdn, subject_base) >>> >>> File "/usr/sbin/ipa-replica-prepare", line 143, in export_certdb >>> raise e >>> >>> Any suggestions? >>> >>> I don't really understand how the dogtag ca fits in with this >>> scenario. Should >>> I just get rid of it? Can I? >>> >> >> I (re?) added the dogtag ca cert to the /etc/httpd/alias db: >> >> certutil -d /var/lib/pki-ca/alias/ -L -n 'caSigningCert cert-pki-ca' -a >> > IPACA.asc >> >> certutil -d /etc/httpd/alias -A -n 'IPA CA' -i IPACA.asc -t CTu,Cu,Cu >> >> Now I get: >> >> Preparing replica for ipapub.cora.nwra.com from ipa.cora.nwra.com >> Copying SSL certificate for the Directory Server from >> STAR_cora_nwra_com.p12 >> Creating SSL certificate for the dogtag Directory Server >> Certificate issuance failed >> >> /var/log/pki-ca/debug shows: >> >> [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet Input >> Parameter requestor_name='IPA Installer' >> [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet Input >> Parameter xmlOutput='true' >> [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet Input >> Parameter profileId='caIPAserviceCert' >> [16/Jan/2013:16:46:35][http-9444-2]: End of ProfileSubmitServlet Input >> Parameters >> [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: start serving >> [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: SubId=profile >> [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: isRenewal >> false >> [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: profileId >> caIPAserviceCert >> [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: authenticator >> raCertAuth found >> [16/Jan/2013:16:46:35][http-9444-2]: >> ProfileSubmitServlet:setCredentialsIntoContext() authIds` null >> [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmistServlet: set Inputs >> into profile Context >> [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: set >> sslClientCertProvider >> [16/Jan/2013:16:46:35][http-9444-2]: AgentCertAuthentication: start >> [16/Jan/2013:16:46:35][http-9444-2]: authenticator instance name is >> raCertAuth >> [16/Jan/2013:16:46:35][http-9444-2]: AgentCertAuthenticator: got provider >> [16/Jan/2013:16:46:35][http-9444-2]: AgentCertAuthenticator: retrieving >> client certificate >> [16/Jan/2013:16:46:35][http-9444-2]: AgentCertAuthentication: No SSL >> Client Certs Found >> [16/Jan/2013:16:46:35][http-9444-2]: ProfileSubmitServlet: >> authentication error Invalid Credential. >> >> What cert needs to be created? Aren't I already specifying the certs >> for the new server? >> >> Thanks. >> > > We really need to put a big fat warning on this too: there be dragons. > > It is really meant for v1 servers where we didn't have a full CA. The CA > is really integrated into IPA v2+ such that replacing certs is going to > cause some amount of grief (as you've seen). > > I didn't think we blew away the existing NSS database using the tool, > though it certainly sounds like we are. > > What you're missing in the ipaCert in /etc/httpd/alias. This is used to > authenticate to dogtag. Can you poke around in /etc/httpd to see if a > backup was made, or use certutil to get a list of the nicknames in there? > > I'm guessing it is trying to issue an SSL cert for the CA 389-ds > instance. There are no cli options for providing that. Even if you did > manage to get a prepared file you'd likely run into a whole new batch of > install problems. > > Sorry about that. We really need to decide whether this tool is worth > supporting at all and fix it (or make it safer) or simply do away with > it. Right now it's just a really sharp tool waiting to cut someone. > > rob Thanks for the confirmation that this is indeed not very well supported :). I went down this route because I find it tedious to have to import CA certs into browsers and particularly into Thunderbird for accessing ldap address book directories. If there are suggestions for other ways to handle this, I would be appreciative. Otherwise I'll keep plugging away at this. Do let me know if this is just not going to be supported though. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From orion at cora.nwra.com Thu Jan 17 16:25:06 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 17 Jan 2013 09:25:06 -0700 Subject: [Freeipa-users] CA cert issues In-Reply-To: <50F758C8.5040800@redhat.com> References: <50F73794.8070902@cora.nwra.com> <50F73D38.7020001@cora.nwra.com> <50F758C8.5040800@redhat.com> Message-ID: <50F825E2.3020708@cora.nwra.com> On 01/16/2013 06:50 PM, Rob Crittenden wrote: > > We really need to put a big fat warning on this too: there be dragons. > > It is really meant for v1 servers where we didn't have a full CA. The CA is > really integrated into IPA v2+ such that replacing certs is going to cause > some amount of grief (as you've seen). > > I didn't think we blew away the existing NSS database using the tool, though > it certainly sounds like we are. > > What you're missing in the ipaCert in /etc/httpd/alias. This is used to > authenticate to dogtag. Can you poke around in /etc/httpd to see if a backup > was made, or use certutil to get a list of the nicknames in there? > > I'm guessing it is trying to issue an SSL cert for the CA 389-ds instance. > There are no cli options for providing that. Even if you did manage to get a > prepared file you'd likely run into a whole new batch of install problems. > > Sorry about that. We really need to decide whether this tool is worth > supporting at all and fix it (or make it safer) or simply do away with it. > Right now it's just a really sharp tool waiting to cut someone. > > rob Well, it looks like it move all of the existing files in /etc/httpd/alias to .orig extensions. I moved those over to an alias.orig directory and imported the ipaCert key. That allowed ipa-replica-prepare to run. Preparing replica for ipapub.cora.nwra.com from ipa.cora.nwra.com Copying SSL certificate for the Directory Server from STAR_cora_nwra_com.p12 Creating SSL certificate for the dogtag Directory Server Copying SSL certificate for the Web Server from STAR_cora_nwra_com.p12 Copying additional files Finalizing configuration Packaging replica information into /var/lib/ipa/replica-info-ipapub.cora.nwra.com.gpg But then on ipa-replica-install, problems as predicted: ipa-replica-install --setup-ca /var/lib/ipa/replica-info-ipapub.cora.nwra.com.gpg ... [16/30]: configuring ssl for ds instance creation of replica failed: Could not find a CA cert in /tmp/tmpPAtailipa/realm_info/dscert.p12 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From rcritten at redhat.com Thu Jan 17 16:27:56 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Jan 2013 11:27:56 -0500 Subject: [Freeipa-users] CA cert issues In-Reply-To: <50F825E2.3020708@cora.nwra.com> References: <50F73794.8070902@cora.nwra.com> <50F73D38.7020001@cora.nwra.com> <50F758C8.5040800@redhat.com> <50F825E2.3020708@cora.nwra.com> Message-ID: <50F8268C.1000001@redhat.com> Orion Poplawski wrote: > On 01/16/2013 06:50 PM, Rob Crittenden wrote: >> >> We really need to put a big fat warning on this too: there be dragons. >> >> It is really meant for v1 servers where we didn't have a full CA. The >> CA is >> really integrated into IPA v2+ such that replacing certs is going to >> cause >> some amount of grief (as you've seen). >> >> I didn't think we blew away the existing NSS database using the tool, >> though >> it certainly sounds like we are. >> >> What you're missing in the ipaCert in /etc/httpd/alias. This is used to >> authenticate to dogtag. Can you poke around in /etc/httpd to see if a >> backup >> was made, or use certutil to get a list of the nicknames in there? >> >> I'm guessing it is trying to issue an SSL cert for the CA 389-ds >> instance. >> There are no cli options for providing that. Even if you did manage to >> get a >> prepared file you'd likely run into a whole new batch of install >> problems. >> >> Sorry about that. We really need to decide whether this tool is worth >> supporting at all and fix it (or make it safer) or simply do away with >> it. >> Right now it's just a really sharp tool waiting to cut someone. >> >> rob > > Well, it looks like it move all of the existing files in > /etc/httpd/alias to .orig extensions. I moved those over to an > alias.orig directory and imported the ipaCert key. That allowed > ipa-replica-prepare to run. > > Preparing replica for ipapub.cora.nwra.com from ipa.cora.nwra.com > Copying SSL certificate for the Directory Server from > STAR_cora_nwra_com.p12 > Creating SSL certificate for the dogtag Directory Server > Copying SSL certificate for the Web Server from STAR_cora_nwra_com.p12 > Copying additional files > Finalizing configuration > Packaging replica information into > /var/lib/ipa/replica-info-ipapub.cora.nwra.com.gpg > > > But then on ipa-replica-install, problems as predicted: > > ipa-replica-install --setup-ca > /var/lib/ipa/replica-info-ipapub.cora.nwra.com.gpg > ... > [16/30]: configuring ssl for ds instance > creation of replica failed: Could not find a CA cert in > /tmp/tmpPAtailipa/realm_info/dscert.p12 > Ok, I think what I would recommend is preparing a replica w/o replacing the certs (e.g. let the CA issue certs for all the services). Install the replica. Then replace with the wildcard certs once the install is up and functioning. rob From orion at cora.nwra.com Thu Jan 17 16:49:19 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 17 Jan 2013 09:49:19 -0700 Subject: [Freeipa-users] CA cert issues In-Reply-To: <50F8268C.1000001@redhat.com> References: <50F73794.8070902@cora.nwra.com> <50F73D38.7020001@cora.nwra.com> <50F758C8.5040800@redhat.com> <50F825E2.3020708@cora.nwra.com> <50F8268C.1000001@redhat.com> Message-ID: <50F82B8F.3030202@cora.nwra.com> On 01/17/2013 09:27 AM, Rob Crittenden wrote: > Orion Poplawski wrote: >> But then on ipa-replica-install, problems as predicted: >> >> ipa-replica-install --setup-ca >> /var/lib/ipa/replica-info-ipapub.cora.nwra.com.gpg >> ... >> [16/30]: configuring ssl for ds instance >> creation of replica failed: Could not find a CA cert in >> /tmp/tmpPAtailipa/realm_info/dscert.p12 >> > > Ok, I think what I would recommend is preparing a replica w/o replacing the > certs (e.g. let the CA issue certs for all the services). > > Install the replica. > > Then replace with the wildcard certs once the install is up and functioning. > > rob That gets to: [21/30]: setting up initial replication Starting replication, please wait until this has completed. [ipa.cora.nwra.com] reports: Update failed! Status: [-11 - System error] creation of replica failed: Failed to start replication Because on ipa.cora : [17/Jan/2013:09:31:42 -0700] NSMMReplicationPlugin - agmt="cn=meToipapub.cora.nwra.com" (ipapub:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user.) because the new cert install wiped out the old slapd-NWRA-COM certs. Installed the NWRA.COM IPA CA there. It seems like a most of the problems would be alleviated if instead of wiping out the old NSS dbs, it simply added the new certs. I don't know if there are any other security implications of this or not. I'm also tempted to start over and do the --dirsrv-cert options on the initial ipa-server-install to see if that helps. Anyway, tried again and now: Configuring Kerberos KDC: Estimated time 30 seconds [1/9]: adding sasl mappings to the directory [2/9]: writing stash file from DS [3/9]: configuring KDC [4/9]: creating a keytab for the directory [5/9]: creating a keytab for the machine [6/9]: adding the password extension to the directory [7/9]: enable GSSAPI for replication creation of replica failed: list index out of range 2013-01-17T16:41:33Z DEBUG [7/9]: enable GSSAPI for replication 2013-01-17T16:41:33Z INFO Setting agreement cn=meToipa.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2013-01-17T16:41:34Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping tree,cn=config 2013-01-17T16:41:35Z INFO Replication Update in progress: FALSE: status: -11 - System error: start: 0: end: 0 2013-01-17T16:41:35Z INFO Setting agreement cn=meToipapub.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2013-01-17T16:41:36Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipapub.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping tree,cn=config 2013-01-17T16:41:37Z INFO Replication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update succeeded: start: 20130117164126Z: end: 20130117164127Z 2013-01-17T16:41:37Z DEBUG list index out of range File "/usr/sbin/ipa-replica-install", line 496, in main() File "/usr/sbin/ipa-replica-install", line 441, in main krb = install_krb(config, setup_pkinit=options.setup_pkinit) File "/usr/sbin/ipa-replica-install", line 163, in install_krb setup_pkinit, pkcs12_info) File "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", line 207, in create_replica self.start_creation("Configuring Kerberos KDC", 30) File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", line 257, in start_creation method() File "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", line 442, in __convert_to_gssapi_replication r_bindpw=self.dm_password) File "/usr/lib/python2.6/site-packages/ipaserver/install/replication.py", line 833, in convert_to_gssapi_replication self.gssapi_update_agreements(self.conn, r_conn) File "/usr/lib/python2.6/site-packages/ipaserver/install/replication.py", line 557, in gssapi_update_agreements self.setup_krb_princs_as_replica_binddns(a, b) File "/usr/lib/python2.6/site-packages/ipaserver/install/replication.py", line 550, in setup_krb_princs_as_replica_binddns mod = [(ldap.MOD_ADD, "nsds5replicabinddn", a_pn[0].dn)] I also see this in /var/log/dirsrv/slapd-NWRA-COM/errors on the master: [17/Jan/2013:09:41:26 -0700] NSMMReplicationPlugin - agmt="cn=meToipapub.cora.nwra.com" (ipapub:389): Schema replication update failed: Type or value exists [17/Jan/2013:09:41:26 -0700] NSMMReplicationPlugin - agmt="cn=meToipapub.cora.nwra.com" (ipapub:389): Warning: unable to replicate schema: rc=1 Which is probably due to some schema modifications I've made, but these don't really seem related to the error above. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From rmeggins at redhat.com Thu Jan 17 16:53:03 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 17 Jan 2013 09:53:03 -0700 Subject: [Freeipa-users] CA cert issues In-Reply-To: <50F82B8F.3030202@cora.nwra.com> References: <50F73794.8070902@cora.nwra.com> <50F73D38.7020001@cora.nwra.com> <50F758C8.5040800@redhat.com> <50F825E2.3020708@cora.nwra.com> <50F8268C.1000001@redhat.com> <50F82B8F.3030202@cora.nwra.com> Message-ID: <50F82C6F.2070909@redhat.com> On 01/17/2013 09:49 AM, Orion Poplawski wrote: > On 01/17/2013 09:27 AM, Rob Crittenden wrote: >> Orion Poplawski wrote: >>> But then on ipa-replica-install, problems as predicted: >>> >>> ipa-replica-install --setup-ca >>> /var/lib/ipa/replica-info-ipapub.cora.nwra.com.gpg >>> ... >>> [16/30]: configuring ssl for ds instance >>> creation of replica failed: Could not find a CA cert in >>> /tmp/tmpPAtailipa/realm_info/dscert.p12 >>> >> >> Ok, I think what I would recommend is preparing a replica w/o >> replacing the >> certs (e.g. let the CA issue certs for all the services). >> >> Install the replica. >> >> Then replace with the wildcard certs once the install is up and >> functioning. >> >> rob > > That gets to: > > [21/30]: setting up initial replication > Starting replication, please wait until this has completed. > [ipa.cora.nwra.com] reports: Update failed! Status: [-11 - System error] > creation of replica failed: Failed to start replication > > Because on ipa.cora : > [17/Jan/2013:09:31:42 -0700] NSMMReplicationPlugin - > agmt="cn=meToipapub.cora.nwra.com" (ipapub:389): Replication bind with > SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error > -8172:Peer's certificate issuer has been marked as not trusted by the > user.) > > because the new cert install wiped out the old slapd-NWRA-COM certs. > Installed the NWRA.COM IPA CA there. > > It seems like a most of the problems would be alleviated if instead of > wiping out the old NSS dbs, it simply added the new certs. I don't > know if there are any other security implications of this or not. > > I'm also tempted to start over and do the --dirsrv-cert options on the > initial ipa-server-install to see if that helps. > > Anyway, tried again and now: > > Configuring Kerberos KDC: Estimated time 30 seconds > [1/9]: adding sasl mappings to the directory > [2/9]: writing stash file from DS > [3/9]: configuring KDC > [4/9]: creating a keytab for the directory > [5/9]: creating a keytab for the machine > [6/9]: adding the password extension to the directory > [7/9]: enable GSSAPI for replication > creation of replica failed: list index out of range > > > 2013-01-17T16:41:33Z DEBUG [7/9]: enable GSSAPI for replication > 2013-01-17T16:41:33Z INFO Setting agreement > cn=meToipa.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping > tree,cn=config schedule to 2358-2359 0 to force synch > 2013-01-17T16:41:34Z INFO Deleting schedule 2358-2359 0 from agreement > cn=meToipa.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping > tree,cn=config > 2013-01-17T16:41:35Z INFO Replication Update in progress: FALSE: > status: -11 - System error: start: 0: end: 0 > 2013-01-17T16:41:35Z INFO Setting agreement > cn=meToipapub.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping > tree,cn=config schedule to 2358-2359 0 to force synch > 2013-01-17T16:41:36Z INFO Deleting schedule 2358-2359 0 from agreement > cn=meToipapub.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping > tree,cn=config > 2013-01-17T16:41:37Z INFO Replication Update in progress: FALSE: > status: 0 Replica acquired successfully: Incremental update succeeded: > start: 20130117164126Z: end: 20130117164127Z > 2013-01-17T16:41:37Z DEBUG list index out of range > File "/usr/sbin/ipa-replica-install", line 496, in > main() > > File "/usr/sbin/ipa-replica-install", line 441, in main > krb = install_krb(config, setup_pkinit=options.setup_pkinit) > > File "/usr/sbin/ipa-replica-install", line 163, in install_krb > setup_pkinit, pkcs12_info) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", > line 207, in create_replica > self.start_creation("Configuring Kerberos KDC", 30) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", line > 257, in start_creation > method() > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", > line 442, in __convert_to_gssapi_replication > r_bindpw=self.dm_password) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/replication.py", > line 833, in convert_to_gssapi_replication > self.gssapi_update_agreements(self.conn, r_conn) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/replication.py", > line 557, in gssapi_update_agreements > self.setup_krb_princs_as_replica_binddns(a, b) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/replication.py", > line 550, in setup_krb_princs_as_replica_binddns > mod = [(ldap.MOD_ADD, "nsds5replicabinddn", a_pn[0].dn)] > > > > I also see this in /var/log/dirsrv/slapd-NWRA-COM/errors on the master: > > [17/Jan/2013:09:41:26 -0700] NSMMReplicationPlugin - > agmt="cn=meToipapub.cora.nwra.com" (ipapub:389): Schema replication > update failed: Type or value exists > [17/Jan/2013:09:41:26 -0700] NSMMReplicationPlugin - > agmt="cn=meToipapub.cora.nwra.com" (ipapub:389): Warning: unable to > replicate schema: rc=1 > > Which is probably due to some schema modifications I've made, but > these don't really seem related to the error above. > And schema replication failures do not prevent the rest of replication from working From orion at cora.nwra.com Thu Jan 17 17:06:27 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 17 Jan 2013 10:06:27 -0700 Subject: [Freeipa-users] CA cert issues In-Reply-To: <50F82B8F.3030202@cora.nwra.com> References: <50F73794.8070902@cora.nwra.com> <50F73D38.7020001@cora.nwra.com> <50F758C8.5040800@redhat.com> <50F825E2.3020708@cora.nwra.com> <50F8268C.1000001@redhat.com> <50F82B8F.3030202@cora.nwra.com> Message-ID: <50F82F93.8030008@cora.nwra.com> On 01/17/2013 09:49 AM, Orion Poplawski wrote: > > Anyway, tried again and now: > > Configuring Kerberos KDC: Estimated time 30 seconds > [1/9]: adding sasl mappings to the directory > [2/9]: writing stash file from DS > [3/9]: configuring KDC > [4/9]: creating a keytab for the directory > [5/9]: creating a keytab for the machine > [6/9]: adding the password extension to the directory > [7/9]: enable GSSAPI for replication > creation of replica failed: list index out of range > Okay, this is more cert stuff, on the replica: [17/Jan/2013:09:41:55 -0700] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) Because the ds instance there doesn't recognize the cert on the master. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From qchang at sri.utoronto.ca Thu Jan 17 17:56:17 2013 From: qchang at sri.utoronto.ca (Qing Chang) Date: Thu, 17 Jan 2013 12:56:17 -0500 Subject: [Freeipa-users] HostEnrol role does not seem to work In-Reply-To: <50F82C6F.2070909@redhat.com> References: <50F73794.8070902@cora.nwra.com> <50F73D38.7020001@cora.nwra.com> <50F758C8.5040800@redhat.com> <50F825E2.3020708@cora.nwra.com> <50F8268C.1000001@redhat.com> <50F82B8F.3030202@cora.nwra.com> <50F82C6F.2070909@redhat.com> Message-ID: <50F83B41.90404@sri.utoronto.ca> I assigned an IPA user account the "HostEnrol" role and run "ipa-client-install", when it got to this "User authorized to enroll computers:", I used that account, then got following: Joining realm failed: No permission to join this host to the IPA domain. Installation failed. Rolling back changes. IPA client is not configured on this system. Am I missing something here? Thanks, Qing From rcritten at redhat.com Thu Jan 17 18:42:26 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Jan 2013 13:42:26 -0500 Subject: [Freeipa-users] HostEnrol role does not seem to work In-Reply-To: <50F83B41.90404@sri.utoronto.ca> References: <50F73794.8070902@cora.nwra.com> <50F73D38.7020001@cora.nwra.com> <50F758C8.5040800@redhat.com> <50F825E2.3020708@cora.nwra.com> <50F8268C.1000001@redhat.com> <50F82B8F.3030202@cora.nwra.com> <50F82C6F.2070909@redhat.com> <50F83B41.90404@sri.utoronto.ca> Message-ID: <50F84612.1070108@redhat.com> Qing Chang wrote: > I assigned an IPA user account the "HostEnrol" role and run > "ipa-client-install", > when it got to this "User authorized to enroll computers:", I used that > account, > then got following: > Joining realm failed: No permission to join this host to the IPA domain. > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > Am I missing something here? What privileges are in the HostEnrol role? Or can you show the output of this, where tuser1 is the user you're trying to enroll with? % ipa user-show tuser1 --all --raw |grep -i member rob From qchang at sri.utoronto.ca Thu Jan 17 19:09:47 2013 From: qchang at sri.utoronto.ca (Qing Chang) Date: Thu, 17 Jan 2013 14:09:47 -0500 Subject: [Freeipa-users] HostEnrol role does not seem to work In-Reply-To: <50F84612.1070108@redhat.com> References: <50F73794.8070902@cora.nwra.com> <50F73D38.7020001@cora.nwra.com> <50F758C8.5040800@redhat.com> <50F825E2.3020708@cora.nwra.com> <50F8268C.1000001@redhat.com> <50F82B8F.3030202@cora.nwra.com> <50F82C6F.2070909@redhat.com> <50F83B41.90404@sri.utoronto.ca> <50F84612.1070108@redhat.com> Message-ID: <50F84C7B.80608@sri.utoronto.ca> On 17/01/2013 1:42 PM, Rob Crittenden wrote: > Qing Chang wrote: >> I assigned an IPA user account the "HostEnrol" role and run >> "ipa-client-install", >> when it got to this "User authorized to enroll computers:", I used that >> account, >> then got following: >> Joining realm failed: No permission to join this host to the IPA domain. >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> Am I missing something here? > > What privileges are in the HostEnrol role? > it's all default, I did not make any changes. > Or can you show the output of this, where tuser1 is the user you're trying to enroll with? > > % ipa user-show tuser1 --all --raw |grep -i member > [root at ipa1 ~]# ipa user-show testipa --all --raw |grep -i member memberof: cn=ipausers,cn=groups,cn=accounts,dc=sri,dc=utoronto,dc=ca memberof: cn=hostenrol,cn=roles,cn=accounts,dc=sri,dc=utoronto,dc=ca memberof: ipauniqueid=d7f28bde-492f-11e2-b297-005056af688c,cn=sudorules,cn=sudo,dc=sri,dc=utoronto,dc=ca memberofindirect: cn=host enrollment,cn=privileges,cn=pbac,dc=sri,dc=utoronto,dc=ca memberofindirect: cn=manage host keytab,cn=permissions,cn=pbac,dc=sri,dc=utoronto,dc=ca memberofindirect: cn=enroll a host,cn=permissions,cn=pbac,dc=sri,dc=utoronto,dc=ca memberofindirect: cn=add krbprincipalname to a host,cn=permissions,cn=pbac,dc=sri,dc=utoronto,dc=ca > rob From rcritten at redhat.com Thu Jan 17 19:40:19 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Jan 2013 14:40:19 -0500 Subject: [Freeipa-users] HostEnrol role does not seem to work In-Reply-To: <50F84C7B.80608@sri.utoronto.ca> References: <50F73794.8070902@cora.nwra.com> <50F73D38.7020001@cora.nwra.com> <50F758C8.5040800@redhat.com> <50F825E2.3020708@cora.nwra.com> <50F8268C.1000001@redhat.com> <50F82B8F.3030202@cora.nwra.com> <50F82C6F.2070909@redhat.com> <50F83B41.90404@sri.utoronto.ca> <50F84612.1070108@redhat.com> <50F84C7B.80608@sri.utoronto.ca> Message-ID: <50F853A3.2080701@redhat.com> Qing Chang wrote: > > On 17/01/2013 1:42 PM, Rob Crittenden wrote: >> Qing Chang wrote: >>> I assigned an IPA user account the "HostEnrol" role and run >>> "ipa-client-install", >>> when it got to this "User authorized to enroll computers:", I used that >>> account, >>> then got following: >>> Joining realm failed: No permission to join this host to the IPA domain. >>> Installation failed. Rolling back changes. >>> IPA client is not configured on this system. >>> >>> Am I missing something here? >> >> What privileges are in the HostEnrol role? >> > it's all default, I did not make any changes. >> Or can you show the output of this, where tuser1 is the user you're >> trying to enroll with? >> >> % ipa user-show tuser1 --all --raw |grep -i member >> > [root at ipa1 ~]# ipa user-show testipa --all --raw |grep -i member > memberof: cn=ipausers,cn=groups,cn=accounts,dc=sri,dc=utoronto,dc=ca > memberof: cn=hostenrol,cn=roles,cn=accounts,dc=sri,dc=utoronto,dc=ca > memberof: > ipauniqueid=d7f28bde-492f-11e2-b297-005056af688c,cn=sudorules,cn=sudo,dc=sri,dc=utoronto,dc=ca > > memberofindirect: cn=host > enrollment,cn=privileges,cn=pbac,dc=sri,dc=utoronto,dc=ca > memberofindirect: cn=manage host > keytab,cn=permissions,cn=pbac,dc=sri,dc=utoronto,dc=ca > memberofindirect: cn=enroll a > host,cn=permissions,cn=pbac,dc=sri,dc=utoronto,dc=ca > memberofindirect: cn=add krbprincipalname to a > host,cn=permissions,cn=pbac,dc=sri,dc=utoronto,dc=ca > Ok, this is enough do do an enrollment (HostEnrol is not a default role). What it lacks is the ability to add a new host entry. You can add this ability by adding the 'Add Hosts' privilege to the 'Host Enrollment' privilege. On the command line like this: $ ipa privilege-add-permission 'Host Enrollment' --permissions='Add Hosts' Note that this is expected. We delegate as few permissions by default as possible. The expectation is that a higher-level administrator pre-creates the hosts that should be allowed to be enrolled and this delegated role can enroll them. rob From rcritten at redhat.com Thu Jan 17 19:54:03 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Jan 2013 14:54:03 -0500 Subject: [Freeipa-users] CA cert issues In-Reply-To: <50F82B8F.3030202@cora.nwra.com> References: <50F73794.8070902@cora.nwra.com> <50F73D38.7020001@cora.nwra.com> <50F758C8.5040800@redhat.com> <50F825E2.3020708@cora.nwra.com> <50F8268C.1000001@redhat.com> <50F82B8F.3030202@cora.nwra.com> Message-ID: <50F856DB.6090306@redhat.com> Orion Poplawski wrote: > On 01/17/2013 09:27 AM, Rob Crittenden wrote: >> Orion Poplawski wrote: >>> But then on ipa-replica-install, problems as predicted: >>> >>> ipa-replica-install --setup-ca >>> /var/lib/ipa/replica-info-ipapub.cora.nwra.com.gpg >>> ... >>> [16/30]: configuring ssl for ds instance >>> creation of replica failed: Could not find a CA cert in >>> /tmp/tmpPAtailipa/realm_info/dscert.p12 >>> >> >> Ok, I think what I would recommend is preparing a replica w/o >> replacing the >> certs (e.g. let the CA issue certs for all the services). >> >> Install the replica. >> >> Then replace with the wildcard certs once the install is up and >> functioning. >> >> rob > > That gets to: > > [21/30]: setting up initial replication > Starting replication, please wait until this has completed. > [ipa.cora.nwra.com] reports: Update failed! Status: [-11 - System error] > creation of replica failed: Failed to start replication > > Because on ipa.cora : > [17/Jan/2013:09:31:42 -0700] NSMMReplicationPlugin - > agmt="cn=meToipapub.cora.nwra.com" (ipapub:389): Replication bind with > SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error > -8172:Peer's certificate issuer has been marked as not trusted by the > user.) > > because the new cert install wiped out the old slapd-NWRA-COM certs. > Installed the NWRA.COM IPA CA there. > > It seems like a most of the problems would be alleviated if instead of > wiping out the old NSS dbs, it simply added the new certs. I don't know > if there are any other security implications of this or not. Yes, that is probably true. I think the reasoning was we didn't know what was in the database already so starting over seemed safer. > > I'm also tempted to start over and do the --dirsrv-cert options on the > initial ipa-server-install to see if that helps. > > Anyway, tried again and now: > > Configuring Kerberos KDC: Estimated time 30 seconds > [1/9]: adding sasl mappings to the directory > [2/9]: writing stash file from DS > [3/9]: configuring KDC > [4/9]: creating a keytab for the directory > [5/9]: creating a keytab for the machine > [6/9]: adding the password extension to the directory > [7/9]: enable GSSAPI for replication > creation of replica failed: list index out of range > > > 2013-01-17T16:41:33Z DEBUG [7/9]: enable GSSAPI for replication > 2013-01-17T16:41:33Z INFO Setting agreement > cn=meToipa.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping > tree,cn=config schedule to 2358-2359 0 to force synch > 2013-01-17T16:41:34Z INFO Deleting schedule 2358-2359 0 from agreement > cn=meToipa.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping > tree,cn=config > 2013-01-17T16:41:35Z INFO Replication Update in progress: FALSE: status: > -11 - System error: start: 0: end: 0 > 2013-01-17T16:41:35Z INFO Setting agreement > cn=meToipapub.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping tree,cn=config > schedule to 2358-2359 0 to force synch > 2013-01-17T16:41:36Z INFO Deleting schedule 2358-2359 0 from agreement > cn=meToipapub.cora.nwra.com,cn=replica,cn=dc\3Dnwra\2Cdc\3Dcom,cn=mapping tree,cn=config > > 2013-01-17T16:41:37Z INFO Replication Update in progress: FALSE: status: > 0 Replica acquired successfully: Incremental update succeeded: start: > 20130117164126Z: end: 20130117164127Z > 2013-01-17T16:41:37Z DEBUG list index out of range > File "/usr/sbin/ipa-replica-install", line 496, in > main() > > File "/usr/sbin/ipa-replica-install", line 441, in main > krb = install_krb(config, setup_pkinit=options.setup_pkinit) > > File "/usr/sbin/ipa-replica-install", line 163, in install_krb > setup_pkinit, pkcs12_info) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", > line 207, in create_replica > self.start_creation("Configuring Kerberos KDC", 30) > > File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", > line 257, in start_creation > method() > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", > line 442, in __convert_to_gssapi_replication > r_bindpw=self.dm_password) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/replication.py", > line 833, in convert_to_gssapi_replication > self.gssapi_update_agreements(self.conn, r_conn) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/replication.py", > line 557, in gssapi_update_agreements > self.setup_krb_princs_as_replica_binddns(a, b) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/replication.py", > line 550, in setup_krb_princs_as_replica_binddns > mod = [(ldap.MOD_ADD, "nsds5replicabinddn", a_pn[0].dn)] This error means that we lack one of the ldap principals on one of the replicas. We've improved the reporting about this error in newer versions and we try a bit harder to make sure things are ok before trying the conversion. It may be because of the replication trust issues, or it could just be bad timing. > > > I also see this in /var/log/dirsrv/slapd-NWRA-COM/errors on the master: > > [17/Jan/2013:09:41:26 -0700] NSMMReplicationPlugin - > agmt="cn=meToipapub.cora.nwra.com" (ipapub:389): Schema replication > update failed: Type or value exists > [17/Jan/2013:09:41:26 -0700] NSMMReplicationPlugin - > agmt="cn=meToipapub.cora.nwra.com" (ipapub:389): Warning: unable to > replicate schema: rc=1 > > Which is probably due to some schema modifications I've made, but these > don't really seem related to the error above. > We try to do all schema modifications online so they end up in 99user.ldif. This ensures that things replicate smoothly. rob From orion at cora.nwra.com Thu Jan 17 20:48:46 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 17 Jan 2013 13:48:46 -0700 Subject: [Freeipa-users] CA cert issues In-Reply-To: <50F856DB.6090306@redhat.com> References: <50F73794.8070902@cora.nwra.com> <50F73D38.7020001@cora.nwra.com> <50F758C8.5040800@redhat.com> <50F825E2.3020708@cora.nwra.com> <50F8268C.1000001@redhat.com> <50F82B8F.3030202@cora.nwra.com> <50F856DB.6090306@redhat.com> Message-ID: <50F863AE.4050706@cora.nwra.com> On 01/17/2013 12:54 PM, Rob Crittenden wrote: > Orion Poplawski wrote: >> >> It seems like a most of the problems would be alleviated if instead of >> wiping out the old NSS dbs, it simply added the new certs. I don't know >> if there are any other security implications of this or not. > > Yes, that is probably true. I think the reasoning was we didn't know what was > in the database already so starting over seemed safer. Filed https://fedorahosted.org/freeipa/ticket/3363 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From qchang at sri.utoronto.ca Thu Jan 17 22:11:58 2013 From: qchang at sri.utoronto.ca (Qing Chang) Date: Thu, 17 Jan 2013 17:11:58 -0500 Subject: [Freeipa-users] HostEnrol role does not seem to work In-Reply-To: <50F853A3.2080701@redhat.com> References: <50F73794.8070902@cora.nwra.com> <50F73D38.7020001@cora.nwra.com> <50F758C8.5040800@redhat.com> <50F825E2.3020708@cora.nwra.com> <50F8268C.1000001@redhat.com> <50F82B8F.3030202@cora.nwra.com> <50F82C6F.2070909@redhat.com> <50F83B41.90404@sri.utoronto.ca> <50F84612.1070108@redhat.com> <50F84C7B.80608@sri.utoronto.ca> <50F853A3.2080701@redhat.com> Message-ID: <50F8772E.7030200@sri.utoronto.ca> On 17/01/2013 2:40 PM, Rob Crittenden wrote: > Qing Chang wrote: >> >> On 17/01/2013 1:42 PM, Rob Crittenden wrote: >>> Qing Chang wrote: >>>> I assigned an IPA user account the "HostEnrol" role and run >>>> "ipa-client-install", >>>> when it got to this "User authorized to enroll computers:", I used that >>>> account, >>>> then got following: >>>> Joining realm failed: No permission to join this host to the IPA domain. >>>> Installation failed. Rolling back changes. >>>> IPA client is not configured on this system. >>>> >>>> Am I missing something here? >>> >>> What privileges are in the HostEnrol role? >>> >> it's all default, I did not make any changes. >>> Or can you show the output of this, where tuser1 is the user you're >>> trying to enroll with? >>> >>> % ipa user-show tuser1 --all --raw |grep -i member >>> >> [root at ipa1 ~]# ipa user-show testipa --all --raw |grep -i member >> memberof: cn=ipausers,cn=groups,cn=accounts,dc=sri,dc=utoronto,dc=ca >> memberof: cn=hostenrol,cn=roles,cn=accounts,dc=sri,dc=utoronto,dc=ca >> memberof: >> ipauniqueid=d7f28bde-492f-11e2-b297-005056af688c,cn=sudorules,cn=sudo,dc=sri,dc=utoronto,dc=ca >> >> memberofindirect: cn=host >> enrollment,cn=privileges,cn=pbac,dc=sri,dc=utoronto,dc=ca >> memberofindirect: cn=manage host >> keytab,cn=permissions,cn=pbac,dc=sri,dc=utoronto,dc=ca >> memberofindirect: cn=enroll a >> host,cn=permissions,cn=pbac,dc=sri,dc=utoronto,dc=ca >> memberofindirect: cn=add krbprincipalname to a >> host,cn=permissions,cn=pbac,dc=sri,dc=utoronto,dc=ca >> > > Ok, this is enough do do an enrollment (HostEnrol is not a default role). What it lacks is the > ability to add a new host entry. > > You can add this ability by adding the 'Add Hosts' privilege to the 'Host Enrollment' privilege. > > On the command line like this: > > $ ipa privilege-add-permission 'Host Enrollment' --permissions='Add Hosts' > > Note that this is expected. We delegate as few permissions by default as possible. The expectation > is that a higher-level administrator pre-creates the hosts that should be allowed to be enrolled > and this delegated role can enroll them. > agreed. Maybe this sort of thing can be put into a FAQ? Appreciated! Qing > rob From topping at codehaus.org Thu Jan 17 22:45:16 2013 From: topping at codehaus.org (Brian Topping) Date: Thu, 17 Jan 2013 17:45:16 -0500 Subject: [Freeipa-users] Best OS to use with FreeIPA? Message-ID: <2D5ED387-2E6D-47CF-8554-62D897978F69@codehaus.org> Apologies if this has been covered elsewhere, I looked through a few months of archives and the documentation and didn't find anything. What's the best OS to build a production FreeIPA instance on? It seems like Fedora has more recent versions in their repositories (CentOS is still at 2.2.0), but I'd prefer to run CentOS as a general rule. Any quick rules of thumb that I can work from? thanks! Brian From dpal at redhat.com Thu Jan 17 23:19:21 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 17 Jan 2013 18:19:21 -0500 Subject: [Freeipa-users] Best OS to use with FreeIPA? In-Reply-To: <2D5ED387-2E6D-47CF-8554-62D897978F69@codehaus.org> References: <2D5ED387-2E6D-47CF-8554-62D897978F69@codehaus.org> Message-ID: <50F886F9.60105@redhat.com> On 01/17/2013 05:45 PM, Brian Topping wrote: > Apologies if this has been covered elsewhere, I looked through a few months of archives and the documentation and didn't find anything. > > What's the best OS to build a production FreeIPA instance on? It seems like Fedora has more recent versions in their repositories (CentOS is still at 2.2.0), but I'd prefer to run CentOS as a general rule. > > Any quick rules of thumb that I can work from? > > thanks! Brian > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users It depends on what level of support you expect and what functionality you are looking for. The first distro that gets the bits is Fedora then RHEL, then CentOS with gap of several months each. It is up to you to choose what is best for you and what risks you are willing to take in your production environment. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From fvzwieten at vxcompany.com Fri Jan 18 11:52:55 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Fri, 18 Jan 2013 12:52:55 +0100 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: <50F1D06A.9080205@redhat.com> References: <50F1D06A.9080205@redhat.com> Message-ID: Hi Dmitri, Sorry for the late reply. I basically want to do the same as Charlie Derwent in another tread on this mailing list: To fully automate the re-installation of a server using Satellite/Spacewalk using kickstart. As the server is an IPA client, it must first get to be un-enrolled, before an ipa-client-install --unattened -w secret etc. can be done in a %post snippet of the kickstart file. It is the automation of the unenrollment proces that we are not able to set up. What I can do on any ipa-client to unenroll on the command line is: ipa --disable-host and ipa host-mod --password=secret --ssh= This unprovisions the client, set's an OTP and removes the host ssh keys. However, this can only be done on an IPA client, and during a kickstart install the server is no longer an IPA client, because it is freshly being set up. It's a typical chicken-and-egg issue. You must first be ipa client to be able to execute ipa commands, but you cannot become an ipa client before unprovisioning yourself using those same ipa commands. Another approuch would be to unprovision the client just before the reboot to be kickstarted, however, I have no idea how to set that up. It would mean the server has to know somehow it is being rebooted because of a re-install, but afaik, there is no way for satellite/spacewalk to tell the server this.. Regards, Fred On Sat, Jan 12, 2013 at 10:06 PM, Dmitri Pal wrote: > On 01/12/2013 03:28 AM, Fred van Zwieten wrote: > > Hi there, > > We are in the process of implementing Satellite and want to automate > server installations 100% using kickstart, cobbler, satellite. > > IPA clients can be scripted enrolled using kickstart. Plenty of > documentation about that. > > However, how to "re"-enroll IPA clients? > > Satellite gives me the option to re-install a server. In this case, > there are still host and possibly service records for this host present in > IPA and DNS. > > One way to think about this is, that it's actually OK to keep those > records there, because it is a "re"-installation, so why remove and > re-enroll? However, there is the krb5.keytab in /etc. I could save that > file during redeployment, but I'm not sure if that will work. And iare > there any other gotcha's. > > So, the question is, how to re-install an IPA client using kickstart > (silent re-install)? > > > The question is how/do you remove the client? > Based on what you say above you use the same system so there are some > leftovers. If you can run ipa-client-install --uninstall it should clean > things like keytab and certs (there have been bugs fixed in freeIPA 3.0). > If the client has access to the server it will clean (not remove) the host > entry too. Then you can re-run the install. If you use OTP you would need > to reset OTP first. > > > Regards, > > Fred > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://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/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hboetes at gmail.com Fri Jan 18 14:31:03 2013 From: hboetes at gmail.com (Han Boetes) Date: Fri, 18 Jan 2013 15:31:03 +0100 Subject: [Freeipa-users] freeipa radius cisco In-Reply-To: <50F5BCF7.3040509@redhat.com> References: <1358266163.15136.145.camel@willson.li.ssimo.org> <50F5BCF7.3040509@redhat.com> Message-ID: I've got it running. Of course you shouldn't expect passwordless logins to work but it's much better than having everyone knowing the passwords. The document that helped me setting up the cisco part was this one: http://wiki.freeradius.org/vendor/Cisco And the magic to add to the configfiles: In client.conf; somerandompass is also used in the cisco config. client 192.168.2.0/16 { secret = somerandompass shortname = someshortname nastype = cisco } And in the file users; the last line throws users directly to the "root" shell: DEFAULT Auth-Type = Kerberos Service-Type = NAS-Prompt-User, cisco-avpair = "shell:priv-lvl=15" Now all I have to figure out is how to set up using eap-tls. The relevant log-message is: [eap] No EAP-Message, not doing EAP ++[eap] returns noop -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Fri Jan 18 15:13:21 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 18 Jan 2013 10:13:21 -0500 Subject: [Freeipa-users] freeipa radius cisco In-Reply-To: References: <1358266163.15136.145.camel@willson.li.ssimo.org> <50F5BCF7.3040509@redhat.com> Message-ID: <50F96691.1090809@redhat.com> On 01/18/2013 09:31 AM, Han Boetes wrote: > In the users file > DEFAULT Auth-Type = Kerberos > Service-Type = NAS-Prompt-User, cisco-avpair = "shell:priv-lvl=15" Be careful! It's almost never a good idea to set the Auth-Type in the user config. Why? Because normally the server figures out the best Auth-Type to use for a given Auth-Request based on the contents of the Auth-Request packet. The contents of the Auth-Request packet depends exclusively on the configuration of the user's device, something you typically do not have control over (think of random user trying to connect with unknown device). The FR server figures out which Auth-Type to use based on it's configuration and set of policy rules, all of which you can write. The problem comes when a user sends an Auth-Request whose contents does not math the Auth-Type you've forced on them, then things will completely *fail*. Using DEFAULT for the Auth-Type is even a more pernicious problem because you're saying apply this to everyone that lands in the default category. There are a few Auth-Type's the server can't figure out on it's own, kerberos is one of them (because fundamentally it's no different than pap in terms of what the client sends). There are a number of approaches one can take to address this issue via policy configuration in the server, but I'm sorry to say I don't have time to document and test all those at the moment. All I'm trying to say is what you've done above will work only in a very constrained scenario, it is not a general solution. The FreeRADIUS list is filled with folks attempts to force an Auth-Type in the users file only to discover their woes. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Fri Jan 18 15:50:29 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 18 Jan 2013 10:50:29 -0500 Subject: [Freeipa-users] freeipa radius cisco In-Reply-To: <50F96691.1090809@redhat.com> References: <1358266163.15136.145.camel@willson.li.ssimo.org> <50F5BCF7.3040509@redhat.com> <50F96691.1090809@redhat.com> Message-ID: <50F96F45.5060809@redhat.com> On 01/18/2013 10:13 AM, John Dennis wrote: > On 01/18/2013 09:31 AM, Han Boetes wrote: >> In the users file >> DEFAULT Auth-Type = Kerberos >> Service-Type = NAS-Prompt-User, cisco-avpair = "shell:priv-lvl=15" > > Be careful! > > It's almost never a good idea to set the Auth-Type in the user config. > Why? Because normally the server figures out the best Auth-Type to use > for a given Auth-Request based on the contents of the Auth-Request > packet. The contents of the Auth-Request packet depends exclusively on > the configuration of the user's device, something you typically do not > have control over (think of random user trying to connect with unknown > device). > > The FR server figures out which Auth-Type to use based on it's > configuration and set of policy rules, all of which you can write. > > The problem comes when a user sends an Auth-Request whose contents does > not math the Auth-Type you've forced on them, then things will > completely *fail*. > > Using DEFAULT for the Auth-Type is even a more pernicious problem > because you're saying apply this to everyone that lands in the default > category. > > There are a few Auth-Type's the server can't figure out on it's own, > kerberos is one of them (because fundamentally it's no different than > pap in terms of what the client sends). There are a number of approaches > one can take to address this issue via policy configuration in the > server, but I'm sorry to say I don't have time to document and test all > those at the moment. > > All I'm trying to say is what you've done above will work only in a very > constrained scenario, it is not a general solution. The FreeRADIUS list > is filled with folks attempts to force an Auth-Type in the users file > only to discover their woes. > Here are a couple of threads I found on the freeradius-users list which might be of help to you: You should use a TLS tunnel with Kerberos auth because the user's password is sent in the request packet, this explains some of the issues with doing krb inside the inner tunnel of the server: http://lists.freeradius.org/pipermail/freeradius-users/2011-February/051625.html This is a how-to someone wrote up on using kerberos with FreeRADIUS, sorry I haven't read it to check for accuracy, but it might be helpful. http://lists.freeradius.org/pipermail/freeradius-users/2012-December/064375.html -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Jan 18 17:09:29 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 18 Jan 2013 12:09:29 -0500 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: References: <50F1D06A.9080205@redhat.com> Message-ID: <50F981C9.50006@redhat.com> On 01/18/2013 06:52 AM, Fred van Zwieten wrote: > Hi Dmitri, > > Sorry for the late reply. I basically want to do the same as Charlie > Derwent in another tread on this mailing list: To fully automate the > re-installation of a server using Satellite/Spacewalk using kickstart. > As the server is an IPA client, it must first get to be un-enrolled, > before an ipa-client-install --unattened -w secret etc. can be done in > a %post snippet of the kickstart file. It is the automation of the > unenrollment proces that we are not able to set up. > > What I can do on any ipa-client to unenroll on the command line is: > > ipa --disable-host and ipa host-mod --password=secret --ssh= > > This unprovisions the client, set's an OTP and removes the host ssh keys. > > However, this can only be done on an IPA client, and during a > kickstart install the server is no longer an IPA client, because it is > freshly being set up. > > It's a typical chicken-and-egg issue. You must first be ipa client to > be able to execute ipa commands, but you cannot become an ipa client > before unprovisioning yourself using those same ipa commands. > > Another approuch would be to unprovision the client just before the > reboot to be kickstarted, however, I have no idea how to set that up. > It would mean the server has to know somehow it is being rebooted > because of a re-install, but afaik, there is no way for > satellite/spacewalk to tell the server this.. > > Regards, > > Fred IMO the right approach would be for the Satellite server to perform "ipa --disable-host and ipa host-mod --password=secret --ssh=" as a part of the re-installation. Satellite should be given an IPA identity and call into IPA when it performs reinstall before rebooting the system. Tough... I will see what I can do. > > > > > On Sat, Jan 12, 2013 at 10:06 PM, Dmitri Pal > wrote: > > On 01/12/2013 03:28 AM, Fred van Zwieten wrote: >> Hi there, >> >> We are in the process of implementing Satellite and want to >> automate server installations 100% using kickstart, cobbler, >> satellite. >> >> IPA clients can be scripted enrolled using kickstart. Plenty of >> documentation about that. >> >> However, how to "re"-enroll IPA clients? >> >> Satellite gives me the option to re-install a server. In this >> case, there are still host and possibly service records for this >> host present in IPA and DNS. >> >> One way to think about this is, that it's actually OK to keep >> those records there, because it is a "re"-installation, so why >> remove and re-enroll? However, there is the krb5.keytab in /etc. >> I could save that file during redeployment, but I'm not sure if >> that will work. And iare there any other gotcha's. >> >> So, the question is, how to re-install an IPA client using >> kickstart (silent re-install)? > > The question is how/do you remove the client? > Based on what you say above you use the same system so there are > some leftovers. If you can run ipa-client-install --uninstall it > should clean things like keytab and certs (there have been bugs > fixed in freeIPA 3.0). If the client has access to the server it > will clean (not remove) the host entry too. Then you can re-run > the install. If you use OTP you would need to reset OTP first. > >> >> Regards, >> >> Fred >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at 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/ > > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From topping at codehaus.org Fri Jan 18 19:25:11 2013 From: topping at codehaus.org (Brian Topping) Date: Fri, 18 Jan 2013 14:25:11 -0500 Subject: [Freeipa-users] Best OS to use with FreeIPA? In-Reply-To: <50F886F9.60105@redhat.com> References: <2D5ED387-2E6D-47CF-8554-62D897978F69@codehaus.org> <50F886F9.60105@redhat.com> Message-ID: <18BD179D-501D-443B-AB39-66B3F51B11D7@codehaus.org> Hi Peter and Dimitri, Thanks for your responses. I think I am going to bite the bullet and put F18 into production. One of the elements that made that easier was recognizing that RHEL 7 was going to be based on Fedora of some sort, and a stripped-down Fedora with SELinux will be plenty secure while I wait for that convergence. Cheers! Brian On Jan 17, 2013, at 6:19 PM, Dmitri Pal wrote: > On 01/17/2013 05:45 PM, Brian Topping wrote: >> Apologies if this has been covered elsewhere, I looked through a few months of archives and the documentation and didn't find anything. >> >> What's the best OS to build a production FreeIPA instance on? It seems like Fedora has more recent versions in their repositories (CentOS is still at 2.2.0), but I'd prefer to run CentOS as a general rule. >> >> Any quick rules of thumb that I can work from? >> >> thanks! Brian >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > It depends on what level of support you expect and what functionality > you are looking for. > The first distro that gets the bits is Fedora then RHEL, then CentOS > with gap of several months each. > It is up to you to choose what is best for you and what risks you are > willing to take in your production environment. > > > -- > 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 at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From fvzwieten at vxcompany.com Fri Jan 18 20:14:01 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Fri, 18 Jan 2013 21:14:01 +0100 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: <50F981C9.50006@redhat.com> References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> Message-ID: Dmitri, Sure I can do this. I can make a script, and have this executed from Satellite (remote command) and than perform the server redeploy from Satellite. However, that makes it a two step process, and that is what I now also have. However, I would like to make it fully automated in a single step. Come to think of it...there is also an api for Satellite. Maybe I can make a script that will first do the IPA stuff and then call Satellite to redeploy the server..... ....hmmm....will look into this...and report my findings Met vriendelijke groeten, * Fred van Zwieten * *Enterprise Open Source Services* * Consultant* *(vrijdags afwezig)* *VX Company IT Services B.V.* *T* (035) 539 09 50 mobiel (06) 41 68 28 48 *F* (035) 539 09 08 *E* fvzwieten at vxcompany.com *I* www.vxcompany.com On Fri, Jan 18, 2013 at 6:09 PM, Dmitri Pal wrote: > On 01/18/2013 06:52 AM, Fred van Zwieten wrote: > > Hi Dmitri, > > Sorry for the late reply. I basically want to do the same as Charlie > Derwent in another tread on this mailing list: To fully automate the > re-installation of a server using Satellite/Spacewalk using kickstart. As > the server is an IPA client, it must first get to be un-enrolled, before an > ipa-client-install --unattened -w secret etc. can be done in a %post > snippet of the kickstart file. It is the automation of the unenrollment > proces that we are not able to set up. > > What I can do on any ipa-client to unenroll on the command line is: > > ipa --disable-host and ipa host-mod --password=secret --ssh= > > This unprovisions the client, set's an OTP and removes the host ssh keys. > > However, this can only be done on an IPA client, and during a kickstart > install the server is no longer an IPA client, because it is freshly being > set up. > > It's a typical chicken-and-egg issue. You must first be ipa client to be > able to execute ipa commands, but you cannot become an ipa client before > unprovisioning yourself using those same ipa commands. > > Another approuch would be to unprovision the client just before the > reboot to be kickstarted, however, I have no idea how to set that up. It > would mean the server has to know somehow it is being rebooted because of a > re-install, but afaik, there is no way for satellite/spacewalk to tell the > server this.. > > Regards, > > Fred > > > IMO the right approach would be for the Satellite server to perform "ipa > --disable-host and ipa host-mod --password=secret --ssh=" as a > part of the re-installation. > Satellite should be given an IPA identity and call into IPA when it > performs reinstall before rebooting the system. > > Tough... I will see what I can do. > > > > > > > On Sat, Jan 12, 2013 at 10:06 PM, Dmitri Pal wrote: > >> On 01/12/2013 03:28 AM, Fred van Zwieten wrote: >> >> Hi there, >> >> We are in the process of implementing Satellite and want to automate >> server installations 100% using kickstart, cobbler, satellite. >> >> IPA clients can be scripted enrolled using kickstart. Plenty of >> documentation about that. >> >> However, how to "re"-enroll IPA clients? >> >> Satellite gives me the option to re-install a server. In this case, >> there are still host and possibly service records for this host present in >> IPA and DNS. >> >> One way to think about this is, that it's actually OK to keep those >> records there, because it is a "re"-installation, so why remove and >> re-enroll? However, there is the krb5.keytab in /etc. I could save that >> file during redeployment, but I'm not sure if that will work. And iare >> there any other gotcha's. >> >> So, the question is, how to re-install an IPA client using kickstart >> (silent re-install)? >> >> >> The question is how/do you remove the client? >> Based on what you say above you use the same system so there are some >> leftovers. If you can run ipa-client-install --uninstall it should clean >> things like keytab and certs (there have been bugs fixed in freeIPA 3.0). >> If the client has access to the server it will clean (not remove) the host >> entry too. Then you can re-run the install. If you use OTP you would need >> to reset OTP first. >> >> >> Regards, >> >> Fred >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://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/ >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From masch82 at gmail.com Sat Jan 19 18:25:14 2013 From: masch82 at gmail.com (MaSch) Date: Sat, 19 Jan 2013 19:25:14 +0100 Subject: [Freeipa-users] Fedora 18 - FreeIPA + AD Message-ID: <50FAE50A.3040008@gmail.com> Hello all, I'm trying to setup FreeIPA on Fedora 18 (Final) with AD integration on a test server. However I do not even get past the initial (local) steps described in : http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Add_trust_with_AD_domain The last step of the section "Install and configure IPA server" gives me the following error : "Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket" However "kdestroy" followed by a consequent "kinit admin" does not help, I get the error again when trying to "ipa-adtrust-install" The ipaserver-install.log says : 2013-01-19T17:19:56Z DEBUG stderr= 2013-01-19T17:19:56Z DEBUG will use ip_address: 172.16.135.141 2013-01-19T17:19:56Z DEBUG Starting external process 2013-01-19T17:19:56Z DEBUG args=kinit admin 2013-01-19T17:19:57Z DEBUG Process finished, return code=0 2013-01-19T17:19:57Z DEBUG stdout=Password for admin at MATRIX.LOCAL: 2013-01-19T17:19:57Z DEBUG stderr= 2013-01-19T17:19:57Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 617, in run_script return_value = main_function() File "/usr/sbin/ipa-adtrust-install", line 304, in main sys.exit("Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket") 2013-01-19T17:19:57Z INFO The ipa-adtrust-install command failed, exception: SystemExit: Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket ______________________________________________________________________________________________________ I tried to follow the instructions and stick to the plan - here is the history of commands I executed on an fresh Fedora 18 Installation (after installing vmware tools in the vm) (long output is omitted and replaced by ...) : [root at linux user]# yum update -y ... [root at linux user]# reboot [root at linux user]# yum install -y "*ipa-server" "*ipa-server-trust-ad" samba4-winbind-clients samba4-winbind samba4-client bind bind-dyndb-ldap ... [root at linux user]# echo "172.16.135.141 ipa-server.matrix.local ipa-server" >> /etc/hosts [root at linux user]# hostname ipa-server.matrix.local [root at linux user]# hostname ipa-server.matrix.local [root at linux user]# ping ipa-server.matrix.local PING ipa-server.matrix.local (172.16.135.141) 56(84) bytes of data. 64 bytes from ipa-server.matrix.local (172.16.135.141): icmp_seq=1 ttl=64 time=0.058 ms [root at linux user]# ipa-server-install -a mypassword1 -p mypassword2 --domain=matrix.local --realm=MATRIX.LOCAL --setup-dns --no-forwarders -U ... setup completes without errors [root at linux user]# kinit admin Password for admin at MATRIX.LOCAL: [root at linux user]# klist Ticket cache: DIR::/run/user/1000/krb5cc_c9794d10f5cd59bd63c423ac50fad257/tktT3hTsU Default principal: admin at MATRIX.LOCAL Valid starting Expires Service principal 01/19/13 12:19:06 01/20/13 12:19:02 krbtgt/MATRIX.LOCAL at MATRIX.LOCAL [root at linux user]# id admin uid=1396400000(admin) gid=1396400000(admins) groups=1396400000(admins) [root at linux user]# getent passwd admin admin:*:1396400000:1396400000:Administrator:/home/admin:/bin/bash [root at linux user]# ipa-adtrust-install --netbios-name=MATRIX -a mypassword1 The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== This program will setup components needed to establish trust to AD domains for the FreeIPA Server. This includes: * Configure Samba * Add trust related objects to FreeIPA LDAP server To accept the default shown in brackets, press the Enter key. The following operations may take some minutes to complete. Please wait until the prompt is returned. Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket ______________________________________________________________________________________________________ The freeipa packages installed are : freeipa-server-trust-ad-3.1.0-2.fc18.x86_64 freeipa-python-3.1.0-2.fc18.x86_64 freeipa-server-selinux-3.1.0-2.fc18.x86_64 freeipa-admintools-3.1.0-2.fc18.x86_64 freeipa-server-3.1.0-2.fc18.x86_64 freeipa-client-3.1.0-2.fc18.x86_64 Any help would be appreciated, perhaps I'm just missing a simple step. Regards Marco From dpal at redhat.com Sat Jan 19 19:16:43 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 19 Jan 2013 14:16:43 -0500 Subject: [Freeipa-users] Fedora 18 - FreeIPA + AD In-Reply-To: <50FAE50A.3040008@gmail.com> References: <50FAE50A.3040008@gmail.com> Message-ID: <50FAF11B.1050006@redhat.com> On 01/19/2013 01:25 PM, MaSch wrote: > Hello all, > > I'm trying to setup FreeIPA on Fedora 18 (Final) with AD integration on a test server. However I do not even get past > the initial (local) steps described in : http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Add_trust_with_AD_domain > The last step of the section "Install and configure IPA server" gives me the following error : > > "Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket" > > However "kdestroy" followed by a consequent "kinit admin" does not help, I get the error again when trying > to "ipa-adtrust-install" > > The ipaserver-install.log says : > 2013-01-19T17:19:56Z DEBUG stderr= > 2013-01-19T17:19:56Z DEBUG will use ip_address: 172.16.135.141 > > 2013-01-19T17:19:56Z DEBUG Starting external process > 2013-01-19T17:19:56Z DEBUG args=kinit admin > 2013-01-19T17:19:57Z DEBUG Process finished, return code=0 > 2013-01-19T17:19:57Z DEBUG stdout=Password for admin at MATRIX.LOCAL: > > 2013-01-19T17:19:57Z DEBUG stderr= > 2013-01-19T17:19:57Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 617, in > run_script > return_value = main_function() > > File "/usr/sbin/ipa-adtrust-install", line 304, in main > sys.exit("Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket") > > 2013-01-19T17:19:57Z INFO The ipa-adtrust-install command failed, exception: SystemExit: Outdated Kerberos credentials. > Use kdestroy and kinit to update your ticket > > ______________________________________________________________________________________________________ > > > I tried to follow the instructions and stick to the plan - here is the history of commands I executed on an fresh Fedora > 18 Installation (after installing vmware tools in the vm) (long output is omitted and replaced by ...) : > > > [root at linux user]# yum update -y > ... > [root at linux user]# reboot > [root at linux user]# yum install -y "*ipa-server" "*ipa-server-trust-ad" samba4-winbind-clients samba4-winbind > samba4-client bind bind-dyndb-ldap > ... > [root at linux user]# echo "172.16.135.141 ipa-server.matrix.local ipa-server" >> /etc/hosts > [root at linux user]# hostname ipa-server.matrix.local > [root at linux user]# hostname > ipa-server.matrix.local > [root at linux user]# ping ipa-server.matrix.local > PING ipa-server.matrix.local (172.16.135.141) 56(84) bytes of data. > 64 bytes from ipa-server.matrix.local (172.16.135.141): icmp_seq=1 ttl=64 time=0.058 ms > [root at linux user]# ipa-server-install -a mypassword1 -p mypassword2 --domain=matrix.local --realm=MATRIX.LOCAL > --setup-dns --no-forwarders -U > ... setup completes without errors > [root at linux user]# kinit admin > Password for admin at MATRIX.LOCAL: > [root at linux user]# klist > Ticket cache: DIR::/run/user/1000/krb5cc_c9794d10f5cd59bd63c423ac50fad257/tktT3hTsU > Default principal: admin at MATRIX.LOCAL > > Valid starting Expires Service principal > 01/19/13 12:19:06 01/20/13 12:19:02 krbtgt/MATRIX.LOCAL at MATRIX.LOCAL > [root at linux user]# id admin > uid=1396400000(admin) gid=1396400000(admins) groups=1396400000(admins) > [root at linux user]# getent passwd admin > admin:*:1396400000:1396400000:Administrator:/home/admin:/bin/bash > [root at linux user]# ipa-adtrust-install --netbios-name=MATRIX -a mypassword1 > The log file for this installation can be found in /var/log/ipaserver-install.log > ============================================================================== > This program will setup components needed to establish trust to AD domains for > the FreeIPA Server. > > This includes: > * Configure Samba > * Add trust related objects to FreeIPA LDAP server > > To accept the default shown in brackets, press the Enter key. > > > The following operations may take some minutes to complete. > Please wait until the prompt is returned. > > Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket > > ______________________________________________________________________________________________________ > > The freeipa packages installed are : > > freeipa-server-trust-ad-3.1.0-2.fc18.x86_64 > freeipa-python-3.1.0-2.fc18.x86_64 > freeipa-server-selinux-3.1.0-2.fc18.x86_64 > freeipa-admintools-3.1.0-2.fc18.x86_64 > freeipa-server-3.1.0-2.fc18.x86_64 > freeipa-client-3.1.0-2.fc18.x86_64 > > > Any help would be appreciated, perhaps I'm just missing a simple step. > > > Regards > Marco > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users What is the situation with the time on that box? Was the time and time zone set correctly? Is it a VM? Can it be that the time drifted in some way? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dale at themacartneyclan.com Sat Jan 19 21:44:20 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Sat, 19 Jan 2013 21:44:20 +0000 Subject: [Freeipa-users] Fedora 18 - FreeIPA + AD In-Reply-To: <50FAF11B.1050006@redhat.com> References: <50FAE50A.3040008@gmail.com> <50FAF11B.1050006@redhat.com> Message-ID: <50FB13B4.5010703@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/19/2013 07:16 PM, Dmitri Pal wrote: > On 01/19/2013 01:25 PM, MaSch wrote: >> Hello all, >> >> I'm trying to setup FreeIPA on Fedora 18 (Final) with AD integration on a test server. However I do not even get past >> the initial (local) steps described in : http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Add_trust_with_AD_domain >> The last step of the section "Install and configure IPA server" gives me the following error : I am having similar issues, however I only have the problem when attempting a trust with AD 2012. Works perfectly on AD 2008r2. Critical pre-req is definitely make sure DNS resolution is working in advance. Its always a killer. If you use IPA managed DNS, use the following. ipa dnszone-add nt.example.com --name-server=dc01.nt.example.com --admin-email="administrator at nt.example.com" --force --forwarder=10.0.2.11 --forward-policy=only the IP address is the IP of the domain controller dc01.nt.example.com >> >> >> "Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket" >> >> However "kdestroy" followed by a consequent "kinit admin" does not help, I get the error again when trying >> to "ipa-adtrust-install" >> >> The ipaserver-install.log says : >> 2013-01-19T17:19:56Z DEBUG stderr= >> 2013-01-19T17:19:56Z DEBUG will use ip_address: 172.16.135.141 >> >> 2013-01-19T17:19:56Z DEBUG Starting external process >> 2013-01-19T17:19:56Z DEBUG args=kinit admin >> 2013-01-19T17:19:57Z DEBUG Process finished, return code=0 >> 2013-01-19T17:19:57Z DEBUG stdout=Password for admin at MATRIX.LOCAL: >> >> 2013-01-19T17:19:57Z DEBUG stderr= >> 2013-01-19T17:19:57Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 617, in >> run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-adtrust-install", line 304, in main >> sys.exit("Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket") >> >> 2013-01-19T17:19:57Z INFO The ipa-adtrust-install command failed, exception: SystemExit: Outdated Kerberos credentials. >> Use kdestroy and kinit to update your ticket >> >> ______________________________________________________________________________________________________ >> >> >> I tried to follow the instructions and stick to the plan - here is the history of commands I executed on an fresh Fedora >> 18 Installation (after installing vmware tools in the vm) (long output is omitted and replaced by ...) : >> >> >> [root at linux user]# yum update -y >> ... >> [root at linux user]# reboot >> [root at linux user]# yum install -y "*ipa-server" "*ipa-server-trust-ad" samba4-winbind-clients samba4-winbind >> samba4-client bind bind-dyndb-ldap >> ... >> [root at linux user]# echo "172.16.135.141 ipa-server.matrix.local ipa-server" >> /etc/hosts >> [root at linux user]# hostname ipa-server.matrix.local >> [root at linux user]# hostname >> ipa-server.matrix.local >> [root at linux user]# ping ipa-server.matrix.local >> PING ipa-server.matrix.local (172.16.135.141) 56(84) bytes of data. >> 64 bytes from ipa-server.matrix.local (172.16.135.141): icmp_seq=1 ttl=64 time=0.058 ms >> [root at linux user]# ipa-server-install -a mypassword1 -p mypassword2 --domain=matrix.local --realm=MATRIX.LOCAL >> --setup-dns --no-forwarders -U >> ... setup completes without errors >> [root at linux user]# kinit admin >> Password for admin at MATRIX.LOCAL: >> [root at linux user]# klist >> Ticket cache: DIR::/run/user/1000/krb5cc_c9794d10f5cd59bd63c423ac50fad257/tktT3hTsU >> Default principal: admin at MATRIX.LOCAL >> >> Valid starting Expires Service principal >> 01/19/13 12:19:06 01/20/13 12:19:02 krbtgt/MATRIX.LOCAL at MATRIX.LOCAL >> [root at linux user]# id admin >> uid=1396400000(admin) gid=1396400000(admins) groups=1396400000(admins) >> [root at linux user]# getent passwd admin >> admin:*:1396400000:1396400000:Administrator:/home/admin:/bin/bash >> [root at linux user]# ipa-adtrust-install --netbios-name=MATRIX -a mypassword1 >> The log file for this installation can be found in /var/log/ipaserver-install.log >> ============================================================================== >> This program will setup components needed to establish trust to AD domains for >> the FreeIPA Server. >> >> This includes: >> * Configure Samba >> * Add trust related objects to FreeIPA LDAP server >> >> To accept the default shown in brackets, press the Enter key. >> >> >> The following operations may take some minutes to complete. >> Please wait until the prompt is returned. >> >> Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket >> >> ______________________________________________________________________________________________________ >> >> The freeipa packages installed are : >> >> freeipa-server-trust-ad-3.1.0-2.fc18.x86_64 >> freeipa-python-3.1.0-2.fc18.x86_64 >> freeipa-server-selinux-3.1.0-2.fc18.x86_64 >> freeipa-admintools-3.1.0-2.fc18.x86_64 >> freeipa-server-3.1.0-2.fc18.x86_64 >> freeipa-client-3.1.0-2.fc18.x86_64 >> >> >> Any help would be appreciated, perhaps I'm just missing a simple step. >> >> >> Regards >> Marco >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > What is the situation with the time on that box? > Was the time and time zone set correctly? > Is it a VM? > Can it be that the time drifted in some way? > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ+xOhAAoJEAJsWS61tB+qr2wP/2R0TsmXDJinGZcIRpx1Cuil Zspb/omJNaKqbWPsvw6aMsdYBTMe2lrzLpiYUbVd3QK7Pf4NV5NnqYmHbsX42b/C D6soYoBE+bG8ja24tXLgbbOJNbg/0x6vZ/tR29xYy1SC75u3HoTMZvxkRIZPas4h SVfavv9NHrC7pxmR6FFjULyby6/yszymghgwN3N8jQxOau5NGA/310WV+MgYPOZX x+G0mLfbRxNbQ0//JdbsV81c0NjMBnSd484p4QsjZcMTuOMRQwULZCatKQKH/7yN 2SIYaZCxnS21vpUFV9vRgOXuwAG3J9Sd4ZvzDv8B5oZDR7TVqTUitOhC1GiGzaAZ VnGJxKjsanknbmfzeOjfew1Qseh4tOHUnbjaV5l4gbNcNkjI+pSI3O9bS2+nQAha OfkiIQZSKrjMPyKwZJCm63s5gptC55KSJCr8uizxcbBWUOne7EEv0v328CnPVx7I MIdzB1ILWovwOTOMIOg+ayS/U2n4l+BiFUf1LwUwYwVt3Ny5DJgmaoyL8I3Vjins dXTVuMo1NU+lxsSGIGbFBqYXyI6XZs7GxR6mI3KUFlz8p65UfvyrhXfMKucl8RbO 3tBCNTAOPM9qxouUo3PySixFw1Cj2kFAVjwbICfazMamW00V0F0cVPO73O7TQWaX P0BeGErR7zhrrXewCk+f =6BNw -----END PGP SIGNATURE----- From dpal at redhat.com Sat Jan 19 22:25:49 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 19 Jan 2013 17:25:49 -0500 Subject: [Freeipa-users] Fedora 18 - FreeIPA + AD In-Reply-To: <50FB13B4.5010703@themacartneyclan.com> References: <50FAE50A.3040008@gmail.com> <50FAF11B.1050006@redhat.com> <50FB13B4.5010703@themacartneyclan.com> Message-ID: <50FB1D6D.80600@redhat.com> On 01/19/2013 04:44 PM, Dale Macartney wrote: > > > On 01/19/2013 07:16 PM, Dmitri Pal wrote: > > On 01/19/2013 01:25 PM, MaSch wrote: > >> Hello all, > >> > >> I'm trying to setup FreeIPA on Fedora 18 (Final) with AD integration > on a test server. However I do not even get past > >> the initial (local) steps described in : > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Add_trust_with_AD_domain > >> The last step of the section "Install and configure IPA server" gives > me the following error : > I am having similar issues, however I only have the problem when > attempting a trust with AD 2012. Works perfectly on AD 2008r2. > > Critical pre-req is definitely make sure DNS resolution is working in > advance. Its always a killer. > > If you use IPA managed DNS, use the following. > > ipa dnszone-add nt.example.com --name-server=dc01.nt.example.com > --admin-email="administrator at nt.example.com" --force > --forwarder=10.0.2.11 --forward-policy=only > > the IP address is the IP of the domain controller dc01.nt.example.com > > >> > >> > >> "Outdated Kerberos credentials. Use kdestroy and kinit to update your > ticket" > >> > >> However "kdestroy" followed by a consequent "kinit admin" does not > help, I get the error again when trying > >> to "ipa-adtrust-install" > >> > >> The ipaserver-install.log says : > >> 2013-01-19T17:19:56Z DEBUG stderr= > >> 2013-01-19T17:19:56Z DEBUG will use ip_address: 172.16.135.141 > >> > >> 2013-01-19T17:19:56Z DEBUG Starting external process > >> 2013-01-19T17:19:56Z DEBUG args=kinit admin > >> 2013-01-19T17:19:57Z DEBUG Process finished, return code=0 > >> 2013-01-19T17:19:57Z DEBUG stdout=Password for admin at MATRIX.LOCAL: > >> > >> 2013-01-19T17:19:57Z DEBUG stderr= > >> 2013-01-19T17:19:57Z INFO File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 617, in > >> run_script > >> return_value = main_function() > >> > >> File "/usr/sbin/ipa-adtrust-install", line 304, in main > >> sys.exit("Outdated Kerberos credentials. Use kdestroy and kinit to > update your ticket") > >> > >> 2013-01-19T17:19:57Z INFO The ipa-adtrust-install command failed, > exception: SystemExit: Outdated Kerberos credentials. > >> Use kdestroy and kinit to update your ticket > >> > >> > ______________________________________________________________________________________________________ > >> > >> > >> I tried to follow the instructions and stick to the plan - here is > the history of commands I executed on an fresh Fedora > >> 18 Installation (after installing vmware tools in the vm) (long > output is omitted and replaced by ...) : > >> > >> > >> [root at linux user]# yum update -y > >> ... > >> [root at linux user]# reboot > >> [root at linux user]# yum install -y "*ipa-server" > "*ipa-server-trust-ad" samba4-winbind-clients samba4-winbind > >> samba4-client bind bind-dyndb-ldap > >> ... > >> [root at linux user]# echo "172.16.135.141 ipa-server.matrix.local > ipa-server" >> /etc/hosts > >> [root at linux user]# hostname ipa-server.matrix.local > >> [root at linux user]# hostname > >> ipa-server.matrix.local > >> [root at linux user]# ping ipa-server.matrix.local > >> PING ipa-server.matrix.local (172.16.135.141) 56(84) bytes of data. > >> 64 bytes from ipa-server.matrix.local (172.16.135.141): icmp_seq=1 > ttl=64 time=0.058 ms > >> [root at linux user]# ipa-server-install -a mypassword1 -p mypassword2 > --domain=matrix.local --realm=MATRIX.LOCAL > >> --setup-dns --no-forwarders -U > >> ... setup completes without errors > >> [root at linux user]# kinit admin > >> Password for admin at MATRIX.LOCAL: > >> [root at linux user]# klist > >> Ticket cache: > DIR::/run/user/1000/krb5cc_c9794d10f5cd59bd63c423ac50fad257/tktT3hTsU > >> Default principal: admin at MATRIX.LOCAL > >> > >> Valid starting Expires Service principal > >> 01/19/13 12:19:06 01/20/13 12:19:02 krbtgt/MATRIX.LOCAL at MATRIX.LOCAL > >> [root at linux user]# id admin > >> uid=1396400000(admin) gid=1396400000(admins) groups=1396400000(admins) > >> [root at linux user]# getent passwd admin > >> admin:*:1396400000:1396400000:Administrator:/home/admin:/bin/bash > >> [root at linux user]# ipa-adtrust-install --netbios-name=MATRIX -a > mypassword1 > >> The log file for this installation can be found in > /var/log/ipaserver-install.log > >> > ============================================================================== > >> This program will setup components needed to establish trust to AD > domains for > >> the FreeIPA Server. > >> > >> This includes: > >> * Configure Samba > >> * Add trust related objects to FreeIPA LDAP server > >> > >> To accept the default shown in brackets, press the Enter key. > >> > >> > >> The following operations may take some minutes to complete. > >> Please wait until the prompt is returned. > >> > >> Outdated Kerberos credentials. Use kdestroy and kinit to update your > ticket > >> > >> > ______________________________________________________________________________________________________ > >> > >> The freeipa packages installed are : > >> > >> freeipa-server-trust-ad-3.1.0-2.fc18.x86_64 > >> freeipa-python-3.1.0-2.fc18.x86_64 > >> freeipa-server-selinux-3.1.0-2.fc18.x86_64 > >> freeipa-admintools-3.1.0-2.fc18.x86_64 > >> freeipa-server-3.1.0-2.fc18.x86_64 > >> freeipa-client-3.1.0-2.fc18.x86_64 > >> > >> > >> Any help would be appreciated, perhaps I'm just missing a simple step. > >> > >> > >> Regards > >> Marco > >> > >> _______________________________________________ > >> Freeipa-users mailing list > >> Freeipa-users at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > What is the situation with the time on that box? > > Was the time and time zone set correctly? > > Is it a VM? > > Can it be that the time drifted in some way? > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sat Jan 19 22:27:30 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 19 Jan 2013 17:27:30 -0500 Subject: [Freeipa-users] Fedora 18 - FreeIPA + AD In-Reply-To: <50FB13B4.5010703@themacartneyclan.com> References: <50FAE50A.3040008@gmail.com> <50FAF11B.1050006@redhat.com> <50FB13B4.5010703@themacartneyclan.com> Message-ID: <50FB1DD2.7070402@redhat.com> On 01/19/2013 04:44 PM, Dale Macartney wrote: > > > On 01/19/2013 07:16 PM, Dmitri Pal wrote: > > On 01/19/2013 01:25 PM, MaSch wrote: > >> Hello all, > >> > >> I'm trying to setup FreeIPA on Fedora 18 (Final) with AD integration > on a test server. However I do not even get past > >> the initial (local) steps described in : > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Add_trust_with_AD_domain > >> The last step of the section "Install and configure IPA server" gives > me the following error : > I am having similar issues, however I only have the problem when > attempting a trust with AD 2012. Works perfectly on AD 2008r2. Sorry for the previous email. Hit wrong button. We have not fully tried AD 2012 so that might be a bug in our code somewhere. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From masch82 at gmail.com Sun Jan 20 10:01:21 2013 From: masch82 at gmail.com (MaSch) Date: Sun, 20 Jan 2013 11:01:21 +0100 Subject: [Freeipa-users] Fedora 18 - FreeIPA + AD In-Reply-To: <50FAF11B.1050006@redhat.com> References: <50FAE50A.3040008@gmail.com> <50FAF11B.1050006@redhat.com> Message-ID: <50FBC071.5090704@gmail.com> On 1/19/13 8:16 PM, Dmitri Pal wrote: > > What is the situation with the time on that box? > Was the time and time zone set correctly? > Is it a VM? > Can it be that the time drifted in some way? > The time zone is correct for my region (Europe/Berlin) as is the current time. It is a VM - running inside VMware Fusion 4 on OSX. I doubt that time drifted in between somehow in an unsual manner. I just tried again and checked : [root at ipa-server user]# klist Ticket cache: DIR::/run/user/1000/krb5cc_1f3f8ebeec8d053aa0a2f46e50fbb20c/tkt5LELnl Default principal: admin at MATRIX.LOCAL Valid starting Expires Service principal 01/20/13 10:47:56 01/21/13 10:47:56 krbtgt/MATRIX.LOCAL at MATRIX.LOCAL [root at ipa-server user]# date Sun Jan 20 10:51:07 CET 2013 [root at ipa-server user]# ipa-adtrust-install --netbios-name=MATRIX -a mypassword1 ... Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket [root at ipa-server user]# date Sun Jan 20 10:51:12 CET 2013 So the "ipa-adtrust-install" is issued while the krbtgt is valid. However as before kdestroy and subsequent kinit don't help. On 1/19/13 10:44 PM, Dale Macartney wrote: > Critical pre-req is definitely make sure DNS resolution is working in > advance. Its always a killer. > > If you use IPA managed DNS, use the following. Thanks for the pointer Dale, but I don't even get that far to do the actual trust. And as far as I can tell, DNS is setup correct locally. The resolv.conf points to the IPA server itself (this is automatically changed during installation), atm no forwarding is done and dns resolution of the ipa-server and ipa-domain work on the ipa-server itself. Regards Marco > On 01/19/2013 01:25 PM, MaSch wrote: >> Hello all, >> >> I'm trying to setup FreeIPA on Fedora 18 (Final) with AD integration on a test server. However I do not even get past >> the initial (local) steps described in : http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Add_trust_with_AD_domain >> The last step of the section "Install and configure IPA server" gives me the following error : >> >> "Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket" >> >> However "kdestroy" followed by a consequent "kinit admin" does not help, I get the error again when trying >> to "ipa-adtrust-install" >> >> The ipaserver-install.log says : >> 2013-01-19T17:19:56Z DEBUG stderr= >> 2013-01-19T17:19:56Z DEBUG will use ip_address: 172.16.135.141 >> >> 2013-01-19T17:19:56Z DEBUG Starting external process >> 2013-01-19T17:19:56Z DEBUG args=kinit admin >> 2013-01-19T17:19:57Z DEBUG Process finished, return code=0 >> 2013-01-19T17:19:57Z DEBUG stdout=Password for admin at MATRIX.LOCAL: >> >> 2013-01-19T17:19:57Z DEBUG stderr= >> 2013-01-19T17:19:57Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 617, in >> run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-adtrust-install", line 304, in main >> sys.exit("Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket") >> >> 2013-01-19T17:19:57Z INFO The ipa-adtrust-install command failed, exception: SystemExit: Outdated Kerberos credentials. >> Use kdestroy and kinit to update your ticket >> >> ______________________________________________________________________________________________________ >> >> >> I tried to follow the instructions and stick to the plan - here is the history of commands I executed on an fresh Fedora >> 18 Installation (after installing vmware tools in the vm) (long output is omitted and replaced by ...) : >> >> >> [root at linux user]# yum update -y >> ... >> [root at linux user]# reboot >> [root at linux user]# yum install -y "*ipa-server" "*ipa-server-trust-ad" samba4-winbind-clients samba4-winbind >> samba4-client bind bind-dyndb-ldap >> ... >> [root at linux user]# echo "172.16.135.141 ipa-server.matrix.local ipa-server" >> /etc/hosts >> [root at linux user]# hostname ipa-server.matrix.local >> [root at linux user]# hostname >> ipa-server.matrix.local >> [root at linux user]# ping ipa-server.matrix.local >> PING ipa-server.matrix.local (172.16.135.141) 56(84) bytes of data. >> 64 bytes from ipa-server.matrix.local (172.16.135.141): icmp_seq=1 ttl=64 time=0.058 ms >> [root at linux user]# ipa-server-install -a mypassword1 -p mypassword2 --domain=matrix.local --realm=MATRIX.LOCAL >> --setup-dns --no-forwarders -U >> ... setup completes without errors >> [root at linux user]# kinit admin >> Password for admin at MATRIX.LOCAL: >> [root at linux user]# klist >> Ticket cache: DIR::/run/user/1000/krb5cc_c9794d10f5cd59bd63c423ac50fad257/tktT3hTsU >> Default principal: admin at MATRIX.LOCAL >> >> Valid starting Expires Service principal >> 01/19/13 12:19:06 01/20/13 12:19:02 krbtgt/MATRIX.LOCAL at MATRIX.LOCAL >> [root at linux user]# id admin >> uid=1396400000(admin) gid=1396400000(admins) groups=1396400000(admins) >> [root at linux user]# getent passwd admin >> admin:*:1396400000:1396400000:Administrator:/home/admin:/bin/bash >> [root at linux user]# ipa-adtrust-install --netbios-name=MATRIX -a mypassword1 >> The log file for this installation can be found in /var/log/ipaserver-install.log >> ============================================================================== >> This program will setup components needed to establish trust to AD domains for >> the FreeIPA Server. >> >> This includes: >> * Configure Samba >> * Add trust related objects to FreeIPA LDAP server >> >> To accept the default shown in brackets, press the Enter key. >> >> >> The following operations may take some minutes to complete. >> Please wait until the prompt is returned. >> >> Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket >> >> ______________________________________________________________________________________________________ >> >> The freeipa packages installed are : >> >> freeipa-server-trust-ad-3.1.0-2.fc18.x86_64 >> freeipa-python-3.1.0-2.fc18.x86_64 >> freeipa-server-selinux-3.1.0-2.fc18.x86_64 >> freeipa-admintools-3.1.0-2.fc18.x86_64 >> freeipa-server-3.1.0-2.fc18.x86_64 >> freeipa-client-3.1.0-2.fc18.x86_64 >> >> >> Any help would be appreciated, perhaps I'm just missing a simple step. >> >> >> Regards >> Marco >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Sun Jan 20 19:24:36 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 20 Jan 2013 14:24:36 -0500 Subject: [Freeipa-users] Fedora 18 - FreeIPA + AD In-Reply-To: <50FBC071.5090704@gmail.com> References: <50FAE50A.3040008@gmail.com> <50FAF11B.1050006@redhat.com> <50FBC071.5090704@gmail.com> Message-ID: <50FC4474.7020602@redhat.com> On 01/20/2013 05:01 AM, MaSch wrote: > On 1/19/13 8:16 PM, Dmitri Pal wrote: >> What is the situation with the time on that box? >> Was the time and time zone set correctly? >> Is it a VM? >> Can it be that the time drifted in some way? >> > The time zone is correct for my region (Europe/Berlin) as is the current time. > It is a VM - running inside VMware Fusion 4 on OSX. > I doubt that time drifted in between somehow in an unsual manner. I just tried again and checked : > > [root at ipa-server user]# klist > Ticket cache: DIR::/run/user/1000/krb5cc_1f3f8ebeec8d053aa0a2f46e50fbb20c/tkt5LELnl > Default principal: admin at MATRIX.LOCAL > > Valid starting Expires Service principal > 01/20/13 10:47:56 01/21/13 10:47:56 krbtgt/MATRIX.LOCAL at MATRIX.LOCAL > [root at ipa-server user]# date > Sun Jan 20 10:51:07 CET 2013 > [root at ipa-server user]# ipa-adtrust-install --netbios-name=MATRIX -a mypassword1 > ... > Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket > [root at ipa-server user]# date > Sun Jan 20 10:51:12 CET 2013 > > So the "ipa-adtrust-install" is issued while the krbtgt is valid. However as before kdestroy and subsequent kinit don't > help. Then it might be that the tgt is actually missing something that AD 2012 is now expecting and it is triggering a wrong message. Please file a ticket or BZ. > > On 1/19/13 10:44 PM, Dale Macartney wrote: >> Critical pre-req is definitely make sure DNS resolution is working in >> advance. Its always a killer. >> >> If you use IPA managed DNS, use the following. > Thanks for the pointer Dale, but I don't even get that far to do the actual trust. And as far as I can tell, DNS is > setup correct locally. The resolv.conf points to the IPA server itself (this is automatically changed during > installation), atm no forwarding is done and dns resolution of the ipa-server and ipa-domain work on the ipa-server itself. > > Regards Marco > > > >> On 01/19/2013 01:25 PM, MaSch wrote: >>> Hello all, >>> >>> I'm trying to setup FreeIPA on Fedora 18 (Final) with AD integration on a test server. However I do not even get past >>> the initial (local) steps described in : http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Add_trust_with_AD_domain >>> The last step of the section "Install and configure IPA server" gives me the following error : >>> >>> "Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket" >>> >>> However "kdestroy" followed by a consequent "kinit admin" does not help, I get the error again when trying >>> to "ipa-adtrust-install" >>> >>> The ipaserver-install.log says : >>> 2013-01-19T17:19:56Z DEBUG stderr= >>> 2013-01-19T17:19:56Z DEBUG will use ip_address: 172.16.135.141 >>> >>> 2013-01-19T17:19:56Z DEBUG Starting external process >>> 2013-01-19T17:19:56Z DEBUG args=kinit admin >>> 2013-01-19T17:19:57Z DEBUG Process finished, return code=0 >>> 2013-01-19T17:19:57Z DEBUG stdout=Password for admin at MATRIX.LOCAL: >>> >>> 2013-01-19T17:19:57Z DEBUG stderr= >>> 2013-01-19T17:19:57Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 617, in >>> run_script >>> return_value = main_function() >>> >>> File "/usr/sbin/ipa-adtrust-install", line 304, in main >>> sys.exit("Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket") >>> >>> 2013-01-19T17:19:57Z INFO The ipa-adtrust-install command failed, exception: SystemExit: Outdated Kerberos credentials. >>> Use kdestroy and kinit to update your ticket >>> >>> ______________________________________________________________________________________________________ >>> >>> >>> I tried to follow the instructions and stick to the plan - here is the history of commands I executed on an fresh Fedora >>> 18 Installation (after installing vmware tools in the vm) (long output is omitted and replaced by ...) : >>> >>> >>> [root at linux user]# yum update -y >>> ... >>> [root at linux user]# reboot >>> [root at linux user]# yum install -y "*ipa-server" "*ipa-server-trust-ad" samba4-winbind-clients samba4-winbind >>> samba4-client bind bind-dyndb-ldap >>> ... >>> [root at linux user]# echo "172.16.135.141 ipa-server.matrix.local ipa-server" >> /etc/hosts >>> [root at linux user]# hostname ipa-server.matrix.local >>> [root at linux user]# hostname >>> ipa-server.matrix.local >>> [root at linux user]# ping ipa-server.matrix.local >>> PING ipa-server.matrix.local (172.16.135.141) 56(84) bytes of data. >>> 64 bytes from ipa-server.matrix.local (172.16.135.141): icmp_seq=1 ttl=64 time=0.058 ms >>> [root at linux user]# ipa-server-install -a mypassword1 -p mypassword2 --domain=matrix.local --realm=MATRIX.LOCAL >>> --setup-dns --no-forwarders -U >>> ... setup completes without errors >>> [root at linux user]# kinit admin >>> Password for admin at MATRIX.LOCAL: >>> [root at linux user]# klist >>> Ticket cache: DIR::/run/user/1000/krb5cc_c9794d10f5cd59bd63c423ac50fad257/tktT3hTsU >>> Default principal: admin at MATRIX.LOCAL >>> >>> Valid starting Expires Service principal >>> 01/19/13 12:19:06 01/20/13 12:19:02 krbtgt/MATRIX.LOCAL at MATRIX.LOCAL >>> [root at linux user]# id admin >>> uid=1396400000(admin) gid=1396400000(admins) groups=1396400000(admins) >>> [root at linux user]# getent passwd admin >>> admin:*:1396400000:1396400000:Administrator:/home/admin:/bin/bash >>> [root at linux user]# ipa-adtrust-install --netbios-name=MATRIX -a mypassword1 >>> The log file for this installation can be found in /var/log/ipaserver-install.log >>> ============================================================================== >>> This program will setup components needed to establish trust to AD domains for >>> the FreeIPA Server. >>> >>> This includes: >>> * Configure Samba >>> * Add trust related objects to FreeIPA LDAP server >>> >>> To accept the default shown in brackets, press the Enter key. >>> >>> >>> The following operations may take some minutes to complete. >>> Please wait until the prompt is returned. >>> >>> Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket >>> >>> ______________________________________________________________________________________________________ >>> >>> The freeipa packages installed are : >>> >>> freeipa-server-trust-ad-3.1.0-2.fc18.x86_64 >>> freeipa-python-3.1.0-2.fc18.x86_64 >>> freeipa-server-selinux-3.1.0-2.fc18.x86_64 >>> freeipa-admintools-3.1.0-2.fc18.x86_64 >>> freeipa-server-3.1.0-2.fc18.x86_64 >>> freeipa-client-3.1.0-2.fc18.x86_64 >>> >>> >>> Any help would be appreciated, perhaps I'm just missing a simple step. >>> >>> >>> Regards >>> Marco >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ From simo at redhat.com Sun Jan 20 20:38:18 2013 From: simo at redhat.com (Simo Sorce) Date: Sun, 20 Jan 2013 15:38:18 -0500 Subject: [Freeipa-users] Fedora 18 - FreeIPA + AD In-Reply-To: <50FB1DD2.7070402@redhat.com> References: <50FAE50A.3040008@gmail.com> <50FAF11B.1050006@redhat.com> <50FB13B4.5010703@themacartneyclan.com> <50FB1DD2.7070402@redhat.com> Message-ID: <1358714298.20683.159.camel@willson.li.ssimo.org> On Sat, 2013-01-19 at 17:27 -0500, Dmitri Pal wrote: > On 01/19/2013 04:44 PM, Dale Macartney wrote: > > > > > > On 01/19/2013 07:16 PM, Dmitri Pal wrote: > > > On 01/19/2013 01:25 PM, MaSch wrote: > > >> Hello all, > > >> > > >> I'm trying to setup FreeIPA on Fedora 18 (Final) with AD > integration > > on a test server. However I do not even get past > > >> the initial (local) steps described in : > > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Add_trust_with_AD_domain > > >> The last step of the section "Install and configure IPA server" > gives > > me the following error : > > I am having similar issues, however I only have the problem when > > attempting a trust with AD 2012. Works perfectly on AD 2008r2. > > Sorry for the previous email. > Hit wrong button. > > We have not fully tried AD 2012 so that might be a bug in our code > somewhere. > I am currently not aware of any issue with 2012 which is what I use in my testing. If anything specific to 2012 is found it would be nice to know. Simo. -- Simo Sorce * Red Hat, Inc * New York From sakodak at gmail.com Sun Jan 20 20:38:40 2013 From: sakodak at gmail.com (KodaK) Date: Sun, 20 Jan 2013 14:38:40 -0600 Subject: [Freeipa-users] When will IPA v3 be available in RHEL? Message-ID: This is a surprisingly difficult thing to google for. I'd really like to roll out an AD trust, but I want to stay within RHEL support. Approximate is fine, I just want to know if I can plan for it sometime this year or not. -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 From rendhalver at gmail.com Mon Jan 21 03:11:18 2013 From: rendhalver at gmail.com (Peter Brown) Date: Mon, 21 Jan 2013 13:11:18 +1000 Subject: [Freeipa-users] Best OS to use with FreeIPA? In-Reply-To: <18BD179D-501D-443B-AB39-66B3F51B11D7@codehaus.org> References: <2D5ED387-2E6D-47CF-8554-62D897978F69@codehaus.org> <50F886F9.60105@redhat.com> <18BD179D-501D-443B-AB39-66B3F51B11D7@codehaus.org> Message-ID: On 19 January 2013 05:25, Brian Topping wrote: > Hi Peter and Dimitri, > > Thanks for your responses. I think I am going to bite the bullet and put > F18 into production. One of the elements that made that easier was > recognizing that RHEL 7 was going to be based on Fedora of some sort, and a > stripped-down Fedora with SELinux will be plenty secure while I wait for > that convergence. > It seems that Fedora 18 will be the template for RedHat 7 so it's almost like getting it early. > > Cheers! Brian > > On Jan 17, 2013, at 6:19 PM, Dmitri Pal wrote: > > > On 01/17/2013 05:45 PM, Brian Topping wrote: > >> Apologies if this has been covered elsewhere, I looked through a few > months of archives and the documentation and didn't find anything. > >> > >> What's the best OS to build a production FreeIPA instance on? It seems > like Fedora has more recent versions in their repositories (CentOS is still > at 2.2.0), but I'd prefer to run CentOS as a general rule. > >> > >> Any quick rules of thumb that I can work from? > >> > >> thanks! Brian > >> > >> _______________________________________________ > >> Freeipa-users mailing list > >> Freeipa-users at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > It depends on what level of support you expect and what functionality > > you are looking for. > > The first distro that gets the bits is Fedora then RHEL, then CentOS > > with gap of several months each. > > It is up to you to choose what is best for you and what risks you are > > willing to take in your production environment. > > > > > > -- > > 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 at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Jan 21 08:44:11 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 21 Jan 2013 09:44:11 +0100 Subject: [Freeipa-users] Fedora 18 - FreeIPA + AD In-Reply-To: <50FC4474.7020602@redhat.com> References: <50FAE50A.3040008@gmail.com> <50FAF11B.1050006@redhat.com> <50FBC071.5090704@gmail.com> <50FC4474.7020602@redhat.com> Message-ID: <20130121084411.GA17244@localhost.localdomain> On Sun, Jan 20, 2013 at 02:24:36PM -0500, Dmitri Pal wrote: > On 01/20/2013 05:01 AM, MaSch wrote: > > On 1/19/13 8:16 PM, Dmitri Pal wrote: > >> What is the situation with the time on that box? > >> Was the time and time zone set correctly? > >> Is it a VM? > >> Can it be that the time drifted in some way? > >> > > The time zone is correct for my region (Europe/Berlin) as is the current time. > > It is a VM - running inside VMware Fusion 4 on OSX. > > I doubt that time drifted in between somehow in an unsual manner. I just tried again and checked : > > > > [root at ipa-server user]# klist > > Ticket cache: DIR::/run/user/1000/krb5cc_1f3f8ebeec8d053aa0a2f46e50fbb20c/tkt5LELnl > > Default principal: admin at MATRIX.LOCAL > > > > Valid starting Expires Service principal > > 01/20/13 10:47:56 01/21/13 10:47:56 krbtgt/MATRIX.LOCAL at MATRIX.LOCAL > > [root at ipa-server user]# date > > Sun Jan 20 10:51:07 CET 2013 > > [root at ipa-server user]# ipa-adtrust-install --netbios-name=MATRIX -a mypassword1 > > ... > > Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket > > [root at ipa-server user]# date > > Sun Jan 20 10:51:12 CET 2013 > > > > So the "ipa-adtrust-install" is issued while the krbtgt is valid. However as before kdestroy and subsequent kinit don't > > help. > > Then it might be that the tgt is actually missing something that AD 2012 > is now expecting and it is triggering a wrong message. > Please file a ticket or BZ. This is not related to AD because it is still the step before establishing the trust as Marco said below. The message "Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket" indicate that we failed to connect to the local LDAP server. Maybe a ticket should be filed to mention the local LDAP server in the message? Marco, have you tried to run ipa-adtrust-install without the -a option? Can you try access your local LDAP server with: # kinit admin # ldapsearch -H ldap://ipa-server.matrix.local -Y GSSAPI -b \ 'dc=matrix,dc=local' -s base bye, Sumit > > > > > On 1/19/13 10:44 PM, Dale Macartney wrote: > >> Critical pre-req is definitely make sure DNS resolution is working in > >> advance. Its always a killer. > >> > >> If you use IPA managed DNS, use the following. > > Thanks for the pointer Dale, but I don't even get that far to do the actual trust. And as far as I can tell, DNS is > > setup correct locally. The resolv.conf points to the IPA server itself (this is automatically changed during > > installation), atm no forwarding is done and dns resolution of the ipa-server and ipa-domain work on the ipa-server itself. > > > > Regards Marco > > > > > > > >> On 01/19/2013 01:25 PM, MaSch wrote: > >>> Hello all, > >>> > >>> I'm trying to setup FreeIPA on Fedora 18 (Final) with AD integration on a test server. However I do not even get past > >>> the initial (local) steps described in : http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Add_trust_with_AD_domain > >>> The last step of the section "Install and configure IPA server" gives me the following error : > >>> > >>> "Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket" > >>> > >>> However "kdestroy" followed by a consequent "kinit admin" does not help, I get the error again when trying > >>> to "ipa-adtrust-install" > >>> > >>> The ipaserver-install.log says : > >>> 2013-01-19T17:19:56Z DEBUG stderr= > >>> 2013-01-19T17:19:56Z DEBUG will use ip_address: 172.16.135.141 > >>> > >>> 2013-01-19T17:19:56Z DEBUG Starting external process > >>> 2013-01-19T17:19:56Z DEBUG args=kinit admin > >>> 2013-01-19T17:19:57Z DEBUG Process finished, return code=0 > >>> 2013-01-19T17:19:57Z DEBUG stdout=Password for admin at MATRIX.LOCAL: > >>> > >>> 2013-01-19T17:19:57Z DEBUG stderr= > >>> 2013-01-19T17:19:57Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 617, in > >>> run_script > >>> return_value = main_function() > >>> > >>> File "/usr/sbin/ipa-adtrust-install", line 304, in main > >>> sys.exit("Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket") > >>> > >>> 2013-01-19T17:19:57Z INFO The ipa-adtrust-install command failed, exception: SystemExit: Outdated Kerberos credentials. > >>> Use kdestroy and kinit to update your ticket > >>> > >>> ______________________________________________________________________________________________________ > >>> > >>> > >>> I tried to follow the instructions and stick to the plan - here is the history of commands I executed on an fresh Fedora > >>> 18 Installation (after installing vmware tools in the vm) (long output is omitted and replaced by ...) : > >>> > >>> > >>> [root at linux user]# yum update -y > >>> ... > >>> [root at linux user]# reboot > >>> [root at linux user]# yum install -y "*ipa-server" "*ipa-server-trust-ad" samba4-winbind-clients samba4-winbind > >>> samba4-client bind bind-dyndb-ldap > >>> ... > >>> [root at linux user]# echo "172.16.135.141 ipa-server.matrix.local ipa-server" >> /etc/hosts > >>> [root at linux user]# hostname ipa-server.matrix.local > >>> [root at linux user]# hostname > >>> ipa-server.matrix.local > >>> [root at linux user]# ping ipa-server.matrix.local > >>> PING ipa-server.matrix.local (172.16.135.141) 56(84) bytes of data. > >>> 64 bytes from ipa-server.matrix.local (172.16.135.141): icmp_seq=1 ttl=64 time=0.058 ms > >>> [root at linux user]# ipa-server-install -a mypassword1 -p mypassword2 --domain=matrix.local --realm=MATRIX.LOCAL > >>> --setup-dns --no-forwarders -U > >>> ... setup completes without errors > >>> [root at linux user]# kinit admin > >>> Password for admin at MATRIX.LOCAL: > >>> [root at linux user]# klist > >>> Ticket cache: DIR::/run/user/1000/krb5cc_c9794d10f5cd59bd63c423ac50fad257/tktT3hTsU > >>> Default principal: admin at MATRIX.LOCAL > >>> > >>> Valid starting Expires Service principal > >>> 01/19/13 12:19:06 01/20/13 12:19:02 krbtgt/MATRIX.LOCAL at MATRIX.LOCAL > >>> [root at linux user]# id admin > >>> uid=1396400000(admin) gid=1396400000(admins) groups=1396400000(admins) > >>> [root at linux user]# getent passwd admin > >>> admin:*:1396400000:1396400000:Administrator:/home/admin:/bin/bash > >>> [root at linux user]# ipa-adtrust-install --netbios-name=MATRIX -a mypassword1 > >>> The log file for this installation can be found in /var/log/ipaserver-install.log > >>> ============================================================================== > >>> This program will setup components needed to establish trust to AD domains for > >>> the FreeIPA Server. > >>> > >>> This includes: > >>> * Configure Samba > >>> * Add trust related objects to FreeIPA LDAP server > >>> > >>> To accept the default shown in brackets, press the Enter key. > >>> > >>> > >>> The following operations may take some minutes to complete. > >>> Please wait until the prompt is returned. > >>> > >>> Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket > >>> > >>> ______________________________________________________________________________________________________ > >>> > >>> The freeipa packages installed are : > >>> > >>> freeipa-server-trust-ad-3.1.0-2.fc18.x86_64 > >>> freeipa-python-3.1.0-2.fc18.x86_64 > >>> freeipa-server-selinux-3.1.0-2.fc18.x86_64 > >>> freeipa-admintools-3.1.0-2.fc18.x86_64 > >>> freeipa-server-3.1.0-2.fc18.x86_64 > >>> freeipa-client-3.1.0-2.fc18.x86_64 > >>> > >>> > >>> Any help would be appreciated, perhaps I'm just missing a simple step. > >>> > >>> > >>> Regards > >>> Marco > >>> > >>> _______________________________________________ > >>> Freeipa-users mailing list > >>> Freeipa-users at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at 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 at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From vijay.thakur at loopmethods.com Mon Jan 21 09:45:00 2013 From: vijay.thakur at loopmethods.com (Vijay Thakur) Date: Mon, 21 Jan 2013 15:15:00 +0530 Subject: [Freeipa-users] FreeIPA Client Setup in Windows 7 & Ubuntu Message-ID: <50FD0E1C.1080006@loopmethods.com> Dear All List Members, I have installed and configured FreeIPA Server 2.2.1 in Fedora 17. All is working very fine at server end. I have successfully configure my Centos 6.0 Box as FreeIPA Client. Now i have to set up FreeIPA clients of Ubuntu 12.04 and windows 7. There is no available documentation for Windows 7 and Ubuntu 12.04. During the first login of Windows 7 as FreeIPA Client, i have followed the following steps: (1) Login as user1 at XYZ.COM and Password: 12345678 (2) Message "Your Password has expired and must be changed". (3) Changed the Password to new one successfully. (4) Again login with new credentials. (5) Windows 7 giving message "The User Name or Password is incorrect". I have already stopped the Windows 7 firewall. Guide me about Ubuntu 12.04 as FreeIPA Client setting. With Warm Wishes, Vijay Thakur From dpal at redhat.com Mon Jan 21 12:37:39 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 21 Jan 2013 07:37:39 -0500 Subject: [Freeipa-users] FreeIPA Client Setup in Windows 7 & Ubuntu In-Reply-To: <50FD0E1C.1080006@loopmethods.com> References: <50FD0E1C.1080006@loopmethods.com> Message-ID: <50FD3693.7060705@redhat.com> On 01/21/2013 04:45 AM, Vijay Thakur wrote: > Dear All List Members, > > > I have installed and configured FreeIPA Server 2.2.1 in Fedora 17. All > is working very fine at server end. I have > successfully configure my Centos 6.0 Box as FreeIPA Client. Now i have > to set up FreeIPA clients of Ubuntu 12.04 > and windows 7. There is no available documentation for Windows 7 and > Ubuntu 12.04. During the first login of > Windows 7 as FreeIPA Client, i have followed the following steps: > > > (1) Login as user1 at XYZ.COM and Password: 12345678 > (2) Message "Your Password has expired and must be changed". > (3) Changed the Password to new one successfully. > (4) Again login with new credentials. > (5) Windows 7 giving message "The User Name or Password is incorrect". > What did you do to configure Windows 7? Can you produce kerberos logs from the server and the client? Any other relevant logs you can find from the client would be helpful too. > I have already stopped the Windows 7 firewall. > > Guide me about Ubuntu 12.04 as FreeIPA Client setting. I would leave this to Ubuntu users to chime in. I know there have been work done for Ubuntu but we unfortunately I do not have information on the state of this work. > > With Warm Wishes, > > > Vijay Thakur > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ From rcritten at redhat.com Mon Jan 21 17:41:27 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Jan 2013 12:41:27 -0500 Subject: [Freeipa-users] When will IPA v3 be available in RHEL? In-Reply-To: References: Message-ID: <50FD7DC7.1030109@redhat.com> KodaK wrote: > This is a surprisingly difficult thing to google for. I'd really like > to roll out an AD trust, but I want to stay within RHEL support. > Approximate is fine, I just want to know if I can plan for it sometime > this year or not. > 3.0 will be in RHEL 6.4. rob From Steven.Jones at vuw.ac.nz Mon Jan 21 20:28:36 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 21 Jan 2013 20:28:36 +0000 Subject: [Freeipa-users] Best OS to use with FreeIPA? In-Reply-To: References: <2D5ED387-2E6D-47CF-8554-62D897978F69@codehaus.org> <50F886F9.60105@redhat.com> <18BD179D-501D-443B-AB39-66B3F51B11D7@codehaus.org>, Message-ID: <833D8E48405E064EBC54C84EC6B36E40547A77F5@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, My experience with IPA over the last year is, I wouldn't use this in a production environment without full vendor support. So I have to say RHEL6.4 64bit, yes it will cost but frankly its minor compared to lost downtime and credibility. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Peter Brown [rendhalver at gmail.com] Sent: Monday, 21 January 2013 4:11 p.m. To: Brian Topping Cc: freeipa-users Subject: Re: [Freeipa-users] Best OS to use with FreeIPA? On 19 January 2013 05:25, Brian Topping > wrote: Hi Peter and Dimitri, Thanks for your responses. I think I am going to bite the bullet and put F18 into production. One of the elements that made that easier was recognizing that RHEL 7 was going to be based on Fedora of some sort, and a stripped-down Fedora with SELinux will be plenty secure while I wait for that convergence. It seems that Fedora 18 will be the template for RedHat 7 so it's almost like getting it early. Cheers! Brian On Jan 17, 2013, at 6:19 PM, Dmitri Pal > wrote: > On 01/17/2013 05:45 PM, Brian Topping wrote: >> Apologies if this has been covered elsewhere, I looked through a few months of archives and the documentation and didn't find anything. >> >> What's the best OS to build a production FreeIPA instance on? It seems like Fedora has more recent versions in their repositories (CentOS is still at 2.2.0), but I'd prefer to run CentOS as a general rule. >> >> Any quick rules of thumb that I can work from? >> >> thanks! Brian >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > It depends on what level of support you expect and what functionality > you are looking for. > The first distro that gets the bits is Fedora then RHEL, then CentOS > with gap of several months each. > It is up to you to choose what is best for you and what risks you are > willing to take in your production environment. > > > -- > 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 at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Mon Jan 21 22:25:57 2013 From: sakodak at gmail.com (KodaK) Date: Mon, 21 Jan 2013 16:25:57 -0600 Subject: [Freeipa-users] Best OS to use with FreeIPA? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40547A77F5@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <2D5ED387-2E6D-47CF-8554-62D897978F69@codehaus.org> <50F886F9.60105@redhat.com> <18BD179D-501D-443B-AB39-66B3F51B11D7@codehaus.org> <833D8E48405E064EBC54C84EC6B36E40547A77F5@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: On Mon, Jan 21, 2013 at 2:28 PM, Steven Jones wrote: > Hi, > > My experience with IPA over the last year is, I wouldn't use this in a > production environment without full vendor support. I can't agree with this more. I can't imagine running this in a production environment without support. If you have support, use it. If you don't -- well, you've always got the mailing list. :) From freeipa at noboost.org Tue Jan 22 03:19:22 2013 From: freeipa at noboost.org (freeipa at noboost.org) Date: Tue, 22 Jan 2013 14:19:22 +1100 Subject: [Freeipa-users] Error: Fedora 18 client to IPA Server 2.2.0? Message-ID: <20130122031922.GA5613@noboost.org> Hi, Has anyone had success with installing the IPA client on Fedora 18 (with SeLinux disabled)? Server: Red Hat Enterprise Linux Server release 6.3 (Santiago) * ipa-server-2.2.0-16.el6.x86_64 Client: Fedora release 18 (Spherical Cow) * freeipa-client-3.1.0-2.fc18.x86_64 Error: I installed with the debug flags and it is technically a complete install, however uid and gid's don't look up correctly. e.g. getent passwd - comes back blank & #Instead of working out the uid/gid, it just shows the number. [root at craigvm-fedora18 home]# ls -la | grep craig drwx------ 45 365 132 16384 Jan 22 13:16 craig Only Errors during the install I could find: 2013-01-22T02:42:13Z INFO Configured /etc/krb5.conf for IPA realm EXAMPLE.COM 2013-01-22T02:42:13Z DEBUG Starting external process 2013-01-22T02:42:13Z DEBUG args=keyctl search @s user ipa_session_cookie:host/craigvm-fedora18.example.com at EXAMPLE.COM 2013-01-22T02:42:13Z DEBUG Process finished, return code=1 2013-01-22T02:42:13Z DEBUG stdout= 2013-01-22T02:42:13Z DEBUG stderr=keyctl_search: Required key not available --- 2013-01-22T02:42:13Z DEBUG Caught fault 3008 from server https://sysvm-ipa.example.com/ipa/xml: invalid 'sshpubkey': must be binary data 2013-01-22T02:42:13Z INFO host_mod: invalid 'sshpubkey': must be binary data 2013-01-22T02:42:13Z WARNING Failed to upload host SSH public keys. ---- Regards, Craig From simo at redhat.com Tue Jan 22 05:51:03 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 22 Jan 2013 00:51:03 -0500 Subject: [Freeipa-users] SSO page FreeIPAv3 In-Reply-To: References: Message-ID: <1358833863.20683.244.camel@willson.li.ssimo.org> On Tue, 2013-01-15 at 18:04 +0800, Umarzuki Mochlis wrote: > problem: > > -using Zimbra Collaboration Suite 8 > -3000 users > -only have license for 2500 users (ZCS Network Edition, users on freeipa) > -500 users on OSS Edition, openldap > > want to achieve: > -single sign-on / login page to log in users on both NE & OSS servers > e.g: user A on NE logs in via webmail.domain.com, user B on OSS also > can log in from webmail.domain.com > > is there any way that I could achieve this with freeipa 3.0? Sorry but this looks more like a Zimbra question than a FreeIPA related one. FreeIPa will allow you to do SSO using GSSAPI for any user that belongs to the FreeIPA directory. As long all your applications use keytabs release by freeipa and have a way to map principals to mailboxes I see no actual obstacle, of course the devil is always in the details. As for integration of Zimbra instances this is probably not the right list to ask. Simo. -- Simo Sorce * Red Hat, Inc * New York From vijay.thakur at loopmethods.com Tue Jan 22 11:09:07 2013 From: vijay.thakur at loopmethods.com (Vijay Thakur) Date: Tue, 22 Jan 2013 16:39:07 +0530 Subject: [Freeipa-users] Freeipa-users Digest, Vol 54, Issue 42 In-Reply-To: References: Message-ID: <50FE7353.3080406@loopmethods.com> On Monday 21 January 2013 10:30 PM, freeipa-users-request at redhat.com wrote: > Send Freeipa-users mailing list submissions to > freeipa-users at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/freeipa-users > or, via email, send a message with subject or body 'help' to > freeipa-users-request at redhat.com > > You can reach the person managing the list at > freeipa-users-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeipa-users digest..." > > > Today's Topics: > > 1. FreeIPA Client Setup in Windows 7 & Ubuntu (Vijay Thakur) > 2. Re: FreeIPA Client Setup in Windows 7 & Ubuntu (Dmitri Pal) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 21 Jan 2013 15:15:00 +0530 > From: Vijay Thakur > To:freeipa-users at redhat.com > Subject: [Freeipa-users] FreeIPA Client Setup in Windows 7 & Ubuntu > Message-ID:<50FD0E1C.1080006 at loopmethods.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Dear All List Members, > > > I have installed and configured FreeIPA Server 2.2.1 in Fedora 17. All > is working very fine at server end. I have > successfully configure my Centos 6.0 Box as FreeIPA Client. Now i have > to set up FreeIPA clients of Ubuntu 12.04 > and windows 7. There is no available documentation for Windows 7 and > Ubuntu 12.04. During the first login of > Windows 7 as FreeIPA Client, i have followed the following steps: > > > (1) Login asuser1 at XYZ.COM and Password: 12345678 > (2) Message "Your Password has expired and must be changed". > (3) Changed the Password to new one successfully. > (4) Again login with new credentials. > (5) Windows 7 giving message "The User Name or Password is incorrect". > > I have already stopped the Windows 7 firewall. > > Guide me about Ubuntu 12.04 as FreeIPA Client setting. > > With Warm Wishes, > > > Vijay Thakur Here is the logs of server side: an 22 16:21:02 ds.example.com krb5kdc[1376](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.51.16: NEEDED_PREAUTH: admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required Jan 22 16:21:02 ds.example.com krb5kdc[1376](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.51.16: ISSUE: authtime 1358851862, etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM Jan 22 16:21:02 ds.example.com krb5kdc[1376](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.51.16: ISSUE: authtime 1358851862, etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for ldap/ds.example.com at EXAMPLE.COM Jan 22 16:34:10 ds.example.com krb5kdc[1376](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.51.17: CLIENT KEY EXPIRED: vijay at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Password has expired Jan 22 16:34:25 ds.example.com krb5kdc[1376](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.51.17: NEEDED_PREAUTH: vijay at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM, Additional pre-authentication required Jan 22 16:34:25 ds.example.com krb5kdc[1376](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.51.17: ISSUE: authtime 1358852665, etypes {rep=18 tkt=18 ses=18}, vijay at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM Jan 22 16:34:25 ds.example.com krb5kdc[1376](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.51.17: NEEDED_PREAUTH: vijay at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required Jan 22 16:34:25 ds.example.com krb5kdc[1376](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.51.17: ISSUE: authtime 1358852665, etypes {rep=18 tkt=18 ses=18}, vijay at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM Jan 22 16:34:25 ds.example.com krb5kdc[1376](info): TGS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.51.17: ISSUE: authtime 1358852665, etypes {rep=18 tkt=18 ses=18}, vijay at EXAMPLE.COM for vijay at EXAMPLE.COM Jan 22 16:34:29 ds.example.com krb5kdc[1376](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.51.17: NEEDED_PREAUTH: vijay at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required Jan 22 16:34:29 ds.example.com krb5kdc[1376](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.51.17: ISSUE: authtime 1358852669, etypes {rep=18 tkt=18 ses=18}, vijay at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM Jan 22 16:34:29 ds.example.com krb5kdc[1376](info): TGS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.51.17: UNKNOWN_SERVER: authtime 0, vijay at EXAMPLE.COM for host/wind at EXAMPLE.COM, Server not found in Kerberos database Jan 22 16:34:54 ds.example.com krb5kdc[1376](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.51.17: NEEDED_PREAUTH: vijay at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required Jan 22 16:34:54 ds.example.com krb5kdc[1376](info): preauth (encrypted_timestamp) verify failure: Decrypt integrity check failed Jan 22 16:34:54 ds.example.com krb5kdc[1376](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.51.17: PREAUTH_FAILED: vijay at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Decrypt integrity check failed Jan 22 16:34:54 ds.example.com krb5kdc[1376](info): preauth (encrypted_timestamp) verify failure: Decrypt integrity check failed Jan 22 16:34:54 ds.example.com krb5kdc[1376](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.51.17: PREAUTH_FAILED: vijay at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Decrypt integrity check failed Kindly tell me the location of kerberose log file in windows 7? With Regards, VJ++ ------------------------------ Message: 2 Date: Mon, 21 Jan 2013 07:37:39 -0500 From: Dmitri Pal To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FreeIPA Client Setup in Windows 7 & Ubuntu Message-ID: <50FD3693.7060705 at redhat.com> Content-Type: text/plain; charset=ISO-8859-1 On 01/21/2013 04:45 AM, Vijay Thakur wrote: >> Dear All List Members, >> >> >> I have installed and configured FreeIPA Server 2.2.1 in Fedora 17. All >> is working very fine at server end. I have >> successfully configure my Centos 6.0 Box as FreeIPA Client. Now i have >> to set up FreeIPA clients of Ubuntu 12.04 >> and windows 7. There is no available documentation for Windows 7 and >> Ubuntu 12.04. During the first login of >> Windows 7 as FreeIPA Client, i have followed the following steps: >> >> >> (1) Login asuser1 at XYZ.COM and Password: 12345678 >> (2) Message "Your Password has expired and must be changed". >> (3) Changed the Password to new one successfully. >> (4) Again login with new credentials. >> (5) Windows 7 giving message "The User Name or Password is incorrect". >> > What did you do to configure Windows 7? > Can you produce kerberos logs from the server and the client? > Any other relevant logs you can find from the client would be helpful too. > > > >> I have already stopped the Windows 7 firewall. >> >> Guide me about Ubuntu 12.04 as FreeIPA Client setting. > I would leave this to Ubuntu users to chime in. > I know there have been work done for Ubuntu but we unfortunately I do > not have information on the state of this work. > >> With Warm Wishes, >> >> >> Vijay Thakur >> >> >> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Tue Jan 22 16:02:39 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Jan 2013 11:02:39 -0500 Subject: [Freeipa-users] Error: Fedora 18 client to IPA Server 2.2.0? In-Reply-To: <20130122031922.GA5613@noboost.org> References: <20130122031922.GA5613@noboost.org> Message-ID: <50FEB81F.7010609@redhat.com> freeipa at noboost.org wrote: > Hi, > > Has anyone had success with installing the IPA client on Fedora 18 (with SeLinux disabled)? > > Server: > Red Hat Enterprise Linux Server release 6.3 (Santiago) > * ipa-server-2.2.0-16.el6.x86_64 > > Client: > Fedora release 18 (Spherical Cow) > * freeipa-client-3.1.0-2.fc18.x86_64 > > Error: > I installed with the debug flags and it is technically a complete > install, however uid and gid's don't look up correctly. > e.g. > getent passwd - comes back blank > > & > > #Instead of working out the uid/gid, it just shows the number. > [root at craigvm-fedora18 home]# ls -la | grep craig > drwx------ 45 365 132 16384 Jan 22 13:16 craig > > > Only Errors during the install I could find: > 2013-01-22T02:42:13Z INFO Configured /etc/krb5.conf for IPA realm > EXAMPLE.COM > 2013-01-22T02:42:13Z DEBUG Starting external process > 2013-01-22T02:42:13Z DEBUG args=keyctl search @s user > ipa_session_cookie:host/craigvm-fedora18.example.com at EXAMPLE.COM > 2013-01-22T02:42:13Z DEBUG Process finished, return code=1 > 2013-01-22T02:42:13Z DEBUG stdout= > 2013-01-22T02:42:13Z DEBUG stderr=keyctl_search: Required key not > available > > --- > 2013-01-22T02:42:13Z DEBUG Caught fault 3008 from server > https://sysvm-ipa.example.com/ipa/xml: invalid 'sshpubkey': > must be binary data > 2013-01-22T02:42:13Z INFO host_mod: invalid 'sshpubkey': must be binary > data > 2013-01-22T02:42:13Z WARNING Failed to upload host SSH public keys. > ---- It sounds like sssd isn't communicating with ipa. One of the last steps of the client install is to use getent to look up the admin user. This should also be in the client install log. Did that succeed? rob From rcritten at redhat.com Tue Jan 22 16:04:55 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Jan 2013 11:04:55 -0500 Subject: [Freeipa-users] Freeipa-users Digest, Vol 54, Issue 42 In-Reply-To: <50FE7353.3080406@loopmethods.com> References: <50FE7353.3080406@loopmethods.com> Message-ID: <50FEB8A7.10508@redhat.com> Vijay Thakur wrote: > On Monday 21 January 2013 10:30 PM, freeipa-users-request at redhat.com wrote: >> >> >> Vijay Thakur > Here is the logs of server side: > > an 22 16:21:02 ds.example.com krb5kdc[1376](info): AS_REQ (4 etypes {18 > 17 16 23}) 192.168.51.16: NEEDED_PREAUTH: admin at EXAMPLE.COM for > krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required > Jan 22 16:21:02 ds.example.com krb5kdc[1376](info): AS_REQ (4 etypes {18 [ snip ] > Kindly tell me the location of kerberose log file in windows 7? I don't believe there are any logs on the windows side. What is it you're trying to do from Windows 7? Are you trying to log in using IPA credentials? What configuration did you perform? Are you using the MIT Kerberos client? IPA is not an AD replacement, you can't do domain logins without a fair bit of configuration. rob From jhrozek at redhat.com Tue Jan 22 16:11:05 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 22 Jan 2013 17:11:05 +0100 Subject: [Freeipa-users] Error: Fedora 18 client to IPA Server 2.2.0? In-Reply-To: <50FEB81F.7010609@redhat.com> References: <20130122031922.GA5613@noboost.org> <50FEB81F.7010609@redhat.com> Message-ID: <20130122161105.GL3690@hendrix.brq.redhat.com> On Tue, Jan 22, 2013 at 11:02:39AM -0500, Rob Crittenden wrote: > freeipa at noboost.org wrote: > >Hi, > > > >Has anyone had success with installing the IPA client on Fedora 18 (with SeLinux disabled)? > > > >Server: > >Red Hat Enterprise Linux Server release 6.3 (Santiago) > >* ipa-server-2.2.0-16.el6.x86_64 > > > >Client: > >Fedora release 18 (Spherical Cow) > >* freeipa-client-3.1.0-2.fc18.x86_64 > > > >Error: > >I installed with the debug flags and it is technically a complete > >install, however uid and gid's don't look up correctly. > >e.g. > >getent passwd - comes back blank > > > >& > > > >#Instead of working out the uid/gid, it just shows the number. > >[root at craigvm-fedora18 home]# ls -la | grep craig > >drwx------ 45 365 132 16384 Jan 22 13:16 craig > > > > > >Only Errors during the install I could find: > >2013-01-22T02:42:13Z INFO Configured /etc/krb5.conf for IPA realm > >EXAMPLE.COM > >2013-01-22T02:42:13Z DEBUG Starting external process > >2013-01-22T02:42:13Z DEBUG args=keyctl search @s user > >ipa_session_cookie:host/craigvm-fedora18.example.com at EXAMPLE.COM > >2013-01-22T02:42:13Z DEBUG Process finished, return code=1 > >2013-01-22T02:42:13Z DEBUG stdout= > >2013-01-22T02:42:13Z DEBUG stderr=keyctl_search: Required key not > >available > > > >--- > >2013-01-22T02:42:13Z DEBUG Caught fault 3008 from server > >https://sysvm-ipa.example.com/ipa/xml: invalid 'sshpubkey': > >must be binary data > >2013-01-22T02:42:13Z INFO host_mod: invalid 'sshpubkey': must be binary > >data > >2013-01-22T02:42:13Z WARNING Failed to upload host SSH public keys. > >---- > > It sounds like sssd isn't communicating with ipa. One of the last > steps of the client install is to use getent to look up the admin > user. This should also be in the client install log. Did that > succeed? > > rob I think Rob is correct. Is there anything relevant in syslog? If not, you may want to raise sssd debugging, restart the SSSD and retry the lookup. From pspacek at redhat.com Tue Jan 22 17:06:58 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 22 Jan 2013 18:06:58 +0100 Subject: [Freeipa-users] FreeIPA Client Setup in Windows 7 & Ubuntu In-Reply-To: <50FEB8A7.10508@redhat.com> References: <50FE7353.3080406@loopmethods.com> <50FEB8A7.10508@redhat.com> Message-ID: <50FEC732.2070703@redhat.com> On 22.1.2013 17:04, Rob Crittenden wrote: > Vijay Thakur wrote: >> On Monday 21 January 2013 10:30 PM, freeipa-users-request at redhat.com wrote: >>> >>> >>> Vijay Thakur >> Here is the logs of server side: >> >> an 22 16:21:02 ds.example.com krb5kdc[1376](info): AS_REQ (4 etypes {18 >> 17 16 23}) 192.168.51.16: NEEDED_PREAUTH: admin at EXAMPLE.COM for >> krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required >> Jan 22 16:21:02 ds.example.com krb5kdc[1376](info): AS_REQ (4 etypes {18 > > [ snip ] > >> Kindly tell me the location of kerberose log file in windows 7? > > I don't believe there are any logs on the windows side. Personally I use tcpdump/wireshark. Built-in parser translates Kerberos errors to human readable form. It often helps a lot. > What is it you're trying to do from Windows 7? Are you trying to log in using > IPA credentials? What configuration did you perform? Are you using the MIT > Kerberos client? > > IPA is not an AD replacement, you can't do domain logins without a fair bit of > configuration. Go for Samba 4 if you are adventurer :-) -- Petr^2 Spacek From matthew.joseph at lmco.com Tue Jan 22 18:32:38 2013 From: matthew.joseph at lmco.com (Joseph, Matthew (EXP)) Date: Tue, 22 Jan 2013 13:32:38 -0500 Subject: [Freeipa-users] OneWaySync Issues Message-ID: <543FB8F8BFD9A74298A96670DA2F2E7F0DD00E5114@HCXMSP1.ca.lmco.com> Hello, I'm trying to configure the oneWaySync option for IPA so only the Windows AD can replicate changes to IPA. When I use the command that I listed below it says it works but when I delete a user form IPA it will then delete the user in Active Directory. Is my command listed below correct? Anyone able to help? Parameters: Server = rhserver Domain = redhat.ca Password = 12345678 Contents of /tmp/unisync; dn: cn=ipa-winsync,cn=plugins,cn=config changetype: modify replace: oneWaySync oneWaySync: From Windows So I enter the following command; ldapmodify -x -D "dc=redhat,dc=ca" -w 12345678 -h rhserver.redhat.ca -f /tmp/unisync Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Jan 22 18:46:41 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Jan 2013 13:46:41 -0500 Subject: [Freeipa-users] OneWaySync Issues In-Reply-To: <543FB8F8BFD9A74298A96670DA2F2E7F0DD00E5114@HCXMSP1.ca.lmco.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0DD00E5114@HCXMSP1.ca.lmco.com> Message-ID: <50FEDE91.1090909@redhat.com> Joseph, Matthew (EXP) wrote: > Hello, > > I?m trying to configure the oneWaySync option for IPA so only the > Windows AD can replicate changes to IPA. > > When I use the command that I listed below it says it works but when I > delete a user form IPA it will then delete the user in Active Directory. > > Is my command listed below correct? Anyone able to help? > > Parameters: > Server = rhserver > Domain = redhat.ca > Password = 12345678 > > Contents of /tmp/unisync; > dn: cn=ipa-winsync,cn=plugins,cn=config > changetype: modify > replace: oneWaySync > oneWaySync: From Windows > > So I enter the following command; > *ldapmodify -x -D "dc=redhat,dc=ca" -w 12345678 ?h rhserver.redhat.ca -f > /tmp/unisync* There should be no space in oneWaySync, it should be fromWindows. rob From rmeggins at redhat.com Tue Jan 22 19:04:03 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 22 Jan 2013 12:04:03 -0700 Subject: [Freeipa-users] OneWaySync Issues In-Reply-To: <50FEDE91.1090909@redhat.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0DD00E5114@HCXMSP1.ca.lmco.com> <50FEDE91.1090909@redhat.com> Message-ID: <50FEE2A3.8010506@redhat.com> On 01/22/2013 11:46 AM, Rob Crittenden wrote: > Joseph, Matthew (EXP) wrote: >> Hello, >> >> I?m trying to configure the oneWaySync option for IPA so only the >> Windows AD can replicate changes to IPA. >> >> When I use the command that I listed below it says it works but when I >> delete a user form IPA it will then delete the user in Active Directory. >> >> Is my command listed below correct? Anyone able to help? >> >> Parameters: >> Server = rhserver >> Domain = redhat.ca >> Password = 12345678 >> >> Contents of /tmp/unisync; >> dn: cn=ipa-winsync,cn=plugins,cn=config >> changetype: modify >> replace: oneWaySync >> oneWaySync: From Windows >> >> So I enter the following command; >> *ldapmodify -x -D "dc=redhat,dc=ca" -w 12345678 ?h rhserver.redhat.ca -f >> /tmp/unisync* > > There should be no space in oneWaySync, it should be fromWindows. I thought the oneWaySync attribute was in the replication/sync agreement entry, not in the ipa-winsync plugin config entry? > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From matthew.joseph at lmco.com Tue Jan 22 18:55:42 2013 From: matthew.joseph at lmco.com (Joseph, Matthew (EXP)) Date: Tue, 22 Jan 2013 13:55:42 -0500 Subject: [Freeipa-users] EXTERNAL: Re: OneWaySync Issues In-Reply-To: <50FEDE91.1090909@redhat.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0DD00E5114@HCXMSP1.ca.lmco.com> <50FEDE91.1090909@redhat.com> Message-ID: <543FB8F8BFD9A74298A96670DA2F2E7F0DD00E5144@HCXMSP1.ca.lmco.com> Hello Rob, Sorry typo on my part. The command I put in is actually fromWindows Matt -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, January 22, 2013 2:47 PM To: Joseph, Matthew (EXP) Cc: freeipa-users at redhat.com Subject: EXTERNAL: Re: [Freeipa-users] OneWaySync Issues Joseph, Matthew (EXP) wrote: > Hello, > > I'm trying to configure the oneWaySync option for IPA so only the > Windows AD can replicate changes to IPA. > > When I use the command that I listed below it says it works but when I > delete a user form IPA it will then delete the user in Active Directory. > > Is my command listed below correct? Anyone able to help? > > Parameters: > Server = rhserver > Domain = redhat.ca > Password = 12345678 > > Contents of /tmp/unisync; > dn: cn=ipa-winsync,cn=plugins,cn=config > changetype: modify > replace: oneWaySync > oneWaySync: From Windows > > So I enter the following command; > *ldapmodify -x -D "dc=redhat,dc=ca" -w 12345678 -h rhserver.redhat.ca > -f > /tmp/unisync* There should be no space in oneWaySync, it should be fromWindows. rob From matthew.joseph at lmco.com Tue Jan 22 19:07:52 2013 From: matthew.joseph at lmco.com (Joseph, Matthew (EXP)) Date: Tue, 22 Jan 2013 14:07:52 -0500 Subject: [Freeipa-users] EXTERNAL: Re: OneWaySync Issues In-Reply-To: <50FEE2A3.8010506@redhat.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0DD00E5114@HCXMSP1.ca.lmco.com> <50FEDE91.1090909@redhat.com> <50FEE2A3.8010506@redhat.com> Message-ID: <543FB8F8BFD9A74298A96670DA2F2E7F0DD00E515F@HCXMSP1.ca.lmco.com> Hey Rob, According to the Red Hat Identity Management documentation provided by Red hat it says to do it with the ldapmodify command. They don't mention any options during the replicator/sync agreement process about uni-directional sync. Matt -----Original Message----- From: Rich Megginson [mailto:rmeggins at redhat.com] Sent: Tuesday, January 22, 2013 3:04 PM To: Rob Crittenden Cc: Joseph, Matthew (EXP); freeipa-users at redhat.com Subject: EXTERNAL: Re: [Freeipa-users] OneWaySync Issues On 01/22/2013 11:46 AM, Rob Crittenden wrote: > Joseph, Matthew (EXP) wrote: >> Hello, >> >> I'm trying to configure the oneWaySync option for IPA so only the >> Windows AD can replicate changes to IPA. >> >> When I use the command that I listed below it says it works but when >> I delete a user form IPA it will then delete the user in Active Directory. >> >> Is my command listed below correct? Anyone able to help? >> >> Parameters: >> Server = rhserver >> Domain = redhat.ca >> Password = 12345678 >> >> Contents of /tmp/unisync; >> dn: cn=ipa-winsync,cn=plugins,cn=config >> changetype: modify >> replace: oneWaySync >> oneWaySync: From Windows >> >> So I enter the following command; >> *ldapmodify -x -D "dc=redhat,dc=ca" -w 12345678 -h rhserver.redhat.ca >> -f >> /tmp/unisync* > > There should be no space in oneWaySync, it should be fromWindows. I thought the oneWaySync attribute was in the replication/sync agreement entry, not in the ipa-winsync plugin config entry? > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From masch82 at gmail.com Tue Jan 22 19:35:58 2013 From: masch82 at gmail.com (MaSch) Date: Tue, 22 Jan 2013 20:35:58 +0100 Subject: [Freeipa-users] Fedora 18 - FreeIPA + AD In-Reply-To: <20130121084411.GA17244@localhost.localdomain> References: <50FAE50A.3040008@gmail.com> <50FAF11B.1050006@redhat.com> <50FBC071.5090704@gmail.com> <50FC4474.7020602@redhat.com> <20130121084411.GA17244@localhost.localdomain> Message-ID: <50FEEA1E.5000209@gmail.com> On 1/21/13 9:44 AM, Sumit Bose wrote: > This is not related to AD because it is still the step before > establishing the trust as Marco said below. The message "Outdated > Kerberos credentials. Use kdestroy and kinit to update your ticket" > indicate that we failed to connect to the local LDAP server. Maybe a > ticket should be filed to mention the local LDAP server in the message? > > Marco, have you tried to run ipa-adtrust-install without the -a option? > Can you try access your local LDAP server with: > > # kinit admin > # ldapsearch -H ldap://ipa-server.matrix.local -Y GSSAPI -b \ > 'dc=matrix,dc=local' -s base > > bye, > Sumit I tried to run ipa-adtrust-install without the -a option - it asks for the password - then I get the same error. ldapsearch works fine (as long as I have a valid ticket) : snip_______________________________________ Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket [root at ipa-server user]# klist Ticket cache: DIR::/run/user/1000/krb5cc_508afa59f766b611435821eb50fee5d0/tktALmOIY Default principal: admin at MATRIX.LOCAL Valid starting Expires Service principal 01/22/13 20:20:56 01/23/13 20:20:56 krbtgt/MATRIX.LOCAL at MATRIX.LOCAL [root at ipa-server user]# ldapsearch -H ldap://ipa-server.matrix.local -Y GSSAPI -b \ > 'dc=matrix,dc=local' -s base SASL/GSSAPI authentication started SASL username: admin at MATRIX.LOCAL SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope baseObject # filter: (objectclass=*) # requesting: ALL # # matrix.local dn: dc=matrix,dc=local objectClass: top objectClass: domain objectClass: pilotObject objectClass: domainRelatedObject objectClass: nisDomainObject dc: matrix info: IPA V2.0 nisDomain: matrix.local associatedDomain: matrix.local # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 _______________________________________snip I will file a bug report ... Thanks for the help so far. > On Sun, Jan 20, 2013 at 02:24:36PM -0500, Dmitri Pal wrote: >> On 01/20/2013 05:01 AM, MaSch wrote: >>> On 1/19/13 8:16 PM, Dmitri Pal wrote: >>>> What is the situation with the time on that box? >>>> Was the time and time zone set correctly? >>>> Is it a VM? >>>> Can it be that the time drifted in some way? >>>> >>> The time zone is correct for my region (Europe/Berlin) as is the current time. >>> It is a VM - running inside VMware Fusion 4 on OSX. >>> I doubt that time drifted in between somehow in an unsual manner. I just tried again and checked : >>> >>> [root at ipa-server user]# klist >>> Ticket cache: DIR::/run/user/1000/krb5cc_1f3f8ebeec8d053aa0a2f46e50fbb20c/tkt5LELnl >>> Default principal: admin at MATRIX.LOCAL >>> >>> Valid starting Expires Service principal >>> 01/20/13 10:47:56 01/21/13 10:47:56 krbtgt/MATRIX.LOCAL at MATRIX.LOCAL >>> [root at ipa-server user]# date >>> Sun Jan 20 10:51:07 CET 2013 >>> [root at ipa-server user]# ipa-adtrust-install --netbios-name=MATRIX -a mypassword1 >>> ... >>> Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket >>> [root at ipa-server user]# date >>> Sun Jan 20 10:51:12 CET 2013 >>> >>> So the "ipa-adtrust-install" is issued while the krbtgt is valid. However as before kdestroy and subsequent kinit don't >>> help. >> >> Then it might be that the tgt is actually missing something that AD 2012 >> is now expecting and it is triggering a wrong message. >> Please file a ticket or BZ. > >> >>> >>> On 1/19/13 10:44 PM, Dale Macartney wrote: >>>> Critical pre-req is definitely make sure DNS resolution is working in >>>> advance. Its always a killer. >>>> >>>> If you use IPA managed DNS, use the following. >>> Thanks for the pointer Dale, but I don't even get that far to do the actual trust. And as far as I can tell, DNS is >>> setup correct locally. The resolv.conf points to the IPA server itself (this is automatically changed during >>> installation), atm no forwarding is done and dns resolution of the ipa-server and ipa-domain work on the ipa-server itself. >>> >>> Regards Marco >>> >>> >>> >>>> On 01/19/2013 01:25 PM, MaSch wrote: >>>>> Hello all, >>>>> >>>>> I'm trying to setup FreeIPA on Fedora 18 (Final) with AD integration on a test server. However I do not even get past >>>>> the initial (local) steps described in : http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Add_trust_with_AD_domain >>>>> The last step of the section "Install and configure IPA server" gives me the following error : >>>>> >>>>> "Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket" >>>>> >>>>> However "kdestroy" followed by a consequent "kinit admin" does not help, I get the error again when trying >>>>> to "ipa-adtrust-install" >>>>> >>>>> The ipaserver-install.log says : >>>>> 2013-01-19T17:19:56Z DEBUG stderr= >>>>> 2013-01-19T17:19:56Z DEBUG will use ip_address: 172.16.135.141 >>>>> >>>>> 2013-01-19T17:19:56Z DEBUG Starting external process >>>>> 2013-01-19T17:19:56Z DEBUG args=kinit admin >>>>> 2013-01-19T17:19:57Z DEBUG Process finished, return code=0 >>>>> 2013-01-19T17:19:57Z DEBUG stdout=Password for admin at MATRIX.LOCAL: >>>>> >>>>> 2013-01-19T17:19:57Z DEBUG stderr= >>>>> 2013-01-19T17:19:57Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 617, in >>>>> run_script >>>>> return_value = main_function() >>>>> >>>>> File "/usr/sbin/ipa-adtrust-install", line 304, in main >>>>> sys.exit("Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket") >>>>> >>>>> 2013-01-19T17:19:57Z INFO The ipa-adtrust-install command failed, exception: SystemExit: Outdated Kerberos credentials. >>>>> Use kdestroy and kinit to update your ticket >>>>> >>>>> ______________________________________________________________________________________________________ >>>>> >>>>> >>>>> I tried to follow the instructions and stick to the plan - here is the history of commands I executed on an fresh Fedora >>>>> 18 Installation (after installing vmware tools in the vm) (long output is omitted and replaced by ...) : >>>>> >>>>> >>>>> [root at linux user]# yum update -y >>>>> ... >>>>> [root at linux user]# reboot >>>>> [root at linux user]# yum install -y "*ipa-server" "*ipa-server-trust-ad" samba4-winbind-clients samba4-winbind >>>>> samba4-client bind bind-dyndb-ldap >>>>> ... >>>>> [root at linux user]# echo "172.16.135.141 ipa-server.matrix.local ipa-server" >> /etc/hosts >>>>> [root at linux user]# hostname ipa-server.matrix.local >>>>> [root at linux user]# hostname >>>>> ipa-server.matrix.local >>>>> [root at linux user]# ping ipa-server.matrix.local >>>>> PING ipa-server.matrix.local (172.16.135.141) 56(84) bytes of data. >>>>> 64 bytes from ipa-server.matrix.local (172.16.135.141): icmp_seq=1 ttl=64 time=0.058 ms >>>>> [root at linux user]# ipa-server-install -a mypassword1 -p mypassword2 --domain=matrix.local --realm=MATRIX.LOCAL >>>>> --setup-dns --no-forwarders -U >>>>> ... setup completes without errors >>>>> [root at linux user]# kinit admin >>>>> Password for admin at MATRIX.LOCAL: >>>>> [root at linux user]# klist >>>>> Ticket cache: DIR::/run/user/1000/krb5cc_c9794d10f5cd59bd63c423ac50fad257/tktT3hTsU >>>>> Default principal: admin at MATRIX.LOCAL >>>>> >>>>> Valid starting Expires Service principal >>>>> 01/19/13 12:19:06 01/20/13 12:19:02 krbtgt/MATRIX.LOCAL at MATRIX.LOCAL >>>>> [root at linux user]# id admin >>>>> uid=1396400000(admin) gid=1396400000(admins) groups=1396400000(admins) >>>>> [root at linux user]# getent passwd admin >>>>> admin:*:1396400000:1396400000:Administrator:/home/admin:/bin/bash >>>>> [root at linux user]# ipa-adtrust-install --netbios-name=MATRIX -a mypassword1 >>>>> The log file for this installation can be found in /var/log/ipaserver-install.log >>>>> ============================================================================== >>>>> This program will setup components needed to establish trust to AD domains for >>>>> the FreeIPA Server. >>>>> >>>>> This includes: >>>>> * Configure Samba >>>>> * Add trust related objects to FreeIPA LDAP server >>>>> >>>>> To accept the default shown in brackets, press the Enter key. >>>>> >>>>> >>>>> The following operations may take some minutes to complete. >>>>> Please wait until the prompt is returned. >>>>> >>>>> Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket >>>>> >>>>> ______________________________________________________________________________________________________ >>>>> >>>>> The freeipa packages installed are : >>>>> >>>>> freeipa-server-trust-ad-3.1.0-2.fc18.x86_64 >>>>> freeipa-python-3.1.0-2.fc18.x86_64 >>>>> freeipa-server-selinux-3.1.0-2.fc18.x86_64 >>>>> freeipa-admintools-3.1.0-2.fc18.x86_64 >>>>> freeipa-server-3.1.0-2.fc18.x86_64 >>>>> freeipa-client-3.1.0-2.fc18.x86_64 >>>>> >>>>> >>>>> Any help would be appreciated, perhaps I'm just missing a simple step. >>>>> >>>>> >>>>> Regards >>>>> Marco >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at 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 at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From mbarr at snap-interactive.com Tue Jan 22 20:39:24 2013 From: mbarr at snap-interactive.com (Matthew Barr) Date: Tue, 22 Jan 2013 15:39:24 -0500 Subject: [Freeipa-users] Starting from scratch & migrating users? Message-ID: We've got a freeipa system installed, but it's experiencing some bugs. I suspect some of it came from adding & removing a replica, as well as upgrading from prior versions. (we're on centos 6.3 now) We're about to do a datacenter rebuild & move, and I'd like to start from scratch, yet still import the users & their passwords. I suspect we can just do a clean build in the new site, and just do a migrate of the users via the ldap method. Thoughts? I don't anticipate moving any hardware that's enrolled from site to site, so certs & the like shouldn't be a factor. Matthew Barr Technical Architect E: mbarr at snap-interactive.com AIM: matthewbarr1 c: (646) 727-0535 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bob.sauvage at gmx.fr Tue Jan 22 20:51:33 2013 From: Bob.sauvage at gmx.fr (Bob Sauvage) Date: Tue, 22 Jan 2013 21:51:33 +0100 Subject: [Freeipa-users] Some interrogations about the freeipa deployment Message-ID: <20130122205133.242570@gmx.com> Hi *, I plan to review the network architecture of my office. 10 Windows/Linux desktops and 2 Linux servers will be deployed on the network. I want to install freeipa on the first server to act like an AD DS. I want to authenticate users on the server and controlling what can be done or not by them on the network. 10 other linux web servers should be accessible (console) by specific users and without the need to authenticating again (single sign on). On these web servers, users can issue specific commands like "/etc/init.d/httpd restart". Is it possible to achive this with freeipa ? Do you have some articles ? Thanks in advance, Bob ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Jan 22 21:51:01 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 22 Jan 2013 21:51:01 +0000 Subject: [Freeipa-users] Some interrogations about the freeipa deployment In-Reply-To: <20130122205133.242570@gmx.com> References: <20130122205133.242570@gmx.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40547A8778@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I have all done this, so from what you write I think IPA would be a good fit for what you want, except that is the single sign on bit I have not looked to see if that can be done. For http restart you control that via sudo in IPA so its centrally managed, I have this working for one such server though I use the reload option instead. I would also not run one instance of IPA myself but with such a small site that's your call. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Bob Sauvage [Bob.sauvage at gmx.fr] Sent: Wednesday, 23 January 2013 9:51 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] Some interrogations about the freeipa deployment Hi *, I plan to review the network architecture of my office. 10 Windows/Linux desktops and 2 Linux servers will be deployed on the network. I want to install freeipa on the first server to act like an AD DS. I want to authenticate users on the server and controlling what can be done or not by them on the network. 10 other linux web servers should be accessible (console) by specific users and without the need to authenticating again (single sign on). On these web servers, users can issue specific commands like "/etc/init.d/httpd restart". Is it possible to achive this with freeipa ? Do you have some articles ? Thanks in advance, Bob ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dale at themacartneyclan.com Tue Jan 22 22:13:45 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Tue, 22 Jan 2013 22:13:45 +0000 Subject: [Freeipa-users] Some interrogations about the freeipa deployment In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40547A8778@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <20130122205133.242570@gmx.com> <833D8E48405E064EBC54C84EC6B36E40547A8778@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <50FF0F19.8030600@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/22/2013 09:51 PM, Steven Jones wrote: > Hi, > > I have all done this, so from what you write I think IPA would be a good fit for what you want, except that is the single sign on bit I have not looked to see if that can be done. For http restart you control that via sudo in IPA so its centrally managed, I have this working for one such server though I use the reload option instead. to enable SSO with SSH from a ipa workstation, just edit /etc/ssh/sshd_config and make sure the line below is set to yes "GSSAPIAuthentication yes" If you've just made the change, it won't take effect until SSH is restarted. So do the usual service sshd restart. > > I would also not run one instance of IPA myself but with such a small site that's your call. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ------------------------- > *From:* freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Bob Sauvage [Bob.sauvage at gmx.fr] > *Sent:* Wednesday, 23 January 2013 9:51 a.m. > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] Some interrogations about the freeipa deployment > > Hi *, > > I plan to review the network architecture of my office. 10 Windows/Linux desktops and 2 Linux servers will be deployed on the network. > > I want to install freeipa on the first server to act like an AD DS. I want to authenticate users on the server and controlling what can be done or not by them on the network. 10 other linux web servers should be accessible (console) by specific users and without the need to authenticating again (single sign on). On these web servers, users can issue specific commands like "/etc/init.d/httpd restart". > > Is it possible to achive this with freeipa ? Do you have some articles ? > > Thanks in advance, > > Bob ! > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ/w8VAAoJEAJsWS61tB+q2+8P/0voaYOSa/ZnwiQmvrqLsaPE oYm4j/m88STSXvDdhDsgNQJZJFY9XDv7y3njnuSWElqHD0yGBEbJvc+pmoi8uZf0 8EORIarUQhCf6awI4RIHxg6+nOOwVkllx/FDVSJldGnKlv3OSvOrln+tTK9gITkg ZzsMvtFTYIjrF4nMSEtTCGfFi7lnmCrvXhXijKSCRjUfZI51t78SamI5ldKzV6Zy RE4ofJQexUpWhCXnDyWg5I/fDY6EQc9UAjeiVjmC462Sp32Rso5bQBYUwrQtD8uG d1b1sfOW3v+oExmnOfSeGwzssl8SzYk1jr9kak9JU1DctPIgp5aCjpKYtRTnh5GB 44bNMXATFHRWVU21QlaTYwmQue12cb1BaehMUjZfvHTvNcK171RF9DfAhxS+U1Z4 ZCyv8mUGDB28xWKx0fH5639CGjPYCZxltOOF/053W7ZyrrRN38O2AD7LUkYdH3kb ci04L/tB8znXcP6OQaTeDzJHY12bkspJz+tBNvM/KeFhJQxw/FQqtFi55KrhlKMN XCsHdj3fqEzV/h6+3wu0Na7Y4hDt5mf0i3i1UTO9nj941QIr2BYKrQLzKSKLu/Md Z+E04ZgiQWgzb+Yw4bFv6I8g4y6nrUFVvDxt970bqgbk9cbfAGLEMjd6xRm6QDgq CJUkZcaWqi3SYPeGHx0x =fTHE -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Jan 22 22:15:42 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 22 Jan 2013 17:15:42 -0500 Subject: [Freeipa-users] Starting from scratch & migrating users? In-Reply-To: References: Message-ID: <50FF0F8E.6060604@redhat.com> On 01/22/2013 03:39 PM, Matthew Barr wrote: > We've got a freeipa system installed, but it's experiencing some bugs. > I suspect some of it came from adding & removing a replica, as well > as upgrading from prior versions. > (we're on centos 6.3 now) > > We're about to do a datacenter rebuild & move, and I'd like to start > from scratch, yet still import the users & their passwords. I > suspect we can just do a clean build in the new site, and just do a > migrate of the users via the ldap method. Which exactly LDAP method? ldif dump and load? This would not work well unless you also manage to move certs and kerberos master key over which is really hard. > > Thoughts? I don't anticipate moving any hardware that's enrolled from > site to site, so certs & the like shouldn't be a factor. > If you are instead of dump and load will install a new IPA server it will not have any old data and will have new certs and kerberos keys. You would have to re-enroll all your clients once again. Users would have to deal with the password change after you read in users using ipa migrate-ds. Other information also would have be precreated using ipa commands but this can be scripted by taking an LDIF and creating a series of ipa commands to add data into the new instance. > > Matthew Barr > Technical Architect > E: mbarr at snap-interactive.com > AIM: matthewbarr1 > c: (646) 727-0535 > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbarr at snap-interactive.com Tue Jan 22 23:28:31 2013 From: mbarr at snap-interactive.com (Matthew Barr) Date: Tue, 22 Jan 2013 18:28:31 -0500 Subject: [Freeipa-users] Starting from scratch & migrating users? In-Reply-To: <50FF0F8E.6060604@redhat.com> References: <50FF0F8E.6060604@redhat.com> Message-ID: <956C5C3B-947E-454B-AF60-CEF882C4DE76@snap-interactive.com> On Jan 22, 2013, at 5:15 PM, Dmitri Pal wrote: > > Which exactly LDAP method? > ldif dump and load? This would not work well unless you also manage to move certs and kerberos master key over which is really hard. I was assuming the ipa migrate-ds. > >> >> Thoughts? I don't anticipate moving any hardware that's enrolled from site to site, so certs & the like shouldn't be a factor. >> > If you are instead of dump and load will install a new IPA server it will not have any old data and will have new certs and kerberos keys. > You would have to re-enroll all your clients once again. Users would have to deal with the password change after you read in users using ipa migrate-ds. > Other information also would have be precreated using ipa commands but this can be scripted by taking an LDIF and creating a series of ipa commands to add data into the new instance. I intend to re-enroll all clients. Only clients in the new site will be in the system. Most of my users (25 users) use linux, and sssd will take care of most of the kerberos hashes. The rest - 10 -15 users - can be told to login to the migrate LDAP page, later on in the migration. We've got very little other information in IPA, so it's not a huge issue. I thought this might be easier than trying to clean up old crud, and moving the master IPA server. There doesn't seem to be a very good process for moving all the components to a new master easily. Thanks! From dpal at redhat.com Wed Jan 23 00:02:44 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 22 Jan 2013 19:02:44 -0500 Subject: [Freeipa-users] Starting from scratch & migrating users? In-Reply-To: <956C5C3B-947E-454B-AF60-CEF882C4DE76@snap-interactive.com> References: <50FF0F8E.6060604@redhat.com> <956C5C3B-947E-454B-AF60-CEF882C4DE76@snap-interactive.com> Message-ID: <50FF28A4.4000304@redhat.com> On 01/22/2013 06:28 PM, Matthew Barr wrote: > On Jan 22, 2013, at 5:15 PM, Dmitri Pal wrote: >> Which exactly LDAP method? >> ldif dump and load? This would not work well unless you also manage to move certs and kerberos master key over which is really hard. > I was assuming the ipa migrate-ds. > > >>> Thoughts? I don't anticipate moving any hardware that's enrolled from site to site, so certs & the like shouldn't be a factor. >>> >> If you are instead of dump and load will install a new IPA server it will not have any old data and will have new certs and kerberos keys. >> You would have to re-enroll all your clients once again. Users would have to deal with the password change after you read in users using ipa migrate-ds. >> Other information also would have be precreated using ipa commands but this can be scripted by taking an LDIF and creating a series of ipa commands to add data into the new instance. > > I intend to re-enroll all clients. Only clients in the new site will be in the system. > > Most of my users (25 users) use linux, and sssd will take care of most of the kerberos hashes. The rest - 10 -15 users - can be told to login to the migrate LDAP page, later on in the migration. > > We've got very little other information in IPA, so it's not a huge issue. > > > I thought this might be easier than trying to clean up old crud, and moving the master IPA server. There doesn't seem to be a very good process for moving all the components to a new master easily. > > > > Thanks! You are correct. There is no good process to move data over but it seems that you thought through things very well. You described the same sequence as I would recommend at the moment to anyone who wants to move from one IPA instance into a completely new one. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From d.sastre.medina at gmail.com Wed Jan 23 07:18:44 2013 From: d.sastre.medina at gmail.com (David Sastre Medina) Date: Wed, 23 Jan 2013 08:18:44 +0100 Subject: [Freeipa-users] Managing jboss through sudo In-Reply-To: <50F75154.10900@redhat.com> References: <50F75154.10900@redhat.com> Message-ID: <20130123071843.GA4448@pris.crapsteak.org> On Wed, Jan 16, 2013 at 08:18:12PM -0500, Dmitri Pal wrote: > On 01/16/2013 07:30 PM, William Muriithi wrote: > > Hello > > > > I am trying to set up dev systems and want to only allow developers to > > modify the jboss directory tree, shutdown and restarting jboss. This > > is mainly so that they dev system don't deviate from the qa and > > production machines. > > > > The directory permissions are fine, but I am having a problem with > > stopping and restarting jboss. (We are running jboss on port 80, so > > they would need root permission for it to bind on port 80). My other > > problem is that the jboss directory path is not the same across > > servers. Wouldn't it be easier to have an init script for JBoss? This way, all you'd need is a sudo rule to allow devs to: $ sudo service jboss (start|stop|status) -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: Digital signature URL: From d.sastre.medina at gmail.com Wed Jan 23 07:28:57 2013 From: d.sastre.medina at gmail.com (David Sastre Medina) Date: Wed, 23 Jan 2013 08:28:57 +0100 Subject: [Freeipa-users] FreeIPA Client Setup in Windows 7 & Ubuntu In-Reply-To: <50FD3693.7060705@redhat.com> References: <50FD0E1C.1080006@loopmethods.com> <50FD3693.7060705@redhat.com> Message-ID: <20130123072855.GB4448@pris.crapsteak.org> On Mon, Jan 21, 2013 at 07:37:39AM -0500, Dmitri Pal wrote: > On 01/21/2013 04:45 AM, Vijay Thakur wrote: > > Guide me about Ubuntu 12.04 as FreeIPA Client setting. > > I know there have been work done for Ubuntu but we unfortunately I do > not have information on the state of this work. Regarding Ubuntu, you can check, for example: http://packages.ubuntu.com/search?suite=all&arch=any&searchon=names&keywords=freeipa http://packages.ubuntu.com/search?suite=all§ion=all&arch=any&keywords=389&searchon=names http://packages.ubuntu.com/search?suite=all§ion=all&arch=any&keywords=sssd&searchon=names -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: Digital signature URL: From chillermillerlong at hotmail.com Wed Jan 23 07:48:20 2013 From: chillermillerlong at hotmail.com (=?utf-8?B?5bCP6b6ZIOmZiA==?=) Date: Wed, 23 Jan 2013 02:48:20 -0500 Subject: [Freeipa-users] FreeIPA Client Setup in Windows 7 & Ubuntu In-Reply-To: <20130123072855.GB4448@pris.crapsteak.org> References: <50FD0E1C.1080006@loopmethods.com>, <50FD3693.7060705@redhat.com>, <20130123072855.GB4448@pris.crapsteak.org> Message-ID: ---------------------------------------- Date: Wed, 23 Jan 2013 08:28:57 +0100 From: d.sastre.medina at gmail.com To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FreeIPA Client Setup in Windows 7 & Ubuntu On Mon, Jan 21, 2013 at 07:37:39AM -0500, Dmitri Pal wrote: > On 01/21/2013 04:45 AM, Vijay Thakur wrote: > > Guide me about Ubuntu 12.04 as FreeIPA Client setting. > > I know there have been work done for Ubuntu but we unfortunately I do > not have information on the state of this work. Regarding Ubuntu, you can check, for example: http://packages.ubuntu.com/search?suite=all&arch=any&searchon=names&keywords=freeipa http://packages.ubuntu.com/search?suite=all§ion=all&arch=any&keywords=389&searchon=names http://packages.ubuntu.com/search?suite=all§ion=all&arch=any&keywords=sssd&searchon=names -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 _______________________________________________ The current version of sssd in any version of Ubuntu is broken. The packaging needs to pass '--datadir=/usr/share' or '$(prefix)' will show up in some python files. Bug report:?https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1079938 Unfortunately, it still hasn't been fixed. Xiao-Long Chen From tjaalton at ubuntu.com Wed Jan 23 09:00:59 2013 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Wed, 23 Jan 2013 11:00:59 +0200 Subject: [Freeipa-users] FreeIPA Client Setup in Windows 7 & Ubuntu In-Reply-To: References: <50FD0E1C.1080006@loopmethods.com>, <50FD3693.7060705@redhat.com>, <20130123072855.GB4448@pris.crapsteak.org> Message-ID: <50FFA6CB.7080604@ubuntu.com> On 23.01.2013 09:48, ?? ? wrote: > ---------------------------------------- > Date: Wed, 23 Jan 2013 08:28:57 +0100 > From: d.sastre.medina at gmail.com > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FreeIPA Client Setup in Windows 7 & Ubuntu > > > On Mon, Jan 21, 2013 at 07:37:39AM -0500, Dmitri Pal wrote: >> On 01/21/2013 04:45 AM, Vijay Thakur wrote: >>> Guide me about Ubuntu 12.04 as FreeIPA Client setting. >> >> I know there have been work done for Ubuntu but we unfortunately I do >> not have information on the state of this work. > > Regarding Ubuntu, you can check, for example: > > http://packages.ubuntu.com/search?suite=all&arch=any&searchon=names&keywords=freeipa > http://packages.ubuntu.com/search?suite=all§ion=all&arch=any&keywords=389&searchon=names > http://packages.ubuntu.com/search?suite=all§ion=all&arch=any&keywords=sssd&searchon=names > > -- > Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 > > _______________________________________________ > > The current version of sssd in any version of Ubuntu is broken. > The packaging needs to pass '--datadir=/usr/share' or '$(prefix)' will show up > in some python files. > > Bug report: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1079938 > > Unfortunately, it still hasn't been fixed. The updates for 12.04 (bumping sssd to 1.8.5 too) and 12.10 are uploaded, just not accepted to -proposed yet. I'll ping the SRU team to let them through.. -- t From john at ox-consulting.com Wed Jan 23 10:05:44 2013 From: john at ox-consulting.com (Johnathan Phan) Date: Wed, 23 Jan 2013 10:05:44 +0000 Subject: [Freeipa-users] openldap to ipa In-Reply-To: References: <3817AE3D-3005-4B2A-830D-2140865B0DFD@citrixonline.com> <50F449EE.5090708@redhat.com> Message-ID: For record sake. This issue was resolved. I resolved the issue by following the following guidance provided in the following bug report. https://fedorahosted.org/freeipa/ticket/3364 On Tue, Jan 15, 2013 at 9:35 AM, Johnathan Phan wrote: > Hi Rcrit, > > As Outlined in the IRC channel. Please find the ldap.conf from the open > ldap server below. > > URI ldap://ldap.example.com ldap://ldap1.example.com > BASE dc=example,dc=com > TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt > > I then copy the file /etc/pki/tls/certs/ca-bundle.crt from the openldap > server over to the test IPA server and on the IPA server I run the > following command. > > certutil -A -d /etc/httpd/alias -n 'openldap CA' -t CT,, -a -i > ca-bundle.crt > > The openldap server is using a certificate signed by a CA. The IPA server > is using the self signed certificate it generated when starting up. > > I still get the error after adding the CA bundle for openldap server to > the apache cert db on IPA server. > > After explaining all this, I feel that the problem lies with the self > signed cert on the IPA server. Can I confirm with someone the process in > which the migration of data occurs? > > I gather the it something like this. > > 1 >IPA binds/creates a connection to the remote server via SSL/TSL and > creates a connection > 2> It then binds to a socket locally > 3> Then contacts the apache server for some reason (no idea why this is > contacting apache on 443?) > > Regards > > John > > > On Mon, Jan 14, 2013 at 6:09 PM, Rob Crittenden wrote: > >> Johnathan Phan wrote: >> >>> Anyone know the details of the low level system steps for the migration >>> script to work? so I can try and backwards engineer or troubleshoot each >>> system as I go along so I can actually migrate the data from openldap to >>> ipa? >>> >> >> The migration is taking place in the context of the web server. So any >> trust needs to be added to /etc/httpd/alias (and the httpd service >> restarted). It needs to trust the signer of the remote LDAP server. What I >> don't know is how you add trust in NSS for a self-signed server >> certificate. You might be best off issuing new SSL certs for your openldap >> server which uses a CA to issue the server cert in order to perform the >> migration. >> >> rob >> >> >>> Regards >>> >>> John >>> >>> >>> On Mon, Jan 14, 2013 at 9:19 AM, Johnathan Phan >> > wrote: >>> >>> Hi Aquino, >>> >>> thanks for the input, however. There is a CRT in there already and >>> it was set to allow on both the IPA server and the target openldap >>> server. >>> the core of the issue seems to be that IPA does not accept the cert >>> either locally or remotely as it does not trust it. >>> >>> anyone know how I can troubleshot this. I have reviewed the dirsrv >>> logs for ldap and I can't spot anything/. >>> >>> Regards >>> John >>> >>> >>> On Fri, Jan 11, 2013 at 5:55 PM, JR Aquino >> > wrote: >>> >>> Try editing /etc/openldap/ldap.conf: >>> >>> TLS_CACERT /etc/ipa/ca.crt >>> TLS_REQCERT allow >>> >>> >>> See if that helps >>> >>> "Keeping your head in the cloud" >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~**~~~~~~~ >>> Jr Aquino | Sr. Information Security Specialist >>> GIAC Exploit Researcher and Advanced Penetration Tester | >>> GIAC Certified Incident Handler | GIAC WebApp Penetration Tester >>> Citrix Online | 7408 Hollister Avenue | Goleta, CA >>> 93117 >>> T: +1 805.690.3478 >>> >>> C: +1 805.717.0365 >> +1%20805.717.0365> >>> jr.aquino at citrix.com >>> <**mailto:jr.aquino at citrixonline.** >>> com >>> >>> >>> >> >>> http://www.citrixonline.com >>> > >>> >>> On Jan 11, 2013, at 8:05 AM, Johnathan Phan >>> >> >> com >>> >>> >> wrote: >>> >>> Hi There, >>> >>> This is driving me up the wall. >>> >>> I have two servers. 1 is a live openldap/kerberous AAA server >>> running on RHEL6. The LDAP service has SSL/TS support. The >>> second server is a test environment running on fedora and has >>> 3.1 IPA installed. >>> >>> As a last step of my POC I need to migrate the users and >>> passwords from the LDAP server to IPA server. >>> >>> I ran this command perfectly fine. >>> >>> ipa config-mod --enable-migration=TRUE >>> >>> However the next step was where my issues began. >>> >>> In the end after a lot of IRC communication and troubleshooting >>> I now run the following command. >>> >>> ipa migrate-ds --bind-dn="cn=admin,dc=**example,dc=com" >>> --user-container="ou=users,ou=**live,dc=example,dc=com" >>> --group-container="ou=groups,**ou=live,dc=example,dc=com" >>> ldaps://ldap1.live.example.com >>> >> com/ > >>> >>> >>> I get the following error. >>> >>> ipa: DEBUG: Caught fault 4203 from server >>> http://fedoraipaserver.test.**example.com/ipa/xml: >>> Can't contact >>> LDAP server: TLS error -8179:Peer's Certificate issuer is not >>> recognized. >>> ipa: DEBUG: Destroyed connection context.xmlclient >>> ipa: ERROR: Can't contact LDAP server: TLS error -8179:Peer's >>> Certificate issuer is not recognized. >>> >>> I have summarized that the IPA server does not trust the cert >>> served by the openldap or the other way around. Does anyone know >>> how to get around this? Or allow me to finish the migration of >>> user data. >>> >>> Regards >>> >>> John >>> >>> -- >>> Johnathan Phan >>> >>> T: +44 (0)784 118 7080 >>> >>> >>> >>> >>> ______________________________**_________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> >>> > >> Freeipa-users at redhat.**com >> >>> >>> https://www.redhat.com/**mailman/listinfo/freeipa-users >>> >>> >>> >>> >>> -- >>> Johnathan Phan >>> ox-consulting >>> >>> >>> T: +44 (0)784 118 7080 >>> john at ox-consulting.com >>> >>> www.ox-consulting.com >>> >>> >>> OX CONSULTING Ltd is registered in England & Wales, number: >>> 07113039, registered address as above. >>> >>> The information contained in this email message may be privileged, >>> confidential or exempt from disclosure under applicable law. If you >>> are not the intended recipient, you are hereby notified that any >>> use, dissemination, distribution or copying of this transmission is >>> strictly prohibited. If you have received this communication in >>> error, or if any problems occur with transmission, please notify the >>> sender immediately. >>> >>> >>> >>> >>> -- >>> Johnathan Phan >>> ox-consulting >>> >>> T: +44 (0)784 118 7080 >>> john at ox-consulting.com >>> >>> www.ox-consulting.com >>> >>> >>> OX CONSULTING Ltd is registered in England & Wales, number: 07113039, >>> registered address as above. >>> >>> The information contained in this email message may be privileged, >>> confidential or exempt from disclosure under applicable law. If you are >>> not the intended recipient, you are hereby notified that any use, >>> dissemination, distribution or copying of this transmission is strictly >>> prohibited. If you have received this communication in error, or if any >>> problems occur with transmission, please notify the sender immediately. >>> >>> >>> ______________________________**_________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/**mailman/listinfo/freeipa-users >>> >>> >> > > > -- > Johnathan Phan > ox-consulting > > T: +44 (0)784 118 7080 > john at ox-consulting.com > > www.ox-consulting.com > > > OX CONSULTING Ltd is registered in England & Wales, number: 07113039, > registered address as above. > > The information contained in this email message may be privileged, > confidential or exempt from disclosure under applicable law. If you are not > the intended recipient, you are hereby notified that any use, > dissemination, distribution or copying of this transmission is strictly > prohibited. If you have received this communication in error, or if any > problems occur with transmission, please notify the sender immediately. > -- Johnathan Phan ox-consulting T: +44 (0)784 118 7080 john at ox-consulting.com www.ox-consulting.com OX CONSULTING Ltd is registered in England & Wales, number: 07113039, registered address as above. The information contained in this email message may be privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this transmission is strictly prohibited. If you have received this communication in error, or if any problems occur with transmission, please notify the sender immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at ox-consulting.com Wed Jan 23 10:11:04 2013 From: john at ox-consulting.com (Johnathan Phan) Date: Wed, 23 Jan 2013 10:11:04 +0000 Subject: [Freeipa-users] missing objects during migration steps Message-ID: Hi everyone, k pass authentication issues now. It's now complaining about objects not there. ipa: ERROR: uri=ldaps://ldap1.example.com:636: Unable to retrieve LDAP schema: No such object: However when I run the following commands on the new IPA server. ldapsearch -x -H ldaps://ldap.example.com:636 -b ou=groups,ou=live,dc=example,dc=com -D "cn=admin,dc=example,dc=com" -W or ldapsearch -x -H ldaps://ldap.example.com:636 -b ou=ib,dc=example,dc=com -D "cn=admin,dc=example,dc=com" -W and I get output Ldap shows the users and groups in the old system. It just dumps out the whole content of the OU. I have tried to run the following two commands and I still get the same error ipa migrate-ds --bind-dn="cn=admin,dc=example,dc=com" --user-container="ou=ib,dc=example,dc=com" ldaps://ldap1.example.com:636 or ipa migrate-ds --bind-dn="cn=admin,dc=example,dc=com" --user-container="ou=ib,dc=example,dc=com" --group-container="ou=groups,ou=live,dc=example,dc=com" ldaps:// ldap1.example.com:636 What is IPA complaining about specifically? I know objects are in these ou's Is it expecting something different? Regards John -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Jan 23 10:20:41 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 23 Jan 2013 12:20:41 +0200 Subject: [Freeipa-users] Some interrogations about the freeipa deployment In-Reply-To: <20130122205133.242570@gmx.com> References: <20130122205133.242570@gmx.com> Message-ID: <20130123102041.GH4474@redhat.com> On Tue, 22 Jan 2013, Bob Sauvage wrote: >Hi *, > > I plan to review the network architecture of my office. 10 > Windows/Linux desktops and 2 Linux servers will be deployed on the > network. > > I want to install freeipa on the first server to act like an AD DS. I Just to make sure we are using same terms, are you talking about Active Directory Directory Service or Active Directory Domain Controller? The latter mode (being an AD DC for Windows clients) is not supported by FreeIPA v3.0/3.1. The former mode is supported to the level of Kerberos authentication. You would be able to configure MIT Kerberos for Windows to authenticate against FreeIPA and use those tickets against Linux resources. However, Windows servers will not be able to provide authenticated access using those tickets since they would not be able to assign access rights to any FreeIPA user due to missing identity information as required by Windows. You could get around of the issue by manually mapping appropriate Kerberos identities to local Windows users on each machine. -- / Alexander Bokovoy From jhrozek at redhat.com Wed Jan 23 13:59:05 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 23 Jan 2013 14:59:05 +0100 Subject: [Freeipa-users] A security bug in SSSD 1.8 and 1.9 (CVE-2013-0220) Message-ID: <20130123135905.GA17619@hendrix.brq.redhat.com> ================= A security bug in SSSD 1.8 and 1.9 =============== = = Subject: out-of-bounds reads in autofs and ssh responder = = CVE ID#: CVE-2013-0220 = = Summary: Multiple out-of-bounds buffer read flaws were found in = the way the autofs and ssh responders of the SSSD = performed the parsing of input packet values. An attacker = could crash the autofs and ssh responders with the use = of a carefully crafted packet written to the responder = sockets. = = = Impact: low = = Acknowledgements: The bug was found by Florian Weimer of the Red Hat = Product Security team = = Affects default = configuration: yes (as generated by ipa-client-install) = = Introduced with: 1.8.0 = =============================================================== ==== DESCRIPTION ==== SSSD versions 1.8.0 through 1.9.3 are vulnerable to a security bug. The functions that parse the incoming data packet from client applications in both the ssh and autofs responders do not check the string lengths against the packet length correctly. An attacker could exploit the bug and crash the autofs or the ssh responder with the use of a specially crafted packet sent to the responder sockets, causing a temporary denial of service. If you are not using the autofs or SSH integration, you can disable the vulnerable responders by removing "ssh" or "autofs" respectively from the list of services configured in the [sssd] section of the SSSD config file. The default configuration of a client of FreeIPA - as generated by ipa-client-install - is affected because the ssh responder is enabled by default. The fix will be delivered as part of the upcoming 1.9.4 release. There won't be a separate 1.9 security release as the 1.9.4 version will be released later this week. The flaw will be fixed in a separate release for the 1.8 and 1.5 LTM releases as well. The bug is being tracked in the following Red Hat Bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=884601 ==== PATCH AVAILABILITY ==== The patch is available at: http://git.fedorahosted.org/cgit/sssd.git/patch/?id=2bd514cfde1938b1e245af11c9b548d58d49b325 From rcritten at redhat.com Wed Jan 23 14:00:33 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Jan 2013 09:00:33 -0500 Subject: [Freeipa-users] missing objects during migration steps In-Reply-To: References: Message-ID: <50FFED01.8000208@redhat.com> Johnathan Phan wrote: > Hi everyone, > > k pass authentication issues now. It's now complaining about objects not > there. > > ipa: ERROR: uri=ldaps://ldap1.example.com:636 > : Unable to retrieve LDAP schema: No such > object: > > However when I run the following commands on the new IPA server. > > ldapsearch -x -H ldaps://ldap.example.com:636 > -b ou=groups,ou=live,dc=example,dc=com -D > "cn=admin,dc=example,dc=com" -W > > or > > ldapsearch -x -H ldaps://ldap.example.com:636 > -b ou=ib,dc=example,dc=com -D > "cn=admin,dc=example,dc=com" -W and I get output > > Ldap shows the users and groups in the old system. It just dumps out the > whole content of the OU. > > I have tried to run the following two commands and I still get the same > error > > ipa migrate-ds --bind-dn="cn=admin,dc=example,dc=com" > --user-container="ou=ib,dc=example,dc=com" ldaps://ldap1.example.com:636 > > > or > > ipa migrate-ds --bind-dn="cn=admin,dc=example,dc=com" > --user-container="ou=ib,dc=example,dc=com" > --group-container="ou=groups,ou=live,dc=example,dc=com" > ldaps://ldap1.example.com:636 > > What is IPA complaining about specifically? I know objects are in these > ou's Is it expecting something different? It is failing trying to query cn=schema. We fetch the schema from the remote server to know what types of data we're dealing with. What version of openldap is this? rob From john at ox-consulting.com Wed Jan 23 14:27:22 2013 From: john at ox-consulting.com (Johnathan Phan) Date: Wed, 23 Jan 2013 14:27:22 +0000 Subject: [Freeipa-users] missing objects during migration steps In-Reply-To: <50FFED01.8000208@redhat.com> References: <50FFED01.8000208@redhat.com> Message-ID: Hi Rob, Please find the output from /usr/sbin/slapd -VV that shows the current openldap version thats running on the ldap server. @(#) $OpenLDAP: slapd 2.4.23 (Jul 31 2012 10:47:00) $ mockbuild at x86-001.build.bos.redhat.com: /builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd ps. I have opened a ticket for this. https://fedorahosted.org/freeipa/ticket/3372 Can I assume you have a away to turn this check off. As in IRC there does not seem to be one. Or are you saying I can allow the scheme value to be checked if I create one or make it readable some how? On Wed, Jan 23, 2013 at 2:00 PM, Rob Crittenden wrote: > Johnathan Phan wrote: > >> Hi everyone, >> >> k pass authentication issues now. It's now complaining about objects not >> there. >> >> ipa: ERROR: uri=ldaps://ldap1.example.com:**636 >> **: Unable to retrieve LDAP schema: No such >> >> object: >> >> However when I run the following commands on the new IPA server. >> >> ldapsearch -x -H ldaps://ldap.example.com:636 >> -b ou=groups,ou=live,dc=example,**dc=com -D >> >> "cn=admin,dc=example,dc=com" -W >> >> or >> >> ldapsearch -x -H ldaps://ldap.example.com:636 >> -b ou=ib,dc=example,dc=com -D >> >> "cn=admin,dc=example,dc=com" -W and I get output >> >> Ldap shows the users and groups in the old system. It just dumps out the >> whole content of the OU. >> >> I have tried to run the following two commands and I still get the same >> error >> >> ipa migrate-ds --bind-dn="cn=admin,dc=**example,dc=com" >> --user-container="ou=ib,dc=**example,dc=com" ldaps:// >> ldap1.example.com:636 >> >> >> >> or >> >> ipa migrate-ds --bind-dn="cn=admin,dc=**example,dc=com" >> --user-container="ou=ib,dc=**example,dc=com" >> --group-container="ou=groups,**ou=live,dc=example,dc=com" >> ldaps://ldap1.example.com:636 >> >> >> What is IPA complaining about specifically? I know objects are in these >> ou's Is it expecting something different? >> > > It is failing trying to query cn=schema. We fetch the schema from the > remote server to know what types of data we're dealing with. What version > of openldap is this? > > rob > > -- Johnathan Phan ox-consulting T: +44 (0)784 118 7080 john at ox-consulting.com www.ox-consulting.com OX CONSULTING Ltd is registered in England & Wales, number: 07113039, registered address as above. The information contained in this email message may be privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this transmission is strictly prohibited. If you have received this communication in error, or if any problems occur with transmission, please notify the sender immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.joseph at lmco.com Wed Jan 23 15:16:41 2013 From: matthew.joseph at lmco.com (Joseph, Matthew (EXP)) Date: Wed, 23 Jan 2013 10:16:41 -0500 Subject: [Freeipa-users] EXTERNAL: Re: OneWaySync Issues In-Reply-To: <50FEE2A3.8010506@redhat.com> References: <543FB8F8BFD9A74298A96670DA2F2E7F0DD00E5114@HCXMSP1.ca.lmco.com> <50FEDE91.1090909@redhat.com> <50FEE2A3.8010506@redhat.com> Message-ID: <543FB8F8BFD9A74298A96670DA2F2E7F0DD00E5427@HCXMSP1.ca.lmco.com> Hey, So if I remove the IPA Password Sync user from the Account Operators then delete a user from IPA it won't replicate to Active Directory. When I create a user on the Active Directory side it will replicate it to IPA. So I started testing out the password sync to see if that will work but I am not having any luck with it (even when our password sync user on the windows side is added to Account Operators). I think I know the issue but I am having trouble finding out the back end of the IPA Directory structure. In the /var/log/dirsrv/slapd****/errors file the last few lines say the follow. Ipalockout_preop - [file ipa_lockout.c, line 527] Failed to retrieve entry "uid=passsyncuser,cn=sysaccounts,cn=etc,dc=ad,dc=ca" : 32 >From looking at that I assume the passsync user I created on the IPA side does not live under the sysaccounts CN. So I guess what I'm looking for is the backend structure of how the users are setup. Does his entry in the backend of IPA actually look like this; uid=passsyncuser,cn=users,dc=ipadomain,dc=ca Thanks, Matt -----Original Message----- From: Rich Megginson [mailto:rmeggins at redhat.com] Sent: Tuesday, January 22, 2013 3:04 PM To: Rob Crittenden Cc: Joseph, Matthew (EXP); freeipa-users at redhat.com Subject: EXTERNAL: Re: [Freeipa-users] OneWaySync Issues On 01/22/2013 11:46 AM, Rob Crittenden wrote: > Joseph, Matthew (EXP) wrote: >> Hello, >> >> I'm trying to configure the oneWaySync option for IPA so only the >> Windows AD can replicate changes to IPA. >> >> When I use the command that I listed below it says it works but when I >> delete a user form IPA it will then delete the user in Active Directory. >> >> Is my command listed below correct? Anyone able to help? >> >> Parameters: >> Server = rhserver >> Domain = redhat.ca >> Password = 12345678 >> >> Contents of /tmp/unisync; >> dn: cn=ipa-winsync,cn=plugins,cn=config >> changetype: modify >> replace: oneWaySync >> oneWaySync: From Windows >> >> So I enter the following command; >> *ldapmodify -x -D "dc=redhat,dc=ca" -w 12345678 -h rhserver.redhat.ca -f >> /tmp/unisync* > > There should be no space in oneWaySync, it should be fromWindows. I thought the oneWaySync attribute was in the replication/sync agreement entry, not in the ipa-winsync plugin config entry? > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Wed Jan 23 15:41:00 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Jan 2013 10:41:00 -0500 Subject: [Freeipa-users] missing objects during migration steps In-Reply-To: References: <50FFED01.8000208@redhat.com> Message-ID: <5100048C.1030402@redhat.com> Johnathan Phan wrote: > Hi Rob, > > Please find the output from /usr/sbin/slapd -VV that shows the current > openldap version thats running on the ldap server. > > @(#) $OpenLDAP: slapd 2.4.23 (Jul 31 2012 10:47:00) $ > > mockbuild at x86-001.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd > > ps. I have opened a ticket for this. > > https://fedorahosted.org/freeipa/ticket/3372 > > Can I assume you have a away to turn this check off. As in IRC there > does not seem to be one. Or are you saying I can allow the scheme value > to be checked if I create one or make it readable some how? There is no way to turn this check off, we always try to retrieve cn=schema. I'd have sworn that openldap already did online schema this way. rob From simo at redhat.com Wed Jan 23 16:14:14 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 23 Jan 2013 11:14:14 -0500 Subject: [Freeipa-users] missing objects during migration steps In-Reply-To: <5100048C.1030402@redhat.com> References: <50FFED01.8000208@redhat.com> <5100048C.1030402@redhat.com> Message-ID: <1358957654.20683.372.camel@willson.li.ssimo.org> On Wed, 2013-01-23 at 10:41 -0500, Rob Crittenden wrote: > Johnathan Phan wrote: > > Hi Rob, > > > > Please find the output from /usr/sbin/slapd -VV that shows the current > > openldap version thats running on the ldap server. > > > > @(#) $OpenLDAP: slapd 2.4.23 (Jul 31 2012 10:47:00) $ > > > > mockbuild at x86-001.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd > > > > ps. I have opened a ticket for this. > > > > https://fedorahosted.org/freeipa/ticket/3372 > > > > Can I assume you have a away to turn this check off. As in IRC there > > does not seem to be one. Or are you saying I can allow the scheme value > > to be checked if I create one or make it readable some how? > > There is no way to turn this check off, we always try to retrieve cn=schema. > > I'd have sworn that openldap already did online schema this way. Please open a bug, we should no depend on the remote schema being readable. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Jan 23 16:42:50 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Jan 2013 11:42:50 -0500 Subject: [Freeipa-users] missing objects during migration steps In-Reply-To: <1358957654.20683.372.camel@willson.li.ssimo.org> References: <50FFED01.8000208@redhat.com> <5100048C.1030402@redhat.com> <1358957654.20683.372.camel@willson.li.ssimo.org> Message-ID: <5100130A.6050007@redhat.com> Simo Sorce wrote: > On Wed, 2013-01-23 at 10:41 -0500, Rob Crittenden wrote: >> Johnathan Phan wrote: >>> Hi Rob, >>> >>> Please find the output from /usr/sbin/slapd -VV that shows the current >>> openldap version thats running on the ldap server. >>> >>> @(#) $OpenLDAP: slapd 2.4.23 (Jul 31 2012 10:47:00) $ >>> >>> mockbuild at x86-001.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd >>> >>> ps. I have opened a ticket for this. >>> >>> https://fedorahosted.org/freeipa/ticket/3372 >>> >>> Can I assume you have a away to turn this check off. As in IRC there >>> does not seem to be one. Or are you saying I can allow the scheme value >>> to be checked if I create one or make it readable some how? >> >> There is no way to turn this check off, we always try to retrieve cn=schema. >> >> I'd have sworn that openldap already did online schema this way. > > Please open a bug, we should no depend on the remote schema being > readable. > > Simo. > He already opened a ticket. rob From jhrozek at redhat.com Wed Jan 23 18:11:59 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 23 Jan 2013 19:11:59 +0100 Subject: [Freeipa-users] A security bug in SSSD (CVE-2013-0219) Message-ID: <20130123181159.GH17619@hendrix.brq.redhat.com> ======================== A security bug in SSSD =============== = = Subject: TOCTOU race conditions when creating or removing home = directories for users in local domain = = CVE ID#: CVE-2013-0219 = = Summary: A TOCTOU (time-of-check, time-of-use) race condition was found = in the way SSSD performed copying and removal of home = directory trees. = = = Impact: low = = Acknowledgements: The bug was found by Florian Weimer of the Red Hat = Product Security Team = = Affects default = configuration: no = = Introduced with: 0.7.0 = =============================================================== ==== DESCRIPTION ==== SSSD versions 0.7.0 through 1.9.3 (inclusive) are vulnerable to a security bug. The removal of a home directory is sensitive to concurrent modification of the directory tree being removed and can unlink files outside the directory tree. When removing a home directory, if another process is modifying that directory at the same time, it becomes possible for the SSSD to unlink files that are outside the directory tree. When creating a home directory, the destination tree can be modified in various ways while it is being constructed because directory permissions are set before populating the directory. This can lead to file creation and permission changes outside the target directory tree using hard links. The fix will be delivered as part of the upcoming 1.9.4 release. There won't be a separate 1.9 security release as the 1.9.4 version will be released later this week. The flaw will be fixed in a separate release for the 1.8 and 1.5 LTM release branches as well. The bug is being tracked in the following Red Hat Bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=884254 ==== WORKAROUND ==== These vulnerabilities are present only while creating or removing home directories, so until patched packages are available, you can simply refrain from performing these actions. ==== PATCH AVAILABILITY ==== The patches are available at: http://git.fedorahosted.org/cgit/sssd.git/patch/?id=94cbf1cfb0f88c967f1fb0a4cf23723148868e4a http://git.fedorahosted.org/cgit/sssd.git/patch/?id=020bf88fd1c5bdac8fc671b37c7118f5378c7047 From shelltoesuperstar at gmail.com Wed Jan 23 18:56:08 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Wed, 23 Jan 2013 18:56:08 +0000 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> Message-ID: Hi My team and I have been around this a few times and as far as we can see the best and simplest way to make this work is if we enrol once and back up all the relevant bits of information so in the event of a rebuild we can restore the necessary components and make it appear to the IPA server that it had never left. Disabling and re-enrolling was the preferred option initially but it seems there are too many issues to make this viable going forward. - How to allow developers/administrators/robots access securely between the disabling the host and re-enrolment (to say reboot the server for PXEboot) - Having to grant users permission to enrol servers even when they only need to re-provision existing servers. - OTP reuse being disabled preventing something simple like the hostname of the server being used during re-enrolment - The lack of a reusable OTP also makes the process two-step (see Fred's mail) rather than the single step we previously had. To that end could someone please tell us or document all the steps required to back up the key ipa-client files so we can get past these problems and move onto the more interesting things that the IPA server can provide. Any effort to simplify the backup and restore process within an IPA client (and the server for that matter) would also be greatly appreciated. Regards, Charlie. On Fri, Jan 18, 2013 at 8:14 PM, Fred van Zwieten wrote: > Dmitri, > > Sure I can do this. I can make a script, and have this executed from > Satellite (remote command) and than perform the server redeploy from > Satellite. However, that makes it a two step process, and that is what I > now also have. However, I would like to make it fully automated in a single > step. > > Come to think of it...there is also an api for Satellite. Maybe I can make > a script that will first do the IPA stuff and then call Satellite to > redeploy the server..... > ....hmmm....will look into this...and report my findings > > > Met vriendelijke groeten, > * > Fred van Zwieten > * > *Enterprise Open Source Services* > * > Consultant* > *(vrijdags afwezig)* > > *VX Company IT Services B.V.* > *T* (035) 539 09 50 mobiel (06) 41 68 28 48 > *F* (035) 539 09 08 > *E* fvzwieten at vxcompany.com > *I* www.vxcompany.com > > > On Fri, Jan 18, 2013 at 6:09 PM, Dmitri Pal wrote: > >> On 01/18/2013 06:52 AM, Fred van Zwieten wrote: >> >> Hi Dmitri, >> >> Sorry for the late reply. I basically want to do the same as Charlie >> Derwent in another tread on this mailing list: To fully automate the >> re-installation of a server using Satellite/Spacewalk using kickstart. As >> the server is an IPA client, it must first get to be un-enrolled, before an >> ipa-client-install --unattened -w secret etc. can be done in a %post >> snippet of the kickstart file. It is the automation of the unenrollment >> proces that we are not able to set up. >> >> What I can do on any ipa-client to unenroll on the command line is: >> >> ipa --disable-host and ipa host-mod --password=secret --ssh= >> >> This unprovisions the client, set's an OTP and removes the host ssh >> keys. >> >> However, this can only be done on an IPA client, and during a kickstart >> install the server is no longer an IPA client, because it is freshly being >> set up. >> >> It's a typical chicken-and-egg issue. You must first be ipa client to >> be able to execute ipa commands, but you cannot become an ipa client before >> unprovisioning yourself using those same ipa commands. >> >> Another approuch would be to unprovision the client just before the >> reboot to be kickstarted, however, I have no idea how to set that up. It >> would mean the server has to know somehow it is being rebooted because of a >> re-install, but afaik, there is no way for satellite/spacewalk to tell the >> server this.. >> >> Regards, >> >> Fred >> >> >> IMO the right approach would be for the Satellite server to perform "ipa >> --disable-host and ipa host-mod --password=secret --ssh=" as a >> part of the re-installation. >> Satellite should be given an IPA identity and call into IPA when it >> performs reinstall before rebooting the system. >> >> Tough... I will see what I can do. >> >> >> >> >> >> >> On Sat, Jan 12, 2013 at 10:06 PM, Dmitri Pal wrote: >> >>> On 01/12/2013 03:28 AM, Fred van Zwieten wrote: >>> >>> Hi there, >>> >>> We are in the process of implementing Satellite and want to automate >>> server installations 100% using kickstart, cobbler, satellite. >>> >>> IPA clients can be scripted enrolled using kickstart. Plenty of >>> documentation about that. >>> >>> However, how to "re"-enroll IPA clients? >>> >>> Satellite gives me the option to re-install a server. In this case, >>> there are still host and possibly service records for this host present in >>> IPA and DNS. >>> >>> One way to think about this is, that it's actually OK to keep those >>> records there, because it is a "re"-installation, so why remove and >>> re-enroll? However, there is the krb5.keytab in /etc. I could save that >>> file during redeployment, but I'm not sure if that will work. And iare >>> there any other gotcha's. >>> >>> So, the question is, how to re-install an IPA client using kickstart >>> (silent re-install)? >>> >>> >>> The question is how/do you remove the client? >>> Based on what you say above you use the same system so there are some >>> leftovers. If you can run ipa-client-install --uninstall it should clean >>> things like keytab and certs (there have been bugs fixed in freeIPA 3.0). >>> If the client has access to the server it will clean (not remove) the host >>> entry too. Then you can re-run the install. If you use OTP you would need >>> to reset OTP first. >>> >>> >>> Regards, >>> >>> Fred >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://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/ >>> >>> >> >> >> -- >> 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 at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Jan 23 19:56:31 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 23 Jan 2013 14:56:31 -0500 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> Message-ID: <5100406F.7040101@redhat.com> On 01/23/2013 01:56 PM, Charlie Derwent wrote: > Hi > > My team and I have been around this a few times and as far as we can > see the best and simplest way to make this work is if we enrol once > and back up all the relevant bits of information so in the event of a > rebuild we can restore the necessary components and make it appear to > the IPA server that it had never left. > > Disabling and re-enrolling was the preferred option initially but it > seems there are too many issues to make this viable going forward. > > * How to allow developers/administrators/robots access securely > between the disabling the host and re-enrolment (to say reboot the > server for PXEboot) > * Having to grant users permission to enrol servers even when they > only need to re-provision existing servers. > * OTP reuse being disabled preventing something simple like the > hostname of the server being used during re-enrolment > * The lack of a reusable OTP also makes the process two-step (see > Fred's mail) rather than the single step we previously had. > > To that end could someone please tell us or document all the steps > required to back up the key ipa-client files so we can get past these > problems and move onto the more interesting things that the IPA server > can provide. > > Any effort to simplify the backup and restore process within an IPA > client (and the server for that matter) would also be greatly appreciated. > I suspect you opened the ticket: https://fedorahosted.org/freeipa/ticket/3373 Anyways I replied in the ticket and I am pasting it here: Making OTP reusable defeats the purpose of the OTP. It becomes just another password. If you want this you can create an account in IPA, limit its privileges to just host enrollment and use the password associated with this account to re-provision systems. Would that solve the problem for you? If the backup seems like a good option I suggest we open an RFE to allow re-enrolling a host using keytab. I can file an RFE for it. What it would do is: add an argument to ipa-client-install to use keytab instead of OTP or password if you saved one. If the authentication successful the client will reconfigure the system once again. Would that solve the problem? I do not like the full backup idea as it is not consistent between the versions. Say you redeploy but with the updated version of software that changed something and config files from the previous version are not 100% the same. Things would break. And depending upon the commands you used we touch different files as SSSD can now be integrated with autofs, ssh, sudo. I am just not sure that backup and restore is really a sustainable approach project/product wise. We can probably craft a list but I am scared promoting it as a solution. > Regards, > Charlie. > > > > > > > > > > > > > > > > > > > > On Fri, Jan 18, 2013 at 8:14 PM, Fred van Zwieten > > wrote: > > Dmitri, > > Sure I can do this. I can make a script, and have this executed > from Satellite (remote command) and than perform the server > redeploy from Satellite. However, that makes it a two step > process, and that is what I now also have. However, I would like > to make it fully automated in a single step. > > Come to think of it...there is also an api for Satellite. Maybe I > can make a script that will first do the IPA stuff and then call > Satellite to redeploy the server..... > ....hmmm....will look into this...and report my findings > > > Met vriendelijke groeten, > * > Fred van Zwieten > * > *Enterprise Open Source Services* > * > Consultant* > /(vrijdags afwezig)/ > > *VX Company IT Services B.V.* > *T* (035) 539 09 50 mobiel (06) 41 68 28 48 > *F* (035) 539 09 08 > *E* fvzwieten at vxcompany.com > *I* www.vxcompany.com > > > On Fri, Jan 18, 2013 at 6:09 PM, Dmitri Pal > wrote: > > On 01/18/2013 06:52 AM, Fred van Zwieten wrote: >> Hi Dmitri, >> >> Sorry for the late reply. I basically want to do the same as >> Charlie Derwent in another tread on this mailing list: To >> fully automate the re-installation of a server using >> Satellite/Spacewalk using kickstart. As the server is an IPA >> client, it must first get to be un-enrolled, before an >> ipa-client-install --unattened -w secret etc. can be done in >> a %post snippet of the kickstart file. It is the automation >> of the unenrollment proces that we are not able to set up. >> >> What I can do on any ipa-client to unenroll on the command >> line is: >> >> ipa --disable-host and ipa host-mod >> --password=secret --ssh= >> >> This unprovisions the client, set's an OTP and removes the >> host ssh keys. >> >> However, this can only be done on an IPA client, and during a >> kickstart install the server is no longer an IPA client, >> because it is freshly being set up. >> >> It's a typical chicken-and-egg issue. You must first be ipa >> client to be able to execute ipa commands, but you cannot >> become an ipa client before unprovisioning yourself using >> those same ipa commands. >> >> Another approuch would be to unprovision the client just >> before the reboot to be kickstarted, however, I have no idea >> how to set that up. It would mean the server has to know >> somehow it is being rebooted because of a re-install, but >> afaik, there is no way for satellite/spacewalk to tell the >> server this.. >> >> Regards, >> >> Fred > > IMO the right approach would be for the Satellite server to > perform "ipa --disable-host and ipa host-mod > --password=secret --ssh=" as a part of the re-installation. > Satellite should be given an IPA identity and call into IPA > when it performs reinstall before rebooting the system. > > Tough... I will see what I can do. > > >> >> >> >> >> On Sat, Jan 12, 2013 at 10:06 PM, Dmitri Pal > > wrote: >> >> On 01/12/2013 03:28 AM, Fred van Zwieten wrote: >>> Hi there, >>> >>> We are in the process of implementing Satellite and want >>> to automate server installations 100% using kickstart, >>> cobbler, satellite. >>> >>> IPA clients can be scripted enrolled using kickstart. >>> Plenty of documentation about that. >>> >>> However, how to "re"-enroll IPA clients? >>> >>> Satellite gives me the option to re-install a server. In >>> this case, there are still host and possibly service >>> records for this host present in IPA and DNS. >>> >>> One way to think about this is, that it's actually OK to >>> keep those records there, because it is a >>> "re"-installation, so why remove and re-enroll? However, >>> there is the krb5.keytab in /etc. I could save that file >>> during redeployment, but I'm not sure if that will work. >>> And iare there any other gotcha's. >>> >>> So, the question is, how to re-install an IPA client >>> using kickstart (silent re-install)? >> >> The question is how/do you remove the client? >> Based on what you say above you use the same system so >> there are some leftovers. If you can run >> ipa-client-install --uninstall it should clean things >> like keytab and certs (there have been bugs fixed in >> freeIPA 3.0). If the client has access to the server it >> will clean (not remove) the host entry too. Then you can >> re-run the install. If you use OTP you would need to >> reset OTP first. >> >>> >>> Regards, >>> >>> Fred >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at 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/ >> >> >> > > > -- > 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 at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Wed Jan 23 20:45:40 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 23 Jan 2013 13:45:40 -0700 Subject: [Freeipa-users] using wildcard or other external CA certs In-Reply-To: <51004B54.2070403@redhat.com> References: <050.da800267d7b7e77bce0964839c3d1163@fedorahosted.org> <51004B54.2070403@redhat.com> Message-ID: <51004BF4.5040701@cora.nwra.com> On 01/23/2013 01:43 PM, Dmitri Pal wrote: > Yes please. Let us do it on the user list. > > Ticket URL: So, my goal in using a wildcard cert signed by a "well known" CA was to be able to avoid installing the IPA CA in clients like Thunderbird and Firefox. Thoughts, comments, suggestions? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From fvzwieten at vxcompany.com Wed Jan 23 20:24:47 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Wed, 23 Jan 2013 21:24:47 +0100 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: <5100406F.7040101@redhat.com> References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> Message-ID: Dmitri, If I understand correcty this would mean I backup the keytab before reinstall en restore it after (easily done with Satellite), then do a ipa-client-install using the keytab. Does this mean the host record in IPA will never change during this process? Sounds good to me. This makes reinstalling a one-step process. When the ssh keys are not preserved during reinstall they must be refreshed in IPA, will ipa-client-install do that too in this case? Fred On Wed, Jan 23, 2013 at 8:56 PM, Dmitri Pal wrote: > On 01/23/2013 01:56 PM, Charlie Derwent wrote: > > Hi > > My team and I have been around this a few times and as far as we can see > the best and simplest way to make this work is if we enrol once and back up > all the relevant bits of information so in the event of a rebuild we can > restore the necessary components and make it appear to the IPA server that > it had never left. > > Disabling and re-enrolling was the preferred option initially but it seems > there are too many issues to make this viable going forward. > > - How to allow developers/administrators/robots access securely > between the disabling the host and re-enrolment (to say reboot the server > for PXEboot) > - Having to grant users permission to enrol servers even when they > only need to re-provision existing servers. > - OTP reuse being disabled preventing something simple like the > hostname of the server being used during re-enrolment > - The lack of a reusable OTP also makes the process two-step (see > Fred's mail) rather than the single step we previously had. > > To that end could someone please tell us or document all the steps > required to back up the key ipa-client files so we can get past these > problems and move onto the more interesting things that the IPA server > can provide. > > Any effort to simplify the backup and restore process within an IPA > client (and the server for that matter) would also be greatly appreciated. > > > I suspect you opened the ticket: > https://fedorahosted.org/freeipa/ticket/3373 > Anyways I replied in the ticket and I am pasting it here: > Making OTP reusable defeats the purpose of the OTP. It becomes just > another password. If you want this you can create an account in IPA, limit > its privileges to just host enrollment and use the password associated with > this account to re-provision systems. Would that solve the problem for you? > > If the backup seems like a good option I suggest we open an RFE to allow > re-enrolling a host using keytab. > I can file an RFE for it. What it would do is: add an argument to > ipa-client-install to use keytab instead of OTP or password if you saved > one. If the authentication successful the client will reconfigure the > system once again. > > Would that solve the problem? > > I do not like the full backup idea as it is not consistent between the > versions. Say you redeploy but with the updated version of software that > changed something and config files from the previous version are not 100% > the same. Things would break. > And depending upon the commands you used we touch different files as SSSD > can now be integrated with autofs, ssh, sudo. > I am just not sure that backup and restore is really a sustainable > approach project/product wise. > We can probably craft a list but I am scared promoting it as a solution. > > > Regards, > Charlie. > > > > > > > > > > > > > > > > > > > > On Fri, Jan 18, 2013 at 8:14 PM, Fred van Zwieten > wrote: > >> Dmitri, >> >> Sure I can do this. I can make a script, and have this executed from >> Satellite (remote command) and than perform the server redeploy from >> Satellite. However, that makes it a two step process, and that is what I >> now also have. However, I would like to make it fully automated in a single >> step. >> >> Come to think of it...there is also an api for Satellite. Maybe I can >> make a script that will first do the IPA stuff and then call Satellite to >> redeploy the server..... >> ....hmmm....will look into this...and report my findings >> >> >> Met vriendelijke groeten, >> * >> Fred van Zwieten >> * >> *Enterprise Open Source Services* >> * >> Consultant* >> *(vrijdags afwezig)* >> >> *VX Company IT Services B.V.* >> *T* (035) 539 09 50 mobiel (06) 41 68 28 48 >> *F* (035) 539 09 08 >> *E* fvzwieten at vxcompany.com >> *I* www.vxcompany.com >> >> >> On Fri, Jan 18, 2013 at 6:09 PM, Dmitri Pal wrote: >> >>> On 01/18/2013 06:52 AM, Fred van Zwieten wrote: >>> >>> Hi Dmitri, >>> >>> Sorry for the late reply. I basically want to do the same as Charlie >>> Derwent in another tread on this mailing list: To fully automate the >>> re-installation of a server using Satellite/Spacewalk using kickstart. As >>> the server is an IPA client, it must first get to be un-enrolled, before an >>> ipa-client-install --unattened -w secret etc. can be done in a %post >>> snippet of the kickstart file. It is the automation of the unenrollment >>> proces that we are not able to set up. >>> >>> What I can do on any ipa-client to unenroll on the command line is: >>> >>> ipa --disable-host and ipa host-mod --password=secret --ssh= >>> >>> This unprovisions the client, set's an OTP and removes the host ssh >>> keys. >>> >>> However, this can only be done on an IPA client, and during a >>> kickstart install the server is no longer an IPA client, because it is >>> freshly being set up. >>> >>> It's a typical chicken-and-egg issue. You must first be ipa client to >>> be able to execute ipa commands, but you cannot become an ipa client before >>> unprovisioning yourself using those same ipa commands. >>> >>> Another approuch would be to unprovision the client just before the >>> reboot to be kickstarted, however, I have no idea how to set that up. It >>> would mean the server has to know somehow it is being rebooted because of a >>> re-install, but afaik, there is no way for satellite/spacewalk to tell the >>> server this.. >>> >>> Regards, >>> >>> Fred >>> >>> >>> IMO the right approach would be for the Satellite server to perform >>> "ipa --disable-host and ipa host-mod --password=secret --ssh=" as >>> a part of the re-installation. >>> Satellite should be given an IPA identity and call into IPA when it >>> performs reinstall before rebooting the system. >>> >>> Tough... I will see what I can do. >>> >>> >>> >>> >>> >>> >>> On Sat, Jan 12, 2013 at 10:06 PM, Dmitri Pal wrote: >>> >>>> On 01/12/2013 03:28 AM, Fred van Zwieten wrote: >>>> >>>> Hi there, >>>> >>>> We are in the process of implementing Satellite and want to automate >>>> server installations 100% using kickstart, cobbler, satellite. >>>> >>>> IPA clients can be scripted enrolled using kickstart. Plenty of >>>> documentation about that. >>>> >>>> However, how to "re"-enroll IPA clients? >>>> >>>> Satellite gives me the option to re-install a server. In this case, >>>> there are still host and possibly service records for this host present in >>>> IPA and DNS. >>>> >>>> One way to think about this is, that it's actually OK to keep those >>>> records there, because it is a "re"-installation, so why remove and >>>> re-enroll? However, there is the krb5.keytab in /etc. I could save that >>>> file during redeployment, but I'm not sure if that will work. And iare >>>> there any other gotcha's. >>>> >>>> So, the question is, how to re-install an IPA client using kickstart >>>> (silent re-install)? >>>> >>>> >>>> The question is how/do you remove the client? >>>> Based on what you say above you use the same system so there are some >>>> leftovers. If you can run ipa-client-install --uninstall it should clean >>>> things like keytab and certs (there have been bugs fixed in freeIPA 3.0). >>>> If the client has access to the server it will clean (not remove) the host >>>> entry too. Then you can re-run the install. If you use OTP you would need >>>> to reset OTP first. >>>> >>>> >>>> Regards, >>>> >>>> Fred >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://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/ >>>> >>>> >>> >>> >>> -- >>> 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 at 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/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Jan 23 20:58:49 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 23 Jan 2013 15:58:49 -0500 Subject: [Freeipa-users] using wildcard or other external CA certs In-Reply-To: <51004BF4.5040701@cora.nwra.com> References: <050.da800267d7b7e77bce0964839c3d1163@fedorahosted.org> <51004B54.2070403@redhat.com> <51004BF4.5040701@cora.nwra.com> Message-ID: <51004F09.7060500@redhat.com> On 01/23/2013 03:45 PM, Orion Poplawski wrote: > On 01/23/2013 01:43 PM, Dmitri Pal wrote: >> Yes please. Let us do it on the user list. >> >> Ticket URL: > > So, my goal in using a wildcard cert signed by a "well known" CA was > to be able to avoid installing the IPA CA in clients like Thunderbird > and Firefox. Thoughts, comments, suggestions? > When you enroll the client we deliver the IPA CA cert to it and store it in every cert store we can AFAIU. But I will leave to Rob to comment on that. There is also a new feature in Fedora to consolidate the certificate store for different components: https://fedoraproject.org/wiki/Features/SharedSystemCertificates It is the step into the right direction. Once it is implemented we would be able to place IPA cert there during enrollment. FF users have to accept IPA cert when they hit IPA self service the first time. I do not see a way around placing the certs into the right stores but may be I am missing something. You can probably use something like puppet to deliver it but isn't the cert store for FF in the user home directory? It might not be available for puppet or any other central tool to mess with. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Bob.sauvage at gmx.fr Wed Jan 23 20:59:12 2013 From: Bob.sauvage at gmx.fr (Bob Sauvage) Date: Wed, 23 Jan 2013 21:59:12 +0100 Subject: [Freeipa-users] Re : Re: Some interrogations about the freeipa deployment Message-ID: <20130123205912.315160@gmx.com> Hi Dale, You mean that if I turn this option to 'yes', I'll be able to connect to the server through SSH without needing to authenticate again ? Even if I'm connected on the domain from a Windows workstation ? Regards, ----- Message d'origine ----- De : Dale Macartney Envoy?s : 22.01.13 23:13 ? : freeipa-users at redhat.com Objet : Re: [Freeipa-users] Some interrogations about the freeipa deployment -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/22/2013 09:51 PM, Steven Jones wrote: > Hi, > > I have all done this, so from what you write I think IPA would be a good fit for what you want, except that is the single sign on bit I have not looked to see if that can be done. For http restart you control that via sudo in IPA so its centrally managed, I have this working for one such server though I use the reload option instead. to enable SSO with SSH from a ipa workstation, just edit /etc/ssh/sshd_config and make sure the line below is set to yes "GSSAPIAuthentication yes" If you've just made the change, it won't take effect until SSH is restarted. So do the usual service sshd restart. > > I would also not run one instance of IPA myself but with such a small site that's your call. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ------------------------- > *From:* freeipa-users-bounces at redhat.com [ freeipa-users-bounces at redhat.com ] on behalf of Bob Sauvage [ Bob.sauvage at gmx.fr ] > *Sent:* Wednesday, 23 January 2013 9:51 a.m. > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] Some interrogations about the freeipa deployment > > Hi *, > > I plan to review the network architecture of my office. 10 Windows/Linux desktops and 2 Linux servers will be deployed on the network. > > I want to install freeipa on the first server to act like an AD DS. I want to authenticate users on the server and controlling what can be done or not by them on the network. 10 other linux web servers should be accessible (console) by specific users and without the need to authenticating again (single sign on). On these web servers, users can issue specific commands like "/etc/init.d/httpd restart". > > Is it possible to achive this with freeipa ? Do you have some articles ? > > Thanks in advance, > > Bob ! > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ/w8VAAoJEAJsWS61tB+q2+8P/0voaYOSa/ZnwiQmvrqLsaPE oYm4j/m88STSXvDdhDsgNQJZJFY9XDv7y3njnuSWElqHD0yGBEbJvc+pmoi8uZf0 8EORIarUQhCf6awI4RIHxg6+nOOwVkllx/FDVSJldGnKlv3OSvOrln+tTK9gITkg ZzsMvtFTYIjrF4nMSEtTCGfFi7lnmCrvXhXijKSCRjUfZI51t78SamI5ldKzV6Zy RE4ofJQexUpWhCXnDyWg5I/fDY6EQc9UAjeiVjmC462Sp32Rso5bQBYUwrQtD8uG d1b1sfOW3v+oExmnOfSeGwzssl8SzYk1jr9kak9JU1DctPIgp5aCjpKYtRTnh5GB 44bNMXATFHRWVU21QlaTYwmQue12cb1BaehMUjZfvHTvNcK171RF9DfAhxS+U1Z4 ZCyv8mUGDB28xWKx0fH5639CGjPYCZxltOOF/053W7ZyrrRN38O2AD7LUkYdH3kb ci04L/tB8znXcP6OQaTeDzJHY12bkspJz+tBNvM/KeFhJQxw/FQqtFi55KrhlKMN XCsHdj3fqEzV/h6+3wu0Na7Y4hDt5mf0i3i1UTO9nj941QIr2BYKrQLzKSKLu/Md Z+E04ZgiQWgzb+Yw4bFv6I8g4y6nrUFVvDxt970bqgbk9cbfAGLEMjd6xRm6QDgq CJUkZcaWqi3SYPeGHx0x =fTHE -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Jan 23 21:01:14 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 23 Jan 2013 16:01:14 -0500 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> Message-ID: <51004F9A.6020006@redhat.com> On 01/23/2013 03:24 PM, Fred van Zwieten wrote: > Dmitri, > > If I understand correcty this would mean I backup the keytab before > reinstall en restore it after (easily done with Satellite), then do a > ipa-client-install using the keytab. Does this mean the host record in > IPA will never change during this process? Sounds good to me. This > makes reinstalling a one-step process. > > When the ssh keys are not preserved during reinstall they must be > refreshed in IPA, will ipa-client-install do that too in this case? Yes I suspect, but that would be the same as the initial enroll. I suspect the keytab, cert and ssh keys would be regenerated. We will just use keytab to acquire ticket and then start the whole enrollment from clean sheet. > > Fred > > > On Wed, Jan 23, 2013 at 8:56 PM, Dmitri Pal > wrote: > > On 01/23/2013 01:56 PM, Charlie Derwent wrote: >> Hi >> >> My team and I have been around this a few times and as far as we >> can see the best and simplest way to make this work is if we >> enrol once and back up all the relevant bits of information so in >> the event of a rebuild we can restore the necessary components >> and make it appear to the IPA server that it had never left. >> >> Disabling and re-enrolling was the preferred option initially but >> it seems there are too many issues to make this viable going forward. >> >> * How to allow developers/administrators/robots access securely >> between the disabling the host and re-enrolment (to say >> reboot the server for PXEboot) >> * Having to grant users permission to enrol servers even when >> they only need to re-provision existing servers. >> * OTP reuse being disabled preventing something simple like the >> hostname of the server being used during re-enrolment >> * The lack of a reusable OTP also makes the process two-step >> (see Fred's mail) rather than the single step we previously had. >> >> To that end could someone please tell us or document all the >> steps required to back up the key ipa-client files so we can get >> past these problems and move onto the more interesting things >> that the IPA server can provide. >> >> Any effort to simplify the backup and restore process within >> an IPA client (and the server for that matter) would also be >> greatly appreciated. >> > I suspect you opened the ticket: > https://fedorahosted.org/freeipa/ticket/3373 > Anyways I replied in the ticket and I am pasting it here: > Making OTP reusable defeats the purpose of the OTP. It becomes > just another password. If you want this you can create an account > in IPA, limit its privileges to just host enrollment and use the > password associated with this account to re-provision systems. > Would that solve the problem for you? > > If the backup seems like a good option I suggest we open an RFE to > allow re-enrolling a host using keytab. > I can file an RFE for it. What it would do is: add an argument to > ipa-client-install to use keytab instead of OTP or password if you > saved one. If the authentication successful the client will > reconfigure the system once again. > > Would that solve the problem? > > I do not like the full backup idea as it is not consistent between > the versions. Say you redeploy but with the updated version of > software that changed something and config files from the previous > version are not 100% the same. Things would break. > And depending upon the commands you used we touch different files > as SSSD can now be integrated with autofs, ssh, sudo. > I am just not sure that backup and restore is really a sustainable > approach project/product wise. > We can probably craft a list but I am scared promoting it as a > solution. > > >> Regards, >> Charlie. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Jan 18, 2013 at 8:14 PM, Fred van Zwieten >> > wrote: >> >> Dmitri, >> >> Sure I can do this. I can make a script, and have this >> executed from Satellite (remote command) and than perform the >> server redeploy from Satellite. However, that makes it a two >> step process, and that is what I now also have. However, I >> would like to make it fully automated in a single step. >> >> Come to think of it...there is also an api for Satellite. >> Maybe I can make a script that will first do the IPA stuff >> and then call Satellite to redeploy the server..... >> ....hmmm....will look into this...and report my findings >> >> >> Met vriendelijke groeten, >> * >> Fred van Zwieten >> * >> *Enterprise Open Source Services* >> * >> Consultant* >> /(vrijdags afwezig)/ >> >> *VX Company IT Services B.V.* >> *T* (035) 539 09 50 mobiel (06) 41 68 28 48 >> *F* (035) 539 09 08 >> *E* fvzwieten at vxcompany.com >> *I* www.vxcompany.com >> >> >> On Fri, Jan 18, 2013 at 6:09 PM, Dmitri Pal > > wrote: >> >> On 01/18/2013 06:52 AM, Fred van Zwieten wrote: >>> Hi Dmitri, >>> >>> Sorry for the late reply. I basically want to do the >>> same as Charlie Derwent in another tread on this mailing >>> list: To fully automate the re-installation of a server >>> using Satellite/Spacewalk using kickstart. As the server >>> is an IPA client, it must first get to be un-enrolled, >>> before an ipa-client-install --unattened -w secret etc. >>> can be done in a %post snippet of the kickstart file. It >>> is the automation of the unenrollment proces that we are >>> not able to set up. >>> >>> What I can do on any ipa-client to unenroll on the >>> command line is: >>> >>> ipa --disable-host and ipa host-mod >>> --password=secret --ssh= >>> >>> This unprovisions the client, set's an OTP and removes >>> the host ssh keys. >>> >>> However, this can only be done on an IPA client, and >>> during a kickstart install the server is no longer an >>> IPA client, because it is freshly being set up. >>> >>> It's a typical chicken-and-egg issue. You must first be >>> ipa client to be able to execute ipa commands, but you >>> cannot become an ipa client before unprovisioning >>> yourself using those same ipa commands. >>> >>> Another approuch would be to unprovision the client just >>> before the reboot to be kickstarted, however, I have no >>> idea how to set that up. It would mean the server has to >>> know somehow it is being rebooted because of a >>> re-install, but afaik, there is no way for >>> satellite/spacewalk to tell the server this.. >>> >>> Regards, >>> >>> Fred >> >> IMO the right approach would be for the Satellite server >> to perform "ipa --disable-host and ipa host-mod >> --password=secret --ssh=" as a part of the re-installation. >> Satellite should be given an IPA identity and call into >> IPA when it performs reinstall before rebooting the system. >> >> Tough... I will see what I can do. >> >> >>> >>> >>> >>> >>> On Sat, Jan 12, 2013 at 10:06 PM, Dmitri Pal >>> > wrote: >>> >>> On 01/12/2013 03:28 AM, Fred van Zwieten wrote: >>>> Hi there, >>>> >>>> We are in the process of implementing Satellite and >>>> want to automate server installations 100% using >>>> kickstart, cobbler, satellite. >>>> >>>> IPA clients can be scripted enrolled using >>>> kickstart. Plenty of documentation about that. >>>> >>>> However, how to "re"-enroll IPA clients? >>>> >>>> Satellite gives me the option to re-install a >>>> server. In this case, there are still host and >>>> possibly service records for this host present in >>>> IPA and DNS. >>>> >>>> One way to think about this is, that it's actually >>>> OK to keep those records there, because it is a >>>> "re"-installation, so why remove and re-enroll? >>>> However, there is the krb5.keytab in /etc. I could >>>> save that file during redeployment, but I'm not >>>> sure if that will work. And iare there any other >>>> gotcha's. >>>> >>>> So, the question is, how to re-install an IPA >>>> client using kickstart (silent re-install)? >>> >>> The question is how/do you remove the client? >>> Based on what you say above you use the same system >>> so there are some leftovers. If you can run >>> ipa-client-install --uninstall it should clean >>> things like keytab and certs (there have been bugs >>> fixed in freeIPA 3.0). If the client has access to >>> the server it will clean (not remove) the host entry >>> too. Then you can re-run the install. If you use OTP >>> you would need to reset OTP first. >>> >>>> >>>> Regards, >>>> >>>> Fred >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at 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/ >>> >>> >>> >> >> >> -- >> 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 at 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/ > > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fvzwieten at vxcompany.com Wed Jan 23 21:09:01 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Wed, 23 Jan 2013 22:09:01 +0100 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: <51004F9A.6020006@redhat.com> References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> <51004F9A.6020006@redhat.com> Message-ID: On Wed, Jan 23, 2013 at 10:01 PM, Dmitri Pal wrote: > On 01/23/2013 03:24 PM, Fred van Zwieten wrote: > > Dmitri, > > If I understand correcty this would mean I backup the keytab before > reinstall en restore it after (easily done with Satellite), then do a > ipa-client-install using the keytab. Does this mean the host record in IPA > will never change during this process? Sounds good to me. This makes > reinstalling a one-step process. > > When the ssh keys are not preserved during reinstall they must be > refreshed in IPA, will ipa-client-install do that too in this case? > > > Yes I suspect, but that would be the same as the initial enroll. I suspect > the keytab, cert and ssh keys would be regenerated. We will just use keytab > to acquire ticket and then start the whole enrollment from clean sheet. > That would be a perfectly workable solution for me. > > Fred > > > On Wed, Jan 23, 2013 at 8:56 PM, Dmitri Pal wrote: > >> On 01/23/2013 01:56 PM, Charlie Derwent wrote: >> >> Hi >> >> My team and I have been around this a few times and as far as we can see >> the best and simplest way to make this work is if we enrol once and back up >> all the relevant bits of information so in the event of a rebuild we can >> restore the necessary components and make it appear to the IPA server that >> it had never left. >> >> Disabling and re-enrolling was the preferred option initially but it >> seems there are too many issues to make this viable going forward. >> >> - How to allow developers/administrators/robots access securely >> between the disabling the host and re-enrolment (to say reboot the server >> for PXEboot) >> - Having to grant users permission to enrol servers even when they >> only need to re-provision existing servers. >> - OTP reuse being disabled preventing something simple like the >> hostname of the server being used during re-enrolment >> - The lack of a reusable OTP also makes the process two-step (see >> Fred's mail) rather than the single step we previously had. >> >> To that end could someone please tell us or document all the steps >> required to back up the key ipa-client files so we can get past these >> problems and move onto the more interesting things that the IPA server >> can provide. >> >> Any effort to simplify the backup and restore process within an IPA >> client (and the server for that matter) would also be greatly appreciated. >> >> >> I suspect you opened the ticket: >> https://fedorahosted.org/freeipa/ticket/3373 >> Anyways I replied in the ticket and I am pasting it here: >> Making OTP reusable defeats the purpose of the OTP. It becomes just >> another password. If you want this you can create an account in IPA, limit >> its privileges to just host enrollment and use the password associated with >> this account to re-provision systems. Would that solve the problem for you? >> >> If the backup seems like a good option I suggest we open an RFE to allow >> re-enrolling a host using keytab. >> I can file an RFE for it. What it would do is: add an argument to >> ipa-client-install to use keytab instead of OTP or password if you saved >> one. If the authentication successful the client will reconfigure the >> system once again. >> >> Would that solve the problem? >> >> I do not like the full backup idea as it is not consistent between the >> versions. Say you redeploy but with the updated version of software that >> changed something and config files from the previous version are not 100% >> the same. Things would break. >> And depending upon the commands you used we touch different files as SSSD >> can now be integrated with autofs, ssh, sudo. >> I am just not sure that backup and restore is really a sustainable >> approach project/product wise. >> We can probably craft a list but I am scared promoting it as a solution. >> >> >> Regards, >> Charlie. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Jan 18, 2013 at 8:14 PM, Fred van Zwieten < >> fvzwieten at vxcompany.com> wrote: >> >>> Dmitri, >>> >>> Sure I can do this. I can make a script, and have this executed from >>> Satellite (remote command) and than perform the server redeploy from >>> Satellite. However, that makes it a two step process, and that is what I >>> now also have. However, I would like to make it fully automated in a single >>> step. >>> >>> Come to think of it...there is also an api for Satellite. Maybe I can >>> make a script that will first do the IPA stuff and then call Satellite to >>> redeploy the server..... >>> ....hmmm....will look into this...and report my findings >>> >>> >>> Met vriendelijke groeten, >>> * >>> Fred van Zwieten >>> * >>> *Enterprise Open Source Services* >>> * >>> Consultant* >>> *(vrijdags afwezig)* >>> >>> *VX Company IT Services B.V.* >>> *T* (035) 539 09 50 mobiel (06) 41 68 28 48 >>> *F* (035) 539 09 08 >>> *E* fvzwieten at vxcompany.com >>> *I* www.vxcompany.com >>> >>> >>> On Fri, Jan 18, 2013 at 6:09 PM, Dmitri Pal wrote: >>> >>>> On 01/18/2013 06:52 AM, Fred van Zwieten wrote: >>>> >>>> Hi Dmitri, >>>> >>>> Sorry for the late reply. I basically want to do the same as Charlie >>>> Derwent in another tread on this mailing list: To fully automate the >>>> re-installation of a server using Satellite/Spacewalk using kickstart. As >>>> the server is an IPA client, it must first get to be un-enrolled, before an >>>> ipa-client-install --unattened -w secret etc. can be done in a %post >>>> snippet of the kickstart file. It is the automation of the unenrollment >>>> proces that we are not able to set up. >>>> >>>> What I can do on any ipa-client to unenroll on the command line is: >>>> >>>> ipa --disable-host and ipa host-mod --password=secret --ssh= >>>> >>>> This unprovisions the client, set's an OTP and removes the host ssh >>>> keys. >>>> >>>> However, this can only be done on an IPA client, and during a >>>> kickstart install the server is no longer an IPA client, because it is >>>> freshly being set up. >>>> >>>> It's a typical chicken-and-egg issue. You must first be ipa client to >>>> be able to execute ipa commands, but you cannot become an ipa client before >>>> unprovisioning yourself using those same ipa commands. >>>> >>>> Another approuch would be to unprovision the client just before the >>>> reboot to be kickstarted, however, I have no idea how to set that up. It >>>> would mean the server has to know somehow it is being rebooted because of a >>>> re-install, but afaik, there is no way for satellite/spacewalk to tell the >>>> server this.. >>>> >>>> Regards, >>>> >>>> Fred >>>> >>>> >>>> IMO the right approach would be for the Satellite server to perform >>>> "ipa --disable-host and ipa host-mod --password=secret --ssh=" as >>>> a part of the re-installation. >>>> Satellite should be given an IPA identity and call into IPA when it >>>> performs reinstall before rebooting the system. >>>> >>>> Tough... I will see what I can do. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Jan 12, 2013 at 10:06 PM, Dmitri Pal wrote: >>>> >>>>> On 01/12/2013 03:28 AM, Fred van Zwieten wrote: >>>>> >>>>> Hi there, >>>>> >>>>> We are in the process of implementing Satellite and want to automate >>>>> server installations 100% using kickstart, cobbler, satellite. >>>>> >>>>> IPA clients can be scripted enrolled using kickstart. Plenty of >>>>> documentation about that. >>>>> >>>>> However, how to "re"-enroll IPA clients? >>>>> >>>>> Satellite gives me the option to re-install a server. In this case, >>>>> there are still host and possibly service records for this host present in >>>>> IPA and DNS. >>>>> >>>>> One way to think about this is, that it's actually OK to keep those >>>>> records there, because it is a "re"-installation, so why remove and >>>>> re-enroll? However, there is the krb5.keytab in /etc. I could save that >>>>> file during redeployment, but I'm not sure if that will work. And iare >>>>> there any other gotcha's. >>>>> >>>>> So, the question is, how to re-install an IPA client using kickstart >>>>> (silent re-install)? >>>>> >>>>> >>>>> The question is how/do you remove the client? >>>>> Based on what you say above you use the same system so there are some >>>>> leftovers. If you can run ipa-client-install --uninstall it should clean >>>>> things like keytab and certs (there have been bugs fixed in freeIPA 3.0). >>>>> If the client has access to the server it will clean (not remove) the host >>>>> entry too. Then you can re-run the install. If you use OTP you would need >>>>> to reset OTP first. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Fred >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://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/ >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 at 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/ >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Jan 23 21:30:19 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Jan 2013 16:30:19 -0500 Subject: [Freeipa-users] using wildcard or other external CA certs In-Reply-To: <51004F09.7060500@redhat.com> References: <050.da800267d7b7e77bce0964839c3d1163@fedorahosted.org> <51004B54.2070403@redhat.com> <51004BF4.5040701@cora.nwra.com> <51004F09.7060500@redhat.com> Message-ID: <5100566B.10803@redhat.com> Dmitri Pal wrote: > On 01/23/2013 03:45 PM, Orion Poplawski wrote: >> On 01/23/2013 01:43 PM, Dmitri Pal wrote: >>> Yes please. Let us do it on the user list. >>> >>> Ticket URL: >> >> So, my goal in using a wildcard cert signed by a "well known" CA was >> to be able to avoid installing the IPA CA in clients like Thunderbird >> and Firefox. Thoughts, comments, suggestions? >> > When you enroll the client we deliver the IPA CA cert to it and store it > in every cert store we can AFAIU. But I will leave to Rob to comment on > that. Well, that is certainly a good idea. Unfortunately that isn't something we can do right now, even with passing in PKCS#12 files. I suspect that with enough intimate knowledge of the cert code you could get something to work (I'd guess you'd need to get the PKCS#12 friendly names just right). This is just hard to automate in any sort of reliable way. > There is also a new feature in Fedora to consolidate the certificate > store for different components: > https://fedoraproject.org/wiki/Features/SharedSystemCertificates > It is the step into the right direction. Once it is implemented we would > be able to place IPA cert there during enrollment. Yup, I think this will help quite a bit. > FF users have to accept IPA cert when they hit IPA self service the > first time. > I do not see a way around placing the certs into the right stores but > may be I am missing something. You can probably use something like > puppet to deliver it but isn't the cert store for FF in the user home > directory? It might not be available for puppet or any other central > tool to mess with. > His point is that if he uses a cert issued by a root CA (e.g. Verisign) then his users won't have to do anything SSL trust-wise because it would already be trusted. We spent a fair bit of time trying to figure this out a couple of years ago and could never come to any sort of workable solution. It is possible for the client installer to stuff the CA into various places but that always inevitably led to really bad corner cases, and in particular, issues with re-installs. rob From simo at redhat.com Wed Jan 23 21:34:13 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 23 Jan 2013 16:34:13 -0500 Subject: [Freeipa-users] using wildcard or other external CA certs In-Reply-To: <51004BF4.5040701@cora.nwra.com> References: <050.da800267d7b7e77bce0964839c3d1163@fedorahosted.org> <51004B54.2070403@redhat.com> <51004BF4.5040701@cora.nwra.com> Message-ID: <1358976853.20683.383.camel@willson.li.ssimo.org> On Wed, 2013-01-23 at 13:45 -0700, Orion Poplawski wrote: > On 01/23/2013 01:43 PM, Dmitri Pal wrote: > > Yes please. Let us do it on the user list. > > > > Ticket URL: > > So, my goal in using a wildcard cert signed by a "well known" CA was to be > able to avoid installing the IPA CA in clients like Thunderbird and Firefox. > Thoughts, comments, suggestions? Sharing the same cert key between many machines is never a good idea. Simo. -- Simo Sorce * Red Hat, Inc * New York From orion at cora.nwra.com Wed Jan 23 21:57:39 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 23 Jan 2013 14:57:39 -0700 Subject: [Freeipa-users] using wildcard or other external CA certs In-Reply-To: <5100566B.10803@redhat.com> References: <050.da800267d7b7e77bce0964839c3d1163@fedorahosted.org> <51004B54.2070403@redhat.com> <51004BF4.5040701@cora.nwra.com> <51004F09.7060500@redhat.com> <5100566B.10803@redhat.com> Message-ID: <51005CD3.4010303@cora.nwra.com> On 01/23/2013 02:30 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 01/23/2013 03:45 PM, Orion Poplawski wrote: >>> On 01/23/2013 01:43 PM, Dmitri Pal wrote: >>>> Yes please. Let us do it on the user list. >>>> >>>> Ticket URL: >>> >>> So, my goal in using a wildcard cert signed by a "well known" CA was >>> to be able to avoid installing the IPA CA in clients like Thunderbird >>> and Firefox. Thoughts, comments, suggestions? >>> >> When you enroll the client we deliver the IPA CA cert to it and store it >> in every cert store we can AFAIU. But I will leave to Rob to comment on >> that. > > Well, that is certainly a good idea. Unfortunately that isn't something we can > do right now, even with passing in PKCS#12 files. I suspect that with enough > intimate knowledge of the cert code you could get something to work (I'd guess > you'd need to get the PKCS#12 friendly names just right). This is just hard to > automate in any sort of reliable way. I'm not clear if you are referring to client (as Dmitri did) or server install (as I was trying to do) here. Having client tools to install the IPA CA would be helpful, but would be needed on multiple platforms. Handling the cert names seems to be the big issue with the server install (and the subject of the bug). FWIW - I've managed to install and replicate 2.2 with such a cert with the hack to the cert code and pausing the install at the right place to fix the CA trust level. So I really don't think we are that far off if we wanted to go this route. The problem I see at the moment is properly identifying the name the CA cert will have in the NSS store without a Friendly Name. >> There is also a new feature in Fedora to consolidate the certificate >> store for different components: >> https://fedoraproject.org/wiki/Features/SharedSystemCertificates >> It is the step into the right direction. Once it is implemented we would >> be able to place IPA cert there during enrollment. > > Yup, I think this will help quite a bit. For Fedora. But Windows, OS X, etc ? >> FF users have to accept IPA cert when they hit IPA self service the >> first time. >> I do not see a way around placing the certs into the right stores but >> may be I am missing something. You can probably use something like >> puppet to deliver it but isn't the cert store for FF in the user home >> directory? It might not be available for puppet or any other central >> tool to mess with. >> > > His point is that if he uses a cert issued by a root CA (e.g. Verisign) then > his users won't have to do anything SSL trust-wise because it would already be > trusted. Yup. > We spent a fair bit of time trying to figure this out a couple of years ago > and could never come to any sort of workable solution. It is possible for the > client installer to stuff the CA into various places but that always > inevitably led to really bad corner cases, and in particular, issues with > re-installs. > > rob Firefox is not so bad I suppose - you can click on a link and it will prompt you to install the cert. I remember Thunderbird to be a much bigger pain, but perhaps that has changed. I'll have to test. I can also imagine another architecture where there are slave LDAP servers with root CA assigned certs for general clients to connect to. The IPA webserver will only be accessed by a few clients so that is less of a big deal. Thanks for the good discussion. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From simo at redhat.com Wed Jan 23 22:16:12 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 23 Jan 2013 17:16:12 -0500 Subject: [Freeipa-users] Announcing FreeIPA 3.1.2 Message-ID: <1358979372.20683.384.camel@willson.li.ssimo.org> The FreeIPA team is proud to announce version FreeIPA v3.1.2 This release contains Security Updates It can be downloaded from http://www.freeipa.org/page/Downloads. == Highlights == During the past few months a number of security Issues have been found that affect FreeIPA. Three Security Advisories have been released: * CVE-2012-4546: Incorrect CRLs publishing * CVE-2012-5484: MITM Attack during Join process * CVE-2013-0199: Cross-Realm Trust key leak The FreeIPA Team would like to thank the Red Hat Security Response Team and in particular Vincent Danen for the invaluable assistance provided for the assessment and resolution of these issues. For CVE-2012-5484 we would like to thank Petr Men??k for reporting the issue. == Upgrading == Please consult each CVE announcement for related Upgrading instructions. An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. 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-devel mailing list: http://www.redhat.com/mailman/listinfo/freeipa-devel == Detailed Changelog since 3.1.1 == Alexander Bokovoy (1): Update plugin to upload CA certificate to LDAP Ana Krivokapic (1): Raise ValidationError for incorrect subtree option. John Dennis (1): Use secure method to acquire IPA CA certificate Martin Kosek (5): permission-find no longer crashes with --targetgroup Avoid CRL migration error message Sort LDAP updates properly Upgrade process should not crash on named restart Installer should not connect to 127.0.0.1 Rob Crittenden (5): Convert uniqueMember members into DN objects. Do SSL CA verification and hostname validation. Don't initialize NSS if we don't have to, clean up unused cert refs Update anonymous access ACI to protect secret attributes. Become IPA 3.1.2 Simo Sorce (1): Upload CA cert in the directory on install ################################################################################ == CVE-2012-4546: Incorrect CRLs publishing == == Summary == It was found that the current default configuration of IPA servers did not publish correct CRLs (Certificate Revocation Lists). The default configuration specifies that every replica is to generate its own CRL, however this can result in inconsistencies in the CRL contents provided to clients from different Identity Management replicas. More specifically, if a certificate is revoked on one Identity Management replica, it will not show up on another Identity Management replica. To avoid this inconsistency, the solution is to configure CRL generation to only take place on one Identity Management server. To do so, the CRL configuration must be changed on all Identity Management servers. == Affected Versions == All 2.x and 3.x versions using multiple CA replicas == Impact == Low == Acknowledgements == The bug was found by the FreeIPA team during an internal review. == Upgrade Instructions == Upgrading to the latest 3.0 or 3.1 FreeIPA versions should be sufficient to resolve the issue. == Manual Instructions == To manually resolve the problem the CRL configuration must be changed on all Identity Management servers. One IPA master needs to be picked as the CRL generator. It does not matter which master, and the following procedure should be used: On the non-CRL generating masters: 1. Configure the clones to point to the CRL generator to get the CRL: 1a. Edit /etc/httpd/conf.d/ipa-pki-proxy.conf 1b. Add "|^/ca/ee/ca/getCRL" to the end of the first LocationMatch. After editing, the first LocationMatch entry in ipa-pki-proxy.conf should look like this: 1c. At the end of this file add: RewriteRule ^/ipa/crl/MasterCRL.bin https://$FQDN/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] 1d. Replace $FQDN with the hostname of the IPA master picked as the CRL generator. 1e. The httpd service will need to be restarted after making this change: # service httpd restart 2. Update the CRL generator to include certificates revoked from other masters in its CRL: 2a. Edit the CA configuration file in /var/lib/pki-ca/conf/CS.cfg: These two settings should be true by default: ca.crl.MasterCRL.enableCRLCache=true ca.crl.MasterCRL.enableCRLUpdates=true 2b. Set this directive to true (This can be appended to the end of CS.cfg): ca.listenToCloneModifications=true 2c. The CA will need to be restarted after making this change: # service pki-cad restart It may be noted that this configuration creates a single point of failure. If the CRL generator server goes down then the other IPA masters will not be able to retrieve a CRL and one will not be generated. In this case one would need to choose a new master as the CRL generator and perform the steps above. It is recommended that a DNS CNAME be created to refer to the server that provides the CRL (with a relatively short TTL). This will provide flexibility in case the CRL generator needs to be changed, and without reconfiguring any clients that need to retrieve the CRL. == Patches == A patch to resolve this issue is available through our git repository: http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=392097f20673708a684da168aec302da7ccda9a6 ################################################################################ == CVE-2012-5484: MITM Attack during Join process == A weakness was found in the way an IPA client communicates with an IPA server when attempting to join an IPA domain. When an IPA client attempts to join an IPA domain an attacker could run a Man in The Middle Attack to try to intercept and hijack initial communication. A join initiated by an administrative user would grant the attacker administrative rights to the IPA server, whereas a join initiated by an unprivileged user would only grant the attacker limited privilege (typically just the ability to join the domain). The weakness is caused by the way the CA certificate is retrieved from the server. The following SSL communication may then be intercepted and subverted. Note that no credentials are exposed through this attack and it is effective only if performed during the join procedure and network traffic can be redirected or intercepted. Mere observation of the network traffic is not sufficient to grant an attacker any privilege. == Affected Versions == All 2.x and 3.x versions == Impact == Low == Acknowledgements == The FreeIPA team would like to thank Petr Men??k for reporting this issue. == Upgrade instructions == The resolution for this issue consist in allowing clients to download the CA certificate exclusively via a mutually authenticated LDAP connection or by providing the CA cert via an external method to the client. At least one IPA server in a domain need to be updated using the provided patches, so that the CA certificate is made available via LDAP. All client should be upgraded to use the updated ipa-client-install script that downloads the CA cert via an authenticated LDAP connection. == Patches == Patches to resolve this issue are available through our git repository: * http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=18eea90ebb24a9c22248f0b7e18646cc6e3e3e0f * http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=a40285c5a0288669b72f9d991508d4405885bffc * http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=91f4af7e6af53e1c6bf17ed36cb2161863eddae4 * http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=a1991aeac19c3fec1fdd0d184c6760c90c9f9fc9 * http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=31e41eea6c2322689826e6065ceba82551c565aa ################################################################################ == CVE-2013-0199: Cross-Realm Trust key leak == FreeIPA 3.0 introduced a Cross-Realm Kerberos trusts with Active Directory, a feature that allows IPA administrators to create a Kerberos trust with an AD. This allows IPA users to be able to access resources in AD trusted domains and vice versa. When the Kerberos trust is created, an outgoing and incoming keys are stored in the IPA LDAP backend (in ipaNTTrustAuthIncoming and ipaNTTrustAuthOutgoing attributes). However, the IPA LDAP ACIs allow anonymous read acess to these attributes which could allow an unprivileged user to read the keys. With these keys an attacker could impersonate users and services of the opposite domain by crafting special Kerberos tickets. == Affected Versions == All 3.x versions. The vulnerability is present only if AD Trusts are enabled and a trust relationship is in place. == Impact == Medium == Acknowledgements == The bug was found by the FreeIPA team during an internal review. == Upgrade Instructions == Administrators are advise to change their ACIs to block the ipaNTTrustAuthIncoming and ipaNTTrustAuthOutgoing attributes from access from non administrative users. Once the new ACIs are in place it is recommended to change the trust password. This can be accomplished by temporary deleting and then recreating the trust agreement between the two domains using tha ipa trust CLI commands. == Patches == A patch to resolve this issue is available through our git repository: http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=d5966bde802d8ef84c202a3e7c85f17b9e305a30 Applying the patch prevents further access to keys but does NOT change the trust secret. ################################################################################ From dpal at redhat.com Wed Jan 23 23:53:29 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 23 Jan 2013 18:53:29 -0500 Subject: [Freeipa-users] Re : Re: Some interrogations about the freeipa deployment In-Reply-To: <20130123205912.315160@gmx.com> References: <20130123205912.315160@gmx.com> Message-ID: <510077F9.7070806@redhat.com> On 01/23/2013 03:59 PM, Bob Sauvage wrote: > > Hi Dale, > > You mean that if I turn this option to 'yes', I'll be able to connect to the server through SSH without needing to authenticate again ? Even if I'm connected on the domain from a Windows workstation ? > If you setup trusts between IPA and AD then yes. If not then you need to ssh from the system that belongs to the API domain. IPA does not support Windows systems to be joined to IPA domain. But you can configure kerberos for Windows and use local Windows accounts. There are some HowTos on the wiki about it. Alternatively you join Linux systems to AD and use it as your central authentication server then SSO would also work but you will loose ability to manage your Linux related policies. Trusts is probably the best for you but there will be dragons. http://freeipa.org/page/Howto/IPAv3_AD_trust_setup > Regards, > > > >> ----- Message d'origine ----- >> >> De : Dale Macartney >> >> Envoy?s : 22.01.13 23:13 >> >> ? : freeipa-users at redhat.com >> >> Objet : Re: [Freeipa-users] Some interrogations about the freeipa deployment >> >> >> > > On 01/22/2013 09:51 PM, Steven Jones wrote: > > Hi, > > > I have all done this, so from what you write I think IPA would be a > good fit for what you want, except that is the single sign on bit I > have not looked to see if that can be done. For http restart you > control that via sudo in IPA so its centrally managed, I have this > working for one such server though I use the reload option instead. > to enable SSO with SSH from a ipa workstation, just edit > /etc/ssh/sshd_config and make sure the line below is set to yes > "GSSAPIAuthentication yes" > > If you've just made the change, it won't take effect until SSH is > restarted. So do the usual service sshd restart. > > > > I would also not run one instance of IPA myself but with such a > small site that's your call. > > > regards > > > Steven Jones > > > Technical Specialist - Linux RHCE > > > Victoria University, Wellington, NZ > > > 0064 4 463 6272 > > > ------------------------- > > *From:* freeipa-users-bounces at redhat.com > [freeipa-users-bounces at redhat.com] on behalf of Bob Sauvage > [Bob.sauvage at gmx.fr] > > *Sent:* Wednesday, 23 January 2013 9:51 a.m. > > *To:* freeipa-users at redhat.com > > *Subject:* [Freeipa-users] Some interrogations about the freeipa > deployment > > > Hi *, > > > I plan to review the network architecture of my office. 10 > Windows/Linux desktops and 2 Linux servers will be deployed on the > network. > > > I want to install freeipa on the first server to act like an AD DS. > I want to authenticate users on the server and controlling what can be > done or not by them on the network. 10 other linux web servers should > be accessible (console) by specific users and without the need to > authenticating again (single sign on). On these web servers, users can > issue specific commands like "/etc/init.d/httpd restart". > > > Is it possible to achive this with freeipa ? Do you have some articles ? > > > Thanks in advance, > > > Bob ! > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > >> > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Jan 24 00:29:16 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 23 Jan 2013 19:29:16 -0500 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> <51004F9A.6020006@redhat.com> Message-ID: <5100805C.4020706@redhat.com> On 01/23/2013 04:09 PM, Fred van Zwieten wrote: > On Wed, Jan 23, 2013 at 10:01 PM, Dmitri Pal > wrote: > > On 01/23/2013 03:24 PM, Fred van Zwieten wrote: >> Dmitri, >> >> If I understand correcty this would mean I backup the keytab >> before reinstall en restore it after (easily done with >> Satellite), then do a ipa-client-install using the keytab. Does >> this mean the host record in IPA will never change during this >> process? Sounds good to me. This makes reinstalling a one-step >> process. >> >> When the ssh keys are not preserved during reinstall they must be >> refreshed in IPA, will ipa-client-install do that too in this case? > > Yes I suspect, but that would be the same as the initial enroll. I > suspect the keytab, cert and ssh keys would be regenerated. We > will just use keytab to acquire ticket and then start the whole > enrollment from clean sheet. > > > That would be a perfectly workable solution for me. https://fedorahosted.org/freeipa/ticket/3374 >> >> Fred >> >> >> On Wed, Jan 23, 2013 at 8:56 PM, Dmitri Pal > > wrote: >> >> On 01/23/2013 01:56 PM, Charlie Derwent wrote: >>> Hi >>> >>> My team and I have been around this a few times and as far >>> as we can see the best and simplest way to make this work is >>> if we enrol once and back up all the relevant bits of >>> information so in the event of a rebuild we can restore the >>> necessary components and make it appear to the IPA server >>> that it had never left. >>> >>> Disabling and re-enrolling was the preferred option >>> initially but it seems there are too many issues to make >>> this viable going forward. >>> >>> * How to allow developers/administrators/robots access >>> securely between the disabling the host and re-enrolment >>> (to say reboot the server for PXEboot) >>> * Having to grant users permission to enrol servers even >>> when they only need to re-provision existing servers. >>> * OTP reuse being disabled preventing something simple >>> like the hostname of the server being used during >>> re-enrolment >>> * The lack of a reusable OTP also makes the process >>> two-step (see Fred's mail) rather than the single step >>> we previously had. >>> >>> To that end could someone please tell us or document all the >>> steps required to back up the key ipa-client files so we can >>> get past these problems and move onto the more interesting >>> things that the IPA server can provide. >>> >>> Any effort to simplify the backup and restore process within >>> an IPA client (and the server for that matter) would also be >>> greatly appreciated. >>> >> I suspect you opened the ticket: >> https://fedorahosted.org/freeipa/ticket/3373 >> Anyways I replied in the ticket and I am pasting it here: >> Making OTP reusable defeats the purpose of the OTP. It >> becomes just another password. If you want this you can >> create an account in IPA, limit its privileges to just host >> enrollment and use the password associated with this account >> to re-provision systems. Would that solve the problem for you? >> >> If the backup seems like a good option I suggest we open an >> RFE to allow re-enrolling a host using keytab. >> I can file an RFE for it. What it would do is: add an >> argument to ipa-client-install to use keytab instead of OTP >> or password if you saved one. If the authentication >> successful the client will reconfigure the system once again. >> >> Would that solve the problem? >> >> I do not like the full backup idea as it is not consistent >> between the versions. Say you redeploy but with the updated >> version of software that changed something and config files >> from the previous version are not 100% the same. Things would >> break. >> And depending upon the commands you used we touch different >> files as SSSD can now be integrated with autofs, ssh, sudo. >> I am just not sure that backup and restore is really a >> sustainable approach project/product wise. >> We can probably craft a list but I am scared promoting it as >> a solution. >> >> >>> Regards, >>> Charlie. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Jan 18, 2013 at 8:14 PM, Fred van Zwieten >>> > >>> wrote: >>> >>> Dmitri, >>> >>> Sure I can do this. I can make a script, and have this >>> executed from Satellite (remote command) and than >>> perform the server redeploy from Satellite. However, >>> that makes it a two step process, and that is what I now >>> also have. However, I would like to make it fully >>> automated in a single step. >>> >>> Come to think of it...there is also an api for >>> Satellite. Maybe I can make a script that will first do >>> the IPA stuff and then call Satellite to redeploy the >>> server..... >>> ....hmmm....will look into this...and report my findings >>> >>> >>> Met vriendelijke groeten, >>> * >>> Fred van Zwieten >>> * >>> *Enterprise Open Source Services* >>> * >>> Consultant* >>> /(vrijdags afwezig)/ >>> >>> *VX Company IT Services B.V.* >>> *T* (035) 539 09 50 mobiel (06) 41 68 28 48 >>> *F* (035) 539 09 08 >>> *E* fvzwieten at vxcompany.com >>> *I* www.vxcompany.com >>> >>> >>> On Fri, Jan 18, 2013 at 6:09 PM, Dmitri Pal >>> > wrote: >>> >>> On 01/18/2013 06:52 AM, Fred van Zwieten wrote: >>>> Hi Dmitri, >>>> >>>> Sorry for the late reply. I basically want to do >>>> the same as Charlie Derwent in another tread on >>>> this mailing list: To fully automate the >>>> re-installation of a server using >>>> Satellite/Spacewalk using kickstart. As the server >>>> is an IPA client, it must first get to be >>>> un-enrolled, before an ipa-client-install >>>> --unattened -w secret etc. can be done in a %post >>>> snippet of the kickstart file. It is the automation >>>> of the unenrollment proces that we are not able to >>>> set up. >>>> >>>> What I can do on any ipa-client to unenroll on the >>>> command line is: >>>> >>>> ipa --disable-host and ipa host-mod >>>> --password=secret --ssh= >>>> >>>> This unprovisions the client, set's an OTP and >>>> removes the host ssh keys. >>>> >>>> However, this can only be done on an IPA client, >>>> and during a kickstart install the server is no >>>> longer an IPA client, because it is freshly being >>>> set up. >>>> >>>> It's a typical chicken-and-egg issue. You must >>>> first be ipa client to be able to execute ipa >>>> commands, but you cannot become an ipa client >>>> before unprovisioning yourself using those same ipa >>>> commands. >>>> >>>> Another approuch would be to unprovision the client >>>> just before the reboot to be kickstarted, however, >>>> I have no idea how to set that up. It would mean >>>> the server has to know somehow it is being rebooted >>>> because of a re-install, but afaik, there is no way >>>> for satellite/spacewalk to tell the server this.. >>>> >>>> Regards, >>>> >>>> Fred >>> >>> IMO the right approach would be for the Satellite >>> server to perform "ipa --disable-host and >>> ipa host-mod --password=secret --ssh=" as a part of >>> the re-installation. >>> Satellite should be given an IPA identity and call >>> into IPA when it performs reinstall before rebooting >>> the system. >>> >>> Tough... I will see what I can do. >>> >>> >>>> >>>> >>>> >>>> >>>> On Sat, Jan 12, 2013 at 10:06 PM, Dmitri Pal >>>> > wrote: >>>> >>>> On 01/12/2013 03:28 AM, Fred van Zwieten wrote: >>>>> Hi there, >>>>> >>>>> We are in the process of implementing >>>>> Satellite and want to automate server >>>>> installations 100% using kickstart, cobbler, >>>>> satellite. >>>>> >>>>> IPA clients can be scripted enrolled using >>>>> kickstart. Plenty of documentation about that. >>>>> >>>>> However, how to "re"-enroll IPA clients? >>>>> >>>>> Satellite gives me the option to re-install a >>>>> server. In this case, there are still host and >>>>> possibly service records for this host present >>>>> in IPA and DNS. >>>>> >>>>> One way to think about this is, that it's >>>>> actually OK to keep those records there, >>>>> because it is a "re"-installation, so why >>>>> remove and re-enroll? However, there is the >>>>> krb5.keytab in /etc. I could save that file >>>>> during redeployment, but I'm not sure if that >>>>> will work. And iare there any other gotcha's. >>>>> >>>>> So, the question is, how to re-install an IPA >>>>> client using kickstart (silent re-install)? >>>> >>>> The question is how/do you remove the client? >>>> Based on what you say above you use the same >>>> system so there are some leftovers. If you can >>>> run ipa-client-install --uninstall it should >>>> clean things like keytab and certs (there have >>>> been bugs fixed in freeIPA 3.0). If the client >>>> has access to the server it will clean (not >>>> remove) the host entry too. Then you can re-run >>>> the install. If you use OTP you would need to >>>> reset OTP first. >>>> >>>>> >>>>> Regards, >>>>> >>>>> Fred >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at 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/ >>>> >>>> >>>> >>> >>> >>> -- >>> 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 at 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/ >> >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shelltoesuperstar at gmail.com Thu Jan 24 00:47:10 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Thu, 24 Jan 2013 00:47:10 +0000 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: <5100805C.4020706@redhat.com> References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> <51004F9A.6020006@redhat.com> <5100805C.4020706@redhat.com> Message-ID: Dmitri, Thank you so much for opening that ticket. You've captured the problem much more eloquently than I have described it in my e-mails and I think the solution is better than any suggestion I put forward to you. It's very much appreciated, we will wait eagerly for that RFE to make it into a release. Secondly, thanks for the suggestion for the short term fix. I agree entirely about the OTP issue (which was why I raised it as an inquiry rather than a defect) it's a much simpler solution than the ideas we had internally and we already have accounts in our IPA server with no shell used for similar automation purposes. While we do have to expose the password, we can mitigate that in the short term while we wait for the solution outlined in the RFE. Regards, Charlie On Thu, Jan 24, 2013 at 12:29 AM, Dmitri Pal wrote: > On 01/23/2013 04:09 PM, Fred van Zwieten wrote: > > On Wed, Jan 23, 2013 at 10:01 PM, Dmitri Pal wrote: > >> On 01/23/2013 03:24 PM, Fred van Zwieten wrote: >> >> Dmitri, >> >> If I understand correcty this would mean I backup the keytab before >> reinstall en restore it after (easily done with Satellite), then do a >> ipa-client-install using the keytab. Does this mean the host record in IPA >> will never change during this process? Sounds good to me. This makes >> reinstalling a one-step process. >> >> When the ssh keys are not preserved during reinstall they must be >> refreshed in IPA, will ipa-client-install do that too in this case? >> >> >> Yes I suspect, but that would be the same as the initial enroll. I >> suspect the keytab, cert and ssh keys would be regenerated. We will just >> use keytab to acquire ticket and then start the whole enrollment from clean >> sheet. >> > > That would be a perfectly workable solution for me. > > > https://fedorahosted.org/freeipa/ticket/3374 > > > >> Fred >> >> >> On Wed, Jan 23, 2013 at 8:56 PM, Dmitri Pal wrote: >> >>> On 01/23/2013 01:56 PM, Charlie Derwent wrote: >>> >>> Hi >>> >>> My team and I have been around this a few times and as far as we can see >>> the best and simplest way to make this work is if we enrol once and back up >>> all the relevant bits of information so in the event of a rebuild we can >>> restore the necessary components and make it appear to the IPA server that >>> it had never left. >>> >>> Disabling and re-enrolling was the preferred option initially but it >>> seems there are too many issues to make this viable going forward. >>> >>> - How to allow developers/administrators/robots access securely >>> between the disabling the host and re-enrolment (to say reboot the server >>> for PXEboot) >>> - Having to grant users permission to enrol servers even when they >>> only need to re-provision existing servers. >>> - OTP reuse being disabled preventing something simple like the >>> hostname of the server being used during re-enrolment >>> - The lack of a reusable OTP also makes the process two-step (see >>> Fred's mail) rather than the single step we previously had. >>> >>> To that end could someone please tell us or document all the steps >>> required to back up the key ipa-client files so we can get past these >>> problems and move onto the more interesting things that the IPA server >>> can provide. >>> >>> Any effort to simplify the backup and restore process within an IPA >>> client (and the server for that matter) would also be greatly appreciated. >>> >>> >>> I suspect you opened the ticket: >>> https://fedorahosted.org/freeipa/ticket/3373 >>> Anyways I replied in the ticket and I am pasting it here: >>> Making OTP reusable defeats the purpose of the OTP. It becomes just >>> another password. If you want this you can create an account in IPA, limit >>> its privileges to just host enrollment and use the password associated with >>> this account to re-provision systems. Would that solve the problem for you? >>> >>> If the backup seems like a good option I suggest we open an RFE to allow >>> re-enrolling a host using keytab. >>> I can file an RFE for it. What it would do is: add an argument to >>> ipa-client-install to use keytab instead of OTP or password if you saved >>> one. If the authentication successful the client will reconfigure the >>> system once again. >>> >>> Would that solve the problem? >>> >>> I do not like the full backup idea as it is not consistent between the >>> versions. Say you redeploy but with the updated version of software that >>> changed something and config files from the previous version are not 100% >>> the same. Things would break. >>> And depending upon the commands you used we touch different files as >>> SSSD can now be integrated with autofs, ssh, sudo. >>> I am just not sure that backup and restore is really a sustainable >>> approach project/product wise. >>> We can probably craft a list but I am scared promoting it as a solution. >>> >>> >>> Regards, >>> Charlie. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Jan 18, 2013 at 8:14 PM, Fred van Zwieten < >>> fvzwieten at vxcompany.com> wrote: >>> >>>> Dmitri, >>>> >>>> Sure I can do this. I can make a script, and have this executed from >>>> Satellite (remote command) and than perform the server redeploy from >>>> Satellite. However, that makes it a two step process, and that is what I >>>> now also have. However, I would like to make it fully automated in a single >>>> step. >>>> >>>> Come to think of it...there is also an api for Satellite. Maybe I can >>>> make a script that will first do the IPA stuff and then call Satellite to >>>> redeploy the server..... >>>> ....hmmm....will look into this...and report my findings >>>> >>>> >>>> Met vriendelijke groeten, >>>> * >>>> Fred van Zwieten >>>> * >>>> *Enterprise Open Source Services* >>>> * >>>> Consultant* >>>> *(vrijdags afwezig)* >>>> >>>> *VX Company IT Services B.V.* >>>> *T* (035) 539 09 50 mobiel (06) 41 68 28 48 >>>> *F* (035) 539 09 08 >>>> *E* fvzwieten at vxcompany.com >>>> *I* www.vxcompany.com >>>> >>>> >>>> On Fri, Jan 18, 2013 at 6:09 PM, Dmitri Pal wrote: >>>> >>>>> On 01/18/2013 06:52 AM, Fred van Zwieten wrote: >>>>> >>>>> Hi Dmitri, >>>>> >>>>> Sorry for the late reply. I basically want to do the same as Charlie >>>>> Derwent in another tread on this mailing list: To fully automate the >>>>> re-installation of a server using Satellite/Spacewalk using kickstart. As >>>>> the server is an IPA client, it must first get to be un-enrolled, before an >>>>> ipa-client-install --unattened -w secret etc. can be done in a %post >>>>> snippet of the kickstart file. It is the automation of the unenrollment >>>>> proces that we are not able to set up. >>>>> >>>>> What I can do on any ipa-client to unenroll on the command line is: >>>>> >>>>> ipa --disable-host and ipa host-mod --password=secret --ssh= >>>>> >>>>> This unprovisions the client, set's an OTP and removes the host ssh >>>>> keys. >>>>> >>>>> However, this can only be done on an IPA client, and during a >>>>> kickstart install the server is no longer an IPA client, because it is >>>>> freshly being set up. >>>>> >>>>> It's a typical chicken-and-egg issue. You must first be ipa client >>>>> to be able to execute ipa commands, but you cannot become an ipa client >>>>> before unprovisioning yourself using those same ipa commands. >>>>> >>>>> Another approuch would be to unprovision the client just before the >>>>> reboot to be kickstarted, however, I have no idea how to set that up. It >>>>> would mean the server has to know somehow it is being rebooted because of a >>>>> re-install, but afaik, there is no way for satellite/spacewalk to tell the >>>>> server this.. >>>>> >>>>> Regards, >>>>> >>>>> Fred >>>>> >>>>> >>>>> IMO the right approach would be for the Satellite server to perform >>>>> "ipa --disable-host and ipa host-mod --password=secret --ssh=" as >>>>> a part of the re-installation. >>>>> Satellite should be given an IPA identity and call into IPA when it >>>>> performs reinstall before rebooting the system. >>>>> >>>>> Tough... I will see what I can do. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Jan 12, 2013 at 10:06 PM, Dmitri Pal wrote: >>>>> >>>>>> On 01/12/2013 03:28 AM, Fred van Zwieten wrote: >>>>>> >>>>>> Hi there, >>>>>> >>>>>> We are in the process of implementing Satellite and want to >>>>>> automate server installations 100% using kickstart, cobbler, satellite. >>>>>> >>>>>> IPA clients can be scripted enrolled using kickstart. Plenty of >>>>>> documentation about that. >>>>>> >>>>>> However, how to "re"-enroll IPA clients? >>>>>> >>>>>> Satellite gives me the option to re-install a server. In this case, >>>>>> there are still host and possibly service records for this host present in >>>>>> IPA and DNS. >>>>>> >>>>>> One way to think about this is, that it's actually OK to keep those >>>>>> records there, because it is a "re"-installation, so why remove and >>>>>> re-enroll? However, there is the krb5.keytab in /etc. I could save that >>>>>> file during redeployment, but I'm not sure if that will work. And iare >>>>>> there any other gotcha's. >>>>>> >>>>>> So, the question is, how to re-install an IPA client using >>>>>> kickstart (silent re-install)? >>>>>> >>>>>> >>>>>> The question is how/do you remove the client? >>>>>> Based on what you say above you use the same system so there are some >>>>>> leftovers. If you can run ipa-client-install --uninstall it should clean >>>>>> things like keytab and certs (there have been bugs fixed in freeIPA 3.0). >>>>>> If the client has access to the server it will clean (not remove) the host >>>>>> entry too. Then you can re-run the install. If you use OTP you would need >>>>>> to reset OTP first. >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Fred >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://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/ >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> 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 at 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/ >>> >>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at zymeworks.com Wed Jan 23 22:50:06 2013 From: eric at zymeworks.com (Eric Chennells) Date: Wed, 23 Jan 2013 14:50:06 -0800 Subject: [Freeipa-users] Windows XP Client problem Message-ID: Hello, I have the unfortunate requirement of needing to authenticate windows XP clients against freeipa. I have followed the instuctions of these two guides: http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Using_Micro soft_Windows.html http://freeipa.org/page/Windows_authentication_against_FreeIPA Kerberos is working, because I can do a kinit username and properly receive a krbtgt principle. However on login I get the error "The system could not log you on". For the map user step I did "ksetup /mapuser * *" and have a local user created with the same username as the IPA user. Is there a step I am missing? I feel as though I am close because kerberos is working. I am using FreeIPA 2.2 on RHEL 6.3 Thanks for any tips. Eric Notice of Confidentiality: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error please contact the sender immediately by return electronic transmission and then immediately delete this transmission including all attachments without copying, distributing or disclosing the same. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Jan 24 06:00:29 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 24 Jan 2013 01:00:29 -0500 Subject: [Freeipa-users] Windows XP Client problem In-Reply-To: References: Message-ID: <5100CDFD.4020200@redhat.com> On 01/23/2013 05:50 PM, Eric Chennells wrote: > Hello, > > I have the unfortunate requirement of needing to authenticate windows > XP clients against freeipa. > > I have followed the instuctions of these two guides: > http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Using_Microsoft_Windows.html > http://freeipa.org/page/Windows_authentication_against_FreeIPA > > Kerberos is working, because I can do a kinit username and properly > receive a krbtgt principle. > > However on login I get the error "The system could not log you on". > > For the map user step I did "ksetup /mapuser * *" and have a local > user created with the same username as the IPA user. I do not have windows system to check so it is a pure speculation. Can it be that the name of the local user actually does not match? May be there is a typo or may be the name of the user should be the full principal or vice verse just short name and you have long one... Anyways I would have investigated that aspect if I were in the same situation. > > Is there a step I am missing? I feel as though I am close because > kerberos is working. > > I am using FreeIPA 2.2 on RHEL 6.3 > > Thanks for any tips. > > Eric > > > > Notice of Confidentiality: The information transmitted is intended > only for the > person or entity to which it is addressed and may contain confidential > and/or > privileged material. Any review, re-transmission, dissemination or > other use of > or taking of any action in reliance upon this information by persons > or entities > other than the intended recipient is prohibited. If you received this > in error > please contact the sender immediately by return electronic > transmission and then > immediately delete this transmission including all attachments without > copying, > distributing or disclosing the same. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chorn at fluxcoil.net Thu Jan 24 07:10:25 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Thu, 24 Jan 2013 08:10:25 +0100 Subject: [Freeipa-users] Windows XP Client problem In-Reply-To: References: Message-ID: <20130124071025.GA9204@fluxcoil.net> Hi, On Wed, Jan 23, 2013 at 02:50:06PM -0800, Eric Chennells wrote: > > I have followed the instuctions of these two guides: > http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Using_Micro > soft_Windows.html > http://freeipa.org/page/Windows_authentication_against_FreeIPA > > Kerberos is working, because I can do a kinit username and properly receive > a krbtgt principle. > > However on login I get the error "The system could not log you on". > > For the map user step I did "ksetup /mapuser * *" and have a local user > created with the same username as the IPA user. > > Is there a step I am missing? I feel as though I am close because kerberos > is working. Looking at the KDC logs when you try to login might bring a pointer, no idea apart from that.. Christian From john at ox-consulting.com Thu Jan 24 09:15:34 2013 From: john at ox-consulting.com (Johnathan Phan) Date: Thu, 24 Jan 2013 09:15:34 +0000 Subject: [Freeipa-users] missing objects during migration steps In-Reply-To: <5100130A.6050007@redhat.com> References: <50FFED01.8000208@redhat.com> <5100048C.1030402@redhat.com> <1358957654.20683.372.camel@willson.li.ssimo.org> <5100130A.6050007@redhat.com> Message-ID: Hi Rob and Simo, Is there a way to make the schema readable so the error does not show up? Or is that pointless? What is the migrate-ds looking for specifically? Can I manually create it for now? Regards John On Wed, Jan 23, 2013 at 4:42 PM, Rob Crittenden wrote: > Simo Sorce wrote: > >> On Wed, 2013-01-23 at 10:41 -0500, Rob Crittenden wrote: >> >>> Johnathan Phan wrote: >>> >>>> Hi Rob, >>>> >>>> Please find the output from /usr/sbin/slapd -VV that shows the current >>>> openldap version thats running on the ldap server. >>>> >>>> @(#) $OpenLDAP: slapd 2.4.23 (Jul 31 2012 10:47:00) $ >>>> >>>> mockbuild at x86-001.build.bos.**redhat.com:/builddir/build/** >>>> BUILD/openldap-2.4.23/**openldap-2.4.23/build-servers/**servers/slapd >>>> >>>> ps. I have opened a ticket for this. >>>> >>>> https://fedorahosted.org/**freeipa/ticket/3372 >>>> >>>> Can I assume you have a away to turn this check off. As in IRC there >>>> does not seem to be one. Or are you saying I can allow the scheme value >>>> to be checked if I create one or make it readable some how? >>>> >>> >>> There is no way to turn this check off, we always try to retrieve >>> cn=schema. >>> >>> I'd have sworn that openldap already did online schema this way. >>> >> >> Please open a bug, we should no depend on the remote schema being >> readable. >> >> Simo. >> >> > He already opened a ticket. > > rob > -- Johnathan Phan ox-consulting T: +44 (0)784 118 7080 john at ox-consulting.com www.ox-consulting.com OX CONSULTING Ltd is registered in England & Wales, number: 07113039, registered address as above. The information contained in this email message may be privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this transmission is strictly prohibited. If you have received this communication in error, or if any problems occur with transmission, please notify the sender immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bob.sauvage at gmx.fr Thu Jan 24 10:04:34 2013 From: Bob.sauvage at gmx.fr (Bob Sauvage) Date: Thu, 24 Jan 2013 11:04:34 +0100 Subject: [Freeipa-users] Re : Re: Re : Re: Some interrogations about the freeipa deployment Message-ID: <20130124100434.186910@gmx.com> Hi Dimitri, Thanks for your response but I'm a little bit confused. Indeed, some users tell me that it's possible to join an IPA domain from a windows workstation and you say this is not possible. I don't have an AD server, I want to configure IPA to act like an AD. My network contains Windows/Linux workstations and I want to centrally manage authentications. Regards ----- Message d'origine ----- De : Dmitri Pal Envoy?s : 24.01.13 00:53 ? : freeipa-users at redhat.com Objet : Re: [Freeipa-users] Re : Re: Some interrogations about the freeipa deployment On 01/23/2013 03:59 PM, Bob Sauvage wrote: > > Hi Dale, > > You mean that if I turn this option to 'yes', I'll be able to connect to the server through SSH without needing to authenticate again ? Even if I'm connected on the domain from a Windows workstation ? > If you setup trusts between IPA and AD then yes. If not then you need to ssh from the system that belongs to the API domain. IPA does not support Windows systems to be joined to IPA domain. But you can configure kerberos for Windows and use local Windows accounts. There are some HowTos on the wiki about it. Alternatively you join Linux systems to AD and use it as your central authentication server then SSO would also work but you will loose ability to manage your Linux related policies. Trusts is probably the best for you but there will be dragons. http://freeipa.org/page/Howto/IPAv3_AD_trust_setup > Regards, > > > >> ----- Message d'origine ----- >> >> De : Dale Macartney >> >> Envoy?s : 22.01.13 23:13 >> >> ? : freeipa-users at redhat.com >> >> Objet : Re: [Freeipa-users] Some interrogations about the freeipa deployment >> >> >> On 01/22/2013 09:51 PM, Steven Jones wrote: > Hi, > I have all done this, so from what you write I think IPA would be a good fit for what you want, except that is the single sign on bit I have not looked to see if that can be done. For http restart you control that via sudo in IPA so its centrally managed, I have this working for one such server though I use the reload option instead. to enable SSO with SSH from a ipa workstation, just edit /etc/ssh/sshd_config and make sure the line below is set to yes "GSSAPIAuthentication yes" If you've just made the change, it won't take effect until SSH is restarted. So do the usual service sshd restart. > I would also not run one instance of IPA myself but with such a small site that's your call. > regards > Steven Jones > Technical Specialist - Linux RHCE > Victoria University, Wellington, NZ > 0064 4 463 6272 > ------------------------- > *From:* freeipa-users-bounces at redhat.com [ freeipa-users-bounces at redhat.com ] on behalf of Bob Sauvage [ Bob.sauvage at gmx.fr ] > *Sent:* Wednesday, 23 January 2013 9:51 a.m. > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] Some interrogations about the freeipa deployment > Hi *, > I plan to review the network architecture of my office. 10 Windows/Linux desktops and 2 Linux servers will be deployed on the network. > I want to install freeipa on the first server to act like an AD DS. I want to authenticate users on the server and controlling what can be done or not by them on the network. 10 other linux web servers should be accessible (console) by specific users and without the need to authenticating again (single sign on). On these web servers, users can issue specific commands like "/etc/init.d/httpd restart". > Is it possible to achive this with freeipa ? Do you have some articles ? > Thanks in advance, > Bob ! > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users >> > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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? http://www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From root at nachtmaus.us Thu Jan 24 13:19:00 2013 From: root at nachtmaus.us (david t. klein) Date: Thu, 24 Jan 2013 07:19:00 -0600 Subject: [Freeipa-users] Re : Re: Re : Re: Some interrogations about the freeipa deployment In-Reply-To: <20130124100434.186910@gmx.com> References: <20130124100434.186910@gmx.com> Message-ID: <04da01cdfa35$60058e80$2010ab80$@us> While you can make it sort of work, it will be a lot more difficulty, and will never work quite how you want. You would be better off using Active Directory or Samba4, and creating trusts between the two domains. -DTK -- david t. klein Cisco Certified Network Associate (CSCO11281885) Linux Professional Institute Certification (LPI000165615) Redhat Certified Engineer (805009745938860) Quis custodiet ipsos custodes? From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Bob Sauvage Sent: Thursday, January 24, 2013 4:05 AM To: dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Re : Re: Re : Re: Some interrogations about the freeipa deployment Hi Dimitri, Thanks for your response but I'm a little bit confused. Indeed, some users tell me that it's possible to join an IPA domain from a windows workstation and you say this is not possible. I don't have an AD server, I want to configure IPA to act like an AD. My network contains Windows/Linux workstations and I want to centrally manage authentications. Regards ----- Message d'origine ----- De : Dmitri Pal Envoy?s : 24.01.13 00:53 ? : freeipa-users at redhat.com Objet : Re: [Freeipa-users] Re : Re: Some interrogations about the freeipa deployment On 01/23/2013 03:59 PM, Bob Sauvage wrote: > > Hi Dale, > > You mean that if I turn this option to 'yes', I'll be able to connect to the server through SSH without needing to authenticate again ? Even if I'm connected on the domain from a Windows workstation ? > If you setup trusts between IPA and AD then yes. If not then you need to ssh from the system that belongs to the API domain. IPA does not support Windows systems to be joined to IPA domain. But you can configure kerberos for Windows and use local Windows accounts. There are some HowTos on the wiki about it. Alternatively you join Linux systems to AD and use it as your central authentication server then SSO would also work but you will loose ability to manage your Linux related policies. Trusts is probably the best for you but there will be dragons. http://freeipa.org/page/Howto/IPAv3_AD_trust_setup > Regards, > > > >> ----- Message d'origine ----- >> >> De : Dale Macartney >> >> Envoy?s : 22.01.13 23:13 >> >> ? : freeipa-users at redhat.com >> >> Objet : Re: [Freeipa-users] Some interrogations about the freeipa deployment >> >> >> On 01/22/2013 09:51 PM, Steven Jones wrote: > Hi, > I have all done this, so from what you write I think IPA would be a good fit for what you want, except that is the single sign on bit I have not looked to see if that can be done. For http restart you control that via sudo in IPA so its centrally managed, I have this working for one such server though I use the reload option instead. to enable SSO with SSH from a ipa workstation, just edit /etc/ssh/sshd_config and make sure the line below is set to yes "GSSAPIAuthentication yes" If you've just made the change, it won't take effect until SSH is restarted. So do the usual service sshd restart. > I would also not run one instance of IPA myself but with such a small site that's your call. > regards > Steven Jones > Technical Specialist - Linux RHCE > Victoria University, Wellington, NZ > 0064 4 463 6272 > ------------------------- > *From:* freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Bob Sauvage [Bob.sauvage at gmx.fr] > *Sent:* Wednesday, 23 January 2013 9:51 a.m. > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] Some interrogations about the freeipa deployment > Hi *, > I plan to review the network architecture of my office. 10 Windows/Linux desktops and 2 Linux servers will be deployed on the network. > I want to install freeipa on the first server to act like an AD DS. I want to authenticate users on the server and controlling what can be done or not by them on the network. 10 other linux web servers should be accessible (console) by specific users and without the need to authenticating again (single sign on). On these web servers, users can issue specific commands like "/etc/init.d/httpd restart". > Is it possible to achive this with freeipa ? Do you have some articles ? > Thanks in advance, > Bob ! > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users >> > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Jan 24 13:53:00 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 24 Jan 2013 15:53:00 +0200 Subject: [Freeipa-users] Re : Re: Re : Re: Some interrogations about the freeipa deployment In-Reply-To: <04da01cdfa35$60058e80$2010ab80$@us> References: <20130124100434.186910@gmx.com> <04da01cdfa35$60058e80$2010ab80$@us> Message-ID: <20130124135300.GL4474@redhat.com> On Thu, 24 Jan 2013, david t. klein wrote: > > >While you can make it sort of work, it will be a lot more difficulty, >and will never work quite how you want. You would be better off using >Active Directory or Samba4, and creating trusts between the two >domains. Samba 4 AD DC does not support cross-forest trusts yet. -- / Alexander Bokovoy From Bob.sauvage at gmx.fr Thu Jan 24 15:53:43 2013 From: Bob.sauvage at gmx.fr (Bob Sauvage) Date: Thu, 24 Jan 2013 16:53:43 +0100 Subject: [Freeipa-users] Re : RE: Re : Re: Re : Re: Some interrogations about the freeipa deployment Message-ID: <20130124155343.186870@gmx.com> I'll give your a concrete example: A developer is connected on his laptop with Windows 7. At startup, he's prompted to login to the domain with his credentials. These credentials are verified by the RHEL server running IPA. Credentials are correct and the user is logged in the domain. => At this point, is this possible ? Now, this user wants to connect through SSH to a RHEL server (another IPA client). He uses PUTTY and he is connecting to the server, no login/password is required, the authentication is done over his IPA connection. => Is this possible ? Now, once connected on the RHEL server, he wants to use the command "reboot now" but this one is not authorized by the IPA server for this user on this server. => Is this possible ? Many thanks, ----- Message d'origine ----- De : david t. klein Envoy?s : 24.01.13 14:19 ? : 'Bob Sauvage', dpal at redhat.com Objet : RE: [Freeipa-users] Re : Re: Re : Re: Some interrogations about the freeipa deployment While you can make it sort of work, it will be a lot more difficulty, and will never work quite how you want. You would be better off using Active Directory or Samba4, and creating trusts between the two domains. -DTK -- david t. klein Cisco Certified Network Associate (CSCO11281885) Linux Professional Institute Certification (LPI000165615) Redhat Certified Engineer (805009745938860) Quis custodiet ipsos custodes? From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Bob Sauvage *Sent:* Thursday, January 24, 2013 4:05 AM *To:* dpal at redhat.com *Cc:* freeipa-users at redhat.com *Subject:* [Freeipa-users] Re : Re: Re : Re: Some interrogations about the freeipa deployment Hi Dimitri, Thanks for your response but I'm a little bit confused. Indeed, some users tell me that it's possible to join an IPA domain from a windows workstation and you say this is not possible. I don't have an AD server, I want to configure IPA to act like an AD. My network contains Windows/Linux workstations and I want to centrally manage authentications. Regards ----- Message d'origine ----- De : Dmitri Pal Envoy?s : 24.01.13 00:53 ? : freeipa-users at redhat.com Objet : Re: [Freeipa-users] Re : Re: Some interrogations about the freeipa deployment On 01/23/2013 03:59 PM, Bob Sauvage wrote: > > Hi Dale, > > You mean that if I turn this option to 'yes', I'll be able to connect to the server through SSH without needing to authenticate again ? Even if I'm connected on the domain from a Windows workstation ? > If you setup trusts between IPA and AD then yes. If not then you need to ssh from the system that belongs to the API domain. IPA does not support Windows systems to be joined to IPA domain. But you can configure kerberos for Windows and use local Windows accounts. There are some HowTos on the wiki about it. Alternatively you join Linux systems to AD and use it as your central authentication server then SSO would also work but you will loose ability to manage your Linux related policies. Trusts is probably the best for you but there will be dragons. http://freeipa.org/page/Howto/IPAv3_AD_trust_setup > Regards, > > > >> ----- Message d'origine ----- >> >> De : Dale Macartney >> >> Envoy?s : 22.01.13 23:13 >> >> ? : freeipa-users at redhat.com >> >> Objet : Re: [Freeipa-users] Some interrogations about the freeipa deployment >> >> >> On 01/22/2013 09:51 PM, Steven Jones wrote: > Hi, > I have all done this, so from what you write I think IPA would be a good fit for what you want, except that is the single sign on bit I have not looked to see if that can be done. For http restart you control that via sudo in IPA so its centrally managed, I have this working for one such server though I use the reload option instead. to enable SSO with SSH from a ipa workstation, just edit /etc/ssh/sshd_config and make sure the line below is set to yes "GSSAPIAuthentication yes" If you've just made the change, it won't take effect until SSH is restarted. So do the usual service sshd restart. > I would also not run one instance of IPA myself but with such a small site that's your call. > regards > Steven Jones > Technical Specialist - Linux RHCE > Victoria University, Wellington, NZ > 0064 4 463 6272 > ------------------------- > *From:* freeipa-users-bounces at redhat.com [ freeipa-users-bounces at redhat.com ] on behalf of Bob Sauvage [ Bob.sauvage at gmx.fr ] > *Sent:* Wednesday, 23 January 2013 9:51 a.m. > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] Some interrogations about the freeipa deployment > Hi *, > I plan to review the network architecture of my office. 10 Windows/Linux desktops and 2 Linux servers will be deployed on the network. > I want to install freeipa on the first server to act like an AD DS. I want to authenticate users on the server and controlling what can be done or not by them on the network. 10 other linux web servers should be accessible (console) by specific users and without the need to authenticating again (single sign on). On these web servers, users can issue specific commands like "/etc/init.d/httpd restart". > Is it possible to achive this with freeipa ? Do you have some articles ? > Thanks in advance, > Bob ! > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users >> > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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? http://www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbarr at snap-interactive.com Thu Jan 24 16:34:28 2013 From: mbarr at snap-interactive.com (Matthew Barr) Date: Thu, 24 Jan 2013 11:34:28 -0500 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: <5100805C.4020706@redhat.com> References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> <51004F9A.6020006@redhat.com> <5100805C.4020706@redhat.com> Message-ID: <8248E16A-9EDA-4918-BD03-10993094E85D@snap-interactive.com> Just reading this over, and the RFE, I've got another possible option. Our standard build uses a key tab of a user with permission to add a host, and that sets the OTP for the kickstart to use. Is it possible to reset the state of the host record to the state where it can use the same install command on an existing host record? Basically, set the OTP again? If i could run a single command to reset the state to allow the OTP to work it would work fairly well.. for example: ipa host-mod wiki01.ayisnap.com --password=foo Background: We've got IPA & puppet. I have to purge the IPA host record & the puppet SSL keys, in order to regenerate them both. Satellite/Spacewalk allows for a rebuild command, but I'm not sure what Katello & foreman will do in the future. Matthew Barr Technical Architect E: mbarr at snap-interactive.com AIM: matthewbarr1 c: (646) 727-0535 From abokovoy at redhat.com Thu Jan 24 17:29:39 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 24 Jan 2013 19:29:39 +0200 Subject: [Freeipa-users] Re : RE: Re : Re: Re : Re: Some interrogations about the freeipa deployment In-Reply-To: <20130124155343.186870@gmx.com> References: <20130124155343.186870@gmx.com> Message-ID: <20130124172939.GM4474@redhat.com> On Thu, 24 Jan 2013, Bob Sauvage wrote: >I'll give your a concrete example: > > A developer is connected on his laptop with Windows 7. At startup, > he's prompted to login to the domain with his credentials. These > credentials are verified by the RHEL server running IPA. Credentials > are correct and the user is logged in the domain. => At this point, is > this possible ? Not directly by IPA. You need to use pGINA and its Kerberos plugin configured against IPA KDC to allow Windows workstations to obtain Kerberos tickets from IPA KDC on user's logon. Your Windows workstation users will need to have same names as IPA domain users and would only exist for the purpose of logon. There were discussions about using pGINA with FreeIPA few years ago, you may search this list mailing archive for details. pGINA has improved since then. > Now, this user wants to connect through SSH to a RHEL server (another > IPA client). He uses PUTTY and he is connecting to the server, no > login/password is required, the authentication is done over his IPA > connection. => Is this possible ? With Kerberos ticket from IPA KDC available it is possible. > Now, once connected on the RHEL server, he wants to use the command > "reboot now" but this one is not authorized by the IPA server for this > user on this server. => Is this possible ? 'sudo reboot now', that's possible. -- / Alexander Bokovoy From Steven.Jones at vuw.ac.nz Thu Jan 24 20:12:24 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 24 Jan 2013 20:12:24 +0000 Subject: [Freeipa-users] Re : Re: Re : Re: Some interrogations about the freeipa deployment In-Reply-To: <20130124100434.186910@gmx.com> References: <20130124100434.186910@gmx.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40547A9190@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, What's possible and what's practical could well be 2 different things. So yes you may get say XP to join, whether its stable, reliable, gives you the functionality you need and wont take a huge effort to look after is something else. I realise there is the nirvana ideal that says get one "AD" to rule them all, but simply that isn't simple. Sure IPA acts like an AD for Linux but pretty much Red Hat linux at that. We will see other linux distros become as effortless and more "real" Unix happen as the eco-system develops, but managing windows and all its versions in a practical sense? cant see it. So if you want to manage windows platforms at the lowest overall cost, lowest risk, minimal impact to your users and least effort buy a Win2k8R2 server licence and run it in a virtual environment, this is what I do at home and it will work well for say 5~100 users. (NB we do it at work at well, just there is a huge difference between 5 users and 20000) You then can sync the IPA and AD with winsync. If that is too complex and you only want authentications then consider AD with something like Likewise Express which is free and connect your linux kit to AD, its limited but its simple/trivial. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Bob Sauvage [Bob.sauvage at gmx.fr] Sent: Thursday, 24 January 2013 11:04 p.m. To: dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Re : Re: Re : Re: Some interrogations about the freeipa deployment Hi Dimitri, Thanks for your response but I'm a little bit confused. Indeed, some users tell me that it's possible to join an IPA domain from a windows workstation and you say this is not possible. I don't have an AD server, I want to configure IPA to act like an AD. My network contains Windows/Linux workstations and I want to centrally manage authentications. Regards ----- Message d'origine ----- De : Dmitri Pal Envoy?s : 24.01.13 00:53 ? : freeipa-users at redhat.com Objet : Re: [Freeipa-users] Re : Re: Some interrogations about the freeipa deployment On 01/23/2013 03:59 PM, Bob Sauvage wrote: > > Hi Dale, > > You mean that if I turn this option to 'yes', I'll be able to connect to the server through SSH without needing to authenticate again ? Even if I'm connected on the domain from a Windows workstation ? > If you setup trusts between IPA and AD then yes. If not then you need to ssh from the system that belongs to the API domain. IPA does not support Windows systems to be joined to IPA domain. But you can configure kerberos for Windows and use local Windows accounts. There are some HowTos on the wiki about it. Alternatively you join Linux systems to AD and use it as your central authentication server then SSO would also work but you will loose ability to manage your Linux related policies. Trusts is probably the best for you but there will be dragons. http://freeipa.org/page/Howto/IPAv3_AD_trust_setup > Regards, > > > >> ----- Message d'origine ----- >> >> De : Dale Macartney >> >> Envoy?s : 22.01.13 23:13 >> >> ? : freeipa-users at redhat.com >> >> Objet : Re: [Freeipa-users] Some interrogations about the freeipa deployment >> >> >> On 01/22/2013 09:51 PM, Steven Jones wrote: > Hi, > I have all done this, so from what you write I think IPA would be a good fit for what you want, except that is the single sign on bit I have not looked to see if that can be done. For http restart you control that via sudo in IPA so its centrally managed, I have this working for one such server though I use the reload option instead. to enable SSO with SSH from a ipa workstation, just edit /etc/ssh/sshd_config and make sure the line below is set to yes "GSSAPIAuthentication yes" If you've just made the change, it won't take effect until SSH is restarted. So do the usual service sshd restart. > I would also not run one instance of IPA myself but with such a small site that's your call. > regards > Steven Jones > Technical Specialist - Linux RHCE > Victoria University, Wellington, NZ > 0064 4 463 6272 > ------------------------- > *From:* freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Bob Sauvage [Bob.sauvage at gmx.fr] > *Sent:* Wednesday, 23 January 2013 9:51 a.m. > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] Some interrogations about the freeipa deployment > Hi *, > I plan to review the network architecture of my office. 10 Windows/Linux desktops and 2 Linux servers will be deployed on the network. > I want to install freeipa on the first server to act like an AD DS. I want to authenticate users on the server and controlling what can be done or not by them on the network. 10 other linux web servers should be accessible (console) by specific users and without the need to authenticating again (single sign on). On these web servers, users can issue specific commands like "/etc/init.d/httpd restart". > Is it possible to achive this with freeipa ? Do you have some articles ? > Thanks in advance, > Bob ! > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users >> > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chillermillerlong at hotmail.com Thu Jan 24 21:21:25 2013 From: chillermillerlong at hotmail.com (=?utf-8?B?5bCP6b6ZIOmZiA==?=) Date: Thu, 24 Jan 2013 16:21:25 -0500 Subject: [Freeipa-users] Trouble with ipa-server-install in Fedora 18 Message-ID: Hi everyone, I have been having trouble getting FreeIPA set up on Fedora 18. ipa-server-install keeps failing at the "[2/20]: configuring certificate server instance" stage. This is on a fresh Fedora 18 virtual machine. I never had any issues on any of the Fedora 18 prereleases. ipa-server-install output:?http://paste.kde.org/655916/raw/ rpm -qa | grep freeipa | sort:?http://paste.kde.org/655928/raw/ /var/log/ipaserver-install.log:?http://ompldr.org/vaDdsOA/ipaserver-install.log If I copy the pkispawn configuration from the log to?/tmp/tmpZmif5T and run the failed command, I get:?http://paste.kde.org/655940/raw/ Does anyone know what could be the problem? I can't seem to find anything about that error. Thanks in advance! Xiao-Long Chen From rcritten at redhat.com Thu Jan 24 21:32:47 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jan 2013 16:32:47 -0500 Subject: [Freeipa-users] Trouble with ipa-server-install in Fedora 18 In-Reply-To: References: Message-ID: <5101A87F.9080501@redhat.com> ?? ? wrote: > Hi everyone, > > I have been having trouble getting FreeIPA set up on Fedora 18. ipa-server-install > keeps failing at the "[2/20]: configuring certificate server instance" stage. This is > on a fresh Fedora 18 virtual machine. I never had any issues on any of the Fedora 18 > prereleases. > > ipa-server-install output: http://paste.kde.org/655916/raw/ > rpm -qa | grep freeipa | sort: http://paste.kde.org/655928/raw/ > /var/log/ipaserver-install.log: http://ompldr.org/vaDdsOA/ipaserver-install.log > > If I copy the pkispawn configuration from the log to /tmp/tmpZmif5T and run the > failed command, I get: http://paste.kde.org/655940/raw/ > > Does anyone know what could be the problem? I can't seem to find anything about > that error. > Looks like a bug in pki-core: 2013-01-24T20:18:55Z DEBUG stderr=Traceback (most recent call last): File "/usr/sbin/pkispawn", line 220, in main(sys.argv) File "/usr/sbin/pkispawn", line 158, in main rv = parser.read_pki_configuration_file() File "/usr/lib/python2.7/site-packages/pki/deployment/pkiparser.py", line 229, in read_pki_configuration_file config.pki_subsystem_dict = dict(self.pki_config.items('CA')) File "/usr/lib64/python2.7/ConfigParser.py", line 655, in items for option in options] File "/usr/lib64/python2.7/ConfigParser.py", line 691, in _interpolate self._interpolate_some(option, L, rawval, section, vars, 1) File "/usr/lib64/python2.7/ConfigParser.py", line 732, in _interpolate_some "'%%' must be followed by '%%' or '(', found: %r" % (rest,)) ConfigParser.InterpolationSyntaxError: '%' must be followed by '%' or '(', found: '%' If you are using % or ( in your DM password you might try a different password as a workaround. rob From eric at zymeworks.com Thu Jan 24 21:36:04 2013 From: eric at zymeworks.com (Eric Chennells) Date: Thu, 24 Jan 2013 13:36:04 -0800 Subject: [Freeipa-users] Windows XP Client problem In-Reply-To: <20130124071025.GA9204@fluxcoil.net> Message-ID: Hi Christian / Dmitri, Yes I have confirmed in the KDC logs that when I attempt to login that the kerberos server is recognizing the request and issuing a ticket. Is anyone aware of if there is an LDAP related configuration needed? It seems like only setting up the kerberos authentication is not enough. Eric On 2013-01-23 11:10 PM, "Christian Horn" wrote: >Hi, > >On Wed, Jan 23, 2013 at 02:50:06PM -0800, Eric Chennells wrote: >> >> I have followed the instuctions of these two guides: >> >>http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Using_Mi >>cro >> soft_Windows.html >> http://freeipa.org/page/Windows_authentication_against_FreeIPA >> >> Kerberos is working, because I can do a kinit username and properly >>receive >> a krbtgt principle. >> >> However on login I get the error "The system could not log you on". >> >> For the map user step I did "ksetup /mapuser * *" and have a local user >> created with the same username as the IPA user. >> >> Is there a step I am missing? I feel as though I am close because >>kerberos >> is working. > >Looking at the KDC logs when you try to login might bring a pointer, >no idea apart from that.. > >Christian > >_______________________________________________ >Freeipa-users mailing list >Freeipa-users at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-users Notice of Confidentiality: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error please contact the sender immediately by return electronic transmission and then immediately delete this transmission including all attachments without copying, distributing or disclosing the same. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Thu Jan 24 21:51:22 2013 From: sakodak at gmail.com (KodaK) Date: Thu, 24 Jan 2013 15:51:22 -0600 Subject: [Freeipa-users] non-expiring password policy (or as close as I can come) Message-ID: I have a need to have certain mission critical application accounts non-expiring (people don't log in directly, but if the accounts expire it could stop production jobs.) I've set "Max lifetime (days)" to 99999 in the web interface, but here's what I see when I do "ipa pwpolicy show": Group: application-accounts Max lifetime (days): 8639913600 Min lifetime (hours): 0 History size: 0 Character classes: 3 Min length: 8 Priority: 0 Max failures: 0 Failure reset interval: 0 Lockout duration: 0 I have a user that is a member of the application-accounts group and they reset their password yesterday, but their password is set to expire in three months: krbpasswordexpiration: 20130423220808Z krbpwdpolicyreference: cn=application-accounts Have I hit some maximum and I'm confusing IPA? Or do I completely misunderstand these entries? I also have a case open with RH on this, but I haven't heard anything back yet. If I get this solved through them I'll be sure to reply with results. Thanks, --Jason From rcritten at redhat.com Thu Jan 24 22:03:00 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jan 2013 17:03:00 -0500 Subject: [Freeipa-users] non-expiring password policy (or as close as I can come) In-Reply-To: References: Message-ID: <5101AF94.6090201@redhat.com> KodaK wrote: > I have a need to have certain mission critical application accounts > non-expiring (people don't log in directly, but if the accounts expire > it could stop production jobs.) > > I've set "Max lifetime (days)" to 99999 in the web interface, but > here's what I see when I do "ipa pwpolicy show": > > Group: application-accounts > Max lifetime (days): 8639913600 > Min lifetime (hours): 0 > History size: 0 > Character classes: 3 > Min length: 8 > Priority: 0 > Max failures: 0 > Failure reset interval: 0 > Lockout duration: 0 > > I have a user that is a member of the application-accounts group and > they reset their password yesterday, but their password is set to > expire in three months: > > krbpasswordexpiration: 20130423220808Z > krbpwdpolicyreference: cn=application-accounts > > Have I hit some maximum and I'm confusing IPA? Or do I completely > misunderstand these entries? > > I also have a case open with RH on this, but I haven't heard anything > back yet. If I get this solved through them I'll be sure to reply > with results. It is a 32-bit time problem. I'd set the maxlife no higher than 5000 for now. rob From Steven.Jones at vuw.ac.nz Thu Jan 24 22:07:38 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 24 Jan 2013 22:07:38 +0000 Subject: [Freeipa-users] non-expiring password policy (or as close as I can come) In-Reply-To: <5101AF94.6090201@redhat.com> References: , <5101AF94.6090201@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40547A9218@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, That could explain why 9999 hasnt worked for my service accounts. Is this fixed in 6.4? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Rob Crittenden [rcritten at redhat.com] Sent: Friday, 25 January 2013 11:03 a.m. To: KodaK Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] non-expiring password policy (or as close as I can come) KodaK wrote: > I have a need to have certain mission critical application accounts > non-expiring (people don't log in directly, but if the accounts expire > it could stop production jobs.) > > I've set "Max lifetime (days)" to 99999 in the web interface, but > here's what I see when I do "ipa pwpolicy show": > > Group: application-accounts > Max lifetime (days): 8639913600 > Min lifetime (hours): 0 > History size: 0 > Character classes: 3 > Min length: 8 > Priority: 0 > Max failures: 0 > Failure reset interval: 0 > Lockout duration: 0 > > I have a user that is a member of the application-accounts group and > they reset their password yesterday, but their password is set to > expire in three months: > > krbpasswordexpiration: 20130423220808Z > krbpwdpolicyreference: cn=application-accounts > > Have I hit some maximum and I'm confusing IPA? Or do I completely > misunderstand these entries? > > I also have a case open with RH on this, but I haven't heard anything > back yet. If I get this solved through them I'll be sure to reply > with results. It is a 32-bit time problem. I'd set the maxlife no higher than 5000 for now. rob _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Thu Jan 24 22:12:59 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jan 2013 17:12:59 -0500 Subject: [Freeipa-users] non-expiring password policy (or as close as I can come) In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40547A9218@STAWINCOX10MBX1.staff.vuw.ac.nz> References: , <5101AF94.6090201@redhat.com> <833D8E48405E064EBC54C84EC6B36E40547A9218@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5101B1EB.1080307@redhat.com> Steven Jones wrote: > Hi, > > That could explain why 9999 hasnt worked for my service accounts. > > Is this fixed in 6.4? No, we are still working on the fix on the freeipa-devel list. rob > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Rob Crittenden [rcritten at redhat.com] > Sent: Friday, 25 January 2013 11:03 a.m. > To: KodaK > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] non-expiring password policy (or as close as I can come) > > KodaK wrote: >> I have a need to have certain mission critical application accounts >> non-expiring (people don't log in directly, but if the accounts expire >> it could stop production jobs.) >> >> I've set "Max lifetime (days)" to 99999 in the web interface, but >> here's what I see when I do "ipa pwpolicy show": >> >> Group: application-accounts >> Max lifetime (days): 8639913600 >> Min lifetime (hours): 0 >> History size: 0 >> Character classes: 3 >> Min length: 8 >> Priority: 0 >> Max failures: 0 >> Failure reset interval: 0 >> Lockout duration: 0 >> >> I have a user that is a member of the application-accounts group and >> they reset their password yesterday, but their password is set to >> expire in three months: >> >> krbpasswordexpiration: 20130423220808Z >> krbpwdpolicyreference: cn=application-accounts >> >> Have I hit some maximum and I'm confusing IPA? Or do I completely >> misunderstand these entries? >> >> I also have a case open with RH on this, but I haven't heard anything >> back yet. If I get this solved through them I'll be sure to reply >> with results. > > It is a 32-bit time problem. > > I'd set the maxlife no higher than 5000 for now. > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From sakodak at gmail.com Thu Jan 24 22:17:34 2013 From: sakodak at gmail.com (KodaK) Date: Thu, 24 Jan 2013 16:17:34 -0600 Subject: [Freeipa-users] non-expiring password policy (or as close as I can come) In-Reply-To: <5101AF94.6090201@redhat.com> References: <5101AF94.6090201@redhat.com> Message-ID: On Thu, Jan 24, 2013 at 4:03 PM, Rob Crittenden wrote: > It is a 32-bit time problem. > > I'd set the maxlife no higher than 5000 for now. Thanks. Is there a way to apply this policy retroactively without requiring my users to reset passwords? --Jason From rcritten at redhat.com Thu Jan 24 22:19:15 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jan 2013 17:19:15 -0500 Subject: [Freeipa-users] non-expiring password policy (or as close as I can come) In-Reply-To: References: <5101AF94.6090201@redhat.com> Message-ID: <5101B363.8060409@redhat.com> KodaK wrote: > On Thu, Jan 24, 2013 at 4:03 PM, Rob Crittenden wrote: >> It is a 32-bit time problem. >> >> I'd set the maxlife no higher than 5000 for now. > > Thanks. Is there a way to apply this policy retroactively without > requiring my users to reset passwords? > > --Jason > You'd have to manually tweak the password expiration in the records using ldapmodify. rob From sigbjorn at nixtra.com Thu Jan 24 23:05:22 2013 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 25 Jan 2013 00:05:22 +0100 Subject: [Freeipa-users] non-expiring password policy (or as close as I can come) In-Reply-To: References: <5101AF94.6090201@redhat.com> Message-ID: <5101BE32.1000007@nixtra.com> On 01/24/2013 11:17 PM, KodaK wrote: > On Thu, Jan 24, 2013 at 4:03 PM, Rob Crittenden wrote: >> It is a 32-bit time problem. >> >> I'd set the maxlife no higher than 5000 for now. > > Thanks. Is there a way to apply this policy retroactively without > requiring my users to reset passwords? > A calender will be shown to choose a date and time for simplicity if you download and use the Apache Directory Studio (http://directory.apache.org/studio/) to edit the krbPasswordExpiration attribute for an user account. It works well. Regards, Siggi From sakodak at gmail.com Thu Jan 24 23:17:25 2013 From: sakodak at gmail.com (KodaK) Date: Thu, 24 Jan 2013 17:17:25 -0600 Subject: [Freeipa-users] non-expiring password policy (or as close as I can come) In-Reply-To: <5101BE32.1000007@nixtra.com> References: <5101AF94.6090201@redhat.com> <5101BE32.1000007@nixtra.com> Message-ID: On Thu, Jan 24, 2013 at 5:05 PM, Sigbjorn Lie wrote: > A calender will be shown to choose a date and time for simplicity if you > download and use the Apache Directory Studio > (http://directory.apache.org/studio/) to edit the krbPasswordExpiration > attribute for an user account. It works well. This is exactly what I ended up doing. I didn't have many, otherwise I would have rigged up an ldapmodify script. From dpal at redhat.com Thu Jan 24 23:53:42 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 24 Jan 2013 18:53:42 -0500 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: <8248E16A-9EDA-4918-BD03-10993094E85D@snap-interactive.com> References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> <51004F9A.6020006@redhat.com> <5100805C.4020706@redhat.com> <8248E16A-9EDA-4918-BD03-10993094E85D@snap-interactive.com> Message-ID: <5101C986.3010109@redhat.com> On 01/24/2013 11:34 AM, Matthew Barr wrote: > Just reading this over, and the RFE, I've got another possible option. > > Our standard build uses a key tab of a user with permission to add a host, and that sets the OTP for the kickstart to use. > > Is it possible to reset the state of the host record to the state where it can use the same install command on an existing host record? Basically, set the OTP again? > > If i could run a single command to reset the state to allow the OTP to work it would work fairly well.. > > for example: ipa host-mod wiki01.ayisnap.com --password=foo Yes you can set it again. This is how we envisioned the feature to be used. If it does not work it is a bug. > > > Background: > > We've got IPA & puppet. I have to purge the IPA host record & the puppet SSL keys, in order to regenerate them both. Satellite/Spacewalk allows for a rebuild command, but I'm not sure what Katello & foreman will do in the future. > > > > > Matthew Barr > Technical Architect > E: mbarr at snap-interactive.com > AIM: matthewbarr1 > c: (646) 727-0535 > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From bret.wortman at damascusgrp.com Thu Jan 24 23:56:02 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Thu, 24 Jan 2013 18:56:02 -0500 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: <5101C986.3010109@redhat.com> References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> <51004F9A.6020006@redhat.com> <5100805C.4020706@redhat.com> <8248E16A-9EDA-4918-BD03-10993094E85D@snap-interactive.com> <5101C986.3010109@redhat.com> Message-ID: <3595316F5E8A4F10AD1D69BB0832A99C@damascusgrp.com> It works like a champ for me. -- Bret Wortman http://bretwortman.com/ http://twitter.com/bretwortman On Thursday, January 24, 2013 at 6:53 PM, Dmitri Pal wrote: > On 01/24/2013 11:34 AM, Matthew Barr wrote: > > Just reading this over, and the RFE, I've got another possible option. > > > > Our standard build uses a key tab of a user with permission to add a host, and that sets the OTP for the kickstart to use. > > > > Is it possible to reset the state of the host record to the state where it can use the same install command on an existing host record? Basically, set the OTP again? > > > > If i could run a single command to reset the state to allow the OTP to work it would work fairly well.. > > > > for example: ipa host-mod wiki01.ayisnap.com --password=foo > > Yes you can set it again. This is how we envisioned the feature to be used. > If it does not work it is a bug. > > > > > > > Background: > > > > We've got IPA & puppet. I have to purge the IPA host record & the puppet SSL keys, in order to regenerate them both. Satellite/Spacewalk allows for a rebuild command, but I'm not sure what Katello & foreman will do in the future. > > > > > > > > > > Matthew Barr > > Technical Architect > > E: mbarr at snap-interactive.com > > AIM: matthewbarr1 > > c: (646) 727-0535 > > > > > > -- > 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 at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Jan 25 00:02:58 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 24 Jan 2013 19:02:58 -0500 Subject: [Freeipa-users] Re : RE: Re : Re: Re : Re: Some interrogations about the freeipa deployment In-Reply-To: <20130124172939.GM4474@redhat.com> References: <20130124155343.186870@gmx.com> <20130124172939.GM4474@redhat.com> Message-ID: <5101CBB2.1020600@redhat.com> On 01/24/2013 12:29 PM, Alexander Bokovoy wrote: > On Thu, 24 Jan 2013, Bob Sauvage wrote: >> I'll give your a concrete example: >> >> A developer is connected on his laptop with Windows 7. At startup, >> he's prompted to login to the domain with his credentials. These >> credentials are verified by the RHEL server running IPA. Credentials >> are correct and the user is logged in the domain. => At this point, is >> this possible ? > Not directly by IPA. You need to use pGINA and its Kerberos plugin > configured against IPA KDC to allow Windows workstations to obtain > Kerberos tickets from IPA KDC on user's logon. Your Windows workstation > users will need to have same names as IPA domain users and would only > exist for the purpose of logon. > > There were discussions about using pGINA with FreeIPA few years ago, you > may search this list mailing archive for details. pGINA has improved > since then. > >> Now, this user wants to connect through SSH to a RHEL server (another >> IPA client). He uses PUTTY and he is connecting to the server, no >> login/password is required, the authentication is done over his IPA >> connection. => Is this possible ? > With Kerberos ticket from IPA KDC available it is possible. > >> Now, once connected on the RHEL server, he wants to use the command >> "reboot now" but this one is not authorized by the IPA server for this >> user on this server. => Is this possible ? > 'sudo reboot now', that's possible. > If you do not want to introduce AD your Windows systems would have limited capabilities. The use cases that you listed would work but this does not mean that other things that you expect from the Windows client joined to an AD domain controller would work out of box. This is why we suggest AD to rule windows clients and IPA for linux clients. If you want SSO across domains the best option is to establish trusts between the two domains AD and IPA. Sync solution would work too but in case of SSH you would have to use password auth rather than SSO to get from windows worksation into Linux box, i.e. SSO cross platform would not work. HTH -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Jan 25 00:05:57 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 24 Jan 2013 19:05:57 -0500 Subject: [Freeipa-users] Windows XP Client problem In-Reply-To: References: Message-ID: <5101CC65.2020507@redhat.com> On 01/24/2013 04:36 PM, Eric Chennells wrote: > Hi Christian / Dmitri, > > Yes I have confirmed in the KDC logs that when I attempt to login that the > kerberos server is recognizing the request and issuing a ticket. > > Is anyone aware of if there is an LDAP related configuration needed? It > seems like only setting up the kerberos authentication is not enough. Have you compared the name of the local user you created on the windows system to the name of the IPA user you are using? Do they match? > > Eric > > > On 2013-01-23 11:10 PM, "Christian Horn" wrote: > > >Hi, > > > >On Wed, Jan 23, 2013 at 02:50:06PM -0800, Eric Chennells wrote: > >> > >> I have followed the instuctions of these two guides: > >> > >>http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Using_Mi > >>cro > >> soft_Windows.html > >> http://freeipa.org/page/Windows_authentication_against_FreeIPA > >> > >> Kerberos is working, because I can do a kinit username and properly > >>receive > >> a krbtgt principle. > >> > >> However on login I get the error "The system could not log you on". > >> > >> For the map user step I did "ksetup /mapuser * *" and have a local user > >> created with the same username as the IPA user. > >> > >> Is there a step I am missing? I feel as though I am close because > >>kerberos > >> is working. > > > >Looking at the KDC logs when you try to login might bring a pointer, > >no idea apart from that.. > > > >Christian > > > >_______________________________________________ > >Freeipa-users mailing list > >Freeipa-users at redhat.com > >https://www.redhat.com/mailman/listinfo/freeipa-users > > > > Notice of Confidentiality: The information transmitted is intended > only for the > person or entity to which it is addressed and may contain confidential > and/or > privileged material. Any review, re-transmission, dissemination or > other use of > or taking of any action in reliance upon this information by persons > or entities > other than the intended recipient is prohibited. If you received this > in error > please contact the sender immediately by return electronic > transmission and then > immediately delete this transmission including all attachments without > copying, > distributing or disclosing the same. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From root at nachtmaus.us Fri Jan 25 02:14:07 2013 From: root at nachtmaus.us (david t. klein) Date: Thu, 24 Jan 2013 20:14:07 -0600 Subject: [Freeipa-users] Re : Re: Re : Re: Some interrogations about the freeipa deployment In-Reply-To: <20130124135300.GL4474@redhat.com> References: <20130124100434.186910@gmx.com> <04da01cdfa35$60058e80$2010ab80$@us> <20130124135300.GL4474@redhat.com> Message-ID: <059d01cdfaa1$a8c45450$fa4cfcf0$@us> Thank you for clarifying. I had thought they said that was planned for 1.0 release, but it has been a while since I last looked at Samba4, other than to skim the press releases a couple of weeks ago, when it actually released. -DTK -- david t. klein Cisco Certified Network Associate (CSCO11281885) Linux Professional Institute Certification (LPI000165615) Redhat Certified Engineer (805009745938860) Quis custodiet ipsos custodes? -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Thursday, January 24, 2013 7:53 AM To: david t. klein Cc: 'Bob Sauvage'; dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Re : Re: Re : Re: Some interrogations about the freeipa deployment On Thu, 24 Jan 2013, david t. klein wrote: > > >While you can make it sort of work, it will be a lot more difficulty, >and will never work quite how you want. You would be better off using >Active Directory or Samba4, and creating trusts between the two >domains. Samba 4 AD DC does not support cross-forest trusts yet. -- / Alexander Bokovoy From mbarr at snap-interactive.com Fri Jan 25 02:36:54 2013 From: mbarr at snap-interactive.com (Matthew Barr) Date: Thu, 24 Jan 2013 21:36:54 -0500 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: <5101C986.3010109@redhat.com> References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> <51004F9A.6020006@redhat.com> <5100805C.4020706@redhat.com> <8248E16A-9EDA-4918-BD03-10993094E85D@snap-interactive.com> <5101C986.3010109@redhat.com> Message-ID: <89694CF9-EDA9-4EF3-892D-70B5FDA31626@snap-interactive.com> On Jan 24, 2013, at 6:53 PM, Dmitri Pal wrote: > > Yes you can set it again. This is how we envisioned the feature to be used. > If it does not work it is a bug. ipa-server-2.2.0-16.el6.x86_64, Centos 6.3 [mbarr at ipa ~]$ ipa host-mod wiki01.ayisnap.com --password=foo ipa: ERROR: invalid 'password': Password cannot be set on enrolled host. Matthew From simo at redhat.com Fri Jan 25 02:40:28 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 24 Jan 2013 21:40:28 -0500 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: <89694CF9-EDA9-4EF3-892D-70B5FDA31626@snap-interactive.com> References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> <51004F9A.6020006@redhat.com> <5100805C.4020706@redhat.com> <8248E16A-9EDA-4918-BD03-10993094E85D@snap-interactive.com> <5101C986.3010109@redhat.com> <89694CF9-EDA9-4EF3-892D-70B5FDA31626@snap-interactive.com> Message-ID: <1359081628.20683.524.camel@willson.li.ssimo.org> On Thu, 2013-01-24 at 21:36 -0500, Matthew Barr wrote: > On Jan 24, 2013, at 6:53 PM, Dmitri Pal wrote: > > > > Yes you can set it again. This is how we envisioned the feature to be used. > > If it does not work it is a bug. > > > ipa-server-2.2.0-16.el6.x86_64, Centos 6.3 > > [mbarr at ipa ~]$ ipa host-mod wiki01.ayisnap.com --password=foo > ipa: ERROR: invalid 'password': Password cannot be set on enrolled host. Matthew this is indeed the correct behavior, previous information from Dmitri was not correct. Once a host is enrolled you cannot reset the OTP password as that would effectively mean destroying the hosts credentials while the host is enrolled. Currently the IPA workflow expects you unenroll the client first. Simo. -- Simo Sorce * Red Hat, Inc * New York From natxo.asenjo at gmail.com Fri Jan 25 07:44:49 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 25 Jan 2013 08:44:49 +0100 Subject: [Freeipa-users] non-expiring password policy (or as close as I can come) In-Reply-To: References: Message-ID: On Thu, Jan 24, 2013 at 10:51 PM, KodaK wrote: > I have a need to have certain mission critical application accounts > non-expiring (people don't log in directly, but if the accounts expire > it could stop production jobs.) Without knowing anything about this particular case, could you not use a service account autheticated with a keytab? I have succesfully used this for authenticating webapps to postgresql, you just need to schedule a renewal of the ticket in cron and use the $KRB5CCNAME environment variable to point to the right place. It was surprisingly easy and works very well. -- groet, natxo From fvzwieten at vxcompany.com Fri Jan 25 08:35:20 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Fri, 25 Jan 2013 09:35:20 +0100 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: <1359081628.20683.524.camel@willson.li.ssimo.org> References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> <51004F9A.6020006@redhat.com> <5100805C.4020706@redhat.com> <8248E16A-9EDA-4918-BD03-10993094E85D@snap-interactive.com> <5101C986.3010109@redhat.com> <89694CF9-EDA9-4EF3-892D-70B5FDA31626@snap-interactive.com> <1359081628.20683.524.camel@willson.li.ssimo.org> Message-ID: And, using the ipa command is only possible on ipa clients. Although our Satellite server is an IPA client, I am (as of yet) unable to execute ipa commands from any ipa client prior to the re-install request from Satellite. There is, afaik, no such thing as a pre-reinstall hook or anything like that. As for the ipa-host-mod --password=foo thing. You can first run the command "ipa disable-host and _then_ run "ipa host-mod --password=foo Met vriendelijke groeten, * Fred van Zwieten * *Enterprise Open Source Services* * Consultant* *(vrijdags afwezig)* *VX Company IT Services B.V.* *T* (035) 539 09 50 mobiel (06) 41 68 28 48 *F* (035) 539 09 08 *E* fvzwieten at vxcompany.com *I* www.vxcompany.com On Fri, Jan 25, 2013 at 3:40 AM, Simo Sorce wrote: > On Thu, 2013-01-24 at 21:36 -0500, Matthew Barr wrote: > > On Jan 24, 2013, at 6:53 PM, Dmitri Pal wrote: > > > > > > Yes you can set it again. This is how we envisioned the feature to be > used. > > > If it does not work it is a bug. > > > > > > ipa-server-2.2.0-16.el6.x86_64, Centos 6.3 > > > > [mbarr at ipa ~]$ ipa host-mod wiki01.ayisnap.com --password=foo > > ipa: ERROR: invalid 'password': Password cannot be set on enrolled host. > > Matthew this is indeed the correct behavior, previous information from > Dmitri was not correct. > > Once a host is enrolled you cannot reset the OTP password as that would > effectively mean destroying the hosts credentials while the host is > enrolled. Currently the IPA workflow expects you unenroll the client > first. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Fri Jan 25 15:44:05 2013 From: alee at redhat.com (Ade Lee) Date: Fri, 25 Jan 2013 10:44:05 -0500 Subject: [Freeipa-users] Trouble with ipa-server-install in Fedora 18 In-Reply-To: <5101A87F.9080501@redhat.com> References: <5101A87F.9080501@redhat.com> Message-ID: <1359128645.2320.1.camel@aleeredhat.laptop> Can you confirm that using a password without % or ( in it resolves the issue? On Thu, 2013-01-24 at 16:32 -0500, Rob Crittenden wrote: > ?? ? wrote: > > Hi everyone, > > > > I have been having trouble getting FreeIPA set up on Fedora 18. ipa-server-install > > keeps failing at the "[2/20]: configuring certificate server instance" stage. This is > > on a fresh Fedora 18 virtual machine. I never had any issues on any of the Fedora 18 > > prereleases. > > > > ipa-server-install output: http://paste.kde.org/655916/raw/ > > rpm -qa | grep freeipa | sort: http://paste.kde.org/655928/raw/ > > /var/log/ipaserver-install.log: http://ompldr.org/vaDdsOA/ipaserver-install.log > > > > If I copy the pkispawn configuration from the log to /tmp/tmpZmif5T and run the > > failed command, I get: http://paste.kde.org/655940/raw/ > > > > Does anyone know what could be the problem? I can't seem to find anything about > > that error. > > > > Looks like a bug in pki-core: > > 2013-01-24T20:18:55Z DEBUG stderr=Traceback (most recent call last): > File "/usr/sbin/pkispawn", line 220, in > main(sys.argv) > File "/usr/sbin/pkispawn", line 158, in main > rv = parser.read_pki_configuration_file() > File "/usr/lib/python2.7/site-packages/pki/deployment/pkiparser.py", > line 229, in read_pki_configuration_file > config.pki_subsystem_dict = dict(self.pki_config.items('CA')) > File "/usr/lib64/python2.7/ConfigParser.py", line 655, in items > for option in options] > File "/usr/lib64/python2.7/ConfigParser.py", line 691, in _interpolate > self._interpolate_some(option, L, rawval, section, vars, 1) > File "/usr/lib64/python2.7/ConfigParser.py", line 732, in > _interpolate_some > "'%%' must be followed by '%%' or '(', found: %r" % (rest,)) > ConfigParser.InterpolationSyntaxError: '%' must be followed by '%' or > '(', found: '%' > > If you are using % or ( in your DM password you might try a different > password as a workaround. > > rob From mbarr at snap-interactive.com Fri Jan 25 16:28:42 2013 From: mbarr at snap-interactive.com (Matthew Barr) Date: Fri, 25 Jan 2013 11:28:42 -0500 Subject: [Freeipa-users] Adding an IPA user that can't SSH? Message-ID: I need to add a few users that can authenticate with IPA (LDAP, in some cases, kerberos in others), but can't SSH into hosts. I'm guessing the best option is to use some sort of group restriction on the SSH /host side, vs anything else in IPA? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Jan 25 16:43:58 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 25 Jan 2013 11:43:58 -0500 Subject: [Freeipa-users] Adding an IPA user that can't SSH? In-Reply-To: References: Message-ID: <5102B64E.2020408@redhat.com> On 01/25/2013 11:28 AM, Matthew Barr wrote: > I need to add a few users that can authenticate with IPA (LDAP, in > some cases, kerberos in others), but can't SSH into hosts. > > I'm guessing the best option is to use some sort of group restriction > on the SSH /host side, vs anything else in IPA? > > Thanks! > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users You can define Host-Based-Access-Control policies. By default any user is allowed to authenticate anywhere. There are no deny HBAC rules so you need to define which users are allowed to do what in your environment. HBAC rules are enforced by SSSD. This means that if you have an app that uses LDAP or kerberos auth bypassing pam stack the HBAC rules do not apply. You need to think it through very well because once you disable the default rule you might get into the situation where the legit authentication of the legit users is denied becuase you have not created a rule allowing those users to login. AFAIK there is also some kind of "no shell" capability in SSH which might be useful in this case but I am not a specialist in this area. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Jan 25 16:47:31 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 25 Jan 2013 11:47:31 -0500 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> <51004F9A.6020006@redhat.com> <5100805C.4020706@redhat.com> <8248E16A-9EDA-4918-BD03-10993094E85D@snap-interactive.com> <5101C986.3010109@redhat.com> <89694CF9-EDA9-4EF3-892D-70B5FDA31626@snap-interactive.com> <1359081628.20683.524.camel@willson.li.ssimo.org> Message-ID: <5102B723.1050003@redhat.com> On 01/25/2013 03:35 AM, Fred van Zwieten wrote: > And, using the ipa command is only possible on ipa clients. > > Although our Satellite server is an IPA client, I am (as of yet) > unable to execute ipa commands from any ipa client prior to the > re-install request from Satellite. There is, afaik, no such thing as a > pre-reinstall hook or anything like that. > Can you please file an RFE against Satellite and pass it to us? It would be much easier for us to have a conversation with Satellite/Spacewalk community. > As for the ipa-host-mod --password=foo thing. You can first run the > command "ipa disable-host and _then_ run "ipa host-mod > --password=foo Yes this is what I meant. Sorry for confusion. > > > Met vriendelijke groeten, > * > Fred van Zwieten > * > *Enterprise Open Source Services* > * > Consultant* > /(vrijdags afwezig)/ > > *VX Company IT Services B.V.* > *T* (035) 539 09 50 mobiel (06) 41 68 28 48 > *F* (035) 539 09 08 > *E* fvzwieten at vxcompany.com > *I* www.vxcompany.com > > > On Fri, Jan 25, 2013 at 3:40 AM, Simo Sorce > wrote: > > On Thu, 2013-01-24 at 21:36 -0500, Matthew Barr wrote: > > On Jan 24, 2013, at 6:53 PM, Dmitri Pal > wrote: > > > > > > Yes you can set it again. This is how we envisioned the > feature to be used. > > > If it does not work it is a bug. > > > > > > ipa-server-2.2.0-16.el6.x86_64, Centos 6.3 > > > > [mbarr at ipa ~]$ ipa host-mod wiki01.ayisnap.com > --password=foo > > ipa: ERROR: invalid 'password': Password cannot be set on > enrolled host. > > Matthew this is indeed the correct behavior, previous information from > Dmitri was not correct. > > Once a host is enrolled you cannot reset the OTP password as that > would > effectively mean destroying the hosts credentials while the host is > enrolled. Currently the IPA workflow expects you unenroll the client > first. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Fri Jan 25 16:51:29 2013 From: sakodak at gmail.com (KodaK) Date: Fri, 25 Jan 2013 10:51:29 -0600 Subject: [Freeipa-users] Adding an IPA user that can't SSH? In-Reply-To: <5102B64E.2020408@redhat.com> References: <5102B64E.2020408@redhat.com> Message-ID: On Fri, Jan 25, 2013 at 10:43 AM, Dmitri Pal wrote: > AFAIK there is also some kind of "no shell" capability in SSH which might be > useful in this case but I am not a specialist in this area. You can do this a few ways, but the easiest (IMO) is something like this in sshd_config: Match User limited-user ForceCommand echo 'This is a non-interactive account' This will cause that message to display if someone tries to log in with that account. From shelltoesuperstar at gmail.com Sat Jan 26 00:57:44 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Sat, 26 Jan 2013 00:57:44 +0000 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: <8248E16A-9EDA-4918-BD03-10993094E85D@snap-interactive.com> References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> <51004F9A.6020006@redhat.com> <5100805C.4020706@redhat.com> <8248E16A-9EDA-4918-BD03-10993094E85D@snap-interactive.com> Message-ID: Hi Matthew, Yes, as said earlier "ipa disable-host ; ipa host-mod --password=foo" works flawlessly. The issue lies with attempting to reuse "foo" as the password, the IPA sever prevents that (and rightly so) which complicates automation hence the RFE. Charlie. On Thu, Jan 24, 2013 at 4:34 PM, Matthew Barr wrote: > Just reading this over, and the RFE, I've got another possible option. > > Our standard build uses a key tab of a user with permission to add a host, > and that sets the OTP for the kickstart to use. > > Is it possible to reset the state of the host record to the state where it > can use the same install command on an existing host record? Basically, > set the OTP again? > > If i could run a single command to reset the state to allow the OTP to > work it would work fairly well.. > > for example: ipa host-mod wiki01.ayisnap.com --password=foo > > > Background: > > We've got IPA & puppet. I have to purge the IPA host record & the puppet > SSL keys, in order to regenerate them both. Satellite/Spacewalk allows for > a rebuild command, but I'm not sure what Katello & foreman will do in the > future. > > > > > Matthew Barr > Technical Architect > E: mbarr at snap-interactive.com > AIM: matthewbarr1 > c: (646) 727-0535 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shelltoesuperstar at gmail.com Sat Jan 26 01:13:09 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Sat, 26 Jan 2013 01:13:09 +0000 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> <51004F9A.6020006@redhat.com> <5100805C.4020706@redhat.com> <8248E16A-9EDA-4918-BD03-10993094E85D@snap-interactive.com> <5101C986.3010109@redhat.com> <89694CF9-EDA9-4EF3-892D-70B5FDA31626@snap-interactive.com> <1359081628.20683.524.camel@willson.li.ssimo.org> Message-ID: Hi Fred Little unsure about what you mean here. What is it you're trying to do exactly? Do you mean you can't run IPA commands on your satellite server? Do you just need to install ipa-admin-tools? Do you mean IPA commands don't work on a IPA client until the client is enrolled? That would make sense as how else would the server authenticate the commands? Jay On Fri, Jan 25, 2013 at 8:35 AM, Fred van Zwieten wrote: > And, using the ipa command is only possible on ipa clients. > > Although our Satellite server is an IPA client, I am (as of yet) unable to > execute ipa commands from any ipa client prior to the re-install request > from Satellite. There is, afaik, no such thing as a pre-reinstall hook or > anything like that. > > As for the ipa-host-mod --password=foo thing. You can first run the > command "ipa disable-host and _then_ run "ipa host-mod > --password=foo > > > Met vriendelijke groeten, > * > Fred van Zwieten > * > *Enterprise Open Source Services* > * > Consultant* > *(vrijdags afwezig)* > > *VX Company IT Services B.V.* > *T* (035) 539 09 50 mobiel (06) 41 68 28 48 > *F* (035) 539 09 08 > *E* fvzwieten at vxcompany.com > *I* www.vxcompany.com > > > On Fri, Jan 25, 2013 at 3:40 AM, Simo Sorce wrote: > >> On Thu, 2013-01-24 at 21:36 -0500, Matthew Barr wrote: >> > On Jan 24, 2013, at 6:53 PM, Dmitri Pal wrote: >> > > >> > > Yes you can set it again. This is how we envisioned the feature to be >> used. >> > > If it does not work it is a bug. >> > >> > >> > ipa-server-2.2.0-16.el6.x86_64, Centos 6.3 >> > >> > [mbarr at ipa ~]$ ipa host-mod wiki01.ayisnap.com --password=foo >> > ipa: ERROR: invalid 'password': Password cannot be set on enrolled host. >> >> Matthew this is indeed the correct behavior, previous information from >> Dmitri was not correct. >> >> Once a host is enrolled you cannot reset the OTP password as that would >> effectively mean destroying the hosts credentials while the host is >> enrolled. Currently the IPA workflow expects you unenroll the client >> first. >> >> Simo. >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fvzwieten at vxcompany.com Sat Jan 26 07:11:15 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Sat, 26 Jan 2013 08:11:15 +0100 Subject: [Freeipa-users] Howto re-deploy an IPA-client using kickstart In-Reply-To: References: <50F1D06A.9080205@redhat.com> <50F981C9.50006@redhat.com> <5100406F.7040101@redhat.com> <51004F9A.6020006@redhat.com> <5100805C.4020706@redhat.com> <8248E16A-9EDA-4918-BD03-10993094E85D@snap-interactive.com> <5101C986.3010109@redhat.com> <89694CF9-EDA9-4EF3-892D-70B5FDA31626@snap-interactive.com> <1359081628.20683.524.camel@willson.li.ssimo.org> Message-ID: On Sat, Jan 26, 2013 at 2:13 AM, Charlie Derwent < shelltoesuperstar at gmail.com> wrote: > Hi Fred > > Little unsure about what you mean here. What is it you're trying to do > exactly? Do you mean you can't run IPA commands on your satellite server? > Do you just need to install ipa-admin-tools? > > Do you mean IPA commands don't work on a IPA client until the client is > enrolled? That would make sense as how else would the server authenticate > the commands? > > First of all, the RFE solves my problem. The discussion was how it might be solved without the RFE in my use case. We redeploy systems using Satellite Web UI. What Satellite basically does when requesting a re-install is scheduling a remote command on the system. This remote command is "koan" (kickstart-over-a-network). Koan will prep the system so it will re-install at the next reboot using the correct kickstart profile, usually through PXE. Now, this to-be-redeployed system is also an IPA-client. In the kickstart file for this system we have "ipa-client-install -w --unattend etc" for unattended enrolledment. The part that is missing is the unattended un-enrollment prior to the systems re-install. I am trying to find a place in the workflow up untill the reboot-before-reinstall sequence to have a script started that does this. Koan would be the ideal candidate, but it does not give this possibility. The RFE solves this problem. I can save the keytab before re-installation and get it back afterwards. Then I can call ipa-client-install with the old keytab to enroll the client, revoke the old keytab and get a new one in one go. I have already also asked about this on the satellite-user mailing-list. Fred > > > > On Fri, Jan 25, 2013 at 8:35 AM, Fred van Zwieten > wrote: > >> And, using the ipa command is only possible on ipa clients. >> >> Although our Satellite server is an IPA client, I am (as of yet) unable >> to execute ipa commands from any ipa client prior to the re-install request >> from Satellite. There is, afaik, no such thing as a pre-reinstall hook or >> anything like that. >> >> As for the ipa-host-mod --password=foo thing. You can first run the >> command "ipa disable-host and _then_ run "ipa host-mod >> --password=foo >> >> >> Met vriendelijke groeten, >> * >> Fred van Zwieten >> * >> *Enterprise Open Source Services* >> * >> Consultant* >> *(vrijdags afwezig)* >> >> *VX Company IT Services B.V.* >> *T* (035) 539 09 50 mobiel (06) 41 68 28 48 >> *F* (035) 539 09 08 >> *E* fvzwieten at vxcompany.com >> *I* www.vxcompany.com >> >> >> On Fri, Jan 25, 2013 at 3:40 AM, Simo Sorce wrote: >> >>> On Thu, 2013-01-24 at 21:36 -0500, Matthew Barr wrote: >>> > On Jan 24, 2013, at 6:53 PM, Dmitri Pal wrote: >>> > > >>> > > Yes you can set it again. This is how we envisioned the feature to >>> be used. >>> > > If it does not work it is a bug. >>> > >>> > >>> > ipa-server-2.2.0-16.el6.x86_64, Centos 6.3 >>> > >>> > [mbarr at ipa ~]$ ipa host-mod wiki01.ayisnap.com --password=foo >>> > ipa: ERROR: invalid 'password': Password cannot be set on enrolled >>> host. >>> >>> Matthew this is indeed the correct behavior, previous information from >>> Dmitri was not correct. >>> >>> Once a host is enrolled you cannot reset the OTP password as that would >>> effectively mean destroying the hosts credentials while the host is >>> enrolled. Currently the IPA workflow expects you unenroll the client >>> first. >>> >>> Simo. >>> >>> -- >>> Simo Sorce * Red Hat, Inc * New York >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chorn at fluxcoil.net Sat Jan 26 07:33:54 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Sat, 26 Jan 2013 08:33:54 +0100 Subject: [Freeipa-users] Windows XP Client problem In-Reply-To: References: <20130124071025.GA9204@fluxcoil.net> Message-ID: <20130126073354.GA13733@fluxcoil.net> Hi, On Thu, Jan 24, 2013 at 01:36:04PM -0800, Eric Chennells wrote: > [windows kerberos client] > > Is anyone aware of if there is an LDAP related configuration needed? It > seems like only setting up the kerberos authentication is not enough. The only working way with unmodified [1] Windows as client is for Windows to use Kerberos from IPA for authentication. Instead of LDAP the user data has to be created locally. So you bevore doing the Ker- beros configuration you have to be able to log into the account. After the Kerb. configuration you can authenticate with the IPA password. Christian [1] So no pgina etc. used, just native Windows From jreg2k at gmail.com Mon Jan 28 11:14:59 2013 From: jreg2k at gmail.com (James James) Date: Mon, 28 Jan 2013 12:14:59 +0100 Subject: [Freeipa-users] Account Expiration Message-ID: Hi, in 389-ds there is a nice plugin I love, it's account policy. You can set account expiration date and the account will be inactive at this day. http://directory.fedoraproject.org/wiki/Account_Policy_Design#Detailed_Design_of_Account_Expiration Is there a way to have this feature with freeipa ? Regards. James -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Jan 28 15:58:59 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 28 Jan 2013 16:58:59 +0100 Subject: [Freeipa-users] Account Expiration In-Reply-To: References: Message-ID: <5106A043.1070103@redhat.com> On 01/28/2013 12:14 PM, James James wrote: > Hi, in 389-ds there is a nice plugin I love, it's account policy. You can set > account expiration date and the account will be inactive at this day. > > http://directory.fedoraproject.org/wiki/Account_Policy_Design#Detailed_Design_of_Account_Expiration > > Is there a way to have this feature with freeipa ? > > Regards. > > > James > Hello James, FreeIPA user plugin does not support this feature, you would need to hack it in the plugin yourselves (patches welcome :-). Generally, you should be able to set account expiration to krbPrincipalExpiration attribute of the user account and it should just work. You can also check few tickets we have already few tickets filed for better handling of this attribute: https://fedorahosted.org/freeipa/ticket/3062 [RFE] Allow admins to change expiration attribute for the accounts https://fedorahosted.org/freeipa/ticket/3305 KrbPrincipalExpiration should be checked in pre-bind op https://fedorahosted.org/freeipa/ticket/3306 [RFE] Expose the krbPrincipalExpiration attribute for editing in the IPA CLI / WEBUI Anyway, if you want a support for this particular plugin, you can file an RFE to Trac/Bugzilla which we will further process. HTH, Martin From jreg2k at gmail.com Mon Jan 28 20:14:00 2013 From: jreg2k at gmail.com (James James) Date: Mon, 28 Jan 2013 21:14:00 +0100 Subject: [Freeipa-users] Account Expiration In-Reply-To: <5106A043.1070103@redhat.com> References: <5106A043.1070103@redhat.com> Message-ID: Hi Martin, thanks a lot for your answer. The krbPrincipalExpiration should do the job. Regards. 2013/1/28 Martin Kosek > On 01/28/2013 12:14 PM, James James wrote: > > Hi, in 389-ds there is a nice plugin I love, it's account policy. You > can set > > account expiration date and the account will be inactive at this day. > > > > > http://directory.fedoraproject.org/wiki/Account_Policy_Design#Detailed_Design_of_Account_Expiration > > > > Is there a way to have this feature with freeipa ? > > > > Regards. > > > > > > James > > > > Hello James, > > FreeIPA user plugin does not support this feature, you would need to hack > it in > the plugin yourselves (patches welcome :-). > > Generally, you should be able to set account expiration to > krbPrincipalExpiration attribute of the user account and it should just > work. > You can also check few tickets we have already few tickets filed for better > handling of this attribute: > > https://fedorahosted.org/freeipa/ticket/3062 > [RFE] Allow admins to change expiration attribute for the accounts > > https://fedorahosted.org/freeipa/ticket/3305 > KrbPrincipalExpiration should be checked in pre-bind op > > https://fedorahosted.org/freeipa/ticket/3306 > [RFE] Expose the krbPrincipalExpiration attribute for editing in the IPA > CLI / > WEBUI > > > Anyway, if you want a support for this particular plugin, you can file an > RFE > to Trac/Bugzilla which we will further process. > > HTH, > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From masch82 at gmail.com Tue Jan 29 21:00:28 2013 From: masch82 at gmail.com (MaSch) Date: Tue, 29 Jan 2013 22:00:28 +0100 Subject: [Freeipa-users] Fedora 18 - FreeIPA + AD In-Reply-To: <50FEEA1E.5000209@gmail.com> References: <50FAE50A.3040008@gmail.com> <50FAF11B.1050006@redhat.com> <50FBC071.5090704@gmail.com> <50FC4474.7020602@redhat.com> <20130121084411.GA17244@localhost.localdomain> <50FEEA1E.5000209@gmail.com> Message-ID: <5108386C.5050005@gmail.com> On 1/22/13 8:35 PM, MaSch wrote: > I will file a bug report ... Just for reference if anyone runs into the same issues : Bug report is here : https://bugzilla.redhat.com/show_bug.cgi?id=904720 a workaround is included in the comments. Upstream IPA track ticket can be found here : https://fedorahosted.org/freeipa/ticket/3381 From freeipa at stormcloud9.net Wed Jan 30 00:26:55 2013 From: freeipa at stormcloud9.net (freeipa at stormcloud9.net) Date: Tue, 29 Jan 2013 19:26:55 -0500 Subject: [Freeipa-users] Unable to start replica server after setting up replication Message-ID: <510868CF.3020004@stormcloud9.net> Using ipa-server 2.2.0-17 on Amazon linux (RHEL6 clone), and after using the `ipa-replica-install` script to configure the replica server, the service will not start. Whenever I try it throws "SASL(-4): no mechanism available" during start. Any ideas? Full output: # /etc/init.d/ipa start Starting Directory Service Starting dirsrv: CLIFF-CLOUDBURRITO-COM... [ OK ] PKI-IPA... [ OK ] Failed to read data from Directory Service: Unknown error when retrieving list of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', 'desc': 'Unknown authentication method'} Shutting down Shutting down dirsrv: CLIFF-CLOUDBURRITO-COM... [ OK ] PKI-IPA... [ OK ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Jan 30 00:49:42 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 29 Jan 2013 19:49:42 -0500 Subject: [Freeipa-users] Unable to start replica server after setting up replication In-Reply-To: <510868CF.3020004@stormcloud9.net> References: <510868CF.3020004@stormcloud9.net> Message-ID: <51086E26.7060907@redhat.com> On 01/29/2013 07:26 PM, freeipa at stormcloud9.net wrote: > Using ipa-server 2.2.0-17 on Amazon linux (RHEL6 clone), and after > using the `ipa-replica-install` script to configure the replica > server, the service will not start. Whenever I try it throws > "SASL(-4): no mechanism available" during start. > > Any ideas? > > Full output: > > # /etc/init.d/ipa start > Starting Directory Service > Starting dirsrv: > CLIFF-CLOUDBURRITO-COM... [ OK ] > PKI-IPA... [ OK ] > Failed to read data from Directory Service: Unknown error when > retrieving list of services from LDAP: {'info': 'SASL(-4): no > mechanism available: ', 'desc': 'Unknown authentication method'} > Shutting down > Shutting down dirsrv: > CLIFF-CLOUDBURRITO-COM... [ OK ] > PKI-IPA... [ OK ] Sounds like DS did not start under the CA. Please check the DS logs in the PKI instance. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa at stormcloud9.net Wed Jan 30 01:05:17 2013 From: freeipa at stormcloud9.net (freeipa at stormcloud9.net) Date: Tue, 29 Jan 2013 20:05:17 -0500 Subject: [Freeipa-users] Unable to start replica server after setting up replication In-Reply-To: <51086E26.7060907@redhat.com> References: <510868CF.3020004@stormcloud9.net> <51086E26.7060907@redhat.com> Message-ID: <510871CD.9060707@stormcloud9.net> On 01/29/2013 07:49 PM, Dmitri Pal wrote: > On 01/29/2013 07:26 PM, freeipa at stormcloud9.net wrote: >> Using ipa-server 2.2.0-17 on Amazon linux (RHEL6 clone), and after >> using the `ipa-replica-install` script to configure the replica >> server, the service will not start. Whenever I try it throws >> "SASL(-4): no mechanism available" during start. >> >> Any ideas? >> >> Full output: >> >> # /etc/init.d/ipa start >> Starting Directory Service >> Starting dirsrv: >> CLIFF-CLOUDBURRITO-COM... [ OK ] >> PKI-IPA... [ OK ] >> Failed to read data from Directory Service: Unknown error when >> retrieving list of services from LDAP: {'info': 'SASL(-4): no >> mechanism available: ', 'desc': 'Unknown authentication method'} >> Shutting down >> Shutting down dirsrv: >> CLIFF-CLOUDBURRITO-COM... [ OK ] >> PKI-IPA... [ OK ] > > Sounds like DS did not start under the CA. Please check the DS logs in > the PKI instance. ns-slapd appears to be starting fine. I can even start it manually, but `ipactl status` still shows the error: Below is the result of me starting it manually (directly running ns-slapd): # ps ax|grep slapd 15540 ? Sl 0:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-PKI-IPA -i /var/run/dirsrv/slapd-PKI-IPA.pid -w /var/run/dirsrv/slapd-PKI-IPA.startpid 15586 ? Sl 0:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM -i /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.pid -w /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.startpid # netstat -tpnl | grep slapd tcp 0 0 :::636 :::* LISTEN 15586/ns-slapd tcp 0 0 :::7389 :::* LISTEN 15540/ns-slapd tcp 0 0 :::7390 :::* LISTEN 15540/ns-slapd tcp 0 0 :::389 :::* LISTEN 15586/ns-slapd # ipactl status Directory Service: RUNNING Unknown error when retrieving list of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', 'desc': 'Unknown authentication method'} -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Jan 30 08:33:34 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 30 Jan 2013 09:33:34 +0100 Subject: [Freeipa-users] Unable to start replica server after setting up replication In-Reply-To: <510871CD.9060707@stormcloud9.net> References: <510868CF.3020004@stormcloud9.net> <51086E26.7060907@redhat.com> <510871CD.9060707@stormcloud9.net> Message-ID: <5108DADE.9060103@redhat.com> On 01/30/2013 02:05 AM, freeipa at stormcloud9.net wrote: > On 01/29/2013 07:49 PM, Dmitri Pal wrote: >> On 01/29/2013 07:26 PM, freeipa at stormcloud9.net wrote: >>> Using ipa-server 2.2.0-17 on Amazon linux (RHEL6 clone), and after using the >>> `ipa-replica-install` script to configure the replica server, the service >>> will not start. Whenever I try it throws "SASL(-4): no mechanism available" >>> during start. >>> >>> Any ideas? >>> >>> Full output: >>> >>> # /etc/init.d/ipa start >>> Starting Directory Service >>> Starting dirsrv: >>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>> PKI-IPA... [ OK ] >>> Failed to read data from Directory Service: Unknown error when retrieving >>> list of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', >>> 'desc': 'Unknown authentication method'} >>> Shutting down >>> Shutting down dirsrv: >>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>> PKI-IPA... [ OK ] >> >> Sounds like DS did not start under the CA. Please check the DS logs in the >> PKI instance. > > ns-slapd appears to be starting fine. I can even start it manually, but `ipactl > status` still shows the error: > Below is the result of me starting it manually (directly running ns-slapd): > > # ps ax|grep slapd > 15540 ? Sl 0:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-PKI-IPA -i > /var/run/dirsrv/slapd-PKI-IPA.pid -w /var/run/dirsrv/slapd-PKI-IPA.startpid > 15586 ? Sl 0:00 /usr/sbin/ns-slapd -D > /etc/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM -i > /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.pid -w > /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.startpid > # netstat -tpnl | grep slapd > tcp 0 0 :::636 :::* > LISTEN 15586/ns-slapd > tcp 0 0 :::7389 :::* > LISTEN 15540/ns-slapd > tcp 0 0 :::7390 :::* > LISTEN 15540/ns-slapd > tcp 0 0 :::389 :::* > LISTEN 15586/ns-slapd > # ipactl status > Directory Service: RUNNING > Unknown error when retrieving list of services from LDAP: {'info': 'SASL(-4): > no mechanism available: ', 'desc': 'Unknown authentication method'} > Hello, OK, it seems that ipactl could not bind to your Directory Server. This script uses a "ldap_uri" configuration option value from /etc/ipa/default.conf to connect to Directory Server via EXTERNAL auth. You can verify yourself if that bind works or not with the following ldapsearch (just replace $LDAP_URI_VALUE with your setting): # ldapsearch -Y EXTERNAL -H $LDAP_URI_VALUE -b "cn=masters,cn=ipa,cn=etc,dc=cliff,dc=cloudburrito,dc=com" I assume it will report the same error as ipactl. We need to verify that the referred LDAP URI is indeed right and functional. Martin From freeipa at stormcloud9.net Wed Jan 30 14:18:28 2013 From: freeipa at stormcloud9.net (freeipa at stormcloud9.net) Date: Wed, 30 Jan 2013 09:18:28 -0500 Subject: [Freeipa-users] Unable to start replica server after setting up replication In-Reply-To: <5108DADE.9060103@redhat.com> References: <510868CF.3020004@stormcloud9.net> <51086E26.7060907@redhat.com> <510871CD.9060707@stormcloud9.net> <5108DADE.9060103@redhat.com> Message-ID: <51092BB4.4050502@stormcloud9.net> On 2013/30/01 03:33, Martin Kosek wrote: > On 01/30/2013 02:05 AM, freeipa at stormcloud9.net wrote: >> On 01/29/2013 07:49 PM, Dmitri Pal wrote: >>> On 01/29/2013 07:26 PM, freeipa at stormcloud9.net wrote: >>>> Using ipa-server 2.2.0-17 on Amazon linux (RHEL6 clone), and after using the >>>> `ipa-replica-install` script to configure the replica server, the service >>>> will not start. Whenever I try it throws "SASL(-4): no mechanism available" >>>> during start. >>>> >>>> Any ideas? >>>> >>>> Full output: >>>> >>>> # /etc/init.d/ipa start >>>> Starting Directory Service >>>> Starting dirsrv: >>>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>>> PKI-IPA... [ OK ] >>>> Failed to read data from Directory Service: Unknown error when retrieving >>>> list of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', >>>> 'desc': 'Unknown authentication method'} >>>> Shutting down >>>> Shutting down dirsrv: >>>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>>> PKI-IPA... [ OK ] >>> Sounds like DS did not start under the CA. Please check the DS logs in the >>> PKI instance. >> ns-slapd appears to be starting fine. I can even start it manually, but `ipactl >> status` still shows the error: >> Below is the result of me starting it manually (directly running ns-slapd): >> >> # ps ax|grep slapd >> 15540 ? Sl 0:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-PKI-IPA -i >> /var/run/dirsrv/slapd-PKI-IPA.pid -w /var/run/dirsrv/slapd-PKI-IPA.startpid >> 15586 ? Sl 0:00 /usr/sbin/ns-slapd -D >> /etc/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM -i >> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.pid -w >> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.startpid >> # netstat -tpnl | grep slapd >> tcp 0 0 :::636 :::* >> LISTEN 15586/ns-slapd >> tcp 0 0 :::7389 :::* >> LISTEN 15540/ns-slapd >> tcp 0 0 :::7390 :::* >> LISTEN 15540/ns-slapd >> tcp 0 0 :::389 :::* >> LISTEN 15586/ns-slapd >> # ipactl status >> Directory Service: RUNNING >> Unknown error when retrieving list of services from LDAP: {'info': 'SASL(-4): >> no mechanism available: ', 'desc': 'Unknown authentication method'} >> > > Hello, > > OK, it seems that ipactl could not bind to your Directory Server. This script > uses a "ldap_uri" configuration option value from /etc/ipa/default.conf to > connect to Directory Server via EXTERNAL auth. > > You can verify yourself if that bind works or not with the following ldapsearch > (just replace $LDAP_URI_VALUE with your setting): > > # ldapsearch -Y EXTERNAL -H $LDAP_URI_VALUE -b > "cn=masters,cn=ipa,cn=etc,dc=cliff,dc=cloudburrito,dc=com" > > I assume it will report the same error as ipactl. We need to verify that the > referred LDAP URI is indeed right and functional. > > Martin The system had no /etc/ipa/default.conf I copied the one from the master server, changed the `host=` and `xmlrpc_uri=` parameters to reflect the replica server, and now `ipactl status`, along with everything else, is working perfectly. Should that file have been created during the `ipa-replica-install` process? I don't see anything in the documentation about having to copy and edit it manually. Thanks -Patrick From mkosek at redhat.com Wed Jan 30 14:19:57 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 30 Jan 2013 15:19:57 +0100 Subject: [Freeipa-users] Unable to start replica server after setting up replication In-Reply-To: <51092B51.2000707@stormcloud9.net> References: <510868CF.3020004@stormcloud9.net> <51086E26.7060907@redhat.com> <510871CD.9060707@stormcloud9.net> <5108DADE.9060103@redhat.com> <51092B51.2000707@stormcloud9.net> Message-ID: <51092C0D.1080606@redhat.com> On 01/30/2013 03:16 PM, Patrick Hemmer wrote: > On 2013/30/01 03:33, Martin Kosek wrote: >> On 01/30/2013 02:05 AM, freeipa at stormcloud9.net wrote: >>> On 01/29/2013 07:49 PM, Dmitri Pal wrote: >>>> On 01/29/2013 07:26 PM, freeipa at stormcloud9.net wrote: >>>>> Using ipa-server 2.2.0-17 on Amazon linux (RHEL6 clone), and after using the >>>>> `ipa-replica-install` script to configure the replica server, the service >>>>> will not start. Whenever I try it throws "SASL(-4): no mechanism available" >>>>> during start. >>>>> >>>>> Any ideas? >>>>> >>>>> Full output: >>>>> >>>>> # /etc/init.d/ipa start >>>>> Starting Directory Service >>>>> Starting dirsrv: >>>>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>>>> PKI-IPA... [ OK ] >>>>> Failed to read data from Directory Service: Unknown error when retrieving >>>>> list of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', >>>>> 'desc': 'Unknown authentication method'} >>>>> Shutting down >>>>> Shutting down dirsrv: >>>>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>>>> PKI-IPA... [ OK ] >>>> Sounds like DS did not start under the CA. Please check the DS logs in the >>>> PKI instance. >>> ns-slapd appears to be starting fine. I can even start it manually, but `ipactl >>> status` still shows the error: >>> Below is the result of me starting it manually (directly running ns-slapd): >>> >>> # ps ax|grep slapd >>> 15540 ? Sl 0:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-PKI-IPA -i >>> /var/run/dirsrv/slapd-PKI-IPA.pid -w /var/run/dirsrv/slapd-PKI-IPA.startpid >>> 15586 ? Sl 0:00 /usr/sbin/ns-slapd -D >>> /etc/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM -i >>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.pid -w >>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.startpid >>> # netstat -tpnl | grep slapd >>> tcp 0 0 :::636 :::* >>> LISTEN 15586/ns-slapd >>> tcp 0 0 :::7389 :::* >>> LISTEN 15540/ns-slapd >>> tcp 0 0 :::7390 :::* >>> LISTEN 15540/ns-slapd >>> tcp 0 0 :::389 :::* >>> LISTEN 15586/ns-slapd >>> # ipactl status >>> Directory Service: RUNNING >>> Unknown error when retrieving list of services from LDAP: {'info': 'SASL(-4): >>> no mechanism available: ', 'desc': 'Unknown authentication method'} >>> >> >> Hello, >> >> OK, it seems that ipactl could not bind to your Directory Server. This script >> uses a "ldap_uri" configuration option value from /etc/ipa/default.conf to >> connect to Directory Server via EXTERNAL auth. >> >> You can verify yourself if that bind works or not with the following ldapsearch >> (just replace $LDAP_URI_VALUE with your setting): >> >> # ldapsearch -Y EXTERNAL -H $LDAP_URI_VALUE -b >> "cn=masters,cn=ipa,cn=etc,dc=cliff,dc=cloudburrito,dc=com" >> >> I assume it will report the same error as ipactl. We need to verify that the >> referred LDAP URI is indeed right and functional. >> >> Martin > > The system had no /etc/ipa/default.conf > I copied the one from the master server, changed the `host=` and > `xmlrpc_uri=` parameters to reflect the replica server, and now `ipactl > status`, along with everything else, is working perfectly. > Should that file have been created during the `ipa-replica-install` > process? I don't see anything in the documentation about having to copy > and edit it manually. > > Thanks > > -Patrick > Yeah, this should have been created during ipa-replica-install. Can you please check /var/log/ipareplica-install.log and check if ipa-client-install (which is run as part of ipa-replica-install) succeeded? I have a suspicion you hit a bug I was fixing recently. Martin From freeipa at stormcloud9.net Wed Jan 30 14:22:50 2013 From: freeipa at stormcloud9.net (freeipa at stormcloud9.net) Date: Wed, 30 Jan 2013 09:22:50 -0500 Subject: [Freeipa-users] Unable to start replica server after setting up replication In-Reply-To: <51092C0D.1080606@redhat.com> References: <510868CF.3020004@stormcloud9.net> <51086E26.7060907@redhat.com> <510871CD.9060707@stormcloud9.net> <5108DADE.9060103@redhat.com> <51092B51.2000707@stormcloud9.net> <51092C0D.1080606@redhat.com> Message-ID: <51092CBA.2010905@stormcloud9.net> On 2013/30/01 09:19, Martin Kosek wrote: > On 01/30/2013 03:16 PM, Patrick Hemmer wrote: >> On 2013/30/01 03:33, Martin Kosek wrote: >>> On 01/30/2013 02:05 AM, freeipa at stormcloud9.net wrote: >>>> On 01/29/2013 07:49 PM, Dmitri Pal wrote: >>>>> On 01/29/2013 07:26 PM, freeipa at stormcloud9.net wrote: >>>>>> Using ipa-server 2.2.0-17 on Amazon linux (RHEL6 clone), and after using the >>>>>> `ipa-replica-install` script to configure the replica server, the service >>>>>> will not start. Whenever I try it throws "SASL(-4): no mechanism available" >>>>>> during start. >>>>>> >>>>>> Any ideas? >>>>>> >>>>>> Full output: >>>>>> >>>>>> # /etc/init.d/ipa start >>>>>> Starting Directory Service >>>>>> Starting dirsrv: >>>>>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>>>>> PKI-IPA... [ OK ] >>>>>> Failed to read data from Directory Service: Unknown error when retrieving >>>>>> list of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', >>>>>> 'desc': 'Unknown authentication method'} >>>>>> Shutting down >>>>>> Shutting down dirsrv: >>>>>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>>>>> PKI-IPA... [ OK ] >>>>> Sounds like DS did not start under the CA. Please check the DS logs in the >>>>> PKI instance. >>>> ns-slapd appears to be starting fine. I can even start it manually, but `ipactl >>>> status` still shows the error: >>>> Below is the result of me starting it manually (directly running ns-slapd): >>>> >>>> # ps ax|grep slapd >>>> 15540 ? Sl 0:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-PKI-IPA -i >>>> /var/run/dirsrv/slapd-PKI-IPA.pid -w /var/run/dirsrv/slapd-PKI-IPA.startpid >>>> 15586 ? Sl 0:00 /usr/sbin/ns-slapd -D >>>> /etc/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM -i >>>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.pid -w >>>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.startpid >>>> # netstat -tpnl | grep slapd >>>> tcp 0 0 :::636 :::* >>>> LISTEN 15586/ns-slapd >>>> tcp 0 0 :::7389 :::* >>>> LISTEN 15540/ns-slapd >>>> tcp 0 0 :::7390 :::* >>>> LISTEN 15540/ns-slapd >>>> tcp 0 0 :::389 :::* >>>> LISTEN 15586/ns-slapd >>>> # ipactl status >>>> Directory Service: RUNNING >>>> Unknown error when retrieving list of services from LDAP: {'info': 'SASL(-4): >>>> no mechanism available: ', 'desc': 'Unknown authentication method'} >>>> >>> Hello, >>> >>> OK, it seems that ipactl could not bind to your Directory Server. This script >>> uses a "ldap_uri" configuration option value from /etc/ipa/default.conf to >>> connect to Directory Server via EXTERNAL auth. >>> >>> You can verify yourself if that bind works or not with the following ldapsearch >>> (just replace $LDAP_URI_VALUE with your setting): >>> >>> # ldapsearch -Y EXTERNAL -H $LDAP_URI_VALUE -b >>> "cn=masters,cn=ipa,cn=etc,dc=cliff,dc=cloudburrito,dc=com" >>> >>> I assume it will report the same error as ipactl. We need to verify that the >>> referred LDAP URI is indeed right and functional. >>> >>> Martin >> The system had no /etc/ipa/default.conf >> I copied the one from the master server, changed the `host=` and >> `xmlrpc_uri=` parameters to reflect the replica server, and now `ipactl >> status`, along with everything else, is working perfectly. >> Should that file have been created during the `ipa-replica-install` >> process? I don't see anything in the documentation about having to copy >> and edit it manually. >> >> Thanks >> >> -Patrick >> > Yeah, this should have been created during ipa-replica-install. > > Can you please check /var/log/ipareplica-install.log and check if > ipa-client-install (which is run as part of ipa-replica-install) succeeded? I > have a suspicion you hit a bug I was fixing recently. > > Martin No, the client install failed: 2013-01-29T23:24:05Z DEBUG stderr= 2013-01-29T23:24:05Z DEBUG Restarting the web server 2013-01-29T23:24:06Z DEBUG args=/sbin/service httpd restart 2013-01-29T23:24:06Z DEBUG stdout=Stopping httpd: [ OK ] Starting httpd: [ OK ] 2013-01-29T23:24:06Z DEBUG stderr= 2013-01-29T23:24:20Z DEBUG args=/usr/sbin/ipa-client-install --on-master --unattended --domain cliff.cloudburrito.com --server i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com --realm CLIFF.CLOUDBURRITO.COM 2013-01-29T23:24:20Z DEBUG stdout=Discovery was successful! Hostname: i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com Realm: CLIFF.CLOUDBURRITO.COM DNS Domain: cliff.cloudburrito.com IPA Server: i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com BaseDN: dc=cliff,dc=cloudburrito,dc=com Configured /etc/sssd/sssd.conf Installation failed. Rolling back changes. 2013-01-29T23:24:20Z DEBUG stderr=DNS domain 'cliff.cloudburrito.com' is not configured for automatic KDC address lookup. KDC address will be set to fixed value. Failed to add CA to the default NSS database. 2013-01-29T23:24:20Z DEBUG Failed to configure the client File "/usr/sbin/ipa-replica-install", line 496, in main() File "/usr/sbin/ipa-replica-install", line 485, in main raise RuntimeError("Failed to configure the client") From mkosek at redhat.com Wed Jan 30 14:37:35 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 30 Jan 2013 15:37:35 +0100 Subject: [Freeipa-users] Unable to start replica server after setting up replication In-Reply-To: <51092CBA.2010905@stormcloud9.net> References: <510868CF.3020004@stormcloud9.net> <51086E26.7060907@redhat.com> <510871CD.9060707@stormcloud9.net> <5108DADE.9060103@redhat.com> <51092B51.2000707@stormcloud9.net> <51092C0D.1080606@redhat.com> <51092CBA.2010905@stormcloud9.net> Message-ID: <5109302F.70403@redhat.com> On 01/30/2013 03:22 PM, freeipa at stormcloud9.net wrote: > > On 2013/30/01 09:19, Martin Kosek wrote: >> On 01/30/2013 03:16 PM, Patrick Hemmer wrote: >>> On 2013/30/01 03:33, Martin Kosek wrote: >>>> On 01/30/2013 02:05 AM, freeipa at stormcloud9.net wrote: >>>>> On 01/29/2013 07:49 PM, Dmitri Pal wrote: >>>>>> On 01/29/2013 07:26 PM, freeipa at stormcloud9.net wrote: >>>>>>> Using ipa-server 2.2.0-17 on Amazon linux (RHEL6 clone), and after using the >>>>>>> `ipa-replica-install` script to configure the replica server, the service >>>>>>> will not start. Whenever I try it throws "SASL(-4): no mechanism available" >>>>>>> during start. >>>>>>> >>>>>>> Any ideas? >>>>>>> >>>>>>> Full output: >>>>>>> >>>>>>> # /etc/init.d/ipa start >>>>>>> Starting Directory Service >>>>>>> Starting dirsrv: >>>>>>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>>>>>> PKI-IPA... [ OK ] >>>>>>> Failed to read data from Directory Service: Unknown error when retrieving >>>>>>> list of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', >>>>>>> 'desc': 'Unknown authentication method'} >>>>>>> Shutting down >>>>>>> Shutting down dirsrv: >>>>>>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>>>>>> PKI-IPA... [ OK ] >>>>>> Sounds like DS did not start under the CA. Please check the DS logs in the >>>>>> PKI instance. >>>>> ns-slapd appears to be starting fine. I can even start it manually, but `ipactl >>>>> status` still shows the error: >>>>> Below is the result of me starting it manually (directly running ns-slapd): >>>>> >>>>> # ps ax|grep slapd >>>>> 15540 ? Sl 0:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-PKI-IPA -i >>>>> /var/run/dirsrv/slapd-PKI-IPA.pid -w /var/run/dirsrv/slapd-PKI-IPA.startpid >>>>> 15586 ? Sl 0:00 /usr/sbin/ns-slapd -D >>>>> /etc/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM -i >>>>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.pid -w >>>>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.startpid >>>>> # netstat -tpnl | grep slapd >>>>> tcp 0 0 :::636 :::* >>>>> LISTEN 15586/ns-slapd >>>>> tcp 0 0 :::7389 :::* >>>>> LISTEN 15540/ns-slapd >>>>> tcp 0 0 :::7390 :::* >>>>> LISTEN 15540/ns-slapd >>>>> tcp 0 0 :::389 :::* >>>>> LISTEN 15586/ns-slapd >>>>> # ipactl status >>>>> Directory Service: RUNNING >>>>> Unknown error when retrieving list of services from LDAP: {'info': 'SASL(-4): >>>>> no mechanism available: ', 'desc': 'Unknown authentication method'} >>>>> >>>> Hello, >>>> >>>> OK, it seems that ipactl could not bind to your Directory Server. This script >>>> uses a "ldap_uri" configuration option value from /etc/ipa/default.conf to >>>> connect to Directory Server via EXTERNAL auth. >>>> >>>> You can verify yourself if that bind works or not with the following ldapsearch >>>> (just replace $LDAP_URI_VALUE with your setting): >>>> >>>> # ldapsearch -Y EXTERNAL -H $LDAP_URI_VALUE -b >>>> "cn=masters,cn=ipa,cn=etc,dc=cliff,dc=cloudburrito,dc=com" >>>> >>>> I assume it will report the same error as ipactl. We need to verify that the >>>> referred LDAP URI is indeed right and functional. >>>> >>>> Martin >>> The system had no /etc/ipa/default.conf >>> I copied the one from the master server, changed the `host=` and >>> `xmlrpc_uri=` parameters to reflect the replica server, and now `ipactl >>> status`, along with everything else, is working perfectly. >>> Should that file have been created during the `ipa-replica-install` >>> process? I don't see anything in the documentation about having to copy >>> and edit it manually. >>> >>> Thanks >>> >>> -Patrick >>> >> Yeah, this should have been created during ipa-replica-install. >> >> Can you please check /var/log/ipareplica-install.log and check if >> ipa-client-install (which is run as part of ipa-replica-install) succeeded? I >> have a suspicion you hit a bug I was fixing recently. >> >> Martin > No, the client install failed: > 2013-01-29T23:24:05Z DEBUG stderr= > 2013-01-29T23:24:05Z DEBUG Restarting the web server > 2013-01-29T23:24:06Z DEBUG args=/sbin/service httpd restart > 2013-01-29T23:24:06Z DEBUG stdout=Stopping httpd: [ OK ] > Starting httpd: [ OK ] > > 2013-01-29T23:24:06Z DEBUG stderr= > 2013-01-29T23:24:20Z DEBUG args=/usr/sbin/ipa-client-install --on-master > --unattended --domain cliff.cloudburrito.com --server > i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com --realm > CLIFF.CLOUDBURRITO.COM > 2013-01-29T23:24:20Z DEBUG stdout=Discovery was successful! > Hostname: i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com > Realm: CLIFF.CLOUDBURRITO.COM > DNS Domain: cliff.cloudburrito.com > IPA Server: i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com > BaseDN: dc=cliff,dc=cloudburrito,dc=com > > > Configured /etc/sssd/sssd.conf > Installation failed. Rolling back changes. > > 2013-01-29T23:24:20Z DEBUG stderr=DNS domain 'cliff.cloudburrito.com' is > not configured for automatic KDC address lookup. > KDC address will be set to fixed value. > > Failed to add CA to the default NSS database. > > 2013-01-29T23:24:20Z DEBUG Failed to configure the client > File "/usr/sbin/ipa-replica-install", line 496, in > main() > > File "/usr/sbin/ipa-replica-install", line 485, in main > raise RuntimeError("Failed to configure the client") > Getting warmer... Can you please check /var/log/ipaclient-install.log if there is a reason why it failed? The problem here is that the client removed default.conf, keytabs etc. when it uninstalled itself due to the failure. Thanks, Martin From freeipa at stormcloud9.net Wed Jan 30 16:43:15 2013 From: freeipa at stormcloud9.net (freeipa at stormcloud9.net) Date: Wed, 30 Jan 2013 11:43:15 -0500 Subject: [Freeipa-users] Unable to start replica server after setting up replication In-Reply-To: <5109302F.70403@redhat.com> References: <510868CF.3020004@stormcloud9.net> <51086E26.7060907@redhat.com> <510871CD.9060707@stormcloud9.net> <5108DADE.9060103@redhat.com> <51092B51.2000707@stormcloud9.net> <51092C0D.1080606@redhat.com> <51092CBA.2010905@stormcloud9.net> <5109302F.70403@redhat.com> Message-ID: <51094DA3.1090604@stormcloud9.net> On 2013/30/01 09:37, Martin Kosek wrote: > On 01/30/2013 03:22 PM, freeipa at stormcloud9.net wrote: >> On 2013/30/01 09:19, Martin Kosek wrote: >>> On 01/30/2013 03:16 PM, Patrick Hemmer wrote: >>>> On 2013/30/01 03:33, Martin Kosek wrote: >>>>> On 01/30/2013 02:05 AM, freeipa at stormcloud9.net wrote: >>>>>> On 01/29/2013 07:49 PM, Dmitri Pal wrote: >>>>>>> On 01/29/2013 07:26 PM, freeipa at stormcloud9.net wrote: >>>>>>>> Using ipa-server 2.2.0-17 on Amazon linux (RHEL6 clone), and after using the >>>>>>>> `ipa-replica-install` script to configure the replica server, the service >>>>>>>> will not start. Whenever I try it throws "SASL(-4): no mechanism available" >>>>>>>> during start. >>>>>>>> >>>>>>>> Any ideas? >>>>>>>> >>>>>>>> Full output: >>>>>>>> >>>>>>>> # /etc/init.d/ipa start >>>>>>>> Starting Directory Service >>>>>>>> Starting dirsrv: >>>>>>>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>>>>>>> PKI-IPA... [ OK ] >>>>>>>> Failed to read data from Directory Service: Unknown error when retrieving >>>>>>>> list of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', >>>>>>>> 'desc': 'Unknown authentication method'} >>>>>>>> Shutting down >>>>>>>> Shutting down dirsrv: >>>>>>>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>>>>>>> PKI-IPA... [ OK ] >>>>>>> Sounds like DS did not start under the CA. Please check the DS logs in the >>>>>>> PKI instance. >>>>>> ns-slapd appears to be starting fine. I can even start it manually, but `ipactl >>>>>> status` still shows the error: >>>>>> Below is the result of me starting it manually (directly running ns-slapd): >>>>>> >>>>>> # ps ax|grep slapd >>>>>> 15540 ? Sl 0:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-PKI-IPA -i >>>>>> /var/run/dirsrv/slapd-PKI-IPA.pid -w /var/run/dirsrv/slapd-PKI-IPA.startpid >>>>>> 15586 ? Sl 0:00 /usr/sbin/ns-slapd -D >>>>>> /etc/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM -i >>>>>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.pid -w >>>>>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.startpid >>>>>> # netstat -tpnl | grep slapd >>>>>> tcp 0 0 :::636 :::* >>>>>> LISTEN 15586/ns-slapd >>>>>> tcp 0 0 :::7389 :::* >>>>>> LISTEN 15540/ns-slapd >>>>>> tcp 0 0 :::7390 :::* >>>>>> LISTEN 15540/ns-slapd >>>>>> tcp 0 0 :::389 :::* >>>>>> LISTEN 15586/ns-slapd >>>>>> # ipactl status >>>>>> Directory Service: RUNNING >>>>>> Unknown error when retrieving list of services from LDAP: {'info': 'SASL(-4): >>>>>> no mechanism available: ', 'desc': 'Unknown authentication method'} >>>>>> >>>>> Hello, >>>>> >>>>> OK, it seems that ipactl could not bind to your Directory Server. This script >>>>> uses a "ldap_uri" configuration option value from /etc/ipa/default.conf to >>>>> connect to Directory Server via EXTERNAL auth. >>>>> >>>>> You can verify yourself if that bind works or not with the following ldapsearch >>>>> (just replace $LDAP_URI_VALUE with your setting): >>>>> >>>>> # ldapsearch -Y EXTERNAL -H $LDAP_URI_VALUE -b >>>>> "cn=masters,cn=ipa,cn=etc,dc=cliff,dc=cloudburrito,dc=com" >>>>> >>>>> I assume it will report the same error as ipactl. We need to verify that the >>>>> referred LDAP URI is indeed right and functional. >>>>> >>>>> Martin >>>> The system had no /etc/ipa/default.conf >>>> I copied the one from the master server, changed the `host=` and >>>> `xmlrpc_uri=` parameters to reflect the replica server, and now `ipactl >>>> status`, along with everything else, is working perfectly. >>>> Should that file have been created during the `ipa-replica-install` >>>> process? I don't see anything in the documentation about having to copy >>>> and edit it manually. >>>> >>>> Thanks >>>> >>>> -Patrick >>>> >>> Yeah, this should have been created during ipa-replica-install. >>> >>> Can you please check /var/log/ipareplica-install.log and check if >>> ipa-client-install (which is run as part of ipa-replica-install) succeeded? I >>> have a suspicion you hit a bug I was fixing recently. >>> >>> Martin >> No, the client install failed: >> 2013-01-29T23:24:05Z DEBUG stderr= >> 2013-01-29T23:24:05Z DEBUG Restarting the web server >> 2013-01-29T23:24:06Z DEBUG args=/sbin/service httpd restart >> 2013-01-29T23:24:06Z DEBUG stdout=Stopping httpd: [ OK ] >> Starting httpd: [ OK ] >> >> 2013-01-29T23:24:06Z DEBUG stderr= >> 2013-01-29T23:24:20Z DEBUG args=/usr/sbin/ipa-client-install --on-master >> --unattended --domain cliff.cloudburrito.com --server >> i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com --realm >> CLIFF.CLOUDBURRITO.COM >> 2013-01-29T23:24:20Z DEBUG stdout=Discovery was successful! >> Hostname: i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com >> Realm: CLIFF.CLOUDBURRITO.COM >> DNS Domain: cliff.cloudburrito.com >> IPA Server: i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com >> BaseDN: dc=cliff,dc=cloudburrito,dc=com >> >> >> Configured /etc/sssd/sssd.conf >> Installation failed. Rolling back changes. >> >> 2013-01-29T23:24:20Z DEBUG stderr=DNS domain 'cliff.cloudburrito.com' is >> not configured for automatic KDC address lookup. >> KDC address will be set to fixed value. >> >> Failed to add CA to the default NSS database. >> >> 2013-01-29T23:24:20Z DEBUG Failed to configure the client >> File "/usr/sbin/ipa-replica-install", line 496, in >> main() >> >> File "/usr/sbin/ipa-replica-install", line 485, in main >> raise RuntimeError("Failed to configure the client") >> > Getting warmer... Can you please check /var/log/ipaclient-install.log if there > is a reason why it failed? The problem here is that the client removed > default.conf, keytabs etc. when it uninstalled itself due to the failure. > > Thanks, > Martin Below is the last few lines of the file. It looks like it's failing because sssd is already configured. This is true as our servers are preconfigured for sssd to use the IPA master server. If this is indeed the cause, is there any way to have it not configure sssd? Or should I wipe the sssd config before attempting to set up the replica? Could it also be fixed so that if the client install does fail, that it doesn't break the server? 2013-01-30T16:28:38Z DEBUG stderr= 2013-01-30T16:28:38Z DEBUG Restoring client configuration files 2013-01-30T16:28:38Z DEBUG args=/usr/sbin/selinuxenabled 2013-01-30T16:28:38Z DEBUG stdout= 2013-01-30T16:28:38Z DEBUG stderr= 2013-01-30T16:28:38Z DEBUG Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' 2013-01-30T16:28:38Z DEBUG -> no files, removing file 2013-01-30T16:28:38Z DEBUG args=/sbin/service nscd status 2013-01-30T16:28:38Z DEBUG stdout= 2013-01-30T16:28:38Z DEBUG stderr=nscd: unrecognized service 2013-01-30T16:28:38Z INFO nscd daemon is not installed, skip configuration 2013-01-30T16:28:38Z DEBUG args=/sbin/service nslcd status 2013-01-30T16:28:38Z DEBUG stdout= 2013-01-30T16:28:38Z DEBUG stderr=nslcd: unrecognized service 2013-01-30T16:28:38Z INFO nslcd daemon is not installed, skip configuration 2013-01-30T16:28:38Z DEBUG The original configuration of SSSD included other domains than IPA-based one. 2013-01-30T16:28:38Z DEBUG Original configuration file is restored, restarting SSSD service. 2013-01-30T16:28:38Z DEBUG args=/sbin/service sssd restart 2013-01-30T16:28:38Z DEBUG stdout=Stopping sssd: [FAILED] Starting sssd: [ OK ] 2013-01-30T16:28:38Z DEBUG stderr=cat: /var/run/sssd.pid: No such file or directory From dpal at redhat.com Wed Jan 30 16:59:29 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 30 Jan 2013 11:59:29 -0500 Subject: [Freeipa-users] Unable to start replica server after setting up replication In-Reply-To: <51094DA3.1090604@stormcloud9.net> References: <510868CF.3020004@stormcloud9.net> <51086E26.7060907@redhat.com> <510871CD.9060707@stormcloud9.net> <5108DADE.9060103@redhat.com> <51092B51.2000707@stormcloud9.net> <51092C0D.1080606@redhat.com> <51092CBA.2010905@stormcloud9.net> <5109302F.70403@redhat.com> <51094DA3.1090604@stormcloud9.net> Message-ID: <51095171.6080405@redhat.com> On 01/30/2013 11:43 AM, freeipa at stormcloud9.net wrote: > On 2013/30/01 09:37, Martin Kosek wrote: >> On 01/30/2013 03:22 PM, freeipa at stormcloud9.net wrote: >>> On 2013/30/01 09:19, Martin Kosek wrote: >>>> On 01/30/2013 03:16 PM, Patrick Hemmer wrote: >>>>> On 2013/30/01 03:33, Martin Kosek wrote: >>>>>> On 01/30/2013 02:05 AM, freeipa at stormcloud9.net wrote: >>>>>>> On 01/29/2013 07:49 PM, Dmitri Pal wrote: >>>>>>>> On 01/29/2013 07:26 PM, freeipa at stormcloud9.net wrote: >>>>>>>>> Using ipa-server 2.2.0-17 on Amazon linux (RHEL6 clone), and after using the >>>>>>>>> `ipa-replica-install` script to configure the replica server, the service >>>>>>>>> will not start. Whenever I try it throws "SASL(-4): no mechanism available" >>>>>>>>> during start. >>>>>>>>> >>>>>>>>> Any ideas? >>>>>>>>> >>>>>>>>> Full output: >>>>>>>>> >>>>>>>>> # /etc/init.d/ipa start >>>>>>>>> Starting Directory Service >>>>>>>>> Starting dirsrv: >>>>>>>>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>>>>>>>> PKI-IPA... [ OK ] >>>>>>>>> Failed to read data from Directory Service: Unknown error when retrieving >>>>>>>>> list of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', >>>>>>>>> 'desc': 'Unknown authentication method'} >>>>>>>>> Shutting down >>>>>>>>> Shutting down dirsrv: >>>>>>>>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>>>>>>>> PKI-IPA... [ OK ] >>>>>>>> Sounds like DS did not start under the CA. Please check the DS logs in the >>>>>>>> PKI instance. >>>>>>> ns-slapd appears to be starting fine. I can even start it manually, but `ipactl >>>>>>> status` still shows the error: >>>>>>> Below is the result of me starting it manually (directly running ns-slapd): >>>>>>> >>>>>>> # ps ax|grep slapd >>>>>>> 15540 ? Sl 0:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-PKI-IPA -i >>>>>>> /var/run/dirsrv/slapd-PKI-IPA.pid -w /var/run/dirsrv/slapd-PKI-IPA.startpid >>>>>>> 15586 ? Sl 0:00 /usr/sbin/ns-slapd -D >>>>>>> /etc/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM -i >>>>>>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.pid -w >>>>>>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.startpid >>>>>>> # netstat -tpnl | grep slapd >>>>>>> tcp 0 0 :::636 :::* >>>>>>> LISTEN 15586/ns-slapd >>>>>>> tcp 0 0 :::7389 :::* >>>>>>> LISTEN 15540/ns-slapd >>>>>>> tcp 0 0 :::7390 :::* >>>>>>> LISTEN 15540/ns-slapd >>>>>>> tcp 0 0 :::389 :::* >>>>>>> LISTEN 15586/ns-slapd >>>>>>> # ipactl status >>>>>>> Directory Service: RUNNING >>>>>>> Unknown error when retrieving list of services from LDAP: {'info': 'SASL(-4): >>>>>>> no mechanism available: ', 'desc': 'Unknown authentication method'} >>>>>>> >>>>>> Hello, >>>>>> >>>>>> OK, it seems that ipactl could not bind to your Directory Server. This script >>>>>> uses a "ldap_uri" configuration option value from /etc/ipa/default.conf to >>>>>> connect to Directory Server via EXTERNAL auth. >>>>>> >>>>>> You can verify yourself if that bind works or not with the following ldapsearch >>>>>> (just replace $LDAP_URI_VALUE with your setting): >>>>>> >>>>>> # ldapsearch -Y EXTERNAL -H $LDAP_URI_VALUE -b >>>>>> "cn=masters,cn=ipa,cn=etc,dc=cliff,dc=cloudburrito,dc=com" >>>>>> >>>>>> I assume it will report the same error as ipactl. We need to verify that the >>>>>> referred LDAP URI is indeed right and functional. >>>>>> >>>>>> Martin >>>>> The system had no /etc/ipa/default.conf >>>>> I copied the one from the master server, changed the `host=` and >>>>> `xmlrpc_uri=` parameters to reflect the replica server, and now `ipactl >>>>> status`, along with everything else, is working perfectly. >>>>> Should that file have been created during the `ipa-replica-install` >>>>> process? I don't see anything in the documentation about having to copy >>>>> and edit it manually. >>>>> >>>>> Thanks >>>>> >>>>> -Patrick >>>>> >>>> Yeah, this should have been created during ipa-replica-install. >>>> >>>> Can you please check /var/log/ipareplica-install.log and check if >>>> ipa-client-install (which is run as part of ipa-replica-install) succeeded? I >>>> have a suspicion you hit a bug I was fixing recently. >>>> >>>> Martin >>> No, the client install failed: >>> 2013-01-29T23:24:05Z DEBUG stderr= >>> 2013-01-29T23:24:05Z DEBUG Restarting the web server >>> 2013-01-29T23:24:06Z DEBUG args=/sbin/service httpd restart >>> 2013-01-29T23:24:06Z DEBUG stdout=Stopping httpd: [ OK ] >>> Starting httpd: [ OK ] >>> >>> 2013-01-29T23:24:06Z DEBUG stderr= >>> 2013-01-29T23:24:20Z DEBUG args=/usr/sbin/ipa-client-install --on-master >>> --unattended --domain cliff.cloudburrito.com --server >>> i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com --realm >>> CLIFF.CLOUDBURRITO.COM >>> 2013-01-29T23:24:20Z DEBUG stdout=Discovery was successful! >>> Hostname: i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com >>> Realm: CLIFF.CLOUDBURRITO.COM >>> DNS Domain: cliff.cloudburrito.com >>> IPA Server: i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com >>> BaseDN: dc=cliff,dc=cloudburrito,dc=com >>> >>> >>> Configured /etc/sssd/sssd.conf >>> Installation failed. Rolling back changes. >>> >>> 2013-01-29T23:24:20Z DEBUG stderr=DNS domain 'cliff.cloudburrito.com' is >>> not configured for automatic KDC address lookup. >>> KDC address will be set to fixed value. >>> >>> Failed to add CA to the default NSS database. >>> >>> 2013-01-29T23:24:20Z DEBUG Failed to configure the client >>> File "/usr/sbin/ipa-replica-install", line 496, in >>> main() >>> >>> File "/usr/sbin/ipa-replica-install", line 485, in main >>> raise RuntimeError("Failed to configure the client") >>> >> Getting warmer... Can you please check /var/log/ipaclient-install.log if there >> is a reason why it failed? The problem here is that the client removed >> default.conf, keytabs etc. when it uninstalled itself due to the failure. >> >> Thanks, >> Martin > Below is the last few lines of the file. > It looks like it's failing because sssd is already configured. This is > true as our servers are preconfigured for sssd to use the IPA master > server. If this is indeed the cause, is there any way to have it not > configure sssd? Or should I wipe the sssd config before attempting to > set up the replica? > Could it also be fixed so that if the client install does fail, that it > doesn't break the server? > > 2013-01-30T16:28:38Z DEBUG stderr= > 2013-01-30T16:28:38Z DEBUG Restoring client configuration files > 2013-01-30T16:28:38Z DEBUG args=/usr/sbin/selinuxenabled > 2013-01-30T16:28:38Z DEBUG stdout= > 2013-01-30T16:28:38Z DEBUG stderr= > 2013-01-30T16:28:38Z DEBUG Saving Index File to > '/var/lib/ipa-client/sysrestore/sysrestore.index' > 2013-01-30T16:28:38Z DEBUG -> no files, removing file > 2013-01-30T16:28:38Z DEBUG args=/sbin/service nscd status > 2013-01-30T16:28:38Z DEBUG stdout= > 2013-01-30T16:28:38Z DEBUG stderr=nscd: unrecognized service > > 2013-01-30T16:28:38Z INFO nscd daemon is not installed, skip configuration > 2013-01-30T16:28:38Z DEBUG args=/sbin/service nslcd status > 2013-01-30T16:28:38Z DEBUG stdout= > 2013-01-30T16:28:38Z DEBUG stderr=nslcd: unrecognized service > > 2013-01-30T16:28:38Z INFO nslcd daemon is not installed, skip configuration > 2013-01-30T16:28:38Z DEBUG The original configuration of SSSD included > other domains than IPA-based one. > 2013-01-30T16:28:38Z DEBUG Original configuration file is restored, > restarting SSSD service. > 2013-01-30T16:28:38Z DEBUG args=/sbin/service sssd restart > 2013-01-30T16:28:38Z DEBUG stdout=Stopping sssd: [FAILED] > Starting sssd: [ OK ] > > 2013-01-30T16:28:38Z DEBUG stderr=cat: /var/run/sssd.pid: No such file > or directory > Any what do SSSD logs say? I seems that restart of SSSD did not go that smoothly. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From freeipa at stormcloud9.net Wed Jan 30 17:02:30 2013 From: freeipa at stormcloud9.net (freeipa at stormcloud9.net) Date: Wed, 30 Jan 2013 12:02:30 -0500 Subject: [Freeipa-users] Unable to start replica server after setting up replication In-Reply-To: <51095171.6080405@redhat.com> References: <510868CF.3020004@stormcloud9.net> <51086E26.7060907@redhat.com> <510871CD.9060707@stormcloud9.net> <5108DADE.9060103@redhat.com> <51092B51.2000707@stormcloud9.net> <51092C0D.1080606@redhat.com> <51092CBA.2010905@stormcloud9.net> <5109302F.70403@redhat.com> <51094DA3.1090604@stormcloud9.net> <51095171.6080405@redhat.com> Message-ID: <51095226.3010303@stormcloud9.net> On 2013/30/01 11:59, Dmitri Pal wrote: > On 01/30/2013 11:43 AM, freeipa at stormcloud9.net wrote: >> On 2013/30/01 09:37, Martin Kosek wrote: >>> On 01/30/2013 03:22 PM, freeipa at stormcloud9.net wrote: >>>> On 2013/30/01 09:19, Martin Kosek wrote: >>>>> On 01/30/2013 03:16 PM, Patrick Hemmer wrote: >>>>>> On 2013/30/01 03:33, Martin Kosek wrote: >>>>>>> On 01/30/2013 02:05 AM, freeipa at stormcloud9.net wrote: >>>>>>>> On 01/29/2013 07:49 PM, Dmitri Pal wrote: >>>>>>>>> On 01/29/2013 07:26 PM, freeipa at stormcloud9.net wrote: >>>>>>>>>> Using ipa-server 2.2.0-17 on Amazon linux (RHEL6 clone), and after using the >>>>>>>>>> `ipa-replica-install` script to configure the replica server, the service >>>>>>>>>> will not start. Whenever I try it throws "SASL(-4): no mechanism available" >>>>>>>>>> during start. >>>>>>>>>> >>>>>>>>>> Any ideas? >>>>>>>>>> >>>>>>>>>> Full output: >>>>>>>>>> >>>>>>>>>> # /etc/init.d/ipa start >>>>>>>>>> Starting Directory Service >>>>>>>>>> Starting dirsrv: >>>>>>>>>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>>>>>>>>> PKI-IPA... [ OK ] >>>>>>>>>> Failed to read data from Directory Service: Unknown error when retrieving >>>>>>>>>> list of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', >>>>>>>>>> 'desc': 'Unknown authentication method'} >>>>>>>>>> Shutting down >>>>>>>>>> Shutting down dirsrv: >>>>>>>>>> CLIFF-CLOUDBURRITO-COM... [ OK ] >>>>>>>>>> PKI-IPA... [ OK ] >>>>>>>>> Sounds like DS did not start under the CA. Please check the DS logs in the >>>>>>>>> PKI instance. >>>>>>>> ns-slapd appears to be starting fine. I can even start it manually, but `ipactl >>>>>>>> status` still shows the error: >>>>>>>> Below is the result of me starting it manually (directly running ns-slapd): >>>>>>>> >>>>>>>> # ps ax|grep slapd >>>>>>>> 15540 ? Sl 0:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-PKI-IPA -i >>>>>>>> /var/run/dirsrv/slapd-PKI-IPA.pid -w /var/run/dirsrv/slapd-PKI-IPA.startpid >>>>>>>> 15586 ? Sl 0:00 /usr/sbin/ns-slapd -D >>>>>>>> /etc/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM -i >>>>>>>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.pid -w >>>>>>>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.startpid >>>>>>>> # netstat -tpnl | grep slapd >>>>>>>> tcp 0 0 :::636 :::* >>>>>>>> LISTEN 15586/ns-slapd >>>>>>>> tcp 0 0 :::7389 :::* >>>>>>>> LISTEN 15540/ns-slapd >>>>>>>> tcp 0 0 :::7390 :::* >>>>>>>> LISTEN 15540/ns-slapd >>>>>>>> tcp 0 0 :::389 :::* >>>>>>>> LISTEN 15586/ns-slapd >>>>>>>> # ipactl status >>>>>>>> Directory Service: RUNNING >>>>>>>> Unknown error when retrieving list of services from LDAP: {'info': 'SASL(-4): >>>>>>>> no mechanism available: ', 'desc': 'Unknown authentication method'} >>>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> OK, it seems that ipactl could not bind to your Directory Server. This script >>>>>>> uses a "ldap_uri" configuration option value from /etc/ipa/default.conf to >>>>>>> connect to Directory Server via EXTERNAL auth. >>>>>>> >>>>>>> You can verify yourself if that bind works or not with the following ldapsearch >>>>>>> (just replace $LDAP_URI_VALUE with your setting): >>>>>>> >>>>>>> # ldapsearch -Y EXTERNAL -H $LDAP_URI_VALUE -b >>>>>>> "cn=masters,cn=ipa,cn=etc,dc=cliff,dc=cloudburrito,dc=com" >>>>>>> >>>>>>> I assume it will report the same error as ipactl. We need to verify that the >>>>>>> referred LDAP URI is indeed right and functional. >>>>>>> >>>>>>> Martin >>>>>> The system had no /etc/ipa/default.conf >>>>>> I copied the one from the master server, changed the `host=` and >>>>>> `xmlrpc_uri=` parameters to reflect the replica server, and now `ipactl >>>>>> status`, along with everything else, is working perfectly. >>>>>> Should that file have been created during the `ipa-replica-install` >>>>>> process? I don't see anything in the documentation about having to copy >>>>>> and edit it manually. >>>>>> >>>>>> Thanks >>>>>> >>>>>> -Patrick >>>>>> >>>>> Yeah, this should have been created during ipa-replica-install. >>>>> >>>>> Can you please check /var/log/ipareplica-install.log and check if >>>>> ipa-client-install (which is run as part of ipa-replica-install) succeeded? I >>>>> have a suspicion you hit a bug I was fixing recently. >>>>> >>>>> Martin >>>> No, the client install failed: >>>> 2013-01-29T23:24:05Z DEBUG stderr= >>>> 2013-01-29T23:24:05Z DEBUG Restarting the web server >>>> 2013-01-29T23:24:06Z DEBUG args=/sbin/service httpd restart >>>> 2013-01-29T23:24:06Z DEBUG stdout=Stopping httpd: [ OK ] >>>> Starting httpd: [ OK ] >>>> >>>> 2013-01-29T23:24:06Z DEBUG stderr= >>>> 2013-01-29T23:24:20Z DEBUG args=/usr/sbin/ipa-client-install --on-master >>>> --unattended --domain cliff.cloudburrito.com --server >>>> i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com --realm >>>> CLIFF.CLOUDBURRITO.COM >>>> 2013-01-29T23:24:20Z DEBUG stdout=Discovery was successful! >>>> Hostname: i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com >>>> Realm: CLIFF.CLOUDBURRITO.COM >>>> DNS Domain: cliff.cloudburrito.com >>>> IPA Server: i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com >>>> BaseDN: dc=cliff,dc=cloudburrito,dc=com >>>> >>>> >>>> Configured /etc/sssd/sssd.conf >>>> Installation failed. Rolling back changes. >>>> >>>> 2013-01-29T23:24:20Z DEBUG stderr=DNS domain 'cliff.cloudburrito.com' is >>>> not configured for automatic KDC address lookup. >>>> KDC address will be set to fixed value. >>>> >>>> Failed to add CA to the default NSS database. >>>> >>>> 2013-01-29T23:24:20Z DEBUG Failed to configure the client >>>> File "/usr/sbin/ipa-replica-install", line 496, in >>>> main() >>>> >>>> File "/usr/sbin/ipa-replica-install", line 485, in main >>>> raise RuntimeError("Failed to configure the client") >>>> >>> Getting warmer... Can you please check /var/log/ipaclient-install.log if there >>> is a reason why it failed? The problem here is that the client removed >>> default.conf, keytabs etc. when it uninstalled itself due to the failure. >>> >>> Thanks, >>> Martin >> Below is the last few lines of the file. >> It looks like it's failing because sssd is already configured. This is >> true as our servers are preconfigured for sssd to use the IPA master >> server. If this is indeed the cause, is there any way to have it not >> configure sssd? Or should I wipe the sssd config before attempting to >> set up the replica? >> Could it also be fixed so that if the client install does fail, that it >> doesn't break the server? >> >> 2013-01-30T16:28:38Z DEBUG stderr= >> 2013-01-30T16:28:38Z DEBUG Restoring client configuration files >> 2013-01-30T16:28:38Z DEBUG args=/usr/sbin/selinuxenabled >> 2013-01-30T16:28:38Z DEBUG stdout= >> 2013-01-30T16:28:38Z DEBUG stderr= >> 2013-01-30T16:28:38Z DEBUG Saving Index File to >> '/var/lib/ipa-client/sysrestore/sysrestore.index' >> 2013-01-30T16:28:38Z DEBUG -> no files, removing file >> 2013-01-30T16:28:38Z DEBUG args=/sbin/service nscd status >> 2013-01-30T16:28:38Z DEBUG stdout= >> 2013-01-30T16:28:38Z DEBUG stderr=nscd: unrecognized service >> >> 2013-01-30T16:28:38Z INFO nscd daemon is not installed, skip configuration >> 2013-01-30T16:28:38Z DEBUG args=/sbin/service nslcd status >> 2013-01-30T16:28:38Z DEBUG stdout= >> 2013-01-30T16:28:38Z DEBUG stderr=nslcd: unrecognized service >> >> 2013-01-30T16:28:38Z INFO nslcd daemon is not installed, skip configuration >> 2013-01-30T16:28:38Z DEBUG The original configuration of SSSD included >> other domains than IPA-based one. >> 2013-01-30T16:28:38Z DEBUG Original configuration file is restored, >> restarting SSSD service. >> 2013-01-30T16:28:38Z DEBUG args=/sbin/service sssd restart >> 2013-01-30T16:28:38Z DEBUG stdout=Stopping sssd: [FAILED] >> Starting sssd: [ OK ] >> >> 2013-01-30T16:28:38Z DEBUG stderr=cat: /var/run/sssd.pid: No such file >> or directory >> > Any what do SSSD logs say? > I seems that restart of SSSD did not go that smoothly. sssd started up fine, it's running right now. Looks like a race condition, the pid file has an mtime of 16:28:38, the same second as the "No such file or directory" error. From jhrozek at redhat.com Wed Jan 30 18:13:46 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 30 Jan 2013 19:13:46 +0100 Subject: [Freeipa-users] Unable to start replica server after setting up replication In-Reply-To: <51095226.3010303@stormcloud9.net> References: <51086E26.7060907@redhat.com> <510871CD.9060707@stormcloud9.net> <5108DADE.9060103@redhat.com> <51092B51.2000707@stormcloud9.net> <51092C0D.1080606@redhat.com> <51092CBA.2010905@stormcloud9.net> <5109302F.70403@redhat.com> <51094DA3.1090604@stormcloud9.net> <51095171.6080405@redhat.com> <51095226.3010303@stormcloud9.net> Message-ID: <20130130181346.GL28593@hendrix.brq.redhat.com> On Wed, Jan 30, 2013 at 12:02:30PM -0500, freeipa at stormcloud9.net wrote: > > On 2013/30/01 11:59, Dmitri Pal wrote: > > On 01/30/2013 11:43 AM, freeipa at stormcloud9.net wrote: > >> On 2013/30/01 09:37, Martin Kosek wrote: > >>> On 01/30/2013 03:22 PM, freeipa at stormcloud9.net wrote: > >>>> On 2013/30/01 09:19, Martin Kosek wrote: > >>>>> On 01/30/2013 03:16 PM, Patrick Hemmer wrote: > >>>>>> On 2013/30/01 03:33, Martin Kosek wrote: > >>>>>>> On 01/30/2013 02:05 AM, freeipa at stormcloud9.net wrote: > >>>>>>>> On 01/29/2013 07:49 PM, Dmitri Pal wrote: > >>>>>>>>> On 01/29/2013 07:26 PM, freeipa at stormcloud9.net wrote: > >>>>>>>>>> Using ipa-server 2.2.0-17 on Amazon linux (RHEL6 clone), and after using the > >>>>>>>>>> `ipa-replica-install` script to configure the replica server, the service > >>>>>>>>>> will not start. Whenever I try it throws "SASL(-4): no mechanism available" > >>>>>>>>>> during start. > >>>>>>>>>> > >>>>>>>>>> Any ideas? > >>>>>>>>>> > >>>>>>>>>> Full output: > >>>>>>>>>> > >>>>>>>>>> # /etc/init.d/ipa start > >>>>>>>>>> Starting Directory Service > >>>>>>>>>> Starting dirsrv: > >>>>>>>>>> CLIFF-CLOUDBURRITO-COM... [ OK ] > >>>>>>>>>> PKI-IPA... [ OK ] > >>>>>>>>>> Failed to read data from Directory Service: Unknown error when retrieving > >>>>>>>>>> list of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', > >>>>>>>>>> 'desc': 'Unknown authentication method'} > >>>>>>>>>> Shutting down > >>>>>>>>>> Shutting down dirsrv: > >>>>>>>>>> CLIFF-CLOUDBURRITO-COM... [ OK ] > >>>>>>>>>> PKI-IPA... [ OK ] > >>>>>>>>> Sounds like DS did not start under the CA. Please check the DS logs in the > >>>>>>>>> PKI instance. > >>>>>>>> ns-slapd appears to be starting fine. I can even start it manually, but `ipactl > >>>>>>>> status` still shows the error: > >>>>>>>> Below is the result of me starting it manually (directly running ns-slapd): > >>>>>>>> > >>>>>>>> # ps ax|grep slapd > >>>>>>>> 15540 ? Sl 0:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-PKI-IPA -i > >>>>>>>> /var/run/dirsrv/slapd-PKI-IPA.pid -w /var/run/dirsrv/slapd-PKI-IPA.startpid > >>>>>>>> 15586 ? Sl 0:00 /usr/sbin/ns-slapd -D > >>>>>>>> /etc/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM -i > >>>>>>>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.pid -w > >>>>>>>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.startpid > >>>>>>>> # netstat -tpnl | grep slapd > >>>>>>>> tcp 0 0 :::636 :::* > >>>>>>>> LISTEN 15586/ns-slapd > >>>>>>>> tcp 0 0 :::7389 :::* > >>>>>>>> LISTEN 15540/ns-slapd > >>>>>>>> tcp 0 0 :::7390 :::* > >>>>>>>> LISTEN 15540/ns-slapd > >>>>>>>> tcp 0 0 :::389 :::* > >>>>>>>> LISTEN 15586/ns-slapd > >>>>>>>> # ipactl status > >>>>>>>> Directory Service: RUNNING > >>>>>>>> Unknown error when retrieving list of services from LDAP: {'info': 'SASL(-4): > >>>>>>>> no mechanism available: ', 'desc': 'Unknown authentication method'} > >>>>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> OK, it seems that ipactl could not bind to your Directory Server. This script > >>>>>>> uses a "ldap_uri" configuration option value from /etc/ipa/default.conf to > >>>>>>> connect to Directory Server via EXTERNAL auth. > >>>>>>> > >>>>>>> You can verify yourself if that bind works or not with the following ldapsearch > >>>>>>> (just replace $LDAP_URI_VALUE with your setting): > >>>>>>> > >>>>>>> # ldapsearch -Y EXTERNAL -H $LDAP_URI_VALUE -b > >>>>>>> "cn=masters,cn=ipa,cn=etc,dc=cliff,dc=cloudburrito,dc=com" > >>>>>>> > >>>>>>> I assume it will report the same error as ipactl. We need to verify that the > >>>>>>> referred LDAP URI is indeed right and functional. > >>>>>>> > >>>>>>> Martin > >>>>>> The system had no /etc/ipa/default.conf > >>>>>> I copied the one from the master server, changed the `host=` and > >>>>>> `xmlrpc_uri=` parameters to reflect the replica server, and now `ipactl > >>>>>> status`, along with everything else, is working perfectly. > >>>>>> Should that file have been created during the `ipa-replica-install` > >>>>>> process? I don't see anything in the documentation about having to copy > >>>>>> and edit it manually. > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> -Patrick > >>>>>> > >>>>> Yeah, this should have been created during ipa-replica-install. > >>>>> > >>>>> Can you please check /var/log/ipareplica-install.log and check if > >>>>> ipa-client-install (which is run as part of ipa-replica-install) succeeded? I > >>>>> have a suspicion you hit a bug I was fixing recently. > >>>>> > >>>>> Martin > >>>> No, the client install failed: > >>>> 2013-01-29T23:24:05Z DEBUG stderr= > >>>> 2013-01-29T23:24:05Z DEBUG Restarting the web server > >>>> 2013-01-29T23:24:06Z DEBUG args=/sbin/service httpd restart > >>>> 2013-01-29T23:24:06Z DEBUG stdout=Stopping httpd: [ OK ] > >>>> Starting httpd: [ OK ] > >>>> > >>>> 2013-01-29T23:24:06Z DEBUG stderr= > >>>> 2013-01-29T23:24:20Z DEBUG args=/usr/sbin/ipa-client-install --on-master > >>>> --unattended --domain cliff.cloudburrito.com --server > >>>> i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com --realm > >>>> CLIFF.CLOUDBURRITO.COM > >>>> 2013-01-29T23:24:20Z DEBUG stdout=Discovery was successful! > >>>> Hostname: i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com > >>>> Realm: CLIFF.CLOUDBURRITO.COM > >>>> DNS Domain: cliff.cloudburrito.com > >>>> IPA Server: i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com > >>>> BaseDN: dc=cliff,dc=cloudburrito,dc=com > >>>> > >>>> > >>>> Configured /etc/sssd/sssd.conf > >>>> Installation failed. Rolling back changes. > >>>> > >>>> 2013-01-29T23:24:20Z DEBUG stderr=DNS domain 'cliff.cloudburrito.com' is > >>>> not configured for automatic KDC address lookup. > >>>> KDC address will be set to fixed value. > >>>> > >>>> Failed to add CA to the default NSS database. > >>>> > >>>> 2013-01-29T23:24:20Z DEBUG Failed to configure the client > >>>> File "/usr/sbin/ipa-replica-install", line 496, in > >>>> main() > >>>> > >>>> File "/usr/sbin/ipa-replica-install", line 485, in main > >>>> raise RuntimeError("Failed to configure the client") > >>>> > >>> Getting warmer... Can you please check /var/log/ipaclient-install.log if there > >>> is a reason why it failed? The problem here is that the client removed > >>> default.conf, keytabs etc. when it uninstalled itself due to the failure. > >>> > >>> Thanks, > >>> Martin > >> Below is the last few lines of the file. > >> It looks like it's failing because sssd is already configured. This is > >> true as our servers are preconfigured for sssd to use the IPA master > >> server. If this is indeed the cause, is there any way to have it not > >> configure sssd? Or should I wipe the sssd config before attempting to > >> set up the replica? > >> Could it also be fixed so that if the client install does fail, that it > >> doesn't break the server? > >> > >> 2013-01-30T16:28:38Z DEBUG stderr= > >> 2013-01-30T16:28:38Z DEBUG Restoring client configuration files > >> 2013-01-30T16:28:38Z DEBUG args=/usr/sbin/selinuxenabled > >> 2013-01-30T16:28:38Z DEBUG stdout= > >> 2013-01-30T16:28:38Z DEBUG stderr= > >> 2013-01-30T16:28:38Z DEBUG Saving Index File to > >> '/var/lib/ipa-client/sysrestore/sysrestore.index' > >> 2013-01-30T16:28:38Z DEBUG -> no files, removing file > >> 2013-01-30T16:28:38Z DEBUG args=/sbin/service nscd status > >> 2013-01-30T16:28:38Z DEBUG stdout= > >> 2013-01-30T16:28:38Z DEBUG stderr=nscd: unrecognized service > >> > >> 2013-01-30T16:28:38Z INFO nscd daemon is not installed, skip configuration > >> 2013-01-30T16:28:38Z DEBUG args=/sbin/service nslcd status > >> 2013-01-30T16:28:38Z DEBUG stdout= > >> 2013-01-30T16:28:38Z DEBUG stderr=nslcd: unrecognized service > >> > >> 2013-01-30T16:28:38Z INFO nslcd daemon is not installed, skip configuration > >> 2013-01-30T16:28:38Z DEBUG The original configuration of SSSD included > >> other domains than IPA-based one. > >> 2013-01-30T16:28:38Z DEBUG Original configuration file is restored, > >> restarting SSSD service. > >> 2013-01-30T16:28:38Z DEBUG args=/sbin/service sssd restart > >> 2013-01-30T16:28:38Z DEBUG stdout=Stopping sssd: [FAILED] > >> Starting sssd: [ OK ] > >> > >> 2013-01-30T16:28:38Z DEBUG stderr=cat: /var/run/sssd.pid: No such file > >> or directory > >> > > Any what do SSSD logs say? > > I seems that restart of SSSD did not go that smoothly. > > sssd started up fine, it's running right now. Looks like a race > condition, the pid file has an mtime of 16:28:38, the same second as the > "No such file or directory" error. There was an error fixed in 1.9 (and hence RHEL-6.4) where the SSSD init scripts would report success and the sssd would write pidfile before all the subprocesses that actually talk to the remote servers were up. Starting the SSSD so that it's in a full functional state can take up toa couple of seconds. In 6.4 you should see [OK] after a delay when the SSSD is starting up. From christianh at 4over.com Wed Jan 30 22:41:33 2013 From: christianh at 4over.com (Christian Hernandez) Date: Wed, 30 Jan 2013 14:41:33 -0800 Subject: [Freeipa-users] Error Starting IPA after crash Message-ID: Hello, I had a crash due to full disks. I cleared the offending directory (backups and such). But I cannot start IPA. I drilled it down to the DirSrv not starting. Isolating the error I tried just starting the dirsrv service dirsrv start But I'm seeing this in the logs.... [30/Jan/2013:13:51:40 -0800] - 389-Directory/1.2.10.2 B2012.194.51 starting up [30/Jan/2013:13:51:40 -0800] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [30/Jan/2013:14:06:06 -0800] - Unable to start slapd because it is already running as process 1543 [30/Jan/2013:14:06:06 -0800] - Shutting down due to possible conflicts with other slapd processes [30/Jan/2013:14:08:15 -0800] - Unable to start slapd because it is already running as process 1543 [30/Jan/2013:14:08:15 -0800] - Shutting down due to possible conflicts with other slapd processes [30/Jan/2013:14:14:05 -0800] - 389-Directory/1.2.10.2 B2012.194.51 starting up [30/Jan/2013:14:14:05 -0800] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [30/Jan/2013:14:14:05 -0800] - libdb: unable to join the environment I have a replica that is running; so the "heat" is off - but is there any way to get this started? Thank you, Christian Hernandez -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Jan 30 23:36:21 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 30 Jan 2013 16:36:21 -0700 Subject: [Freeipa-users] Error Starting IPA after crash In-Reply-To: References: Message-ID: <5109AE75.1070905@redhat.com> On 01/30/2013 03:41 PM, Christian Hernandez wrote: > Hello, > > I had a crash due to full disks. I cleared the offending directory > (backups and such). > > But I cannot start IPA. I drilled it down to the DirSrv not starting. > > Isolating the error I tried just starting the dirsrv > > service dirsrv start > > But I'm seeing this in the logs.... > > > [30/Jan/2013:13:51:40 -0800] - 389-Directory/1.2.10.2 > B2012.194.51 starting up > [30/Jan/2013:13:51:40 -0800] - Detected Disorderly Shutdown last time > Directory Server was running, recovering database. > [30/Jan/2013:14:06:06 -0800] - Unable to start slapd because it is > already running as process 1543 > [30/Jan/2013:14:06:06 -0800] - Shutting down due to possible conflicts > with other slapd processes > [30/Jan/2013:14:08:15 -0800] - Unable to start slapd because it is > already running as process 1543 > [30/Jan/2013:14:08:15 -0800] - Shutting down due to possible conflicts > with other slapd processes > [30/Jan/2013:14:14:05 -0800] - 389-Directory/1.2.10.2 > B2012.194.51 starting up > [30/Jan/2013:14:14:05 -0800] - Detected Disorderly Shutdown last time > Directory Server was running, recovering database. > [30/Jan/2013:14:14:05 -0800] - libdb: unable to join the environment > > I have a replica that is running; so the "heat" is off - but is there > any way to get this started? I'm assuming you are running on EL6.3? ps -ef|grep slapd ls -al /var/lib/dirsrv/slapd-INST/db > > Thank you, > > Christian Hernandez > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From christianh at 4over.com Wed Jan 30 23:46:35 2013 From: christianh at 4over.com (Christian Hernandez) Date: Wed, 30 Jan 2013 15:46:35 -0800 Subject: [Freeipa-users] Error Starting IPA after crash In-Reply-To: <5109AE75.1070905@redhat.com> References: <5109AE75.1070905@redhat.com> Message-ID: Rich, Correct, running 6.3 [root at ipa1.gln.4over.com db]# ps -ef|grep slapd dirsrv 4899 1 7 14:25 ? 00:05:34 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-4OVER-COM -i /var/run/dirsrv/slapd-4OVER-COM.pid -w /var/run/dirsrv/slapd-4OVER-COM.startpid root 30545 3522 0 15:41 pts/1 00:00:00 grep slapd The output of the ls command is HUGE with...here is a suppresed output [root at ipa1.gln.4over.com db]# ls -al /var/lib/dirsrv/slapd-4OVER-COM/db/ | head -25 total 1465384 drwxrwx--- 3 dirsrv dirsrv 73728 Jan 30 15:44 . drwxrwx--- 6 dirsrv dirsrv 4096 Jan 14 16:52 .. -rw------- 1 dirsrv dirsrv 24576 Jan 30 15:42 __db.001 -rw------- 1 dirsrv dirsrv 1728512 Jan 30 15:44 __db.002 -rw------- 1 dirsrv dirsrv 10002432 Jan 30 15:44 __db.003 -rw------- 1 dirsrv dirsrv 1081344 Jan 30 15:44 __db.004 -rw------- 1 dirsrv dirsrv 8126464 Jan 30 15:44 __db.005 -rw------- 1 dirsrv dirsrv 90112 Jan 30 15:44 __db.006 -rw------- 1 dirsrv dirsrv 49 Jan 30 15:42 DBVERSION -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309284 -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309285 -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309286 -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309287 -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309288 -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309289 -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309290 -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309291 -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309292 -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309293 -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309294 -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309295 -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309296 -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309297 -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309298 I increased the "timeout" in the /etc/init.d/dirsrv to about 60000 to see if it will try and recover. Is there hope to recover this? Or should I just re-install the server and make it a replica (this used to be my "master" i.e. it was the first IPA server installed in our 3 server setup)? Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christianh at 4over.com www.4over.com On Wed, Jan 30, 2013 at 3:36 PM, Rich Megginson wrote: > On 01/30/2013 03:41 PM, Christian Hernandez wrote: > > Hello, > > I had a crash due to full disks. I cleared the offending directory > (backups and such). > > But I cannot start IPA. I drilled it down to the DirSrv not starting. > > Isolating the error I tried just starting the dirsrv > > service dirsrv start > > But I'm seeing this in the logs.... > > > [30/Jan/2013:13:51:40 -0800] - 389-Directory/1.2.10.2 B2012.194.51 > starting up > [30/Jan/2013:13:51:40 -0800] - Detected Disorderly Shutdown last time > Directory Server was running, recovering database. > [30/Jan/2013:14:06:06 -0800] - Unable to start slapd because it is already > running as process 1543 > [30/Jan/2013:14:06:06 -0800] - Shutting down due to possible conflicts > with other slapd processes > [30/Jan/2013:14:08:15 -0800] - Unable to start slapd because it is already > running as process 1543 > [30/Jan/2013:14:08:15 -0800] - Shutting down due to possible conflicts > with other slapd processes > [30/Jan/2013:14:14:05 -0800] - 389-Directory/1.2.10.2 B2012.194.51 > starting up > [30/Jan/2013:14:14:05 -0800] - Detected Disorderly Shutdown last time > Directory Server was running, recovering database. > [30/Jan/2013:14:14:05 -0800] - libdb: unable to join the environment > > I have a replica that is running; so the "heat" is off - but is there > any way to get this started? > > > I'm assuming you are running on EL6.3? > > ps -ef|grep slapd > > ls -al /var/lib/dirsrv/slapd-INST/db > > > Thank you, > > Christian Hernandez > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Jan 31 00:01:47 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 30 Jan 2013 17:01:47 -0700 Subject: [Freeipa-users] Error Starting IPA after crash In-Reply-To: References: <5109AE75.1070905@redhat.com> Message-ID: <5109B46B.6060306@redhat.com> On 01/30/2013 04:46 PM, Christian Hernandez wrote: > Rich, > > Correct, running 6.3 > > [root at ipa1.gln.4over.com db]# ps > -ef|grep slapd > dirsrv 4899 1 7 14:25 ? 00:05:34 /usr/sbin/ns-slapd -D > /etc/dirsrv/slapd-4OVER-COM -i /var/run/dirsrv/slapd-4OVER-COM.pid -w > /var/run/dirsrv/slapd-4OVER-COM.startpid > root 30545 3522 0 15:41 pts/1 00:00:00 grep slapd > > The output of the ls command is HUGE with...here is a suppresed output > > [root at ipa1.gln.4over.com db]# ls -al > /var/lib/dirsrv/slapd-4OVER-COM/db/ | head -25 > total 1465384 > drwxrwx--- 3 dirsrv dirsrv 73728 Jan 30 15:44 . > drwxrwx--- 6 dirsrv dirsrv 4096 Jan 14 16:52 .. > -rw------- 1 dirsrv dirsrv 24576 Jan 30 15:42 __db.001 > -rw------- 1 dirsrv dirsrv 1728512 Jan 30 15:44 __db.002 > -rw------- 1 dirsrv dirsrv 10002432 Jan 30 15:44 __db.003 > -rw------- 1 dirsrv dirsrv 1081344 Jan 30 15:44 __db.004 > -rw------- 1 dirsrv dirsrv 8126464 Jan 30 15:44 __db.005 > -rw------- 1 dirsrv dirsrv 90112 Jan 30 15:44 __db.006 > -rw------- 1 dirsrv dirsrv 49 Jan 30 15:42 DBVERSION > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309284 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309285 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309286 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309287 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309288 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309289 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309290 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309291 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309292 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309293 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309294 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309295 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309296 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309297 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309298 > > > I increased the "timeout" in the /etc/init.d/dirsrv to about 60000 to > see if it will try and recover. Sounds good. If you have that many log files, it may take a while to recover. > > Is there hope to recover this? Or should I just re-install the server > and make it a replica (this used to be my "master" i.e. it was the > first IPA server installed in our 3 server setup)? Try the increased timeout. > > Thank you, > > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > > > www.4over.com > > > > On Wed, Jan 30, 2013 at 3:36 PM, Rich Megginson > wrote: > > On 01/30/2013 03:41 PM, Christian Hernandez wrote: >> Hello, >> >> I had a crash due to full disks. I cleared the offending >> directory (backups and such). >> >> But I cannot start IPA. I drilled it down to the DirSrv not >> starting. >> >> Isolating the error I tried just starting the dirsrv >> >> service dirsrv start >> >> But I'm seeing this in the logs.... >> >> >> [30/Jan/2013:13:51:40 -0800] - 389-Directory/1.2.10.2 >> B2012.194.51 starting up >> [30/Jan/2013:13:51:40 -0800] - Detected Disorderly Shutdown last >> time Directory Server was running, recovering database. >> [30/Jan/2013:14:06:06 -0800] - Unable to start slapd because it >> is already running as process 1543 >> [30/Jan/2013:14:06:06 -0800] - Shutting down due to possible >> conflicts with other slapd processes >> [30/Jan/2013:14:08:15 -0800] - Unable to start slapd because it >> is already running as process 1543 >> [30/Jan/2013:14:08:15 -0800] - Shutting down due to possible >> conflicts with other slapd processes >> [30/Jan/2013:14:14:05 -0800] - 389-Directory/1.2.10.2 >> B2012.194.51 starting up >> [30/Jan/2013:14:14:05 -0800] - Detected Disorderly Shutdown last >> time Directory Server was running, recovering database. >> [30/Jan/2013:14:14:05 -0800] - libdb: unable to join the environment >> >> I have a replica that is running; so the "heat" is off - but is >> there any way to get this started? > > I'm assuming you are running on EL6.3? > > ps -ef|grep slapd > > ls -al /var/lib/dirsrv/slapd-INST/db >> >> Thank you, >> >> Christian Hernandez >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christianh at 4over.com Thu Jan 31 00:53:33 2013 From: christianh at 4over.com (Christian Hernandez) Date: Wed, 30 Jan 2013 16:53:33 -0800 Subject: [Freeipa-users] Error Starting IPA after crash In-Reply-To: <5109B46B.6060306@redhat.com> References: <5109AE75.1070905@redhat.com> <5109B46B.6060306@redhat.com> Message-ID: Just to update... I let the logs be read and now I can start IPA without a problem! Thanks for the help! :) Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christianh at 4over.com www.4over.com On Wed, Jan 30, 2013 at 4:01 PM, Rich Megginson wrote: > On 01/30/2013 04:46 PM, Christian Hernandez wrote: > > Rich, > > Correct, running 6.3 > > [root at ipa1.gln.4over.com db]# ps -ef|grep slapd > dirsrv 4899 1 7 14:25 ? 00:05:34 /usr/sbin/ns-slapd -D > /etc/dirsrv/slapd-4OVER-COM -i /var/run/dirsrv/slapd-4OVER-COM.pid -w > /var/run/dirsrv/slapd-4OVER-COM.startpid > root 30545 3522 0 15:41 pts/1 00:00:00 grep slapd > > The output of the ls command is HUGE with...here is a suppresed output > > [root at ipa1.gln.4over.com db]# ls -al /var/lib/dirsrv/slapd-4OVER-COM/db/ > | head -25 > total 1465384 > drwxrwx--- 3 dirsrv dirsrv 73728 Jan 30 15:44 . > drwxrwx--- 6 dirsrv dirsrv 4096 Jan 14 16:52 .. > -rw------- 1 dirsrv dirsrv 24576 Jan 30 15:42 __db.001 > -rw------- 1 dirsrv dirsrv 1728512 Jan 30 15:44 __db.002 > -rw------- 1 dirsrv dirsrv 10002432 Jan 30 15:44 __db.003 > -rw------- 1 dirsrv dirsrv 1081344 Jan 30 15:44 __db.004 > -rw------- 1 dirsrv dirsrv 8126464 Jan 30 15:44 __db.005 > -rw------- 1 dirsrv dirsrv 90112 Jan 30 15:44 __db.006 > -rw------- 1 dirsrv dirsrv 49 Jan 30 15:42 DBVERSION > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309284 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309285 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309286 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309287 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309288 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309289 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309290 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309291 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309292 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309293 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309294 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309295 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309296 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309297 > -rw------- 1 dirsrv dirsrv 10485760 Jan 30 15:43 log.0000309298 > > > I increased the "timeout" in the /etc/init.d/dirsrv to about 60000 to > see if it will try and recover. > > > Sounds good. If you have that many log files, it may take a while to > recover. > > > > Is there hope to recover this? Or should I just re-install the server > and make it a replica (this used to be my "master" i.e. it was the first > IPA server installed in our 3 server setup)? > > > Try the increased timeout. > > > > Thank you, > > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > www.4over.com > > > On Wed, Jan 30, 2013 at 3:36 PM, Rich Megginson wrote: > >> On 01/30/2013 03:41 PM, Christian Hernandez wrote: >> >> Hello, >> >> I had a crash due to full disks. I cleared the offending directory >> (backups and such). >> >> But I cannot start IPA. I drilled it down to the DirSrv not starting. >> >> Isolating the error I tried just starting the dirsrv >> >> service dirsrv start >> >> But I'm seeing this in the logs.... >> >> >> [30/Jan/2013:13:51:40 -0800] - 389-Directory/1.2.10.2 B2012.194.51 >> starting up >> [30/Jan/2013:13:51:40 -0800] - Detected Disorderly Shutdown last time >> Directory Server was running, recovering database. >> [30/Jan/2013:14:06:06 -0800] - Unable to start slapd because it is >> already running as process 1543 >> [30/Jan/2013:14:06:06 -0800] - Shutting down due to possible conflicts >> with other slapd processes >> [30/Jan/2013:14:08:15 -0800] - Unable to start slapd because it is >> already running as process 1543 >> [30/Jan/2013:14:08:15 -0800] - Shutting down due to possible conflicts >> with other slapd processes >> [30/Jan/2013:14:14:05 -0800] - 389-Directory/1.2.10.2 B2012.194.51 >> starting up >> [30/Jan/2013:14:14:05 -0800] - Detected Disorderly Shutdown last time >> Directory Server was running, recovering database. >> [30/Jan/2013:14:14:05 -0800] - libdb: unable to join the environment >> >> I have a replica that is running; so the "heat" is off - but is there >> any way to get this started? >> >> >> I'm assuming you are running on EL6.3? >> >> ps -ef|grep slapd >> >> ls -al /var/lib/dirsrv/slapd-INST/db >> >> >> Thank you, >> >> Christian Hernandez >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: